update kubeletconfig docs for v1.10, beta

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

@@ -6,18 +6,21 @@ 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.
+
+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.
 
 {% 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,10 +30,9 @@ 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.
 
 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
@@ -41,11 +43,10 @@ For a trick to generate a configuration file from a live node, see
 
 ## Start a Kubelet process configured via the config file
 
-Start the Kubelet with the `KubeletConfigFile` feature gate enabled and the 
-Kubelet's `--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. 
 
 {% endcapture %}
 
@@ -54,16 +55,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 flags and configuration provided via `--config` 
+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