kubernetes · steveperry-53 · Sep 27, 2017 · Sep 27, 2017 · Sep 27, 2017 · Sep 27, 2017
diff --git a/_data/tasks.yml b/_data/tasks.yml
@@ -110,6 +110,7 @@ toc:
 - title: TLS
   section:
   - docs/tasks/tls/managing-tls-in-a-cluster.md
+  - docs/tasks/tls/certificate-rotation.md
 
 - title: Administer a Cluster
   section:

diff --git a/docs/api-reference/v1.5/index.html b/docs/api-reference/v1.5/index.html
@@ -74,7 +74,7 @@ <h4 id="additional-operations">Additional Operations</h4>
 <p><strong>Read / Write Status</strong>: Read or Update the Status for a resource object.  The Status can only changed through these update operations.</p>
 <hr>
 <h1 id="-strong-workloads-strong-"><strong>WORKLOADS</strong></h1>
-<p>Worloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1">Containers</a> are created
+<p>Workloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1">Containers</a> are created
 by Controllers through <a href="#pod-v1">Pods</a>.  Pods run Containers and provide environmental dependencies such as shared or
 persistent storage <a href="#volume-v1">Volumes</a> and <a href="#configmap-v1">Configuration</a> or <a href="#secret-v1">Secret</a> data injected into the
 container.</p>

diff --git a/docs/api-reference/v1.6/index.html b/docs/api-reference/v1.6/index.html
@@ -74,7 +74,7 @@ <h4 id="additional-operations">Additional Operations</h4>
 <p><strong>Read / Write Status</strong>: Read or Update the Status for a resource object.  The Status can only changed through these update operations.</p>
 <hr>
 <h1 id="-strong-workloads-strong-"><strong>WORKLOADS</strong></h1>
-<p>Worloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
+<p>Workloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
 by Controllers through <a href="#pod-v1-core">Pods</a>.  Pods run Containers and provide environmental dependencies such as shared or
 persistent storage <a href="#volume-v1-core">Volumes</a> and <a href="#configmap-v1-core">Configuration</a> or <a href="#secret-v1-core">Secret</a> data injected into the
 container.</p>

diff --git a/docs/api-reference/v1.7/index.html b/docs/api-reference/v1.7/index.html
@@ -74,7 +74,7 @@ <h4 id="additional-operations">Additional Operations</h4>
 <p><strong>Read / Write Status</strong>: Read or Update the Status for a resource object.  The Status can only changed through these update operations.</p>
 <hr>
 <h1 id="-strong-workloads-strong-"><strong>WORKLOADS</strong></h1>
-<p>Worloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
+<p>Workloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
 by Controllers through <a href="#pod-v1-core">Pods</a>.  Pods run Containers and provide environmental dependencies such as shared or
 persistent storage <a href="#volume-v1-core">Volumes</a> and <a href="#configmap-v1-core">Configuration</a> or <a href="#secret-v1-core">Secret</a> data injected into the
 container.</p>

diff --git a/docs/concepts/cluster-administration/manage-deployment.md b/docs/concepts/cluster-administration/manage-deployment.md
@@ -82,7 +82,7 @@ Because `kubectl` outputs resource names in the same syntax it accepts, it's eas
 ```shell
 $ kubectl get $(kubectl create -f docs/user-guide/nginx/ -o name | grep service)
 NAME           CLUSTER-IP   EXTERNAL-IP   PORT(S)      AGE
-my-nginx-svc   10.0.0.208                 80/TCP       0s
+my-nginx-svc   10.0.0.208   <pending>     80/TCP       0s
 ```
 
 With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format

diff --git a/docs/resources-reference/v1.5/index.html b/docs/resources-reference/v1.5/index.html
@@ -15,7 +15,7 @@
 <div id="wrapper">
 <div id="code-tabs-wrapper" class="code-tabs"><ul class="code-tab-list"><li class="code-tab" id="example">example</li></ul></div>
 <div id="page-content-wrapper" class="body-content container-fluid"><h1 id="-strong-workloads-strong-"><strong>WORKLOADS</strong></h1>
-<p>Worloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1">Containers</a> are created
+<p>Workloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1">Containers</a> are created
 by Controllers through <a href="#pod-v1">Pods</a>.  Pods run Containers and provide environmental dependencies such as shared or
 persistent storage <a href="#volume-v1">Volumes</a> and <a href="#configmap-v1">Configuration</a> or <a href="#secret-v1">Secret</a> data injected into the
 container.</p>

diff --git a/docs/resources-reference/v1.6/index.html b/docs/resources-reference/v1.6/index.html
@@ -15,7 +15,7 @@
 <div id="wrapper">
 <div id="code-tabs-wrapper" class="code-tabs"><ul class="code-tab-list"><li class="code-tab" id="example">example</li></ul></div>
 <div id="page-content-wrapper" class="body-content container-fluid"><h1 id="-strong-workloads-strong-"><strong>WORKLOADS</strong></h1>
-<p>Worloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
+<p>Workloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
 by Controllers through <a href="#pod-v1-core">Pods</a>.  Pods run Containers and provide environmental dependencies such as shared or
 persistent storage <a href="#volume-v1-core">Volumes</a> and <a href="#configmap-v1-core">Configuration</a> or <a href="#secret-v1-core">Secret</a> data injected into the
 container.</p>

diff --git a/docs/resources-reference/v1.7/index.html b/docs/resources-reference/v1.7/index.html
@@ -15,7 +15,7 @@
 <div id="wrapper">
 <div id="code-tabs-wrapper" class="code-tabs"><ul class="code-tab-list"><li class="code-tab" id="example">example</li></ul></div>
 <div id="page-content-wrapper" class="body-content container-fluid"><h1 id="-strong-workloads-strong-"><strong>WORKLOADS</strong></h1>
-<p>Worloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
+<p>Workloads resources are responsible for managing and running your containers on the cluster.  <a href="#container-v1-core">Containers</a> are created
 by Controllers through <a href="#pod-v1-core">Pods</a>.  Pods run Containers and provide environmental dependencies such as shared or
 persistent storage <a href="#volume-v1-core">Volumes</a> and <a href="#configmap-v1-core">Configuration</a> or <a href="#secret-v1-core">Secret</a> data injected into the
 container.</p>

diff --git a/docs/setup/pick-right-solution.md b/docs/setup/pick-right-solution.md
@@ -17,7 +17,7 @@ When you are ready to scale up to more machines and higher availability, a [host
 [Turnkey cloud solutions](#turnkey-cloud-solutions) require only a few commands to create
 and cover a wide range of cloud providers.
 
-If you already have a way to configure hosting resources, use [kubeadm](/docs/getting-started-guides/kubeadm/) to easily bring up a cluster with a single command per machine.
+If you already have a way to configure hosting resources, use [kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster with a single command per machine.
 
 [Custom solutions](#custom-solutions) vary from step-by-step instructions to general advice for setting up
 a Kubernetes cluster from scratch.
@@ -88,7 +88,7 @@ If you are interested in supporting Kubernetes on a new platform, see
 ## Universal
 
 If you already have a way to configure hosting resources, use
-[kubeadm](/docs/getting-started-guides/kubeadm/) to easily bring up a cluster
+[kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster
 with a single command per machine.
 
 ## Cloud

diff --git a/docs/tasks/tls/certificate-rotation.md b/docs/tasks/tls/certificate-rotation.md
@@ -0,0 +1,81 @@
+---
+approvers:
+- jcbsmpsn
+- mikedanese
+title: Certificate Rotation
+---
+
+{% capture overview %}
+This page shows how to enable and configure certificate rotation for the kubelet.
+{% endcapture %}
+
+{% capture prerequisites %}
+
+* Kubernetes version 1.8.0 or later is required
+
+* Kubelet certificate rotation is beta in 1.8.0 which means it may change without notice.
+
+{% endcapture %}
+
+{% capture steps %}
+
+## Overview
+
+The kubelet uses certificates for authenticating to the Kubernetes API.  By
+default, these certificates are issued with one year expiration so that they do
+not need to be renewed too frequently.
+
+Kubernetes 1.8 contains [kubelet certificate
+rotation](/docs/tasks/administer-cluster/certificate-rotation/), a beta feature
+that will automatically generate a new key and request a new certificate from
+the Kubernetes API as the current certificate approaches expiration. Once the
+new certificate is available, it will be used for authenticating connections to
+the Kubernetes API.
+
+## Enabling client certificate rotation
+
+The `kubelet` process accepts an argument `--rotate-certificates` that controls
+if the kubelet will automatically request a new certificate as the expiration of
+the certificate currently in use approaches.  Since certificate rotation is a
+beta feature, the feature flag must also be enabled with
+`--feature-gates=RotateKubeletClientCertificate=true`.
+
+
+The `kube-controller-manager` process accepts an argument
+`--experimental-cluster-signing-duration` that controls how long certificates
+will be issued for.
+
+## Understanding the certificate rotation configuration
+
+When a kubelet starts up, if it is configured to bootstrap (using the
+`--bootstrap-kubeconfig` flag), it will use its initial certificate to connect
+to the Kubernetes API and issue a certificate signing request. You can view the
+status of certificate signing requests using:
+
+```sh
+kubectl get csr
+```
+
+Initially a certificate signing request from the kubelet on a node will have a
+status of `Pending`. If the certificate signing requests meets specific
+criteria, it will be auto approved by the controller manager, then it will have
+a status of `Approved`. Next, the controller manager will sign a certificate,
+issued for the duration specified by the
+`--experimental-cluster-signing-duration` parameter, and the signed certificate
+will be attached to the certificate signing requests.
+
+The kubelet will retrieve the signed certificate from the Kubernetes API and
+write that to disk, in the location specified by `--cert-dir`. Then the kubelet
+will use the new certificate to connect to the Kubernetes API.
+
+As the expiration of the signed certificate approaches, the kubelet will
+automatically issue a new certificate signing request, using the Kubernetes
+API. Again, the controller manager will automatically approve the certificate
+request and attach a signed certificate to the certificate signing request. The
+kubelet will retrieve the new signed certificate from the Kubernetes API and
+write that to disk. Then it will update the connections it has to the
+Kubernetes API to reconnect using the new certificate.
+
+{% endcapture %}
+
+{% include templates/task.md %}