Resolving merge conflicts with master

2017-11-30 18:53:33 -06:00
parent 53f460ad9e a49d85186a
commit 538dd33ff2
5068 changed files with 25074 additions and 855452 deletions
@@ -21,8 +21,8 @@ When accessing the Kubernetes API for the first time, use the
 Kubernetes command-line tool, `kubectl`.

 To access a cluster, you need to know the location of the cluster and have credentials
-to access it.  Typically, this is automatically set-up when you work through
-a [Getting started guide](/docs/getting-started-guides/),
+to access it. Typically, this is automatically set-up when you work through
+a [Getting started guide](/docs/setup/),
 or someone else setup the cluster and provided you with credentials and a location.

 Check the location and credentials that kubectl knows about with this command:
@@ -32,22 +32,22 @@ $ kubectl config view
 ```

 Many of the [examples](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/) provide an introduction to using
-kubectl.  Complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index).
+kubectl. Complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index).

 ### Directly accessing the REST API

-Kubectl handles locating and authenticating to the apiserver. If you want to directly access the REST API with an http client like
-`curl` or `wget`, or a browser, there are multiple ways you can locate and authenticate against the apiserver:
+kubectl handles locating and authenticating to the API server. If you want to directly access the REST API with an http client like
+`curl` or `wget`, or a browser, there are multiple ways you can locate and authenticate against the API server:

- 1. Run kubectl in proxy mode (recommended).  This method is recommended, since it uses the stored apiserver location abd verifies the identity of the apiserver using a self-signed cert.  No Man-in-the-middle (MITM) attack is possible using this method .
- 1. Alternatively, you can provide the location and credentials directly to the http client. This works with for client code that is confused by proxies.  To protect against man in the middle attacks, you'll need to import a root cert into your browser.
+ 1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method.
+ 1. Alternatively, you can provide the location and credentials directly to the http client. This works with client code that is confused by proxies. To protect against man in the middle attacks, you'll need to import a root cert into your browser.

 Using the Go or Python client libraries provides accessing kubectl in proxy mode.

 #### Using kubectl proxy

-The following command runs kubectl in a mode where it acts as a reverse proxy.  It handles
-locating the apiserver and authenticating.
+The following command runs kubectl in a mode where it acts as a reverse proxy. It handles
+locating the API server and authenticating.

 Run it like this:

@@ -55,7 +55,7 @@ Run it like this:
 $ kubectl proxy --port=8080 &
 ```

-See [kubectl proxy](/docs/user-guide/kubectl/v1.6/#proxy) for more details.
+See [kubectl proxy](/docs/user-guide/kubectl/{{page.version}}/#proxy) for more details.

 Then you can explore the API with curl, wget, or a browser, like so:

@@ -77,7 +77,7 @@ $ curl http://localhost:8080/api/
 #### Without kubectl proxy

 It is possible to avoid using kubectl proxy by passing an authentication token
-directly to the apiserver, like this:
+directly to the API server, like this:

 ``` shell
 $ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
@@ -97,17 +97,17 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 }
 ```

-The above example uses the `--insecure` flag.  This leaves it subject to MITM
-attacks.  When kubectl accesses the cluster it uses a stored root certificate
-and client certificates to access the server.  (These are installed in the
-`~/.kube` directory).  Since cluster certificates are typically self-signed, it
+The above example uses the `--insecure` flag. This leaves it subject to MITM
+attacks. When kubectl accesses the cluster it uses a stored root certificate
+and client certificates to access the server. (These are installed in the
+`~/.kube` directory). Since cluster certificates are typically self-signed, it
 may take special configuration to get your http client to use root
 certificate.

-On some clusters, the apiserver does not require authentication; it may serve
-on localhost, or be protected by a firewall.  There is not a standard
-for this.  [Configuring Access to the API](/docs/admin/accessing-the-api)
-describes how a cluster admin can configure this.  Such approaches may conflict
+On some clusters, the API server does not require authentication; it may serve
+on localhost, or be protected by a firewall. There is not a standard
+for this. [Configuring Access to the API](/docs/admin/accessing-the-api)
+describes how a cluster admin can configure this. Such approaches may conflict
 with future high-availability support.

 ### Programmatic access to the API
@@ -121,7 +121,7 @@ Kubernetes officially supports client libraries for [Go](#go-client) and
 * Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.

 The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go):
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go):

 ```golang
 import (
@@ -136,7 +136,7 @@ import (
   // creates the clientset
   clientset, _:= kubernetes.NewForConfig(config)
   // access the API to list pods
-   pods, _:= clientset.Core().Pods("").List(v1.ListOptions{})
+   pods, _:= clientset.CoreV1().Pods("").List(v1.ListOptions{})
   fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
 ...
 ```
@@ -148,7 +148,7 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex
 To use [Python client](https://github.com/kubernetes-incubator/client-python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-incubator/client-python) for more installation options.

 The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py):
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py):

 ```python
 from kubernetes import client, config
@@ -168,37 +168,46 @@ There are [client libraries](/docs/reference/client-libraries/) for accessing th

 ### Accessing the API from a Pod

-When accessing the API from a pod, locating and authenticating
+When accessing the API from a Pod, locating and authenticating
 to the API server are somewhat different.

-The recommended way to locate the apiserver within the pod is with
-the `kubernetes` DNS name, which resolves to a Service IP which in turn
-will be routed to an apiserver.
+The easiest way to use the Kubernetes API from a Pod is to use
+one of the official [client libraries](/docs/reference/client-libraries/). These
+libraries can automatically discover the API server and authenticate.

-The recommended way to authenticate to the apiserver is with a
-[service account](/docs/user-guide/service-accounts) credential.  By kube-system, a pod
+While running in a Pod, the Kubernetes apiserver is accessible via a Service named
+`kubernetes` in the `default` namespace. Therefore, Pods can use the 
+`kubernetes.default` hostname to query the API server. Official client libraries
+do this automatically.
+
+From within a Pod, the recommended way to authenticate to the API server is with a
+[service account](/docs/user-guide/service-accounts) credential. By default, a Pod
 is associated with a service account, and a credential (token) for that
-service account is placed into the filesystem tree of each container in that pod,
+service account is placed into the filesystem tree of each container in that Pod,
 at `/var/run/secrets/kubernetes.io/serviceaccount/token`.

 If available, a certificate bundle is placed into the filesystem tree of each
 container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
-used to verify the serving certificate of the apiserver.
+used to verify the serving certificate of the API server.

 Finally, the default namespace to be used for namespaced API operations is placed in a file
 at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.

-From within a pod the recommended ways to connect to API are:
+From within a Pod, the recommended ways to connect to the Kubernetes API are:

-  - run a kubectl proxy as one of the containers in the pod, or as a background
-    process within a container.  This proxies the
-    Kubernetes API to the localhost interface of the pod, so that other processes
-    in any container of the pod can access it.  See this [example of using kubectl proxy
-    in a pod](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/staging/kubectl-container/).
-  - use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
-    They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
+  - Use one of the official [client libraries](/docs/reference/client-libraries/)
+    as they handle API host discovery and authentication automatically.
+    For Go client, the `rest.InClusterConfig()` function assists with this.
+    See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go).

-In each case, the credentials of the pod are used to communicate securely with the apiserver.
+  - If you would like to query the API without an official client library, you can run `kubectl proxy`
+    as the [command](/docs/tasks/inject-data-application/define-command-argument-container/)
+    of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate
+    to the API and expose it on the `localhost` interface of the Pod, so that other containers
+    in the Pod can use it directly.
+
+In each case, the service account credentials of the Pod are used to communicate
+securely with the API server.

 {% endcapture %}

@@ -27,12 +27,12 @@ You have several options for connecting to nodes, pods and services from outside
  - Access services through public IPs.
    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
      the cluster.  See the [services](/docs/user-guide/services) and
-      [kubectl expose](/docs/user-guide/kubectl/v1.6/#expose) documentation.
+      [kubectl expose](/docs/user-guide/kubectl/{{page.version}}/#expose) documentation.
    - Depending on your cluster environment, this may just expose the service to your corporate network,
      or it may expose it to the internet.  Think about whether the service being exposed is secure.
      Does it do its own authentication?
    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
-      place a unique label on the pod it and create a new service which selects this label.
+      place a unique label on the pod and create a new service which selects this label.
    - In most cases, it should not be necessary for application developer to directly access
      nodes via their nodeIPs.
  - Access services, nodes, or pods using the Proxy Verb.
@@ -43,11 +43,11 @@ You have several options for connecting to nodes, pods and services from outside
    - Only works for HTTP/HTTPS.
    - Described [here](#manually-constructing-apiserver-proxy-urls).
  - Access from a node or pod in the cluster.
-    - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/user-guide/kubectl/v1.6/#exec).
+    - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/user-guide/kubectl/{{page.version}}/#exec).
      Connect to other nodes, pods, and services from that shell.
-    - Some clusters may allow you to ssh to a node in the cluster.  From there you may be able to
-      access cluster services.  This is a non-standard method, and will work on some clusters but
-      not others.  Browsers and other tools may or may not be installed.  Cluster DNS may not work.
+    - Some clusters may allow you to ssh to a node in the cluster. From there you may be able to
+      access cluster services. This is a non-standard method, and will work on some clusters but
+      not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.

 ### Discovering builtin services

@@ -102,7 +102,7 @@ If you haven't specified a name for your port, you don't have to specify *port_n

 You may be able to put an apiserver proxy URL into the address bar of a browser. However:

-  - Web browsers cannot usually pass tokens, so you may need to use basic (password) auth.  Apiserver can be configured to accept basic auth,
+  - Web browsers cannot usually pass tokens, so you may need to use basic (password) auth. Apiserver can be configured to accept basic auth,
    but your cluster may not be configured to accept basic auth.
  - Some web apps may not work, particularly those with client side javascript that construct URLs in a
    way that is unaware of the proxy path prefix.
@@ -55,7 +55,7 @@ There are two main components to be aware of:
 {% endcapture %}

 {% capture whatsnext %}
-Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
+Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
 {% endcapture %}

 {% include templates/task.md %}
@@ -21,7 +21,7 @@ PersistentVolume.
 "Recycle", and "Delete". For dynamically provisioned `PersistentVolumes`,
 the default reclaim policy is "Delete". This means that a dynamically provisioned
 volume is automatically deleted when a user deletes the corresponding
-`PeristentVolumeClaim`. This automatic behavior might be inappropriate if the volume
+`PersistentVolumeClaim`. This automatic behavior might be inappropriate if the volume
 contains precious data. In that case, it is more appropriate to use the "Retain"
 policy. With the "Retain" policy, if a user deletes a `PersistentVolumeClaim`,
 the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to the
@@ -1,5 +1,5 @@
 ---
-assignees:
+approvers:
 - danwent
 title: Use Cilium for NetworkPolicy
 ---
@@ -72,7 +72,7 @@ There are two main components to be aware of:
 {% endcapture %}

 {% capture whatsnext %}
-Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy with Cilium.  Have fun, and if you have questions, contact us using the [Cilium Slack Channel](https://cilium.herokuapp.com/).
+Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy with Cilium.  Have fun, and if you have questions, contact us using the [Cilium Slack Channel](https://cilium.herokuapp.com/).
 {% endcapture %}

 {% include templates/task.md %}
@@ -15,7 +15,7 @@ running cluster.

 ## Creating and configuring a Cluster

-To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/getting-started-guides/) depending on your environment.
+To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/setup/) depending on your environment.

 ## Upgrading a cluster

@@ -49,12 +49,11 @@ Alternatively, to upgrade your entire cluster to the latest stable release:
 cluster/gce/upgrade.sh release/stable
 ```

-### Upgrading Google Container Engine (GKE) clusters
+### Upgrading Google Kubernetes Engine clusters

-Google Container Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest
-version. It also handles upgrading the operating system and other components that the master runs on.
+Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.

-The node upgrade process is user-initiated and is described in the [GKE documentation.](https://cloud.google.com/container-engine/docs/clusters/upgrade)
+The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).

 ### Upgrading clusters on other platforms

@@ -68,7 +67,7 @@ Different providers, and tools, will manage upgrades differently.  It is recomme
 ## Resizing a cluster

 If your cluster runs short on resources you can easily add more machines to it if your cluster is running in [Node self-registration mode](/docs/admin/node/#self-registration-of-nodes).
-If you're using GCE or GKE it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
+If you're using GCE or Google Kubernetes Engine it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:

 ```shell
 gcloud compute instance-groups managed resize kubernetes-minion-group --size=42 --zone=$ZONE
@@ -80,7 +79,7 @@ In other environments you may need to configure the machine yourself and tell th

 ### Cluster autoscaling

-If you are using GCE or GKE, you can configure your cluster so that it is automatically rescaled based on
+If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
 pod needs.

 As described in [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/), users can reserve how much CPU and memory is allocated to pods.
@@ -91,10 +90,10 @@ to wait until some pods are terminated or a new node is added.
 Cluster autoscaler looks for the pods that cannot be scheduled and checks if adding a new node, similar
 to the other in the cluster, would help. If yes, then it resizes the cluster to accommodate the waiting pods.

-Cluster autoscaler also scales down the cluster if it notices that some node is not needed anymore for
+Cluster autoscaler also scales down the cluster if it notices that one or more nodes are not needed anymore for
 an extended period of time (10min but it may change in the future).

-Cluster autoscaler is configured per instance group (GCE) or node pool (GKE).
+Cluster autoscaler is configured per instance group (GCE) or node pool (Google Kubernetes Engine).

 If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
 To configure cluster autoscaler you have to set three environment variables:
@@ -109,7 +108,7 @@ Example:
 KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
 ```

-On GKE you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
+On Google Kubernetes Engine you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
 (which you want to be autoscaled) by passing flags `--enable-autoscaling` `--min-nodes` and `--max-nodes`
 to the corresponding `gcloud` commands.

@@ -198,4 +197,4 @@ You can use `kubectl convert` command to convert config files between different
 kubectl convert -f pod.yaml --output-version v1
 ```

-For more options, please refer to the usage of [kubectl convert](/docs/user-guide/kubectl/v1.6/#convert) command.
+For more options, please refer to the usage of [kubectl convert](/docs/user-guide/kubectl/{{page.version}}/#convert) command.
@@ -58,7 +58,7 @@ for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment
 thereby making the scheduler resilient to failures. Here is the deployment
 config. Save it as `my-scheduler.yaml`:

-{% include code.html language="yaml" file="my-scheduler.yaml" ghlink="/docs/tutorials/clusters/my-scheduler.yaml" %}
+{% include code.html language="yaml" file="my-scheduler.yaml" ghlink="/docs/tasks/administer-cluster/my-scheduler.yaml" %}

 An important thing to note here is that the name of the scheduler specified as an
 argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `spec.schedulerName` on pods, to determine whether this scheduler is responsible for scheduling a particular pod.
@@ -131,7 +131,7 @@ scheduler in that pod spec. Let's look at three examples.

 - Pod spec without any scheduler name

-  {% include code.html language="yaml" file="pod1.yaml" ghlink="/docs/tutorials/clusters/pod1.yaml" %}
+  {% include code.html language="yaml" file="pod1.yaml" ghlink="/docs/tasks/administer-cluster/pod1.yaml" %}

  When no scheduler name is supplied, the pod is automatically scheduled using the
  default-scheduler.
@@ -144,7 +144,7 @@ kubectl create -f pod1.yaml

 - Pod spec with `default-scheduler`

-  {% include code.html language="yaml" file="pod2.yaml" ghlink="/docs/tutorials/clusters/pod2.yaml" %}
+  {% include code.html language="yaml" file="pod2.yaml" ghlink="/docs/tasks/administer-cluster/pod2.yaml" %}

  A scheduler is specified by supplying the scheduler name as a value to `spec.schedulerName`. In this case, we supply the name of the
  default scheduler which is `default-scheduler`.
@@ -157,7 +157,7 @@ kubectl create -f pod2.yaml

 - Pod spec with `my-scheduler`

-  {% include code.html language="yaml" file="pod3.yaml" ghlink="/docs/tutorials/clusters/pod3.yaml" %}
+  {% include code.html language="yaml" file="pod3.yaml" ghlink="/docs/tasks/administer-cluster/pod3.yaml" %}

  In this case, we specify that this pod should be scheduled using the scheduler that we
  deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler
@@ -40,9 +40,7 @@ Use a single-node etcd cluster only for testing purpose.

 1. Run the following:

-    ``` bash
-     ./etcd --client-listen-urls=http://$PRIVATE_IP:2379 --client-advertise-urls=http://$PRIVATE_IP:2379
-    ```
+        ./etcd --client-listen-urls=http://$PRIVATE_IP:2379 --client-advertise-urls=http://$PRIVATE_IP:2379

 2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`.

@@ -84,17 +82,18 @@ To secure etcd, either set up firewall rules or use the security features provid

 To configure etcd with secure peer communication, specify flags `--peer-key-file=peer.key` and `--peer-cert-file=peer.cert`, and use https as URL schema.

-Similarly, to configure etcd with secure client communication, specify flags `--key-file=peer.key` and `--cert-file=peer.cert`, and use https as URL schema.
+Similarly, to configure etcd with secure client communication, specify flags `--key-file=k8sclient.key` and `--cert-file=k8sclient.cert`, and use https as URL schema.

 ### Limiting access of etcd clusters

 After configuring secure communication, restrict the access of etcd cluster to only the Kubernetes API server. Use TLS authentication to do so.

-For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are trusted by the CA `etcd.ca`. When etcd is configured with `--client-cert-auth` along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by `--trusted-ca-file` flag. Specifying flags `--client-cert-auth=true` and `--trust-ca-file=etcd.ca` will restrict the access to clients with the certificate `k8sclient.cert`.
+For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are trusted by the CA `etcd.ca`. When etcd is configured with `--client-cert-auth` along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by `--trusted-ca-file` flag. Specifying flags `--client-cert-auth=true` and `--trusted-ca-file=etcd.ca` will restrict the access to clients with the certificate `k8sclient.cert`.

 Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert` and `--etcd-keyfile=k8sclient.key`.

 **Note**: etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
+{: .note}

 ## Replacing a failed etcd member

@@ -130,12 +129,11 @@ Though etcd keeps unique member IDs internally, it is recommended to use a uniqu

 4. Start the newly added member on a machine with the IP `10.0.0.4`:

-    ```bash
-    export ETCD_NAME="member4"
-    export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380"
-    export ETCD_INITIAL_CLUSTER_STATE=existing
-    etcd [flags]
-    ```
+        export ETCD_NAME="member4"
+        export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380"
+        export ETCD_INITIAL_CLUSTER_STATE=existing
+        etcd [flags]
+
 5. Do either of the following:

   1. Update its `--etcd-servers` flag to make Kubernetes aware of the configuration changes, then restart the Kubernetes API server.
@@ -186,7 +184,7 @@ Before starting the restore operation, a snapshot file must be present. It can e

 If the access URLs of the restored cluster is changed from the previous cluster, the Kubernetes API server must be reconfigured accordingly. In this case, restart Kubernetes API server with the flag `--etcd-servers=$NEW_ETCD_CLUSTER` instead of the flag `--etcd-servers=$OLD_ETCD_CLUSTER`. Replace `$NEW_ETCD_CLUSTER` and `$OLD_ETCD_CLUSTER` with the respective IP addresses. If a load balancer is used in front of an etcd cluster, you might need to update the load balancer instead.

-If the majority of etcd members have permanently failed, the etcd cluster is considered failed. In this scenario, Kubernetes cannot make any changes to its current state. Although the scheduled pods might  continue to run, no new pods can be scheduled. In such cases, recover the etcd cluster and potentially reconfigure Kubernetes API server to fix the issue.
+If the majority of etcd members have permanently failed, the etcd cluster is considered failed. In this scenario, Kubernetes cannot make any changes to its current state. Although the scheduled pods might continue to run, no new pods can be scheduled. In such cases, recover the etcd cluster and potentially reconfigure Kubernetes API server to fix the issue.

 ## Upgrading and rolling back etcd clusters

@@ -201,7 +199,8 @@ The upgrade procedure described in this document assumes that either:
   etcd cluster. During the time the etcd cluster is shut down, the Kubernetes API Server will be read only.

 **Warning**: Deviations from the assumptions are untested by continuous
-integration, and deviations might create undesirable consequences. Additional information about operating an etcd cluster is available [from the etcd maintainers](https://github.com/coreos/etcd/tree/master/Documentation).
+integration, and deviations might create undesirable consequences. Additional information about operating an etcd cluster is available [from the etcd maintainers](https://github.com/coreos/etcd/tree/master/Documentation). 
+{: .warning}

 ### Background

@@ -213,7 +212,7 @@ Note that we need to migrate both the etcd versions that we are using (from 2.2.
 to at least 3.0.x) as well as the version of the etcd API that Kubernetes talks to. The etcd 3.0.x
 binaries support both the v2 and v3 API.

-This document describes how to do this migration.  If you want to skip the
+This document describes how to do this migration. If you want to skip the
 background and cut right to the procedure, see [Upgrade
 Procedure](#upgrade-procedure).

@@ -228,7 +227,7 @@ There are requirements on how an etcd cluster upgrade can be performed. The prim
 Upgrade only one minor release at a time. For example, we cannot upgrade directly from 2.1.x to 2.3.x.
 Within patch releases it is possible to upgrade and downgrade between arbitrary versions. Starting a cluster for
 any intermediate minor release, waiting until the cluster is healthy, and then
-shutting down the cluster down will perform the migration. For example, to upgrade from version 2.1.x to 2.3.y,
+shutting down the cluster will perform the migration. For example, to upgrade from version 2.1.x to 2.3.y,
 it is enough to start etcd in 2.2.z version, wait until it is healthy, stop it, and then start the
 2.3.y version.

@@ -240,7 +239,7 @@ The etcd team has provided a [custom rollback tool](https://git.k8s.io/kubernete
 but the rollback tool has these limitations:

 * This custom rollback tool is not part of the etcd repo and does not receive the same
-  testing as the rest of etcd.  We are testing it in a couple of end-to-end tests.
+  testing as the rest of etcd. We are testing it in a couple of end-to-end tests.
  There is only community support here.

 * The rollback can be done only from the 3.0.x version (that is using the v3 API) to the
@@ -253,6 +252,7 @@ but the rollback tool has these limitations:
 **Warning**: If the data is not kept in `application/json` format (see [Upgrade
 Procedure](#upgrade-procedure)), you will lose the option to roll back to etcd
 2.2.
+{: .warning}

 The last bullet means that any component or user that has some logic
 depending on resource versions may require restart after etcd rollback. This
@@ -263,13 +263,14 @@ rollback might require restarting all Kubernetes components on all nodes.
 **Note**: At the time of writing, both Kubelet and KubeProxy are using “resource
 version” only for watching (i.e. are not using resource versions for anything
 else). And both are using reflector and/or informer frameworks for watching
-(i.e.  they don’t send watch requests themselves). Both those frameworks if they
+(i.e. they don’t send watch requests themselves). Both those frameworks if they
 can’t renew watch, they will start from “current version” by doing “list + watch
 from the resource version returned by list”. That means that if the apiserver
 will be down for the period of rollback, all of node components should basically
 restart their watches and start from “now” when apiserver is back. And it will
 be back with new resource version. That would mean that restarting node
-components is not needed.  But the assumptions here may not hold forever.
+components is not needed. But the assumptions here may not hold forever.
+{: .note}

 ### Design

@@ -283,7 +284,7 @@ focus on them at all. We focus only on the upgrade/rollback here.
 ### New etcd Docker image

 We decided to completely change the content of the etcd image and the way it works.
-So far, the Docker image for etcd  in version X has contained only the etcd and
+So far, the Docker image for etcd in version X has contained only the etcd and
 etcdctl binaries.

 Going forward, the Docker image for etcd in version X will contain multiple
@@ -336,7 +337,7 @@ script works as follows:
 1. Verify that the detected version is 3.0.x with the v3 API, and the
   desired version is 2.2.1 with the v2 API. We don’t support any other rollback.
 1. If so, we run the custom tool provided by etcd team to do the offline
-   rollback.  This tool reads the v3 formatted data and writes it back to disk
+   rollback. This tool reads the v3 formatted data and writes it back to disk
   in v2 format.
 1. Finally update the contents of the version file.

@@ -349,7 +350,7 @@ Simply modify the command line in the etcd manifest to:

 Starting in Kubernetes version 1.6, this has been done in the manifests for new
 Google Compute Engine clusters. You should also specify these environment
-variables.  In particular,you must keep `STORAGE_MEDIA_TYPE` set to
+variables. In particular, you must keep `STORAGE_MEDIA_TYPE` set to
 `application/json` if you wish to preserve the option to roll back.

 ```
@@ -7,7 +7,7 @@ title: Configure Minimum and Maximum CPU Constraints for a Namespace

 This page shows how to set minimum and maximum values for the CPU resources used by Containers
 and Pods in a namespace. You specify minimum and maximum CPU values in a
-[LimitRange](/docs/api-reference/v1.6/#limitrange-v1-core)
+[LimitRange](/docs/api-reference/{{page.version}}/#limitrange-v1-core)
 object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created
 in the namespace.

@@ -79,6 +79,11 @@ CPU request and limit to the Container.

 * Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.

+**Note:** When creating a `LimitRange` object, you can specify limits on huge-pages
+or GPUs as well. However, when both `default` and `defaultRequest` are specified
+on these resources, the two values must be the same.
+{: .note}
+
 Here's the configuration file for a Pod that has one Container. The Container manifest
 specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
 minimum and maximum CPU constraints imposed by the LimitRange.
@@ -95,7 +95,7 @@ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/cpu-defaults-pod-
 View the Pod specification:

 ```
-kubectl get pod cpu-limit-no-request --output=yaml --namespace=default-cpu-example
+kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example
 ```

 The output shows that the Container's CPU request is set to match its CPU limit.
@@ -122,6 +122,12 @@ Create the Pod:
 kubectl create -f https://k8s.io/docs/tasks/administer-cluster/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
 ```

+View the Pod specification:
+
+```
+kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example
+```
+
 The output shows that the Container's CPU request is set to the value specified in the
 Container's configuration file. The Container's CPU limit is set to 1 cpu, which is the
 default CPU limit for the namespace.
@@ -8,7 +8,7 @@ title: Control CPU Management Policies on the Node
 Kubernetes keeps many aspects of how pods execute on nodes abstracted
 from the user. This is by design.  However, some workloads require
 stronger guarantees in terms of latency and/or performance in order to operate
-acceptably.  The kubelet provides methods to enable more complex workload
+acceptably. The kubelet provides methods to enable more complex workload
 placement policies while keeping the abstraction free from explicit placement
 directives.

@@ -151,7 +151,7 @@ spec:
 ```

 This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
-And the container's resource limit for the CPU resource is an integer greater than 
+And the container's resource limit for the CPU resource is an integer greater than
 or equal to one. The `nginx` container is granted 2 exclusive CPUs.


@@ -186,7 +186,6 @@ spec:
 ```

 This pod runs in the `Guaranteed` QoS class because only `limits` are specified
-and `requests` are set equal to `limits` when not explicitly specified. And the 
-container's resource limit for the CPU resource is an integer greater than or 
-equal to one.The `nginx` container is granted 2 exclusive CPUs.
-
+and `requests` are set equal to `limits` when not explicitly specified. And the
+container's resource limit for the CPU resource is an integer greater than or
+equal to one. The `nginx` container is granted 2 exclusive CPUs.
@@ -17,7 +17,7 @@ can develop their features independantly from the core Kubernetes release cycles

 Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisifed.

-To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvier](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
+To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.

 ## Developing

@@ -114,10 +114,10 @@ apiVersion: v1
 kind: ConfigMap
 metadata:
  name: kube-dns
-    namespace: kube-system
-    data:
-      stubDomains: |
-          {“consul.local”: [“10.150.0.1”]}
+  namespace: kube-system
+data:
+  stubDomains: |
+    {“consul.local”: [“10.150.0.1”]}
 ```

 Note that the cluster administrator did not wish to override the node’s
@@ -136,10 +136,10 @@ apiVersion: v1
 kind: ConfigMap
 metadata:
  name: kube-dns
-    namespace: kube-system
-    data:
-      upstreamNameservers: |
-          [“172.16.0.1”]
+  namespace: kube-system
+data:
+  upstreamNameservers: |
+    [“172.16.0.1”]
 ```

 {% endcapture %}
@@ -28,7 +28,7 @@ The ip-masq-agent configures iptables rules to hide a pod's IP address behind th
 *   **Link Local**
    A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.

-The ip-masq-agent configures iptables rules to handle masquerading node/pod IP addresses when sending traffic to destinations outside the cluster node's IP and the Cluster IP range.  This essentially hides pod IP addresses behind the cluster node's IP address.  In some environments, traffic to "external" addresses must come from a known machine address. For example, in Google Cloud, any traffic to the internet must come from a VM's IP.  When containers are used, as in GKE, the Pod IP will be rejected for egress. To avoid this, we must hide the Pod IP behind the VM's own IP address - generally known as "masquerade". By default, the agent is configured to treat the three private IP ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918) as non-masquerade [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).  These ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The agent will also treat link-local (169.254.0.0/16) as a non-masquerade CIDR by default.  The agent is configured to reload its configuration from the location */etc/config/ip-masq-agent* every 60 seconds, which is also configurable.
+The ip-masq-agent configures iptables rules to handle masquerading node/pod IP addresses when sending traffic to destinations outside the cluster node's IP and the Cluster IP range.  This essentially hides pod IP addresses behind the cluster node's IP address.  In some environments, traffic to "external" addresses must come from a known machine address. For example, in Google Cloud, any traffic to the internet must come from a VM's IP.  When containers are used, as in Google Kubernetes Engine, the Pod IP will be rejected for egress. To avoid this, we must hide the Pod IP behind the VM's own IP address - generally known as "masquerade". By default, the agent is configured to treat the three private IP ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918) as non-masquerade [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).  These ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The agent will also treat link-local (169.254.0.0/16) as a non-masquerade CIDR by default.  The agent is configured to reload its configuration from the location */etc/config/ip-masq-agent* every 60 seconds, which is also configurable.

 ![masq/non-masq example](/images/docs/ip-masq.png)

@@ -50,7 +50,7 @@ MASQUERADE  all  --  anywhere             anywhere             /* ip-masq-agent:

 ```

-By default, in GCE/GKE starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster.  If you are running in another environment, you can add the ip-masq-agent [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to your cluster:
+By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster.  If you are running in another environment, you can add the ip-masq-agent [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to your cluster:

 {% endcapture %}

@@ -18,8 +18,7 @@ The Kube-router Addon comes with a Network Policy Controller that watches Kubern
 {% endcapture %}

 {% capture whatsnext %}
-Once you have installed the Kube-router addon, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
+Once you have installed the Kube-router addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
 {% endcapture %}

 {% include templates/task.md %}
-
@@ -41,6 +41,12 @@ $ export ARCH=amd64 # or: arm, arm64, ppc64le, s390x
 $ curl -sSL https://dl.k8s.io/release/${VERSION}/bin/linux/${ARCH}/kubeadm > /usr/bin/kubeadm
 $ chmod a+rx /usr/bin/kubeadm
 ```
+**Caution:** Upgrading the `kubeadm` package on your system prior to
+upgrading the control plane causes a failed upgrade. Even though
+`kubeadm` is shipped in the Kubernetes repositories, it's important
+to install `kubeadm` manually. The kubeadm team is working on fixing
+this limitation.
+{: .caution}

 Verify that this download of kubeadm works, and has the expected version:

@@ -79,7 +85,7 @@ $ kubeadm upgrade plan
 [upgrade/health] Checking Static Pod manifests exists on disk: All manifests exist on disk
 [upgrade/config] Making sure the configuration is correct:
 [upgrade/config] Reading configuration from the cluster...
-[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
+[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
 [upgrade] Fetching available versions to upgrade to:
 [upgrade/versions] Cluster version: v1.7.1
 [upgrade/versions] kubeadm version: v1.8.0
@@ -140,7 +146,7 @@ $ kubeadm upgrade apply v1.8.0
 [upgrade/health] Checking Static Pod manifests exists on disk: All manifests exist on disk
 [upgrade/config] Making sure the configuration is correct:
 [upgrade/config] Reading configuration from the cluster...
-[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
+[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
 [upgrade/version] You have chosen to upgrade to version "v1.8.0"
 [upgrade/versions] Cluster version: v1.7.1
 [upgrade/versions] kubeadm version: v1.8.0
@@ -202,6 +208,12 @@ $ kubeadm upgrade apply v1.8.0
   find your CNI provider and see if there are additional upgrade steps
   necessary.

+6. Add RBAC permissions for automated certificate rotation. In the future, kubeadm will perform this step automatically:
+
+```shell
+$ kubectl create clusterrolebinding kubeadm:node-autoapprove-certificate-rotation --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeclient --group=system:nodes
+```
+
 ## Upgrading your master and node packages

 For each host (referred to as `$HOST` below) in your cluster, upgrade `kubelet` by executing the following commands:
@@ -240,28 +252,13 @@ Now the new version of the `kubelet` should be running on the host. Verify this
 $ systemctl status kubelet
 ```

-3. Since certificate rotation is enabled by default, you may need to manually approve the new kubelet's CertificateSigningRequest before it can rejoin the cluster:
-
-```shell
-$ kubectl get csr | grep -v Approved
-NAME                                                   AGE       REQUESTOR                 CONDITION
-node-csr-czl32tarZb_XYKnvXf0Q0o4spGUXzJhN2p4_ld7k1iM   2h        system:bootstrap:033abb   Pending
-```
-
-If you see any CSRs listed that aren't already approved, you can manually approve them using kubectl:
-
-```shell
-$ kubectl certificate approve node-csr-czl32tarZb_XYKnvXf0Q0o4spGUXzJhN2p4_ld7k1iM
-certificatesigningrequest "node-csr-czl32tarZb_XYKnvXf0Q0o4spGUXzJhN2p4_ld7k1iM" approved
-```
-
-4. Bring the host back online by marking it schedulable:
+3. Bring the host back online by marking it schedulable:

 ```shell
 $ kubectl uncordon $HOST
 ```

-5. After upgrading `kubelet` on each host in your cluster, verify that all nodes are available again by executing the following (from anywhere, for example, from outside the cluster):
+4. After upgrading `kubelet` on each host in your cluster, verify that all nodes are available again by executing the following (from anywhere, for example, from outside the cluster):

 ```shell
 $ kubectl get nodes
@@ -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 this structure, and thus the config file API,
+is still considered 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](/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.
+
+{% endcapture %}
+
+{% include templates/task.md %}
@@ -7,7 +7,7 @@ title: Limit Storage Consumption
 This example demonstrates an easy way to limit the amount of storage consumed in a namespace.

 The following resources are used in the demonstration: [ResourceQuota](/docs/concepts/policy/resource-quotas/),
-[LimitRange](/docs/tasks/configure-pod-container/limit-range/),
+[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/),
 and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/).

 {% endcapture %}
@@ -7,7 +7,7 @@ title: Configure Minimum and Maximum Memory Constraints for a Namespace

 This page shows how to set minimum and maximum values for memory used by Containers
 running in a namespace. You specify minimum and maximum memory values in a
-[LimitRange](/docs/api-reference/v1.6/#limitrange-v1-core)
+[LimitRange](/docs/api-reference/{{page.version}}/#limitrange-v1-core)
 object. If a Pod does not meet the constraints imposed by the LimitRange,
 it cannot be created in the namespace.

@@ -49,7 +49,7 @@ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/memory-constraint
 View detailed information about the LimitRange:

 ```shell
-kubectl get limitrange cpu-min-max-demo --namespace=constraints-mem-example --output=yaml
+kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example --output=yaml
 ```

 The output shows the minimum and maximum memory constraints as expected. But
@@ -15,7 +15,7 @@ Kubernetes assigns a default memory request under certain conditions that are ex

 {% include task-tutorial-prereqs.md %}

-Each node in your cluster must have at least 300 GiB of memory.
+Each node in your cluster must have at least 2 GiB of memory.

 {% endcapture %}

@@ -20,7 +20,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu

 This example assumes the following:

-1. You have an [existing Kubernetes cluster](/docs/getting-started-guides/).
+1. You have an [existing Kubernetes cluster](/docs/setup/).
 2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.

 ### Step One: Understand the default namespace
@@ -152,7 +152,7 @@ $ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
 ```
 We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
 Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
-If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/v1.6/#run) for more details.
+If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/{{page.version}}/#run) for more details.

 ```shell
 $ kubectl get deployment
@@ -10,7 +10,7 @@ This page shows how to view, work in, and delete namespaces. The page also shows
 {% endcapture %}

 {% capture prerequisites %}
-* Have an [existing Kubernetes cluster](/docs/getting-started-guides/).
+* Have an [existing Kubernetes cluster](/docs/setup/).
 * Have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
 {% endcapture %}

@@ -238,7 +238,7 @@ $ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
 ```
 We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname.
 Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
-If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/v1.7/#run) for more details.
+If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/{{page.version}}/#run) for more details.

 ```shell
 $ kubectl get deployment
@@ -334,7 +334,7 @@ Use cases include:

 ## Understanding namespaces and DNS

-When you create a [Service](/docs/concepts/services-networking/service/), it creates a corresponding [DNS entry](/docs/admin/dns).
+When you create a [Service](/docs/concepts/services-networking/service/), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/).
 This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
 that if a container just uses `<service-name>` it will resolve to the service which
 is local to a namespace.  This is useful for using the same configuration across
@@ -9,7 +9,7 @@ This page shows how to configure quotas for API objects, including
 PersistentVolumeClaims and Services. A quota restricts the number of
 objects, of a particular type, that can be created in a namespace.
 You specify quotas in a
-[ResourceQuota](/docs/api-reference/v1.7/#resourcequota-v1-core)
+[ResourceQuota](/docs/api-reference/{{page.version}}/#resourcequota-v1-core)
 object.

 {% endcapture %}
@@ -53,7 +53,7 @@ kubectl get resourcequota object-quota-demo --namespace=quota-object-example --o

 The output shows that in the quota-object-example namespace, there can be at most
 one PersistentVolumeClaim, at most two Services of type LoadBalancer, and no Services
-of type NodePort. 
+of type NodePort.

 ```yaml
 status:
@@ -67,7 +67,7 @@ status:
    services.nodeports: "0"
 ```

-## Create a PersistentVolumeClaim:
+## Create a PersistentVolumeClaim

 Here is the configuration file for a PersistentVolumeClaim object:

@@ -92,7 +92,7 @@ NAME             STATUS
 pvc-quota-demo   Pending
 ```

-## Attempt to create a second PersistentVolumeClaim:
+## Attempt to create a second PersistentVolumeClaim

 Here is the configuration file for a second PersistentVolumeClaim:

@@ -7,7 +7,7 @@ title: Configure Memory and CPU Quotas for a Namespace

 This page shows how to set quotas for the total amount memory and CPU that
 can be used by all Containers running in a namespace. You specify quotas in a
-[ResourceQuota](/docs/api-reference/v1.7/#resourcequota-v1-core)
+[ResourceQuota](/docs/api-reference/{{page.version}}/#resourcequota-v1-core)
 object.

 {% endcapture %}
@@ -7,7 +7,7 @@ title: Configure a Pod Quota for a Namespace

 This page shows how to set a quota for the total number of Pods that can run
 in a namespace. You specify quotas in a
-[ResourceQuota](/docs/api-reference/v1.7/#resourcequota-v1-core)
+[ResourceQuota](/docs/api-reference/{{page.version}}/#resourcequota-v1-core)
 object.

 {% endcapture %}
@@ -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
@@ -158,7 +159,7 @@ because this ConfigMap configures a Kubernetes system component - the Kubelet.

 The `--append-hash` option appends a short checksum of the ConfigMap contents
 to the name. This is convenient for an edit->push workflow, as it will
-automatically, yet deterministically, generate new names for new ConfigMaps. 
+automatically, yet deterministically, generate new names for new ConfigMaps.

 We use the `-o yaml` output format so that the name, namespace, and uid are all
 reported following creation. We will need these in the next step. We will refer
@@ -167,7 +168,7 @@ to the name as CONFIG_MAP_NAME and the uid as CONFIG_MAP_UID.
 ### Authorize your Node to read the new ConfigMap

 Now that you've created a new ConfigMap, you need to authorize your node to
-read it. First, create a Role for your new ConfigMap with the 
+read it. First, create a Role for your new ConfigMap with the
 following commands:

 ```
@@ -182,7 +183,7 @@ $ kubectl -n kube-system create rolebinding ${CONFIG_MAP_NAME}-reader --role=${C
 ```

 Once the Node Authorizer is updated to do this automatically, you will
-be able to skip this step. 
+be able to skip this step.

 ### Set the Node to use the new configuration

@@ -255,7 +256,7 @@ as NEW_CONFIG_MAP_UID.
 ### Authorize your Node to read the new ConfigMap

 Now that you've created a new ConfigMap, you need to authorize your node to
-read it. First, create a Role for your new ConfigMap with the 
+read it. First, create a Role for your new ConfigMap with the
 following commands:

 ```
@@ -270,7 +271,7 @@ $ kubectl -n kube-system create rolebinding ${NEW_CONFIG_MAP_NAME}-reader --role
 ```

 Once the Node Authorizer is updated to do this automatically, you will
-be able to skip this step. 
+be able to skip this step.

 ### Configure the Node to use the new configuration

@@ -27,19 +27,15 @@ Follow the [containerized installation guide](https://github.com/romana/romana/t
 To apply network policies use one of the following:

 * [Romana network policies](https://github.com/romana/romana/wiki/Romana-policies).
-    * [Example of Romana network policy](https://github.com/romana/core/tree/master/policy).
+    * [Example of Romana network policy](https://github.com/romana/core/blob/master/doc/policy.md).
 * The NetworkPolicy API.

 {% endcapture %}

 {% capture whatsnext %}

-Once your have installed Romana, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
+Once your have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.

 {% endcapture %}

 {% include templates/task.md %}
-
-
-
-
@@ -40,8 +40,8 @@ Successfully running cloud-controller-manager requires some changes to your clus

 Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways:

-* kubelets specifying `--cloud-provider=external` will add a taint `node.cloudprovider.kubernetes.io/uninitialized` with an effect `NoSchedule` during initialization. This marks the node as needing a second initialization from an external controller before it can be scheduled work. Note that in the event that cloud controller manager is not available, new nodes in the cluster will be left unscheduable. The taint is important since the scheduler may require cloud specific information about nodes such as it's region or type (high cpu, gpu, high memory, spot instance, etc).
-* cloud information about nodes in the cluster will no longer be retrieved using local metadata, but instead all API calls to retreive node information will go through cloud controller manager. This may mean you can restrict access to your cloud API on the kubelets for better security. For larger clusters you may want to consider if cloud controller manager will hit rate limits since it is now responsible for almost all API calls to your cloud from within the cluster.
+* kubelets specifying `--cloud-provider=external` will add a taint `node.cloudprovider.kubernetes.io/uninitialized` with an effect `NoSchedule` during initialization. This marks the node as needing a second initialization from an external controller before it can be scheduled work. Note that in the event that cloud controller manager is not available, new nodes in the cluster will be left unschedulable. The taint is important since the scheduler may require cloud specific information about nodes such as their region or type (high cpu, gpu, high memory, spot instance, etc).
+* cloud information about nodes in the cluster will no longer be retrieved using local metadata, but instead all API calls to retrieve node information will go through cloud controller manager. This may mean you can restrict access to your cloud API on the kubelets for better security. For larger clusters you may want to consider if cloud controller manager will hit rate limits since it is now responsible for almost all API calls to your cloud from within the cluster.


 As of v1.8, cloud controller manager can implement:
@@ -78,13 +78,13 @@ Cloud controller manager does not implement any of the volume controllers found

 ### Scalability

-In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retreive node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.
+In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.

 ### Chicken and Egg

-The goal of the cloud controller manager project is to decouple development of cloud features from the core Kubernetes project. Unforunately, many aspects of the Kubernetes project has assumptions that cloud provider features are tightly integrated into the project. As a result, adopting this new architecture can create several situations where a request is being made for information from a cloud provider, but the cloud controller manager may not be able to return that information without the original request being complete.
+The goal of the cloud controller manager project is to decouple development of cloud features from the core Kubernetes project. Unfortunately, many aspects of the Kubernetes project has assumptions that cloud provider features are tightly integrated into the project. As a result, adopting this new architecture can create several situations where a request is being made for information from a cloud provider, but the cloud controller manager may not be able to return that information without the original request being complete.

-A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstraping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialzed in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
+A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.

 As this initiative evolves, changes will be made to address these issues in upcoming releases.

@@ -123,7 +123,7 @@ prevent cross talk, or advanced networking policy.

 By default, there are no restrictions on which nodes may run a pod.  Kubernetes offers a 
 [rich set of policies for controlling placement of pods onto nodes](/docs/concepts/configuration/assign-pod-node/)
-and the [taint based pod placement and eviction](/docs/concepts/configuration/taint-and-toleration)
+and the [taint based pod placement and eviction](/docs/concepts/configuration/taint-and-toleration/)
 that are available to end users. For many clusters use of these policies to separate workloads
 can be a convention that authors adopt or enforce via tooling.

@@ -151,7 +151,7 @@ access to a subset of the keyspace is strongly recommended.

 ### Enable audit logging

-The [audit logger](/docs/admin/audit/) is an alpha feature that records actions taken by the
+The [audit logger](/docs/tasks/debug-application-cluster/audit/) is an alpha feature that records actions taken by the
 API for later analysis in the event of a compromise. It is recommended to enable audit logging 
 and archive the audit file on a secure server.

@@ -6,9 +6,9 @@ title: Static Pods

 **If you are running clustered Kubernetes and are using static pods to run a pod on every node, you should probably be using a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)!**

-*Static pods* are managed directly by kubelet daemon on a specific node, without API server observing it. It does not have associated any replication controller, kubelet daemon itself watches it and restarts it when it crashes. There is no health check though. Static pods are always bound to one kubelet daemon and always run on the same node with it.
+*Static pods* are managed directly by kubelet daemon on a specific node, without the API server observing it. It does not have an associated replication controller, and kubelet daemon itself watches it and restarts it when it crashes. There is no health check. Static pods are always bound to one kubelet daemon and always run on the same node with it.

-Kubelet automatically creates so-called *mirror pod* on Kubernetes API server for each static pod, so the pods are visible there, but they cannot be controlled from the API server.
+Kubelet automatically creates so-called *mirror pod* on the Kubernetes API server for each static pod, so the pods are visible there, but they cannot be controlled from the API server.

 ## Static pod creation

@@ -16,7 +16,7 @@ Static pod can be created in two ways: either by using configuration file(s) or

 ### Configuration files

-The configuration files are just standard pod definition in json or yaml format in specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
+The configuration files are just standard pod definitions in json or yaml format in a specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
 Note that kubelet will ignore files starting with dots when scanning the specified directory.

 For example, this is how to start a simple web server as a static pod:
@@ -29,25 +29,25 @@ For example, this is how to start a simple web server as a static pod:

 2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:

-    ```
-    [root@my-node1 ~] $ mkdir /etc/kubelet.d/
-    [root@my-node1 ~] $ cat <<EOF >/etc/kubelet.d/static-web.yaml
-    apiVersion: v1
-    kind: Pod
-    metadata:
-      name: static-web
-      labels:
-        role: myrole
-    spec:
-      containers:
+```shell
+[root@my-node1 ~] $ mkdir /etc/kubelet.d/
+[root@my-node1 ~] $ cat <<EOF >/etc/kubelet.d/static-web.yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: static-web
+  labels:
+    role: myrole
+spec:
+  containers:
+    - name: web
+      image: nginx
+      ports:
        - name: web
-          image: nginx
-          ports:
-            - name: web
-              containerPort: 80
-              protocol: TCP
-    EOF
-    ```
+          containerPort: 80
+          protocol: TCP
+EOF
+```

 3. Configure your kubelet daemon on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument.
    On Fedora edit `/etc/kubernetes/kubelet` to include this line:
@@ -64,7 +64,7 @@ For example, this is how to start a simple web server as a static pod:
    [root@my-node1 ~] $ systemctl restart kubelet
    ```

-## Pods created via HTTP
+### Pods created via HTTP

 Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--pod-manifest-path=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).

@@ -18,19 +18,15 @@ Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-

 {% capture steps %}

-## Installing Weave Net addon
+## Install the Weave Net addon

 Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kube-addon/) guide.

-The Weave Net Addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
-
-{% endcapture %}
-
-{% capture example %}
+The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.

 ## Namespace isolation example

-1. Create a namespace with `DefaultDeny`.
+1. Create a Namespace with `DefaultDeny`.

 ```yaml
 kind: Namespace
@@ -46,7 +42,7 @@ metadata:
      }
 ```

-2. Create 2 pods inside this namespace.
+2. Create 2 Pods inside this Namespace.

 ```yaml
 kind: Pod
@@ -74,15 +70,15 @@ spec:
    image: nginx
 ```

-3. Get the IP addresses of the pods.
+3. Get the IP addresses of the Pods.

 ```shell
 kubectl get po -n myns -o wide
 ```
-**Note:** If your cURL requests to pods are forbidden, try making cURL requests to other pods from within a pod.
+**Note:** If your cURL requests to Pods are forbidden, try making cURL requests to other Pods from within a Pod.
 {: .note}

-4. Create a Kubernetes NetworkPolicy that allows pods within the same namespace to connect with each other.
+4. Create a Kubernetes NetworkPolicy that allows Pods within the same Namespace to connect with each other.

 ```yaml
 apiVersion: networking.k8s.io/v1
@@ -103,12 +99,84 @@ spec:
 **Caution:** After applying the network policy, pods outside the namespace you specify may be unable to connect with pods inside the namespace.
 {. :caution}

-{% endcapture %}
+## Test the installation

+1. Verify that the weave works.
+
+Enter the following command:
+
+```shell
+kubectl get po -n kube-system -o wide
+```
+
+The output is similar to this:
+
+```
+NAME                                    READY     STATUS    RESTARTS   AGE       IP              NODE
+weave-net-1t1qg                         2/2       Running   0          9d        192.168.2.10    workndoe3
+weave-net-231d7                         2/2       Running   1          7d        10.2.0.17       worknodegpu
+weave-net-7nmwt                         2/2       Running   3          9d        192.168.2.131   masternode
+weave-net-pmw8w                         2/2       Running   0          9d        192.168.2.216   worknode2
+```
+
+Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.)
+
+2. Create a Network Policy. 
+
+For more information, see "[Declare Network Policy](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/)".
+
+3. Check the logs.
+
+After creating a NetworkPolicy, check the logs:
+
+```shell
+kubectl logs -f  weave-net-pmw8w weave-npc  -n kube-system
+```
+
+Log output looks like this:
+
+```log
+INFO: 2017/08/14 02:22:32.511992 EVENT AddNetworkPolicy {"metadata":{"name":"aaa","namespace":"myns","selfLink":"/apis/extensions/v1beta1/namespaces/myns/networkpolicies/aaa","uid":"67b229fd-8097-11e7-92f3-005056a3bc75","resourceVersion":"1507955","generation":1,"creationTimestamp":"2017-08-14T02:22:22Z"},"spec":{"podSelector":{"matchExpressions":[{"key":"inns","operator":"In","values":["yes"]}]},"ingress":[{"from":[{"podSelector":{"matchExpressions":[{"key":"inns","operator":"In","values":["yes"]}]}}]}]}}
+INFO: 2017/08/14 02:22:32.512103 creating ipset: &npc.selectorSpec{key:"inns in (yes)", selector:labels.internalSelector{labels.Requirement{key:"inns", operator:"in", strValues:[]string{"yes"}}}, ipsetType:"hash:ip", ipsetName:"weave-[T]a=ETzaKA{o*muaFe:2IX(t"}
+INFO: 2017/08/14 02:22:32.538003 adding rule: [-m set --match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t src -m set --match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t dst -j ACCEPT]
+^[^C
+```
+
+4. Finally, check the logs for iptables.
+
+```shell
+iptables -L
+```
+
+The output is similar to this:
+
+```iptables
+Chain WEAVE-NPC (1 references)
+target     prot opt source               destination         
+ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
+ACCEPT     all  --  anywhere             base-address.mcast.net/4 
+WEAVE-NPC-DEFAULT  all  --  anywhere             anywhere             state NEW
+WEAVE-NPC-INGRESS  all  --  anywhere             anywhere             state NEW
+ACCEPT     all  --  anywhere             anywhere             ! match-set weave-local-pods dst
+
+Chain WEAVE-NPC-DEFAULT (1 references)
+target     prot opt source               destination         
+ACCEPT     all  --  anywhere             anywhere             match-set weave-iuZcey(5DeXbzgRFs8Szo]+@p dst
+ACCEPT     all  --  anywhere             anywhere             match-set weave-k?Z;25^M}|1s7P3|H9i;*;MhG dst
+ACCEPT     all  --  anywhere             anywhere             match-set weave-4vtqMI+kx/2]jD%_c0S%thO%V dst
+
+Chain WEAVE-NPC-INGRESS (1 references)
+target     prot opt source               destination         
+ACCEPT     all  --  anywhere             anywhere             match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t src match-set weave-[T]a=ETzaKA{o*muaFe:2IX(t dst
+```
+
+The match-set labels have been applied to iptables, so the weave is working correctly.
+
+{% endcapture %}

 {% capture whatsnext %}

-Once you have installed the Weave Net addon, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
+Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.

 {% endcapture %}