merge master to 1.10, with fixes (#7682)

2018-03-08 14:03:55 -05:00
parent bb8c59a640
commit 44b51d6056
548 changed files with 11634 additions and 318622 deletions
@@ -135,10 +135,10 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex

 #### Python client

-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.
+To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-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 apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples/example1.py).

 #### Other languages

@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bprashanth
 - davidopp
 title: Configure Your Cloud Provider's Firewalls
@@ -105,6 +105,12 @@ which should produce output like this:

 The IP address is listed next to `LoadBalancer Ingress`.

+**Note**: If you are running your service on Minikube, you can find the assigned IP address and port with:
+{: .note}
+```bash
+minikube service example-service --url
+```
+
 ## Preserving the client source IP

 Due to the implementation of this feature, the source IP seen in the target
@@ -12,11 +12,16 @@ spec:
    targetPort: 80
  type: LoadBalancer
 ---
-apiVersion: apps/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: frontend
 spec:
+  selector:
+    matchLabels:
+      app: hello
+      tier: frontend
+      track: stable
  replicas: 1
  template:
    metadata:
@@ -1,8 +1,13 @@
-apiVersion: apps/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: hello
 spec:
+  selector:
+    matchLabels:
+      app: hello
+      tier: backend
+      track: stable
  replicas: 7
  template:
    metadata:
@@ -71,6 +71,8 @@ provides load balancing for an application that has two running instances.
        Type:                   NodePort
        IP:                     10.32.0.16
        Port:                   <unset> 8080/TCP
+        TargetPort:             8080/TCP
+        NodePort:               <unset> 31496/TCP
        Endpoints:              10.200.1.4:8080,10.200.2.5:8080
        Session Affinity:       None
        Events:                 <none>
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bryk
 - mikedanese
 - rf232
@@ -156,7 +156,7 @@ Services and discovery view shows Kubernetes resources that allow for exposing s
 Storage view shows Persistent Volume Claim resources which are used by applications for storing data.

 #### Config
-Config view show all Kubernetes resources that are used for live configuration of applications running in clusters. This is now Config Maps and Secrets. The view allows for editing and managing config objects and displays secrets hidden by default.
+Config view shows all Kubernetes resources that are used for live configuration of applications running in clusters. This is now Config Maps and Secrets. The view allows for editing and managing config objects and displays secrets hidden by default.

 ![Secret detail view](/images/docs/ui-dashboard-secret-detail.png)

@@ -1,6 +1,6 @@
 ---
 title: Configure the aggregation layer
-approvers:
+reviewers:
 - lavalamp
 - cheftako
 - chenopis
@@ -1,6 +1,6 @@
 ---
 title: Extend the Kubernetes API with CustomResourceDefinitions
-approvers:
+reviewers:
 - deads2k
 - enisoc
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - enisoc
 - IanLewis
 title: Extend the Kubernetes API with ThirdPartyResources
@@ -1,6 +1,6 @@
 ---
 title: Migrate a ThirdPartyResource to CustomResourceDefinition
-approvers:
+reviewers:
 - enisoc
 - deads2k
 ---
@@ -1,6 +1,6 @@
 ---
 title: Setup an extension API server
-approvers:
+reviewers:
 - lavalamp
 - cheftako
 - chenopis
@@ -145,10 +145,10 @@ If the application is deployed as a Pod in the cluster, please refer to the [nex

 #### Python client

-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.
+To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-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 API server. 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-client/python/tree/master/examples/example1.py):

 ```python
 from kubernetes import client, config
@@ -69,7 +69,7 @@ This shows the proxy-verb URL for accessing each service.
 For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
 at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example:
 `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
-(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
+(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)

 #### Manually constructing apiserver proxy URLs

@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - caseydavenport
 title: Use Calico for NetworkPolicy
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - danwent
 title: Use Cilium for NetworkPolicy
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - lavalamp
 - thockin
 title: Cluster Management
@@ -23,6 +23,11 @@ The current state of cluster upgrades is provider dependent, and some releases m

 * [Upgrading to 1.6](/docs/admin/upgrade-1-6)

+### Upgrading an Azure Kubernetes Service (AKS) cluster
+
+Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
+currently user-initiated and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster).
+
 ### Upgrading Google Compute Engine clusters

 Google Compute Engine Open Source (GCE-OSS) support master upgrades by deleting and
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - davidopp
 - madhusudancs
 title: Configure Multiple Schedulers
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - mml
 - wojtek-t
 title: Operating etcd clusters for Kubernetes
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - johnbelamaric
 title: Using CoreDNS for Service Discovery
 min-kubernetes-server-version: v1.9
@@ -1,6 +1,6 @@
 ---
 title: Control CPU Management Policies on the Node
-approvers:
+reviewers:
 - sjenning
 - ConnorDoyle
 - balajismaniam
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - caseydavenport
 - danwinship
 title: Declare Network Policy
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - luxas
 - thockin
 - wlan0
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bowei
 - zihongz
 title: Customizing DNS Service
@@ -7,7 +7,7 @@ title: Customizing DNS Service

 {% capture overview %}
 This page provides hints on configuring DNS Pod and guidance on customizing the
-DNS resolution process and diagnosing DNS problems.
+DNS resolution process.
 {% endcapture %}

 {% capture prerequisites %}
@@ -183,182 +183,8 @@ data:
    ["172.16.0.1"]
 ```

-## Debugging DNS resolution
-
-### Create a simple Pod to use as a test environment
-
-Create a file named busybox.yaml with the following contents:
-
-{% include code.html language="yaml" file="busybox.yaml" ghlink="/docs/tasks/administer-cluster/busybox.yaml" %}
-
-Then create a pod using this file and verify its status:
-
-```shell
-$ kubectl create -f busybox.yaml
-pod "busybox" created
-
-$ kubectl get pods busybox
-NAME      READY     STATUS    RESTARTS   AGE
-busybox   1/1       Running   0          <some-time>
-```
-
-Once that pod is running, you can exec `nslookup` in that environment.
-If you see something like the following, DNS is working correctly.
-
-```shell
-$ kubectl exec -ti busybox -- nslookup kubernetes.default
-Server:    10.0.0.10
-Address 1: 10.0.0.10
-
-Name:      kubernetes.default
-Address 1: 10.0.0.1
-```
-
-If the `nslookup` command fails, check the following:
-
-### Check the local DNS configuration first
-
-Take a look inside the resolv.conf file.
-(See [Inheriting DNS from the node](#inheriting-dns-from-the-node) and
-[Known issues](#known-issues) below for more information)
-
-```shell
-$ kubectl exec busybox cat /etc/resolv.conf
-```
-
-Verify that the search path and name server are set up like the following
-(note that search path may vary for different cloud providers):
-
-```
-search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
-nameserver 10.0.0.10
-options ndots:5
-```
-
-Errors such as the following indicate a problem with the kube-dns add-on or
-associated Services:
-
-```
-$ kubectl exec -ti busybox -- nslookup kubernetes.default
-Server:    10.0.0.10
-Address 1: 10.0.0.10
-
-nslookup: can't resolve 'kubernetes.default'
-```
-
-or
-
-```
-$ kubectl exec -ti busybox -- nslookup kubernetes.default
-Server:    10.0.0.10
-Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
-
-nslookup: can't resolve 'kubernetes.default'
-```
-
-### Check if the DNS pod is running
-
-Use the `kubectl get pods` command to verify that the DNS pod is running.
-
-```shell
-$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
-NAME                    READY     STATUS    RESTARTS   AGE
-...
-kube-dns-v19-ezo1y      3/3       Running   0           1h
-...
-```
-
-If you see that no pod is running or that the pod has failed/completed, the DNS
-add-on may not be deployed by default in your current environment and you will
-have to deploy it manually.
-
-### Check for Errors in the DNS pod
-
-Use `kubectl logs` command to see logs for the DNS daemons.
-
-```shell
-$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
-$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
-$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
-```
-
-See if there is any suspicious log. Letter '`W`', '`E`', '`F`' at the beginning
-represent Warning, Error and Failure. Please search for entries that have these
-as the logging level and use
-[kubernetes issues](https://github.com/kubernetes/kubernetes/issues)
-to report unexpected errors.
-
-### Is DNS service up?
-
-Verify that the DNS service is up by using the `kubectl get service` command.
-
-```shell
-$ kubectl get svc --namespace=kube-system
-NAME          CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
-...
-kube-dns      10.0.0.10      <none>        53/UDP,53/TCP        1h
-...
-```
-
-If you have created the service or in the case it should be created by default
-but it does not appear, see 
-[debugging services](/docs/tasks/debug-application-cluster/debug-service/) for
-more information.
-
-### Are DNS endpoints exposed?
-
-You can verify that DNS endpoints are exposed by using the `kubectl get endpoints`
-command.
-
-```shell
-$ kubectl get ep kube-dns --namespace=kube-system
-NAME       ENDPOINTS                       AGE
-kube-dns   10.180.3.17:53,10.180.3.17:53    1h
-```
-
-If you do not see the endpoints, see endpoints section in the
-[debugging services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
-
-For additional Kubernetes DNS examples, see the
-[cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
-in the Kubernetes GitHub repository.
-
-## Known issues
-
-Kubernetes installs do not configure the nodes' resolv.conf files to use the
-cluster DNS by default, because that process is inherently distro-specific.
-This should probably be implemented eventually.
-
-Linux's libc is impossibly stuck ([see this bug from
-2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
-3 DNS `nameserver` records and 6 DNS `search` records.  Kubernetes needs to
-consume 1 `nameserver` record and 3 `search` records.  This means that if a
-local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
-some of those settings will be lost.  As a partial workaround, the node can run
-`dnsmasq` which will provide more `nameserver` entries, but not more `search`
-entries.  You can also use kubelet's `--resolv-conf` flag.
-
-If you are using Alpine version 3.3 or earlier as your base image, DNS may not
-work properly owing to a known issue with Alpine.
-Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
-for more information.
-
-## Kubernetes Federation (Multiple Zone support)
-
-Release 1.3 introduced Cluster Federation support for multi-site Kubernetes
-installations. This required some minor (backward-compatible) changes to the
-way the Kubernetes cluster DNS server processes DNS queries, to facilitate
-the lookup of federated services (which span multiple Kubernetes clusters).
-See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/)
-for more details on Cluster Federation and multi-site support.
-
-## References
-
- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)
-
 ## What's next
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
+- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).

 {% endcapture %}

@@ -0,0 +1,197 @@
+---
+approvers:
+- bowei
+- zihongz
+title:  Debugging DNS Resolution
+---
+
+{% capture overview %}
+This page provides hints on diagnosing DNS problems.
+{% endcapture %}
+
+{% capture prerequisites %}
+* {% include task-tutorial-prereqs.md %}
+* Kubernetes version 1.6 and above.
+* The cluster must be configured to use the `kube-dns` addon.
+{% endcapture %}
+
+{% capture steps %}
+
+### Create a simple Pod to use as a test environment
+
+Create a file named busybox.yaml with the following contents:
+
+{% include code.html language="yaml" file="busybox.yaml" ghlink="/docs/tasks/administer-cluster/busybox.yaml" %}
+
+Then create a pod using this file and verify its status:
+
+```shell
+$ kubectl create -f busybox.yaml
+pod "busybox" created
+
+$ kubectl get pods busybox
+NAME      READY     STATUS    RESTARTS   AGE
+busybox   1/1       Running   0          <some-time>
+```
+
+Once that pod is running, you can exec `nslookup` in that environment.
+If you see something like the following, DNS is working correctly.
+
+```shell
+$ kubectl exec -ti busybox -- nslookup kubernetes.default
+Server:    10.0.0.10
+Address 1: 10.0.0.10
+
+Name:      kubernetes.default
+Address 1: 10.0.0.1
+```
+
+If the `nslookup` command fails, check the following:
+
+### Check the local DNS configuration first
+
+Take a look inside the resolv.conf file.
+(See [Inheriting DNS from the node](#inheriting-dns-from-the-node) and
+[Known issues](#known-issues) below for more information)
+
+```shell
+$ kubectl exec busybox cat /etc/resolv.conf
+```
+
+Verify that the search path and name server are set up like the following
+(note that search path may vary for different cloud providers):
+
+```
+search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
+nameserver 10.0.0.10
+options ndots:5
+```
+
+Errors such as the following indicate a problem with the kube-dns add-on or
+associated Services:
+
+```
+$ kubectl exec -ti busybox -- nslookup kubernetes.default
+Server:    10.0.0.10
+Address 1: 10.0.0.10
+
+nslookup: can't resolve 'kubernetes.default'
+```
+
+or
+
+```
+$ kubectl exec -ti busybox -- nslookup kubernetes.default
+Server:    10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+nslookup: can't resolve 'kubernetes.default'
+```
+
+### Check if the DNS pod is running
+
+Use the `kubectl get pods` command to verify that the DNS pod is running.
+
+```shell
+$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
+NAME                    READY     STATUS    RESTARTS   AGE
+...
+kube-dns-v19-ezo1y      3/3       Running   0           1h
+...
+```
+
+If you see that no pod is running or that the pod has failed/completed, the DNS
+add-on may not be deployed by default in your current environment and you will
+have to deploy it manually.
+
+### Check for Errors in the DNS pod
+
+Use `kubectl logs` command to see logs for the DNS daemons.
+
+```shell
+$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
+$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
+$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
+```
+
+See if there is any suspicious log. Letter '`W`', '`E`', '`F`' at the beginning
+represent Warning, Error and Failure. Please search for entries that have these
+as the logging level and use
+[kubernetes issues](https://github.com/kubernetes/kubernetes/issues)
+to report unexpected errors.
+
+### Is DNS service up?
+
+Verify that the DNS service is up by using the `kubectl get service` command.
+
+```shell
+$ kubectl get svc --namespace=kube-system
+NAME          CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
+...
+kube-dns      10.0.0.10      <none>        53/UDP,53/TCP        1h
+...
+```
+
+If you have created the service or in the case it should be created by default
+but it does not appear, see 
+[debugging services](/docs/tasks/debug-application-cluster/debug-service/) for
+more information.
+
+### Are DNS endpoints exposed?
+
+You can verify that DNS endpoints are exposed by using the `kubectl get endpoints`
+command.
+
+```shell
+$ kubectl get ep kube-dns --namespace=kube-system
+NAME       ENDPOINTS                       AGE
+kube-dns   10.180.3.17:53,10.180.3.17:53    1h
+```
+
+If you do not see the endpoints, see endpoints section in the
+[debugging services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
+
+For additional Kubernetes DNS examples, see the
+[cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
+in the Kubernetes GitHub repository.
+
+## Known issues
+
+Kubernetes installs do not configure the nodes' resolv.conf files to use the
+cluster DNS by default, because that process is inherently distro-specific.
+This should probably be implemented eventually.
+
+Linux's libc is impossibly stuck ([see this bug from
+2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
+3 DNS `nameserver` records and 6 DNS `search` records.  Kubernetes needs to
+consume 1 `nameserver` record and 3 `search` records.  This means that if a
+local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
+some of those settings will be lost.  As a partial workaround, the node can run
+`dnsmasq` which will provide more `nameserver` entries, but not more `search`
+entries.  You can also use kubelet's `--resolv-conf` flag.
+
+If you are using Alpine version 3.3 or earlier as your base image, DNS may not
+work properly owing to a known issue with Alpine.
+Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
+for more information.
+
+## Kubernetes Federation (Multiple Zone support)
+
+Release 1.3 introduced Cluster Federation support for multi-site Kubernetes
+installations. This required some minor (backward-compatible) changes to the
+way the Kubernetes cluster DNS server processes DNS queries, to facilitate
+the lookup of federated services (which span multiple Kubernetes clusters).
+See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/)
+for more details on Cluster Federation and multi-site support.
+
+## References
+
+- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
+- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)
+
+## What's next
+- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
+
+{% endcapture %}
+
+{% include templates/task.md %}
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - smarterclayton
 title: Encrypting Secret Data at Rest
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - davidopp
 - filipg
 - piosz
@@ -19,6 +19,12 @@ and becomes pending (for example when the cluster is highly utilized and either
 vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).

 ## Rescheduler: guaranteed scheduling of critical add-ons
+**Rescheduler is deprecated as of Kubernetes 1.10 and will be removed in version 1.11 in
+accordance with the [deprecation policy](/docs/reference/deprecation-policy) for beta features.**
+
+**To avoid eviction of critical pods, you must
+[enable priorities in scheduler](/docs/concepts/configuration/pod-priority-preemption/)
+before upgrading to Kubernetes 1.10 or higher.**

 Rescheduler ensures that critical add-ons are always scheduled
 (assuming the cluster has enough resources to run the critical add-on pods in the absence of regular pods).
@@ -35,18 +41,24 @@ while the other pods shouldn't tolerate the taint. The taint is removed once the

 *Warning:* currently there is no guarantee which node is chosen and which pods are being killed
 in order to schedule critical pods, so if rescheduler is enabled your pods might be occasionally
-killed for this purpose.
+killed for this purpose. Please ensure that rescheduler is not enabled along with priorities & preemptions in default-scheduler as rescheduler is oblivious to priorities and it may evict high priority pods, instead of low priority ones.

 ## Config

-Rescheduler should be enabled by default. It doesn't have any user facing configuration (component config) or API.
-Rescheduler may also be disabled.
+Rescheduler doesn't have any user facing configuration (component config) or API.

-### Marking add-on as critical
+### Marking pod as critical when using Rescheduler. 
+** Marking pod as critical when using Rescheduler.

-To be critical an add-on has to run in `kube-system` namespace (configurable via flag) and
+To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and

 * have the `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string, and
-* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`
+* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`.

 The first one marks a pod a critical. The second one is required by Rescheduler algorithm.
+
+### Marking pod as critical when priorites are enabled.
+
+To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
+
+* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too).
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - jszczepkowski
 title: Set up High-Availability Kubernetes Masters
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - murali-reddy
 title: Use Kube-router for NetworkPolicy
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - pipejakob
 title: Upgrading kubeadm clusters from 1.6 to 1.7
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - pipejakob
 - luxas
 - roberthbailey
@@ -36,10 +36,10 @@ You have to carry out the following steps by executing these commands on your ma
 1. Install the most recent version of `kubeadm` using `curl` like so:

 ```shell
-$ export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
-$ 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
+export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
+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 
@@ -51,7 +51,7 @@ this limitation.
 Verify that this download of kubeadm works, and has the expected version:

 ```shell
-$ kubeadm version
+kubeadm version
 ```

 2. If this the first time you use `kubeadm upgrade`, in order to preserve the configuration for future upgrades, do:
@@ -61,7 +61,7 @@ Note that for below you will need to recall what CLI args you passed to `kubeadm
 If you used flags, do:

 ```shell
-$ kubeadm config upload from-flags [flags]
+kubeadm config upload from-flags [flags]
 ```

 Where `flags` can be empty.
@@ -69,7 +69,7 @@ Where `flags` can be empty.
 If you used a config file, do:

 ```shell
-$ kubeadm config upload from-file --config [config]
+kubeadm config upload from-file --config [config]
 ```

 Where the `config` is mandatory.
@@ -77,7 +77,12 @@ Where the `config` is mandatory.
 3. On the master node, run the following:

 ```shell
-$ kubeadm upgrade plan
+kubeadm upgrade plan
+```
+
+You should see output similar to this:
+
+```shell
 [preflight] Running pre-flight checks
 [upgrade] Making sure the cluster is healthy:
 [upgrade/health] Checking API Server health: Healthy
@@ -115,7 +120,7 @@ Components that must be upgraded manually after you've upgraded the control plan
 COMPONENT   CURRENT      AVAILABLE
 Kubelet     1 x v1.7.1   v1.8.0

-Upgrade to the latest experimental version:
+Upgrade to the latest stable version:

 COMPONENT            CURRENT   AVAILABLE
 API Server           v1.7.1    v1.8.0
@@ -138,7 +143,12 @@ The `kubeadm upgrade plan` checks that your cluster is in an upgradeable state a
 4. Pick a version to upgrade to and run, for example, `kubeadm upgrade apply` as follows:

 ```shell
-$ kubeadm upgrade apply v1.8.0
+kubeadm upgrade apply v1.8.0
+```
+
+You should see output similar to this:
+
+```shell
 [preflight] Running pre-flight checks
 [upgrade] Making sure the cluster is healthy:
 [upgrade/health] Checking API Server health: Healthy
@@ -211,7 +221,7 @@ $ kubeadm upgrade apply v1.8.0
 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
+kubectl create clusterrolebinding kubeadm:node-autoapprove-certificate-rotation --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeclient --group=system:nodes
 ```

 ## Upgrading your master and node packages
@@ -221,7 +231,7 @@ For each host (referred to as `$HOST` below) in your cluster, upgrade `kubelet`
 1. Prepare the host for maintenance, marking it unschedulable and evicting the workload:

 ```shell
-$ kubectl drain $HOST --ignore-daemonsets
+kubectl drain $HOST --ignore-daemonsets
 ```

 When running this command against the master host, this error is expected and can be safely ignored (since there are static pods running on the master):
@@ -236,32 +246,32 @@ error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or
 If the host is running a Debian-based distro such as Ubuntu, run:

 ```shell
-$ apt-get update
-$ apt-get upgrade
+apt-get update
+apt-get upgrade
 ```

 If the host is running CentOS or the like, run:

 ```shell
-$ yum update
+yum update
 ```

 Now the new version of the `kubelet` should be running on the host. Verify this using the following command on `$HOST`:

 ```shell
-$ systemctl status kubelet
+systemctl status kubelet
 ```

 3. Bring the host back online by marking it schedulable:

 ```shell
-$ kubectl uncordon $HOST
+kubectl uncordon $HOST
 ```

 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
+kubectl get nodes
 ```

 If the `STATUS` column of the above command shows `Ready` for all of your hosts, you are done.
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - pipejakob
 - luxas
 - roberthbailey
@@ -39,10 +39,10 @@ Execute these commands on your master node:
 1. Install the most recent version of `kubeadm` using `curl` like so:

 ```shell
-$ export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
-$ 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
+export VERSION=$(curl -sSL https://dl.k8s.io/release/stable.txt) # or manually specify a released Kubernetes version
+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. 
@@ -53,13 +53,18 @@ team is working on fixing this limitation.
 Verify that this download of kubeadm works and has the expected version:

 ```shell
-$ kubeadm version
+kubeadm version
 ```

 2. On the master node, run the following:

 ```shell
-$ kubeadm upgrade plan
+kubeadm upgrade plan
+```
+
+You should see output similar to this:
+
+```shell
 [preflight] Running pre-flight checks
 [upgrade] Making sure the cluster is healthy:
 [upgrade/health] Checking API Server health: Healthy
@@ -97,7 +102,7 @@ Components that must be upgraded manually after you've upgraded the control plan
 COMPONENT   CURRENT      AVAILABLE
 Kubelet     1 x v1.8.1   v1.9.0

-Upgrade to the latest experimental version:
+Upgrade to the latest stable version:

 COMPONENT            CURRENT   AVAILABLE
 API Server           v1.8.1    v1.9.0
@@ -122,7 +127,12 @@ To check CoreDNS version, include the `--feature-gates=CoreDNS=true` flag to ver
 3. Pick a version to upgrade to and run. For example:

 ```shell
-$ kubeadm upgrade apply v1.9.0
+kubeadm upgrade apply v1.9.0
+```
+
+You should see output similar to this:
+
+```shell
 [preflight] Running pre-flight checks.
 [upgrade] Making sure the cluster is healthy:
 [upgrade/config] Making sure the configuration is correct:
@@ -194,7 +204,7 @@ For each host (referred to as `$HOST` below) in your cluster, upgrade `kubelet`
 1. Prepare the host for maintenance, marking it unschedulable and evicting the workload:

 ```shell
-$ kubectl drain $HOST --ignore-daemonsets
+kubectl drain $HOST --ignore-daemonsets
 ```

 When running this command against the master host, this error is expected and can be safely ignored (since there are static pods running on the master):
@@ -209,32 +219,32 @@ error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or
 If the host is running a Debian-based distro such as Ubuntu, run:

 ```shell
-$ apt-get update
-$ apt-get upgrade
+apt-get update
+apt-get upgrade
 ```

 If the host is running CentOS or the like, run:

 ```shell
-$ yum update
+yum update
 ```

 Now the new version of the `kubelet` should be running on the host. Verify this using the following command on `$HOST`:

 ```shell
-$ systemctl status kubelet
+systemctl status kubelet
 ```

 3. Bring the host back online by marking it schedulable:

 ```shell
-$ kubectl uncordon $HOST
+kubectl uncordon $HOST
 ```

 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
+kubectl get nodes
 ```

 If the `STATUS` column of the above command shows `Ready` for all of your hosts, you are done.
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - mtaufen
 - dawnchen
 title: Set Kubelet parameters via a config file
@@ -10,7 +10,7 @@ memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024))
 memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes)
 memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}')

-memory_working_set=$memory_usage_in_bytes
+memory_working_set=${memory_usage_in_bytes}
 if [ "$memory_working_set" -lt "$memory_total_inactive_file" ];
 then
    memory_working_set=0
@@ -28,4 +28,4 @@ echo "memory.total_inactive_file $memory_total_inactive_file"
 echo "memory.working_set $memory_working_set"
 echo "memory.available_in_bytes $memory_available_in_bytes"
 echo "memory.available_in_kb $memory_available_in_kb"
-echo "memory.available_in_mb $memory_available_in_mb"
+echo "memory.available_in_mb $memory_available_in_mb"
@@ -1,4 +1,4 @@
-apiVersion: apps/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
  labels:
@@ -7,6 +7,10 @@ metadata:
  name: my-scheduler
  namespace: kube-system
 spec:
+  selector:
+    matchLabels:
+      component: scheduler
+      tier: control-plane
  replicas: 1
  template:
    metadata:
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - derekwaynecarr
 - janetkuo
 title: Namespaces Walkthrough
@@ -28,7 +28,7 @@ This example assumes the following:
 By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods,
 Services, and Deployments used by the cluster.

-Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
+Assuming you have a fresh cluster, you can inspect the available namespaces by doing the following:

 ```shell
 $ kubectl get namespaces
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - derekwaynecarr
 - janetkuo
 title: Share a Cluster with Namespaces
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - derekwaynecarr
 - vishh
 - timstclair
@@ -312,7 +312,7 @@ To facilitate this scenario, the `kubelet` would be launched as follows:
 Implicit in this configuration is the understanding that "System reserved" should include the amount of memory
 covered by the eviction threshold.

-To reach that capacity, either some Pod is using more than its request, or the system is using more than `500Mi`.
+To reach that capacity, either some Pod is using more than its request, or the system is using more than `1.5Gi - 500Mi = 1Gi`.

 This configuration ensures that the scheduler does not place Pods on a node that immediately induce memory pressure
 and trigger eviction assuming those Pods use less than their configured request.
@@ -0,0 +1,144 @@
+---
+reviewers:
+- msau42
+- jsafrane
+title: Persistent Volume Claim Protection
+---
+
+{% capture overview %}
+{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
+
+As of Kubernetes 1.9, persistent volume claims (PVCs) that are in active use by a pod can be protected from pre-mature removal.
+
+{% endcapture %}
+
+{% capture prerequisites %}
+
+- A v1.9 or higher Kubernetes must be installed.
+- As PVC Protection is a Kubernetes v1.9 alpha feature it must be enabled:
+1. [Admission controller](/docs/admin/admission-controllers/) must be started with the [PVC Protection plugin](/docs/admin/admission-controllers/#persistent-volume-claim-protection-alpha).
+2. All Kubernetes components must be started with the `PVCProtection` alpha features enabled.
+
+{% endcapture %}
+
+{% capture steps %}
+
+## PVC Protection Verification
+
+The example below uses a GCE PD `StorageClass`, however, similar steps can be performed for any volume type.
+
+Create a `StorageClass` for convenient storage provisioning:
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: slow
+provisioner: kubernetes.io/gce-pd
+parameters:
+  type: pd-standard
+```
+
+There are two scenarios: a PVC deleted by a user is either in active use or not in active use by a pod.
+
+### Scenario 1: The PVC is not in active use by a pod
+
+- Create a PVC:
+
+```yaml
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: slzc
+spec:
+  accessModes:
+    - ReadWriteOnce
+  storageClassName: slow
+  resources:
+    requests:
+      storage: 3.7Gi
+```
+
+- Check that the PVC has the finalizer `kubernetes.io/pvc-protection` set:
+```shell
+$ kubectl describe pvc slzc
+Name:          slzc
+Namespace:     default
+StorageClass:  slow
+Status:        Bound
+Volume:        pvc-bee8c30a-d6a3-11e7-9af0-42010a800002
+Labels:        <none>
+Annotations:   pv.kubernetes.io/bind-completed=yes
+               pv.kubernetes.io/bound-by-controller=yes
+               volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd
+Finalizers:    [kubernetes.io/pvc-protection]
+Capacity:      4Gi
+Access Modes:  RWO
+Events:
+  Type    Reason                 Age   From                         Message
+  ----    ------                 ----  ----                         -------
+  Normal  ProvisioningSucceeded  2m    persistentvolume-controller  Successfully provisioned volume pvc-bee8c30a-d6a3-11e7-9af0-42010a800002 using kubernetes.io/gce-pd
+```
+
+- Delete the PVC and check that the PVC (not in active use by a pod) was removed successfully.
+
+### Scenario 2: The PVC is in active use by a pod
+
+- Again, create the same PVC.
+- Create a pod that uses the PVC:
+
+```yaml
+kind: Pod
+apiVersion: v1
+metadata:
+  name: app1
+spec:
+  containers:
+  - name: test-pod
+    image: k8s.gcr.io/busybox:1.24
+    command:
+      - "/bin/sh"
+    args:
+      - "-c"
+      - "date > /mnt/app1.txt; sleep 60 && exit 0 || exit 1"
+    volumeMounts:
+      - name: path-pvc
+        mountPath: "/mnt"
+  restartPolicy: "Never"
+  volumes:
+    - name: path-pvc
+      persistentVolumeClaim:
+        claimName: slzc
+```
+
+- Wait until the pod status is `Running`, i.e. the PVC becomes in active use.
+- Delete the PVC that is now in active use by a pod and verify that the PVC is not removed but its status is `Terminating`:
+
+```shell
+Name:          slzc
+Namespace:     default
+StorageClass:  slow
+Status:        Terminating (since Fri, 01 Dec 2017 14:47:55 +0000)
+Volume:        pvc-803a1f4d-d6a6-11e7-9af0-42010a800002
+Labels:        <none>
+Annotations:   pv.kubernetes.io/bind-completed=yes
+               pv.kubernetes.io/bound-by-controller=yes
+               volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd
+Finalizers:    [kubernetes.io/pvc-protection]
+Capacity:      4Gi
+Access Modes:  RWO
+Events:
+  Type    Reason                 Age   From                         Message
+  ----    ------                 ----  ----                         -------
+  Normal  ProvisioningSucceeded  52s   persistentvolume-controller  Successfully provisioned volume pvc-803a1f4d-d6a6-11e7-9af0-42010a800002 using kubernetes.io/gce-pd
+```
+-  Wait until the pod status is `Terminated` (either delete the pod or wait until it finishes). Afterwards, check that the PVC is removed.
+
+
+{% endcapture %}
+
+{% capture discussion %}
+
+
+{% endcapture %}
+
+{% include templates/task.md %}
@@ -1,8 +1,11 @@
-apiVersion: apps/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: pod-quota-demo
 spec:
+  selector:
+    matchLabels:
+      purpose: quota-demo
  replicas: 3
  template:
    metadata:
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - mtaufen
 - dawnchen
 title: Reconfigure a Node's Kubelet in a Live Cluster
@@ -332,7 +332,7 @@ condition's message reverts to `using current: local`.

 ### Deauthorize your Node fom reading the old ConfigMap

-Once you know your Node is using the default configuraiton again, it is a good
+Once you know your Node is using the default configuration again, it is a good
 idea to deauthorize the node from reading the old ConfigMap. Run the following
 commands to remove the RoleBinding and Role:

@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - vishh
 - derekwaynecarr
 - dashpole
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - chrismarino
 title: Romana for NetworkPolicy
 ---
@@ -1,19 +1,19 @@
 ---
-approvers:
+reviewers:
 - luxas
 - thockin
 - wlan0
 title: Kubernetes Cloud Controller Manager
 ---

-**Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers can develop their features independently from the core Kubernetes release cycles.**
+{% include feature-state-alpha.md %}

 * TOC
 {:toc}

 ## Cloud Controller Manager

-Kubernetes v1.6 contains a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
+Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.

 The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.

@@ -25,7 +25,7 @@ Every cloud has their own set of requirements for running their own cloud provid

 * cloud authentication/authorization: your cloud may require a token or IAM rules to allow access to their APIs
 * kubernetes authentication/authorization: cloud-controller-manager may need RBAC rules set to speak to the kubernetes apiserver
-* high availabilty: like kube-controller-manager, you may want a high available setup for cloud controller manager using leader election (on by default).
+* high availability: like kube-controller-manager, you may want a high available setup for cloud controller manager using leader election (on by default).

 ### Running cloud-controller-manager

@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - davidopp
 - mml
 - foxish
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - smarterclayton
 - liggitt
 - ericchiang
@@ -39,7 +39,7 @@ potentially unsecured traffic.

 Choose an authentication mechanism for the API servers to use that matches the common access patterns 
 when you install a cluster. For instance, small single user clusters may wish to use a simple certificate 
-or static Bearer token approach. Larger clusters may wish to integrate an existing or OIDC or LDAP server that
+or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that
 allow users to be subdivided into groups. 

 All API clients must be authenticated, even those that are part of the infrastructure like nodes,
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - jsafrane
 title: Static Pods
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - mml
 title: Cluster Management Guide for Version 1.6
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bboreham
 title: Weave Net for NetworkPolicy
 ---
@@ -67,7 +67,7 @@ for the Pod:
 {% include code.html language="yaml" file="memory-request-limit.yaml" ghlink="/docs/tasks/configure-pod-container/memory-request-limit.yaml" %}

 In the configuration file, the `args` section provides arguments for the Container when it starts.
-The `-mem-total 150Mi` argument tells the Container to attempt to allocate 150 MiB of memory.
+The `"--vm-bytes", "150M"` arguments tell the Container to attempt to allocate 150 MiB of memory.

 Create the Pod:

@@ -0,0 +1,7 @@
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
@@ -0,0 +1,4 @@
+color.good=purple
+color.bad=yellow
+allow.textmode=true
+how.nice.to.look=fairlyNice
@@ -63,7 +63,7 @@ Here is the configuration file for the hostPath PersistentVolume:
 {% include code.html language="yaml" file="task-pv-volume.yaml" ghlink="/docs/tasks/configure-pod-container/task-pv-volume.yaml" %}

 The configuration file specifies that the volume is at `/mnt/data` on the
-the cluster's Node. The configuration also specifies a size of 10 gibibytes and
+cluster's Node. The configuration also specifies a size of 10 gibibytes and
 an access mode of `ReadWriteOnce`, which means the volume can be mounted as
 read-write by a single Node. It defines the [StorageClass name](/docs/concepts/storage/persistent-volumes/#class)
 `manual` for the PersistentVolume, which will be used to bind
@@ -31,8 +31,8 @@ The data source corresponds to a key-value pair in the ConfigMap, where
 * key = the file name or the key you provided on the command line, and
 * value = the file contents or the literal value you provided on the command line.

-You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or
-[`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information
+You can use [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) or
+[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to retrieve information
 about a ConfigMap.

 ### Create ConfigMaps from directories
@@ -42,13 +42,13 @@ You can use `kubectl create configmap` to create a ConfigMap from multiple files
 For example:

 ```shell
-kubectl create configmap game-config --from-file=docs/user-guide/configmap/kubectl
+kubectl create configmap game-config --from-file=https://k8s.io/docs/tasks/configure-pod-container/configmap/kubectl
 ```

-combines the contents of the `docs/user-guide/configmap/kubectl/` directory
+combines the contents of the `docs/tasks/configure-pod-container/configmap/kubectl/` directory

 ```shell
-ls docs/user-guide/configmap/kubectl/
+ls docs/tasks/configure-pod-container/configmap/kubectl/
 game.properties
 ui.properties
 ```
@@ -68,7 +68,7 @@ game.properties:        158 bytes
 ui.properties:          83 bytes
 ```

-The `game.properties` and `ui.properties` files in the `docs/user-guide/configmap/kubectl/` directory are represented in the `data` section of the ConfigMap.
+The `game.properties` and `ui.properties` files in the `docs/tasks/configure-pod-container/configmap/kubectl/` directory are represented in the `data` section of the ConfigMap.

 ```shell
 kubectl get configmaps game-config -o yaml
@@ -107,7 +107,7 @@ You can use `kubectl create configmap` to create a ConfigMap from an individual
 For example,

 ```shell
-kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties
+kubectl create configmap game-config-2 --from-file=https://k8s.io/docs/tasks/configure-pod-container/configmap/kubectl/game.properties
 ```

 would produce the following ConfigMap:
@@ -127,7 +127,7 @@ game.properties:        158 bytes
 You can pass in the  `--from-file` argument multiple times to create a ConfigMap from multiple data sources.

 ```shell
-kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties --from-file=docs/user-guide/configmap/kubectl/ui.properties
+kubectl create configmap game-config-2 --from-file=https://k8s.io/docs/tasks/configure-pod-container/configmap/kubectl/game.properties --from-file=https://k8s.io/docs/tasks/configure-pod-container/configmap/kubectl/ui.properties
 ```

 ```shell
@@ -143,6 +143,75 @@ game.properties:        158 bytes
 ui.properties:          83 bytes
 ```

+Use the option `--from-env-file` to create a ConfigMap from an env-file, for example:
+```shell
+# Env-files contain a list of environment variables.
+# These syntax rules apply:
+#   Each line in an env file has to be in VAR=VAL format.
+#   Lines beginning with # (i.e. comments) are ignored.
+#   Blank lines are ignored.
+#   There is no special handling of quotation marks (i.e. they will be part of the ConfigMap value)).
+
+
+cat docs/tasks/configure-pod-container/game-env-file.properties
+enemies=aliens
+lives=3
+allowed="true"
+
+# This comment and the empty line above it are ignored
+```
+
+```shell
+kubectl create configmap game-config-env-file \
+        --from-env-file=docs/tasks/configure-pod-container/game-env-file.properties
+```
+
+would produce the following ConfigMap:
+
+```shell
+kubectl get configmap game-config-env-file -o yaml
+apiVersion: v1
+data:
+  allowed: '"true"'
+  enemies: aliens
+  lives: "3"
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2017-12-27T18:36:28Z
+  name: game-config-env-file
+  namespace: default
+  resourceVersion: "809965"
+  selfLink: /api/v1/namespaces/default/configmaps/game-config-env-file
+  uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
+```
+
+When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used:
+
+```shell
+kubectl create configmap config-multi-env-files \
+        --from-env-file=docs/tasks/configure-pod-container/game-env-file.properties \
+        --from-env-file=docs/tasks/configure-pod-container/ui-env-file.properties
+```
+
+would produce the following ConfigMap:
+
+```
+kubectl get configmap config-multi-env-files -o yaml
+apiVersion: v1
+data:
+  color: purple
+  how: fairlyNice
+  textmode: "true"
+kind: ConfigMap
+metadata:
+  creationTimestamp: 2017-12-27T18:38:34Z
+  name: config-multi-env-files
+  namespace: default
+  resourceVersion: "810136"
+  selfLink: /api/v1/namespaces/default/configmaps/config-multi-env-files
+  uid: 252c4572-eb35-11e7-887b-42010a8002b8
+```
+
 #### Define the key to use when creating a ConfigMap from a file

 You can define a key other than the file name to use in the `data` section of your ConfigMap when using the `--from-file` argument:
@@ -156,7 +225,7 @@ where `<my-key-name>` is the key you want to use in the ConfigMap and `<path-to-
 For example:

 ```shell
-kubectl create configmap game-config-3 --from-file=game-special-key=docs/user-guide/configmap/kubectl/game.properties
+kubectl create configmap game-config-3 --from-file=game-special-key=https://k8s.io/docs/tasks/configure-pod-container/configmap/kubectl/game.properties

 kubectl get configmaps game-config-3 -o yaml
 ```
@@ -476,6 +545,11 @@ basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files

 When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet.

+**Note:** A container using a ConfigMap as a
+[subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive
+ConfigMap updates.
+{: .note}
+
 {% endcapture %}

 {% capture discussion %}
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - jpeeler
 - pmorie
 title: Configure a Pod to Use a Projected Volume for Storage
@@ -57,7 +57,7 @@ the Pod:

 {% capture whatsnext %}
 * Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
-* Read the the [all-in-one volume](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
+* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
 {% endcapture %}

 {% include templates/task.md %}
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bprashanth
 - liggitt
 - thockin
@@ -2,6 +2,7 @@ apiVersion: v1
 kind: Pod
 metadata:
  name: cpu-demo-2
+  namespace: cpu-example
 spec:
  containers:
  - name: cpu-demo-ctr-2
@@ -2,6 +2,7 @@ apiVersion: v1
 kind: Pod
 metadata:
  name: cpu-demo
+  namespace: cpu-example
 spec:
  containers:
  - name: cpu-demo-ctr
@@ -0,0 +1,5 @@
+enemies=aliens
+lives=3
+allowed="true"
+
+# This comment and the empty line above it are ignored
@@ -2,19 +2,15 @@ apiVersion: v1
 kind: Pod
 metadata:
  name: memory-demo-2
+  namespace: mem-example
 spec:
  containers:
  - name: memory-demo-2-ctr
-    image: vish/stress
+    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
-    args:
-    - -mem-total
-    - 250Mi
-    - -mem-alloc-size
-    - 10Mi
-    - -mem-alloc-sleep
-    - 1s
+    command: ["stress"]
+    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]
@@ -2,19 +2,15 @@ apiVersion: v1
 kind: Pod
 metadata:
  name: memory-demo-3
+  namespace: mem-example
 spec:
  containers:
  - name: memory-demo-3-ctr
-    image: vish/stress
+    image: polinux/stress
    resources:
      limits:
        memory: "1000Gi"
      requests:
        memory: "1000Gi"
-    args:
-    - -mem-total
-    - 150Mi
-    - -mem-alloc-size
-    - 10Mi
-    - -mem-alloc-sleep
-    - 1s
+    command: ["stress"]
+    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
@@ -2,19 +2,15 @@ apiVersion: v1
 kind: Pod
 metadata:
  name: memory-demo
+  namespace: mem-example
 spec:
  containers:
  - name: memory-demo-ctr
-    image: vish/stress
+    image: polinux/stress
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
-    args:
-    - -mem-total
-    - 150Mi
-    - -mem-alloc-size
-    - 10Mi
-    - -mem-alloc-sleep
-    - 1s
+    command: ["stress"]
+    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
@@ -7,5 +7,5 @@ spec:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
-  - name: regsecret
+  - name: regcred

@@ -22,12 +22,13 @@ private Docker registry or repository.

 ## Log in to Docker

+On your laptop, you must authenticate with a registry in order to pull a private image:
+
    docker login

 When prompted, enter your Docker username and password.

-The login process creates or updates a `config.json` file that holds an
-authorization token.
+The login process creates or updates a `config.json` file that holds an authorization token.

 View the `config.json` file:

@@ -46,11 +47,13 @@ The output contains a section similar to this:
 **Note:** If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
 {: .note}

-## Create a Secret that holds your authorization token
+## Create a Secret in the cluster that holds your authorization token

-Create a Secret named `regsecret`:
+A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate with a container registry to pull a private image.

-    kubectl create secret docker-registry regsecret --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
+Create this Secret, naming it `regcred`:
+
+    kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

 where:

@@ -59,46 +62,44 @@ where:
 * `<your-pword>` is your Docker password.
 * `<your-email>` is your Docker email.

-## Understanding your Secret
+You have successfully set your Docker credentials in the cluster as a Secret called `regcred`.

-To understand what's in the Secret you just created, start by viewing the
-Secret in YAML format:
+## Inspecting the Secret `regcred`

-    kubectl get secret regsecret --output=yaml
+To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
+
+    kubectl get secret regcred --output=yaml

 The output is similar to this:

    apiVersion: v1
    data:
-      .dockercfg: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
+      .dockerconfigjson: eyJodHRwczovL2luZGV4L ... J0QUl6RTIifX0=
    kind: Secret
    metadata:
      ...
-      name: regsecret
+      name: regcred
      ...
-    type: kubernetes.io/dockercfg
+    type: kubernetes.io/dockerconfigjson

-The value of the `.dockercfg` field is a base64 representation of your secret data.
+The value of the `.dockerconfigjson` field is a base64 representation of your Docker credentials.

-Copy the base64 representation of the secret data into a file named `secret64`.
-
-**Important**: Make sure there are no line breaks in your `secret64` file.
-
-To understand what is in the `.dockercfg` field, convert the secret data to a
+To understand what is in the `.dockerconfigjson` field, convert the secret data to a
 readable format:

-    base64 -d secret64
+    kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 -d

 The output is similar to this:

-    {"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}
+    {"auths":{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}

-Notice that the secret data contains the authorization token from your
-`config.json` file.
+Notice that the Secret data contains the authorization token similar to your local `~/.docker/config.json` file.
+
+You have successfully set your Docker credentials as a Secret called `regcred` in the cluster.

 ## Create a Pod that uses your Secret

-Here is a configuration file for a Pod that needs access to your secret data:
+Here is a configuration file for a Pod that needs access to your Docker credentials in `regcred`:

 {% include code.html language="yaml" file="private-reg-pod.yaml" ghlink="/docs/tasks/configure-pod-container/private-reg-pod.yaml" %}

@@ -106,17 +107,12 @@ Download the above file:

    wget -O my-private-reg-pod.yaml https://k8s.io/docs/tasks/configure-pod-container/private-reg-pod.yaml

-In file `my-private-reg-pod.yaml`, replace `<your-private-image>` with the
-path to an image in a private repository.
-
-Example Docker Hub private image:
+In file `my-private-reg-pod.yaml`, replace `<your-private-image>` with the path to an image in a private registry such as:

    janedoe/jdoe-private:v1

-To pull the image from the private repository, Kubernetes needs credentials. The
- `imagePullSecrets` field in the configuration file specifies that Kubernetes
- should get the credentials from a Secret named
-`regsecret`.
+To pull the image from the private registry, Kubernetes needs credentials.
+The `imagePullSecrets` field in the configuration file specifies that Kubernetes should get the credentials from a Secret named `regcred`.

 Create a Pod that uses your Secret, and verify that the Pod is running:

@@ -128,12 +124,10 @@ Create a Pod that uses your Secret, and verify that the Pod is running:
 {% capture whatsnext %}

 * Learn more about [Secrets](/docs/concepts/configuration/secret/).
-* Learn more about
-[using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
+* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
 * See [kubectl create secret docker-registry](/docs/user-guide/kubectl/{{page.version}}/#-em-secret-docker-registry-em-).
-* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core)
-* See the `imagePullSecrets` field of
-[PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).
+* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core).
+* See the `imagePullSecrets` field of [PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).

 {% endcapture %}

@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - erictune
 - mikedanese
 - thockin
@@ -43,7 +43,7 @@ For more information about security mechanisms in Linux, see

 To specify security settings for a Pod, include the `securityContext` field
 in the Pod specification. The `securityContext` field is a
-[PodSecurityContext](/docs/api-reference/{{page.version}}/#podsecuritycontext-v1-core) object.
+[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{page.version}}/#podsecuritycontext-v1-core) object.
 The security settings that you specify for a Pod apply to all Containers in the Pod.
 Here is a configuration file for a Pod that has a `securityContext` and an `emptyDir` volume:

@@ -131,7 +131,7 @@ exit

 To specify security settings for a Container, include the `securityContext` field
 in the Container manifest. The `securityContext` field is a
-[SecurityContext](/docs/api-reference/{{page.version}}/#securitycontext-v1-core) object.
+[SecurityContext](/docs/reference/generated/kubernetes-api/{{page.version}}/#securitycontext-v1-core) object.
 Security settings that you specify for a Container apply only to
 the individual Container, and they override settings made at the Pod level when
 there is overlap. Container settings do not affect the Pod's Volumes.
@@ -0,0 +1,3 @@
+color=purple
+textmode=true
+how=fairlyNice
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - soltysh
 - sttts
 - ericchiang
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - fgrzadkowski
 - piosz
 title: Core metrics pipeline
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - janetkuo
 - thockin
 title: Application Introspection and Debugging
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - mikedanese
 - thockin
 title: Troubleshoot Applications
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - davidopp
 title: Troubleshoot Clusters
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bprashanth
 - enisoc
 - erictune
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bprashanth
 title: Debug Pods and Replication Controllers
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - thockin
 - bowei
 title: Debug Services
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bprashanth
 - enisoc
 - erictune
@@ -21,7 +21,7 @@ subjects:
  name: event-exporter-sa
  namespace: default
 ---
-apiVersion: apps/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: event-exporter-v0.1.0
@@ -29,6 +29,9 @@ metadata:
  labels:
    app: event-exporter
 spec:
+  selector:
+    matchLabels:
+      app: event-exporter
  replicas: 1
  template:
    metadata:
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - crassirostris
 - piosz
 title: Events in Stackdriver
@@ -55,7 +55,7 @@ spec:
          readOnly: true
        - name: config-volume
          mountPath: /etc/fluent/config.d
-        # Liveness probe is aimed to help in situarions where fluentd
+        # Liveness probe is aimed to help in situations where fluentd
        # silently hangs for no apparent reasons until manual restart.
        # The idea of this probe is that if fluentd is not queueing or
        # flushing chunks for 5 minutes, something is not right. If
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - caesarxuchao
 - mikedanese
 title: Get a Shell to a Running Container
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - crassirostris
 - piosz
 title: Logging Using Elasticsearch and Kibana
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - crassirostris
 - piosz
 title: Logging Using Stackdriver
@@ -10,7 +10,7 @@ with the [overview of logging in Kubernetes](/docs/concepts/cluster-administrati

 **Note:** By default, Stackdriver logging collects only your container's standard output and
 standard error streams. To collect any logs your application writes to a file (for example),
-see the [sidecar approach](/docs/concepts/cluster-administration/logging#using-a-sidecar-container-with-the-logging-agent)
+see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
 in the Kubernetes logging overview.

 ## Deploying
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - Random-Liu
 - dchen1107
 title: Monitor Node Health
@@ -1,8 +1,11 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
  name: nginx-deployment
 spec:
+  selector:
+    matchLabels:
+      app: nginx
  replicas: 2
  template:
    metadata:
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - mikedanese
 title: Tools for Monitoring Compute, Storage, and Network Resources
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - brendandburns
 - davidopp
 title: Troubleshooting
@@ -1,6 +1,6 @@
 ---
 title: Example Task Template
-approvers:
+reviewers:
 - chenopis
 ---

@@ -1,6 +1,6 @@
 ---
 title: Extend kubectl with plugins
-approvers:
+reviewers:
 - fabianofranz
 description: With kubectl plugins, you can extend the functionality of the kubectl command by adding new subcommands.
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - bprashanth
 - quinton-hoole
 title: Cross-cluster Service Discovery using Federated Services
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1
 kind: Deployment
 metadata:
  labels:
@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1
 kind: ReplicaSet
 metadata:
  labels:
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - madhusudancs
 title: Set up Cluster Federation with Kubefed
 ---
@@ -24,52 +24,57 @@ This guide assumes that you have a running Kubernetes cluster. Please
 see one of the [getting started](/docs/setup/) guides
 for installation instructions for your platform.

-
 ## Getting `kubefed`

-Download the client tarball corresponding to the latest release and
-extract the binaries in the tarball with the commands:
+Download the client tarball corresponding to the particular release and 
+extract the binaries in the tarball:
+
+> Note that until kubernetes versions `1.8.x` the federation project was 
+maintained as part of [core kubernetes repo](https://github.com/kubernetes/kubernetes).
+At some point between kubernetes releases `1.8.0` and `1.9.0`, it moved into 
+a separate [federation repo](https://github.com/kubernetes/federation) and is 
+now maintained there. After this move, the federation release information is 
+available at the release page [here](https://github.com/kubernetes/federation/releases).
+
+### For k8s versions 1.8.x and earlier:

 ```shell
-# Linux
-curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/kubernetes-client-linux-amd64.tar.gz
+curl -LO https://storage.googleapis.com/kubernetes-release/release/${RELEASE-VERSION}/kubernetes-client-linux-amd64.tar.gz
 tar -xzvf kubernetes-client-linux-amd64.tar.gz
-
-# OS X
-curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/kubernetes-client-darwin-amd64.tar.gz
-tar -xzvf kubernetes-client-darwin-amd64.tar.gz
-
-# Windows
-curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/kubernetes-client-windows-amd64.tar.gz
-tar -xzvf kubernetes-client-windows-amd64.tar.gz
 ```
+> Note that the variable `RELEASE-VERSION` should be either appropriately 
+set to or replaced with the actual version needed. 

-> Note: The URLs in the curl commands above download the binaries for
-`amd64`. If you are on a different architecture, please use a URL
-appropriate for your architecture. You can find the list of available
-binaries on the
-[release page](https://git.k8s.io/kubernetes/CHANGELOG.md#client-binaries-1).
-
-Copy the extracted binaries to one of the directories in your `$PATH`
-and set the executable permission on those binaries.
-
+Copy the extracted binary to one of the directories in your `$PATH`
+and set the executable permission on the binary.

 ```shell
 sudo cp kubernetes/client/bin/kubefed /usr/local/bin
 sudo chmod +x /usr/local/bin/kubefed
-sudo cp kubernetes/client/bin/kubectl /usr/local/bin
-sudo chmod +x /usr/local/bin/kubectl
 ```

-### Install with snap on Ubuntu
+### For k8s versions 1.9.x and above:

-kubefed is available as a [snap](https://snapcraft.io/) application.
+```shell
+curl -LO https://storage.cloud.google.com/kubernetes-federation-release/release/${RELEASE-VERSION}/federation-client-linux-amd64.tar.gz
+tar -xzvf federation-client-linux-amd64.tar.gz
+```

-1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
+> Note that the variable `RELEASE-VERSION` should be replaced with one of the 
+release versions available at [federation release page](https://github.com/kubernetes/federation/releases). 

-       sudo snap install kubefed --classic
+Copy the extracted binary to one of the directories in your `$PATH`
+and set the executable permission on the binary.

-2. Run [`kubefed version`](/docs/admin/kubefed_version/) to verify that the version you've installed is sufficiently up-to-date.
+```shell
+sudo cp federation/client/bin/kubefed /usr/local/bin
+sudo chmod +x /usr/local/bin/kubefed
+```
+
+### Install kubectl
+
+You can install a matching version of kubectl using the instructions on 
+the  [kubectl install page](https://kubernetes.io/docs/tasks/tools/install-kubectl/).

 ## Choosing a host cluster.

@@ -483,7 +488,7 @@ federation control plane's etcd. You can delete the federation
 namespace by running the following command:

 ```
-kubectl delete ns federation-system --host-cluster-context=rivendell
+kubectl delete ns federation-system --context=rivendell
 ```

 Note that `rivendell` is the host cluster name, replace that with the
@@ -10,14 +10,14 @@ spec:
      args:
      - while true; do
          echo -en '\n';
-          if [[ -e /etc/cpu_limit ]]; then
-            echo -en '\n'; cat /etc/cpu_limit; fi;
-          if [[ -e /etc/cpu_request ]]; then
-            echo -en '\n'; cat /etc/cpu_request; fi;
-          if [[ -e /etc/mem_limit ]]; then
-            echo -en '\n'; cat /etc/mem_limit; fi;
-          if [[ -e /etc/mem_request ]]; then
-            echo -en '\n'; cat /etc/mem_request; fi;
+          if [[ -e /etc/podinfo/cpu_limit ]]; then
+            echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
+          if [[ -e /etc/podinfo/cpu_request ]]; then
+            echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
+          if [[ -e /etc/podinfo/mem_limit ]]; then
+            echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
+          if [[ -e /etc/podinfo/mem_request ]]; then
+            echo -en '\n'; cat /etc/podinfo/mem_request; fi;
          sleep 5;
        done;
      resources:
@@ -29,7 +29,7 @@ spec:
          cpu: "250m"
      volumeMounts:
        - name: podinfo
-          mountPath: /etc
+          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
@@ -16,15 +16,15 @@ spec:
      command: ["sh", "-c"]
      args:
      - while true; do
-          if [[ -e /etc/labels ]]; then 
-            echo -en '\n\n'; cat /etc/labels; fi;
-          if [[ -e /etc/annotations ]]; then
-            echo -en '\n\n'; cat /etc/annotations; fi;
+          if [[ -e /etc/podinfo/labels ]]; then
+            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
+          if [[ -e /etc/podinfo/annotations ]]; then
+            echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
-          mountPath: /etc
+          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
@@ -135,6 +135,11 @@ written to a new temporary directory, and the `..data` symlink is updated
 atomically using
 [rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html).

+**Note:** A container using Downward API as a
+[subPath](/docs/concepts/storage/volumes/#using-subpath) volume mount will not
+receive Downward API updates.
+{: .note}
+
 Exit the shell:

 ```shell
@@ -1,4 +1,4 @@
-apiVersion: apps/v1beta2
+apiVersion: apps/v1
 kind: ReplicaSet
 metadata:
  name: frontend
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - jessfraz
 title: Inject Information into Pods Using a PodPreset
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - janetkuo
 title: Performing a Rollback on a DaemonSet
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - janetkuo
 title: Perform a Rolling Update on a DaemonSet
 ---
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - vishh
 title: Schedule GPUs
 ---
@@ -9,6 +9,141 @@ across nodes. The support for NVIDIA GPUs was added in v1.6 and has gone through
 multiple backwards incompatible iterations. This page describes how users can
 consume GPUs across different Kubernetes versions and the current limitations.

+## v1.8 onwards
+
+**From 1.8 onwards, the recommended way to consume GPUs is to use [device
+plugins](/docs/concepts/cluster-administration/device-plugins).**
+
+To enable GPU support through device plugins before 1,10, the `DevicePlugins`
+feature gate has to be explicitly set to true across the system:
+`--feature-gates="DevicePlugins=true"`. This is no longer required starting
+from 1.10.
+
+Then you have to install NVIDIA drivers on the nodes and run an NVIDIA GPU device
+plugin ([see below](#deploying-nvidia-gpu-device-plugin)).
+
+When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` as
+a schedulable resource.
+
+You can consume these GPUs from your containers by requesting
+`nvidia.com/gpu` just like you request `cpu` or `memory`.
+However, there are some limitations in how you specify the resource requirements
+when using GPUs:
+- GPUs are only supposed to be specified in the `limits` section, which means:
+  * You can specify GPU `limits` without specifying `requests` because
+    Kubernetes will use the limit as the request value by default.
+  * You can specify GPU in both `limits` and `requests` but these two values
+    must be equal.
+  * You cannot specify GPU `requests` without specifying `limits`.
+- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs.
+- Each container can request one or more GPUs. It is not possible to request a
+  fraction of a GPU.
+
+Here's an example:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: cuda-vector-add
+spec:
+  restartPolicy: OnFailure
+  containers:
+    - name: cuda-vector-add
+      # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
+      image: "k8s.gcr.io/cuda-vector-add:v0.1"
+      resources:
+        limits:
+          nvidia.com/gpu: 1 # requesting 1 GPU
+```
+
+### Deploying NVIDIA GPU device plugin
+
+There are currently two device plugin implementations for NVIDIA GPUs:
+
+#### Official NVIDIA GPU device plugin
+
+The [official NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
+has the following requirements:
+- Kubernetes nodes have to be pre-installed with NVIDIA drivers.
+- Kubernetes nodes have to be pre-installed with [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)
+- nvidia-container-runtime must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
+  for docker instead of runc.
+- NVIDIA drivers ~= 361.93
+
+To deploy the NVIDIA device plugin once your cluster is running and the above
+requirements are satisfied:
+
+```
+# For Kubernetes v1.8
+kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml
+
+# For Kubernetes v1.9
+kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml
+```
+
+Report issues with this device plugin to [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
+
+#### NVIDIA GPU device plugin used by GKE/GCE
+
+The [NVIDIA GPU device plugin used by GKE/GCE](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
+doesn't require using nvidia-docker and should work with any container runtime
+that is compatible with the Kubernetes Container Runtime Interface (CRI). It's tested
+on [Container-Optimized OS](https://cloud.google.com/container-optimized-os/)
+and has experimental code for Ubuntu from 1.9 onwards.
+
+On your 1.9 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
+
+```
+# Install NVIDIA drivers on Container-Optimized OS:
+kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/daemonset.yaml
+
+# Install NVIDIA drivers on Ubuntu (experimental):
+kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/nvidia-driver-installer/ubuntu/daemonset.yaml
+
+# Install the device plugin:
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.9/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
+```
+
+Report issues with this device plugin and installation method to [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
+
+## Clusters containing different types of NVIDIA GPUs
+
+If different nodes in your cluster have different types of NVIDIA GPUs, then you
+can use [Node Labels and Node Selectors](/docs/tasks/configure-pod-container/assign-pods-nodes/)
+to schedule pods to appropriate nodes.
+
+For example:
+
+```shell
+# Label your nodes with the accelerator type they have.
+kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
+kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
+```
+
+Specify the GPU type in the pod spec:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: cuda-vector-add
+spec:
+  restartPolicy: OnFailure
+  containers:
+    - name: cuda-vector-add
+      # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
+      image: "k8s.gcr.io/cuda-vector-add:v0.1"
+      resources:
+        limits:
+          nvidia.com/gpu: 1
+  nodeSelector:
+    accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc.
+```
+
+This will ensure that the pod will be scheduled to a node that has the GPU type
+you specified.
+
 ## v1.6 and v1.7
 To enable GPU support in 1.6 and 1.7, a special **alpha** feature gate
 `Accelerators` has to be set to true across the system:
@@ -69,146 +204,6 @@ The `Accelerators` feature gate and `alpha.kubernetes.io/nvidia-gpu` resource
 works on 1.8 and 1.9 as well. It will be deprecated in 1.10 and removed in
 1.11.

-## v1.8 onwards
-
-**From 1.8 onwards, the recommended way to consume GPUs is to use [device
-plugins](/docs/concepts/cluster-administration/device-plugins).**
-
-To enable GPU support through device plugins before 1,10, the `DevicePlugins`
-feature gate has to be explicitly set to true across the system:
-`--feature-gates="DevicePlugins=true"`. This is no longer required starting
-from 1.10.
-
-Then you have to install NVIDIA drivers on the nodes and run an NVIDIA GPU device
-plugin ([see below](#deploying-nvidia-gpu-device-plugin)).
-
-When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` as
-a schedulable resource.
-
-You can consume these GPUs from your containers by requesting
-`nvidia.com/gpu` just like you request `cpu` or `memory`.
-However, there are some limitations in how you specify the resource requirements
-when using GPUs:
- GPUs are only supposed to be specified in the `limits` section, which means:
-  * You can specify GPU `limits` without specifying `requests` because
-    Kubernetes will use the limit as the request value by default.
-  * You can specify GPU in both `limits` and `requests` but these two values
-    must be equal.
-  * You cannot specify GPU `requests` without specifying `limits`.
- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs.
- Each container can request one or more GPUs. It is not possible to request a
-  fraction of a GPU.
-
-Unlike with `alpha.kubernetes.io/nvidia-gpu`, when using `nvidia.com/gpu` as
-the resource, you don't have to mount any special directories in your pod
-specs. The device plugin is expected to inject them automatically in the
-container.
-
-Here's an example:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: cuda-vector-add
-spec:
-  restartPolicy: OnFailure
-  containers:
-    - name: cuda-vector-add
-      # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
-      image: "k8s.gcr.io/cuda-vector-add:v0.1"
-      resources:
-        limits:
-          nvidia.com/gpu: 1 # requesting 1 GPU
-```
-
-### Deploying NVIDIA GPU device plugin
-
-There are currently two device plugin implementations for NVIDIA GPUs:
-
-#### Official NVIDIA GPU device plugin
-
-The [official NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
-has the following requirements:
- Kubernetes nodes have to be pre-installed with NVIDIA drivers.
- Kubernetes nodes have to be pre-installed with [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)
- nvidia-container-runtime must be configured as the [default runtime](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)
-  for docker instead of runc.
- NVIDIA drivers ~= 361.93
-
-To deploy the NVIDIA device plugin once your cluster is running and the above
-requirements are satisfied:
-
-```
-# For Kubernetes v1.8
-kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml
-
-# For Kubernetes v1.9
-kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml
-```
-
-Report issues with this device plugin to [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
-
-#### NVIDIA GPU device plugin used by GKE/GCE
-
-The [NVIDIA GPU device plugin used by GKE/GCE](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
-doesn't require using nvidia-docker and should work with any container runtime
-that is compatible the Kubernetes Container Runtime Interface (CRI). It's tested
-on [Container-Optimized OS](https://cloud.google.com/container-optimized-os/)
-and has experimental code for Ubuntu from 1.9 onwards.
-
-On your 1.9 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
-
-```
-# Install NVIDIA drivers on Container-Optimized OS:
-kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/daemonset.yaml
-
-# Install NVIDIA drivers on Ubuntu (experimental):
-kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/nvidia-driver-installer/ubuntu/daemonset.yaml
-
-# Install the device plugin:
-kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.9/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
-```
-
-Report issues with this device plugin and installation method to [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
-
-## Clusters containing different types of NVIDIA GPUs
-
-If different nodes in your cluster have different types of NVIDIA GPUs, then you
-can use [Node Labels and Node Selectors](/docs/tasks/configure-pod-container/assign-pods-nodes/)
-to schedule pods to appropriate nodes.
-
-For example:
-
-```shell
-# Label your nodes with the accelerator type they have.
-kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
-kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
-```
-
-Specify the GPU type in the pod spec:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: cuda-vector-add
-spec:
-  restartPolicy: OnFailure
-  containers:
-    - name: cuda-vector-add
-      # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
-      image: "k8s.gcr.io/cuda-vector-add:v0.1"
-      resources:
-        limits:
-          nvidia.com/gpu: 1
-  nodeSelector:
-    accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc.
-```
-
-This will ensure that the pod will be scheduled to a node that has the GPU type
-you specified.
-
 ## Future
 - Support for hardware accelerators in Kubernetes is still in alpha.
 - Better APIs will be introduced to provision and consume accelerators in a scalable manner.
@@ -1,5 +1,5 @@
 ---
-approvers:
+reviewers:
 - derekwaynecarr
 title: Manage HugePages
 ---
--- a/Show More
+++ b/Show More