update kubeletconfig docs for v1.10, beta

docs/tasks/administer-cluster/kubelet-config-file.md

@@ -6,18 +6,20 @@ title: Set Kubelet parameters via a config file
 ---
 
 {% capture overview %}
-{% include feature-state-alpha.md %}
+{% include feature-state-beta.md %}
 
-As of Kubernetes 1.8, a subset of the Kubelet's configuration parameters may be
-set via an on-disk config file, as a substitute for command-line flags. In the
-future, most of the existing command-line flags will be deprecated in favor of
-providing parameters via a config file, which simplifies node deployment.
+A subset of the Kubelet's configuration parameters may be
+set via an on-disk config file, as a substitute for command-line flags.
+This functionality is considered beta in v1.10.
+
+Most of the existing command-line flags are deprecated in favor of providing
+parameters via a config file, which simplifies node deployment.
 
 {% endcapture %}
 
 {% capture prerequisites %}
 
-- A v1.8 or higher Kubelet binary must be installed.
+- A v1.10 or higher Kubelet binary must be installed for beta functionality.
 
 {% endcapture %}
 
@@ -27,24 +29,42 @@ providing parameters via a config file, which simplifies node deployment.
 
 The subset of the Kubelet's configuration that can be configured via a file
 is defined by the `KubeletConfiguration` struct
-[here (v1alpha1)](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1alpha1/types.go).
+[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
+
 The configuration file must be a JSON or YAML representation of the parameters
-in this struct. Note that this structure, and thus the config file API,
-is still considered alpha and is not subject to stability guarantees.
+in this struct. Make sure the Kubelet has read permissions on the file.
+
+Here is an example of what this file might look like:
+```
+kind: KubeletConfiguration
+apiVersion: kubeletconfig/v1beta1
+evictionHard:
+    memory.available:  "200Mi"
+```
 
-Create a file named `kubelet` in its own directory and make sure the directory
-and file are both readable by the Kubelet. You should write your intended
-Kubelet configuration in this `kubelet` file.
+In the example, the Kubelet is configured to evict Pods when available memory drops below 200Mi.
+All other Kubelet configuration values are left at their built-in defaults, unless overridden
+by flags. Command line flags which target the same value as a config file will override that value.
 
 For a trick to generate a configuration file from a live node, see
 [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet).
 
 ## Start a Kubelet process configured via the config file
 
-Start the Kubelet with the `--init-config-dir` flag set to the location of the directory
-containing the `kubelet` file. The Kubelet will then load the parameters defined
-by `KubeletConfiguration` from the `kubelet` file, rather than from their 
-associated command-line flags.
+Start the Kubelet with the `--config` flag set to the filepath of the Kubelet's config file.
+The Kubelet will then load its config from this file.
+
+Note that command line flags which target the same value as a config file will override that value.
+This helps ensure backwards compatibility with the command-line API.
+
+Note that relative file paths in the Kubelet config file are resolved relative to the
+location of the Kubelet config file, whereas relative paths in command line flags are resolved
+relative to the Kubelet's current working directory.
+
+Note that some default values differ between command-line flags and the Kubelet config file.
+If `--config` is provided and the values are not specified via the command line, the
+defaults for the `KubeletConfiguration` version apply.
+In the above example, this version is `kubeletconfig/v1beta1`.
 
 {% endcapture %}
 
@@ -53,16 +73,8 @@ associated command-line flags.
 ## Relationship to Dynamic Kubelet Config
 
 If you are using the [Dynamic Kubelet Configuration](/docs/tasks/administer-cluster/reconfigure-kubelet)
-feature, the configuration provided via `--init-config-dir` will be considered
-the "last known good" configuration by the automatic rollback mechanism.
-
-Note that the layout of the files in the `--init-config-dir` mirrors the layout
-of data in the ConfigMaps used for Dynamic Kubelet Config; the file names are
-the same as the keys of the ConfigMap, and the file contents are JSON or YAML
-representations of the same structures. Today, the only pair is 
-`kubelet:KubeletConfiguration`, though more may emerge in the future.
-See [Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet)
-for more information.
+feature, the combination of configuration provided via `--config` and any flags which override these values
+is considered the default "last known good" configuration by the automatic rollback mechanism.
 
 {% endcapture %}
 

docs/tasks/administer-cluster/reconfigure-kubelet.md

@@ -112,12 +112,14 @@ configz endpoint:
 
 ```
 $ export NODE_NAME=the-name-of-the-node-you-are-reconfiguring
-$ curl -sSL http://localhost:8001/api/v1/proxy/nodes/${NODE_NAME}/configz | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubeletconfig/v1alpha1"' > kubelet_configz_${NODE_NAME}
+$ curl -sSL http://localhost:8001/api/v1/proxy/nodes/${NODE_NAME}/configz | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubeletconfig/${VERSION}"' > kubelet_configz_${NODE_NAME}
 ```
 
 Note that we have to manually add the `kind` and `apiVersion` to the downloaded
 object, as these are not reported by the configz endpoint. This is one of the
 limitations of the endpoint that is planned to be fixed in the future.
+If you are using a Kubelet less than v1.10, you must substitute `v1alpha1` for `{VERSION}`.
+If you are using a Kubelet v1.10 or higher, you must substitute `v1beta1` for `{VERSION}`.
 
 ### Edit the configuration file