Merge remote-tracking branch 'upstream/master' into release-1.8

2017-08-01 13:17:13 -07:00
parent 9979f1d821 47fb29d668
commit dfbc33b8fb
206 changed files with 2904 additions and 2513 deletions
@@ -32,11 +32,14 @@ defaults:
 permalink: pretty

 gems:
-  - jekyll-redirect-from
  - jekyll-feed
  - jekyll-sitemap
  - jekyll-seo-tag
  - jekyll-include-cache
+# disabled gems
+#  - jekyll-redirect-from
+
+include: [_redirects]

 # SEO
 logo: /images/favicon.png
@@ -7,6 +7,7 @@
    {% if page.case_study_styles %}<link rel="stylesheet" type="text/css" href="/css/case_study_styles.css"><!-- custom case_study_styles on -->{% else %}<link rel="stylesheet" type="text/css" href="/css/styles.css"><!-- default styles.css on -->{% endif %}
    <link rel="stylesheet" type="text/css" href="/css/jquery-ui.min.css">
    <link rel="stylesheet" type="text/css" href="/css/sweetalert.css">
+    <link rel="stylesheet" type="text/css" href="/css/callouts.css">
    {% if page.class == "gridPage" %}<link rel="stylesheet" type="text/css" href="/css/gridpage.css">{% endif %}
    {% if page.css %}<link rel="stylesheet" type="text/css" href="{{ page.css }}"><!-- custom css added -->{% else %}<!-- no custom css detected -->{% endif %}

@@ -1,4 +1,8 @@
 You need to have a Kubernetes cluster, and the kubectl command-line tool must
 be configured to communicate with your cluster. If you do not already have a
 cluster, you can create one by using
-[Minikube](/docs/getting-started-guides/minikube).
+[Minikube](/docs/getting-started-guides/minikube),
+or you can use one of these Kubernetes playgrounds:
+
+* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
+* [Play with Kubernetes](http://labs.play-with-k8s.com/)
@@ -0,0 +1,242 @@
+#
+# set server-side redirects in this file
+# see https://www.netlify.com/docs/redirects/
+#
+
+/docs/admin/addons												/docs/concepts/cluster-administration/addons		301
+/docs/admin/apparmor/											/docs/tutorials/clusters/apparmor		301
+/docs/admin/audit												/docs/tasks/debug-application-cluster/audit		301
+/docs/admin/cluster-components									/docs/concepts/overview/components		301
+/docs/admin/cluster-management									/docs/tasks/administer-cluster/cluster-management		301
+/docs/admin/cluster-troubleshooting								/docs/tasks/debug-application-cluster/debug-cluster		301
+/docs/admin/daemons												/docs/concepts/workloads/controllers/daemonset		301
+/docs/admin/disruptions											/docs/concepts/workloads/pods/disruptions		301
+/docs/admin/dns													/docs/concepts/services-networking/dns-pod-service		301
+/docs/admin/etcd												/docs/tasks/administer-cluster/configure-upgrade-etcd		301
+/docs/admin/etcd_upgrade										/docs/tasks/administer-cluster/configure-upgrade-etcd		301
+/docs/admin/federation/kubefed									/docs/tasks/federation/set-up-cluster-federation-kubefed		301
+/docs/admin/garbage-collection									/docs/concepts/cluster-administration/kubelet-garbage-collection		301
+/docs/admin/ha-master-gce										/docs/tasks/administer-cluster/highly-available-master		301
+/docs/admin/													/docs/concepts/cluster-administration/cluster-administration-overview		301
+/docs/admin/kubeadm-upgrade-1-7									/docs/tasks/administer-cluster/kubeadm-upgrade-1-7		301
+/docs/admin/limitrange/											/docs/tasks/administer-cluster/cpu-memory-limit		301
+/docs/admin/master-node-communication							/docs/concepts/architecture/master-node-communication		301
+/docs/admin/multi-cluster										/docs/concepts/cluster-administration/federation		301
+/docs/admin/multiple-schedulers									/docs/tasks/administer-cluster/configure-multiple-schedulers		301
+/docs/admin/namespaces/											/docs/tasks/administer-cluster/namespaces		301
+/docs/admin/namespaces/walkthrough								/docs/tasks/administer-cluster/namespaces-walkthrough		301
+/docs/admin/network-plugins										/docs/concepts/cluster-administration/network-plugins		301
+/docs/admin/networking											/docs/concepts/cluster-administration/networking		301
+/docs/admin/node												/docs/concepts/architecture/nodes		301
+/docs/admin/node-allocatable									/docs/tasks/administer-cluster/reserve-compute-resources		301
+/docs/admin/node-problem										/docs/tasks/debug-application-cluster/monitor-node-health		301
+/docs/admin/out-of-resource										/docs/tasks/administer-cluster/out-of-resource		301
+/docs/admin/rescheduler											/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods		301
+/docs/admin/resourcequota/										/docs/concepts/policy/resource-quotas		301
+/docs/admin/resourcequota/limitstorageconsumption				/docs/tasks/administer-cluster/limit-storage-consumption		301
+/docs/admin/resourcequota/walkthrough							/docs/tasks/administer-cluster/apply-resource-quota-limit		301
+/docs/admin/static-pods											/docs/tasks/administer-cluster/static-pod		301
+/docs/admin/sysctls												/docs/concepts/cluster-administration/sysctl-cluster		301
+/docs/admin/upgrade-1-6											/docs/tasks/administer-cluster/upgrade-1-6		301
+
+/docs/api														/docs/concepts/overview/kubernetes-api		301
+
+/docs/concepts/abstractions/controllers/garbage-collection		/docs/concepts/workloads/controllers/garbage-collection		301
+/docs/concepts/abstractions/controllers/petsets					/docs/concepts/workloads/controllers/petset		301
+/docs/concepts/abstractions/controllers/statefulsets			/docs/concepts/workloads/controllers/statefulset		301
+/docs/concepts/abstractions/init-containers						/docs/concepts/workloads/pods/init-containers		301
+/docs/concepts/abstractions/overview							/docs/concepts/overview/working-with-objects/kubernetes-objects		301
+/docs/concepts/abstractions/pod									/docs/concepts/workloads/pods/pod-overview		301
+
+/docs/concepts/cluster-administration/access-cluster			/docs/tasks/access-application-cluster/access-cluster		301
+/docs/concepts/cluster-administration/audit						/docs/tasks/debug-application-cluster/audit		301
+/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig	/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig		301
+/docs/concepts/cluster-administration/cluster-management		/docs/tasks/administer-cluster/cluster-management		301
+/docs/concepts/cluster-administration/configure-etcd			/docs/tasks/administer-cluster/configure-upgrade-etcd		301
+/docs/concepts/cluster-administration/etcd-upgrade				/docs/tasks/administer-cluster/configure-upgrade-etcd		301
+/docs/concepts/cluster-administration/federation-service-discovery	/docs/tasks/federation/federation-service-discovery		301
+/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods	/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods		301
+/docs/concepts/cluster-administration/master-node-communication	/docs/concepts/architecture/master-node-communication		301
+/docs/concepts/cluster-administration/multiple-clusters			/docs/concepts/cluster-administration/federation		301
+/docs/concepts/cluster-administration/out-of-resource			/docs/tasks/administer-cluster/out-of-resource		301
+/docs/concepts/cluster-administration/resource-usage-monitoring	/docs/tasks/debug-application-cluster/resource-usage-monitoring		301
+/docs/concepts/cluster-administration/static-pod				/docs/tasks/administer-cluster/static-pod		301
+
+/docs/concepts/clusters/logging									/docs/concepts/cluster-administration/logging		301
+/docs/concepts/configuration/container-command-arg				/docs/tasks/inject-data-application/define-command-argument-container/docs/concepts/ecosystem/thirdpartyresource		301						/docs/tasks/access-kubernetes-api/extend-api-third-party-resource
+/docs/concepts/jobs/cron-jobs									/docs/concepts/workloads/controllers/cron-jobs		301
+/docs/concepts/jobs/run-to-completion-finite-workloads			/docs/concepts/workloads/controllers/jobs-run-to-completion		301
+/docs/concepts/nodes/node										/docs/concepts/architecture/nodes		301
+/docs/concepts/storage/etcd-store-api-object					/docs/tasks/administer-cluster/configure-upgrade-etcd		301
+
+/docs/concepts/tools/kubectl/object-management-overview			/docs/tutorials/object-management-kubectl/object-management		301
+/docs/concepts/tools/kubectl/object-management-using-declarative-config	/docs/tutorials/object-management-kubectl/declarative-object-management-configuration		301
+/docs/concepts/tools/kubectl/object-management-using-imperative-commands	/docs/tutorials/object-management-kubectl/imperative-object-management-command		301
+/docs/concepts/tools/kubectl/object-management-using-imperative-config	/docs/tutorials/object-management-kubectl/imperative-object-management-configuration		301
+
+/docs/getting-started-guides/									/docs/setup/pick-right-solution		301
+/docs/getting-started-guides/kubeadm							/docs/setup/independent/create-cluster-kubeadm		301
+/docs/getting-started-guides/network-policy/calico				/docs/tasks/administer-cluster/calico-network-policy		301
+/docs/getting-started-guides/network-policy/romana				/docs/tasks/administer-cluster/romana-network-policy		301
+/docs/getting-started-guides/network-policy/walkthrough			/docs/tasks/administer-cluster/declare-network-policy		301
+/docs/getting-started-guides/network-policy/weave				/docs/tasks/administer-cluster/weave-network-policy		301
+/docs/getting-started-guides/running-cloud-controller			/docs/tasks/administer-cluster/running-cloud-controller		301
+/docs/getting-started-guides/ubuntu/calico						/docs/getting-started-guides/ubuntu/		301
+
+/docs/hellonode													/docs/tutorials/stateless-application/hello-minikube		301
+/docs/															/docs/home/		301
+/docs/samples													/docs/tutorials/		301
+/docs/tasks/administer-cluster/assign-pods-nodes				/docs/tasks/configure-pod-container/assign-pods-nodes		301
+/docs/tasks/administer-cluster/overview							/docs/concepts/cluster-administration/cluster-administration-overview		301
+
+/docs/tasks/configure-pod-container/apply-resource-quota-limit	/docs/tasks/administer-cluster/apply-resource-quota-limit		301
+/docs/tasks/configure-pod-container/calico-network-policy		/docs/tasks/administer-cluster/calico-network-policy		301
+/docs/tasks/configure-pod-container/communicate-containers-same-pod	/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume		301
+/docs/tasks/configure-pod-container/declare-network-policy		/docs/tasks/administer-cluster/declare-network-policy		301
+/docs/tasks/configure-pod-container/define-environment-variable-container	/docs/tasks/inject-data-application/define-environment-variable-container		301
+/docs/tasks/configure-pod-container/distribute-credentials-secure	/docs/tasks/inject-data-application/distribute-credentials-secure		301
+/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information	/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information		301
+/docs/tasks/configure-pod-container/environment-variable-expose-pod-information	/docs/tasks/inject-data-application/environment-variable-expose-pod-information		301
+/docs/tasks/configure-pod-container/limit-range					/docs/tasks/administer-cluster/cpu-memory-limit		301
+/docs/tasks/configure-pod-container/romana-network-policy		/docs/tasks/administer-cluster/romana-network-policy		301
+/docs/tasks/configure-pod-container/weave-network-policy		/docs/tasks/administer-cluster/weave-network-policy		301
+
+/docs/tasks/kubectl/get-shell-running-container					/docs/tasks/debug-application-cluster/get-shell-running-container		301
+/docs/tasks/kubectl/install										/docs/tasks/tools/install-kubectl		301
+/docs/tasks/kubectl/list-all-running-container-images			/docs/tasks/access-application-cluster/list-all-running-container-images		301
+
+/docs/tasks/manage-stateful-set/debugging-a-statefulset			/docs/tasks/debug-application-cluster/debug-stateful-set		301
+/docs/tasks/manage-stateful-set/deleting-a-statefulset			/docs/tasks/run-application/delete-stateful-set		301
+/docs/tasks/manage-stateful-set/scale-stateful-set				/docs/tasks/run-application/scale-stateful-set		301
+/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set	/docs/tasks/run-application/upgrade-pet-set-to-stateful-set		301
+
+/docs/tasks/run-application/podpreset							/docs/tasks/inject-data-application/podpreset		301
+/docs/tasks/troubleshoot/debug-init-containers					/docs/tasks/debug-application-cluster/debug-init-containers		301
+/docs/tasks/web-ui-dashboard									/docs/tasks/access-application-cluster/web-ui-dashboard		301
+/docs/templatedemos												/docs/home/contribute/page-templates		301
+/docs/tools/kompose/											/docs/tools/kompose/user-guide		301
+
+/docs/tutorials/clusters/multiple-schedulers					/docs/tasks/administer-cluster/configure-multiple-schedulers		301
+/docs/tutorials/connecting-apps/connecting-frontend-backend		/docs/tasks/access-application-cluster/connecting-frontend-backend		301
+/docs/tutorials/federation/set-up-cluster-federation-kubefed	/docs/tasks/federation/set-up-cluster-federation-kubefed		301
+/docs/tutorials/federation/set-up-coredns-provider-federation	/docs/tasks/federation/set-up-coredns-provider-federation		301
+/docs/tutorials/federation/set-up-placement-policies-federation	/docs/tasks/federation/set-up-placement-policies-federation		301
+/docs/tutorials/getting-started/create-cluster					/docs/tutorials/kubernetes-basics/cluster-intro		301
+/docs/tutorials/stateful-application/run-replicated-stateful-application	/docs/tasks/run-application/run-replicated-stateful-application		301
+/docs/tutorials/stateful-application/run-stateful-application	/docs/tasks/run-application/run-single-instance-stateful-application		301
+/docs/tutorials/stateless-application/expose-external-ip-address-service	/docs/tasks/access-application-cluster/service-access-application-cluster		301
+/docs/tutorials/stateless-application/run-stateless-ap-replication-controller	/docs/tasks/run-application/run-stateless-application-deployment		301
+/docs/tutorials/stateless-application/run-stateless-application-deployment	/docs/tasks/run-application/run-stateless-application-deployment		301
+
+/docs/user-guide/accessing-the-cluster							/docs/tasks/access-application-cluster/access-cluster		301
+/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/	/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases		301
+/docs/user-guide/annotations									/docs/concepts/overview/working-with-objects/annotations		301
+/docs/user-guide/application-troubleshooting					/docs/tasks/debug-application-cluster/debug-application		301
+/docs/user-guide/compute-resources								/docs/concepts/configuration/manage-compute-resources-container		301
+/docs/user-guide/config-best-practices							/docs/concepts/configuration/overview		301
+/docs/user-guide/configmap/										/docs/tasks/configure-pod-container/configmap		301
+/docs/user-guide/configuring-containers							/docs/tasks/		301
+/docs/user-guide/connecting-applications						/docs/concepts/services-networking/connect-applications-service		301
+/docs/user-guide/connecting-to-applications-port-forward		/docs/tasks/access-application-cluster/port-forward-access-application-cluster		301
+/docs/user-guide/connecting-to-applications-proxy				/docs/tasks/access-kubernetes-api/http-proxy-access-api		301
+/docs/user-guide/container-environment							/docs/concepts/containers/container-lifecycle-hooks		301
+/docs/user-guide/cron-jobs										/docs/concepts/workloads/controllers/cron-jobs		301
+/docs/user-guide/debugging-pods-and-replication-controllers		/docs/tasks/debug-application-cluster/debug-pod-replication-controller		301
+/docs/user-guide/debugging-services								/docs/tasks/debug-application-cluster/debug-service		301
+/docs/user-guide/deploying-applications							/docs/tasks/run-application/run-stateless-application-deployment		301
+/docs/user-guide/deployments									/docs/concepts/workloads/controllers/deployment		301
+/docs/user-guide/downward-api/									/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information		301
+/docs/user-guide/downward-api/volume/							/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information		301
+/docs/user-guide/environment-guide/								/docs/tasks/inject-data-application/environment-variable-expose-pod-information		301
+/docs/user-guide/federation/cluster								/docs/tasks/administer-federation/cluster		301
+/docs/user-guide/federation/configmap							/docs/tasks/administer-federation/configmap		301
+/docs/user-guide/federation/daemonsets							/docs/tasks/administer-federation/daemonset		301
+/docs/user-guide/federation/deployment							/docs/tasks/administer-federation/deployment		301
+/docs/user-guide/federation/events								/docs/tasks/administer-federation/events		301
+/docs/user-guide/federation/federated-ingress					/docs/tasks/administer-federation/ingress		301
+/docs/user-guide/federation/federated-services					/docs/tasks/federation/federation-service-discovery		301
+/docs/user-guide/federation/									/docs/concepts/cluster-administration/federation		301
+/docs/user-guide/federation/namespaces							/docs/tasks/administer-federation/namespaces		301
+/docs/user-guide/federation/replicasets							/docs/tasks/administer-federation/replicaset		301
+/docs/user-guide/federation/secrets								/docs/tasks/administer-federation/secret		301
+/docs/user-guide/garbage-collection								/docs/concepts/workloads/controllers/garbage-collection		301
+/docs/user-guide/getting-into-containers						/docs/tasks/debug-application-cluster/get-shell-running-container		301
+/docs/user-guide/gpus											/docs/tasks/manage-gpus/scheduling-gpus		301
+/docs/user-guide/horizontal-pod-autoscaling/					/docs/tasks/run-application/horizontal-pod-autoscale		301
+/docs/user-guide/horizontal-pod-autoscaling/walkthrough			/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough		301
+/docs/user-guide/identifiers									/docs/concepts/overview/working-with-objects/names		301
+/docs/user-guide/images											/docs/concepts/containers/images		301
+/docs/user-guide/												/docs/home/		301
+/docs/user-guide/ingress										/docs/concepts/services-networking/ingress		301
+/docs/user-guide/introspection-and-debugging					/docs/tasks/debug-application-cluster/debug-application-introspection		301
+/docs/user-guide/jobs											/docs/concepts/workloads/controllers/jobs-run-to-completion		301
+/docs/user-guide/jobs/expansions/								/docs/tasks/job/parallel-processing-expansion		301
+/docs/user-guide/jobs/work-queue-1/								/docs/tasks/job/coarse-parallel-processing-work-queue/		301
+/docs/user-guide/jobs/work-queue-2/								/docs/tasks/job/fine-parallel-processing-work-queue/		301
+/docs/user-guide/kubeconfig-file								/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig		301
+/docs/user-guide/labels											/docs/concepts/overview/working-with-objects/labels		301
+/docs/user-guide/liveness										/docs/tasks/configure-pod-container/configure-liveness-readiness-probes		301
+/docs/user-guide/load-balancer									/docs/tasks/access-application-cluster/create-external-load-balancer		301
+/docs/user-guide/logging/elasticsearch							/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana		301
+/docs/user-guide/logging/overview								/docs/concepts/cluster-administration/logging		301
+/docs/user-guide/logging/stackdriver							/docs/tasks/debug-application-cluster/logging-stackdriver		301
+/docs/user-guide/managing-deployments							/docs/concepts/cluster-administration/manage-deployment		301
+/docs/user-guide/monitoring										/docs/tasks/debug-application-cluster/resource-usage-monitoring		301
+/docs/user-guide/namespaces										/docs/concepts/overview/working-with-objects/namespaces		301
+/docs/user-guide/networkpolicies								/docs/concepts/services-networking/network-policies		301
+/docs/user-guide/node-selection/								/docs/concepts/configuration/assign-pod-node		301
+/docs/user-guide/persistent-volumes/							/docs/concepts/storage/persistent-volumes		301
+/docs/user-guide/persistent-volumes/walkthrough					/docs/tasks/configure-pod-container/configure-persistent-volume-storage		301
+/docs/user-guide/petset											/docs/concepts/workloads/controllers/petset		301
+/docs/user-guide/petset/bootstrapping/							/docs/concepts/workloads/controllers/petset		301
+/docs/user-guide/pod-preset/									/docs/tasks/inject-data-application/podpreset		301
+/docs/user-guide/pod-security-policy/							/docs/concepts/policy/pod-security-policy		301
+/docs/user-guide/pod-states										/docs/concepts/workloads/pods/pod-lifecycle		301
+/docs/user-guide/pod-templates									/docs/concepts/workloads/pods/pod-overview		301
+/docs/user-guide/pods/											/docs/concepts/workloads/pods/pod		301
+/docs/user-guide/pods/init-container							/docs/concepts/workloads/pods/init-containers		301
+/docs/user-guide/pods/multi-container							/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume		301
+/docs/user-guide/pods/single-container							/docs/tasks/run-application/run-stateless-application-deployment		301
+/docs/user-guide/prereqs										/docs/tasks/tools/install-kubectl		301
+/docs/user-guide/production-pods								/docs/tasks/		301
+/docs/user-guide/projected-volume/								/docs/tasks/configure-pod-container/configure-projected-volume-storage		301
+/docs/user-guide/quick-start									/docs/tasks/access-application-cluster/service-access-application-cluster		301
+/docs/user-guide/replicasets									/docs/concepts/workloads/controllers/replicaset		301
+/docs/user-guide/replication-controller/						/docs/concepts/workloads/controllers/replicationcontroller		301
+/docs/user-guide/rolling-updates								/docs/tasks/run-application/rolling-update-replication-controller		301
+/docs/user-guide/secrets/										/docs/concepts/configuration/secret		301
+/docs/user-guide/secrets/walkthrough							/docs/tasks/inject-data-application/distribute-credentials-secure		301
+/docs/user-guide/service-accounts								/docs/tasks/configure-pod-container/configure-service-account		301
+/docs/user-guide/services-firewalls								/docs/tasks/access-application-cluster/configure-cloud-provider-firewall		301
+/docs/user-guide/services/										/docs/concepts/services-networking/service		301
+/docs/user-guide/services/operations							/docs/tasks/access-application-cluster/connecting-frontend-backend		301
+/docs/user-guide/sharing-clusters								/docs/tasks/administer-cluster/share-configuration		301
+/docs/user-guide/simple-nginx									/docs/tasks/run-application/run-stateless-application-deployment		301
+/docs/user-guide/thirdpartyresources							/docs/tasks/access-kubernetes-api/extend-api-third-party-resource		301
+/docs/user-guide/ui												/docs/tasks/access-application-cluster/web-ui-dashboard		301
+/docs/user-guide/update-demo/									/docs/tasks/run-application/rolling-update-replication-controller		301
+/docs/user-guide/volumes										/docs/concepts/storage/volumes		301
+/docs/user-guide/working-with-resources							/docs/tutorials/object-management-kubectl/object-management		301
+
+/docs/whatisk8s													/docs/concepts/overview/what-is-kubernetes		301
+
+#
+# redirects from /js/redirects.js
+#
+/resource-quota													/docs/concepts/policy/resource-quotas		301
+/horizontal-pod-autoscaler										/docs/tasks/run-application/horizontal-pod-autoscale		301
+/docs/roadmap													https://github.com/kubernetes/kubernetes/milestones/		301
+/api-ref														https://github.com/kubernetes/kubernetes/milestones/		301
+/kubernetes/third_party/swagger-ui								/docs/reference		301
+/docs/user-guide/overview										/docs/concepts/overview/what-is-kubernetes		301
+/docs/troubleshooting											/docs/tasks/debug-application-cluster/troubleshooting		301
+/docs/concepts/services-networking/networkpolicies				/docs/concepts/services-networking/network-policies		301
+/docs/getting-started-guides/meanstack							https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d		301
+/docs/samples													/docs/tutorials		301
+/v1.1															/		301
+/v1.0															/		301
+
+#
+# Redirect users with chinese language preference to /cn
+#
+#/  /cn  302  Language=zh
@@ -0,0 +1,238 @@
+---
+assignees:
+- thockin
+title: CentOS
+---
+
+* TOC
+{:toc}
+
+## 警告
+
+本文档适用于Kubernetes 1.1.0，目前已经被[废弃](https://github.com/kubernetes/kubernetes.github.io/issues/1613)。相关内容请参阅最新版[指南](/docs/getting-started-guides/kubeadm/)。
+
+## 前提条件
+
+在CentOS上部署和配置Kubernetes，您需要在集群中拥有一台机器作为master节点，并拥有至少一台运行CentOS 7系统的主机作为集群节点（node）。
+
+## 启动一个集群
+
+本文档是一篇基于CentOS系统部署和配置Kubernetes的入门指南，内容涵盖一个手工的配置，以便于您了解所有的底层软件包、服务以及端口等信息。
+
+Kubernetes由一系列服务构成，包括kube-apiserver、kube-scheduler、kube-controller-manager、kubelet以及kube-proxy等。这些服务由systemd管理，配置集中位于/etc/kubernetes。我们将在集群中的不同主机上部署不同的服务。其中，第一台主机，即centos-master，将被部署成为Kubernetes集群中的master节点。这台主机上将运行kube-apiserver、kube-controller-manager和kube-scheduler。 此外，master节点还将运行 _etcd_。集群中剩余的主机，即centos-minion-n节点，将运行kubelet、proxy、cadvisor和docker。
+
+集群中的所有节点将运行flanneld来构建网络（networking overlay）。
+
+**系统信息：**
+
+主机：
+
+请使用您真实环境中的信息替换以下配置中的各个主机IP
+
+```conf
+centos-master = 192.168.121.9
+centos-minion-1 = 192.168.121.65
+centos-minion-2 = 192.168.121.66
+centos-minion-3 = 192.168.121.67
+```
+
+**配置主机环境：**
+
+* 在集群所有节点上——centos-{master,minion-n}，创建包含以下配置信息的/etc/yum.repos.d/virt7-docker-common-release.repo文件。
+
+```conf
+[virt7-docker-common-release]
+name=virt7-docker-common-release
+baseurl=http://cbs.centos.org/repos/virt7-docker-common-release/x86_64/os/
+gpgcheck=0
+```
+
+* 在集群所有节点上——centos-{master,minion-n}，安装Kubernetes、etcd和flanneld。这一过程也将同时在节点上安装docker和cadvisor。
+
+```shell
+yum -y install --enablerepo=virt7-docker-common-release kubernetes etcd flannel
+```
+
+* 将master节点和其他节点的主机名——IP映射添加到所有集群节点的/etc/hosts文件中（如果主机名已经在DNS中记录，则可略过此步）
+
+```shell
+echo "192.168.121.9    centos-master
+192.168.121.65    centos-minion-1
+192.168.121.66  centos-minion-2
+192.168.121.67  centos-minion-3" >> /etc/hosts
+```
+
+* 编辑/etc/kubernetes/config文件以保证在集群所有主机上都包含以下内容：
+
+```shell
+# logging to stderr意为从systemd journal获取日志
+KUBE_LOGTOSTDERR="--logtostderr=true"
+
+# journal消息级别, 0代表debug
+KUBE_LOG_LEVEL="--v=0"
+
+# 是否允许集群运行privileged docker containers
+KUBE_ALLOW_PRIV="--allow-privileged=false"
+
+# 配置replication conrtoller和scheduler所需的kube-apiserver地址
+KUBE_MASTER="--master=http://centos-master:8080"
+```
+
+* 由于docker与一些防火墙规则不兼容，需要在master节点及其他集群节点上禁用防火墙。在CentOS系统上，需要首先禁用SELinux，进而才能禁用防火墙。
+
+```shell
+setenforce 0
+systemctl disable iptables-services firewalld
+systemctl stop iptables-services firewalld
+```
+
+**配置master节点上的Kubernetes服务**
+
+* 编辑/etc/etcd/etcd.conf文件内容如下：
+
+```shell
+# [member]
+ETCD_NAME=default
+ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
+ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
+
+#[cluster]
+ETCD_ADVERTISE_CLIENT_URLS="http://0.0.0.0:2379"
+```
+
+* 编辑/etc/kubernetes/apiserver文件内容如下：
+
+```shell
+# 本地服务器监听地址
+KUBE_API_ADDRESS="--address=0.0.0.0"
+
+# 本地服务器监听端口
+KUBE_API_PORT="--port=8080"
+
+# Kubelet监听端口
+KUBELET_PORT="--kubelet-port=10250"
+
+# 以逗号间隔的etcd集群中各个节点的地址
+KUBE_ETCD_SERVERS="--etcd-servers=http://centos-master:2379"
+
+# Kubernetes服务IP地址网段
+KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
+
+# 请添加您需要的Kubernetes API Server启动参数
+KUBE_API_ARGS=""
+```
+
+* 启动ETCD并保存master节点的网络设置（network overlay configuration）：
+**警告** 请根据您的真实环境配置网络信息！在本文环境中，`172.30.0.0/16`网段是可用的。
+
+```shell
+systemctl start etcd
+etcdctl mkdir /kube-centos/network
+etcdctl mk /kube-centos/network/config "{ \"Network\": \"172.30.0.0/16\", \"SubnetLen\": 24, \"Backend\": { \"Type\": \"vxlan\" } }"
+```
+
+* 在master节点上配置/etc/sysconfig/flanneld文件使用flannel覆盖Docker网络 (需要在其他集群节点上完成相同配置，详见下文):
+
+```shell
+# Flanneld配置选项
+
+# etcd url地址，指向运行etcd的服务器
+FLANNEL_ETCD_ENDPOINTS="http://centos-master:2379"
+
+# etcd配置秘钥，即flannel查询的配置秘钥
+# 用于网段分配
+FLANNEL_ETCD_PREFIX="/kube-centos/network"
+
+# 其它需要的Flannel启动参数
+#FLANNEL_OPTIONS=""
+```
+
+* 在master节点上启动相关服务：
+
+```shell
+for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler flanneld; do
+    systemctl restart $SERVICES
+    systemctl enable $SERVICES
+    systemctl status $SERVICES
+done
+```
+
+**在集群其他节点上配置Kubernetes服务**
+
+***我们需要在集群其他节点上配置kubelet，启动kubelet和proxy服务***
+
+* 编辑/etc/kubernetes/kubelet文件内容如下：
+
+```shell
+# info server的服务地址
+KUBELET_ADDRESS="--address=0.0.0.0"
+
+# info server的监听端口
+KUBELET_PORT="--port=10250"
+
+# 本字段可以设置空值以使用真实的主机名
+# 注意节点序号（n）
+KUBELET_HOSTNAME="--hostname-override=centos-minion-n"
+
+# api-server地址
+KUBELET_API_SERVER="--api-servers=http://centos-master:8080"
+
+# 添加您所需要的Kubelet参数
+KUBELET_ARGS=""
+```
+
+* 在所有节点上配置/etc/sysconfig/flanneld文件设置使用flannel覆盖Docker网络：
+
+```shell
+# Flanneld配置选项
+
+# etcd url地址，指向运行etcd的服务器
+FLANNEL_ETCD_ENDPOINTS="http://centos-master:2379"
+
+# etcd配置秘钥，即flannel查询的配置秘钥
+# 用于网段分配
+FLANNEL_ETCD_PREFIX="/kube-centos/network"
+
+# 其他需要配置的选项
+#FLANNEL_OPTIONS=""
+```
+
+* 在节点上启动相关服务（centos-minion-n）
+
+```shell
+for SERVICES in kube-proxy kubelet flanneld docker; do
+    systemctl restart $SERVICES
+    systemctl enable $SERVICES
+    systemctl status $SERVICES
+done
+```
+* 配置kubectl
+
+```shell
+kubectl config set-cluster default-cluster --server=http://centos-master:8080
+kubectl config set-context default-context --cluster=default-cluster --user=default-admin
+kubectl config use-context default-context
+```
+
+*至此，Kubernetes在CentOS集群中的部署已经完成 ！*
+
+* 在centos-master节点上通过kubectl命令检查所有的Kubernetes节点已经到位
+
+```shell
+$ kubectl get nodes
+NAME                   STATUS     AGE     VERSION
+centos-minion-1        Ready      3d      v1.6.0+fff5156
+centos-minion-2        Ready      3d      v1.6.0+fff5156   
+centos-minion-3        Ready      3d      v1.6.0+fff5156
+```
+
+**现在，Kubernetes集群已经正常运行！可以创建测试pod验证集群了！**
+
+## 支持级别
+
+
+IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
+-------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
+Bare-metal           | custom       | CentOS | flannel     | [docs](/docs/getting-started-guides/centos/centos_manual_config)            |          | Community ([@coolsvap](https://github.com/coolsvap))
+
+有关所有解决方案的支持级别信息，请参阅[解决方案列表](/docs/getting-started-guides/#table-of-solutions)。
@@ -0,0 +1,708 @@
+---
+assignees:
+- erictune
+- thockin
+title: Offline
+---
+
+本文档介绍了如何在CoreOS系统上部署Kubernetes。主要针对需要在离线环境下部署的场景，无论您是真实部署前的POC测试还是由于应用程序受限必须在离线环境中使用，本文档都是适用的。
+
+* TOC
+{:toc}
+
+
+## 前提条件
+
+1. 安装了 *CentOS 6* 系统的PXE服务器
+2. 集群中需要至少两台物理裸机节点
+
+## 概要设计
+
+1. 管理tftp目录
+  * /tftpboot/(coreos)(centos)(RHEL)
+  * /tftpboot/pxelinux.0/(MAC) -> 链接到Linux镜像配置文件
+2. 安装时更新pxelinux链接
+3. 更新DHCP配置，添加所需要部署的主机的相关信息
+4. 创建一个etcd集群
+5. 确保集群处于离线环境[etcd discovery tool](https://discovery.etcd.io/).
+6. 安装配置CoreOS slave节点作为Kubernetes节点
+
+## 本文档定义的一些变量
+
+| Node Description              | MAC               | IP          |
+| :---------------------------- | :---------------: | :---------: |
+| CoreOS/etcd/Kubernetes Master | d0:00:67:13:0d:00 | 10.20.30.40 |
+| CoreOS Slave 1                | d0:00:67:13:0d:01 | 10.20.30.41 |
+| CoreOS Slave 2                | d0:00:67:13:0d:02 | 10.20.30.42 |
+
+
+## 设置PXELINUX CentOS
+
+请参阅[这篇指南](http://docs.fedoraproject.org/en-US/Fedora/7/html/Installation_Guide/ap-pxe-server.html)以了解完整的CentOS PXELINUX环境设置步骤。本节内容仅是上述指南文档的概要缩写版本。
+
+1. 安装CentOS上所需要的相关软件包
+
+```shell
+sudo yum install tftp-server dhcp syslinux
+```
+
+2. 编辑`/etc/xinetd.d/tftp`文件以启用tftp服务
+
+```conf
+disable = no
+```
+
+3. 拷贝所需的syslinux镜像文件
+
+```shell
+su -
+mkdir -p /tftpboot
+cd /tftpboot
+cp /usr/share/syslinux/pxelinux.0 /tftpboot
+cp /usr/share/syslinux/menu.c32 /tftpboot
+cp /usr/share/syslinux/memdisk /tftpboot
+cp /usr/share/syslinux/mboot.c32 /tftpboot
+cp /usr/share/syslinux/chain.c32 /tftpboot
+
+/sbin/service dhcpd start
+/sbin/service xinetd start
+/sbin/chkconfig tftp on
+```
+
+4. 设置默认引导菜单
+
+```shell
+mkdir /tftpboot/pxelinux.cfg
+touch /tftpboot/pxelinux.cfg/default
+```
+
+5. 编辑默认引导菜单`/tftpboot/pxelinux.cfg/default`
+
+```conf
+default menu.c32
+prompt 0
+timeout 15
+ONTIMEOUT local
+display boot.msg
+
+MENU TITLE Main Menu
+
+LABEL local
+        MENU LABEL Boot local hard drive
+        LOCALBOOT 0
+```
+
+至此，您应当已经配置好一个可用的PXELINUX环境用来运行CoreOS节点了，您可以通过在本地运行VirtualBox或者物理裸机来验证这一点。
+
+## 添加CoreOS至PXE
+
+本节将介绍如何在一个现有的PXELINUX环境上设置CoreOS镜像。
+
+1. 查找或者创建TFTP根目录，后续所有步骤都将基于此目录。
+    * 本文中我们假设`/tftpboot`是根目录。
+2. tftp根目录准备好后，我们将为CoreOS镜像创建一个新的目录结构。
+3. 下载由CoreOS团队提供的CoreOS PXE相关文件。
+
+```shell
+MY_TFTPROOT_DIR=/tftpboot
+mkdir -p $MY_TFTPROOT_DIR/images/coreos/
+cd $MY_TFTPROOT_DIR/images/coreos/
+wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz
+wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz.sig
+wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz
+wget http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz.sig
+gpg --verify coreos_production_pxe.vmlinuz.sig
+gpg --verify coreos_production_pxe_image.cpio.gz.sig
+```
+
+4. 再次编辑菜单`/tftpboot/pxelinux.cfg/default`
+
+```conf
+default menu.c32
+prompt 0
+timeout 300
+ONTIMEOUT local
+display boot.msg
+
+MENU TITLE Main Menu
+
+LABEL local
+        MENU LABEL Boot local hard drive
+        LOCALBOOT 0
+
+MENU BEGIN CoreOS Menu
+
+    LABEL coreos-master
+        MENU LABEL CoreOS Master
+        KERNEL images/coreos/coreos_production_pxe.vmlinuz
+        APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<xxx.xxx.xxx.xxx>/pxe-cloud-config-single-master.yml
+
+    LABEL coreos-slave
+        MENU LABEL CoreOS Slave
+        KERNEL images/coreos/coreos_production_pxe.vmlinuz
+        APPEND initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<xxx.xxx.xxx.xxx>/pxe-cloud-config-slave.yml
+MENU END
+```
+
+此文件配置了系统将从本地磁盘引导，但添加了从PXE CoreOS镜像引导的选项。
+
+## DHCP配置
+
+本节将介绍如何配置DHCP服务器分发新的镜像。这里我们假设集群中有其他的服务器需要从不同的CoreOS镜像引导。
+
+1. 添加`filename`字段到 _host_ 或者 _subnet_ 部分。
+
+```conf
+filename "/tftpboot/pxelinux.0";
+```
+
+2. 现在，我们可以创建pxelinux配置文件，这些配置将来也可以作为其他不同CoreOS部署的模版。
+
+```conf
+subnet 10.20.30.0 netmask 255.255.255.0 {
+        next-server 10.20.30.242;
+        option broadcast-address 10.20.30.255;
+        filename "<other default image>";
+
+        ...
+        # http://www.syslinux.org/wiki/index.php/PXELINUX
+        host core_os_master {
+                hardware ethernet d0:00:67:13:0d:00;
+                option routers 10.20.30.1;
+                fixed-address 10.20.30.40;
+                option domain-name-servers 10.20.30.242;
+                filename "/pxelinux.0";
+        }
+        host core_os_slave {
+                hardware ethernet d0:00:67:13:0d:01;
+                option routers 10.20.30.1;
+                fixed-address 10.20.30.41;
+                option domain-name-servers 10.20.30.242;
+                filename "/pxelinux.0";
+        }
+        host core_os_slave2 {
+                hardware ethernet d0:00:67:13:0d:02;
+                option routers 10.20.30.1;
+                fixed-address 10.20.30.42;
+                option domain-name-servers 10.20.30.242;
+                filename "/pxelinux.0";
+        }
+        ...
+}
+```
+
+稍后我们将介绍节点的配置。
+
+## Kubernetes
+
+部署以上配置前，需要首先创建一个`etcd`主节点(master)。为了做到这一点，我们需要使用一个特殊的cloud-config.yaml来pxe CoreOS，可以有两种方式：
+1. 第一种方式是将云配置文件模版化，然后通过编程的方式为不同的集群提供不同的配置。
+2. 第二种方式是运行一个服务发现协议从而可以在云环境中做服务的自动发现。
+
+在本demo中，我们仅简单地创建一个静态的单一`etcd`服务器来运行Kubernetes并提供`etcd`的主要服务。
+
+由于我们的集群处于一个离线的环境中，所以大部分的CoreOS和Kubernetes帮助进程是受限的。为了完成部署，我们需要下载Kubernetes的各种可执行文件到本地然后再启动运行。
+
+一种简单的方案是在DHCP/TFTP主机上搭建一个简易的web服务器，从而环境中的CoreOS PXE机器可以从其上下载各种可执行文件。
+
+为了达到这一目标，我们将启动一个`apache`服务器并提供运行Kuberetes所需要的各种可执行文件。
+
+以下脚本运行在上文中准备好的PXE服务器上：
+
+```shell
+rm /etc/httpd/conf.d/welcome.conf
+cd /var/www/html/
+wget -O kube-register  https://github.com/kelseyhightower/kube-register/releases/download/v0.0.2/kube-register-0.0.2-linux-amd64
+wget -O setup-network-environment https://github.com/kelseyhightower/setup-network-environment/releases/download/v1.0.0/setup-network-environment
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubernetes
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-apiserver
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-controller-manager
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-scheduler
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubectl
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubecfg
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kubelet
+wget https://storage.googleapis.com/kubernetes-release/release/v0.15.0/bin/linux/amd64/kube-proxy
+wget -O flanneld https://storage.googleapis.com/k8s/flanneld
+```
+
+以上脚本将准备好运行Kubernetes所需的所有可执行文件。未来这些文件将可通过互联网直接进行更新。
+
+现在可以开始准备部署了！
+
+## 云平台配置
+
+以下Kubernetes离线版本部署配置文件经过了一定的裁减。
+
+以下内容基于配置文件: [master.yml](/docs/getting-started-guides/coreos/cloud-configs/master.yaml), 以及[node.yml](/docs/getting-started-guides/coreos/cloud-configs/node.yaml)
+
+将文件中的一些占位字段做如下修改：
+
+ - 使用您的PXE服务器的ip地址替换文件中的`<PXE_SERVER_IP>` (例如10.20.30.242)
+ - 使用Kubernetes master节点的ip地址替换文件中的`<MASTER_SERVER_IP>` (例如10.20.30.40)
+ - 如果您使用私有docker镜像仓库，请使用您的镜像仓库DNS名字替换文件中的`rdocker.example.com`
+ - 如果您使用代理，请用代理服务器地址（包含端口）替换文件中的`rproxy.example.com`
+ - 在配置文件最后添加您的SSH公钥
+
+### master.yml
+
+在PXE服务器上创建并编辑文件`/var/www/html/coreos/pxe-cloud-config-master.yml`。
+
+```yaml
+#cloud-config
+---
+write_files:
+  - path: /opt/bin/waiter.sh
+    owner: root
+    content: |
+      #! /usr/bin/bash
+      until curl http://127.0.0.1:4001/v2/machines; do sleep 2; done
+  - path: /opt/bin/kubernetes-download.sh
+    owner: root
+    permissions: 0755
+    content: |
+      #! /usr/bin/bash
+      /usr/bin/wget -N -P "/opt/bin" "http://<PXE_SERVER_IP>/kubectl"
+      /usr/bin/wget -N -P "/opt/bin" "http://<PXE_SERVER_IP>/kubernetes"
+      /usr/bin/wget -N -P "/opt/bin" "http://<PXE_SERVER_IP>/kubecfg"
+      chmod +x /opt/bin/*
+  - path: /etc/profile.d/opt-path.sh
+    owner: root
+    permissions: 0755
+    content: |
+      #! /usr/bin/bash
+      PATH=$PATH/opt/bin
+coreos:
+  units:
+    - name: 10-eno1.network
+      runtime: true
+      content: |
+        [Match]
+        Name=eno1
+        [Network]
+        DHCP=yes
+    - name: 20-nodhcp.network
+      runtime: true
+      content: |
+        [Match]
+        Name=en*
+        [Network]
+        DHCP=none
+    - name: get-kube-tools.service
+      runtime: true
+      command: start
+      content: |
+        [Service]
+        ExecStartPre=-/usr/bin/mkdir -p /opt/bin
+        ExecStart=/opt/bin/kubernetes-download.sh
+        RemainAfterExit=yes
+        Type=oneshot
+    - name: setup-network-environment.service
+      command: start
+      content: |
+        [Unit]
+        Description=Setup Network Environment
+        Documentation=https://github.com/kelseyhightower/setup-network-environment
+        Requires=network-online.target
+        After=network-online.target
+        [Service]
+        ExecStartPre=-/usr/bin/mkdir -p /opt/bin
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/setup-network-environment
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/setup-network-environment
+        ExecStart=/opt/bin/setup-network-environment
+        RemainAfterExit=yes
+        Type=oneshot
+    - name: etcd.service
+      command: start
+      content: |
+        [Unit]
+        Description=etcd
+        Requires=setup-network-environment.service
+        After=setup-network-environment.service
+        [Service]
+        EnvironmentFile=/etc/network-environment
+        User=etcd
+        PermissionsStartOnly=true
+        ExecStart=/usr/bin/etcd \
+        --name ${DEFAULT_IPV4} \
+        --addr ${DEFAULT_IPV4}:4001 \
+        --bind-addr 0.0.0.0 \
+        --cluster-active-size 1 \
+        --data-dir /var/lib/etcd \
+        --http-read-timeout 86400 \
+        --peer-addr ${DEFAULT_IPV4}:7001 \
+        --snapshot true
+        Restart=always
+        RestartSec=10s
+    - name: fleet.socket
+      command: start
+      content: |
+        [Socket]
+        ListenStream=/var/run/fleet.sock
+    - name: fleet.service
+      command: start
+      content: |
+        [Unit]
+        Description=fleet daemon
+        Wants=etcd.service
+        After=etcd.service
+        Wants=fleet.socket
+        After=fleet.socket
+        [Service]
+        Environment="FLEET_ETCD_SERVERS=http://127.0.0.1:4001"
+        Environment="FLEET_METADATA=role=master"
+        ExecStart=/usr/bin/fleetd
+        Restart=always
+        RestartSec=10s
+    - name: etcd-waiter.service
+      command: start
+      content: |
+        [Unit]
+        Description=etcd waiter
+        Wants=network-online.target
+        Wants=etcd.service
+        After=etcd.service
+        After=network-online.target
+        Before=flannel.service
+        Before=setup-network-environment.service
+        [Service]
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/waiter.sh
+        ExecStart=/usr/bin/bash /opt/bin/waiter.sh
+        RemainAfterExit=true
+        Type=oneshot
+    - name: flannel.service
+      command: start
+      content: |
+        [Unit]
+        Wants=etcd-waiter.service
+        After=etcd-waiter.service
+        Requires=etcd.service
+        After=etcd.service
+        After=network-online.target
+        Wants=network-online.target
+        Description=flannel is an etcd backed overlay network for containers
+        [Service]
+        Type=notify
+        ExecStartPre=-/usr/bin/mkdir -p /opt/bin
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/flanneld
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/flanneld
+        ExecStartPre=-/usr/bin/etcdctl mk /coreos.com/network/config '{"Network":"10.100.0.0/16", "Backend": {"Type": "vxlan"}}'
+        ExecStart=/opt/bin/flanneld
+    - name: kube-apiserver.service
+      command: start
+      content: |
+        [Unit]
+        Description=Kubernetes API Server
+        Documentation=https://github.com/kubernetes/kubernetes
+        Requires=etcd.service
+        After=etcd.service
+        [Service]
+        ExecStartPre=-/usr/bin/mkdir -p /opt/bin
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-apiserver
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-apiserver
+        ExecStart=/opt/bin/kube-apiserver \
+        --address=0.0.0.0 \
+        --port=8080 \
+        --service-cluster-ip-range=10.100.0.0/16 \
+        --etcd-servers=http://127.0.0.1:4001 \
+        --logtostderr=true
+        Restart=always
+        RestartSec=10
+    - name: kube-controller-manager.service
+      command: start
+      content: |
+        [Unit]
+        Description=Kubernetes Controller Manager
+        Documentation=https://github.com/kubernetes/kubernetes
+        Requires=kube-apiserver.service
+        After=kube-apiserver.service
+        [Service]
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-controller-manager
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-controller-manager
+        ExecStart=/opt/bin/kube-controller-manager \
+        --master=127.0.0.1:8080 \
+        --logtostderr=true
+        Restart=always
+        RestartSec=10
+    - name: kube-scheduler.service
+      command: start
+      content: |
+        [Unit]
+        Description=Kubernetes Scheduler
+        Documentation=https://github.com/kubernetes/kubernetes
+        Requires=kube-apiserver.service
+        After=kube-apiserver.service
+        [Service]
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-scheduler
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-scheduler
+        ExecStart=/opt/bin/kube-scheduler --master=127.0.0.1:8080
+        Restart=always
+        RestartSec=10
+    - name: kube-register.service
+      command: start
+      content: |
+        [Unit]
+        Description=Kubernetes Registration Service
+        Documentation=https://github.com/kelseyhightower/kube-register
+        Requires=kube-apiserver.service
+        After=kube-apiserver.service
+        Requires=fleet.service
+        After=fleet.service
+        [Service]
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-register
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-register
+        ExecStart=/opt/bin/kube-register \
+        --metadata=role=node \
+        --fleet-endpoint=unix:///var/run/fleet.sock \
+        --healthz-port=10248 \
+        --api-endpoint=http://127.0.0.1:8080
+        Restart=always
+        RestartSec=10
+  update:
+    group: stable
+    reboot-strategy: off
+ssh_authorized_keys:
+  - ssh-rsa AAAAB3NzaC1yc2EAAAAD...
+```
+
+### node.yml
+
+在PXE服务器上创建并编辑文件`/var/www/html/coreos/pxe-cloud-config-slave.yml`。
+
+```yaml
+#cloud-config
+---
+write_files:
+  - path: /etc/default/docker
+    content: |
+      DOCKER_EXTRA_OPTS='--insecure-registry="rdocker.example.com:5000"'
+coreos:
+  units:
+    - name: 10-eno1.network
+      runtime: true
+      content: |
+        [Match]
+        Name=eno1
+        [Network]
+        DHCP=yes
+    - name: 20-nodhcp.network
+      runtime: true
+      content: |
+        [Match]
+        Name=en*
+        [Network]
+        DHCP=none
+    - name: etcd.service
+      mask: true
+    - name: docker.service
+      drop-ins:
+        - name: 50-insecure-registry.conf
+          content: |
+            [Service]
+            Environment="HTTP_PROXY=http://rproxy.example.com:3128/" "NO_PROXY=localhost,127.0.0.0/8,rdocker.example.com"
+    - name: fleet.service
+      command: start
+      content: |
+        [Unit]
+        Description=fleet daemon
+        Wants=fleet.socket
+        After=fleet.socket
+        [Service]
+        Environment="FLEET_ETCD_SERVERS=http://<MASTER_SERVER_IP>:4001"
+        Environment="FLEET_METADATA=role=node"
+        ExecStart=/usr/bin/fleetd
+        Restart=always
+        RestartSec=10s
+    - name: flannel.service
+      command: start
+      content: |
+        [Unit]
+        After=network-online.target
+        Wants=network-online.target
+        Description=flannel is an etcd backed overlay network for containers
+        [Service]
+        Type=notify
+        ExecStartPre=-/usr/bin/mkdir -p /opt/bin
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/flanneld
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/flanneld
+        ExecStart=/opt/bin/flanneld -etcd-endpoints http://<MASTER_SERVER_IP>:4001
+    - name: docker.service
+      command: start
+      content: |
+        [Unit]
+        After=flannel.service
+        Wants=flannel.service
+        Description=Docker Application Container Engine
+        Documentation=http://docs.docker.io
+        [Service]
+        EnvironmentFile=-/etc/default/docker
+        EnvironmentFile=/run/flannel/subnet.env
+        ExecStartPre=/bin/mount --make-rprivate /
+        ExecStart=/usr/bin/docker -d --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU} -s=overlay -H fd:// ${DOCKER_EXTRA_OPTS}
+        [Install]
+        WantedBy=multi-user.target
+    - name: setup-network-environment.service
+      command: start
+      content: |
+        [Unit]
+        Description=Setup Network Environment
+        Documentation=https://github.com/kelseyhightower/setup-network-environment
+        Requires=network-online.target
+        After=network-online.target
+        [Service]
+        ExecStartPre=-/usr/bin/mkdir -p /opt/bin
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/setup-network-environment
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/setup-network-environment
+        ExecStart=/opt/bin/setup-network-environment
+        RemainAfterExit=yes
+        Type=oneshot
+    - name: kube-proxy.service
+      command: start
+      content: |
+        [Unit]
+        Description=Kubernetes Proxy
+        Documentation=https://github.com/kubernetes/kubernetes
+        Requires=setup-network-environment.service
+        After=setup-network-environment.service
+        [Service]
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kube-proxy
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-proxy
+        ExecStart=/opt/bin/kube-proxy \
+        --etcd-servers=http://<MASTER_SERVER_IP>:4001 \
+        --logtostderr=true
+        Restart=always
+        RestartSec=10
+    - name: kube-kubelet.service
+      command: start
+      content: |
+        [Unit]
+        Description=Kubernetes Kubelet
+        Documentation=https://github.com/kubernetes/kubernetes
+        Requires=setup-network-environment.service
+        After=setup-network-environment.service
+        [Service]
+        EnvironmentFile=/etc/network-environment
+        ExecStartPre=/usr/bin/wget -N -P /opt/bin http://<PXE_SERVER_IP>/kubelet
+        ExecStartPre=/usr/bin/chmod +x /opt/bin/kubelet
+        ExecStart=/opt/bin/kubelet \
+        --address=0.0.0.0 \
+        --port=10250 \
+        --hostname-override=${DEFAULT_IPV4} \
+        --api-servers=<MASTER_SERVER_IP>:8080 \
+        --healthz-bind-address=0.0.0.0 \
+        --healthz-port=10248 \
+        --logtostderr=true
+        Restart=always
+        RestartSec=10
+  update:
+    group: stable
+    reboot-strategy: off
+ssh_authorized_keys:
+  - ssh-rsa AAAAB3NzaC1yc2EAAAAD...
+```
+
+## 创建pxelinux.cfg相关文件
+
+为 _slave_ 节点创建一个pxelinux目标文件： `vi /tftpboot/pxelinux.cfg/coreos-node-slave`
+
+```conf
+default coreos
+prompt 1
+timeout 15
+
+display boot.msg
+
+label coreos
+    menu default
+    kernel images/coreos/coreos_production_pxe.vmlinuz
+    append initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<pxe-host-ip>/coreos/pxe-cloud-config-slave.yml console=tty0 console=ttyS0 coreos.autologin=tty1 coreos.autologin=ttyS0
+```
+
+为 _master_ 节点也创建一个： `vi /tftpboot/pxelinux.cfg/coreos-node-master`
+
+```conf
+default coreos
+prompt 1
+timeout 15
+
+display boot.msg
+
+label coreos
+    menu default
+    kernel images/coreos/coreos_production_pxe.vmlinuz
+    append initrd=images/coreos/coreos_production_pxe_image.cpio.gz cloud-config-url=http://<pxe-host-ip>/coreos/pxe-cloud-config-master.yml console=tty0 console=ttyS0 coreos.autologin=tty1 coreos.autologin=ttyS0
+```
+
+## 指定pxelinux目标
+
+在上一步骤中我们已经设置了master和slave节点的目标, 我们需要将特定的主机配置为这些目标。为实现这一点，我们可以通过将指定的MAC地址配置到指定的pxelinux.cfg文件的方法来解决。
+
+参照本文开始时的MAC地址列表，可以做出下文中的修改。更多细节信息请参阅[相关文档](http://www.syslinux.org/wiki/index.php/PXELINUX).
+
+```shell
+cd /tftpboot/pxelinux.cfg
+ln -s coreos-node-master 01-d0-00-67-13-0d-00
+ln -s coreos-node-slave 01-d0-00-67-13-0d-01
+ln -s coreos-node-slave 01-d0-00-67-13-0d-02
+```
+
+重启这些服务器令这些镜像PXE化并准备开始运行容器！
+
+## 创建测试pod
+
+现在，Kubernetes已经成功部署在CoreOS上了，我们可以创建一些pod来测试部署。
+
+请参考[一个简单的nginx样例部署](/docs/user-guide/simple-nginx)来测试集群环境。
+
+更多完整的应用程序示例，请参阅[示例目录](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/)中的各种例子。
+
+## 一些用于调试的帮助命令
+
+列出etcd中的所有关键字：
+
+```shell
+etcdctl ls --recursive
+```
+
+列出所有fleet集群中的机器：
+
+```shell
+fleetctl list-machines
+```
+
+查阅master节点上各种Kubernetes服务的系统状态：
+
+```shell
+systemctl status kube-apiserver
+systemctl status kube-controller-manager
+systemctl status kube-scheduler
+systemctl status kube-register
+```
+
+查阅集群节点上各种服务的系统状态：
+
+```shell
+systemctl status kube-kubelet
+systemctl status docker.service
+```
+
+列举Kubernetes环境中的各种对象：
+
+```shell
+kubectl get pods
+kubectl get nodes
+```
+
+结束Kubernetes中的所有pod：
+
+```shell
+for i in `kubectl get pods | awk '{print $1}'`; do kubectl delete pod $i; done
+```
+
+## 支持级别
+
+
+IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
+-------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
+Bare-metal (Offline) | CoreOS       | CoreOS | flannel     | [docs](/docs/getting-started-guides/coreos/bare_metal_offline)              |          | Community ([@jeffbean](https://github.com/jeffbean))
+
+有关所有解决方案的支持级别信息，请参阅[解决方案列表](/docs/getting-started-guides/#table-of-solutions)。
@@ -0,0 +1,19 @@
+.caution, .note, .warning {
+    padding: 20px;
+    margin: 20px 0;
+    border: 1px solid #eee;
+    border-left-width: 5px;
+    border-radius: 3px;
+}
+
+.caution {
+    border-left-color: #f0ad4e;
+}
+
+.note {
+    border-left-color: #428bca;
+}
+
+.warning {
+    border-left-color: #d9534f;
+}
@@ -232,7 +232,8 @@ See the [InitialResouces proposal](https://git.k8s.io/community/contributors/des
 ### NamespaceLifecycle

 This plug-in enforces that a `Namespace` that is undergoing termination cannot have new objects created in it,
-and ensures that requests in a non-existent `Namespace` are rejected.
+and ensures that requests in a non-existent `Namespace` are rejected. This plug-in also prevents deletion of
+three system reserved namespaces `default`, `kube-system`, `kube-public`.

 A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that
 namespace.  In order to enforce integrity of that process, we strongly recommend running this plug-in.
@@ -447,8 +447,8 @@ The request body will be of the following format:
 }
 ```

-The remote service is expected to fill the `TokenAccessReviewStatus` field of
-the request to indicate the success of the login. The response body's "spec"
+The remote service is expected to fill the `status` field of
+the request to indicate the success of the login. The response body's `spec`
 field is ignored and may be omitted. A successful validation of the bearer
 token would return:

@@ -86,9 +86,9 @@ An example request body:
 }
 ```

-The remote service is expected to fill the SubjectAccessReviewStatus field of
+The remote service is expected to fill the `status` field of
 the request and respond to either allow or disallow access. The response body's
-"spec" field is ignored and may be omitted. A permissive response would return:
+`spec` field is ignored and may be omitted. A permissive response would return:

 ```json
 {
@@ -3,7 +3,7 @@ assignees:
 - smarterclayton
 - lavalamp
 - whitlockjc
- caesrxuchao
+- caesarxuchao
 title: Dynamic Admission Control
 ---

@@ -41,7 +41,7 @@ This page describes how to use Initializers and External Admission Webhooks.

 Once the controller has performed its assigned task, it removes its name from
 the list. For example, it may send a PATCH that inserts a container in a pod and
-also removes its name from `metadata.initializers`. Initializers may make
+also removes its name from `metadata.initializers.pending`. Initializers may make
 mutations to objects.

 Objects which have a non-empty initializer list are considered uninitialized,
@@ -64,7 +64,7 @@ external admission webhooks, as they have better performance.
 When an object is POSTed, it is checked against all existing
 `initializerConfiguration` objects (explained below). For all that it matches,
 all `spec.initializers[].name`s are appended to the new object's
-`metadata.initializers` field.
+`metadata.initializers.pending` field.

 An initializer controller should list and watch for uninitialized objects, by
 using the query parameter `?includeUninitialized=true`. If using client-go, just
@@ -73,7 +73,7 @@ set
 to true.

 For the observed uninitialized objects, an initializer controller should first
-check if its name matches `metadata.initializers[0]`. If so, it should then
+check if its name matches `metadata.initializers.pending[0]`. If so, it should then
 perform its assigned task and remove its name from the list.

 ### Enable initializers alpha feature
@@ -81,7 +81,7 @@ perform its assigned task and remove its name from the list.
 *Initializers* is an alpha feature, so it is disabled by default. To turn it on,
 you need to:

-* Include "Initializer" in the `--admission-control` flag when starting
+* Include "Initializers" in the `--admission-control` flag when starting
  `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should
  have the same flag setting.

@@ -99,13 +99,13 @@ API](/docs/api-reference/{{page.version}}/#deployment-v1beta1-apps).
 ### Configure initializers on the fly

 You can configure what initializers are enabled and what resources are subject
-to the initializers by creating `initializerconfigurations`.
+to the initializers by creating `initializerConfiguration` resources.

 You should first deploy the initializer controller and make sure that it is
-working properly before creating the `initializerconfigurations`. Otherwise, any
+working properly before creating the `initializerConfiguration`. Otherwise, any
 newly created resources will be stuck in an uninitialized state.

-The following is an example `initiallizerConfiguration`.
+The following is an example `initializerConfiguration`:

 ```yaml
 apiVersion: admissionregistration.k8s.io/v1alpha1
@@ -126,12 +126,16 @@ initializers:
          - pods
 ```

+After you create the `initializerConfiguration`, the system will take a few
+seconds to honor the new configuration. Then, `"podimage.example.com"` will be
+appended to the `metadata.initializers.pending` field of newly created pods. You
+should already have a ready "podimage" initializer controller that handles pods
+whose `metadata.initializers.pending[0].name="podimage.example.com"`. Otherwise
+the pods will stuck uninitialized.
+
 Make sure that all expansions of the `<apiGroup, apiVersions, resources>` tuple
 in a `rule` are valid. If they are not, separate them in different `rules`.

-After you create the `initializerConfiguration`, the system will take a few
-seconds to honor the new configuration.
-
 ## External Admission Webhooks

 ### What are external admission webhooks?
@@ -232,7 +236,7 @@ it is working properly before creating the externaladmissionhookconfigurations.
 Otherwise, depending whether the webhook is configured as fail open or fail
 closed, operations will be unconditionally accepted or rejected. 

-The following is an example externaladmissionhookconfiguration.
+The following is an example `externaladmissionhookconfiguration`:

 ```yaml
 apiVersion: admissionregistration.k8s.io/v1alpha1
@@ -17,11 +17,19 @@ and progress on the feature is being tracked as [feature #43](https://github.com

 ## kube-apiserver configuration

-You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet bootstrap-specific group.
+The API server should be configured with an [authenticator](/docs/admin/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
+
 This group will later be used in the controller-manager configuration to scope approvals in the default approval
 controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests
 (using the bootstrap token) strictly to client requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility (e.g. you could disable a particular bootstrap group's access when you are done provisioning the nodes).

+While any authentication strategy can be used for the kubelet's initial bootstrap credentials, the following two authenticators are recommended for ease of provisioning.
+
+1. [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) - __alpha__
+2. [Token authentication file](###token-authentication-file)
+
+Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario. 
+
 ### Token authentication file
 Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number
 generator (such as /dev/urandom on most modern systems). There are multiple ways you can generate a token. For example:
@@ -34,7 +42,7 @@ The token file should look like the following example, where the first three val
 name should be as depicted:

 ```
-02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
+02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"
 ```

 Add the `--token-auth-file=FILENAME` flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file.
@@ -127,20 +135,20 @@ provided by the removed auto-approval flag, of approving all CSRs by a single gr

 ```
 # REMOVED: This flag no longer works as of 1.7.
--insecure-experimental-approve-all-kubelet-csrs-for-group="kubelet-bootstrap-token"
+--insecure-experimental-approve-all-kubelet-csrs-for-group="system:bootstrappers"
 ```

 An admin would create a `ClusterRoleBinding` targeting that group.

 ```yml
-# Approve all CSRs for the group "kubelet-bootstrap-token"
+# Approve all CSRs for the group "system:bootstrappers"
 kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1beta1
 metadata:
  name: auto-approve-csrs-for-group
 subjects:
 - kind: Group
-  name: kubelet-bootstrap-token
+  name: system:bootstrappers
  apiGroup: rbac.authorization.k8s.io
 roleRef:
  kind: ClusterRole
@@ -179,10 +187,11 @@ kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --ku

 When starting the kubelet, if the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by `--kubeconfig`. The certificate and key file will be placed in the directory specified by `--cert-dir`.

-The flag to enable this bootstrapping when starting the kubelet is:
+**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:

 ```
--experimental-bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
+--require-kubeconfig
+--bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
 ```

 Additionally, in 1.7 the kubelet implements __alpha__ features for enabling rotation of both its client and/or serving certs.
@@ -63,7 +63,7 @@ persistent storage of objects.
 The main Kubernetes API server handles built-in resources like *pods* and *services*,
 and can also handle custom resources in a generic way through [CustomResourceDefinitions](#customresourcedefinitions).

-The [aggregation layer](/docs/concepts/api-extension/) allows you to provide specialized
+The [aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) allows you to provide specialized
 implementations for your custom resources by writing and deploying your own standalone API server.
 The main API server delegates requests to you for the custom resources that you handle,
 making them available to all of its clients.
@@ -4,11 +4,6 @@ assignees:
 - roberthbailey
 - liggitt
 title: Master-Node communication
-redirect_from:
- "/docs/admin/master-node-communication/"
- "/docs/admin/master-node-communication.html"
- "/docs/concepts/cluster-administration/master-node-communication/"
- "/docs/concepts/cluster-administration/master-node-communication.html"
 ---

 * TOC
@@ -3,11 +3,6 @@ assignees:
 - caesarxuchao
 - dchen1107
 title: Nodes
-redirect_from:
- "/docs/admin/node/"
- "/docs/admin/node.html"
- "/docs/concepts/nodes/node/"
- "/docs/concepts/nodes/node.html"
 ---

 * TOC
@@ -54,8 +49,8 @@ The `conditions` field describes the status of all `Running` nodes.
 |----------------|-------------|
 | `OutOfDisk`    | `True` if there is insufficient free space on the node for adding new pods, otherwise `False` |
 | `Ready`        | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last 40 seconds |
-| `MemoryPressure`    | `True` if node has no memory pressure, otherwise `False` |
-| `DiskPressure`    | `True` if node has no disk pressure, otherwise `False` |
+| `MemoryPressure`    | `True` if pressure exists on the node memory -- that is, if the node memory is low; otherwise `False` |
+| `DiskPressure`    | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` |

 The node condition is represented as a JSON object. For example, the following response describes a healthy node.

@@ -1,8 +1,5 @@
 ---
 title: Installing Addons
-redirect_from:
- "/docs/admin/addons/"
- "/docs/admin/addons.html"
 ---

 ## Overview
@@ -3,11 +3,6 @@ assignees:
 - davidopp
 - lavalamp
 title: Cluster Administration Overview
-redirect_from:
- "/docs/admin/"
- "/docs/admin/index.html"
- "/docs/tasks/administer-cluster/overview/"
- "/docs/tasks/administer-cluster/overview.html"
 ---

 {% capture overview %}
@@ -1,12 +1,5 @@
 ---
 title: Federation
-redirect_from:
- "/docs/user-guide/federation/"
- "/docs/user-guide/federation/index.html"
- "/docs/concepts/cluster-administration/multiple-clusters/"
- "/docs/concepts/cluster-administration/multiple-clusters.html"
- "/docs/admin/multi-cluster/"
- "/docs/admin/multi-cluster.html"
 ---

 {% capture overview %}
@@ -2,9 +2,6 @@
 assignees:
 - mikedanese
 title: Configuring kubelet Garbage Collection
-redirect_from:
- "/docs/admin/garbage-collection/"
- "/docs/admin/garbage-collection.html"
 ---

 * TOC
@@ -3,12 +3,6 @@ assignees:
 - crassirostris
 - piosz
 title: Logging Architecture
-redirect_from:
- "/docs/concepts/clusters/logging/"
- "/docs/concepts/clusters/logging.html"
-redirect_from:
- "/docs/user-guide/logging/overview/"
- "/docs/user-guide/logging/overview.html"
 ---

 Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
@@ -4,9 +4,6 @@ assignees:
 - janetkuo
 - mikedanese
 title: Managing Resources
-redirect_from:
- "/docs/user-guide/managing-deployments/"
- "/docs/user-guide/managing-deployments.html"
 ---

 You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](/docs/user-guide/configuring-containers/#configuration-in-kubernetes) and [labels](/docs/user-guide/deploying-applications/#labels).
@@ -4,9 +4,6 @@ assignees:
 - freehan
 - thockin
 title: Network Plugins
-redirect_from:
- "/docs/admin/network-plugins/"
- "/docs/admin/network-plugins.html"
 ---

 * TOC
@@ -2,9 +2,6 @@
 assignees:
 - thockin
 title: Cluster Networking
-redirect_from:
- "/docs/admin/networking/"
- "/docs/admin/networking.html"
 ---

 Kubernetes approaches networking somewhat differently than Docker does by
@@ -1,8 +1,5 @@
 ---
 title: Proxies in Kubernetes
-redirect_from:
- "/docs/user-guide/accessing-the-cluster/"
- "/docs/user-guide/accessing-the-cluster.html"
 ---

 {% capture overview %}
@@ -2,9 +2,6 @@
 assignees:
 - sttts
 title: Using Sysctls in a Kubernetes Cluster
-redirect_from:
- "/docs/admin/sysctls/"
- "/docs/admin/sysctls.html"
 ---

 * TOC
@@ -4,9 +4,6 @@ assignees:
 - kevin-wangzefeng
 - bsalamat
 title: Assigning Pods to Nodes
-redirect_from:
- "/docs/user-guide/node-selection/"
- "/docs/user-guide/node-selection/index.html"
 ---

 You can constrain a [pod](/docs/concepts/workloads/pods/pod/) to only be able to run on particular [nodes](/docs/concepts/nodes/node/) or to prefer to
@@ -142,6 +139,8 @@ If you specify multiple `nodeSelectorTerms` associated with `nodeAffinity` types

 If you specify multiple `matchExpressions` associated with `nodeSelectorTerms`, then the pod can be scheduled onto a node **only if all** `matchExpressions` can be satisfied.

+If you remove or change the label of the node where the pod is scheduled, the pod won't be removed. In other words, the affinity selection works only at the time of scheduling the pod.
+
 For more information on node affinity, see the design doc
 [here](https://git.k8s.io/community/contributors/design-proposals/nodeaffinity.md).

@@ -1,8 +1,5 @@
 ---
 title: Managing Compute Resources for Containers
-redirect_from:
- "/docs/user-guide/compute-resources/"
- "/docs/user-guide/compute-resources.html"
 ---

 {% capture overview %}
@@ -197,7 +194,7 @@ is pending with a message of this type, there are several things to try:
 - Add more nodes to the cluster.
 - Terminate unneeded Pods to make room for pending Pods.
 - Check that the Pod is not larger than all the nodes. For example, if all the
-  nodes have a capacity of `cpu: 1`, then a Pod with a limit of `cpu: 1.1` will
+  nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will
  never be scheduled.

 You can check node capacities and amounts allocated with the
@@ -241,7 +238,7 @@ the node.

 The amount of resources available to Pods is less than the node capacity, because
 system daemons use a portion of the available resources. The `allocatable` field
-[NodeStatus](/docs/resources-reference/v1.6/#nodestatus-v1-core)
+[NodeStatus](/docs/resources-reference/{{page.version}}/#nodestatus-v1-core)
 gives the amount of resources that are available to Pods. For more information, see
 [Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md).

@@ -430,9 +427,9 @@ consistency across providers and platforms.
 * Get hands-on experience
 [assigning CPU and RAM resources to a container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/).

-* [Container](/docs/api-reference/v1.6/#container-v1-core)
+* [Container](/docs/api-reference/{{page.version}}/#container-v1-core)

-* [ResourceRequirements](/docs/resources-reference/v1.6/#resourcerequirements-v1-core)
+* [ResourceRequirements](/docs/resources-reference/{{page.version}}/#resourcerequirements-v1-core)

 {% endcapture %}

@@ -2,9 +2,6 @@
 assignees:
 - mikedanese
 title: Configuration Best Practices
-redirect_from:
- "/docs/user-guide/config-best-practices/"
- "/docs/user-guide/config-best-practices.html"
 ---

 {% capture overview %}
@@ -2,9 +2,6 @@
 assignees:
 - mikedanese
 title: Secrets
-redirect_from:
- "/docs/user-guide/secrets/index/"
- "/docs/user-guide/secrets/index.html"
 ---

 Objects of type `secret` are intended to hold sensitive information, such as
@@ -769,6 +766,40 @@ it to read a file.

 <!-- TODO: explain how to do this while still using automation. -->

+## Best practices
+
+### Clients that use the secrets API
+
+When deploying applications that interact with the secrets API, access should be
+limited using [authorization policies](
+https://kubernetes.io/docs/admin/authorization/) such as [RBAC](
+https://kubernetes.io/docs/admin/authorization/rbac/).
+
+Secrets often hold values that span a spectrum of importance, many of which can
+cause escalations within Kubernetes (e.g. service account tokens) and to
+external systems. Even if an individual app can reason about the power of the
+secrets it expects to interact with, other apps within the same namespace can
+render those assumptions invalid.
+
+For these reasons `watch` and `list` requests for secrets within a namespace are
+extremely powerful capabilities and should be avoided, since listing secrets allows
+the clients to inspect the values if all secrets are in that namespace. The ability to
+`watch` and `list` all secrets in a cluster should be reserved for only the most
+privileged, system-level components.
+
+Applications that need to access the secrets API should perform `get` requests on
+the secrets they need. This lets administrators restrict access to all secrets
+while [white-listing access to individual instances](
+https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) that
+the app needs.
+
+For improved performance over a looping `get`, clients can design resources that
+reference a secret then `watch` the resource, re-requesting the secret when the
+reference changes. Additionally, a ["bulk watch" API](
+https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md)
+to let clients `watch` individual resources has also been proposed, and will likely
+be available in future releases of Kubernetes. 
+
 ## Security Properties

 ### Protections
@@ -3,9 +3,6 @@ assignees:
 - mikedanese
 - thockin
 title: Container Lifecycle Hooks
-redirect_from:
- "/docs/user-guide/container-environment/"
- "/docs/user-guide/container-environment.html"
 ---

 {% capture overview %}
@@ -3,9 +3,6 @@ assignees:
 - erictune
 - thockin
 title: Images
-redirect_from:
- "/docs/user-guide/images/"
- "/docs/user-guide/images.html"
 ---

 {% capture overview %}
@@ -36,7 +36,7 @@ In addition, Kubernetes contains a number of higher-level abstractions called Co

 ## Kubernetes Control Plane

-The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system to the desired state that you provided.
+The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.

 For example, when you use the Kubernetes API to create a Deployment object, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.

@@ -2,10 +2,8 @@
 assignees:
 - lavalamp
 title: Kubernetes Components
-redirect_from:
- "/docs/admin/cluster-components/"
- "/docs/admin/cluster-components.html"
 ---
+
 {% capture overview %}
 This document outlines the various binary components needed to
 deliver a functioning Kubernetes cluster.
@@ -2,9 +2,6 @@
 assignees:
 - chenopis
 title: The Kubernetes API
-redirect_from:
- "/docs/api/"
- "/docs/api.html"
 ---

 Overall API conventions are described in the [API conventions doc](https://git.k8s.io/community/contributors/devel/api-conventions.md).
@@ -3,10 +3,8 @@ assignees:
 - bgrant0607
 - mikedanese
 title: What is Kubernetes?
-redirect_from:
- "/docs/whatisk8s/"
- "/docs/whatisk8s.html"
 ---
+
 {% capture overview %}
 This page is an overview of Kubernetes.
 {% endcapture %}
@@ -1,8 +1,5 @@
 ---
 title: Annotations
-redirect_from:
- "/docs/user-guide/annotations/"
- "/docs/user-guide/annotations.html"
 ---

 {% capture overview %}
@@ -1,9 +1,5 @@
 ---
 title: Understanding Kubernetes Objects
-
-redirect_from:
- "/docs/concepts/abstractions/overview/"
- "/docs/concepts/abstractions/overview.html"
 ---

 {% capture overview %}
@@ -2,9 +2,6 @@
 assignees:
 - mikedanese
 title: Labels and Selectors
-redirect_from:
- "/docs/user-guide/labels/"
- "/docs/user-guide/labels.html"
 ---

 _Labels_ are key/value pairs that are attached to objects, such as pods.
@@ -79,7 +76,7 @@ One could filter for resources in `production` excluding `frontend` using the co

 ### _Set-based_ requirement

-_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and exists (only the key identifier). For example:
+_Set-based_ label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: `in`,`notin` and `exists` (only the key identifier). For example:

 ```
 environment in (production, qa)
@@ -3,9 +3,6 @@ assignees:
 - mikedanese
 - thockin
 title: Names
-redirect_from:
- "/docs/user-guide/identifiers/"
- "/docs/user-guide/identifiers.html"
 ---

 All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID.
@@ -4,9 +4,6 @@ assignees:
 - mikedanese
 - thockin
 title: Namespaces
-redirect_from:
- "/docs/user-guide/namespaces/"
- "/docs/user-guide/namespaces.html"
 ---

 Kubernetes supports multiple virtual clusters backed by the same physical cluster.
@@ -2,9 +2,6 @@
 assignees:
 - pweil-
 title: Pod Security Policies
-redirect_from:
- "/docs/user-guide/pod-security-policy/"
- "/docs/user-guide/pod-security-policy/index.html"
 ---

 Objects of type `PodSecurityPolicy` govern the ability
@@ -35,7 +32,6 @@ administrator to control the following:
 | The use of host ports                                         | `hostPorts`                       |
 | The use of host's PID namespace                               | `hostPID`                         |
 | The use of host's IPC namespace                               | `hostIPC`                         |
-| The use of host paths                                         | [`allowedHostPaths`](#allowed-host-paths)    |
 | The SELinux context of the container                          | [`seLinux`](#selinux)             |
 | The user ID                                                   | [`runAsUser`](#runasuser)         |
 | Configuring allowable supplemental groups                     | [`supplementalGroups`](#supplementalgroups) |
@@ -129,9 +125,6 @@ configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.
 ### Host Network
 - *HostPorts*, default `empty`. List of `HostPortRange`, defined by `min`(inclusive) and `max`(inclusive), which define the allowed host ports.
 
-### Allowed Host Paths
- - *AllowedHostPaths* is a white list of allowed host path prefixes. Empty indicates that all host paths may be used.
-
 ## Admission

 _Admission control_ with `PodSecurityPolicy` allows for control over the
@@ -206,6 +199,29 @@ following

 ## Working With RBAC

-In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to privileged containers based on user role and groups. Access to different PodSecurityPolicy objects can be controlled via authorization. To limit access to PodSecurityPolicy objects for pods created via a Deployment, ReplicaSet, etc, the [Controller Manager](/docs/admin/kube-controller-manager/) must be run against the secured API port, and must not have superuser permissions.
+In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to
+privileged containers based on user role and groups. Access to different
+PodSecurityPolicy objects can be controlled via authorization.

-PodSecurityPolicy authorization uses the union of all policies available to the user creating the pod and the service account specified on the pod. When pods are created via a Deployment, ReplicaSet, etc, it is Controller Manager that creates the pod, so if it is running against the unsecured API port, all PodSecurityPolicy objects would be allowed, and you could not effectively subdivide access. Access to given PSP policies for a user will be effective only when deploying Pods directly. For more details, see the [PodSecurityPolicy RBAC example](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md) of applying PodSecurityPolicy to control access to privileged containers based on role and groups when deploying Pods directly.
+Note that [Controller Manager](/docs/admin/kube-controller-manager/) must be run
+against [the secured API port](/docs/admin/accessing-the-api/), and must not
+have superuser permissions. Otherwise requests would bypass authentication and
+authorization modules, all PodSecurityPolicy objects would be allowed,
+and user will be able to create privileged containers.
+
+PodSecurityPolicy authorization uses the union of all policies available to the
+user creating the pod and
+[the service account specified on the pod](/docs/tasks/configure-pod-container/configure-service-account/).
+
+Access to given PSP policies for a user will be effective only when creating
+Pods directly.
+
+For pods created on behalf of a user, in most cases by Controller Manager,
+access should be given to the service account specified on the pod spec
+template. Examples of resources that create pods on behalf of a user are
+Deployments, ReplicaSets, etc.
+
+For more details, see the
+[PodSecurityPolicy RBAC example](https://git.k8s.io/examples/staging/podsecuritypolicy/rbac/README.md)
+of applying PodSecurityPolicy to control access to privileged containers based
+on role and groups when deploying Pods directly.
@@ -2,9 +2,6 @@
 assignees:
 - derekwaynecarr
 title: Resource Quotas
-redirect_from:
- "/docs/admin/resourcequota/"
- "/docs/admin/resourcequota/index.html"
 ---

 When several users or teams share a cluster with a fixed number of nodes,
@@ -3,9 +3,6 @@ assignees:
 - rickypai
 - thockin
 title: Adding entries to Pod /etc/hosts with HostAliases
-redirect_from:
- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/"
- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases.md"
 ---

 * TOC
@@ -4,9 +4,6 @@ assignees:
 - lavalamp
 - thockin
 title: Connecting Applications with Services
-redirect_from:
- "/docs/user-guide/connecting-applications/"
- "/docs/user-guide/connecting-applications.html"
 ---

 * TOC
@@ -67,7 +64,7 @@ This is equivalent to `kubectl create -f` the following yaml:

 {% include code.html language="yaml" file="nginx-svc.yaml" ghlink="/docs/concepts/services-networking/nginx-svc.yaml" %}

-This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/v1.6/#service-v1-core) to see the list of supported fields in service definition.
+This specification will create a Service which targets TCP port 80 on any Pod with the `run: my-nginx` label, and expose it on an abstracted Service port (`targetPort`: is the port the container accepts traffic on, `port`: is the abstracted Service port, which can be any port other pods use to access the Service). View [service API object](/docs/api-reference/{{page.version}}/#service-v1-core) to see the list of supported fields in service definition.
 Check your Service:

 ```shell
@@ -3,9 +3,6 @@ assignees:
 - davidopp
 - thockin
 title: DNS Pods and Services
-redirect_from:
- "/docs/admin/dns/"
- "/docs/admin/dns.html"
 ---

 ## Introduction
@@ -237,6 +234,29 @@ nameserver 10.0.0.10
 options ndots:5
 ```

+### DNS Policy
+
+By default, DNS policy for a pod is 'ClusterFirst'. So pods running with hostNetwork cannot resolve DNS names. To have DNS options set along with hostNetwork, you should specify DNS policy explicitly to 'ClusterFirstWithHostNet'. Update the busybox.yaml as following:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: busybox
+  namespace: default
+spec:
+  containers:
+  - image: busybox
+    command:
+      - sleep
+      - "3600"
+    imagePullPolicy: IfNotPresent
+    name: busybox
+  restartPolicy: Always
+  hostNetwork: true
+  dnsPolicy: ClusterFirstWithHostNet
+```
+
 #### Quick diagnosis

 Errors such as the following indicate a problem with the kube-dns add-on or associated Services:
@@ -285,7 +305,7 @@ Use `kubectl logs` command to see logs for the DNS daemons.
 ```
 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 healthz
+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. W, E, F letter 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.
@@ -2,9 +2,6 @@
 assignees:
 - bprashanth
 title: Ingress Resources
-redirect_from:
- "/docs/user-guide/ingress/"
- "/docs/user-guide/ingress.html"
 ---

 * TOC
@@ -4,9 +4,6 @@ assignees:
 - caseydavenport
 - danwinship
 title: Network Policies
-redirect_from:
- "/docs/user-guide/networkpolicies/"
- "/docs/user-guide/networkpolicies.html"
 ---

 * TOC
@@ -28,7 +25,7 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is

 ## The `NetworkPolicy` Resource

-See the [api-reference](/docs/api-reference/v1.7/#networkpolicy-v1-networking) for a full definition of the resource.
+See the [api-reference](/docs/api-reference/{{page.version}}/#networkpolicy-v1-networking) for a full definition of the resource.

 An example `NetworkPolicy` might look like this:

@@ -2,9 +2,6 @@
 assignees:
 - bprashanth
 title: Services
-redirect_from:
- "/docs/user-guide/services/"
- "/docs/user-guide/services/index.html"
 ---

 Kubernetes [`Pods`](/docs/user-guide/pods) are mortal. They are born and when they die, they
@@ -5,9 +5,6 @@ assignees:
 - saad-ali
 - thockin
 title: Persistent Volumes
-redirect_from:
- "/docs/user-guide/persistent-volumes/"
- "/docs/user-guide/persistent-volumes/index.html"
 ---

 This document describes the current state of `PersistentVolumes` in Kubernetes.  Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
@@ -5,9 +5,6 @@ assignees:
 - saad-ali
 - thockin
 title: Volumes
-redirect_from:
- "/docs/user-guide/volumes/"
- "/docs/user-guide/volumes.html"
 ---

 {% capture overview %}
@@ -42,7 +39,7 @@ A Kubernetes volume, on the other hand, has an explicit lifetime - the same as
 the pod that encloses it.  Consequently, a volume outlives any containers that run
 within the Pod, and data is preserved across Container restarts. Of course, when a
 Pod ceases to exist, the volume will cease to exist, too.  Perhaps more
-importantly than this, Kubernetes supports many type of volumes, and a Pod can
+importantly than this, Kubernetes supports many types of volumes, and a Pod can
 use any number of them simultaneously.

 At its core, a volume is just a directory, possibly with some data in it, which
@@ -4,11 +4,6 @@ assignees:
 - soltysh
 - janetkuo
 title: Cron Jobs
-redirect_from:
- "/docs/concepts/jobs/cron-jobs/"
- "/docs/concepts/jobs/cron-jobs.html"
- "/docs/user-guide/cron-jobs/"
- "/docs/user-guide/cron-jobs.html"
 ---

 * TOC
@@ -2,9 +2,6 @@
 assignees:
 - erictune
 title: Daemon Sets
-redirect_from:
- "/docs/admin/daemons/"
- "/docs/admin/daemons.html"
 ---

 * TOC
@@ -41,9 +38,7 @@ A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/dev

 The `.spec.template` is the only required field of the `.spec`.

-The `.spec.template` is a [pod template](/docs/user-guide/replication-controller/#pod-template).
-It has exactly the same schema as a [pod](/docs/user-guide/pods), except
-it is nested and does not have an `apiVersion` or `kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.

 In addition to required fields for a pod, a pod template in a DaemonSet has to specify appropriate
 labels (see [pod selector](#pod-selector)).
@@ -3,30 +3,31 @@ assignees:
 - bgrant0607
 - janetkuo
 title: Deployments
-redirect_from:
- "/docs/user-guide/deployments/"
- "/docs/user-guide/deployments.html"
 ---

-{:toc}
-
-## What is a Deployment?
+{% capture overview %}

 A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) (the next-generation ReplicationController).
-You only need to describe the desired state in a Deployment object, and the Deployment controller will
-change the actual state to the desired state at a controlled rate for you. You can define Deployments to
-create new ReplicaSets, or remove existing Deployments and adopt all of their resources with new Deployments.
+You describe the desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to
+create new ReplicaSets, or remove existing Deployments and adopt all their resources with new Deployments.

-**Note:** You should not manage ReplicaSets owned by a Deployment, otherwise you are racing with the Deployment
-controller! All of the use cases should be covered just by manipulating the Deployment object. Consider opening
-an issue in the main Kubernetes repository, if your use case is not covered below.
+**Note:** You should not manage ReplicaSets owned by a Deployment. If you do so, you are racing with the Deployment
+controller! All the use cases should be covered by manipulating the Deployment object. Consider opening
+an issue in the main Kubernetes repository if your use case is not covered below.
+
+{% endcapture %}
+
+
+{% capture body %}
+
+## Use Case

 A typical use case is:

 * [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
-* Later, [declare the new state of the Pods](#updating-a-deployment) you want to run by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old to the new ReplicaSet in a controlled rate. Each new ReplicaSet that is created, updates the revision of the Deployment.
-* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment will not be stable. Each rollback updates the revision of the Deployment.
+* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
+* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
 * [Scale up the Deployment to facilitate more load.](#scaling-a-deployment)
 * [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
 * [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck
@@ -35,7 +36,7 @@ A typical use case is:

 ## Creating a Deployment

-Here is an example Deployment. It creates a ReplicaSet to bring up 3 nginx Pods.
+Here is an example Deployment. It creates a ReplicaSet to bring up three nginx Pods.

 {% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/workloads/controllers/nginx-deployment.yaml" %}

@@ -47,7 +48,7 @@ deployment "nginx-deployment" created
 ```

 Setting the kubectl flag `--record` to `true` allows you to record current command in the annotations of
-the resources being created or updated. It will be useful for future introspection; for example, to see the
+the resources being created or updated. It is useful for future introspection: for example, to see the
 commands executed in each Deployment revision.

 Then running `get` immediately will give:
@@ -62,7 +63,7 @@ This indicates that the Deployment's number of desired replicas is 3 (according
 the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`)
 is 0, and the number of available replicas (`.status.availableReplicas`) is also 0.

-To see the Deployment rollout status, simply run:
+To see the Deployment rollout status, run:

 ```shell
 $ kubectl rollout status deployment/nginx-deployment
@@ -70,7 +71,7 @@ Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 deployment "nginx-deployment" successfully rolled out
 ```

-Running the `get` again a few seconds later, should give:
+Running the `get` again a few seconds later should give:

 ```shell
 $ kubectl get deployments
@@ -98,31 +99,30 @@ nginx-deployment-2035384211-kzszj   1/1       Running   0          18s       app
 nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
 ```

-The created ReplicaSet will ensure that there are three nginx Pods at all times.
+The created ReplicaSet ensures that there are three nginx Pods at all times.

 **Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case,
-`app = nginx`), i.e. don't overlap with other controllers (including other Deployments, ReplicaSets,
-StatefulSets, etc.). Kubernetes won't stop you from doing that, and if you end up with multiple
-controllers that have overlapping selectors, those controllers may fight with each other and won't behave
+`app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets,
+StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
+controllers have overlapping selectors, those controllers may fight with each other and won't behave
 correctly.

 ### Pod-template-hash label

-**Note:** This label is not meant to be mutated by users!
+**Note:** This label is not meant to be changed by users!

-Note the pod-template-hash label in the example output in the pod labels above. pod-template-hash is added by the
-Deployment controller in every ReplicaSet that a Deployment creates or adopts. Its purpose is so that children
-ReplicaSets of a Deployment will not overlap among them. It is computed by hashing the PodTemplate of the ReplicaSet
+Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
+Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child
+ReplicaSets of a Deployment do not overlap. It is computed by hashing the PodTemplate of the ReplicaSet
 and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels,
 and in any existing Pods that the ReplicaSet may have.

 ## Updating a Deployment

-**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`)
-is changed, e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment,
-will not trigger a rollout.
+**Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
+is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.

-Suppose that we now want to update the nginx Pods to start using the `nginx:1.9.1` image
+Suppose that we now want to update the nginx Pods to use the `nginx:1.9.1` image
 instead of the `nginx:1.7.9` image.

 ```shell
@@ -137,7 +137,7 @@ $ kubectl edit deployment/nginx-deployment
 deployment "nginx-deployment" edited
 ```

-To see its rollout status, simply run:
+To see the rollout status, run:

 ```shell
 $ kubectl rollout status deployment/nginx-deployment
@@ -247,14 +247,14 @@ It is generally discouraged to make label selector updates and it is suggested t
 In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped
 all of the implications.

-* Selector additions require the pod template labels in the Deployment spec to be updated with the new label, too,
+* Selector additions require the pod template labels in the Deployment spec to be updated with the new label too,
 otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does
 not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and
 creating a new ReplicaSet.
-* Selector updates, i.e., changing the existing value in a selector key, result in the same behavior as additions.
-* Selector removals, i.e., removing an existing key from the Deployment selector, do not require any changes in the
-pod template labels, no existing ReplicaSet is orphaned, and a new ReplicaSet will not be created, but note that the
-removed label will still exist in any existing Pods and ReplicaSets.
+* Selector updates -- that is, changing the existing value in a selector key -- result in the same behavior as additions.
+* Selector removals -- that is, removing an existing key from the Deployment selector -- do not require any changes in the
+pod template labels. No existing ReplicaSet is orphaned, and a new ReplicaSet is not created, but note that the
+removed label still exists in any existing Pods and ReplicaSets.

 ## Rolling Back a Deployment

@@ -263,11 +263,11 @@ By default, all of the Deployment's rollout history is kept in the system so tha
 (you can change that by modifyingrevision history limit]).

 **Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the
-new revision is created if and only if the Deployment's pod template (i.e. `.spec.template`) is changed,
-e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment,
-will not create a Deployment revision -- so that we can facilitate simultaneous manual- or auto-scaling.
-This implies that when you rollback to an earlier revision, only the Deployment's pod template part will
-be rolled back.
+new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,
+for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
+do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling.
+This means that when you roll back to an earlier revision, only the Deployment's pod template part is
+rolled back.

 Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:

@@ -630,7 +630,7 @@ due to some of the following factors:

 One way you can detect this condition is to specify a deadline parameter in your Deployment spec:
 ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the
-number of seconds the Deployment controller waits before indicating (via the Deployment status) that the
+number of seconds the Deployment controller waits before indicating (in the Deployment status) that the
 Deployment progress has stalled.

 The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report
@@ -780,12 +780,11 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib

 The `.spec.template` is the only required field of the `.spec`.

-The `.spec.template` is a [pod template](/docs/user-guide/replication-controller/#pod-template).  It has exactly
-the same schema as a [Pod](/docs/user-guide/pods), except it is nested and does not have an
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](docs/concepts/workloads/pods/pod/), except it is nested and does not have an
 `apiVersion` or `kind`.

 In addition to required fields for a Pod, a pod template in a Deployment must specify appropriate
-labels (i.e. don't overlap with other controllers, see [selector](#selector)) and an appropriate restart policy.
+labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).

 Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is
 allowed, which is the default if not specified.
@@ -800,19 +799,19 @@ allowed, which is the default if not specified.
 for the Pods targeted by this deployment.

 If specified, `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by
-the API.  If `.spec.selector` is unspecified, `.spec.selector.matchLabels` will be defaulted to
+the API.  If `.spec.selector` is unspecified, `.spec.selector.matchLabels` defaults to
 `.spec.template.metadata.labels`.

-Deployment may kill Pods whose labels match the selector, in the case that their template is different
-than `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It will bring up new
-Pods with `.spec.template` if number of Pods are less than the desired number.
+A Deployment may terminate Pods whose labels match the selector if their template is different
+tfrom `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It brings up new
+Pods with `.spec.template` if the number of Pods is less than the desired number.

-**Note:** You should not create other pods whose labels match this selector, either directly, via
-another Deployment or via another controller such as ReplicaSets or ReplicationControllers. Otherwise,
-the Deployment will think that those pods were created by it. Kubernetes will not stop you from doing this.
+**Note:** You should not create other pods whose labels match this selector, either directly, by creating
+another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
+do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.

 If you have multiple controllers that have overlapping selectors, the controllers will fight with each
-other's and won't behave correctly.
+other and won't behave correctly.

 ### Strategy

@@ -833,10 +832,9 @@ the rolling update process.
 ##### Max Unavailable

 `.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number
-of Pods that can be unavailable during the update process. The value can be an absolute number (e.g. 5)
-or a percentage of desired Pods (e.g. 10%). The absolute number is calculated from percentage by
-rounding down. This can not be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. By default, a
-value of 25% is used.
+of Pods that can be unavailable during the update process. The value can be an absolute number (for example, 5)
+or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by
+rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%.

 For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired
 Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled
@@ -846,12 +844,12 @@ at all times during the update is at least 70% of the desired Pods.
 ##### Max Surge

 `.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
-that can be created above the desired number of Pods. Value can be an absolute number (e.g. 5) or a
-percentage of desired Pods (e.g. 10%). This can not be 0 if `MaxUnavailable` is 0. The absolute number
-is calculated from percentage by rounding up. By default, a value of 25% is used.
+that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a
+percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number
+is calculated from the percentage by rounding up. The default value is 25%.

 For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the
-rolling update starts, such that the total number of old and new Pods do not exceed 130% of desired
+rolling update starts, such that the total number of old and new Pods does not exceed 130% of desired
 Pods. Once old Pods have been killed, the new ReplicaSet can be scaled up further, ensuring that the
 total number of Pods running at any time during the update is at most 130% of desired Pods.

@@ -917,3 +915,7 @@ it is created.
 [Kubectl rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers
 in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have
 additional features, such as rolling back to any previous revision even after the rolling update is done.
+
+{% endcapture %}
+
+{% include templates/concept.md %}
@@ -1,11 +1,5 @@
 ---
 title: Garbage Collection
-redirect_from:
- "/docs/concepts/abstractions/controllers/garbage-collection/"
- "/docs/concepts/abstractions/controllers/garbage-collection.html"
- "/docs/user-guide/garbage-collection/"
- "/docs/user-guide/garbage-collection.html"
-
 ---

 {% capture overview %}
@@ -3,11 +3,6 @@ assignees:
 - erictune
 - soltysh
 title: Jobs - Run to Completion
-redirect_from:
- "/docs/concepts/jobs/run-to-completion-finite-workloads/"
- "/docs/concepts/jobs/run-to-completion-finite-workloads.html"
- "/docs/user-guide/jobs/"
- "/docs/user-guide/jobs.html"
 ---

 * TOC
@@ -92,9 +87,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d

 The `.spec.template` is the only required field of the `.spec`.

-The `.spec.template` is a [pod template](/docs/user-guide/replication-controller/#pod-template).  It has exactly
-the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or
-`kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/user-guide/pods), except it is nested and does not have an `apiVersion` or `kind`.

 In addition to required fields for a Pod, a pod template in a job must specify appropriate
 labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
@@ -115,12 +108,12 @@ There are three main types of jobs:
  - normally only one pod is started, unless the pod fails.
  - job is complete as soon as Pod terminates successfully.
 1. Parallel Jobs with a *fixed completion count*:
-  - specify a non-zero positive value for `.spec.completions`
+  - specify a non-zero positive value for `.spec.completions`.
  - the job is complete when there is one successful pod for each value in the range 1 to `.spec.completions`.
  - **not implemented yet:** each pod passed a different index in the range 1 to `.spec.completions`.
 1. Parallel Jobs with a *work queue*:
-  - do not specify `.spec.completions`, default to `.spec.Parallelism`
-  - the pods must coordinate with themselves or an external service to determine what each should work on
+  - do not specify `.spec.completions`, default to `.spec.Parallelism`.
+  - the pods must coordinate with themselves or an external service to determine what each should work on.
  - each pod is independently capable of determining whether or not all its peers are done, thus the entire Job is done.
  - when _any_ pod terminates with success, no new pods are created.
  - once at least one pod has terminated with success and all pods are terminated, then the job is completed with success.
@@ -8,13 +8,6 @@ assignees:
 - kow3ns
 - smarterclayton
 title: PetSets
-redirect_from:
- "/docs/concepts/abstractions/controllers/petsets/"
- "/docs/concepts/abstractions/controllers/petsets.html"
- "/docs/user-guide/petset/bootstrapping/"
- "/docs/user-guide/petset/bootstrapping/index.html"
- "/docs/user-guide/petset/"
- "/docs/user-guide/petset.html"
 ---

 __Warning:__ Starting in Kubernetes version 1.5, PetSet has been renamed to [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets). To use (or continue to use) PetSet in Kubernetes 1.5, you _must_ [migrate](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/) your existing PetSets to StatefulSets. For information on working with StatefulSet, see the tutorial on [how to run replicated stateful applications](/docs/tutorials/stateful-application/run-replicated-stateful-application).
@@ -4,15 +4,9 @@ assignees:
 - bprashanth
 - madhusudancs
 title: Replica Sets
-redirect_from:
- "/docs/user-guide/replicasets/"
- "/docs/user-guide/replicasets.html"
 ---

-* TOC
-{:toc}
-
-## What is a ReplicaSet?
+{% capture overview %}

 ReplicaSet is the next-generation Replication Controller. The only difference
 between a _ReplicaSet_ and a
@@ -21,6 +15,13 @@ the selector support. ReplicaSet supports the new set-based selector requirement
 as described in the [labels user guide](/docs/user-guide/labels/#label-selectors)
 whereas a Replication Controller only supports equality-based selector requirements.

+{% endcapture %}
+
+
+{% capture body %}
+
+## How to use a ReplicaSet
+
 Most [`kubectl`](/docs/user-guide/kubectl/) commands that support
 Replication Controllers also support ReplicaSets. One exception is the
 [`rolling-update`](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) command. If
@@ -36,16 +37,16 @@ creation, deletion and updates. When you use Deployments you don't have to worry
 about managing the ReplicaSets that they create. Deployments own and manage
 their ReplicaSets.

-## When to use a ReplicaSet?
+## When to use a ReplicaSet

-A ReplicaSet ensures that a specified number of pod “replicas” are running at any given
+A ReplicaSet ensures that a specified number of pod replicas are running at any given
 time. However, a Deployment is a higher-level concept that manages ReplicaSets and
 provides declarative updates to pods along with a lot of other useful features.
 Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless
 you require custom update orchestration or don't require updates at all.

 This actually means that you may never need to manipulate ReplicaSet objects:
-use directly a Deployment and define your application in the spec section.
+use a Deployment instead, and define your application in the spec section.

 ## Example

@@ -82,8 +83,8 @@ frontend-qhloh   1/1       Running   0          1m
 ## ReplicaSet as an Horizontal Pod Autoscaler target

 A ReplicaSet can also be a target for
-[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/),
-i.e. a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
+[Horizontal Pod Autoscalers (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). That is,
+a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
 the ReplicaSet we created in the previous example.

 {% include code.html language="yaml" file="hpa-rs.yaml" ghlink="/docs/concepts/workloads/controllers/hpa-rs.yaml" %}
@@ -97,9 +98,13 @@ of the replicated pods.
 kubectl create -f hpa-rs.yaml
 ```

-Alternatively, you can just use the `kubectl autoscale` command to accomplish the same
+Alternatively, you can use the `kubectl autoscale` command to accomplish the same
 (and it's easier!)

 ```shell
 kubectl autoscale rs frontend
 ```
+
+{% endcapture %}
+
+{% include templates/concept.md %}
@@ -3,38 +3,42 @@ assignees:
 - bprashanth
 - janetkuo
 title: Replication Controller
-redirect_from:
- "/docs/user-guide/replication-controller/"
- "/docs/user-guide/replication-controller/index.html"
 ---

-* TOC
-{:toc}
+{% capture overview %}

-## What is a ReplicationController?
+NOTE: A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.

-A _ReplicationController_ ensures that a specified number of pod "replicas" are running at any one
-time. In other words, a ReplicationController makes sure that a pod or homogeneous set of pods are
+A _ReplicationController_ ensures that a specified number of pod replicas are running at any one
+time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is
 always up and available.
-If there are too many pods, it will kill some. If there are too few, the
-ReplicationController will start more. Unlike manually created pods, the pods maintained by a
-ReplicationController are automatically replaced if they fail, get deleted, or are terminated.
-For example, your pods get re-created on a node after disruptive maintenance such as a kernel upgrade.
-For this reason, we recommend that you use a ReplicationController even if your application requires
-only a single pod. You can think of a ReplicationController as something similar to a process supervisor,
-but rather than individual processes on a single node, the ReplicationController supervises multiple pods
+
+{% endcapture %}
+
+
+{% capture body %}
+
+## How a ReplicationController Works
+
+If there are too many pods, the ReplicationController terminates the extra pods. If there are too few, the
+ReplicationController starts more pods. Unlike manually created pods, the pods maintained by a
+ReplicationController are automatically replaced if they fail, are deleted, or are terminated.
+For example, your pods are re-created on a node after disruptive maintenance such as a kernel upgrade.
+For this reason, you should use a ReplicationController even if your application requires
+only a single pod. A ReplicationController is similar to a process supervisor,
+but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods
 across multiple nodes.

 ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in
 kubectl commands.

-A simple case is to create 1 ReplicationController object in order to reliably run one instance of
+A simple case is to create one ReplicationController object to reliably run one instance of
 a Pod indefinitely.  A more complex use case is to run several identical replicas of a replicated
 service, such as web servers.

 ## Running an example ReplicationController

-Here is an example ReplicationController config.  It runs 3 copies of the nginx web server.
+This example ReplicationController config runs three copies of the nginx web server.

 {% include code.html language="yaml" file="replication.yaml" ghlink="/docs/concepts/workloads/controllers/replication.yaml" %}

@@ -64,14 +68,14 @@ Events:
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-4ok8v
 ```

-Here, 3 pods have been made, but none are running yet, perhaps because the image is being pulled.
+Here, three pods are created, but none is running yet, perhaps because the image is being pulled.
 A little later, the same command may show:

 ```shell
 Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
 ```

-To list all the pods that belong to the rc in a machine readable form, you can use a command like this:
+To list all the pods that belong to the ReplicationController in a machine readable form, you can use a command like this:

 ```shell
 $ pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
@@ -96,12 +100,10 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun

 The `.spec.template` is the only required field of the `.spec`.

-The `.spec.template` is a pod template.  It has exactly
-the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or
-`kind`.
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.

 In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
-labels (i.e. don't overlap with other controllers, see [pod selector](#pod-selector)) and an appropriate restart policy.
+labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [pod selector](#pod-selector).

 Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is allowed, which is the default
 if not specified.
@@ -113,27 +115,27 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.

 The ReplicationController can itself have labels (`.metadata.labels`).  Typically, you
 would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified
-then it is defaulted to  `.spec.template.metadata.labels`.  However, they are allowed to be
+then it defaults to  `.spec.template.metadata.labels`.  However, they are allowed to be
 different, and the `.metadata.labels` do not affect the behavior of the ReplicationController.

 ### Pod Selector

-The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors).  A replication
-controller manages all the pods with labels which match the selector.  It does not distinguish
-between pods which it created or deleted versus pods which some other person or process created or
-deleted.  This allows the ReplicationController to be replaced without affecting the running pods.
+The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A ReplicationController
+manages all the pods with labels that match the selector. It does not distinguish
+between pods that it created or deleted and pods that another person or process created or
+deleted. This allows the ReplicationController to be replaced without affecting the running pods.

 If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.selector`, or it will
 be rejected by the API.  If `.spec.selector` is unspecified, it will be defaulted to
 `.spec.template.metadata.labels`.

-Also you should not normally create any pods whose labels match this selector, either directly, via
-another ReplicationController or via another controller such as Job.  Otherwise, the
-ReplicationController will think that those pods were created by it.  Kubernetes will not stop you
+Also you should not normally create any pods whose labels match this selector, either directly, with 
+another ReplicationController, or with another controller such as Job. If you do so, the
+ReplicationController thinks that it created the other pods.  Kubernetes does not stop you
 from doing this.

 If you do end up with multiple controllers that have overlapping selectors, you
-will have to manage the deletion yourself (see [below](#updating-a-replication-controller)).
+will have to manage the deletion yourself (see [below](#working-with-replicationcontrollers)).

 ### Multiple Replicas

@@ -177,7 +179,7 @@ Pods may be removed from a ReplicationController's target set by changing their

 ### Rescheduling

-As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (e.g., due to an action by another control agent).
+As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (for example, due to an action by another control agent).

 ### Scaling

@@ -211,13 +213,13 @@ A ReplicationController will never terminate on its own, but it isn't expected t

 ## Writing programs for Replication

-Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (e.g., cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself.
+Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (for example, cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself.

 ## Responsibilities of the ReplicationController

 The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.

-The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).
+The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).

 The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.

@@ -245,12 +247,12 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and

 ### Bare Pods

-Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A ReplicationController delegates local container restarts to some agent on the node (e.g., Kubelet or Docker).
+Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node.  A ReplicationController delegates local container restarts to some agent on the node (for example, Kubelet or Docker).

 ### Job

 Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for pods that are expected to terminate on their own
-(i.e. batch jobs).
+(that is, batch jobs).

 ### DaemonSet

@@ -262,3 +264,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
 ## For more information

 Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
+
+{% endcapture %}
+
+{% include templates/concept.md %}
@@ -7,9 +7,6 @@ assignees:
 - kow3ns
 - smarterclayton
 title: StatefulSets
-redirect_from:
- "/docs/concepts/abstractions/controllers/statefulsets/"
- "/docs/concepts/abstractions/controllers/statefulsets.html"
 ---

 {% capture overview %}
@@ -192,7 +189,7 @@ Pod.

 ## Update Strategies

-In Kuberentes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure 
+In Kubernetes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure
 and disable automated rolling updates for containers, labels, resource request/limits, and
 annotations for the Pods in a StatefulSet.

@@ -4,11 +4,6 @@ assignees:
 - foxish
 - davidopp
 title: Disruptions
-redirect_from:
- "/docs/admin/disruptions/"
- "/docs/admin/disruptions.html"
- "/docs/tasks/configure-pod-container/configure-pod-disruption-budget/"
- "/docs/tasks/administer-cluster/configure-pod-disruption-budget/"
 ---

 {% capture overview %}
@@ -41,7 +36,7 @@ an application.  Examples are:
 - eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource.md).

 Except for the out-of-resources condition, all these conditions
-should be familiar to most users; they are are not specific
+should be familiar to most users; they are not specific
 to Kubernetes.

 We call other cases *voluntary disruptions*.  These include both
@@ -136,7 +131,7 @@ during application updates is configured in the controller spec.
 (Learn about [updating a deployment](/docs/concepts/cluster-administration/manage-deployment/#updating-your-application-without-a-service-outage).)

 When a pod is evicted using the eviction API, it is gracefully terminated (see
-`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/v1.6/#podspec-v1-core).)
+`terminationGracePeriodSeconds` in [PodSpec](/docs/resources-reference/{{page.version}}/#podspec-v1-core).)

 ## PDB Example

@@ -188,9 +183,7 @@ At some point, the pods terminate, and the cluster look like this:

 At this point, if an impatient cluster administrator tries to drain `node-2` or
 `node-3`, the drain command will block, because there are only 2 available
-pods for the deployment, and its PDB requires at least 2.  After some time
-
-asses, `pod-d` becomes available.
+pods for the deployment, and its PDB requires at least 2.  After some time passes, `pod-d` becomes available.

 The cluster state now looks like this:

@@ -207,7 +200,7 @@ one pod available for the deployment.

 The deployment creates a replacement for `pod-b` called `pod-e`.
 However, not there are not enough resources in the cluster to schedule
-`pod-e`.  So, the drain  then the drain will block.  The cluster may end up in this
+`pod-e`.  So, the drain will again block.  The cluster may end up in this
 state:

 |    node-1 *drained*  |       node-2        |       node-3       | *no node*          |
@@ -2,11 +2,6 @@
 assignees:
 - erictune
 title: Init Containers
-redirect_from:
- "/docs/concepts/abstractions/init-containers/"
- "/docs/concepts/abstractions/init-containers.html"
- "/docs/user-guide/pods/init-container/"
- "/docs/user-guide/pods/init-container.html"
 ---

 {% capture overview %}
@@ -36,7 +31,7 @@ Init Containers are exactly like regular Containers, except:
 If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init
 Container succeeds. However, if the Pod has a `restartPolicy` of Never, it is not restarted.

-To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/v1.6/#container-v1-core) alongside the app `containers` array.
+To specify a Container as an Init Container, add the `initContainers` field on the PodSpec as a JSON array of objects of type [v1.Container](/docs/api-reference/{{page.version}}/#container-v1-core) alongside the app `containers` array.
 The status of the init containers is returned in `status.initContainerStatuses`
 field as an array of the container statuses (similar to the `status.containerStatuses`
 field).
@@ -1,8 +1,5 @@
 ---
 title: Pod Lifecycle
-redirect_from:
- "/docs/user-guide/pod-states/"
- "/docs/user-guide/pod-states.html"
 ---

 {% capture overview %}
@@ -20,7 +17,7 @@ This page describes the lifecycle of a Pod.
 ## Pod phase

 A Pod's `status` field is a
-[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core)
+[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core)
 object, which has a `phase` field.

 The phase of a Pod is a simple, high-level summary of where the Pod is in its
@@ -55,7 +52,7 @@ Here are the possible values for `phase`:
 ## Pod conditions

 A Pod has a PodStatus, which has an array of
-[PodConditions](/docs/resources-reference/v1.6/#podcondition-v1-core). Each element
+[PodConditions](/docs/resources-reference/{{page.version}}/#podcondition-v1-core). Each element
 of the PodCondition array has a `type` field and a `status` field. The `type`
 field is a string, with possible values PodScheduled, Ready, Initialized, and
 Unschedulable. The `status` field is a string, with possible values True, False,
@@ -63,22 +60,22 @@ and Unknown.

 ## Container probes

-A [Probe](/docs/resources-reference/v1.6/#probe-v1-core) is a diagnostic
+A [Probe](/docs/resources-reference/{{page.version}}/#probe-v1-core) is a diagnostic
 performed periodically by the [kubelet](/docs/admin/kubelet/)
 on a Container. To perform a diagnostic,
 the kubelet calls a
 [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by
 the Container. There are three types of handlers:

-* [ExecAction](/docs/resources-reference/v1.6/#execaction-v1-core):
+* [ExecAction](/docs/resources-reference/{{page.version}}/#execaction-v1-core):
  Executes a specified command inside the Container. The diagnostic
  is considered successful if the command exits with a status code of 0.

-* [TCPSocketAction](/docs/resources-reference/v1.6/#tcpsocketaction-v1-core):
+* [TCPSocketAction](/docs/resources-reference/{{page.version}}/#tcpsocketaction-v1-core):
  Performs a TCP check against the Container's IP address on
  a specified port. The diagnostic is considered successful if the port is open.

-* [HTTPGetAction](/docs/resources-reference/v1.6/#httpgetaction-v1-core):
+* [HTTPGetAction](/docs/resources-reference/{{page.version}}/#httpgetaction-v1-core):
  Performs an HTTP Get request against the Container's IP
  address on a specified port and path. The diagnostic is considered successful
  if the response has a status code greater than or equal to 200 and less than 400.
@@ -132,11 +129,11 @@ to stop.
 ## Pod and Container status

 For detailed information about Pod Container status, see
-[PodStatus](/docs/resources-reference/v1.6/#podstatus-v1-core)
+[PodStatus](/docs/resources-reference/{{page.version}}/#podstatus-v1-core)
 and
-[ContainerStatus](/docs/resources-reference/v1.6/#containerstatus-v1-core).
+[ContainerStatus](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core).
 Note that the information reported as Pod status depends on the current
-[ContainerState](/docs/resources-reference/v1.6/#containerstatus-v1-core).
+[ContainerState](/docs/resources-reference/{{page.version}}/#containerstatus-v1-core).

 ## Restart policy

@@ -2,11 +2,6 @@
 assignees:
 - erictune
 title: Pod Overview
-redirect_from:
- "/docs/concepts/abstractions/pod/"
- "/docs/concepts/abstractions/pod.html"
- "/docs/user-guide/pod-templates/"
- "/docs/user-guide/pod-templates.html"
 ---

 {% capture overview %}
@@ -1,9 +1,6 @@
 ---
 assignees:
 title: Pods
-redirect_from:
- "/docs/user-guide/pods/index/"
- "/docs/user-guide/pods/index.html"
 ---

 * TOC
@@ -196,4 +193,4 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'

 Pod is a top-level resource in the Kubernetes REST API. More details about the
 API object can be found at: [Pod API
-object](/docs/api-reference/v1.6/#pod-v1-core).
+object](/docs/api-reference/{{page.version}}/#pod-v1-core).
@@ -252,7 +252,7 @@ kubectl cluster-info

 ### Accessing the cluster programmatically 

-It's possible to use the locally stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) to program against your Kubernetes cluster in the programming language of your choice. 
+It's possible to use the locally stored client certificates to access the api server. For example, you may want to use any of the [Kubernetes API client libraries](/docs/reference/client-libraries/) to program against your Kubernetes cluster in the programming language of your choice. 

 To demonstrate how to use these locally stored certificates, we provide the following example of using ```curl``` to communicate to the master api server via https:

@@ -65,11 +65,11 @@ kube-node-02.example.com

 ## Setting up ansible access to your nodes

-If you already are running on a machine which has passwordless ssh access to the kube-master and kube-node-{01,02} nodes, and 'sudo' privileges, simply set the value of `ansible_ssh_user` in `~/contrib/ansible/group_vars/all.yml` to the username which you use to ssh to the nodes (i.e. `fedora`), and proceed to the next step...
+If you already are running on a machine which has passwordless ssh access to the kube-master and kube-node-{01,02} nodes, and 'sudo' privileges, simply set the value of `ansible_ssh_user` in `~/contrib/ansible/inventory/group_vars/all.yml` to the username which you use to ssh to the nodes (i.e. `fedora`), and proceed to the next step...

 *Otherwise* setup ssh on the machines like so (you will need to know the root password to all machines in the cluster).

-edit: ~/contrib/ansible/group_vars/all.yml
+edit: ~/contrib/ansible/inventory/group_vars/all.yml

 ```yaml
 ansible_ssh_user: root
@@ -95,10 +95,10 @@ done

 ## Setting up the cluster

-Although the default value of variables in `~/contrib/ansible/group_vars/all.yml` should be good enough, if not, change them as needed.
+Although the default value of variables in `~/contrib/ansible/inventory/group_vars/all.yml` should be good enough, if not, change them as needed.

 ```conf
-edit: ~/contrib/ansible/group_vars/all.yml
+edit: ~/contrib/ansible/inventory/group_vars/all.yml
 ```

 **Configure access to Kubernetes packages**
@@ -444,14 +444,29 @@ because of how this is used later.
 - Alternate, manual approach:

  1. Set `--configure-cbr0=false` on kubelet and restart.
-  1. Create a bridge
-     - `ip link add name cbr0 type bridge`.
+  1. Create a bridge.
+
+        ```
+        ip link add name cbr0 type bridge
+        ```
+
  1. Set appropriate MTU. NOTE: the actual value of MTU will depend on your network environment
-     - `ip link set dev cbr0 mtu 1460`
+
+        ```
+        ip link set dev cbr0 mtu 1460
+        ```
+
  1. Add the node's network to the bridge (docker will go on other side of bridge).
-     - `ip addr add $NODE_X_BRIDGE_ADDR dev cbr0`
+
+        ```
+        ip addr add $NODE_X_BRIDGE_ADDR dev cbr0
+        ```
+
  1. Turn it on
-     - `ip link set dev cbr0 up`
+
+        ```
+        ip link set dev cbr0 up
+        ```

 If you have turned off Docker's IP masquerading to allow pods to talk to each
 other, then you may need to do masquerading just for destination IPs outside
@@ -501,11 +516,13 @@ all configured and managed *by Kubernetes*:

 You will need to run one or more instances of etcd.

-  - Recommended approach: run one etcd instance, with its log written to a directory backed
+  - Highly available and easy to restore - Run 3 or 5 etcd instances with, their logs written to a directory backed
    by durable storage (RAID, GCE PD)
-  - Alternative: run 3 or 5 etcd instances.
-    - Log can be written to non-durable storage because storage is replicated.
-    - run a single apiserver which connects to one of the etcd nodes.
+  - Not highly available, but easy to restore - Run one etcd instance, with its log written to a directory backed
+    by durable storage (RAID, GCE PD)
+    **Note:** May result in operations outages in case of instance outage
+  - Highly available - Run 3 or 5 etcd instances with non durable storage.
+    **Note:** Log can be written to non-durable storage because storage is replicated.

 See [cluster-troubleshooting](/docs/admin/cluster-troubleshooting) for more discussion on factors affecting cluster
 availability.
@@ -1,8 +1,5 @@
 ---
 title: Kubernetes on Ubuntu
-redirect_from:
- "/docs/getting-started-guides/ubuntu/calico/"
- "/docs/getting-started-guides/ubuntu/calico.html"
 ---

 {% capture overview %}
@@ -10,7 +10,7 @@ This page covers how to get started with deploying Kubernetes on vSphere and det
 * TOC
 {:toc}

-### Getting started with vSphere
+### Getting started with the vSphere Cloud Provider

 Kubernetes comes with a cloud provider for vSphere. A quick and easy way to try out the cloud provider is to deploy Kubernetes using [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere).

@@ -20,7 +20,7 @@ This page also describes how to configure and get started with the cloud provide

 To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch.

-Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere page](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md)
+Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md) page

 ### vSphere Cloud Provider

@@ -31,219 +31,178 @@ vSphere Cloud Provider allows using vSphere managed storage within Kubernetes. I
 3. Storage Classes and provisioning of volumes.
 4. vSphere Storage Policy Based Management for Containers orchestrated by Kubernetes.

-Documentation for how to use vSphere managed storage can be found in the
-[persistent volumes user
-guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the
-[volumes user
-guide](/docs/concepts/storage/volumes/#vspherevolume)
+Documentation for how to use vSphere managed storage can be found in the [persistent volumes user guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the [volumes user guide](/docs/concepts/storage/volumes/#vspherevolume)

-Examples can be found
-[here](https://git.k8s.io/kubernetes/examples/volumes/vsphere)
+Examples can be found [here](https://git.k8s.io/kubernetes/examples/volumes/vsphere)

-#### Configuring vSphere Cloud Provider
+#### Enable vSphere Cloud Provider

-If a Kubernetes cluster has not been deployed using Kubernetes-Anywhere, follow the instructions below to use the vSphere Cloud Provider. These steps are not needed when using Kubernetes-Anywhere, they will be done as part of the deployment.
+If a Kubernetes cluster has not been deployed using Kubernetes-Anywhere, follow the instructions below to enable the vSphere Cloud Provider. These steps are not needed when using Kubernetes-Anywhere, they will be done as part of the deployment.

-* Enable UUID for a VM
+**Step-1** [Create a VM folder](https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.vcenterhost.doc/GUID-031BDB12-D3B2-4E2D-80E6-604F304B4D0C.html) and move Kubernetes Node VMs to this folder.

-This can be done via [govc tool](https://github.com/vmware/govmomi/tree/master/govc)
+**Step-2** Make sure Node VM names must comply with the regex `[a-z](([-0-9a-z]+)?[0-9a-z])?(\.[a-z0-9](([-0-9a-z]+)?[0-9a-z])?)*` If Node VMs does not comply with this regex, rename them and make it compliant to this regex.

-```
-export GOVC_URL=<IP/URL>
-export GOVC_USERNAME=<vCenter User>
-export GOVC_PASSWORD=<vCenter Password>
-export GOVC_INSECURE=1
-govc vm.change -e="disk.enableUUID=1" -vm=<VMNAME>
-```
+  Node VM names constraints:

-* Create Role and User with Required Privileges for vSphere Cloud Provider
+  * VM names can not begin with numbers.
+  * VM names can not have capital letters, any special charaters except `.` and `-`.
+  * VM names can not be shorter than 3 chars and longer than 63

-vSphere Cloud Provider requires the following minimal set of privileges to interact with vCenter:
+**Step-3** Enable disk UUID on Node virtual machines

-Please refer [vSphere Documentation Center](http://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc%2FGUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html&resultof=%22%43%72%65%61%74%65%22%20%22%63%72%65%61%74%22%20%22%43%75%73%74%6f%6d%22%20%22%63%75%73%74%6f%6d%22%20%22%52%6f%6c%65%22%20%22%72%6f%6c%65%22%20) to know about steps for creating a Custom Role, User and Role Assignment.
+The disk.EnableUUID parameter must be set to "TRUE" for each Node VM. This step is necessary so that the VMDK always presents a consistent UUID to the VM, thus allowing the disk to be mounted properly. 

-Note: Assign Permissions at the vCenter Level and make sure to check Propagate.
+For each of the virtual machine nodes that will be participating in the cluster, follow the steps below using [GOVC tool](https://github.com/vmware/govmomi/tree/master/govc)

-```
-Datastore > Allocate space
-Datastore > Low level file Operations
-Virtual Machine > Configuration > Add existing disk
-Virtual Machine > Configuration > Add or remove device
-Virtual Machine > Configuration > Remove disk
-```
+* Set up GOVC environment

-For the VSAN policy based volume provisioning feature, the following additional privileges are required.
+        export GOVC_URL='vCenter IP OR FQDN'
+        export GOVC_USERNAME='vCenter User'
+        export GOVC_PASSWORD='vCenter Password'
+        export GOVC_INSECURE=1

-```
-Network > Assign network
-Virtual machine > Configuration > Add new disk
-Virtual Machine > Inventory > Create new
-Virtual machine > Configuration > Add new disk
-Resource > Assign virtual machine to resource pool
-```
+* Find Node VM Paths

-* Provide the cloud config file to each instance of kubelet, apiserver and controller manager via ```--cloud-config=<path to file>``` flag. Cloud config [template can be found at Kubernetes-Anywhere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/vsphere.conf)
+        govc ls /datacenter/vm/<vm-folder-name>

-Sample Config:
+* Set disk.EnableUUID to true for all VMs
+
+        govc vm.change -e="disk.enableUUID=1" -vm='VM Path'
+
+Note: If Kubernetes Node VMs are created from template VM then `disk.EnableUUID=1` can be set on the template VM. VMs cloned from this template, will automatically inherit this property.
+
+**Step-4** Create and assign Roles to the vSphere Cloud Provider user and vSphere entities.
+
+Note: if you want to use Administrator account then this step can be skipped.
+
+vSphere Cloud Provider requires the following minimal set of privileges to interact with vCenter. Please refer [vSphere Documentation Center](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html) to know about steps for creating a Custom Role, User and Role Assignment.
+
+<table>
+<thead>
+<tr>
+  <th>Roles</th>
+  <th>Privileges</th>
+  <th>Entities</th>
+  <th>Propagate to Children</th>
+</tr>
+</thead>
+<tbody><tr>
+  <td>manage-k8s-node-vms</td>
+  <td>Resource.AssignVMToPool<br> System.Anonymous<br> System.Read<br> System.View<br> VirtualMachine.Config.AddExistingDisk<br> VirtualMachine.Config.AddNewDisk<br> VirtualMachine.Config.AddRemoveDevice<br> VirtualMachine.Config.RemoveDisk<br> VirtualMachine.Inventory.Create<br> VirtualMachine.Inventory.Delete</td>
+  <td>Cluster,<br> Hosts,<br> VM Folder</td>
+  <td>Yes</td>
+</tr>
+<tr>
+  <td>manage-k8s-volumes</td>
+  <td>Datastore.AllocateSpace<br> Datastore.FileManagement<br> System.Anonymous<br> System.Read<br> System.View</td>
+  <td>Datastore</td>
+  <td>No</td>
+</tr>
+<tr>
+  <td>k8s-system-read-and-spbm-profile-view</td>
+  <td>StorageProfile.View<br> System.Anonymous<br> System.Read<br> System.View</td>
+  <td>vCenter</td>
+  <td>No</td>
+</tr>
+<tr>
+  <td>ReadOnly</td>
+  <td>System.Anonymous<br>System.Read<br>System.View</td>
+  <td>Datacenter,<br> Datastore Cluster,<br> Datastore Storage Folder</td>
+  <td>No</td>
+</tr>
+</tbody>
+</table>
+
+**Step-5** Create the vSphere cloud config file (`vsphere.conf`). Cloud config template can be found [here](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/vsphere.conf)
+
+This config file needs to be placed in the shared directory which should be accessible from kubelet container, controller-manager pod, and API server pod.
+
+**```vsphere.conf``` for Master Node:**

 ```
 [Global]
-        user = <User name for vCenter>
-        password = <Password for vCenter>
-        server = <IP/URL for vCenter>
-        port = <Default 443 for vCenter>
-        insecure-flag = <set to 1 if the host above uses a self-signed cert>
-        datacenter = <Datacenter to be used>
-        datastore = <Datastore to use for provisioning volumes using storage classes/dynamic provisioning>
-        working-dir = <Folder in which VMs are provisioned, can be null>
-        vm-uuid = <VM Instance UUID of virtual machine which can be retrieved from instanceUuid property in VmConfigInfo, or also set as vc.uuid in VMX file. If empty, will be retrieved from sysfs (requires root)>
+        user = "vCenter username for cloud provider"
+        password = "password"
+        server = "IP/FQDN for vCenter"
+        port = "443" #Optional
+        insecure-flag = "1" #set to 1 if the vCenter uses a self-signed cert
+        datacenter = "Datacenter name" 
+        datastore = "Datastore name" #Datastore to use for provisioning volumes using storage classes/dynamic provisioning
+        working-dir = "vCenter VM folder path in which node VMs are located"
+        vm-name = "VM name of the Master Node" #Optional
+        vm-uuid = "UUID of the Node VM" # Optional        
 [Disk]
    scsicontrollertype = pvscsi
 ```

-* Set the cloud provider via ```--cloud-provider=vsphere``` flag for each instance of kubelet, apiserver and controller manager.
+Note: **```vm-name``` parameter is introduced in 1.6.4 release.** Both ```vm-uuid``` and ```vm-name``` are optional parameters. if ```vm-name``` is specified then ```vm-uuid``` is not used. if both are not specified then kubelet will get vm-uuid from `/sys/class/dmi/id/product_serial` and query vCenter to find the Node VM's name. 

-* When upgrading to 1.6 install the default storage class addons, [click here for more details](https://github.com/kubernetes/kubernetes/issues/40070)
+**```vsphere.conf``` for Worker Nodes:** (Only Applicable to 1.6.4 release and above. For older releases this file should have all the parameters specified in Master node's ```vSphere.conf``` file)
+ 
+``` 
+[Global]
+        vm-name = "VM name of the Worker Node"
+```
+
+Below is summary of supported parameters in the `vsphere.conf` file
+
+* ```user``` is the vCenter username for vSphere Cloud Provider.
+* ```password``` is the password for vCenter user specified with `user`.
+* ```server``` is the vCenter Server IP or FQDN
+* ```port``` is the vCenter Server Port. Default is 443 if not specified.
+* ```insecure-flag``` is set to 1 if vCenter used a self-signed certificate.
+* ```datacenter``` is the name of the datacenter on which Node VMs are deployed.
+* ```datastore``` is the default datastore to use for provisioning volumes using storage classes/dynamic provisioning.
+* ```vm-name``` is recently added configuration parameter. This is optional parameter. When this parameter is present, ```vsphere.conf``` file on the worker node does not need vCenter credentials.
+
+  **Note:** ```vm-name``` is added in the release 1.6.4. Prior releases does not support this parameter. 
+
+* ```working-dir``` can be set to empty ( working-dir = ""), if Node VMs are located in the root VM folder.
+* ```vm-uuid``` is the VM Instance UUID of virtual machine. ```vm-uuid``` can be set to empty (```vm-uuid = ""```). if set to empty, this will be retrieved from /sys/class/dmi/id/product_serial file on virtual machine (requires root access).
+
+  * ```vm-uuid``` needs to be set in this format - ```423D7ADC-F7A9-F629-8454-CE9615C810F1```
+
+  * ```vm-uuid``` can be retrieved from Node Virtual machines using following command. This will be different on each node VM.
+
+        cat /sys/class/dmi/id/product_serial | sed -e 's/^VMware-//' -e 's/-/ /' | awk '{ print toupper($1$2$3$4 "-" $5$6 "-" $7$8 "-" $9$10 "-" $11$12$13$14$15$16) }'
+
+* `datastore` is the default datastore used for provisioning volumes using storage classes. If datastore is located in storage folder or datastore is member of datastore cluster, make sure to specify full datastore path. Make sure vSphere Cloud Provider user has Read Privilege set on the datastore cluster or storage folder to be able to find datastore.
+  * For datastore located in the datastore cluster, specify datastore as mentioned below
+
+        datastore = "DatastoreCluster/datastore1"
+
+  * For datastore located in the storage folder, specify datastore as mentioned below
+
+        datastore = "DatastoreStorageFolder/datastore1"
+
+**Step-6** Add flags to controller-manager, API server and Kubelet to enable vSphere Cloud Provider.
+* Add following flags to kubelet running on every node and to the controller-manager and API server pods manifest files. 
+
+```
+--cloud-provider=vsphere
+--cloud-config=<Path of the vsphere.conf file>
+```
+
+Manifest files for API server and controller-manager are generally located at `/etc/kubernetes`
+
+**Step-7** Restart Kubelet on all nodes.
+* Reload kubelet systemd unit file using ```systemctl daemon-reload```
+* Restart kubelet service using ```systemctl restart kubelet.service```
+
+Note: After enabling the vSphere Cloud Provider, Node names will be set to the VM names from the vCenter Inventory.

 #### Known issues
-
-### Kube-up (Deprecated)
-
-Kube-up.sh is no longer supported and is deprecated. The steps for kube-up are included but going forward [kube-anywhere](https://github.com/kubernetes/kubernetes-anywhere) is preferred.
-
-The recommended version for kube-up is [v1.4.7](https://github.com/kubernetes/kubernetes/releases/tag/v1.4.7)
-
-The example below creates a Kubernetes cluster with 4 worker node Virtual.
-Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
-
-#### Prerequisites
-
-* You need administrator credentials to an ESXi machine or vCenter instance with write mode api access enabled (not available on the free ESXi license).
-* You must have Go (see [here](https://git.k8s.io/community/contributors/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org).
-* You must have your `GOPATH` set up and include `$GOPATH/bin` in your `PATH`.
-
-```shell
-export GOPATH=$HOME/src/go
-mkdir -p $GOPATH
-export PATH=$PATH:$GOPATH/bin
-```
-
-* Install the govc tool to interact with ESXi/vCenter. Head to [govc Releases](https://github.com/vmware/govmomi/releases) to download the latest.
-
-```shell
-# Sample commands for v0.8.0 for 64 bit Linux.
-curl -OL https://github.com/vmware/govmomi/releases/download/v0.8.0/govc_linux_amd64.gz
-gzip -d govc_linux_amd64.gz
-chmod +x govc_linux_amd64
-mv govc_linux_amd64 /usr/local/bin/govc
-```
-
-* Get or build a [binary release](/docs/getting-started-guides/binary_release)
-
-#### Setup
-
-Download a prebuilt Debian 8.2 VMDK that we'll use as a base image:
-
-```shell
-curl --remote-name-all https://storage.googleapis.com/govmomi/vmdk/2016-01-08/kube.vmdk.gz{,.md5}
-md5sum -c kube.vmdk.gz.md5
-gzip -d kube.vmdk.gz
-```
-
-Configure the environment for govc
-
-```shell
-export GOVC_URL='hostname' # hostname of the vc
-export GOVC_USERNAME='username' # username for logging into the vsphere.
-export GOVC_PASSWORD='password' # password for the above username
-export GOVC_NETWORK='Network Name' # Name of the network the vms should join. Many times it could be "VM Network"
-export GOVC_INSECURE=1 # If the host above uses a self-signed cert
-export GOVC_DATASTORE='target datastore'
-# To get resource pool via govc: govc ls -l 'host/*' | grep ResourcePool | awk '{print $1}' | xargs -n1 -t govc pool.info
-export GOVC_RESOURCE_POOL='resource pool or cluster with access to datastore'
-export GOVC_GUEST_LOGIN='kube:kube' # Used for logging into kube.vmdk during deployment.
-export GOVC_PORT=443 # The port to be used by vSphere cloud provider plugin
-# To get datacente via govc: govc datacenter.info
-export GOVC_DATACENTER='ha-datacenter' # The datacenter to be used by vSphere cloud provider plugin
-```
-
-Sample environment
-
-```shell
-export GOVC_URL='10.161.236.217'
-export GOVC_USERNAME='administrator'
-export GOVC_PASSWORD='MyPassword1'
-export GOVC_NETWORK='VM Network'
-export GOVC_INSECURE=1
-export GOVC_DATASTORE='datastore1'
-export GOVC_RESOURCE_POOL='/Datacenter/host/10.20.104.24/Resources'
-export GOVC_GUEST_LOGIN='kube:kube'
-export GOVC_PORT='443'
-export GOVC_DATACENTER='Datacenter'
-```
-
-Import this VMDK into your vSphere datastore:
-
-```shell
-govc import.vmdk kube.vmdk ./kube/
-```
-
-Verify that the VMDK was correctly uploaded and expanded to ~3GiB:
-
-```shell
-govc datastore.ls ./kube/
-```
-
-If you need to debug any part of the deployment, the guest login for
-the image that you imported is `kube:kube`. It is normally specified
-in the GOVC_GUEST_LOGIN parameter above.
-
-Also take a look at the file `cluster/vsphere/config-default.sh` and
-make any needed changes. You can configure the number of nodes
-as well as the IP subnets you have made available to Kubernetes, pods,
-and services.
-
-#### Starting a cluster
-
-Now, let's continue with deploying Kubernetes.
-This process takes about ~20-30 minutes depending on your network.
-
-##### From extracted binary release
-
-```shell
-cd kubernetes
-KUBERNETES_PROVIDER=vsphere cluster/kube-up.sh
-```
-
-##### Build from source
-
-```shell
-cd kubernetes
-make release
-KUBERNETES_PROVIDER=vsphere cluster/kube-up.sh
-```
-
-Refer to the top level README and the getting started guide for Google Compute
-Engine. Once you have successfully reached this point, your vSphere Kubernetes
-deployment works just as any other one!
-
-**Enjoy!**
-
-#### Extra: debugging deployment failure
-
-The output of `kube-up.sh` displays the IP addresses of the VMs it deploys. You
-can log into any VM as the `kube` user to poke around and figure out what is
-going on (find yourself authorized with your SSH key, or use the password
-`kube` otherwise).
+[vmware#220](https://github.com/vmware/kubernetes/issues/220) :
+vSphere Cloud Provider can not be used on the Kubernetes Cluster when vCenter port is configured other than the default port 443. Fix for this issue is already out (Kubernetes PR# [49689](https://github.com/kubernetes/kubernetes/pull/49689)). We will make sure that, PR 49689 is cherry picked to 1.7, 1.6 and 1.5 branches. 

 ## Support Level


-IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs                                              | Conforms | Support Level
-------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
-Vmware vSphere       | Kube-anywhere    | Photon OS | Flannel         | [docs](/docs/getting-started-guides/vsphere)                                |          | Community  ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu)), ([@luomiao](https://github.com/luomiao)), ([@divyenpatel](https://github.com/divyenpatel))
+IaaS Provider        | Config. Mgmt | OS     | Networking | Docs                                          | Conforms  | Support Level
+-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | --------- | ----------------------------
+Vmware vSphere       | Kube-anywhere    | Photon OS | Flannel         | [docs](/docs/getting-started-guides/vsphere)                                |                | Community  ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu)), ([@luomiao](https://github.com/luomiao)), ([@divyenpatel](https://github.com/divyenpatel))

 If you identify any issues/problems using the vSphere cloud provider, you can create an issue in our repo - [VMware Kubernetes](https://github.com/vmware/kubernetes).

 For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
-
@@ -1,7 +1,4 @@
 ---
-redirect_from:
- "/docs/templatedemos/"
- "/docs/templatedemos.html"
 title: Using Page Templates
 ---

@@ -137,6 +137,111 @@ A list of Kubernetes-specific terms and words to be used consistently across the
  <tr><td>TBD</td><td>TBD</td></tr>
 </table>{% endcomment %}

+## Callout Formatting
+Callouts help create different rhetorical appeal levels. Our documentation supports three different callouts: **Note:** {: .note}, **Caution:** {: .caution}, and **Warning:** {: .warning}. 
+
+1. Start each callout with the appropriate prefix.
+
+2. Use the following syntax to apply a style:
+
+```console
+**Note:** The prefix you use is the same text you use in the tag. 
+{: .note} <!-- This tag must appear on a new line. -->
+```
+
+The output is:
+
+**Note:** The prefix you choose is the same text for the tag.
+{: .note}
+
+### Note
+
+Use {: .note} to highlight a tip or a piece of information that may be helpful to know. 
+
+For example:
+
+```console
+**Note:** You can _still_ use Markdown inside these callouts. 
+{: .note}
+```
+
+The output is:
+
+**Note:** You can _still_ use Markdown inside these callouts.
+{: .note}
+
+### Caution
+
+Use {: .caution} to call attention to an important piece of information to avoid pitfalls.  
+
+For example:
+
+```console
+**Caution:** The callout style only applies to the line directly above the tag. 
+{: .caution}
+```
+
+The output is:
+
+**Caution:** The callout style only applies to the line directly above the tag. 
+{: .caution}
+
+### Warning
+
+Use {: .warning} to indicate danger or a piece of information that is crucial to follow.
+
+For example:
+
+```console
+**Warning:** Beware. 
+{: .warning}
+```
+
+The output is:
+
+**Warning:** Beware. 
+{: .warning}
+
+## Common Callout Issues
+
+### Style Does Not Apply
+
+Callout tags must be on a new line to apply the style. Github's Preview Changes feature further obfuscates this fact by rendering the tag on the same line, but your code must match the following syntax:
+
+```console
+**Note:** Your text goes here.
+{: .note} <!-- This tag must appear on a new line. -->
+```
+
+### Multiple Lines
+
+Callouts should generally be single sentences and automatically span multiple lines. However, you can use `<br/>` tags if you need to create multiple lines.
+
+For example:
+
+```console
+**Note:"** This is my note. Use `<br/>` to create multiple lines. <br/> <br/> You can still use _Markdown_ to **format** text!
+{: .note}
+```
+
+The output is:
+
+**Note:** This is my note. Use `<br/>` to create multiple lines. <br/> <br/> You can still use _Markdown_ to **format** text!
+{: .note}
+
+Typing multiple lines does **not** work. The callout style only applies to the line directly above the tag. 
+
+```console
+**Note:** This is my note. 
+
+I didn't read the stlye guide.
+{: .note}
+```
+
+**Note:** This is my note. 
+
+I didn't read the stlye guide.
+{: .note}

 ## Content best practices

@@ -3,11 +3,6 @@ assignees:
 - bgrant0607
 - thockin
 title: Kubernetes Documentation
-redirect_from:
- "/docs/"
- "/docs/index.html"
- "/docs/user-guide/"
- "/docs/user-guide/index.html"
 ---

 Kubernetes documentation can help you set up Kubernetes, learn about the system, or get your applications and workloads running on Kubernetes. To learn the basics of what Kubernetes is and how it works, read "[What is Kubernetes](/docs/concepts/overview/what-is-kubernetes/)".
@@ -36,21 +36,22 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 The following Kubernetes API client libraries are provided and maintained by
 their authors, not the Kubernetes team.

-| Language | Client Library |
-|----------|----------------|
-| Clojure  | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) |
-| Go       | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) |
-| Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) |
+| Language             | Client Library                           |
+| -------------------- | ---------------------------------------- |
+| Clojure              | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) |
+| Go                   | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) |
+| Java (OSGi)          | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) |
 | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) |
-| Node.js  | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) |
-| Node.js  | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) |
-| Perl     | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) |
-| PHP      | [github.com/devstub/kubernetes-api-php-client](https://github.com/devstub/kubernetes-api-php-client) |
-| PHP      | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
-| Python   | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
-| Ruby     | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
-| Ruby     | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
-| Scala    | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
+| Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) |
+| Node.js              | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) |
+| Node.js              | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) |
+| Perl                 | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) |
+| PHP                  | [github.com/devstub/kubernetes-api-php-client](https://github.com/devstub/kubernetes-api-php-client) |
+| PHP                  | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) |
+| Python               | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
+| Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
+| Ruby                 | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
+| Scala                | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) |
 {% endcapture %}

 {% include templates/concept.md %}
@@ -1,8 +1,5 @@
 ---
 title: Federation API Reference
-redirect_from:
- "/docs/federation/api-reference/"
- "/docs/federation/api-reference/index.md"
 ---
 # API Reference

@@ -5,9 +5,6 @@ assignees:
 - errordeveloper
 - jbeda
 title: Using kubeadm to Create a Cluster
-redirect_from:
- "/docs/getting-started-guides/kubeadm/"
- "/docs/getting-started-guides/kubeadm.html"
 ---

 {% capture overview %}
@@ -105,17 +102,16 @@ kubeadm on, and run:
 kubeadm init
 ```

-**Note:** this will autodetect the network interface to advertise the master on
+**Note:**
+ - You need to choose a Pod Network Plugin in the next step. Depending on what
+third-party provider you choose, you might have to set the `--pod-network-cidr` to
+something provider-specific. The tabs below will contain a notice about what flags
+on `kubeadm init` are required.
+ - This will autodetect the network interface to advertise the master on
 as the interface with the default gateway. If you want to use a different
 interface, specify `--apiserver-advertise-address=<ip-address>` argument to `kubeadm
 init`.

-There are pod network implementations where the master also plays a role in
-allocating a set of network address space for each node.  When using
-[flannel](https://github.com/coreos/flannel) as the [pod network](#pod-network)
-(described in step 3), specify `--pod-network-cidr=10.244.0.0/16`. _This is not
-required for any other networks besides flannel._
-
 Please refer to the [kubeadm reference doc](/docs/admin/kubeadm/) if you want to
 read more about the flags `kubeadm init` provides.

@@ -182,31 +178,9 @@ token can add authenticated nodes to your cluster.  These tokens can be listed,
 created and deleted with the `kubeadm token` command.  See the [reference
 guide](/docs/admin/kubeadm/#manage-tokens).

-#### Master Isolation
-
-By default, your cluster will not schedule pods on the master for security
-reasons. If you want to be able to schedule pods on the master, e.g. for a
-single-machine Kubernetes cluster for development, run:
-
-``` bash
-kubectl taint nodes --all node-role.kubernetes.io/master-
-```
-
-With output looking something like:
-
-```
-node "test-01" tainted
-taint key="dedicated" and effect="" not found.
-taint key="dedicated" and effect="" not found.
-```
-
-This will remove the `node-role.kubernetes.io/master` taint from any nodes that
-have it, including the master node, meaning that the scheduler will then be able
-to schedule pods everywhere.
-
 ### (3/4) Installing a pod network {#pod-network}

-You must install a pod network add-on so that your pods can communicate with
+You **must** install a pod network add-on so that your pods can communicate with
 each other.

 **The network must be deployed before any applications.  Also, kube-dns, a
@@ -228,13 +202,79 @@ You can install a pod network add-on with the following command:
 kubectl apply -f <add-on.yaml>
 ```

-Please refer to the specific add-on installation guide for exact details. 
-
 **NOTE:** You can install **only one** pod network per cluster.

-If you are on another architecture than amd64, you should use the
-flannel or Weave Net overlay networks as described in [the
-multi-platform section](#multi-platform)
+
+{% capture choose %}
+Please select one of the tabs to see installation instructions for the respective third-party Pod Network Provider.
+{% endcapture %}
+
+{% capture calico %}
+
+The official Calico guide is [here](http://docs.projectcalico.org/v2.3/getting-started/kubernetes/installation/hosted/kubeadm/)
+
+**Note:**
+ - In order for Network Policy to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init`
+ - Calico works on `amd64` only.
+
+```shell
+kubectl apply -f http://docs.projectcalico.org/v2.3/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml
+```
+{% endcapture %}
+
+{% capture canal %}
+
+The official Canal set-up guide is [here](https://github.com/projectcalico/canal/tree/master/k8s-install)
+
+**Note:**
+ - For Canal to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`.
+ - Canal works on `amd64` only.
+
+```shell
+kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.6/rbac.yaml
+kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.6/canal.yaml
+```
+{% endcapture %}
+
+{% capture flannel %}
+
+**Note:**
+ - For flannel to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`.
+ - flannel works on `amd64`, `arm`, `arm64` and `ppc64le`, but for it to work on an other platform than
+`amd64` you have to manually download the manifest and replace `amd64` occurances with your chosen platform.
+
+```shell
+kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
+kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
+```
+{% endcapture %}
+
+{% capture romana %}
+
+The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm)
+
+**Note:** Romana works on `amd64` only.
+
+```shell
+kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml
+```
+{% endcapture %}
+
+{% capture weave_net %}
+
+The official Weave Net set-up guide is [here](https://www.weave.works/docs/net/latest/kube-addon/)
+
+**Note:** Weave Net works on `amd64`, `arm` and `arm64` without any extra action required.
+
+```shell
+kubectl apply -f https://git.io/weave-kube-1.6
+```
+{% endcapture %}
+
+{% assign tab_names = "Choose one...,Calico,Canal,Flannel,Romana,Weave Net" | split: ',' | compact %}
+{% assign tab_contents = site.emptyArray | push: choose | push: calico | push: canal | push: flannel | push: romana | push: weave_net %}
+
+{% include tabs.md %}

 Once a pod network has been installed, you can confirm that it is working by
 checking that the kube-dns pod is Running in the output of `kubectl get pods --all-namespaces`.
@@ -243,6 +283,28 @@ And once the kube-dns pod is up and running, you can continue by joining your no
 If your network is not working or kube-dns is not in the Running state, check
 out the [troubleshooting section](#troubleshooting) below.

+#### Master Isolation
+
+By default, your cluster will not schedule pods on the master for security
+reasons. If you want to be able to schedule pods on the master, e.g. for a
+single-machine Kubernetes cluster for development, run:
+
+``` bash
+kubectl taint nodes --all node-role.kubernetes.io/master-
+```
+
+With output looking something like:
+
+```
+node "test-01" tainted
+taint key="dedicated" and effect="" not found.
+taint key="dedicated" and effect="" not found.
+```
+
+This will remove the `node-role.kubernetes.io/master` taint from any nodes that
+have it, including the master node, meaning that the scheduler will then be able
+to schedule pods everywhere.
+
 ### (4/4) Joining your nodes

 The nodes are where your workloads (containers and pods, etc) run. To add new nodes to your cluster do the following for each machine:
@@ -419,7 +481,9 @@ kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64,
 following the [multi-platform
 proposal](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/multi-platform.md).

-Currently, only the pod networks [flannel](https://github.com/coreos/flannel) and [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) work on multiple architectures.
+Only some of the network providers offer solutions for all platforms. Please consult the list of
+network providers above or the documentation from each provider to figure out whether the provider
+supports your chosen platform.

 ## Limitations

@@ -4,9 +4,6 @@ assignees:
 - erictune
 - mikedanese
 title: Picking the Right Solution
-redirect_from:
- "/docs/getting-started-guides/index/"
- "/docs/getting-started-guides/index.html"
 ---

 Kubernetes can run on various platforms: from your laptop, to VMs on a cloud provider, to rack of
@@ -1,10 +1,5 @@
 ---
 title: Accessing Clusters
-redirect_from:
- "/docs/user-guide/accessing-the-cluster/"
- "/docs/user-guide/accessing-the-cluster.html"
- "/docs/concepts/cluster-administration/access-cluster/"
- "/docs/concepts/cluster-administration/access-cluster.html"
 ---

 * TOC
@@ -124,7 +119,8 @@ with future high-availability support.

 ### Programmatic access to the API

-Kubernetes supports [Go](#go-client) and [Python](#python-client) client libraries.
+Kubernetes officially supports [Go](#go-client) and [Python](#python-client)
+client libraries.

 #### Go client

@@ -145,7 +141,8 @@ as the kubectl CLI does to locate and authenticate to the apiserver. See this [e

 #### Other languages

-There are [client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
+There are [client libraries](/docs/reference/client-libraries/) for accessing the API from other languages.
+See documentation for other libraries for how they authenticate.

 ### Accessing the API from a Pod

@@ -3,11 +3,6 @@ assignees:
 - mikedanese
 - thockin
 title: Authenticate Across Clusters with kubeconfig
-redirect_from:
- "/docs/user-guide/kubeconfig-file/"
- "/docs/user-guide/kubeconfig-file.html"
- "/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/"
- "/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig.html"
 ---

 Authentication in Kubernetes can differ for different individuals.
@@ -1,10 +1,5 @@
 ---
 title: Communicate Between Containers in the Same Pod Using a Shared Volume
-redirect_from:
- "/docs/user-guide/pods/multi-container/"
- "/docs/user-guide/pods/multi-container.html"
- "docs/tasks/configure-pod-container/communicate-containers-same-pod/"
- "docs/tasks/configure-pod-container/communicate-containers-same-pod.html"
 ---

 {% capture overview %}
@@ -144,9 +139,9 @@ the shared Volume is lost.
 * See
 [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).

-* See [Volume](/docs/api-reference/v1.6/#volume-v1-core).
+* See [Volume](/docs/api-reference/{{page.version}}/#volume-v1-core).

-* See [Pod](/docs/api-reference/v1.6/#pod-v1-core).
+* See [Pod](/docs/api-reference/{{page.version}}/#pod-v1-core).

 {% endcapture %}

@@ -3,9 +3,6 @@ assignees:
 - bprashanth
 - davidopp
 title: Configure Your Cloud Provider's Firewalls
-redirect_from:
- "/docs/user-guide/services-firewalls/"
- "/docs/user-guide/services-firewalls.html"
 ---

 Many cloud providers (e.g. Google Compute Engine) define firewalls that help prevent inadvertent
@@ -1,10 +1,5 @@
 ---
 title: Connect a Front End to a Back End Using a Service
-redirect_from:
- "/docs/user-guide/services/operations/"
- "/docs/user-guide/services/operations.html"
- "/docs/tutorials/connecting-apps/connecting-frontend-backend/"
- "/docs/tutorials/connecting-apps/connecting-frontend-backend.html"
 ---

 {% capture overview %}
@@ -1,8 +1,5 @@
 ---
 title: Create an External Load Balancer
-redirect_from:
- "/docs/user-guide/load-balancer/"
- "/docs/user-guide/load-balancer.html"
 ---


@@ -1,8 +1,5 @@
 ---
 title: List All Container Images Running in a Cluster
-redirect_from:
- "/docs/tasks/kubectl/list-all-running-container-images/"
- "/docs/tasks/kubectl/list-all-running-container-images.html"
 ---

 {% capture overview %}
@@ -1,8 +1,5 @@
 ---
 title: Use Port Forwarding to Access Applications in a Cluster
-redirect_from:
- "/docs/user-guide/connecting-to-applications-port-forward/"
- "/docs/user-guide/connecting-to-applications-port-forward.html"
 ---

 {% capture overview %}
@@ -1,10 +1,5 @@
 ---
 title: Use a Service to Access an Application in a Cluster
-redirect_from:
- "/docs/user-guide/quick-start/"
- "/docs/user-guide/quick-start.html"
- "/docs/tutorials/stateless-application/expose-external-ip-address-service/"
- "/docs/tutorials/stateless-application/expose-external-ip-address-service.html"
 ---

 {% capture overview %}
@@ -99,11 +94,14 @@ provides load balancing for an application that has two running instances.
   see the node address by running `kubectl cluster-info`. If you are
   using Google Compute Engine instances, you can use the
   `gcloud compute instances list` command to see the public addresses of your
-   nodes.
+   nodes. For more information about this command, see the [GCE documentation](https://cloud.google.com/sdk/gcloud/reference/compute/instances/list). 

 1. On your chosen node, create a firewall rule that allows TCP traffic
   on your node port. For example, if your Service has a NodePort value of
-   31568, create a firewall rule that allows TCP traffic on port 31568.
+   31568, create a firewall rule that allows TCP traffic on port 31568. Different 
+   cloud providers offer different ways of configuring firewall rules. See [the 
+   GCE documentation on firewall rules](https://cloud.google.com/compute/docs/vpc/firewalls), 
+   for example.

 1. Use the node address and node port to access the Hello World application:

@@ -4,11 +4,6 @@ assignees:
 - mikedanese
 - rf232
 title: Web UI (Dashboard)
-redirect_from:
- "/docs/user-guide/ui/"
- "/docs/user-guide/ui.html"
- "/docs/tasks/web-ui-dashboard/"
- "/docs/tasks/web-ui-dashboard.html"
 ---

 Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster itself along with its attendant resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
@@ -3,11 +3,6 @@ assignees:
 - enisoc
 - IanLewis
 title: Extend the Kubernetes API with ThirdPartyResources
-redirect_from:
- "/docs/user-guide/thirdpartyresources/"
- "/docs/user-guide/thirdpartyresources.html"
- "/docs/concepts/ecosystem/thirdpartyresource/"
- "/docs/concepts/ecosystem/thirdpartyresource.html"
 ---

 {% assign for_k8s_version="1.7" %}{% include feature-state-deprecated.md %}
@@ -1,8 +1,5 @@
 ---
 title: Use an HTTP Proxy to Access the Kubernetes API
-redirect_from:
- "/docs/user-guide/connecting-to-applications-proxy/"
- "/docs/user-guide/connecting-to-applications-proxy.html"
 ---

 {% capture overview %}
@@ -1,9 +1,5 @@
 ---
 title: Access Clusters Using the Kubernetes API
-redirect_from:
- "/docs/user-guide/accessing-the-cluster/"
- "/docs/user-guide/accessing-the-cluster.html"
- "/docs/concepts/cluster-administration/access-cluster/"
 ---

 {% capture overview %}
@@ -116,7 +112,8 @@ with future high-availability support.

 ### Programmatic access to the API

-Kubernetes supports [Go](#go-client) and [Python](#python-client) client libraries.
+Kubernetes officially supports client libraries for [Go](#go-client) and
+[Python](#python-client).

 #### Go client

@@ -167,7 +164,7 @@ for i in ret.items:

 #### Other languages

-There are [client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
+There are [client libraries](/docs/reference/client-libraries/) for accessing the API from other languages. See documentation for other libraries for how they authenticate.

 ### Accessing the API from a Pod

@@ -1,8 +1,5 @@
 ---
 title: Access Services Running on Clusters
-redirect_from:
- "/docs/user-guide/accessing-the-cluster/"
- "/docs/user-guide/accessing-the-cluster.html"
 ---

 {% capture overview %}
@@ -3,11 +3,6 @@ assignees:
 - derekwaynecarr
 - janetkuo
 title: Apply Resource Quotas and Limits
-redirect_from:
- "/docs/admin/resourcequota/walkthrough/"
- "/docs/admin/resourcequota/walkthrough.html"
- "/docs/tasks/configure-pod-container/apply-resource-quota-limit/"
- "/docs/tasks/configure-pod-container/apply-resource-quota-limit.html"
 ---

 {% capture overview %}
@@ -2,11 +2,6 @@
 assignees:
 - caseydavenport
 title: Use Calico for NetworkPolicy
-redirect_from:
- "/docs/getting-started-guides/network-policy/calico/"
- "/docs/getting-started-guides/network-policy/calico.html"
- "/docs/tasks/configure-pod-container/calico-network-policy/"
- "/docs/tasks/configure-pod-container/calico-network-policy.html"
 ---

 {% capture overview %}
@@ -72,9 +72,9 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to

 ### Reference

-* [PersistentVolume](/docs/api-reference/v1.6/#persistentvolume-v1-core)
-* [PersistentVolumeClaim](/docs/api-reference/v1.6/#persistentvolumeclaim-v1-core)
-* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/api-reference/v1.6/#persistentvolumeclaim-v1-core).
+* [PersistentVolume](/docs/api-reference/{{page.version}}/#persistentvolume-v1-core)
+* [PersistentVolumeClaim](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core)
+* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/api-reference/{{page.version}}/#persistentvolumeclaim-v1-core).
 {% endcapture %}

 {% include templates/task.md %}
@@ -3,11 +3,6 @@ assignees:
 - lavalamp
 - thockin
 title: Cluster Management
-redirect_from:
- "/docs/admin/cluster-management/"
- "/docs/admin/cluster-management.html"
- "/docs/concepts/cluster-administration/cluster-management/"
- "/docs/concepts/cluster-administration/cluster-management.html"
 ---

 * TOC
@@ -3,11 +3,6 @@ assignees:
 - davidopp
 - madhusudancs
 title: Configure Multiple Schedulers
-redirect_from:
- "/docs/admin/multiple-schedulers/"
- "/docs/admin/multiple-schedulers.html"
- "/docs/tutorials/clusters/multiple-schedulers/"
- "/docs/tutorials/clusters/multiple-schedulers.html"
 ---

 Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
@@ -3,17 +3,6 @@ assignees:
 - mml
 - wojtek-t
 title: Operating etcd clusters for Kubernetes
-redirect_from:
- "/docs/concepts/storage/etcd-store-api-object/"
- "/docs/concepts/storage/etcd-store-api-object.html"
- "/docs/admin/etcd/"
- "/docs/admin/etcd.html"
- "/docs/admin/etcd_upgrade/"
- "/docs/admin/etcd_upgrade.html"
- "/docs/concepts/cluster-administration/configure-etcd/"
- "/docs/concepts/cluster-administration/configure-etcd.html"
- "/docs/concepts/cluster-administration/etcd-upgrade/"
- "/docs/concepts/cluster-administration/etcd-upgrade.html"
 ---

 etcd is a strong, consistent, and highly-available key value store which Kubernetes uses for persistent storage of all of its API objects. This documentation provides specific instruction on operating, upgrading, and rolling back etcd clusters for Kubernetes. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
@@ -3,11 +3,6 @@ assignees:
 - derekwaynecarr
 - janetkuo
 title: Set Pod CPU and Memory Limits
-redirect_from:
- "/docs/admin/limitrange/"
- "/docs/admin/limitrange/index.html"
- "/docs/tasks/configure-pod-container/limit-range/"
- "/docs/tasks/configure-pod-container/limit-range.html"
 ---

 {% capture overview %}
@@ -103,7 +98,7 @@ deployment "nginx" created
 ```

 Note that `kubectl run` creates a Deployment named "nginx" 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. 
 The Deployment manages 1 replica of single container Pod. Let's take a look at the Pod it manages. First, find the name of the Pod:

 ```shell
@@ -215,8 +210,8 @@ to 512MB of memory.  The cluster operator creates a separate namespace for each
 each namespace.
 3. Users may create a pod which consumes resources just below the capacity of a machine.  The left over space
 may be too small to be useful, but big enough for the waste to be costly over the entire cluster.  As a result,
-the cluster operator may want to set limits that a pod must consume at least 20% of the memory and CPU of their
-average node size in order to provide for more uniform scheduling and limit waste.
+the cluster operator may want to set limits that a pod must consume no more than 20% of the memory and CPU of
+their average node size in order to provide for more uniform scheduling and limit waste.

 ## Summary

@@ -3,14 +3,9 @@ assignees:
 - caseydavenport
 - danwinship
 title: Declare Network Policy
-redirect_from:
- "/docs/getting-started-guides/network-policy/walkthrough/"
- "/docs/getting-started-guides/network-policy/walkthrough.html"
- "/docs/tasks/configure-pod-container/declare-network-policy/"
- "/docs/tasks/configure-pod-container/declare-network-policy.html"
 ---
 {% capture overview %}
-This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/user-guide/network-policies) to declare network policies that govern how pods communicate with each other. 
+This document helps you get started using using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
 {% endcapture %}

 {% capture prerequisites %}
@@ -148,7 +148,7 @@ program to retrieve the contents of your secret.
 Since secrets are encrypted on write, performing an update on a secret will encrypt that content.

 ```
-kubectl get secrets -o json | kubectl update -f -
+kubectl get secrets -o json | kubectl replace -f -
 ```

 The command above reads all secrets and then updates them to apply server side encryption.
@@ -165,7 +165,7 @@ the presence of a highly available deployment where multiple `kube-apiserver` pr
 2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key
 3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config
 4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key
-5. Run `kubectl get secrets -o json | kubectl update -f -` to update all secrets
+5. Run `kubectl get secrets -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
 6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets

 With a single `kube-apiserver`, step 2 may be skipped
@@ -189,7 +189,7 @@ resources:
          secret: <BASE 64 ENCODED SECRET>
 ```

-and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets -o json | kubectl update -f -`
+and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets -o json | kubectl replace -f -`
 to force all secrets to be decrypted.

 {% endcapture %}
@@ -4,11 +4,6 @@ assignees:
 - filipg
 - piosz
 title: Guaranteed Scheduling For Critical Add-On Pods
-redirect_from:
- "/docs/admin/rescheduler/"
- "/docs/admin/rescheduler.html"
- "/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods/"
- "/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods.html"
 ---

 * TOC
--- a/Show More
+++ b/Show More