Add doc on how to configure Kubelet with a file

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

@@ -0,0 +1,70 @@
+---
+approvers:
+- mtaufen
+- dawnchen
+title: Set Kubelet parameters via a config file
+---
+
+{% capture overview %}
+{% include feature-state-alpha.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.
+
+{% endcapture %}
+
+{% capture prerequisites %}
+
+- A v1.8 or higher Kubelet binary must be installed.
+
+{% endcapture %}
+
+{% capture steps %}
+
+## Create the config file
+
+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).
+The configuration file must be a JSON or YAML representation of the parameters
+in this struct. Note that that this structure, and thus the config file API,
+is still considured alpha and is not subject to stability gurarantees.
+
+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.
+
+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 `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.
+
+{% endcapture %}
+
+{% capture discussion %}
+
+## Relationship to Dynamic Kubelet Config
+
+If you are using the [Dynamic Kubelet Configuration](https://github.com/kubernetes/features/issues/281)
+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-conifg-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.
+
+{% endcapture %}
+
+{% include templates/task.md %}

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

@@ -89,12 +89,13 @@ and debug issues. The compromise, however, is that you must start with knowledge
 of the existing configuration to ensure that you only change the fields you
 intend to change.
 
-In the future, the Kubelet will be bootstrapped from a file on disk, and you
-will simply edit a copy of this file (which, as a best practice, should live in
-version control) while creating the first Kubelet ConfigMap. Today, however, the
-Kubelet is still bootstrapped with command-line flags. Fortunately, there is a
-dirty trick you can use to generate a config file containing a Node's current
-configuration. The trick involves hitting the Kubelet server's `configz`
+In the future, the Kubelet will be bootstrapped from a file on disk
+(see [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)),
+and you will simply edit a copy of this file (which, as a best practice, should
+live in version control) while creating the first Kubelet ConfigMap. Today,
+however, the Kubelet is still bootstrapped with command-line flags. Fortunately,
+there is a dirty trick you can use to generate a config file containing a Node's
+current configuration. The trick involves hitting the Kubelet server's `configz`
 endpoint via the kubectl proxy. This endpoint, in its current implementation, is
 intended to be used only as a debugging aid, which is part of why this is a
 dirty trick. There is ongoing work to improve the endpoint, and in the future