Sync up between dev-1.18 and master branches (#19055)

* Fixed outdated ECR credential debug message (#18631) * Fixed outdated ECR credential debug message The log message for troubleshooting kubelet auto fetching ECR credentils issue has been changed (noticed since 1.14), and the new message reads like this when verbose log level is set to 3: - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API` - `aws_credentials.go:116] Got ECR credentials from ECR API for <Your ECR AWS Account ID>.dkr.ecr.us-east-1.amazonaws.com` This is based on the kubelet source code: https://github.com/kubernetes/kubernetes/blob/release-1.14/pkg/credentialprovider/aws/aws_credentials.go#L91 This PR is to fix this and to avoid confusion for more people who are troubleshooting the kubelet ECR issue. * Update content/en/docs/concepts/containers/images.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Fix deployment name in docs/tasks/administer-cluster/dns-horizontal-autoscaling.md (#18772) * ru/docs/tutorials/hello-minikube.md: sync with English translation. (#18687) * content/ru/docs/concepts/_index.md: use English names for kinds. (#18613) * Fix French typo in "when" section (#18786) * First Japanese l10n work for release-1.16 (#18790) * Translate concepts/services-networking/connect-applications-service/ into Japanese (#17710) * Translate concepts/services-networking/connect-applications-service/ into Japanese * Apply review * Translate content/ja/docs/tasks/_index.md into Japanese (#17789) * add task index * huge page * ja-docs: Update kops Installation Steps (#17804) * Update /ja/docs/tasks/tools/install-minikube/ (#17711) * Update /ja/docs/tasks/tools/install-minikube/ * Apply review * Apply review * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/tools/install-minikube.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/assign-cpu-resource/ in Japanese (#16160) * copy from content/en/docs/tasks/configure-pod-container/ to ja * translate assign-cpu-resource.md in Japanese * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/configure-pod-container/assign-cpu-resource.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update assign-cpu-resource.md ここの *request* と *limit* はほかの文中の単語とは異なり、YAMLのfieldを表すため、訳さないでおく * fix translation "Pod scheduling is based on requests." の箇所。 requestsに基づいているのは事実だが、直訳されたときになにを指すのかあいまいなので、対象を具体的に記述 * Translate concepts/workloads/controllers/deployment/ in Japanese #14848 (#17794) * ja-trans: Translate concepts/workloads/controllers/deployment/ into Japanese (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * ja-trans: Improve Japanese translation in concepts/workloads/controllers/deployment/ (#14848) * little fix (#18135) * update index (#18136) * Update /ja/docs/setup/_index.md (#18139) * Update /ja/docs/tasks/tools/install-kubectl/ (#18137) * update /docs/ja/tasks/tools/install-kubectl/ * fix mongon * apply reveiw * Update /ja/docs/reference/command-line-tools-reference/feature-gates/ (#18141) * Update feature agete * tidy up feature gates list * translate new lines * table caption * blank * する -> します * apply review * fix broken link * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * update translation * remove line * Update content/ja/docs/reference/command-line-tools-reference/feature-gates.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * rollpack * Update /ja/docs/concepts/services-networking/service/ (#18138) * update /ja/docs/concepts/services-networking/service/ * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/services-networking/service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * consider Endpoints as a Kubernetes resource * full * Update content/ja/docs/concepts/_index.md (#18145) * Update concepts * control plane * apply review * fix bold (#18165) * Update /ja/docs/concepts/overview/components.md (#18153) * update /ja/docs/concepts/overview/components.md * some japanese docs are already there * translate prepend * apply upstream changes (#18278) * Translate concepts/services-networking/ingress into Japanese #17741 (#18234) * ja-trans: Translate concepts/services-networking/ingress into Japanese (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * ja-trans: Improve Japanese translation in concepts/services-networking/ingress (#17741) * Update pod overview in Japanese (#18277) * Update pod-overview * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * ノード * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/concepts/workloads/pods/pod-overview.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/scheduling/scheduler-perf-tuning/ in Japanese #17119 (#17796) * ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) * ja-trans:conetent/ja/casestudies/nav (#18450) * Translate tasks/debug-application-cluster/debug-service/ in Japanese (#18395) * Translate tasks/debug-application-cluster/debug-service/ in Japanese * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Change all `Pods` to `Pod` and `Endpoints` to `Endpoint` * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Updated content pointed out in review * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply suggestions from review * Apply suggestions form review * Apply suggestions from review * Apply suggestions from review * Apply suggestions from code review Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/debug-application-cluster/debug-service.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese (#18200) * Translate concepts/extend-kubernetes/api-extension/custom-resources/ into Japanese * Apply suggestions from code review between L1 an L120 by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update CustomResourceDefinition not to localize into Japanese * Revert the link to customresourcedefinitions to English Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Apply suggestions from code review by oke-py and inductor Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-Authored-By: inductor <kohei.ota@zozo.com> * Apply a suggestion from review by inductor * Apply a suggestion from code review by oke-py Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese (#16173) * copy from content/en/docs/tasks/configure-pod-container/quality-service-pod.md to Ja * Translate tasks/configure-pod-container/quality-service-pod/ into Japanese Guaranteed, Burstable, BestEffortは用語として存在するので訳さない Signed-off-by: Takuma Hashimoto <takumaxd+github@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * Update content/ja/docs/tasks/configure-pod-container/quality-service-pod.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) (#18285) * Translate content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Translated kubectl cheet sheet. * Fix typos in content/ja/docs/reference/kubectl/cheatsheet.md (#17739) * Fix japanese style in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix translation in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Fix typo in content/ja/docs/reference/kubectl/cheatsheet.md * Modify translation for casestudies (#18767) * modify terminology * add ten * update translation * update * update * update * fix typo (#18769) * remove english comment (#18770) * ja-trans:conetent/ja/casestudies/spotify (#18451) * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Updated with the proposal from inductor Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Updated with inductor 's proposal Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: content/ja/case-studies/spotify * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> * Update content/ja/case-studies/spotify/index.html Co-Authored-By: inductor <kohei.ota@zozo.com> Co-authored-by: inductor <kohei.ota@zozo.com> * Translate Japanese headers (#18776) * translate headers * add index for references * Update content/ja/docs/setup/production-environment/tools/_index.md Co-Authored-By: Naoki Oketani <okepy.naoki@gmail.com> * translate controller Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> * ja-docs: translate install-kubeadm into Japanese (#18198) * ja-docs: translate install-kubeadm into Japanese * translate table title in install-kubeadm to Japanese * update kubeadm install doc * remove extra spaces * fix translation miss * translate url title into japanese * fix translation miss * remove line break in sentence and translate title * remove extra line break * remove extra line break * fix translation miss Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com> * delete zh SEE ALSO(51-54) (#18788) * Added missing brackets in markdown (#18783) * Fix broken links in api_changes doc (#18743) * fix jump (#18781) * fix redundant note (#18780) * Fix typo: default-manager -> default-scheduler (#18709) like #18649 #18708 * fix issue #18738 (#18773) Signed-off-by: Dominic Yin <yindongchao@inspur.com> * Correct description of kubectl (#18172) * Correct description of kubectl Given that `kubectl` is not a [command line interface (CLI)](https://en.wikipedia.org/wiki/Command-line_interface), I suggest calling it what it is -- a control utility (ctl = control). The term "tool" is commonly used in place of "utility," including the `kubectl` docs. A CLI presents the user with a command prompt at which the user can enter multiple command lines that a command-line interpreter interprets and processes. Think of `bash`, `emacs`, or a SQL shell. Since `kubectl` is not run in a shell, it is not a CLI. Here are related docs that correctly refer to `kubectl` as a "command-line tool": - https://kubernetes.io/docs/reference/tools/#kubectl - https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-kubectl - https://kubernetes.io/docs/tasks/tools/install-kubectl/ - https://kubernetes.io/docs/reference/kubectl/kubectl/ * Update content/en/docs/reference/kubectl/overview.md Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> * Add blog post: Reviewing 2019 in Docs (#18662) Tiny fix Feedback from onlydole Add missing link Incremental fixes Revise Jim's job title Update content/en/blog/_posts/2020-01-17-Docs-Review-2019.md Co-Authored-By: Celeste Horgan <celeste@cncf.io> Feedback from celeste, change date * Update OWNERS_ALIASES (#18803) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> * blog: introduce CSI support for ephemeral inline volumes (#16832) * csi-ephemeral-inline-volumes: introduce CSI support for ephemeral inline volumes This was alpha in Kubernetes 1.15 and became beta in 1.16. Several CSI drivers already support it (soon...). * csi-ephemeral-inline-volumes: bump date and address feedback (NodeUnpublishVolume) * csi-ephemeral-inline-volumes: add examples and next steps * csi-ephemeral-inline-volumes: rename file, minor edits * csi-ephemeral-inline-volumes: include Docker example * Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md (#18062) * Create 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update and rename 2019-12-10-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md * Update and rename 2019-01-16-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md to 2019-01-22-Gamified-Chaos-Engineering-Tool-for-Kubernetes.md Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> * Revert "Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#16869)" (#18805) This reverts commit 2c4545e105. * add blog k8s on mips (#18795) * add blog k8s on mips * modify english title to chinese * modify some error * Remove user-journeys legacy content #18615 (#18779) * Use monospace for HostFolder and VM in the French Minikube setup guide. (#18749) * Add French version of persistent volume page concept page (#18706) * Add French version of persistent volume page concept page * Fix * Fix * Fix * Fix * sync content/zh/docs/reference/issues-security/ en zh (#18727) * update zh-translation: /docs/concepts/storage/volume-snapshots.md (#18650) * Clean up user journeys content for zh (#18815) * Followup fixes for: Add resource version section to api-concepts (#18069) * Followup fixes for: Add resource version section to api-concepts documentation * Apply feedback * Apply feedback * Switch paragraph to active voice * Add Community and Code of Conduct for ID (#18828) * Add additional ways to contribute part to update zh doc (#18762) * Add additional ways to contribute part to update zh doc * Add original English text * Update content/zh/docs/contribute/_index.md Co-Authored-By: chentanjun <tanjunchen20@gmail.com> Co-authored-by: chentanjun <tanjunchen20@gmail.com> * Clean up extensions/v1beta1 in docs (#18839) * fix an example path (#18848) * Translating network plugins (#17184) * Fix for a typo (#18822) * tą instalację -> tę instalację / (https://sjp.pwn.pl/poradnia/haslo/te-czy-ta;1598.html) (#18801) * Fix typo in Scalability section (#18866) The phrase `very larger` is not valid, it is supposed to be either `very large` or `larger`. Propose to have it `very large`. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Add Polish translation of Contribute index page (#18775) Co-Authored-By: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> * Clean up extensions/v1beta1 in docs (#18838) * Add Indonesian Manage Compute Resources page (#18468) * Add Indonesian Manage Compute Resources page * Updates to id Manage Compute Resources page * Add DaemonSet docs ID localization (#18632) Signed-off-by: giovanism <giovanism@outlook.co.id> * Fix typo in en/docs/contribute/style/content-guilde.md (#18862) * partial fix for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted #18411 (#18875) * See Also removed file 31 * see also removed file 32 * see also removed file 33 * see also removed file 34 * see also removed file 35 * Modify pod.md (#18818) website/content/ko/docs/concepts/workloads/pods/pod.md 23 line 쿠버네티스는는 -> 쿠버네티스는 modify * remove $ following the style guide (#18855) * Add Hyperlink to Kubernetes API (#18852) * Drive by copy edit of blog post (#18881) * Medium copy edit. * more fixes * Translate Events Calendar (#18860) * Adding Bahasa Indonesia translation for Device Plugin page #18676 (#18676) Co-Authored-By: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> * change escaped chars to markdown (#18858) Helps to keep doc clean for long term * Fix header layout on Safari (#18888) * Fix references to sig-docs-l10n-admins (#18661) * Add French deployment concept page (#18516) * Add French deployment concept page * Fix * Fix * Fix * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/concepts/workloads/controllers/deployment.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Fix ZH security aliases (#18895) * disable simplytunde as an approver due to inactivity. (#18899) Always welcome to come back if able to become active again Signed-off-by: Brad Topol <btopol@us.ibm.com> * install container runtimes without prompts (#18893) In Kubernetes docs, all of the packages that are required to set up the Kubernetes are installed without requiring any prompts through the package manager (like apt or yum) except for the container runtimes. https://kubernetes.io/docs/setup/production-environment/container-runtimes/ So, it would be better to have these installations with prompts (yes) disabled. * Fix small typos (#18886) * Fix small typos Small typos noticed and fixed in: - configure-upgrade-etcd.md - reconfigure-kubelet.md Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Rephrase a paragraph on etcd upgrade en\docs\tasks\administer-cluster\configure-upgrade-etcd.md Following a suggestion in #18886, I've rephrased a sentence on etcd upgrade prerequisites. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Clean up extensions/v1beta1 in docs (#18841) * Update _index.md (#18825) * Run minikube docker-env in a shell-independent way (#18823) * doc: correct pv status for pv protection example. (#18816) * Small editorial fixes in glossary entries (#18807) * Small editorial fixes in glossary entries * Revert the wording in the glossary term for proxy * fix doc conflict regarding postStart (#18806) * kubeadm: improvements to the cert management documentation (#18397) - move the sections about custom certificates and external CA to the kubeadm-certs page - minor cleanups to the kubeadm-certs page, including updated output for the check-expiration command - link the implementation details page to the new locations for custom certs and external CA * fix doc conflict regarding postStart * Grammar (#18785) * grammar: 'to' distributes over 'or' * grammar: reword per app.grammarly.com * grammar: simplify from app.grammarly.com * spelling: etc. * feat: add ephermeral container approach inside pod debug page. (#18754) * doc: add pod security policy reference link to document. (#18729) * doc: add pod security policy reference link to document. * doc: add what's next for pod-security-policy ref. * Revise version requirements (#18688) Assume that the reader is running a version of Kubernetes that supports the Secret resource. * en: Remove kubectl duplicate example (#18656) With #16974 and the removal of --include-uninitialized flag, the second and third examples of kubectl delete become equal, thus leading to duplication and being confusing. Suggest to remove the duplicate and replace it with another example in the future if needed. Observed in v1.16 and v1.17 documentation. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Fix typo for tasks/access-kubernetes-api/configure-aggregation-layer.md (#18652) * Unify runtime references (#18493) - Use the glossary to correctly reference runtimes - Updated runtime class documentation for CRI-O - Removed rktlet from runtimes since its EOL Signed-off-by: Sascha Grunert <sgrunert@suse.com> * Clean up admission controller deprecation example (#18399) * sync zh-trans content/zh/docs/concepts/workloads/pods/ephemeral-containers.md (#18883) * Remove redundant information when deploy flannel on kubernetes include windows node (#18272) * sync zh-trans content/zh/docs/concepts/workloads/pods/pod-overview.md (#18882) * partial fix for for SEE ALSO section under content/zh/docs/reference/setup-tools/kubeadm/generated/ need to be deleted (#18879) * see also removed from file 36 * see also removed from file 37 * see also removed from file 38 * see also removed from file 39 * see also removed from file 40 * update zh content/zh/docs/contribute/style/write-new-topic.md (#18859) * sync zh-trans /docs/concepts/_index.md and /docs/concepts/example-concept-template.md (#18863) * See also removed file 56 & 57 (#18912) * see also removed file 56 * see also removed file 57 * Third Korean L10n Work For Release 1.17 (#18915) * Changed some words in the IPv4/IPv6 dual-stack korean doc. (#18668) * Update to Outdated files in dev-1.17-ko.3 branch. (#18580) * Translate content/ko/docs/concepts/services-networking/service in Korean (#18195) * Translate docs/tasks/access-application-cluster/port-forward-access-application-cluster.md in Korean (#18721) * Translate controllers/garbage-collection.md in Korean. (#18595) Co-Authored-by: Seokho Son <shsongist@gmail.com> Co-Authored-by: Lawrence Kay <lkay9495@hotmail.com> Co-Authored-by: Jesang Myung <jesang.myung@gmail.com> Co-Authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> * clean up makefile, config (#18517) Added target for createversiondirs (shell script) in Makefile. updates for tagged release regenerate api ref, rm Makefile_temp add parens to pip check * Improve Russian translation of Home page (#17841) * Improve Russian translation of Home page * Update i18n/ru.toml Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> * Update content/ru/_index.html Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> * Update content/ru/_index.html Co-Authored-By: Slava Semushin <slava.semushin@gmail.com> Co-authored-by: Slava Semushin <slava.semushin@gmail.com> * update ref link for v1.16 (#18837) Related to issue #18820. remove links to prev API refs * Cleanup user journeys related configs and scripts (#18814) * See also removed file 81 to 85 (#18909) * see also removed file 81 * see also removed file 82 * see also removed file 83 * see also removed file 84 * see also removed file 85 * See also removed file 65 to 70 (#18908) * see also removed file 65 * see also removed file 66 * see also removed file 67 * see also removed file 68 * see also removed file 69 * see also removed file 70 * Translate Task index page into Polish (#18876) Co-Authored-By: Karol Pucyński <kpucynski@gmail.com> Co-Authored-By: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> * Document dry-run authorization requirements (#18235) * Document dry-run write access requirement. - Add section on dry-run authorization - Refer to dry-run authorization for diff - Consistently hyphenate dry-run * Update content/en/docs/reference/using-api/api-concepts.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * reword storage release note to match the change in k/k PR #87090 (#18921) * sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18868) * See also removed file 60 to 63 (#18907) * see also removed file 60 * see also removed file 61 * see also removed file 62 * see also removed file 63 * See also removed file 91 to 95 (#18910) * see also removed file 91 * see also removed file 93 * see also removed file 94 * see also removed file 95 * content/zh/docs/concepts/workloads/pods/podpreset.md (#18870) * fix: fixed eating initial 2 spaces inside code. (#18914) * Update Calico section of kubeadm install guide (#18821) * Update Calico section of kubeadm install guide * Address review feedback * See also removed file 96 to 100 (#18911) * see also removed file 96 * see also removed file 97 * see also removed file 98 * see also removed file 99 * see also removed file 100 * repair zh docs in kubeadm (#18949) * repair zh docs about kubeadm (#18950) * Update apparmor.md (#18951) * Update basic-stateful-set.md (#18952) * Add missing hyperlink for pod-overhead (#18936) * Update service.md (#18480) make article reads more smoothly * zh-trans update content/zh/docs/concepts/workloads/controllers/deploy… (#18657) * zh-trans update content/zh/docs/concepts/workloads/controllers/deployment.md * zh-trans update content\zh\docs\concepts\workloads\controllers\deployment.md * Update source-ip documentation (#18760) * sync zh-trans /docs/concepts/workloads/pods/pod.md (#18880) * sync zh-trans /docs/concepts/workloads/controllers/cron-jobs.md and /docs/concepts/workloads/controllers/daemonset.md (#18864) * sync zh-trans content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md (#18867) * Add a French version of Secret concept page (#18604) * Add a French version of Secret concept page * Fix * Fix * Update content/fr/docs/concepts/configuration/secret.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Update content/fr/docs/concepts/configuration/secret.md Co-Authored-By: Aurélien Perrier <aperrier@universe.sh> * Fix Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Aurélien Perrier <aperrier@universe.sh> * (refactor): Corrections (grammatical) in service.md file (#18944) * Update service.md * Fixed the invaild changes Signed-off-by: Udit Gaurav <uditgaurav@gmail.com> * Update container-runtimes.md (#18608) for debian install of docker, also install gnupg2 for apt-key add to work * Fix that dual-stack does not require Kubenet specifically (#18924) * Fix that dual-stack does not require Kubenet specifically Rather it requires a network plugin that supports dual-stack, and others are available, including Calico. * Update content/en/docs/tasks/network/validate-dual-stack.md Added link to doc about network plugins Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Revert "Configurable Scaling for the HPA (#18157)" (#18963) This reverts commit 5dbfaafe1a. * Update horizontal-pod-autoscale-walkthrough.md (#18960) Update command for creating php-apache deployment due to the following warning: `kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.` * doc: add link for type=LoadBalancer service in tutorial. (#18916) * Typo fix (#18830) * sync zh-trans content/zh/docs/concepts/workloads/controllers/statefulset.md (#18869) * Revise pull request template (#18744) * Revise pull request template * Reference compiled docs in PR template Refer readers to https://k8s.io/contribute/start/ This keeps the template short, and it lets Hugo use templating for the current version. * Update certificates.md (#18970) * Add web-ui-dashboard to French (#17974) * Add web-ui-dashboard to French * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Update content/fr/docs/tasks/access-application-cluster/web-ui-dashboard.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix * Fix Co-authored-by: Tim Bannister <tim@scalefactory.com> * Added a translated code of conduct (#18981) * Added a translated code of conduct * fixed some minor mistakes and capitalization * Moved to informal speech * Translate the contribute advanced page to French (#13425) * Translate the contribute advanced page to French * Corrections * Correction * Correction * Correction * Correction * Correction * Fix typo in hello-minikube.md (#18991) * Add note for LB behaviour for cordoned nodes. (#18784) * Add note for LB behaviour for cordoned nodes. See also https://github.com/kubernetes/kubernetes/issues/65013 This is a reasonably common pitfall: `kubectl cordon <all nodes>` will also drop all LB traffic to the cluster, but this is not documented anywhere but in issues, when found it is usually already too late. * Update with feedback * Add KIND as the options for spinning up a test kubernetes environment (#17860) * fix typo in /ja/docs/concepts/workloads/pods/init-containers (#18997) * hide some original comments in translate docs (#18986) * hide original comment * hide some original comments * Fix code of conduct title (#19006) * Added a note about built-in priority-classes (#18979) * Added a note about build-in priority-classes * Update content/en/docs/concepts/configuration/pod-priority-preemption.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Add description for TTL (#19001) * Fix whitespace on deployment page (#18990) * Add details to the API deprecations blog post (#19014) * Document list/map/structType and listMapKeys (#18977) These markers where introduced to describe topology of lists, maps, structs - primarily in support of server-side apply. Secondarily, a small typo fix:) * Remove "Unschedulable" pod condition type from the pod lifecycle docs (#18956) The pod lifecycle documentation erroneously indicated `Unschedulable` as a possible `type` of pod condition. That's not true. Only four condition types exist. The `Unschedulable` value is not a type, but one of the possible reasons of the `PodScheduled` condition type. * Revise “Encrypting Secret Data at Rest” (#18810) * Drop reference to old Kubernetes versions At the time of writing, Kubernetes v1.13 is the oldest supported version, and encryption-at-rest is no longer alpha. * Tidy whitespace * Add table caption * Set metadata for required Kubernetes version * maintain the current relative path when switching to other site versions (#18871) * Update kubectl create configmap section (#18885) * Add common examples to Service Topology documentation (#18712) * service topology: add missing 'enabling service topology' page Signed-off-by: Andrew Sy Kim <kiman@vmware.com> * service topology: add common examples Signed-off-by: Andrew Sy Kim <kiman@vmware.com> * updating contrib for ref docs (#18787) more cleanup * fix translate docs format (#19018) * Update nodes.md (#19019) * Translate Contribute index page into Russian (#19022) * Added german translation for Addons page (#19010) * Added german translation for Addons page * Smaller adjustments * removed a english leftover-sentence * consistent spelling of "Add-Ons" * Removed english entry for CoreDNS * Update content/de/docs/concepts/cluster-administration/addons.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Translated a heading Co-authored-by: Tim Bannister <tim@scalefactory.com> * (fix) Removed `-n test` from `kubectl get pv` command (#18877) - PV are cluster scoped rather than namespaced scope - So, there is no need to list it by namespace Signed-off-by: Aman Gupta <aman.gupta@mayadata.io> * Link to setup page about Kind (#18996) Link from /docs/setup/ to /docs/setup/learning-environment/kind/ now that the target page exists. * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md (#18808) * Create Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Taylor Dolezal <onlydole@users.noreply.github.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update content/en/blog/_posts/Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-Authored-By: Bob Killen <killen.bob@gmail.com> * Update Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md * Update and rename Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md to 2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> * Revise glossary entry for Device Plugin (#16291) * Document control plane monitoring (#17578) * Document control plane monitoring * Update content/en/docs/concepts/cluster-administration/monitoring.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Update content/en/docs/concepts/cluster-administration/monitoring.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> * Merge controller-metrics.md into monitoring.md Co-authored-by: Tim Bannister <tim@scalefactory.com> * Document none driver compatibility with non docker runtime. (#17952) * Refined unclear sentence on 3rd party dependencies (#18015) * Refined unclear sentence on 3rd party dependencies I reworded the sentence on third party dependencies a bit in order to make it more sound * Update content/en/docs/concepts/security/overview.md Sounds much better Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Improve network policies concept (#18091) * Adopt website style guidelines * Tweak wording Co-Authored-By: cmluciano <cmluciano@cruznet.org> * Make sample NetworkPolicies downloadable Co-authored-by: cmluciano <cmluciano@cruznet.org> * clean up secret generators (#18320) * Use built-in version check & metadata (#18542) * Reword kubelet live reconfiguration task (#18629) - Revise version requirements - Use glossary tooltips in summary - Use sentence case for headings - Write kubelet in lowercase where appropriate - Add “What's next” section * fix: add dns search record limit note. (#18913) * Remove duplicate content: Roles & Responsibilities (#18920) * Remove duplicate content: Roles & Responsibilities Signed-off-by: Celeste <celeste@cncf.io> Address feedback Signed-off-by: Celeste <celeste@cncf.io> * Apply suggestions from review Co-Authored-By: Zach Corleissen <zacharysarah@users.noreply.github.com> * Link to contribution guidelines Signed-off-by: Celeste Horgan <celeste@cncf.io> * Address PR feedback Signed-off-by: Celeste Horgan <celeste@cncf.io> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> * Fix of pull request #18960 (#18974) * Fix of pull request #18960 * Add yaml configuration file snippets * Remove redundant code snippet for command * Update cheatsheet.md (#18975) * Update cheatsheet.md "List all pods in the namespace, with more details" command corrected by adding --all-namespaces * Update content/en/docs/reference/kubectl/cheatsheet.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com> * Correct description of Knitter CNI plugin (#18983) * Add Elastic metricbeat to examples of DaemonSets and rename logstash (#19024) * Add Elastic metricbeat to examples of DaemonSets The URL points to the docs related to how to configure metricbeat on k8s * Filebeat is the next thing * Separated commands from output (#19023) * Update KubeCon URLs (#19027) The URLs had changed (and were being redirected). Also, added parameters to better identify the traffic source. * remove see also and close issue (#19032) * sync zh-trans content/zh/docs/concepts/workloads/controllers/garbage-collection.md (#18865) * zh trans /docs/reference/access-authn-authz/extensible-admission-controllers.md (#18856) * Update zh/docs/concepts/services-networking/dns-pod-service.md#pods (#18992) * Adding contribution best practice in contribute docs (#18059) * Add kubectl patch example with quotes on Windows (#18853) * Add kubectl patch example with quotes on Windows When running the `kubectl patch` example, on Windows systems you get an error when passing the patch request in single quotes. Passing it in double quotes with the inner ones escaped produced the desired behavior as is in the example given for Linux systems. I've added a small note for Windows users to have that in mind. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Use Hugo note shortcode Windows note is placed inside a [shortcode](https://kubernetes.io/docs/contribute/style/style-guide/#shortcodes) to be consistent with the style guide. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Remove shell Markdown syntax I've removed the shell syntax from the Windows example and have changed the description to be the same as the one used in [jsonpath](https://kubernetes.io/docs/reference/kubectl/jsonpath/) document to be more consistent. The jsonpath example uses cmd syntax, though it is note inside a note shortcode, therefore I've opted out of using any syntax as it seems to break rendering inside the shortcode. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Add cmd markdown syntax and fix order list I've tested this locally with `make docker-serve` on my Linux machine and finally things are looking better, I've managed to address these two issues: - the Windows example is now inside `note` shortcode and also the cmd syntax renders correctly on the page - the list of steps broke after the first one, I've indented a paragraph and now the steps are in the expected order Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Remove command prompt from example According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included when showing an example. This commit removes it for consistency with the style guide. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * cleanup /docs/concepts/workloads/pods/pod-lifecycle/ (#19009) * update nodes.md (#18987) 将“用量低”更改为“可用量低”，避免歧义 * Remove command prompt from Windows example (#18906) * Remove command prompt from Windows example According to the [style guide](https://kubernetes.io/docs/contribute/style/style-guide/#don-t-include-the-command-prompt), the command prompt should not be included in the examples. Removing the Windows command prompt from the jsonpath example. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Put Windows example inside note shortcode I'm putting the Windows example in a Hug note shortcode to be consistent with the rest of the documentation. Signed-off-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> * Updated CHANGELOG-11 link (#19036) * update command used to create deployment (#19005) The previous one was showing a deprecation warning when used. * Update Korean localization guide (#19004) rev1-Update Korean localization guide * docs: fix broken etcd's official documents link (#19021) * Update automated-tasks-with-cron-jobs.md (#19043) Co-authored-by: Xin Chen <xchen@opq.com.au> Co-authored-by: Tim Bannister <tim@scalefactory.com> Co-authored-by: lemon <lemonli@users.noreply.github.com> Co-authored-by: Slava Semushin <slava.semushin@gmail.com> Co-authored-by: Olivier Cloirec <5033885+clook@users.noreply.github.com> Co-authored-by: inductor <kohei.ota@zozo.com> Co-authored-by: Naoki Oketani <okepy.naoki@gmail.com> Co-authored-by: Samuel Kihahu <kihahu@users.noreply.github.com> Co-authored-by: Takuma Hashimoto <takuma-hashimoto@freee.co.jp> Co-authored-by: Keita Akutsu <kakts.git@gmail.com> Co-authored-by: Masa Taniguchi <maabou512@gmail.com> Co-authored-by: Soto Sugita <sotoiwa@gmail.com> Co-authored-by: Kozzy Hasebe <48105562+hasebe@users.noreply.github.com> Co-authored-by: kazuaki harada <canhel.4suti50y.salamander@gmail.com> Co-authored-by: Shunsuke Miyoshi <s.miyoshi@jp.fujitsu.com> Co-authored-by: hato wang <26351545+wyyxd2017@users.noreply.github.com> Co-authored-by: xieyanker <xjsisnice@gmail.com> Co-authored-by: zhouya0 <50729202+zhouya0@users.noreply.github.com> Co-authored-by: littleboy <zhaoze01@inspur.com> Co-authored-by: camper42 <camper.xlii@gmail.com> Co-authored-by: Dominic Yin <hi@ydcool.me> Co-authored-by: Steve Bang <stevebang@gmail.com> Co-authored-by: Zach Corleissen <zacharysarah@users.noreply.github.com> Co-authored-by: Ryan McGinnis <ryanmcginnis@users.noreply.github.com> Co-authored-by: Shunde Zhang <shunde.p.zhang@gmail.com> Co-authored-by: Bob Killen <killen.bob@gmail.com> Co-authored-by: Taylor Dolezal <onlydole@users.noreply.github.com> Co-authored-by: Patrick Ohly <patrick.ohly@intel.com> Co-authored-by: Eugenio Marzo <eugenio.marzo@yahoo.it> Co-authored-by: Kaitlyn Barnard <kaitlynbarnard10@gmail.com> Co-authored-by: TimYin <shiguangyin@inspur.com> Co-authored-by: Shivang Goswami <shivang.goswami@infosys.com> Co-authored-by: Fabian Baumanis <fabian.baumanis@gmx.de> Co-authored-by: Rémy Léone <remy.leone@gmail.com> Co-authored-by: chentanjun <tanjunchen20@gmail.com> Co-authored-by: helight <helight@helight.info> Co-authored-by: Jie Shen <drfish.me@gmail.com> Co-authored-by: Joe Betz <jpbetz@google.com> Co-authored-by: Danni Setiawan <danninov@users.noreply.github.com> Co-authored-by: GoodGameZoo <gaoguangze111@gmail.com> Co-authored-by: makocchi <makocchi@gmail.com> Co-authored-by: babang <prabangkoro@users.noreply.github.com> Co-authored-by: Sharjeel Aziz <sharjeel.aziz@gmail.com> Co-authored-by: Wojtek Cichoń <wojtek.cichon@protonmail.com> Co-authored-by: Mariyan Dimitrov <mariyan.dimitrov@gmail.com> Co-authored-by: Maciej Filocha <12587791+mfilocha@users.noreply.github.com> Co-authored-by: Michał Sochoń <kaszpir@gmail.com> Co-authored-by: Yudi A Phanama <11147376+phanama@users.noreply.github.com> Co-authored-by: Giovan Isa Musthofa <giovanism@outlook.co.id> Co-authored-by: Park Sung Taek <tjdxor8223@gmail.com> Co-authored-by: Kyle Smith <kylessmith@protonmail.com> Co-authored-by: craigbox <craig.box@gmail.com> Co-authored-by: Afrizal Fikri <laser.survivor@gmail.com> Co-authored-by: Gede Wahyu Adi Pramana <tokekbesi@gmail.com> Co-authored-by: Anshu Prateek <333902+anshprat@users.noreply.github.com> Co-authored-by: Sergei Zyubin <sergei@crate.io> Co-authored-by: Christoph Blecker <admin@toph.ca> Co-authored-by: Brad Topol <btopol@us.ibm.com> Co-authored-by: Venkata Harshavardhan Reddy Allu <venkataharshavardhan_ven@srmuniv.edu.in> Co-authored-by: KYamani <yamani.kamel@gmail.com> Co-authored-by: Trishank Karthik Kuppusamy <33133073+trishankatdatadog@users.noreply.github.com> Co-authored-by: Jacky Wu <Colstuwjx@gmail.com> Co-authored-by: Gerasimos Dimitriadis <gedimitr@gmail.com> Co-authored-by: Rajat Toshniwal <rnt.rajat@gmail.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Sascha Grunert <sgrunert@suse.com> Co-authored-by: wawa <xiaozhang0210@hotmail.com> Co-authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com> Co-authored-by: Karen Bradshaw <kbhawkey@gmail.com> Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com> Co-authored-by: Karol Pucyński <9209870+kpucynski@users.noreply.github.com> Co-authored-by: Julian V. Modesto <julianvmodesto@gmail.com> Co-authored-by: Jeremy L. Morris <jeremylevanmorris@gmail.com> Co-authored-by: Casey Davenport <caseydavenport@users.noreply.github.com> Co-authored-by: zhanwang <zhanw15@gmail.com> Co-authored-by: wwgfhf <51694849+wwgfhf@users.noreply.github.com> Co-authored-by: harleyliao <357857613@qq.com> Co-authored-by: ten2ton <50288981+ten2ton@users.noreply.github.com> Co-authored-by: Aurélien Perrier <aperrier@universe.sh> Co-authored-by: UDIT GAURAV <35391335+uditgaurav@users.noreply.github.com> Co-authored-by: Rene Luria <rene@luria.ch> Co-authored-by: Neil Jerram <neiljerram@gmail.com> Co-authored-by: Arjun <arjunrn@users.noreply.github.com> Co-authored-by: Katarzyna Kańska <katarzyna.m.kanska@gmail.com> Co-authored-by: Laurens Versluis <lfdversluis@users.noreply.github.com> Co-authored-by: Ray76 <rayfoo55@gmail.com> Co-authored-by: Alexander Zimmermann <7714821+alexzimmer96@users.noreply.github.com> Co-authored-by: Christian Meter <cmeter@googlemail.com> Co-authored-by: MMeent <boekewurm@gmail.com> Co-authored-by: RA489 <rohit.anand@india.nec.com> Co-authored-by: Akira Tanimura <autopp.inc@gmail.com> Co-authored-by: Patouche <Patouche@users.noreply.github.com> Co-authored-by: Jordan Liggitt <jordan@liggitt.net> Co-authored-by: Maria Ntalla <maria.ntalla@gmail.com> Co-authored-by: Marko Lukša <marko.luksa@gmail.com> Co-authored-by: John Morrissey <jwm@horde.net> Co-authored-by: Andrew Sy Kim <kim.andrewsy@gmail.com> Co-authored-by: ngsw <ngsw@ngsw.jp> Co-authored-by: Aman Gupta <aman.gupta@mayadata.io> Co-authored-by: Marek Siarkowicz <marek.siarkowicz@protonmail.com> Co-authored-by: tom1299 <tom1299@users.noreply.github.com> Co-authored-by: cmluciano <cmluciano@cruznet.org> Co-authored-by: Celeste Horgan <celeste@cncf.io> Co-authored-by: Prasad Honavar <prasadhonavar@gmail.com> Co-authored-by: Sam <sammcj@users.noreply.github.com> Co-authored-by: Victor Martinez <victormartinezrubio@gmail.com> Co-authored-by: Dan Kohn <dan@linuxfoundation.org> Co-authored-by: vishakha <54327666+vishakhanihore@users.noreply.github.com> Co-authored-by: liyinda246 <liyinda0000@163.com> Co-authored-by: Kabir Kwatra <kabir@kwatra.me> Co-authored-by: Armand Grillet <2117580+armandgrillet@users.noreply.github.com> Co-authored-by: Junwoo Ji <jydrogen@gmail.com> Co-authored-by: rm <rajib.jolite@gmail.com>
2020-02-11 04:15:53 +05:30
parent fb1c0e8b77
commit 63f30b086a
313 changed files with 18391 additions and 6502 deletions
@@ -45,12 +45,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
        <br>
        <br>
        <br>
        <br>
-        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
+        <a href="https://www.lfasiallc.cn/kubecon-cloudnativecon-open-source-summit-china/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncch20" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -12,21 +12,45 @@ When APIs evolve, the old API is deprecated and eventually removed.

 The **v1.16** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:

-* NetworkPolicy (in the **extensions/v1beta1** API group)
-  * Migrate to use the **networking.k8s.io/v1** API, available since v1.8.
-    Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1** API.
-* PodSecurityPolicy (in the **extensions/v1beta1** API group)
+* NetworkPolicy in the **extensions/v1beta1** API version is no longer served
+  * Migrate to use the **networking.k8s.io/v1** API version, available since v1.8.
+    Existing persisted data can be retrieved/updated via the new version.
+* PodSecurityPolicy in the **extensions/v1beta1** API version
  * Migrate to use the **policy/v1beta1** API, available since v1.10.
-    Existing persisted data can be retrieved/updated via the **policy/v1beta1** API.
-* DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the **extensions/v1beta1** and **apps/v1beta2** API groups)
-  * Migrate to use the **apps/v1** API, available since v1.9.
-    Existing persisted data can be retrieved/updated via the **apps/v1** API.
+    Existing persisted data can be retrieved/updated via the new version.
+* DaemonSet in the **extensions/v1beta1** and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.templateGeneration` is removed
+      * `spec.selector` is now required and immutable after creation
+      * `spec.updateStrategy.type` now defaults to `RollingUpdate`
+* Deployment in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.rollbackTo` is removed
+      * `spec.selector` is now required and immutable after creation
+      * `spec.progressDeadlineSeconds` now defaults to `600` seconds
+      * `spec.revisionHistoryLimit` now defaults to `10`
+      * `maxSurge` and `maxUnavailable` now default to `25%`
+* StatefulSet in the **apps/v1beta1** and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.selector` is now required and immutable after creation
+      * `spec.updateStrategy.type` now defaults to `RollingUpdate`
+* ReplicaSet in the **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions is no longer served
+  * Migrate to use the **apps/v1** API version, available since v1.9.
+    Existing persisted data can be retrieved/updated via the new version.
+  * Notable changes:
+      * `spec.selector` is now required and immutable after creation

 The **v1.20** release will stop serving the following deprecated API versions in favor of newer and more stable API versions:

-* Ingress (in the **extensions/v1beta1** API group)
-  * Migrate to use the **networking.k8s.io/v1beta1** API, serving Ingress since v1.14.
-    Existing persisted data can be retrieved/updated via the **networking.k8s.io/v1beta1** API.
+* Ingress in the **extensions/v1beta1** API version will no longer be served
+  * Migrate to use the **networking.k8s.io/v1beta1** API version, available since v1.14.
+    Existing persisted data can be retrieved/updated via the new version.

 # What To Do

@@ -0,0 +1,99 @@
+---
+layout: blog
+title: "Reviewing 2019 in Docs"
+date: 2020-01-21
+slug: reviewing-2019-in-docs
+---
+
+**Author:** Zach Corleissen (Cloud Native Computing Foundation)
+
+Hi, folks! I'm one of the co-chairs for the Kubernetes documentation special interest group (SIG Docs). This blog post is a review of SIG Docs in 2019. Our contributors did amazing work last year, and I want to highlight their successes. 
+
+Although I review 2019 in this post, my goal is to point forward to 2020. I observe some trends in SIG Docs–some good, others troubling. I want to raise visibility before those challenges increase in severity.
+
+## The good
+
+There was much to celebrate in SIG Docs in 2019.
+
+Kubernetes docs started the year with three localizations in progress. By the end of the year, we ended with ten localizations available, four of which (Chinese, French, Japanese, Korean) are reasonably complete. The Korean and French teams deserve special mentions for their contributions to git best practices across all localizations (Korean team) and help bootstrapping other localizations (French team).
+
+Despite significant transition over the year, SIG Docs [improved its review velocity](https://k8s.devstats.cncf.io/d/44/pr-time-to-approve-and-merge?orgId=1&var-period=w&var-repogroup_name=SIG%20Docs&var-apichange=All&var-size_name=All&var-kind_name=All), with a median review time from PR open to merge of just over 24 hours. 
+
+Issue triage improved significantly in both volume and speed, largely due to the efforts of GitHub users @sftim, @tengqm, and @kbhawkey. 
+
+Doc sprints remain valuable at KubeCon contributor days, introducing new contributors to Kubernetes documentation.
+
+The docs component of Kubernetes quarterly releases improved over 2019, thanks to iterative playbook improvements from release leads and their teams.
+
+Site traffic increased over the year. The website ended the year with ~6 million page views per month in December, up from ~5M page views in January. The kubernetes.io website had 851k site visitors in October, a new all-time high. Reader satisfaction [remains general](https://kubernetes.io/blog/2019/10/29/kubernetes-documentation-end-user-survey/).
+
+We onboarded a new SIG chair: @jimangel, a Cloud Architect at General Motors. Jim was a docs contributor for a year, during which he led the 1.14 docs release, before stepping up as chair.
+
+
+
+## The not so good
+
+While reader satisfaction is decent, **most respondents indicated dissatisfaction with stale content** in every area: concepts, tasks, tutorials, and reference. Additionally, readers requested more diagrams, advanced conceptual content, and code samples&mdash;things that technical writers excel at providing.
+
+SIG Docs continues to solve how best to handle [third-party content](https://github.com/kubernetes/enhancements/pull/1327). **There's too much vendor content on kubernetes.io**, and guidelines for adding or rejecting third-party content remain unclear. The discussion so far has been powerful, including pushback demanding greater collaborative input&mdash;a powerful reminder that Kubernetes is in all ways a communal effort.
+
+
+We're in the middle of our third chair transition in 18 months. Each chair transition has been healthy and collegial, but it's still a lot of turnover in a short time. Chairing any open source project is difficult, but especially so with SIG Docs. Chairship of SIG Docs requires a steep learning curve across multiple domains: docs (both written and generated from spec), information architecture, specialized contribution paths (for example, localization), how to run a release cycle, website development, CI/CD, community management, on and on. It's a role that requires multiple people to function successfully without burning people out. Training replacements is time-intensive.
+
+Perhaps most pressing in the Not So Good category is that SIG Docs currently has only one technical writer dedicated full-time to Kubernetes docs. This has impacts on Kubernetes docs: some obvious, some less so.
+
+## Impacts of understaffing on Kubernetes docs
+
+<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Me today: <a href="https://t.co/cDpHOWEsjf">pic.twitter.com/cDpHOWEsjf</a></p>&mdash; Benjamin Elder (@BenTheElder) <a href="https://twitter.com/BenTheElder/status/1215453579651104768?ref_src=twsrc%5Etfw">January 10, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
+
+If Kubernetes continues through 2020 without more technical writers dedicated to the docs, here's what I see as the most likely possibilities.
+
+### But first, a disclaimer
+
+{{< caution >}}
+
+It is very hard to predict, especially the future.
+-Niels Bohr
+
+{{< /caution >}}
+
+
+Some of my predictions are almost certainly wrong. Any errors are mine alone. 
+
+That said...
+
+### Effects in 2020
+
+Current levels of function aren't self-sustaining. Even with a strong playbook, the release cycle still requires expert support from at least one (and usually two) chairs during every cycle. Without fail, each release breaks in new and unexpected ways, and it requires familiarity and expertise to diagnose and resolve. As chairs continue to cycle&mdash;and to be clear, regular transitions are part of a healthy project&mdash;we accrue the risks associated with a pool lacking sufficient professional depth and employer support.
+
+Oddly enough, one of the challenges to staffing is that the docs appear good enough. Based on site analytics and survey responses, readers are pleased with the quality of the docs. When folks visit the site, they generally find what they need and behave like satisfied visitors.
+
+The danger is that this will change over time: slowly with occasional losses of function, annoying at first, then increasingly critical. The more time passes without adequate staffing, the more difficult and costly fixes will become.
+
+I suspect this is true because the challenges we face now at decent levels of reader satisfaction are already difficult to fix. API reference generation is complex and brittle; the site's UI is outdated; and our most consistent requests are for more tutorials, advanced concepts, diagrams, and code samples, all of which require ongoing, dedicated time to create.
+
+**Release support remains strong.**
+
+The release team continues a solid habit of leaving each successive team with better support than the previous release. This mostly takes the form of iterative improvements to the [docs release playbook](https://github.com/kubernetes/community/tree/master/sig-release#docs-lead), producing better documentation and reducing siloed knowledge.
+
+**Staleness accelerates.**
+
+Conceptual content becomes less accurate or relevant as features change or deprecate. Tutorial content degrades for the same reason.
+
+The content structure will also degrade: the categories of concepts, tasks, and tutorials are legacy categories that may not best fit the needs of current readers, let alone future ones.
+
+Cruft accumulates for both readers and contributors. Reference docs become increasingly brittle without intervention. 
+
+**Critical knowledge vanishes.**
+
+As I mentioned previously, SIG Docs has a wide range of functions, some with a steep learning curve. As contributors change roles or jobs, their expertise and availability will diminish or reduce to zero. Contributors with specific knowledge may not be available for consultation, exposing critical vulnerabilities in docs function. Specific examples include reference generation and chair leadership.
+
+### That's a lot to take in
+
+It's difficult to strike a balance between the importance of SIG Docs' work to the community and our users, the joy it brings me personally, and the fact that things can't remain as they are without significant negative impacts (eventually). SIG Docs is by no means dying; it's a vibrant community with active contributors doing cool things. It's also a community with some critical knowledge and capacity shortages that can only be remedied with trained, paid staff dedicated to documentation.
+
+## What the community can do for healthy docs
+
+Hire technical writers dedicated to Kubernetes docs. Support advanced content creation, not just release docs and incremental feature updates.
+
+Thanks, and Happy 2020.
@@ -0,0 +1,251 @@
+---
+title: CSI Ephemeral Inline Volumes
+date: 2020-01-21
+---
+
+**Author:** Patrick Ohly (Intel)
+
+Typically, volumes provided by an external storage driver in
+Kubernetes are *persistent*, with a lifecycle that is completely
+independent of pods or (as a special case) loosely coupled to the
+first pod which uses a volume ([late binding
+mode](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode)).
+The mechanism for requesting and defining such volumes in Kubernetes
+are [Persistent Volume Claim (PVC) and Persistent Volume
+(PV)](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
+objects. Originally, volumes that are backed by a Container Storage Interface
+(CSI) driver could only be used via this PVC/PV mechanism.
+
+But there are also use cases for data volumes whose content and
+lifecycle is tied to a pod. For example, a driver might populate a
+volume with dynamically created secrets that are specific to the
+application running in the pod. Such volumes need to be created
+together with a pod and can be deleted as part of pod termination
+(*ephemeral*). They get defined as part of the pod spec (*inline*).
+
+Since Kubernetes 1.15, CSI drivers can also be used for such
+*ephemeral inline* volumes. The [CSIInlineVolume feature
+gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)
+had to be set to enable it in 1.15 because support was still in alpha
+state. In 1.16, the feature reached beta state, which typically means
+that it is enabled in clusters by default.
+
+CSI drivers have to be adapted to support this because although two
+existing CSI gRPC calls are used (`NodePublishVolume` and `NodeUnpublishVolume`),
+the way how they are
+used is different and not covered by the CSI spec: for ephemeral
+volumes, only `NodePublishVolume` is invoked by `kubelet` when asking
+the CSI driver for a volume. All other calls
+(like `CreateVolume`, `NodeStageVolume`, etc.) are skipped. The volume
+parameters are provided in the pod spec and from there copied into the
+`NodePublishVolumeRequest.volume_context` field. There are currently
+no standardized parameters; even common ones like size must be
+provided in a format that is defined by the CSI driver. Likewise, only
+`NodeUnpublishVolume` gets called after the pod has terminated and the
+volume needs to be removed.
+
+Initially, the assumption was that CSI drivers would be specifically
+written to provide either persistent or ephemeral volumes. But there
+are also drivers which provide storage that is useful in both modes:
+for example, [PMEM-CSI](https://github.com/intel/pmem-csi) manages
+persistent memory (PMEM), a new kind of local storage that is provided
+by [Intel® Optane™ DC Persistent
+Memory](https://www.intel.com/content/www/us/en/architecture-and-technology/optane-dc-persistent-memory.html). Such
+memory is useful both as persistent data storage (faster than normal SSDs)
+and as ephemeral scratch space (higher capacity than DRAM).
+
+Therefore the support in Kubernetes 1.16 was extended:
+* Kubernetes and users can determine which kind of volumes a driver
+  supports via the `volumeLifecycleModes` field in the [`CSIDriver`
+  object](https://kubernetes-csi.github.io/docs/csi-driver-object.html#what-fields-does-the-csidriver-object-have).
+* Drivers can get information about the volume mode by enabling the
+  ["pod info on
+  mount"](https://kubernetes-csi.github.io/docs/pod-info.html) feature
+  which then will add the new `csi.storage.k8s.io/ephemeral` entry to
+  the `NodePublishRequest.volume_context`.
+
+For more information about implementing support of ephemeral inline
+volumes in a CSI driver, see the [Kubernetes-CSI
+documentation](https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html)
+and the [original design
+document](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190122-csi-inline-volumes.md).
+
+What follows in this blog post are usage examples based on real drivers
+and a summary at the end.
+
+# Examples
+
+## [PMEM-CSI](https://github.com/intel/pmem-csi)
+
+Support for ephemeral inline volumes was added in [release
+v0.6.0](https://github.com/intel/pmem-csi/releases/tag/v0.6.0). The
+driver can be used on hosts with real Intel® Optane™ DC Persistent
+Memory, on [special machines in
+GCE](https://github.com/intel/pmem-csi/blob/v0.6.0/examples/gce.md) or
+with hardware emulated by QEMU. The latter is fully [integrated into
+the
+makefile](https://github.com/intel/pmem-csi/tree/v0.6.0#qemu-and-kubernetes)
+and only needs Go, Docker and KVM, so that approach was used for this
+example:
+
+```sh
+git clone --branch release-0.6 https://github.com/intel/pmem-csi
+cd pmem-csi
+TEST_DISTRO=clear TEST_DISTRO_VERSION=32080 TEST_PMEM_REGISTRY=intel make start
+```
+
+Bringing up the four-node cluster can take a while but eventually should end with:
+
+```
+The test cluster is ready. Log in with /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm, run kubectl once logged in.
+Alternatively, KUBECONFIG=/work/pmem-csi/_work/pmem-govm/kube.config can also be used directly.
+
+To try out the pmem-csi driver persistent volumes:
+...
+
+To try out the pmem-csi driver ephemeral volumes:
+   cat deploy/kubernetes-1.17/pmem-app-ephemeral.yaml | /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm kubectl create -f -
+```
+
+`deploy/kubernetes-1.17/pmem-app-ephemeral.yaml` specifies one volume:
+
+```
+kind: Pod
+apiVersion: v1
+metadata:
+  name: my-csi-app-inline-volume
+spec:
+  containers:
+    - name: my-frontend
+      image: busybox
+      command: [ "sleep", "100000" ]
+      volumeMounts:
+      - mountPath: "/data"
+        name: my-csi-volume
+  volumes:
+  - name: my-csi-volume
+    csi:
+      driver: pmem-csi.intel.com
+      fsType: "xfs"
+      volumeAttributes:
+        size: "2Gi"
+        nsmode: "fsdax"
+```
+
+Once we have created that pod, we can inspect the result:
+
+```sh
+kubectl describe pods/my-csi-app-inline-volume
+```
+
+```
+Name:         my-csi-app-inline-volume
+...
+Volumes:
+  my-csi-volume:
+    Type:              CSI (a Container Storage Interface (CSI) volume source)
+    Driver:            pmem-csi.intel.com
+    FSType:            xfs
+    ReadOnly:          false
+    VolumeAttributes:      nsmode=fsdax
+                           size=2Gi
+```
+
+```sh
+kubectl exec my-csi-app-inline-volume -- df -h /data
+```
+
+```
+Filesystem                Size      Used Available Use% Mounted on
+/dev/ndbus0region0fsdax/d7eb073f2ab1937b88531fce28e19aa385e93696
+                          1.9G     34.2M      1.8G   2% /data
+```
+
+
+## [Image Populator](https://github.com/kubernetes-csi/csi-driver-image-populator)
+
+The image populator automatically unpacks a container image and makes
+its content available as an ephemeral volume. It's still in
+development, but canary images are already available which can be
+installed with:
+
+```sh
+kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-csidriverinfo.yaml
+kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-daemonset.yaml
+```
+
+This example pod will run nginx and have it serve data that
+comes from the `kfox1111/misc:test` image:
+
+```sh
+kubectl create -f - <<EOF
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.13-alpine
+    ports:
+    - containerPort: 80
+    volumeMounts:
+    - name: data
+      mountPath: /usr/share/nginx/html
+  volumes:
+  - name: data
+    csi:
+      driver: image.csi.k8s.io
+      volumeAttributes:
+          image: kfox1111/misc:test
+EOF
+```
+
+```sh
+kubectl exec nginx -- cat /usr/share/nginx/html/test
+```
+
+That `test` file just contains a single word:
+```
+testing
+```
+
+Such data containers can be built with Dockerfiles such as:
+```
+FROM scratch
+COPY index.html /index.html
+```
+
+## [cert-manager-csi](https://github.com/jetstack/cert-manager-csi)
+
+cert-manager-csi works together with
+[cert-manager](https://github.com/jetstack/cert-manager). The goal for
+this driver is to facilitate requesting and mounting certificate key
+pairs to pods seamlessly. This is useful for facilitating mTLS, or
+otherwise securing connections of pods with guaranteed present
+certificates whilst having all of the features that cert-manager
+provides. This project is experimental.
+
+
+# Next steps
+
+One of the issues with ephemeral inline volumes is that pods get
+scheduled by Kubernetes onto nodes without knowing anything about the
+currently available storage on that node. Once the pod has been
+scheduled, the CSI driver must make the volume available one that
+node. If that is currently not possible, the pod cannot start. This
+will be retried until eventually the volume becomes ready. The
+[storage capacity tracking
+KEP](https://github.com/kubernetes/enhancements/pull/1353) is an
+attempt to address this problem.
+
+A related KEP introduces a [standardized size
+parameter](https://github.com/kubernetes/enhancements/pull/1409).
+
+Currently, CSI ephemeral inline volumes stay in beta while issues like
+these are getting discussed. Your feedback is needed to decide how to
+proceed with this feature. For the KEPs, the two PRs linked to above
+is a good place to comment. The SIG Storage also [meets
+regularly](https://github.com/kubernetes/community/tree/master/sig-storage#meetings)
+and can be reached via [Slack and a mailing
+list](https://github.com/kubernetes/community/tree/master/sig-storage#contact).
@@ -0,0 +1,110 @@
+---
+layout: blog
+title: "KubeInvaders - Gamified Chaos Engineering Tool for Kubernetes"
+date: 2020-01-22
+slug: kubeinvaders-gamified-chaos-engineering-tool-for-kubernetes
+---
+
+**Authors** Eugenio Marzo, Sourcesense
+
+Some months ago, I released my latest project called KubeInvaders. The
+first time I shared it with the community was during an Openshift
+Commons Briefing session. Kubenvaders is a Gamified Chaos Engineering
+tool for Kubernetes and Openshift and helps test how resilient your
+Kubernetes cluster is, in a fun way.
+
+It is like Space Invaders, but the aliens are pods.
+
+![](https://github.com/lucky-sideburn/KubeInvaders-kubernetes-post/raw/master/img1.png)
+
+During my presentation at Codemotion Milan 2019, I started saying "of
+course you can do it with few lines of Bash, but it is boring."
+
+![](https://github.com/lucky-sideburn/KubeInvaders-kubernetes-post/raw/master/img2.png)
+
+Using the code above you can kill random pods across a Kubernetes cluster, but I
+think it is much more fun with the spaceship of KubeInvaders.
+
+I published the code at
+[https://github.com/lucky-sideburn/KubeInvaders](https://github.com/lucky-sideburn/KubeInvaders)
+and there is a little community that is growing gradually. Some people
+love to use it for demo sessions killing pods on a big screen.
+
+![](https://github.com/lucky-sideburn/KubeInvaders-kubernetes-post/raw/master/img3.png)
+
+## How to install KubeInvaders
+
+I defined multiples modes to install it:
+
+1.  Helm Chart
+    [https://github.com/lucky-sideburn/KubeInvaders/tree/master/helm-charts/kubeinvaders](https://github.com/lucky-sideburn/KubeInvaders/tree/master/helm-charts/kubeinvaders)
+
+2.  Manual Installation for Openshift using a template
+    [https://github.com/lucky-sideburn/KubeInvaders\#install-kubeinvaders-on-openshift](https://github.com/lucky-sideburn/KubeInvaders#install-kubeinvaders-on-openshift)
+
+3.  Manual Installation for Kubernetes
+    [https://github.com/lucky-sideburn/KubeInvaders\#install-kubeinvaders-on-kubernetes](https://github.com/lucky-sideburn/KubeInvaders#install-kubeinvaders-on-kubernetes)
+
+The preferred way, of course, is with a Helm chart:
+  
+  ```
+  # Please set target_namespace to set your target namespace!
+  helm install --set-string target_namespace="namespace1,namespace2" \
+  --name kubeinvaders --namespace kubeinvaders ./helm-charts/kubeinvaders
+  ```
+
+## How to use KubeInvaders
+
+Once it is installed on your cluster you can use the following
+functionalities:
+
+ * Key 'a' — Switch to automatic pilot
+ * Key 'm' — Switch to manual pilot
+ * Key 'i' — Show pod's name. Move the ship towards an alien
+ * Key 'h' — Print help
+ * Key 'n' — Jump between different namespaces (my favorite feature!)
+
+## Tuning KubeInvaders
+
+At Codemotion Milan 2019, my colleagues and I organized a desk with a
+game station for playing KubeInvaders. People had to fight with Kubernetes to
+win a t-shirt.
+
+If you have pods that require a few seconds to start, you may lose. It
+is possible to set the complexity of the game with these parameters as
+environmment variables in the Kubernetes deployment:
+
+ * ALIENPROXIMITY — Reduce this value to increase the distance between aliens;
+ * HITSLIMIT — Seconds of CPU time to wait before shooting;
+ * UPDATETIME — Seconds to wait before updating pod status (you can set also 0.x Es: 0.5);
+
+The result is a harder game experience against the machine.
+
+## Use cases
+
+Adopting chaos engineering strategies for your production environment is
+really useful, because it is the only way to test if a system supports
+unexpected destructive events.
+
+KubeInvaders is a game — so please do not take it too seriously! — but it demonstrates
+some important use cases:
+
+ * Test how resilient Kubernetes clusters are on unexpected pod deletion
+ * Collect metrics like pod restart time
+ * Tune readiness probes
+
+## Next steps
+
+I want to continue to add some cool features and integrate it into a
+Kubernetes dashboard because I am planning to transform it into a
+"Gamified Chaos Engineering and Development Tool for Kubernetes", to help
+developer to interact with deployments in a Kubernetes environment. For
+example:
+
+ * Point to the aliens to get pod logs
+ * Deploy Helm charts by shooting some particular objects
+ * Read messages stored in a specific label present in a deployment
+
+Please feel free to contribute to
+[https://github.com/lucky-sideburn/KubeInvaders](https://github.com/lucky-sideburn/KubeInvaders)
+and stay updated following \#kubeinvaders news [on Twitter](https://twitter.com/luckysideburn).
@@ -0,0 +1,760 @@
+---
+layout: blog
+title: "Deploying External OpenStack Cloud Provider with Kubeadm"
+date: 2020-02-07
+slug: Deploying-External-OpenStack-Cloud-Provider-with-Kubeadm
+---
+This document describes how to install a single control-plane Kubernetes cluster v1.15 with kubeadm on CentOS, and then deploy an external OpenStack cloud provider and Cinder CSI plugin to use Cinder volumes as persistent volumes in Kubernetes.
+
+### Preparation in OpenStack
+
+This cluster runs on OpenStack VMs, so let's create a few things in OpenStack first.
+
+* A project/tenant for this Kubernetes cluster
+* A user in this project for Kubernetes, to query node information and attach volumes etc
+* A private network and subnet
+* A router for this private network and connect it to a public network for floating IPs
+* A security group for all Kubernetes VMs
+* A VM as a control-plane node and a few VMs as worker nodes
+
+The security group will have the following rules to open ports for Kubernetes.
+
+**Control-Plane Node**
+
+|Protocol  | Port Number | Description|
+|----------|-------------|------------|
+|TCP |6443|Kubernetes API Server|
+|TCP|2379-2380|etcd server client API|
+|TCP|10250|Kubelet API|
+|TCP|10251|kube-scheduler|
+|TCP|10252|kube-controller-manager|
+|TCP|10255|Read-only Kubelet API|
+
+**Worker Nodes**
+
+|Protocol  | Port Number | Description|
+|----------|-------------|------------|
+|TCP|10250|Kubelet API|
+|TCP|10255|Read-only Kubelet API|
+|TCP|30000-32767|NodePort Services|
+
+**CNI ports on both control-plane and worker nodes**
+
+|Protocol  | Port Number | Description|
+|----------|-------------|------------|
+|TCP|179|Calico BGP network|
+|TCP|9099|Calico felix (health check)|
+|UDP|8285|Flannel|
+|UDP|8472|Flannel|
+|TCP|6781-6784|Weave Net|
+|UDP|6783-6784|Weave Net|
+
+CNI specific ports are only required to be opened when that particular CNI plugin is used. In this guide, we will use Weave Net. Only the Weave Net ports (TCP 6781-6784 and UDP 6783-6784), will need to be opened in the security group.
+
+The control-plane node needs at least 2 cores and 4GB RAM. After the VM is launched, verify its hostname and make sure it is the same as the node name in Nova. 
+If the hostname is not resolvable, add it to `/etc/hosts`.
+
+For example, if the VM is called master1, and it has an internal IP 192.168.1.4. Add that to `/etc/hosts` and set hostname to master1.
+```shell
+echo "192.168.1.4 master1" >> /etc/hosts
+
+hostnamectl set-hostname master1
+```
+### Install Docker and Kubernetes
+
+Next, we'll follow the official documents to install docker and Kubernetes using kubeadm.
+
+Install Docker following the steps from the [container runtime](/docs/setup/production-environment/container-runtimes/) documentation.
+
+Note that it is a [best practice to use systemd as the cgroup driver](/docs/setup/production-environment/container-runtimes/#cgroup-drivers) for Kubernetes.
+If you use an internal container registry, add them to the docker config.
+```shell
+# Install Docker CE
+## Set up the repository
+### Install required packages.
+
+yum install yum-utils device-mapper-persistent-data lvm2
+
+### Add Docker repository.
+
+yum-config-manager \
+  --add-repo \
+  https://download.docker.com/linux/centos/docker-ce.repo
+
+## Install Docker CE.
+
+yum update && yum install docker-ce-18.06.2.ce
+
+## Create /etc/docker directory.
+
+mkdir /etc/docker
+
+# Configure the Docker daemon
+
+cat > /etc/docker/daemon.json <<EOF
+{
+  "exec-opts": ["native.cgroupdriver=systemd"],
+  "log-driver": "json-file",
+  "log-opts": {
+    "max-size": "100m"
+  },
+  "storage-driver": "overlay2",
+  "storage-opts": [
+    "overlay2.override_kernel_check=true"
+  ]
+}
+EOF
+
+mkdir -p /etc/systemd/system/docker.service.d
+
+# Restart Docker
+systemctl daemon-reload
+systemctl restart docker
+systemctl enable docker
+```
+
+Install kubeadm following the steps from the [Installing Kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) documentation.
+
+```shell
+cat <<EOF > /etc/yum.repos.d/kubernetes.repo
+[kubernetes]
+name=Kubernetes
+baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
+enabled=1
+gpgcheck=1
+repo_gpgcheck=1
+gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
+EOF
+
+# Set SELinux in permissive mode (effectively disabling it)
+# Caveat: In a production environment you may not want to disable SELinux, please refer to Kubernetes documents about SELinux
+setenforce 0
+sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
+
+yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
+
+systemctl enable --now kubelet
+
+cat <<EOF >  /etc/sysctl.d/k8s.conf
+net.bridge.bridge-nf-call-ip6tables = 1
+net.bridge.bridge-nf-call-iptables = 1
+EOF
+sysctl --system
+
+# check if br_netfilter module is loaded
+lsmod | grep br_netfilter
+
+# if not, load it explicitly with 
+modprobe br_netfilter
+```
+
+The official document about how to create a single control-plane cluster can be found from the [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) documentation.
+
+We'll largely follow that document but also add additional things for the cloud provider.
+To make things more clear, we'll use a `kubeadm-config.yml` for the control-plane node.
+In this config we specify to use an external OpenStack cloud provider, and where to find its config.
+We also enable storage API in API server's runtime config so we can use OpenStack volumes as persistent volumes in Kubernetes.
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta1
+kind: InitConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    cloud-provider: "external"
+---
+apiVersion: kubeadm.k8s.io/v1beta2
+kind: ClusterConfiguration
+kubernetesVersion: "v1.15.1"
+apiServer:
+  extraArgs:
+    enable-admission-plugins: NodeRestriction
+    runtime-config: "storage.k8s.io/v1=true"
+controllerManager:
+  extraArgs:
+    external-cloud-volume-plugin: openstack
+  extraVolumes:
+  - name: "cloud-config"
+    hostPath: "/etc/kubernetes/cloud-config"
+    mountPath: "/etc/kubernetes/cloud-config"
+    readOnly: true
+    pathType: File
+networking:
+  serviceSubnet: "10.96.0.0/12"
+  podSubnet: "10.224.0.0/16"
+  dnsDomain: "cluster.local"
+```
+
+Now we'll create the cloud config, `/etc/kubernetes/cloud-config`, for OpenStack. 
+Note that the tenant here is the one we created for all Kubernetes VMs in the beginning.
+All VMs should be launched in this project/tenant.
+In addition you need to create a user in this tenant for Kubernetes to do queries.
+The ca-file is the CA root certificate for OpenStack's API endpoint, for example `https://openstack.cloud:5000/v3`
+At the time of writing the cloud provider doesn't allow insecure connections (skip CA check).
+
+```ini
+[Global]
+region=RegionOne
+username=username
+password=password
+auth-url=https://openstack.cloud:5000/v3
+tenant-id=14ba698c0aec4fd6b7dc8c310f664009
+domain-id=default
+ca-file=/etc/kubernetes/ca.pem
+
+[LoadBalancer]
+subnet-id=b4a9a292-ea48-4125-9fb2-8be2628cb7a1
+floating-network-id=bc8a590a-5d65-4525-98f3-f7ef29c727d5
+
+[BlockStorage]
+bs-version=v2
+
+[Networking]
+public-network-name=public
+ipv6-support-disabled=false
+```
+
+Next run kubeadm to initiate the control-plane node
+```shell
+kubeadm init --config=kubeadm-config.yml
+```
+
+With the initialization completed, copy admin config to .kube
+```shell
+  mkdir -p $HOME/.kube
+  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
+  sudo chown $(id -u):$(id -g) $HOME/.kube/config
+```
+
+At this stage, the control-plane node is created but not ready. All the nodes have the taint `node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule` and are waiting to be initialized by the cloud-controller-manager.
+```console
+# kubectl describe no master1
+Name:               master1
+Roles:              master
+......
+Taints:             node-role.kubernetes.io/master:NoSchedule
+                    node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule
+                    node.kubernetes.io/not-ready:NoSchedule
+......
+```
+Now deploy the OpenStack cloud controller manager into the cluster, following [using controller manager with kubeadm](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-controller-manager-with-kubeadm.md).
+
+Create a secret with the cloud-config for the openstack cloud provider. 
+```shell
+kubectl create secret -n kube-system generic cloud-config --from-literal=cloud.conf="$(cat /etc/kubernetes/cloud-config)" --dry-run -o yaml > cloud-config-secret.yaml
+kubectl apply -f cloud-config-secret.yaml 
+```
+
+Get the CA certificate for OpenStack API endpoints and put that into `/etc/kubernetes/ca.pem`.
+
+Create RBAC resources.
+```shell
+kubectl apply -f https://github.com/kubernetes/cloud-provider-openstack/raw/release-1.15/cluster/addons/rbac/cloud-controller-manager-roles.yaml
+kubectl apply -f https://github.com/kubernetes/cloud-provider-openstack/raw/release-1.15/cluster/addons/rbac/cloud-controller-manager-role-bindings.yaml
+```
+
+We'll run the OpenStack cloud controller manager as a DaemonSet rather than a pod.
+The manager will only run on the control-plane node, so if there are multiple control-plane nodes, multiple pods will be run for high availability.
+Create `openstack-cloud-controller-manager-ds.yaml` containing the following manifests, then apply it.
+
+```yaml
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: cloud-controller-manager
+  namespace: kube-system
+---
+apiVersion: apps/v1
+kind: DaemonSet
+metadata:
+  name: openstack-cloud-controller-manager
+  namespace: kube-system
+  labels:
+    k8s-app: openstack-cloud-controller-manager
+spec:
+  selector:
+    matchLabels:
+      k8s-app: openstack-cloud-controller-manager
+  updateStrategy:
+    type: RollingUpdate
+  template:
+    metadata:
+      labels:
+        k8s-app: openstack-cloud-controller-manager
+    spec:
+      nodeSelector:
+        node-role.kubernetes.io/master: ""
+      securityContext:
+        runAsUser: 1001
+      tolerations:
+      - key: node.cloudprovider.kubernetes.io/uninitialized
+        value: "true"
+        effect: NoSchedule
+      - key: node-role.kubernetes.io/master
+        effect: NoSchedule
+      - effect: NoSchedule
+        key: node.kubernetes.io/not-ready
+      serviceAccountName: cloud-controller-manager
+      containers:
+        - name: openstack-cloud-controller-manager
+          image: docker.io/k8scloudprovider/openstack-cloud-controller-manager:v1.15.0
+          args:
+            - /bin/openstack-cloud-controller-manager
+            - --v=1
+            - --cloud-config=$(CLOUD_CONFIG)
+            - --cloud-provider=openstack
+            - --use-service-account-credentials=true
+            - --address=127.0.0.1
+          volumeMounts:
+            - mountPath: /etc/kubernetes/pki
+              name: k8s-certs
+              readOnly: true
+            - mountPath: /etc/ssl/certs
+              name: ca-certs
+              readOnly: true
+            - mountPath: /etc/config
+              name: cloud-config-volume
+              readOnly: true
+            - mountPath: /usr/libexec/kubernetes/kubelet-plugins/volume/exec
+              name: flexvolume-dir
+            - mountPath: /etc/kubernetes
+              name: ca-cert
+              readOnly: true
+          resources:
+            requests:
+              cpu: 200m
+          env:
+            - name: CLOUD_CONFIG
+              value: /etc/config/cloud.conf
+      hostNetwork: true
+      volumes:
+      - hostPath:
+          path: /usr/libexec/kubernetes/kubelet-plugins/volume/exec
+          type: DirectoryOrCreate
+        name: flexvolume-dir
+      - hostPath:
+          path: /etc/kubernetes/pki
+          type: DirectoryOrCreate
+        name: k8s-certs
+      - hostPath:
+          path: /etc/ssl/certs
+          type: DirectoryOrCreate
+        name: ca-certs
+      - name: cloud-config-volume
+        secret:
+          secretName: cloud-config
+      - name: ca-cert
+        secret:
+          secretName: openstack-ca-cert
+```
+
+When the controller manager is running, it will query OpenStack to get information about the nodes and remove the taint. In the node info you'll see the VM's UUID in OpenStack.
+```console
+# kubectl describe no master1
+Name:               master1
+Roles:              master
+......
+Taints:             node-role.kubernetes.io/master:NoSchedule
+                    node.kubernetes.io/not-ready:NoSchedule
+......
+sage:docker: network plugin is not ready: cni config uninitialized
+......
+PodCIDR:                     10.224.0.0/24
+ProviderID:                  openstack:///548e3c46-2477-4ce2-968b-3de1314560a5
+
+```
+Now install your favourite CNI and the control-plane node will become ready.
+
+For example, to install Weave Net, run this command:
+```shell
+kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
+```
+
+Next we'll set up worker nodes.
+
+Firstly, install docker and kubeadm in the same way as how they were installed in the control-plane node. 
+To join them to the cluster we need a token and ca cert hash from the output of control-plane node installation. 
+If it is expired or lost we can recreate it using these commands.
+
+```shell
+# check if token is expired
+kubeadm token list
+
+# re-create token and show join command
+kubeadm token create --print-join-command
+
+```
+
+Create `kubeadm-config.yml` for worker nodes with the above token and ca cert hash.
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta2
+discovery:
+  bootstrapToken:
+    apiServerEndpoint: 192.168.1.7:6443
+    token: 0c0z4p.dnafh6vnmouus569
+    caCertHashes: ["sha256:fcb3e956a6880c05fc9d09714424b827f57a6fdc8afc44497180905946527adf"]
+kind: JoinConfiguration
+nodeRegistration:
+  kubeletExtraArgs:
+    cloud-provider: "external"
+
+```
+apiServerEndpoint is the control-plane node, token and caCertHashes can be taken from the join command printed in the output of 'kubeadm token create' command.
+
+Run kubeadm and the worker nodes will be joined to the cluster.
+```shell
+kubeadm join  --config kubeadm-config.yml 
+```
+
+At this stage we'll have a working Kubernetes cluster with an external OpenStack cloud provider.
+The provider tells Kubernetes about the mapping between Kubernetes nodes and OpenStack VMs.
+If Kubernetes wants to attach a persistent volume to a pod, it can find out which OpenStack VM the pod is running on from the mapping, and attach the underlying OpenStack volume to the VM accordingly.
+
+### Deploy Cinder CSI
+
+The integration with Cinder is provided by an external Cinder CSI plugin, as described in the [Cinder CSI](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) documentation.
+
+We'll perform the following steps to install the Cinder CSI plugin.
+Firstly, create a secret with CA certs for OpenStack's API endpoints. It is the same cert file as what we use in cloud provider above.
+```shell
+kubectl create secret -n kube-system generic openstack-ca-cert --from-literal=ca.pem="$(cat /etc/kubernetes/ca.pem)" --dry-run -o yaml > openstack-ca-cert.yaml
+kubectl apply -f openstack-ca-cert.yaml
+```
+Then create RBAC resources.
+```shell
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/release-1.15/manifests/cinder-csi-plugin/cinder-csi-controllerplugin-rbac.yaml
+kubectl apply -f https://github.com/kubernetes/cloud-provider-openstack/raw/release-1.15/manifests/cinder-csi-plugin/cinder-csi-nodeplugin-rbac.yaml
+```
+
+The Cinder CSI plugin includes a controller plugin and a node plugin.
+The controller communicates with Kubernetes APIs and Cinder APIs to create/attach/detach/delete Cinder volumes. The node plugin in-turn runs on each worker node to bind a storage device (attached volume) to a pod, and unbind it during deletion.
+Create `cinder-csi-controllerplugin.yaml` and apply it to create csi controller.
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: csi-cinder-controller-service
+  namespace: kube-system
+  labels:
+    app: csi-cinder-controllerplugin
+spec:
+  selector:
+    app: csi-cinder-controllerplugin
+  ports:
+    - name: dummy
+      port: 12345
+
+---
+kind: StatefulSet
+apiVersion: apps/v1
+metadata:
+  name: csi-cinder-controllerplugin
+  namespace: kube-system
+spec:
+  serviceName: "csi-cinder-controller-service"
+  replicas: 1
+  selector:
+    matchLabels:
+      app: csi-cinder-controllerplugin
+  template:
+    metadata:
+      labels:
+        app: csi-cinder-controllerplugin
+    spec:
+      serviceAccount: csi-cinder-controller-sa
+      containers:
+        - name: csi-attacher
+          image: quay.io/k8scsi/csi-attacher:v1.0.1
+          args:
+            - "--v=5"
+            - "--csi-address=$(ADDRESS)"
+          env:
+            - name: ADDRESS
+              value: /var/lib/csi/sockets/pluginproxy/csi.sock
+          imagePullPolicy: "IfNotPresent"
+          volumeMounts:
+            - name: socket-dir
+              mountPath: /var/lib/csi/sockets/pluginproxy/
+        - name: csi-provisioner
+          image: quay.io/k8scsi/csi-provisioner:v1.0.1
+          args:
+            - "--provisioner=csi-cinderplugin"
+            - "--csi-address=$(ADDRESS)"
+          env:
+            - name: ADDRESS
+              value: /var/lib/csi/sockets/pluginproxy/csi.sock
+          imagePullPolicy: "IfNotPresent"
+          volumeMounts:
+            - name: socket-dir
+              mountPath: /var/lib/csi/sockets/pluginproxy/
+        - name: csi-snapshotter
+          image: quay.io/k8scsi/csi-snapshotter:v1.0.1
+          args:
+            - "--connection-timeout=15s"
+            - "--csi-address=$(ADDRESS)"
+          env:
+            - name: ADDRESS
+              value: /var/lib/csi/sockets/pluginproxy/csi.sock
+          imagePullPolicy: Always
+          volumeMounts:
+            - mountPath: /var/lib/csi/sockets/pluginproxy/
+              name: socket-dir
+        - name: cinder-csi-plugin
+          image: docker.io/k8scloudprovider/cinder-csi-plugin:v1.15.0
+          args :
+            - /bin/cinder-csi-plugin
+            - "--v=5"
+            - "--nodeid=$(NODE_ID)"
+            - "--endpoint=$(CSI_ENDPOINT)"
+            - "--cloud-config=$(CLOUD_CONFIG)"
+            - "--cluster=$(CLUSTER_NAME)"
+          env:
+            - name: NODE_ID
+              valueFrom:
+                fieldRef:
+                  fieldPath: spec.nodeName
+            - name: CSI_ENDPOINT
+              value: unix://csi/csi.sock
+            - name: CLOUD_CONFIG
+              value: /etc/config/cloud.conf
+            - name: CLUSTER_NAME
+              value: kubernetes
+          imagePullPolicy: "IfNotPresent"
+          volumeMounts:
+            - name: socket-dir
+              mountPath: /csi
+            - name: secret-cinderplugin
+              mountPath: /etc/config
+              readOnly: true
+            - mountPath: /etc/kubernetes
+              name: ca-cert
+              readOnly: true
+      volumes:
+        - name: socket-dir
+          hostPath:
+            path: /var/lib/csi/sockets/pluginproxy/
+            type: DirectoryOrCreate
+        - name: secret-cinderplugin
+          secret:
+            secretName: cloud-config
+        - name: ca-cert
+          secret:
+            secretName: openstack-ca-cert
+```
+
+
+Create `cinder-csi-nodeplugin.yaml` and apply it to create csi node.
+```yaml
+kind: DaemonSet
+apiVersion: apps/v1
+metadata:
+  name: csi-cinder-nodeplugin
+  namespace: kube-system
+spec:
+  selector:
+    matchLabels:
+      app: csi-cinder-nodeplugin
+  template:
+    metadata:
+      labels:
+        app: csi-cinder-nodeplugin
+    spec:
+      serviceAccount: csi-cinder-node-sa
+      hostNetwork: true
+      containers:
+        - name: node-driver-registrar
+          image: quay.io/k8scsi/csi-node-driver-registrar:v1.1.0
+          args:
+            - "--v=5"
+            - "--csi-address=$(ADDRESS)"
+            - "--kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)"
+          lifecycle:
+            preStop:
+              exec:
+                command: ["/bin/sh", "-c", "rm -rf /registration/cinder.csi.openstack.org /registration/cinder.csi.openstack.org-reg.sock"]
+          env:
+            - name: ADDRESS
+              value: /csi/csi.sock
+            - name: DRIVER_REG_SOCK_PATH
+              value: /var/lib/kubelet/plugins/cinder.csi.openstack.org/csi.sock
+            - name: KUBE_NODE_NAME
+              valueFrom:
+                fieldRef:
+                  fieldPath: spec.nodeName
+          imagePullPolicy: "IfNotPresent"
+          volumeMounts:
+            - name: socket-dir
+              mountPath: /csi
+            - name: registration-dir
+              mountPath: /registration
+        - name: cinder-csi-plugin
+          securityContext:
+            privileged: true
+            capabilities:
+              add: ["SYS_ADMIN"]
+            allowPrivilegeEscalation: true
+          image: docker.io/k8scloudprovider/cinder-csi-plugin:v1.15.0
+          args :
+            - /bin/cinder-csi-plugin
+            - "--nodeid=$(NODE_ID)"
+            - "--endpoint=$(CSI_ENDPOINT)"
+            - "--cloud-config=$(CLOUD_CONFIG)"
+          env:
+            - name: NODE_ID
+              valueFrom:
+                fieldRef:
+                  fieldPath: spec.nodeName
+            - name: CSI_ENDPOINT
+              value: unix://csi/csi.sock
+            - name: CLOUD_CONFIG
+              value: /etc/config/cloud.conf
+          imagePullPolicy: "IfNotPresent"
+          volumeMounts:
+            - name: socket-dir
+              mountPath: /csi
+            - name: pods-mount-dir
+              mountPath: /var/lib/kubelet/pods
+              mountPropagation: "Bidirectional"
+            - name: kubelet-dir
+              mountPath: /var/lib/kubelet
+              mountPropagation: "Bidirectional"
+            - name: pods-cloud-data
+              mountPath: /var/lib/cloud/data
+              readOnly: true
+            - name: pods-probe-dir
+              mountPath: /dev
+              mountPropagation: "HostToContainer"
+            - name: secret-cinderplugin
+              mountPath: /etc/config
+              readOnly: true
+            - mountPath: /etc/kubernetes
+              name: ca-cert
+              readOnly: true
+      volumes:
+        - name: socket-dir
+          hostPath:
+            path: /var/lib/kubelet/plugins/cinder.csi.openstack.org
+            type: DirectoryOrCreate
+        - name: registration-dir
+          hostPath:
+            path: /var/lib/kubelet/plugins_registry/
+            type: Directory
+        - name: kubelet-dir
+          hostPath:
+            path: /var/lib/kubelet
+            type: Directory
+        - name: pods-mount-dir
+          hostPath:
+            path: /var/lib/kubelet/pods
+            type: Directory
+        - name: pods-cloud-data
+          hostPath:
+            path: /var/lib/cloud/data
+            type: Directory
+        - name: pods-probe-dir
+          hostPath:
+            path: /dev
+            type: Directory
+        - name: secret-cinderplugin
+          secret:
+            secretName: cloud-config
+        - name: ca-cert
+          secret:
+            secretName: openstack-ca-cert
+
+```
+When they are both running, create a storage class for Cinder.
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: csi-sc-cinderplugin
+provisioner: csi-cinderplugin
+```
+Then we can create a PVC with this class.
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: myvol
+spec:
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi
+  storageClassName: csi-sc-cinderplugin
+
+```
+
+When the PVC is created, a Cinder volume is created correspondingly.
+```console
+# kubectl get pvc
+NAME    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
+myvol   Bound    pvc-14b8bc68-6c4c-4dc6-ad79-4cb29a81faad   1Gi        RWO            csi-sc-cinderplugin   3s
+
+```
+In OpenStack the volume name will match the Kubernetes persistent volume generated name. In this example it would be: _pvc-14b8bc68-6c4c-4dc6-ad79-4cb29a81faad_
+
+Now we can create a pod with the PVC. 
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: web
+spec:
+  containers:
+    - name: web
+      image: nginx
+      ports:
+        - name: web
+          containerPort: 80
+          hostPort: 8081
+          protocol: TCP
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: mypd
+  volumes:
+    - name: mypd
+      persistentVolumeClaim:
+        claimName: myvol
+```
+When the pod is running, the volume will be attached to the pod.
+If we go back to OpenStack, we can see the Cinder volume is mounted to the worker node where the pod is running on.
+```console
+# openstack volume show 6b5f3296-b0eb-40cd-bd4f-2067a0d6287f
+--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| Field                          | Value                                                                                                                                                                                                                                                                                                                          |
+--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| attachments                    | [{u'server_id': u'1c5e1439-edfa-40ed-91fe-2a0e12bc7eb4', u'attachment_id': u'11a15b30-5c24-41d4-86d9-d92823983a32', u'attached_at': u'2019-07-24T05:02:34.000000', u'host_name': u'compute-6', u'volume_id': u'6b5f3296-b0eb-40cd-bd4f-2067a0d6287f', u'device': u'/dev/vdb', u'id': u'6b5f3296-b0eb-40cd-bd4f-2067a0d6287f'}] |
+| availability_zone              | nova                                                                                                                                                                                                                                                                                                                           |
+| bootable                       | false                                                                                                                                                                                                                                                                                                                          |
+| consistencygroup_id            | None                                                                                                                                                                                                                                                                                                                           |
+| created_at                     | 2019-07-24T05:02:18.000000                                                                                                                                                                                                                                                                                                     |
+| description                    | Created by OpenStack Cinder CSI driver                                                                                                                                                                                                                                                                                         |
+| encrypted                      | False                                                                                                                                                                                                                                                                                                                          |
+| id                             | 6b5f3296-b0eb-40cd-bd4f-2067a0d6287f                                                                                                                                                                                                                                                                                           |
+| migration_status               | None                                                                                                                                                                                                                                                                                                                           |
+| multiattach                    | False                                                                                                                                                                                                                                                                                                                          |
+| name                           | pvc-14b8bc68-6c4c-4dc6-ad79-4cb29a81faad                                                                                                                                                                                                                                                                                       |
+| os-vol-host-attr:host          | rbd:volumes@rbd#rbd                                                                                                                                                                                                                                                                                                            |
+| os-vol-mig-status-attr:migstat | None                                                                                                                                                                                                                                                                                                                           |
+| os-vol-mig-status-attr:name_id | None                                                                                                                                                                                                                                                                                                                           |
+| os-vol-tenant-attr:tenant_id   | 14ba698c0aec4fd6b7dc8c310f664009                                                                                                                                                                                                                                                                                               |
+| properties                     | attached_mode='rw', cinder.csi.openstack.org/cluster='kubernetes'                                                                                                                                                                                                                                                              |
+| replication_status             | None                                                                                                                                                                                                                                                                                                                           |
+| size                           | 1                                                                                                                                                                                                                                                                                                                              |
+| snapshot_id                    | None                                                                                                                                                                                                                                                                                                                           |
+| source_volid                   | None                                                                                                                                                                                                                                                                                                                           |
+| status                         | in-use                                                                                                                                                                                                                                                                                                                         |
+| type                           | rbd                                                                                                                                                                                                                                                                                                                            |
+| updated_at                     | 2019-07-24T05:02:35.000000                                                                                                                                                                                                                                                                                                     |
+| user_id                        | 5f6a7a06f4e3456c890130d56babf591                                                                                                                                                                                                                                                                                               |
+--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+
+```
+
+### Summary
+
+In this walk-through, we deployed a Kubernetes cluster on OpenStack VMs and integrated it with OpenStack using an external OpenStack cloud provider. Then on this Kubernetes cluster we deployed Cinder CSI plugin which can create Cinder volumes and expose them in Kubernetes as persistent volumes.
@@ -275,6 +275,12 @@ and do not respect the unschedulable attribute on a node. This assumes that daem
 the machine even if it is being drained of applications while it prepares for a reboot.
 {{< /note >}}

+{{< caution >}}
+`kubectl cordon` marks a node as 'unschedulable', which has the side effect of the service
+controller removing the node from any LoadBalancer node target lists it was previously 
+eligible for, effectively removing incoming load balancer traffic from the cordoned node(s).
+{{< /caution >}}
+
 ### Node capacity

 The capacity of the node (number of cpus and amount of memory) is part of the node object.
@@ -28,7 +28,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
 * [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
 * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
-* [Knitter](https://github.com/ZTE/Knitter/) is a network solution supporting multiple networking in Kubernetes.
+* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
 * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
@@ -1,50 +0,0 @@
---
-title: Controller manager metrics
-content_template: templates/concept
-weight: 100
---
-
-{{% capture overview %}}
-Controller manager metrics provide important insight into the performance and health of
-the controller manager.
-
-{{% /capture %}}
-
-{{% capture body %}}
-## What are controller manager metrics
-
-Controller manager metrics provide important insight into the performance and health of the controller manager.
-These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
-etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
-to gauge the health of a cluster.
-
-Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
-These metrics can be used to monitor health of persistent volume operations.
-
-For example, for GCE these metrics are called:
-
-```
-cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
-cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
-cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
-cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
-```
-
-
-
-## Configuration
-
-
-In a cluster, controller-manager metrics are available from `http://localhost:10252/metrics`
-from the host where the controller-manager is running.
-
-The metrics are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
-
-In a production environment you may want to configure prometheus or some other metrics scraper
-to periodically gather these metrics and make them available in some kind of time series database.
-
-{{% /capture %}}
-
-
@@ -0,0 +1,132 @@
+---
+title: Metrics For The Kubernetes Control Plane
+reviewers:
+- brancz
+- logicalhan
+- RainbowMango
+content_template: templates/concept
+weight: 60
+aliases:
+- controller-metrics.md
+---
+
+{{% capture overview %}}
+
+System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
+
+Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Metrics in Kubernetes
+
+In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag.
+
+Examples of those components:
+* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}
+* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}
+* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
+* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
+* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
+
+In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper
+to periodically gather these metrics and make them available in some kind of time series database.
+
+Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle.
+
+If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`.
+For example:
+```
+apiVersion: rbac.authorization.k8s.io/v1	
+kind: ClusterRole	
+metadata:	
+  name: prometheus	
+rules:	
+  - nonResourceURLs:	
+      - "/metrics"	
+    verbs:	
+      - get
+```
+
+## Metric lifecycle
+
+Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deletion
+
+Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time.
+
+Stable metrics can be guaranteed to not change; Specifically, stability means:
+
+* the metric itself will not be deleted (or renamed)
+* the type of metric will not be modified
+
+Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated.
+
+Before deprecation:
+
+```
+# HELP some_counter this counts things
+# TYPE some_counter counter
+some_counter 0
+```
+
+After deprecation:
+
+```
+# HELP some_counter (Deprecated since 1.15.0) this counts things
+# TYPE some_counter counter
+some_counter 0
+```
+
+Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component.
+
+Once a metric is deleted, the metric is not published. You cannot change this using an override.
+
+
+## Show Hidden Metrics
+
+As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
+
+The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release. The version is expressed as x.y, where x is the major version, y is the minor version. The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is the metrics deprecation policy runs against the minor release.
+
+The flag can only take the previous minor version as it's value. All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`. The too old version is not allowed because this violates the metrics deprecated policy.
+
+Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. According to metrics deprecated policy, we can reach the following conclusion:
+
+* In release `1.n`, the metric is deprecated, and it can be emitted by default.
+* In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`.
+* In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore.
+
+If you're upgrading from release `1.12` to `1.13`, but still depend on a metric `A` deprecated in `1.12`, you should set hidden metrics via command line: `--show-hidden-metrics=1.12` and remember to remove this metric dependency before upgrading to `1.14`
+
+## Component metrics
+
+### kube-controller-manager metrics
+
+Controller manager metrics provide important insight into the performance and health of the controller manager.
+These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as
+etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used
+to gauge the health of a cluster.
+
+Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack.
+These metrics can be used to monitor health of persistent volume operations.
+
+For example, for GCE these metrics are called:
+
+```
+cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
+cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
+cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
+cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
+* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
+* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
+{{% /capture %}}
@@ -62,6 +62,12 @@ To use priority and preemption in Kubernetes 1.11 and later, follow these steps:

 Keep reading for more information about these steps.

+{{< note >}}
+Kubernetes already ships with two PriorityClasses:
+`system-cluster-critical` and `system-node-critical`.
+These are common classes and are used to [ensure that critical components are always scheduled first](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
+{{< /note >}}
+
 If you try the feature and then decide to disable it, you must remove the
 PodPriority command-line flag or set it to `false`, and then restart the API
 server and scheduler. After the feature is disabled, the existing Pods keep
@@ -73,6 +73,7 @@ A toleration "matches" a taint if the keys are the same and the effects are the
 `Operator` defaults to `Equal` if not specified.

 {{< note >}}
+
 There are two special cases:

 * An empty `key` with operator `Exists` matches all keys, values and effects which means this
@@ -88,8 +89,9 @@ tolerations:
 ```yaml
 tolerations:
 - key: "key"
-  operator: "Exists"
+      operator: "Exists"
 ```
+
 {{< /note >}}

 The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`.
@@ -124,9 +124,9 @@ Troubleshooting:
 - Verify all requirements above.
 - Get $REGION (e.g. `us-west-2`) credentials on your workstation. SSH into the host and run Docker manually with those creds. Does it work?
 - Verify kubelet is running with `--cloud-provider=aws`.
- Check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like:
-  - `plugins.go:56] Registering credential provider: aws-ecr-key`
-  - `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
+- Increase kubelet log level verbosity to at least 3 and check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like:
+  - `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
+  - `aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com`

 ### Using Azure Container Registry (ACR)
 When using [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/)
@@ -120,7 +120,7 @@ For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/

 Kubernetes built-in dockershim CRI does not support runtime handlers.

-#### [containerd](https://containerd.io/)
+#### {{< glossary_tooltip term_id="containerd" >}}

 Runtime handlers are configured through containerd's configuration at
 `/etc/containerd/config.toml`. Valid handlers are configured under the runtimes section:
@@ -132,19 +132,20 @@ Runtime handlers are configured through containerd's configuration at
 See containerd's config documentation for more details:
 https://github.com/containerd/cri/blob/master/docs/config.md

-#### [cri-o](https://cri-o.io/)
+#### {{< glossary_tooltip term_id="cri-o" >}}

-Runtime handlers are configured through cri-o's configuration at `/etc/crio/crio.conf`. Valid
+Runtime handlers are configured through CRI-O's configuration at `/etc/crio/crio.conf`. Valid
 handlers are configured under the [crio.runtime
-table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table):
+table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table):

 ```
 [crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"
 ```

-See cri-o's config documentation for more details:
-https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
+See CRI-O's [config documentation][100] for more details.
+
+[100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md

 ### Scheduling

@@ -44,7 +44,7 @@ The controller interprets the structured data as a record of the user's
 desired state, and continually maintains this state.

 You can deploy and update a custom controller on a running cluster, independently
-of the cluster's own lifecycle. Custom controllers can work with any kind of resource,
+of the cluster's lifecycle. Custom controllers can work with any kind of resource,
 but they are especially effective when combined with custom resources. The
 [Operator pattern](https://coreos.com/blog/introducing-operators.html) combines custom
 resources and custom controllers. You can use custom controllers to encode domain knowledge
@@ -61,7 +61,7 @@ When creating a new API, consider whether to [aggregate your API with the Kubern
 | You want to view your new types in a Kubernetes UI, such as dashboard, alongside built-in types. | Kubernetes UI support is not required. |
 | You are developing a new API. | You already have a program that serves your API and works well. |
 | You are willing to accept the format restriction that Kubernetes puts on REST resource paths, such as API Groups and Namespaces. (See the [API Overview](/docs/concepts/overview/kubernetes-api/).) | You need to have specific REST paths to be compatible with an already defined REST API. |
-| Your resources are naturally scoped to a cluster or to namespaces of a cluster. | Cluster or namespace scoped resources are a poor fit; you need control over the specifics of resource paths. |
+| Your resources are naturally scoped to a cluster or namespaces of a cluster. | Cluster or namespace scoped resources are a poor fit; you need control over the specifics of resource paths. |
 | You want to reuse [Kubernetes API support features](#common-features).  | You don't need those features. |

 ### Declarative APIs
@@ -83,7 +83,7 @@ Signs that your API might not be declarative include:
 - You talk about Remote Procedure Calls (RPCs).
 - Directly storing large amounts of data (e.g. > a few kB per object, or >1000s of objects).
 - High bandwidth access (10s of requests per second sustained) needed.
- - Store end-user data (such as images, PII, etc) or other large-scale data processed by applications.
+ - Store end-user data (such as images, PII, etc.) or other large-scale data processed by applications.
 - The natural operations on the objects are not CRUD-y.
 - The API is not easily modeled as objects.
 - You chose to represent pending operations with an operation ID or an operation object.
@@ -96,7 +96,7 @@ Use a ConfigMap if any of the following apply:
 * You want to put the entire config file into one key of a configMap.
 * The main use of the config file is for a program running in a Pod on your cluster to consume the file to configure itself.
 * Consumers of the file prefer to consume via file in a Pod or environment variable in a pod, rather than the Kubernetes API.
-* You want to perform rolling updates via Deployment, etc, when the file is updated.
+* You want to perform rolling updates via Deployment, etc., when the file is updated.

 {{< note >}}
 Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
@@ -140,7 +140,7 @@ and use a controller to handle events.

 ## API server aggregation

-Usually, each resource in the Kubernetes API requires code that handles REST requests and manages 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 [CRDs](#customresourcedefinitions).
+Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also generically handle custom resources through [CRDs](#customresourcedefinitions).

 The [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows you to provide specialized
 implementations for your custom resources by writing and deploying your own standalone API server.
@@ -305,7 +305,7 @@ PersistentVolumeClaim  storage   1Gi  2Gi  -                -              -
 {{< codenew file="admin/resource/pvc-limit-lower.yaml" >}}

 ```shell
-kubectl create -f https://k8s.io/examples/admin/resource//pvc-limit-lower.yaml -n limitrange-demo
+kubectl create -f https://k8s.io/examples/admin/resource/pvc-limit-lower.yaml -n limitrange-demo
 ```

 While creating a PVC with `requests.storage` lower than the Min value in the LimitRange, an Error thrown by the server:
@@ -341,7 +341,7 @@ kubectl apply -f https://k8s.io/examples/admin/resource/limit-memory-ratio-pod.y
 Describe the <limit-memory-ratio-pod> LimitRange with the following kubectl command:

 ```shell
-$ kubectl describe limitrange/limit-memory-ratio-pod
+kubectl describe limitrange/limit-memory-ratio-pod
 ```

 ```shell
@@ -22,7 +22,7 @@ updates.
 ## What is a Pod Security Policy?

 A _Pod Security Policy_ is a cluster-level resource that controls security
-sensitive aspects of the pod specification. The `PodSecurityPolicy` objects
+sensitive aspects of the pod specification. The [PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects
 define a set of conditions that a pod must run with in order to be accepted into
 the system, as well as defaults for the related fields. They allow an
 administrator to control the following:
@@ -626,3 +626,9 @@ Refer to the [Sysctl documentation](
 /docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy).

 {{% /capture %}}
+
+{{% capture whatsnext %}}
+
+Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
+
+{{% /capture %}}
@@ -142,7 +142,7 @@ Area of Concern for Code | Recommendation |
 --------------------------------------------- | ------------ |
 Access over TLS only | If your code needs to communicate via TCP, ideally it would be performing a TLS handshake with the client ahead of time. With the exception of a few cases, the default behavior should be to encrypt everything in transit. Going one step further, even "behind the firewall" in our VPC's it's still a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. There are numerous tools that can be used to accomplish this in Kubernetes such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). |
 Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
-3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to ensure that a regular scan of the code's dependencies are still secure with no CVE's currently filed against them. Each language has a tool for performing this check automatically. |
+3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to regularly scan the code's dependencies to ensure that they are still secure with no vulnerabilities currently filed against them. Each language has a tool for performing this check automatically. |
 Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found here: https://www.owasp.org/index.php/Source_Code_Analysis_Tools |
 Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project |

@@ -31,7 +31,6 @@ Enabling IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following

   * Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod)
   * IPv4 and IPv6 enabled Services (each Service must be for a single address family)
-   * Kubenet multi address family support (IPv4 and IPv6)
   * Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces

 ## Prerequisites
@@ -40,7 +39,7 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack

   * Kubernetes 1.16 or later
   * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
-   * Kubenet network plugin
+   * A network plugin that supports dual-stack (such as Kubenet or Calico)
   * Kube-proxy running in mode IPVS

 ## Enable IPv4/IPv6 dual-stack
@@ -56,7 +55,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
      * `--feature-gates="IPv6DualStack=true"`
   * kube-proxy:
      * `--proxy-mode=ipvs`
-      * `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>` 
+      * `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>`
      * `--feature-gates="IPv6DualStack=true"`

 {{< caution >}}
@@ -11,16 +11,16 @@ weight: 50
 {{< toc >}}

 {{% capture overview %}}
-A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.
+A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints.

-`NetworkPolicy` resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods.
+NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods.

 {{% /capture %}}

 {{% capture body %}}
 ## Prerequisites

-Network policies are implemented by the network plugin, so you must be using a networking solution which supports `NetworkPolicy` - simply creating the resource without a controller to implement it will have no effect.
+Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect.

 ## Isolated and Non-isolated Pods

@@ -30,11 +30,11 @@ Pods become isolated by having a NetworkPolicy that selects them. Once there is

 Network policies do not conflict, they are additive. If any policy or policies select a pod, the pod is restricted to what is allowed by the union of those policies' ingress/egress rules. Thus, order of evaluation does not affect the policy result.

-## The `NetworkPolicy` Resource
+## The NetworkPolicy resource {#networkpolicy-resource}

-See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) for a full definition of the resource.
+See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) reference for a full definition of the resource.

-An example `NetworkPolicy` might look like this:
+An example NetworkPolicy might look like this:

 ```yaml
 apiVersion: networking.k8s.io/v1
@@ -73,23 +73,25 @@ spec:
      port: 5978
 ```

-*POSTing this to the API server will have no effect unless your chosen networking solution supports network policy.*
+{{< note >}}
+POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy.
+{{< /note >}}

-__Mandatory Fields__: As with all other Kubernetes config, a `NetworkPolicy`
+__Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy
 needs `apiVersion`, `kind`, and `metadata` fields.  For general information
 about working with config files, see
 [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
 and [Object Management](/docs/concepts/overview/working-with-objects/object-management).

-__spec__: `NetworkPolicy` [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.
+__spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.

-__podSelector__: Each `NetworkPolicy` includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace.
+__podSelector__: Each NetworkPolicy includes a `podSelector` which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty `podSelector` selects all pods in the namespace.

-__policyTypes__: Each `NetworkPolicy` includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules.
+__policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules.

-__ingress__: Each `NetworkPolicy` may include a list of whitelist `ingress` rules.  Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
+__ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules.  Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.

-__egress__: Each `NetworkPolicy` may include a list of whitelist `egress` rules.  Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
+__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules.  Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.

 So, the example NetworkPolicy:

@@ -107,7 +109,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-

 There are four kinds of selectors that can be specified in an `ingress` `from` section or `egress` `to` section:

-__podSelector__: This selects particular Pods in the same namespace as the `NetworkPolicy` which should be allowed as ingress sources or egress destinations.
+__podSelector__: This selects particular Pods in the same namespace as the NetworkPolicy which should be allowed as ingress sources or egress destinations.

 __namespaceSelector__: This selects particular namespaces for which all Pods should be allowed as ingress sources or egress destinations.

@@ -168,16 +170,7 @@ in that namespace.

 You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-spec:
-  podSelector: {}
-  policyTypes:
-  - Ingress
-```
+{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}

 This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated. This policy does not change the default egress isolation behavior.

@@ -185,33 +178,13 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will

 If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic in that namespace.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: allow-all
-spec:
-  podSelector: {}
-  ingress:
-  - {}
-  policyTypes:
-  - Ingress
-```
+{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}

 ### Default deny all egress traffic

 You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-spec:
-  podSelector: {}
-  policyTypes:
-  - Egress
-```
+{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}

 This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed egress traffic. This policy does not
 change the default ingress isolation behavior.
@@ -220,34 +193,13 @@ change the default ingress isolation behavior.

 If you want to allow all traffic from all pods in a namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all egress traffic in that namespace.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: allow-all
-spec:
-  podSelector: {}
-  egress:
-  - {}
-  policyTypes:
-  - Egress
-```
+{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}

 ### Default deny all ingress and all egress traffic

 You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.

-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny
-spec:
-  podSelector: {}
-  policyTypes:
-  - Ingress
-  - Egress
-```
+{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}

 This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic.

@@ -255,9 +207,12 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will

 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

-Kubernetes supports SCTP as a `protocol` value in `NetworkPolicy` definitions as an alpha feature. To enable this feature, the cluster administrator needs to enable the `SCTPSupport` feature gate on the apiserver, for example, `“--feature-gates=SCTPSupport=true,...”`. When the feature gate is enabled, users can set the `protocol` field of a `NetworkPolicy` to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections.
+To use this feature, you (or your cluster administrator) will need to enable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=true,…`.  
+When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`.

-The CNI plugin has to support SCTP as `protocol` value in `NetworkPolicy`.
+{{< note >}}
+You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
+{{< /note >}}


 {{% /capture %}}
@@ -266,6 +221,6 @@ The CNI plugin has to support SCTP as `protocol` value in `NetworkPolicy`.

 - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
  walkthrough for further examples.
- See more [Recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
+- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.

 {{% /capture %}}
@@ -46,23 +46,6 @@ with it, while intrazonal traffic does not. Other common needs include being abl
 to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to
 Nodes connected to the same top-of-rack switch for the lowest latency.

-## Prerequisites
-
-The following prerequisites are needed in order to enable topology aware service
-routing:
-
-   * Kubernetes 1.17 or later
-   * Kube-proxy running in iptables mode or IPVS mode
-   * Enable [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
-
-## Enable Service Topology
-
-To enable service topology, enable the `ServiceTopology` feature gate for
-kube-apiserver and kube-proxy:
-
-```
--feature-gates="ServiceTopology=true"
-```

 ## Using Service Topology

@@ -117,6 +100,98 @@ traffic as follows.
  it is used.


+## Examples
+
+The following are common examples of using the Service Topology feature.
+
+### Only Node Local Endpoints
+
+A Service that only routes to node local endpoints. If no endpoints exist on the node, traffic is dropped:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+```
+
+### Prefer Node Local Endpoints
+
+A Service that prefers node local Endpoints but falls back to cluster wide endpoints if node local endpoints do not exist:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+    - "*"
+```
+
+
+### Only Zonal or Regional Endpoints
+
+A Service that prefers zonal then regional endpoints. If no endpoints exist in either, traffic is dropped.
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "topology.kubernetes.io/zone"
+    - "topology.kubernetes.io/region"
+```
+
+### Prefer Node Local, Zonal, then Regional Endpoints
+
+A Service that prefers node local, zonal, then regional endpoints but falls back to cluster wide endpoints.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: my-app
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+  topologyKeys:
+    - "kubernetes.io/hostname"
+    - "topology.kubernetes.io/zone"
+    - "topology.kubernetes.io/region"
+    - "*"
+```
+
+
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -225,7 +225,8 @@ There are a few reasons for using proxying for Services:
 In this mode, kube-proxy watches the Kubernetes master for the addition and
 removal of Service and Endpoint objects. For each Service it opens a
 port (randomly chosen) on the local node.  Any connections to this "proxy port"
-is proxied to one of the Service's backend Pods (as reported via
+are
+proxied to one of the Service's backend Pods (as reported via
 Endpoints). kube-proxy takes the `SessionAffinity` setting of the Service into
 account when deciding which backend Pod to use.

@@ -276,9 +277,9 @@ state.
 When accessing a Service, IPVS directs traffic to one of the backend Pods.

 The IPVS proxy mode is based on netfilter hook function that is similar to
-iptables mode, but uses hash table as the underlying data structure and works
+iptables mode, but uses a hash table as the underlying data structure and works
 in the kernel space.
-That means kube-proxy in IPVS mode redirects traffic with a lower latency than
+That means kube-proxy in IPVS mode redirects traffic with lower latency than
 kube-proxy in iptables mode, with much better performance when synchronising
 proxy rules. Compared to the other proxy modes, IPVS mode also supports a
 higher throughput of network traffic.
@@ -310,7 +311,7 @@ about Kubernetes or Services or Pods.

 If you want to make sure that connections from a particular client
 are passed to the same Pod each time, you can select the session affinity based
-on client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP"
+on the client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP"
 (the default is "None").
 You can also set the maximum session sticky time by setting
 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately.
@@ -421,7 +422,7 @@ Pods in other Namespaces must qualify the name as `my-service.my-ns`. These name
 will resolve to the cluster IP assigned for the Service.

 Kubernetes also supports DNS SRV (Service) records for named ports.  If the
-`"my-service.my-ns"` Service has a port named `"http"` with protocol set to
+`"my-service.my-ns"` Service has a port named `"http"` with the protocol set to
 `TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover
 the port number for `"http"`, as well as the IP address.

@@ -506,7 +507,7 @@ For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8`
 If you want a specific port number, you can specify a value in the `nodePort`
 field. The control plane will either allocate you that port or report that
 the API transaction failed.
-This means that you need to take care about possible port collisions yourself.
+This means that you need to take care of possible port collisions yourself.
 You also have to use a valid port number, one that's inside the range configured
 for NodePort use.

@@ -549,7 +550,7 @@ status:
 Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced.

 For LoadBalancer type of Services, when there is more than one port defined, all
-ports must have the same protocol and the protocol must be one of `TCP`, `UDP`
+ports must have the same protocol and the protocol must be one of `TCP`, `UDP`,
 and `SCTP`.

 Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created
@@ -677,7 +678,7 @@ SSL, the ELB expects the Pod to authenticate itself over the encrypted
 connection, using a certificate.

 HTTP and HTTPS selects layer 7 proxying: the ELB terminates
-the connection with the user, parse headers and inject the `X-Forwarded-For`
+the connection with the user, parses headers, and injects the `X-Forwarded-For`
 header with the user's IP address (Pods only see the IP address of the
 ELB at the other end of its connection) when forwarding requests.

@@ -849,7 +850,7 @@ traffic. Nodes without any Pods for a particular LoadBalancer Service will fail
 the NLB Target Group's health check on the auto-assigned
 `.spec.healthCheckNodePort` and not receive any traffic.

-In order to achieve even traffic, either use a DaemonSet, or specify a
+In order to achieve even traffic, either use a DaemonSet or specify a
 [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
 to not locate on the same node.

@@ -1182,7 +1183,7 @@ virtual IP address will simply transport the packets there.
 The Kubernetes project intends to improve support for L7 (HTTP) Services.

 The Kubernetes project intends to have more flexible ingress modes for Services
-which encompass the current ClusterIP, NodePort, and LoadBalancer modes and more.
+that encompass the current ClusterIP, NodePort, and LoadBalancer modes and more.


 {{% /capture %}}
@@ -115,7 +115,7 @@ Labels:          type=local
 Annotations:     <none>
 Finalizers:      [kubernetes.io/pv-protection]
 StorageClass:    standard
-Status:          Available
+Status:          Terminating
 Claim:
 Reclaim Policy:  Delete
 Access Modes:    RWO
@@ -19,8 +19,8 @@ collected.  Deleting a DaemonSet will clean up the Pods it created.
 Some typical uses of a DaemonSet are:

 - running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
- running a logs collection daemon on every node, such as `fluentd` or `logstash`.
- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` or [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/).
+- running a logs collection daemon on every node, such as `fluentd` or `filebeat`.
+- running a node monitoring daemon on every node, such as [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond`, [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) or [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html).

 In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
 A more complex setup might use multiple DaemonSets for a single type of daemon, but with
@@ -136,7 +136,7 @@ metadata:
  name: frontend-9si5l
  namespace: default
  ownerReferences:
-  - apiVersion: extensions/v1beta1
+  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
@@ -261,7 +261,7 @@ the -d option.
 For example:
 ```shell
 kubectl proxy --port=8080
-curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
 > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
 > -H "Content-Type: application/json"
 ```
@@ -273,7 +273,7 @@ When using the REST API or the `client-go` library, you must set `propagationPol
 For example:
 ```shell
 kubectl proxy --port=8080
-curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
 > -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
 > -H "Content-Type: application/json"
 ```
@@ -10,7 +10,7 @@ weight: 65

 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

-The TTL controller provides a TTL mechanism to limit the lifetime of resource
+The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource
 objects that have finished execution. TTL controller only handles
 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for
 now, and may be expanded to handle other resources that will finish execution,
@@ -55,7 +55,7 @@ array has six possible fields:

 * The `message` field is a human-readable message indicating details
  about the transition.
-  
+
 * The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition.

 * The `status` field is a string, with possible values "`True`", "`False`", and "`Unknown`".
@@ -67,8 +67,6 @@ array has six possible fields:
    balancing pools of all matching Services;
  * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers)
    have started successfully;
-  * `Unschedulable`: the scheduler cannot schedule the Pod right now, for example
-    due to lack of resources or other constraints;
  * `ContainersReady`: all containers in the Pod are ready.


@@ -185,18 +183,18 @@ Once Pod is assigned to a node by scheduler, kubelet starts creating containers
       Reason:       ErrImagePull
 	  ...
   ```
-   
-* `Running`: Indicates that the container is executing without issues. Once a container enters into Running, `postStart` hook (if any) is executed. This state also displays the time when the container entered Running state.  
-   
+
+* `Running`: Indicates that the container is executing without issues. The `postStart` hook (if any) is executed prior to the container entering a Running state. This state also displays the time when the container entered Running state.
+
   ```yaml
   ...
      State:          Running
       Started:      Wed, 30 Jan 2019 16:46:38 +0530
   ...
-   ```   
-       
+   ```
+
 * `Terminated`:  Indicates that the container completed its execution and has stopped running. A container enters into this when it has successfully completed execution or when it has failed for some reason. Regardless, a reason and exit code is displayed, as well as the container's start and finish time. Before a container enters into Terminated, `preStop` hook (if any) is executed.
-  
+
   ```yaml
   ...
      State:          Terminated
@@ -205,7 +203,7 @@ Once Pod is assigned to a node by scheduler, kubelet starts creating containers
        Started:      Wed, 30 Jan 2019 11:45:26 +0530
        Finished:     Wed, 30 Jan 2019 11:45:26 +0530
    ...
-   ``` 
+   ```

 ## Pod readiness gate

@@ -216,7 +214,7 @@ extra feedback or signals into `PodStatus`, Kubernetes 1.11 introduced a
 feature named [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md).
 You can use the new field `ReadinessGate` in the `PodSpec` to specify additional
 conditions to be evaluated for Pod readiness. If Kubernetes cannot find such a
-condition in the `status.conditions` field of a Pod, the status of the condition 
+condition in the `status.conditions` field of a Pod, the status of the condition
 is default to "`False`". Below is an example:

 ```yaml
@@ -255,12 +253,6 @@ when both the following statements are true:
 To facilitate this change to Pod readiness evaluation, a new Pod condition
 `ContainersReady` is introduced to capture the old Pod `Ready` condition.

-In K8s 1.11, as an alpha feature, the "Pod Ready++" feature has to be explicitly enabled by
-setting the `PodReadinessGates` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-to true.
-
-In K8s 1.12, the feature is enabled by default.
-
 ## Restart policy

 A PodSpec has a `restartPolicy` field with possible values Always, OnFailure,
@@ -277,8 +269,8 @@ once bound to a node, a Pod will never be rebound to another node.
 ## Pod lifetime

 In general, Pods remain until a human or controller process explicitly removes them.
-The control plane cleans up terminated Pods (with a phase of `Succeeded` or 
-`Failed`), when the number of Pods exceeds the configured threshold 
+The control plane cleans up terminated Pods (with a phase of `Succeeded` or
+`Failed`), when the number of Pods exceeds the configured threshold
 (determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
 This avoids a resource leak as Pods are created and terminated over time.

@@ -13,68 +13,50 @@ we're happy to have your help! Anyone can contribute, whether you're new to the
 project or you've been around a long time, and whether you self-identify as a
 developer, an end user, or someone who just can't stand seeing typos.

-For information on the Kubernetes documentation
- content and style, see the 
- [Documentation style overview](/docs/contribute/style/).
+{{% /capture %}}

 {{% capture body %}}

-## Types of docs contributors
+## Getting Started

- A _member_ of the Kubernetes organization who has [signed the CLA](/docs/contribute/start#sign-the-cla)
-  and contributed some time and effort to the project. See
-  [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
-  for specific criteria for membership.
- A SIG Docs _reviewer_ is a member of the Kubernetes organization who has
-  expressed interest in reviewing documentation pull requests and who has been
-  added to the appropriate GitHub group and `OWNERS` files in the GitHub
-  repository, by a SIG Docs Approver.
- A SIG Docs _approver_ is a member in good standing who has shown a continued
-  commitment to the project. An approver can merge pull requests
-  and publish content on behalf of the Kubernetes organization.
-  Approvers can also represent SIG Docs in the larger Kubernetes community.
-  Some of the duties of a SIG Docs approver, such as coordinating a release,
-  require a significant time commitment.
+Anyone can open an issue describing problems or desired improvements with documentation, or contribute a change with a pull request (PR).
+Some tasks require more trust and need more access in the Kubernetes organization.
+See [Participating in SIG Docs](/docs/contribute/participating/) for more details about
+of roles and permissions.

-## Ways to contribute to documentation
+Kubernetes documentation resides in a GitHub repository. While we welcome
+contributions from anyone, you do need basic comfort with git and GitHub to
+operate effectively in the Kubernetes community.

-This list is divided into things anyone can do, things Kubernetes organization
-members can do, and things that require a higher level of access and familiarity
-with SIG Docs processes. Contributing consistently over time can help you
-understand some of the tooling and organizational decisions that have already
-been made.
+To get involved with documentation:

-This is not an exhaustive list of ways you can contribute to the Kubernetes
-documentation, but it should help you get started.
+1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
+2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website) and the website's [static site generator](https://gohugo.io).
+3. Make sure you understand the basic processes for [improving content](https://kubernetes.io/docs/contribute/start/#improve-existing-content) and [reviewing changes](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests).

- [Anyone](/docs/contribute/start/)
-  - Open actionable issues
- [Member](/docs/contribute/start/)
-  - Improve existing docs
-  - Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
-  - Improve docs accessibility
-  - Provide non-binding feedback on PRs
-  - Write a blog post or case study
- [Reviewer](/docs/contribute/intermediate/)
-  - Document new features
-  - Triage and categorize issues
-  - Review PRs
-  - Create diagrams, graphics assets, and embeddable screencasts / videos
-  - Localization
-  - Contribute to other repos as a docs representative
-  - Edit user-facing strings in code
-  - Improve code comments, Godoc
- [Approver](/docs/contribute/advanced/)
-  - Publish contributor content by approving and merging PRs
-  - Participate in a Kubernetes release team as a docs representative
-  - Propose improvements to the style guide
-  - Propose improvements to docs tests
-  - Propose improvements to the Kubernetes website or other tooling
+## Contributions best practices

+- Do write clear and meaningful GIT commit messages.
+- Make sure to include _Github Special Keywords_ which references the issue and automatically closes the issue when PR is merged.
+- When you make a small change to a PR like fixing a typo, any style change, or changing grammar. Make sure you squash your commits so that you dont get a large number of commits for a relatively small change.
+- Make sure you include a nice PR description depicting the code you have changes, why to change a following piece of code and ensuring there is sufficient information for the reviewer to understand your PR.
+- Additional Readings : 
+    - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/)
+    - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests )
+    - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git )

-## Additional ways to contribute
+## Other ways to contribute

 - To contribute to the Kubernetes community through online forums like Twitter or Stack Overflow, or learn about local meetups and Kubernetes events, visit the [Kubernetes community site](/community/).
 - To contribute to feature development, read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get started.

 {{% /capture %}}
+
+{{% capture whatsnext %}}
+
+- For more information about the basics of contributing to documentation, read [Start contributing](/docs/contribute/start/).
+- Follow the [Kubernetes documentation style guide](/docs/contribute/style/style-guide/) when proposing changes.
+- For more information about SIG Docs, read [Participating in SIG Docs](/docs/contribute/participating/).
+- For more information about localizing Kubernetes docs, read [Localizing Kubernetes documentation](/docs/contribute/localization/).
+
+{{% /capture %}}
@@ -1,9 +1,12 @@
 ---
-title: Reference docs overview
+title: Reference Docs Overview
 main_menu: true
 weight: 80
 ---

-Much of the Kubernetes reference documentation is generated from Kubernetes
-source code, using scripts. The topics in this section document how to generate
-this type of content.
+The topics in this section document how to generate the Kubernetes
+reference guides.
+
+To build the reference documentation, see the following guide:
+
+* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
@@ -1,13 +1,14 @@
 ---
 title: Contributing to the Upstream Kubernetes Code
 content_template: templates/task
+weight: 20
 ---

 {{% capture overview %}}

-This page shows how to contribute to the upstream kubernetes/kubernetes project
-to fix bugs found in the Kubernetes API documentation or the `kube-*`
-components such as `kube-apiserver`, `kube-controller-manager`, etc.
+This page shows how to contribute to the upstream `kubernetes/kubernetes` project.
+You can fix bugs found in the Kubernetes API documentation or the content of
+the Kubernetes components such as `kubeadm`, `kube-apiserver`, and `kube-controller-manager`.

 If you instead want to regenerate the reference documentation for the Kubernetes
 API or the `kube-*` components from the upstream code, see the following instructions:
@@ -17,28 +18,25 @@ API or the `kube-*` components from the upstream code, see the following instruc

 {{% /capture %}}

-
 {{% capture prerequisites %}}

-You need to have these tools installed:
+- You need to have these tools installed:

-* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-* [Golang](https://golang.org/doc/install) version 1.9.1 or later
-* [Docker](https://docs.docker.com/engine/installation/)
-* [etcd](https://github.com/coreos/etcd/) 
+  - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
+  - [Golang](https://golang.org/doc/install) version 1.13+
+  - [Docker](https://docs.docker.com/engine/installation/)
+  - [etcd](https://github.com/coreos/etcd/)

-Your $GOPATH environment variable must be set, and the location of `etcd`
-must be in your $PATH environment variable.
+- Your `GOPATH` environment variable must be set, and the location of `etcd`
+  must be in your `PATH` environment variable.

-You need to know how to create a pull request to a GitHub repository.
-Typically, this involves creating a fork of the repository. For more
-information, see
-[Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/) and
-[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
+- You need to know how to create a pull request to a GitHub repository.
+  Typically, this involves creating a fork of the repository.
+  For more information, see [Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/)
+  and [GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).

 {{% /capture %}}

-
 {{% capture steps %}}

 ## The big picture
@@ -221,11 +219,10 @@ the same as the generated files in the master branch. The generated files in the
 contain API elements only from Kubernetes 1.9. The generated files in the master branch might contain
 API elements that are not in 1.9, but are under development for 1.10.

-
 ## Generating the published reference docs

 The preceding section showed how to edit a source file and then generate
-several files, including `api/openapi-spec/swagger.json` in the 
+several files, including `api/openapi-spec/swagger.json` in the
 `kubernetes/kubernetes` repository.
 The `swagger.json` file is the OpenAPI definition file to use for generating
 the API reference documentation.
@@ -238,8 +235,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube
 {{% capture whatsnext %}}

 * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
-* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
-* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
+* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
+* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)

 {{% /capture %}}
-
@@ -1,12 +1,12 @@
 ---
 title: Generating Reference Documentation for kubectl Commands
 content_template: templates/task
+weight: 90
 ---

 {{% capture overview %}}

-This page shows how to automatically generate reference pages for the
-commands provided by the `kubectl` tool.
+This page shows how to generate the `kubectl` command reference.

 {{< note >}}
 This topic shows how to generate reference documentation for
@@ -23,29 +23,12 @@ reference page, see

 {{% /capture %}}

-
 {{% capture prerequisites %}}

-* You need to have
-[Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-installed.
-
-* You need to have
-[Golang](https://golang.org/doc/install) version 1.9.1 or later installed,
-and your `$GOPATH` environment variable must be set.
-
-* You need to have
-[Docker](https://docs.docker.com/engine/installation/) installed.
-
-* You need to know how to create a pull request to a GitHub repository.
-Typically, this involves creating a fork of the repository. For more
-information, see
-[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/) and
-[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
+{{< include "prerequisites-ref-docs.md" >}}

 {{% /capture %}}

-
 {{% capture steps %}}

 ## Setting up the local repositories
@@ -85,8 +68,7 @@ Remove the spf13 package from `$GOPATH/src/k8s.io/kubernetes/vendor/github.com`.
 rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/github.com/spf13
 ```

-The kubernetes/kubernetes repository provides access to the kubectl and kustomize source code.
-
+The kubernetes/kubernetes repository provides the `kubectl` and `kustomize` source code.

 * Determine the base directory of your clone of the
 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repository.
@@ -108,15 +90,16 @@ The remaining steps refer to your base directory as `<rdocs-base>`.

 In your local k8s.io/kubernetes repository, check out the branch of interest,
 and make sure it is up to date. For example, if you want to generate docs for
-Kubernetes 1.15, you could use these commands:
+Kubernetes 1.17, you could use these commands:

 ```shell
 cd <k8s-base>
-git checkout release-1.15
-git pull https://github.com/kubernetes/kubernetes release-1.15
+git checkout v1.17.0
+git pull https://github.com/kubernetes/kubernetes v1.17.0
 ```

-If you do not need to edit the kubectl source code, follow the instructions to [Edit the Makefile](#editing-makefile).
+If you do not need to edit the `kubectl` source code, follow the instructions for
+[Setting build variables](#setting-build-variables).

 ## Editing the kubectl source code

@@ -152,65 +135,60 @@ milestone in your pull request. If you don’t have those permissions, you will
 need to work with someone who can set the label and milestone for you.
 {{< /note >}}

-## Editing Makefile
+## Setting build variables

-Go to `<rdocs-base>`, and open the `Makefile` for editing:
+Go to `<rdocs-base>`. On you command line, set the following environment variables.

-* Set `K8SROOT` to `<k8s-base>`.
-* Set `WEBROOT` to `<web-base>`.
-* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
-if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`.
+* Set `K8S_ROOT` to `<k8s-base>`.
+* Set `WEB_ROOT` to `<web-base>`.
+* Set `K8S_RELEASE` to the version of the docs you want to build.
+  For example, if you want to build docs for Kubernetes 1.17, set `K8S_RELEASE` to 1.17.

-For example, update the following variables:
-
-```
-WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
-K8SROOT=$(GOPATH)/src/k8s.io/kubernetes
-MINOR_VERSION=15
-```
-
-## Creating a version directory
-
-The version directory is a staging area for the kubectl command reference build.
-The YAML files in this directory are used to create the structure and navigation
-of the kubectl command reference.
-
-In the `<rdocs-base>/gen-kubectldocs/generators` directory, if you do not already
-have a directory named `v1_<MINOR_VERSION>`, create one now by copying the directory
-for the previous version. For example, suppose you want to generate docs for
-Kubernetes 1.15, but you don't already have a `v1_15` directory. Then you could
-create and populate a `v1_15` directory by running these commands:
+For example:

 ```shell
-mkdir gen-kubectldocs/generators/v1_15
-cp -r gen-kubectldocs/generators/v1_14/* gen-kubectldocs/generators/v1_15
+export WEB_ROOT=$(GOPATH)/src/github.com/<your-username>/website
+export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
+export K8S_RELEASE=1.17
 ```

-## Checking out a branch in k8s.io/kubernetes
+## Creating a versioned directory

-In your local <k8s-base> repository, checkout the branch that has
+The `createversiondirs` build target creates a versioned directory
+and copies the kubectl reference configuration files to the versioned directory.
+The versioned directory name follows the pattern of `v<major>_<minor>`.
+
+In the `<rdocs-base>` directory, run the following build target:
+
+```shell
+cd <rdocs-base>
+make createversiondirs
+```
+
+## Checking out a release tag in k8s.io/kubernetes
+
+In your local `<k8s-base>` repository, checkout the branch that has
 the version of Kubernetes that you want to document. For example, if you want
-to generate docs for Kubernetes 1.15, checkout the release-1.15 branch. Make sure
+to generate docs for Kubernetes 1.17, checkout the `v1.17.0` tag. Make sure
 you local branch is up to date.

 ```shell
 cd <k8s-base>
-git checkout release-1.15
-git pull https://github.com/kubernetes/kubernetes release-1.15
+git checkout v1.17.0
+git pull https://github.com/kubernetes/kubernetes v1.17.0
 ```

 ## Running the doc generation code

-In your local kubernetes-sigs/reference-docs repository, build and run the
-kubectl command reference generation code. You might need to run the command as root:
+In your local `<rdocs-base>`, run the `copycli` build target. The command runs as `root`:

 ```shell
 cd <rdocs-base>
 make copycli
 ```

-The `copycli` command will clean the staging directories, generate the kubectl command files,
-and copy the collated kubectl reference HTML page and assets to `<web-base>`.
+The `copycli` command cleans the temporary build directory, generates the kubectl command files,
+and copies the collated kubectl command reference HTML page and assets to `<web-base>`.

 ## Locate the generated files

@@ -237,7 +215,7 @@ static/docs/reference/generated/kubectl/kubectl-commands.html
 static/docs/reference/generated/kubectl/navData.js
 ```

-Additionally, the output might show the modified files:
+The output may also include:

 ```
 static/docs/reference/generated/kubectl/scroll.js
@@ -275,13 +253,12 @@ A few minutes after your pull request is merged, your updated reference
 topics will be visible in the
 [published documentation](/docs/home).

-
 {{% /capture %}}

 {{% capture whatsnext %}}

-* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
-* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/)
-* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
+* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
+* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
+* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)

 {{% /capture %}}
@@ -1,14 +1,16 @@
 ---
 title: Generating Reference Documentation for the Kubernetes API
 content_template: templates/task
+weight: 50
 ---

 {{% capture overview %}}

-This page shows how to update the generated reference docs for the Kubernetes API.
+This page shows how to update the Kubernetes API reference documentation.
+
 The Kubernetes API reference documentation is built from the
 [Kubernetes OpenAPI spec](https://github.com/kubernetes/kubernetes/blob/master/api/openapi-spec/swagger.json)
-and tools from [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs).
+using the [kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) generation code.

 If you find bugs in the generated documentation, you need to
 [fix them upstream](/docs/contribute/generate-ref-docs/contribute-upstream/).
@@ -18,23 +20,12 @@ spec, continue reading this page.

 {{% /capture %}}

-
 {{% capture prerequisites %}}

-You need to have these tools installed:
-
-* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-* [Golang](https://golang.org/doc/install) version 1.9.1 or later
-
-You need to know how to create a pull request (PR) to a GitHub repository.
-Typically, this involves creating a fork of the repository. For more
-information, see
-[Creating a Documentation Pull Request](/docs/contribute/start/) and
-[GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
+{{< include "prerequisites-ref-docs.md" >}}

 {{% /capture %}}

-
 {{% capture steps %}}

 ## Setting up the local repositories
@@ -83,49 +74,50 @@ The remaining steps refer to your base directory as `<web-base>`.
 repository is `$GOPATH/src/github.com/kubernetes-sigs/reference-docs.`
 The remaining steps refer to your base directory as `<rdocs-base>`.

-
 ## Generating the API reference docs

 This section shows how to generate the
 [published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).

-### Modifying the Makefile
+### Setting build variables

-Go to `<rdocs-base>`, and open the `Makefile` for editing:
+* Set `K8S_ROOT` to `<k8s-base>`.
+* Set `WEB_ROOT` to `<web-base>`.
+* Set `K8S_RELEASE` to the version of the docs you want to build.
+  For example, if you want to build docs for Kubernetes 1.17, set `K8S_RELEASE` to 1.17.

-* Set `K8SROOT` to `<k8s-base>`.
-* Set `WEBROOT` to `<web-base>`.
-* Set `MINOR_VERSION` to the minor version of the docs you want to build. For example,
-if you want to build docs for Kubernetes 1.15, set `MINOR_VERSION` to 15. Save and close the `Makefile`.
-
-For example, update the following variables:
-
-```
-WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
-K8SROOT=$(GOPATH)/src/k8s.io/kubernetes
-MINOR_VERSION=15
-```
-
-### Copying the OpenAPI spec
-
-Run the following command in `<rdocs-base>`:
+For example:

 ```shell
+export WEB_ROOT=$(GOPATH)/src/github.com/<your-username>/website
+export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
+export K8S_RELEASE=1.17
+```
+
+### Creating versioned directory and fetching Open API spec
+
+The `updateapispec` build target creates the versioned  build directory.
+After the directory is created, the Open API spec is fetched from the
+`<k8s-base>` repository. These steps ensure that the version
+of the configuration files and Kubernetes Open API spec match the release version.
+The versioned directory name follows the pattern of `v<major>_<minor>`.
+
+In the `<rdocs-base>` directory, run the following build target:
+
+```shell
+cd <rdocs-base>
 make updateapispec
 ```

-The output shows that the file was copied:
-
-```shell
-cp ~/src/k8s.io/kubernetes/api/openapi-spec/swagger.json gen-apidocs/generators/openapi-spec/swagger.json
-```
-
 ### Building the API reference docs

+The `copyapi` target builds the API reference and
+copies the generated files to directories in `<web-base>`.
 Run the following command in `<rdocs-base>`:

 ```shell
-make api
+cd <rdocs-base>
+make copyapi
 ```

 Verify that these two files have been generated:
@@ -135,71 +127,57 @@ Verify that these two files have been generated:
 [ -e "<rdocs-base>/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js"
 ```

-### Creating directories for published docs
-
-Create the directories in `<web-base>` for the generated API reference files:
-
-```shell
-mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>
-mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/css
-mkdir -p <web-base>/static/docs/reference/generated/kubernetes-api/v1.<minor-version>/fonts
-```
-
-## Copying the generated docs to the kubernetes/website repository
-
-Run the following command in `<rdocs-base>` to copy the generated files to
-your local kubernetes/website repository:
-
-```shell
-make copyapi
-```
-
-Go to the base of your local kubernetes/website repository, and
-see which files have been modified:
+Go to the base of your local `<web-base>`, and
+view which files have been modified:

 ```shell
 cd <web-base>
 git status
 ```

-The output shows the modified files:
+The output is similar to:

 ```
-static/docs/reference/generated/kubernetes-api/v1.15/css/bootstrap.min.css
-static/docs/reference/generated/kubernetes-api/v1.15/css/font-awesome.min.css
-static/docs/reference/generated/kubernetes-api/v1.15/css/stylesheet.css
-static/docs/reference/generated/kubernetes-api/v1.15/fonts/FontAwesome.otf
-static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.eot
-static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.svg
-static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.ttf
-static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff
-static/docs/reference/generated/kubernetes-api/v1.15/fonts/fontawesome-webfont.woff2
-static/docs/reference/generated/kubernetes-api/v1.15/index.html
-static/docs/reference/generated/kubernetes-api/v1.15/jquery.scrollTo.min.js
-static/docs/reference/generated/kubernetes-api/v1.15/navData.js
-static/docs/reference/generated/kubernetes-api/v1.15/scroll.js
+static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css
+static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css
+static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2
+static/docs/reference/generated/kubernetes-api/v1.17/index.html
+static/docs/reference/generated/kubernetes-api/v1.17/js/jquery.scrollTo.min.js
+static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js
+static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js
 ```

 ## Updating the API reference index pages

-* Open `<web-base>/content/en/docs/reference/kubernetes-api/api-index.md` for editing, and update the API reference version number. For example:
+When generating reference documentation for a new release, update the file,
+`<web-base>/content/en/docs/reference/kubernetes-api/api-index.md` with the new
+version number.

-    ```markdown
+* Open `<web-base>/content/en/docs/reference/kubernetes-api/api-index.md` for editing,
+  and update the API reference version number. For example:
+
+    ```
    ---
-    title: v1.15
+    title: v1.17
    ---

-    [Kubernetes API v1.15](/docs/reference/generated/kubernetes-api/v1.15/)
+    [Kubernetes API v1.17](/docs/reference/generated/kubernetes-api/v1.17/)
    ```

 * Open `<web-base>/content/en/docs/reference/_index.md` for editing, and add a
-   new link for the latest API reference. Remove the oldest API reference version.
-   There should be five links to the most recent API references.
+  new link for the latest API reference. Remove the oldest API reference version.
+  There should be five links to the most recent API references.

 ## Locally test the API reference

 Publish a local version of the API reference.
-Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.15/).
+Verify the [local preview](http://localhost:1313/docs/reference/generated/kubernetes-api/v1.17/).

 ```shell
 cd <web-base>
@@ -220,8 +198,8 @@ to monitor your pull request until it has been merged.

 {{% capture whatsnext %}}

-* [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/)
-* [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/)
-* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
+* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
+* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
+* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)

 {{% /capture %}}
@@ -1,228 +1,34 @@
 ---
 title: Generating Reference Pages for Kubernetes Components and Tools
 content_template: templates/task
+weight: 120
 ---

 {{% capture overview %}}

-This page shows how to use the `update-imported-docs` tool to generate
-reference documentation for tools and components in the
-[Kubernetes](https://github.com/kubernetes/kubernetes) repository.
+This page shows how to build the Kubernetes component and tool reference pages.

 {{% /capture %}}

 {{% capture prerequisites %}}

-* You need a machine that is running Linux or macOS.
-
-* Install the following:
-
-    * [Python](https://www.python.org/downloads/) v3.7.x
-    * [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-    * [Golang](https://golang.org/doc/install) version 1.13+
-    * [Pip](https://pypi.org/project/pip/) used to install PyYAML
-    * [PyYAML](https://pyyaml.org/) v5.1.2
-    * [make](https://www.gnu.org/software/make/)
-    * [gcc compiler/linker](https://gcc.gnu.org/)
-
-* The `Go` binary must be in your path. The `update-imported-docs` tool sets your GOPATH.
-
-* You need to know how to create a pull request to a GitHub repository.
-This involves creating your own fork of the repository. For more
-information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone).
+Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)
+in the Reference Documentation Quickstart guide.

 {{% /capture %}}

 {{% capture steps %}}

-## Getting the repository
-
-Make sure your `website` fork is up-to-date with the `kubernetes/website` master and then clone your `website` fork.
-
-```shell
-mkdir github.com
-cd github.com
-git clone git@github.com:<your_github_username>/website.git
-```
-
-Determine the base directory of your clone. For example, if you followed the
-preceding step to get the repository, your base directory is
-`github.com/website.` The remaining steps refer to your base directory as
-`<web-base>`.
-
-The `update-imported-docs` tool generates the reference documentation for the
-Kubernetes components from the Kubernetes source code. The tool automatically
-clones the `kubernetes/kubernetes` repository. If you want to change the
-reference documentation, please follow [this
-guide](/docs/contribute/generate-ref-docs/contribute-upstream).
-
-## Overview of update-imported-docs
-
-The `update-imported-docs` tool is located in the `kubernetes/website/update-imported-docs/`
-directory. The tool consists of a Python script that reads a YAML configuration file and performs the following steps:
-
-1. Clones the related repositories specified in a configuration file. For the
-   purpose of generating reference docs, the repository that is cloned by
-   default is `kubernetes-sigs/reference-docs`.
-1. Runs commands under the cloned repositories to prepare the docs generator and
-   then generates the Markdown files.
-1. Copies the generated Markdown files to a local clone of the `kubernetes/website`
-   repository under locations specified in the configuration file.
-1. Updates `kubectl` command links from `kubectl`.md to the `kubectl` command reference.
-
-When the Markdown files are in your local clone of the `kubernetes/website`
-repository, you can submit them in a [pull request](/docs/contribute/start/)
-to `kubernetes/website`.
-
-## Configuration file format
-
-Each config file may contain multiple repos that will be imported together. When
-necessary, you can customize the configuration file by manually editing it. You
-may create new config files for importing other groups of documents. Imported
-documents must follow these guidelines:
-
-1. Adhere to the [Documentation Style Guide](/docs/contribute/style/style-guide/).
-
-1. Have `title` defined in the front matter. For example:
-
-    ```
-    ---
-    title: Title Displayed in Table of Contents
-    ---
-
-    Rest of the .md file...
-    ```
-1. Be listed in the `kubernetes/website/data/reference.yml` file
-
-The following is an example of the YAML configuration file:
-
-```yaml
-repos:
- name: community
-  remote: https://github.com/kubernetes/community.git
-  branch: master
-  files:
-  - src: contributors/devel/README.md
-    dst: docs/imported/community/devel.md
-  - src: contributors/guide/README.md
-    dst: docs/imported/community/guide.md
-```
-
-Note: `generate-command` is an optional entry, which can be used to run a
-given command or a short script to generate the docs from within a repo.
-
-## Customizing the reference.yml config file
-
-Open `<web-base>/update-imported-docs/reference.yml` for editing.
-Do not change the content for the `generate-command` entry unless you understand
-what it is doing and need to change the specified release branch.
-
-```yaml
-repos:
- name: reference-docs
-  remote: https://github.com/kubernetes-sigs/reference-docs.git
-  # This and the generate-command below needs a change when reference-docs has
-  # branches properly defined
-  branch: master
-  generate-command: |
-    cd $GOPATH
-    git clone https://github.com/kubernetes/kubernetes.git src/k8s.io/kubernetes
-    cd src/k8s.io/kubernetes
-    git checkout release-1.17
-    make generated_files
-    cp -L -R vendor $GOPATH/src
-    rm -r vendor
-    cd $GOPATH
-    go get -v github.com/kubernetes-sigs/reference-docs/gen-compdocs
-    cd src/github.com/kubernetes-sigs/reference-docs/
-    make comp
-```
-
-In reference.yml, the `files` field is a list of `src` and `dst` fields. The `src` field
-specifies the location of a generated Markdown file, and the `dst` field specifies
-where to copy this file in the cloned `kubernetes/website` repository.
-For example:
-
-```yaml
-repos:
- name: reference-docs
-  remote: https://github.com/kubernetes-sigs/reference-docs.git
-  files:
-  - src: gen-compdocs/build/kube-apiserver.md
-    dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
-  ...
-```
-
-Note that when there are many files to be copied from the same source directory
-to the same destination directory, you can use wildcards in the value given to
-`src` and you can just provide the directory name as the value for `dst`.
-For example:
-
-```yaml
-  files:
-  - src: gen-compdocs/build/kubeadm*.md
-    dst: content/en/docs/reference/setup-tools/kubeadm/generated/
-```
-
-## Running the update-imported-docs tool
-
-After having reviewed and/or customized the `reference.yaml` file, you can run
-the `update-imported-docs` tool:
-
-```shell
-cd <web-base>/update-imported-docs
-./update-imported-docs reference.yml
-```
-
-## Fixing Links
-
-To fix relative links within your imported files, set the repo config's
-`gen-absolute-links` property to `true`. You can find an example of this in
-[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml).
-
-## Adding and committing changes in kubernetes/website
-
-List the files that were generated and copied to the `kubernetes/website`
-repository:
-
-```
-cd <web-base>
-git status
-```
-
-The output shows the new and modified files. For example, the output
-might look like this:
-
-```shell
-...
-
-    modified:   content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
-    modified:   content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
-    modified:   content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
-    modified:   content/en/docs/reference/command-line-tools-reference/kube-proxy.md
-    modified:   content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
-    modified:   content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md
-    modified:   content/en/docs/reference/kubectl/kubectl.md
-...
-```
-
-Run `git add` and `git commit` to commit the files.
-
-## Creating a pull request
-
-Create a pull request to the `kubernetes/website` repository. Monitor your
-pull request, and respond to review comments as needed. Continue to monitor
-your pull request until it is merged.
-
-A few minutes after your pull request is merged, your updated reference
-topics will be visible in the
-[published documentation](/docs/home/).
+Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
+to generate the Kubernetes component and tool reference pages.

 {{% /capture %}}

 {{% capture whatsnext %}}

+* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
 * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
 * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
 * [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/)
+
 {{% /capture %}}
@@ -0,0 +1,21 @@
+
+### Requirements:
+
+- You need a machine that is running Linux or macOS.
+
+- You need to have these tools installed:
+
+  - [Python](https://www.python.org/downloads/) v3.7.x
+  - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
+  - [Golang](https://golang.org/doc/install) version 1.13+
+  - [Pip](https://pypi.org/project/pip/) used to install PyYAML
+  - [PyYAML](https://pyyaml.org/) v5.1.2
+  - [make](https://www.gnu.org/software/make/)
+  - [gcc compiler/linker](https://gcc.gnu.org/)
+  - [Docker](https://docs.docker.com/engine/installation/) (Required only for `kubectl` command reference)
+
+- Your `PATH` environment variable must include the required build tools, such as the `Go` binary and `python`.
+
+- You need to know how to create a pull request to a GitHub repository.
+  This involves creating your own fork of the repository. For more
+  information, see [Work from a local clone](/docs/contribute/intermediate/#work_from_a_local_clone).
@@ -0,0 +1,260 @@
+---
+title: Quickstart
+content_template: templates/task
+weight: 40
+---
+
+{{% capture overview %}}
+
+This page shows how to use the `update-imported-docs` script to generate
+the Kubernetes reference documentation. The script automates
+the build setup and generates the reference documentation for a release.
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "prerequisites-ref-docs.md" >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Getting the docs repository
+
+Make sure your `website` fork is up-to-date with the `kubernetes/website` master and clone
+your `website` fork.
+
+```shell
+mkdir github.com
+cd github.com
+git clone git@github.com:<your_github_username>/website.git
+```
+
+Determine the base directory of your clone. For example, if you followed the
+preceding step to get the repository, your base directory is
+`github.com/website.` The remaining steps refer to your base directory as
+`<web-base>`.
+
+{{< note>}}
+If you want to change the content of the component tools and API reference,
+see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contribute-upstream).
+{{< /note >}}
+
+## Overview of update-imported-docs
+
+The `update-imported-docs` script is located in the `<web-base>/update-imported-docs/`
+directory.
+
+The script builds the following references:
+
+* Component and tool reference pages
+* The `kubectl` command reference
+* The Kubernetes API reference
+
+The `update-imported-docs` script generates the Kubernetes reference documentation
+from the Kubernetes source code. The script creates a temporary directory
+under `/tmp` on your machine and clones the required repositories: `kubernetes/kubernetes` and
+`kubernetes-sigs/reference-docs` into this directory.
+The script sets your `GOPATH` to this temporary directory.
+Three additional environment variables are set:
+
+* `K8S_RELEASE`
+* `K8S_ROOT`
+* `K8S_WEBROOT`
+
+The script requires two arguments to run successfully:
+
+* A YAML configuration file (`reference.yml`)
+* A release version, for example:`1.17`
+
+The configuration file contains a `generate-command` field.
+The `generate-command` field defines a series of build instructions
+from `kubernetes-sigs/reference-docs/Makefile`. The `K8S_RELEASE` variable
+determines the version of the release.
+
+The `update-imported-docs` script performs the following steps:
+
+1. Clones the related repositories specified in a configuration file. For the
+   purpose of generating reference docs, the repository that is cloned by
+   default is `kubernetes-sigs/reference-docs`.
+1. Runs commands under the cloned repositories to prepare the docs generator and
+   then generates the HTML and Markdown files.
+1. Copies the generated HTML and Markdown files to a local clone of the `<web-base>`
+   repository under locations specified in the configuration file.
+1. Updates `kubectl` command links from `kubectl`.md to the refer to
+   the sections in the `kubectl` command reference.
+
+When the generated files are in your local clone of the `<web-base>`
+repository, you can submit them in a [pull request](/docs/contribute/start/)
+to `<web-base>`.
+
+## Configuration file format
+
+Each configuration file may contain multiple repos that will be imported together. When
+necessary, you can customize the configuration file by manually editing it. You
+may create new config files for importing other groups of documents.
+The following is an example of the YAML configuration file:
+
+```yaml
+repos:
+- name: community
+  remote: https://github.com/kubernetes/community.git
+  branch: master
+  files:
+  - src: contributors/devel/README.md
+    dst: docs/imported/community/devel.md
+  - src: contributors/guide/README.md
+    dst: docs/imported/community/guide.md
+```
+
+Single page Markdown documents, imported by the tool, must adhere to
+the [Documentation Style Guide](/docs/contribute/style/style-guide/).
+
+## Customizing reference.yml
+
+Open `<web-base>/update-imported-docs/reference.yml` for editing.
+Do not change the content for the `generate-command` field unless you understand
+how the command is used to build the references.
+You should not need to update `reference.yml`. At times, changes in the
+upstream source code, may require changes to the configuration file
+(for example: golang version dependencies and third-party library changes).
+If you encounter build issues, contact the SIG-Docs team on the
+[#sig-docs Kubernetes Slack channel](https://kubernetes.slack.com).
+
+{{< note >}}
+The `generate-command` is an optional entry, which can be used to run a
+given command or a short script to generate the docs from within a repository.
+{{< /note >}}
+
+In `reference.yml`, `files` contains a list of `src` and `dst` fields.
+The `src` field contains the location of a generated Markdown file in the cloned
+`kubernetes-sigs/reference-docs` build directory, and the `dst` field specifies
+where to copy this file in the cloned `kubernetes/website` repository.
+For example:
+
+```yaml
+repos:
+- name: reference-docs
+  remote: https://github.com/kubernetes-sigs/reference-docs.git
+  files:
+  - src: gen-compdocs/build/kube-apiserver.md
+    dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
+  ...
+```
+
+Note that when there are many files to be copied from the same source directory
+to the same destination directory, you can use wildcards in the value given to
+`src`. You must provide the directory name as the value for `dst`.
+For example:
+
+```yaml
+  files:
+  - src: gen-compdocs/build/kubeadm*.md
+    dst: content/en/docs/reference/setup-tools/kubeadm/generated/
+```
+
+## Running the update-imported-docs tool
+
+You can run the `update-imported-docs` tool as follows:
+
+```shell
+cd <web-base>/update-imported-docs
+./update-imported-docs <configuration-file.yml> <release-version>
+```
+
+For example:
+
+```shell
+./update-imported-docs reference.yml 1.17
+```
+
+<!-- Revisit: is the release configuration used -->
+## Fixing Links
+
+The `release.yml` configuration file contains instructions to fix relative links.
+To fix relative links within your imported files, set the`gen-absolute-links`
+property to `true`. You can find an example of this in
+[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml).
+
+## Adding and committing changes in kubernetes/website
+
+List the files that were generated and copied to `<web-base>`:
+
+```shell
+cd <web-base>
+git status
+```
+
+The output shows the new and modified files. The generated output varies
+depending upon changes made to the upstream source code.
+
+### Generated component tool files
+
+```
+content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md
+content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
+content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
+content/en/docs/reference/command-line-tools-reference/kube-proxy.md
+content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
+content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md
+content/en/docs/reference/kubectl/kubectl.md
+```
+
+### Generated kubectl command reference files
+
+```
+static/docs/reference/generated/kubectl/kubectl-commands.html
+static/docs/reference/generated/kubectl/navData.js
+static/docs/reference/generated/kubectl/scroll.js
+static/docs/reference/generated/kubectl/stylesheet.css
+static/docs/reference/generated/kubectl/tabvisibility.js
+static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css
+static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css
+static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js
+static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js
+static/docs/reference/generated/kubectl/css/font-awesome.min.css
+```
+
+### Generated Kubernetes API reference directories and files
+
+```
+static/docs/reference/generated/kubernetes-api/v1.17/index.html
+static/docs/reference/generated/kubernetes-api/v1.17/js/navData.js
+static/docs/reference/generated/kubernetes-api/v1.17/js/scroll.js
+static/docs/reference/generated/kubernetes-api/v1.17/js/query.scrollTo.min.js
+static/docs/reference/generated/kubernetes-api/v1.17/css/font-awesome.min.css
+static/docs/reference/generated/kubernetes-api/v1.17/css/bootstrap.min.css
+static/docs/reference/generated/kubernetes-api/v1.17/css/stylesheet.css
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/FontAwesome.otf
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.eot
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.svg
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.ttf
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff
+static/docs/reference/generated/kubernetes-api/v1.17/fonts/fontawesome-webfont.woff2
+```
+
+Run `git add` and `git commit` to commit the files.
+
+## Creating a pull request
+
+Create a pull request to the `kubernetes/website` repository. Monitor your
+pull request, and respond to review comments as needed. Continue to monitor
+your pull request until it is merged.
+
+A few minutes after your pull request is merged, your updated reference
+topics will be visible in the
+[published documentation](/docs/home/).
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+To generate the individual reference documentation by manually setting up the required build repositories and
+running the build targets, see the following guides:
+
+* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
+* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
+* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
+
+{{% /capture %}}
@@ -54,16 +54,16 @@ Once you've opened a localization PR, you can become members of the Kubernetes G

 ### Add your localization team in GitHub

-Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685). 
+Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685).

-Members of `sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`. 
+Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`.

-The `sig-docs-**-reviews` team automates review assignment for new PRs.
+For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs.

-Members of `sig-docs-l10n-admins` can create new development branches to coordinate translation efforts.
+Members of `@kubernetes/website-maintainers` can create new development branches to coordinate translation efforts.
+
+Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs.

-Members of `website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs.
-    
 ### Configure the workflow

 Next, add a GitHub label for your localization in the `kubernetes/test-infra` repository. A label lets you filter issues and pull requests for your specific language.
@@ -240,9 +240,9 @@ Because localization projects are highly collaborative efforts, we encourage tea

 To collaborate on a development branch:

-1. A team member of [@kubernetes/sig-docs-l10n-admins](https://github.com/orgs/kubernetes/teams/sig-docs-l10n-admins) opens a development branch from a source branch on https://github.com/kubernetes/website.
+1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a development branch from a source branch on https://github.com/kubernetes/website.

-    Your team approvers joined the `sig-docs-l10n-admins` team when you [added your localization team](#add-your-localization-team-in-github) to the `kubernetes/org` repository. 
+    Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository.

    We recommend the following branch naming scheme:

@@ -19,7 +19,7 @@ SIG Docs welcomes content and reviews from all contributors. Anyone can open a
 pull request (PR), and anyone is welcome to file issues about content or comment
 on pull requests in progress.

-Within SIG Docs, you may also become a [member](#members),
+You can also become a [member](#members),
 [reviewer](#reviewers), or [approver](#approvers). These roles require greater
 access and entail certain responsibilities for approving and committing changes.
 See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
@@ -34,51 +34,47 @@ aspects of Kubernetes -- the Kubernetes website and documentation.

 ## Roles and responsibilities

-When a pull request is merged to the branch used to publish content (currently
-`master`), that content is published and available to the world. To ensure that
-the quality of our published content is high, we limit merging pull requests to
-SIG Docs approvers. Here's how it works.
+- **Anyone** can contribute to Kubernetes documentation. To contribute, you must [sign the CLA](/docs/contribute/start#sign-the-cla) and have a GitHub account.
+- **Members** of the Kubernetes organization are contributors who have spent time and effort on the Kubernetes project, usually by opening pull requests with accepted changes. See [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for membership criteria.
+- A SIG Docs **Reviewer** is a member of the Kubernetes organization who has
+  expressed interest in reviewing documentation pull requests, and has been
+  added to the appropriate GitHub group and `OWNERS` files in the GitHub
+  repository by a SIG Docs Approver.
+- A SIG Docs **Approver** is a member in good standing who has shown a continued
+  commitment to the project. An approver can merge pull requests
+  and publish content on behalf of the Kubernetes organization.
+  Approvers can also represent SIG Docs in the larger Kubernetes community.
+  Some duties of a SIG Docs approver, such as coordinating a release,
+  require a significant time commitment.

- When a pull request has both the `lgtm` and `approve` labels and has no `hold`
-  labels, the pull request merges automatically. 
- Kubernetes organization members and SIG Docs approvers can add comments to
-  prevent automatic merging of a given pull request (by adding a `/hold` comment
-  or withholding a `/lgtm` comment).
- Any Kubernetes member can add the `lgtm` label, by adding a `/lgtm` comment.
- Only an approver who is a member of SIG Docs can cause a pull request to merge
-  by adding an `/approve` comment. Some approvers also perform additional
-  specific roles, such as [PR Wrangler](#pr-wrangler) or
-  [SIG Docs chairperson](#sig-docs-chairperson).
+## Anyone

-For more information about expectations and differences between the roles of
-Kubernetes organization member and SIG Docs approvers, see
-[Types of contributor](/docs/contribute#types-of-contributor). The following
-sections cover more details about these roles and how they work within
-SIG Docs.
+Anyone can do the following:

-### Anyone
+- Open a GitHub issue against any part of Kubernetes, including documentation.
+- Provide non-binding feedback on a pull request/
+- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+- Use the `/lgtm` Prow command (short for "looks good to me") to recommend the changes in a pull request for merging.
+  {{< note >}}
+  If you are not a member of the Kubernetes organization, using `/lgtm` has no effect on automated systems.
+  {{< /note >}}

-Anyone can file an issue against any part of Kubernetes, including documentation.
+After [signing the CLA](/docs/contribute/start#sign-the-cla), anyone can also:
+- Open a pull request to improve existing content, add new content, or write a blog post or case study.

-Anyone who has signed the CLA can submit a pull request. If you cannot sign the
-CLA, the Kubernetes project cannot accept your contribution.
+## Members

-### Members
+Members are contributors to the Kubernetes project who meet the [membership criteria](https://github.com/kubernetes/community/blob/master/community-membership.md#member). SIG Docs welcomes contributions from all members of the Kubernetes community,
+and frequently requests reviews from members of other SIGs for technical accuracy.

-Any member of the [Kubernetes organization](https://github.com/kubernetes) can
-review a pull request, and SIG Docs team members frequently request reviews from
-members of other SIGs for technical accuracy.
-SIG Docs also welcomes reviews and feedback regardless of a person's membership
-status in the Kubernetes organization. You can indicate your approval by adding
-a comment of `/lgtm` to a pull request. If you are not a member of the
-Kubernetes organization, your `/lgtm` has no effect on automated systems.
+Any member of the [Kubernetes organization](https://github.com/kubernetes) can do the following:

-Any member of the Kubernetes organization can add a `/hold` comment to prevent
-the pull request from being merged. Any member can also remove a `/hold` comment
-to cause a PR to be merged if it already has both `/lgtm` and `/approve` applied
-by appropriate people.
+- Everything listed under [Anyone](#anyone)
+- Use the `/lgtm` comment to add the LGTM (looks good to me) label to a pull request.
+- Use the `/hold` command to prevent a pull request from being merged, if the pull request already has the LGTM and approve labels.
+- Use the `/assign` comment to assign a reviewer to a pull request.

-#### Becoming a member
+### Becoming a member

 After you have successfully submitted at least 5 substantive pull requests, you
 can request [membership](https://github.com/kubernetes/community/blob/master/community-membership.md#member)
@@ -86,11 +82,11 @@ in the Kubernetes organization. Follow these steps:

 1.  Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor)
    your membership.
-    
-      Ask for sponsorship in the [#sig-docs channel on the 
+
+      Ask for sponsorship in the [#sig-docs channel on the
      Kubernetes Slack instance](https://kubernetes.slack.com) or on the
      [SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-      
+
      {{< note >}}
      Don't send a direct email or Slack direct message to an individual
      SIG Docs member.
@@ -108,20 +104,29 @@ in the Kubernetes organization. Follow these steps:
    GitHub issue to show approval and then closes the GitHub issue.
    Congratulations, you are now a member!

-If for some reason your membership request is not accepted right away, the
+If your membership request is not accepted, the
 membership committee provides information or steps to take before applying
 again.

-### Reviewers
+## Reviewers

 Reviewers are members of the
 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
-GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
+GitHub group. Reviewers review documentation pull requests and provide feedback on proposed
+changes. Reviewers can:

-Reviewers review documentation pull requests and provide feedback on proposed
-changes.
+- Do everything listed under [Anyone](#anyone) and [Members](#members)
+- Document new features
+- Triage and categorize issues
+- Review pull requests and provide binding feedback
+- Create diagrams, graphics assets, and embeddable screencasts and videos
+- Localization
+- Edit user-facing strings in code
+- Improve code comments

-Automation assigns reviewers to pull requests, and contributors can request a
+### Assigning reviewers to pull requests
+
+Automation assigns reviewers to all pull requests. You can request a
 review from a specific reviewer with a comment on the pull request: `/assign
 [@_github_handle]`. To indicate that a pull request is technically accurate and
 requires no further changes, a reviewer adds a `/lgtm` comment to the pull
@@ -129,18 +134,14 @@ request.

 If the assigned reviewer has not yet reviewed the content, another reviewer can
 step in. In addition, you can assign technical reviewers and wait for them to
-provide `/lgtm`.
+provide a `/lgtm` comment.

-For a trivial change or one that needs no technical review, the SIG Docs
-[approver](#approvers) can provide the `/lgtm` as well.
+For a trivial change or one that needs no technical review, SIG Docs
+[approvers](#approvers) can provide the `/lgtm` as well.

-A `/approve` comment from a reviewer is ignored by automation.
+An `/approve` comment from a reviewer is ignored by automation.

-For more about how to become a SIG Docs reviewer and the responsibilities and
-time commitment involved, see
-[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer).
-
-#### Becoming a reviewer
+### Becoming a reviewer

 When you meet the
 [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer),
@@ -161,26 +162,27 @@ If you are approved, request that a current SIG Docs approver add you to the
 GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
 add new members to a GitHub group.

-### Approvers
+## Approvers

 Approvers are members of the
 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
 GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).

-Approvers have the ability to merge a PR, and thus, to publish content on the
-Kubernetes website. To approve a PR, an approver leaves an `/approve` comment on
-the PR. If someone who is not an approver leaves the approval comment,
-automation ignores it.
+Approvers can do the following:
+
+- Everything listed under [Anyone](#anyone), [Members](#members) and [Reviewers](#reviewers)
+- Publish contributor content by approving and merging pull requests using the `/approve` comment.
+  If someone who is not an approver leaves the approval comment, automation ignores it.
+- Participate in a Kubernetes release team as a docs representative
+- Propose improvements to the style guide
+- Propose improvements to docs tests
+- Propose improvements to the Kubernetes website or other tooling

 If the PR already has a `/lgtm`, or if the approver also comments with `/lgtm`,
 the PR merges automatically. A SIG Docs approver should only leave a `/lgtm` on
 a change that doesn't need additional technical review.

-For more about how to become a SIG Docs approver and the responsibilities and
-time commitment involved, see
-[Becoming a reviewer or approver](#becoming-an-approver-or-reviewer).
-
-#### Becoming an approver
+### Becoming an approver

 When you meet the
 [requirements](https://github.com/kubernetes/community/blob/master/community-membership.md#approver),
@@ -201,34 +203,29 @@ If you are approved, request that a current SIG Docs approver add you to the
 GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
 add new members to a GitHub group.

-#### Approver responsibilities
+### Approver responsibilities

 Approvers improve the documentation by reviewing and merging pull requests into the website repository. Because this role carries additional privileges, approvers have additional responsibilities:

 - Approvers can use the `/approve` command, which merges PRs into the repo.

    A careless merge can break the site, so be sure that when you merge something, you mean it.
-    
- Make sure that proposed changes meet the contribution guidelines. 
+
+- Make sure that proposed changes meet the [contribution guidelines](/docs/contribute/style/content-guide/#contributing-content).

    If you ever have a question, or you're not sure about something, feel free to call for additional review.

- Verify that netlify tests pass before you `/approve` a PR.
+- Verify that Netlify tests pass before you `/approve` a PR.

    <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify tests must pass before approving" />

- Visit the netlify page preview for a PR to make sure things look good before approving.
+- Visit the Netlify page preview for a PR to make sure things look good before approving.

-#### PR Wrangler
-
-SIG Docs approvers participate in the
-[PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)
-for weekly rotations. SIG Docs expects all approvers to participate in this
-rotation. See
-[Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
+- Participate in the [PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this
+rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)
 for more details.

-#### SIG Docs chairperson
+## SIG Docs chairperson

 Each SIG, including SIG Docs, selects one or more SIG members to act as
 chairpersons. These are points of contact between SIG Docs and other parts of
@@ -285,6 +282,24 @@ The combination of OWNERS files and front-matter in Markdown files determines
 the advice PR owners get from automated systems about who to ask for technical
 and editorial review of their PR.

+## How merging works
+
+When a pull request is merged to the branch used to publish content (currently
+`master`), that content is published and available to the world. To ensure that
+the quality of our published content is high, we limit merging pull requests to
+SIG Docs approvers. Here's how it works.
+
+- When a pull request has both the `lgtm` and `approve` labels, has no `hold`
+  labels, and all tests are passing, the pull request merges automatically.
+- Kubernetes organization members and SIG Docs approvers can add comments to
+  prevent automatic merging of a given pull request (by adding a `/hold` comment
+  or withholding a `/lgtm` comment).
+- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment.
+- Only SIG Docs approvers can merge a pull request
+  by adding an `/approve` comment. Some approvers also perform additional
+  specific roles, such as [PR Wrangler](#pr-wrangler) or
+  [SIG Docs chairperson](#sig-docs-chairperson).
+
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -295,5 +310,3 @@ For more information about contributing to the Kubernetes documentation, see:
 - [Documentation style](/docs/contribute/style/)

 {{% /capture %}}
-
-
@@ -196,15 +196,38 @@ to base your work on. Use these guidelines to make the decision:

 - Use `master` for fixing problems in content that is already published, or
  making improvements to content that already exists.
-  - Use a release branch (such as `dev-{{< release-branch >}}` for the {{< release-branch >}} release) to document upcoming features
-  or changes for an upcoming release that is not yet published.
- Use a feature branch that has been agreed upon by SIG Docs to collaborate on
-  big improvements or changes to the existing documentation, including content
-  reorganization or changes to the look and feel of the website.
+- Use `master` to document something that is already part of the current
+  Kubernetes release, but isn't yet documented. You should write this content
+  in English first, and then localization teams will pick that change up as a
+  localization task.
+- If you're working on a localization, you should follow the convention for
+  that particular localization. To find this out, you can look at other
+  pull requests (tip: search for `is:pr is:merged label:language/xx`)
+  {{< comment >}}Localization note: when localizing that tip, replace `xx`
+  with the actual ISO3166 two-letter code for your target locale.{{< /comment >}}
+  - Some localization teams work with PRs that target `master`
+  - Some localization teams work with a series of long-lived branches, and
+    periodically merge these to `master`. This kind of branch has a name like
+    dev-\<version>-\<language code>.\<team milestone>; for example:
+    `dev-{{< release-branch >}}-ja.1`.
+- If you're writing or updating documentation for a feature change release,
+  then you need to know the major and minor version of Kubernetes that
+  the change will first appear in.
+  - For example, if the feature gate JustAnExample is going to move from alpha
+    to beta in the next minor version, you need to know what the next minor
+    version number is.
+  - Find the release branch named for that version. For example, features that
+    changed in the v{{< release-branch >}} release got documented in the branch
+    named `dev-{{< release-branch >}}`.

 If you're still not sure which branch to choose, ask in `#sig-docs` on Slack or
 attend a weekly SIG Docs meeting to get clarity.

+{{< note >}}
+If you already submitted your pull request and you know that the Base Branch
+was wrong, you (and only you, the submitter) can change it.
+{{< /note >}}
+
 ### Submit a pull request

 Follow these steps to submit a pull request to improve the Kubernetes
@@ -47,7 +47,7 @@ Before adding content, ask yourself this:
 - Is the content about an active CNCF project OR a project in the kubernetes or kubernetes-sigs GitHub organizations?
    - If yes, then:
        - Does the project have its own documentation?
-            - if yes, link to the project's documention from the Kubernetes documentation
+            - if yes, link to the project's documentation from the Kubernetes documentation
            - if no, add the content to the project's repository if possible and then link to it from the Kubernetes documentation
    - If no, then:
        - Stop!
@@ -64,7 +64,7 @@ Below are general categories of non-Kubernetes project content along with guidel
        - Referring to or linking to existing documentation about a CNCF project or a project in the kubernetes or kubernetes-sigs GitHub organizations
            - Example: for installating Kubernetes in a learning environment, including a prerequisite stating that successful installation and configuration of minikube is required and linking to the relevant minikube documentation
        - Adding content for kubernetes or kubernetes-sigs projects that don't have their own instructional content
-            - Example: including [kubadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions
+            - Example: including [kubeadm](https://github.com/kubernetes/kubeadm) installation and troubleshooting instructions
    - Not Allowed:
        - Adding content that duplicates documentation in another repository
            - Examples:
@@ -115,8 +115,9 @@ When adding a new standalone sample file, such as a YAML file, place the code in
 one of the `<LANG>/examples/` subdirectories where `<LANG>` is the language for
 the topic. In your topic file, use the `codenew` shortcode:

-<pre>&#123;&#123;&lt; codenew file="&lt;RELPATH&gt;/my-example-yaml&gt;" &gt;&#125;&#125;</pre>
-
+```none
+{{</* codenew file="<RELPATH>/my-example-yaml>" */>}}
+```
 where `<RELPATH>` is the path to the file to include, relative to the
 `examples` directory. The following Hugo shortcode references a YAML
 file located at `/content/en/examples/pods/storage/gce-volume.yaml`.
@@ -19,12 +19,7 @@ This section of the Kubernetes documentation contains references.
 ## API Reference

 * [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes.
-* Kubernetes API Versions
-  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
-  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
-  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
-  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
-  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
+* [Kubernetes API Reference {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)

 ## API Client Libraries

@@ -39,18 +34,17 @@ client libraries:

 ## CLI Reference

-* [kubectl](/docs/user-guide/kubectl-overview) - Main CLI tool for running commands and managing Kubernetes clusters.
-    * [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
-* [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
-* [kubefed](/docs/admin/kubefed/) - CLI tool to help you administrate your federated clusters.
+* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
+    * [JSONPath](/docs/reference/kubectl/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
+* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.

 ## Config Reference

-* [kubelet](/docs/admin/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.
-* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API that validates and configures data for API objects such as  pods, services, replication controllers.
-* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
-* [kube-proxy](/docs/admin/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
-* [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - The primary *node agent* that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - REST API that validates and configures data for API objects such as  pods, services, replication controllers.
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.

 ## Design Docs

@@ -969,9 +969,10 @@ Specifying `Equivalent` is recommended, and ensures that webhooks continue to in
 resources they expect when upgrades enable new versions of the resource in the API server.

 When a resource stops being served by the API server, it is no longer considered equivalent to other versions of that resource that are still served.
-For example, deprecated `extensions/v1beta1` deployments are scheduled to stop being served by default in v1.16.
-Once that occurs, a webhook with a `apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"]` rule
-would no longer intercept deployments created via `apps/v1` APIs. For that reason, webhooks should prefer registering
+For example, `extensions/v1beta1` deployments were first deprecated and then removed (in Kubernetes v1.16).
+
+Since that removal, a webhook with a `apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"]` rule
+does not intercept deployments created via `apps/v1` APIs. For that reason, webhooks should prefer registering
 for stable versions of resources.

 This example shows a validating webhook that intercepts modifications to deployments (no matter the API group or version),
@@ -15,7 +15,7 @@ tags:

 <!--more-->

-Kubernetes supports several container runtimes: [Docker](http://www.docker.com),
-[containerd](https://containerd.io), [cri-o](https://cri-o.io/),
-[rktlet](https://github.com/kubernetes-incubator/rktlet) and any implementation of
-the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
+Kubernetes supports several container runtimes: {{< glossary_tooltip term_id="docker">}},
+{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
+and any implementation of the [Kubernetes CRI (Container Runtime
+Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
@@ -4,14 +4,26 @@ id: device-plugin
 date: 2019-02-02
 full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
 short_description: >
-  Containers running in Kubernetes that provide access to a vendor specific resource.
+  Software extensions to let Pods access devices that need vendor-specific initialization or setup
 aka:
 tags:
 - fundamental
 - extension
 ---
- Device Plugins are containers running in Kubernetes that provide access to a vendor specific resource.
+ Device plugins run on worker
+{{< glossary_tooltip term_id="node" text="Nodes">}} and provide
+{{< glossary_tooltip term_id="pod" text="Pods ">}} with access to resources,
+such as local hardware, that require vendor-specific initialization or setup
+steps.

 <!--more-->

-[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) are containers running in Kubernetes that provide access to a vendor-specific resource. Device Plugins advertise these resources to {{< glossary_tooltip term_id="kubelet" >}}. They can be deployed manually or as a {{< glossary_tooltip term_id="daemonset" >}}, rather than writing custom Kubernetes code.
+Device plugins advertise resources to the
+{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}, so that workload
+Pods can access hardware features that relate to the Node where that Pod is running.
+You can deploy a device plugin as a {{< glossary_tooltip term_id="daemonset" >}},
+or install the device plugin software directly on each target Node.
+
+See
+[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+for more information.
@@ -15,5 +15,5 @@ tags:

 <!--more--> 

-When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+When processes inside Pods access the cluster, they are authenticated by the API server as a particular service account, for example, `default`. When you create a Pod, if you do not specify a service account, it is automatically assigned the default service account in the same {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.

@@ -14,6 +14,6 @@ tags:

 <!--more--> 

-* In the **Kubernetes Community**: Conversations often use *upstream* to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools relies upon. For example, [community members](#term-member) may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool.
+* In the **Kubernetes Community**: Conversations often use *upstream* to mean the core Kubernetes codebase, which the general ecosystem, other code, or third-party tools rely upon. For example, [community members](#term-member) may suggest that a feature is moved upstream so that it is in the core codebase instead of in a plugin or third-party tool.
 * In **GitHub** or **git**: The convention is to refer to a source repo as *upstream*, whereas the forked repo is considered *downstream*.

@@ -144,7 +144,7 @@ EOF
 # Get commands with basic output
 kubectl get services                          # List all services in the namespace
 kubectl get pods --all-namespaces             # List all pods in all namespaces
-kubectl get pods -o wide                      # List all pods in the namespace, with more details
+kubectl get pods -o wide                      # List all pods in the current namespace, with more details
 kubectl get deployment my-dep                 # List a particular deployment
 kubectl get pods                              # List all pods in the namespace
 kubectl get pod my-pod -o yaml                # Get a pod's YAML
@@ -160,8 +160,8 @@ kubectl get services --sort-by=.metadata.name
 # List pods Sorted by Restart Count
 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

-# List PersistentVolumes in test namespace sorted by capacity
-kubectl get pv -n test --sort-by=.spec.capacity.storage
+# List PersistentVolumes sorted by capacity
+kubectl get pv --sort-by=.spec.capacity.storage

 # Get the version label of all pods with label app=cassandra
 kubectl get pods --selector=app=cassandra -o \
@@ -201,7 +201,7 @@ kubectl diff -f ./my-manifest.yaml

 ## Updating Resources

-As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), use `rollout` instead.
+As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead.

 ```bash
 kubectl set image deployment/frontend www=image:v2               # Rolling update "www" containers of "frontend" deployment, updating the image
@@ -89,11 +89,13 @@ kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
 kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
 ```

+{{< note >}}
 On Windows, you must _double_ quote any JSONPath template that contains spaces (not single quote as shown above for bash). This in turn means that you must use a single quote or escaped double quote around any literals in the template. For example:

 ```cmd
-C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
-C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
+kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
+kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
 ```
+{{< /note >}}

 {{% /capture %}}
@@ -10,7 +10,7 @@ card:
 ---

 {{% capture overview %}}
-Kubectl is a command line interface for running commands against Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
+Kubectl is a command line tool for controlling Kubernetes clusters. `kubectl` looks for a file named config in the $HOME/.kube directory. You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) files by setting the KUBECONFIG environment variable or by setting the [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.

 This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).

@@ -343,9 +343,6 @@ kubectl delete -f pod.yaml
 # Delete all the pods and services that have the label name=<label-name>.
 kubectl delete pods,services -l name=<label-name>

-# Delete all the pods and services that have the label name=<label-name>.
-kubectl delete pods,services -l name=<label-name>
-
 # Delete all pods, including uninitialized ones.
 kubectl delete pods --all
 ```
@@ -334,16 +334,16 @@ are not vulnerable to ordering changes in the list.
 Once the last finalizer is removed, the resource is actually removed from etcd.


-## Dry run
+## Dry-run

-{{< feature-state for_k8s_version="v1.13" state="beta" >}} In version 1.13, the dry run beta feature is enabled by default. The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry run mode. Dry run mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non dry run response. The system guarantees that dry run requests will not be persisted in storage or have any other side effects.
+{{< feature-state for_k8s_version="v1.13" state="beta" >}} In version 1.13, the dry-run beta feature is enabled by default. The modifying verbs (`POST`, `PUT`, `PATCH`, and `DELETE`) can accept requests in a dry-run mode. DryRun mode helps to evaluate a request through the typical request stages (admission chain, validation, merge conflicts) up until persisting objects to storage. The response body for the request is as close as possible to a non-dry-run response. The system guarantees that dry-run requests will not be persisted in storage or have any other side effects.


-### Make a dry run request
+### Make a dry-run request

-Dry run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and in 1.13 the only accepted values are:
+Dry-run is triggered by setting the `dryRun` query parameter. This parameter is a string, working as an enum, and in 1.13 the only accepted values are:

-* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry run requests.
+* `All`: Every stage runs as normal, except for the final storage stage. Admission controllers are run to check that the request is valid, mutating controllers mutate the request, merge is performed on `PATCH`, fields are defaulted, and schema validation occurs. The changes are not persisted to the underlying storage, but the final object which would have been persisted is still returned to the user, along with the normal status code. If the request would trigger an admission controller which would have side effects, the request will be failed rather than risk an unwanted side effect. All built in admission control plugins support dry-run. Additionally, admission webhooks can declare in their [configuration object](/docs/reference/generated/kubernetes-api/v1.13/#webhook-v1beta1-admissionregistration-k8s-io) that they do not have side effects by setting the sideEffects field to "None". If a webhook actually does have side effects, then the sideEffects field should be set to "NoneOnDryRun", and the webhook should also be modified to understand the `DryRun` field in AdmissionReview, and prevent side effects on dry-run requests.
 * Leave the value empty, which is also the default: Keep the default modifying behavior.

 For example:
@@ -352,12 +352,28 @@ For example:
        Content-Type: application/json
        Accept: application/json

-The response would look the same as for non dry run request, but the values of some generated fields may differ.
+The response would look the same as for non-dry-run request, but the values of some generated fields may differ.

+### Dry-run authorization
+
+Authorization for dry-run and non-dry-run requests is identical. Thus, to make
+a dry-run request, the user must be authorized to make the non-dry-run request.
+
+For example, to run a dry-run `PATCH` for Deployments, you must have the
+`PATCH` permission for Deployments, as in the example of the RBAC rule below.
+
+```yaml
+rules:
+- apiGroups: ["extensions", "apps"]
+  resources: ["deployments"]
+  verbs: ["patch"]
+```
+
+See [Authorization Overview](/docs/reference/access-authn-authz/authorization/).

 ### Generated values

-Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry run request, since these values will likely be different in dry run mode from when the real request is made. Some of these fields are:
+Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry-run request, since these values will likely be different in dry-run mode from when the real request is made. Some of these fields are:

 * `name`: if `generateName` is set, `name` will have a unique random name
 * `creationTimestamp`/`deletionTimestamp`: records the time of creation/deletion
@@ -557,14 +573,22 @@ more information about how an object's schema is used to make decisions when
 merging, see
 [sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff).

+A number of markers were added in Kubernetes 1.16 and 1.17, to allow API developers to describe the merge strategy supported by lists, maps, and structs. These markers can be applied to objects of the respective type, in Go files or OpenAPI specs.
+
+| Golang marker | OpenAPI extension | Accepted values | Description | Introduced in |
+|---|---|---|---|---|
+| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16          |
+| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries e.g. `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 |
+| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 |
+| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 |
+
 ### Custom Resources

 By default, Server Side Apply treats custom resources as unstructured data. All
 keys are treated the same as struct fields, and all lists are considered atomic.
-If the validation field is specified in the Custom Rseource Definition, it is
+If the validation field is specified in the Custom Resource Definition, it is
 used when merging objects of this type.

-
 ### Using Server-Side Apply in a controller

 As a developer of a controller, you can use server-side apply as a way to
@@ -667,32 +691,33 @@ For get and list, the semantics of resource version are:

 **Get:**

-| resourceVersion unset | resourceVersion="0" | resourceVersion="{non-zero version}" |
-|-----------------------|---------------------|--------------------------------------|
-| Most Recent           | Any                 | Not older than                       |
+| resourceVersion unset | resourceVersion is `0` | resourceVersion is set but not `0` |
+|-----------------------|------------------------|------------------------------------|
+| Most Recent           | Any                    | Not older than                     |

 **List:**

-| paging    | resourceVersion unset | resourceVersion="0" | resourceVersion="{non-zero version}" |
-|-----------|-----------------------|---------------------|--------------------------------------|
-| no limit  | Most Recent           | Any                 | Not older than                       |
-| limit="n" | Most Recent           | Any                 | Exact                                |
-
+| paging                        | resourceVersion unset | resourceVersion="0"                            | resourceVersion="{value other than 0}" |
+|-------------------------------|-----------------------|------------------------------------------------|----------------------------------------|
+| limit unset                   | Most Recent           | Any                                            | Not older than                         |
+| limit="n", continue unset     | Most Recent           | Any                                            | Exact                                  |
+| limit="n", continue="<token>" | Continue Token, Exact | Invalid, but treated as Continue Token, Exact  | Invalid, HTTP `400 Bad Request`        |

 The meaning of the get and list semantics are:

 - **Most Recent:** Return data at the most recent resource version. The returned data must be consistent (i.e. served from etcd via a quorum read).
- **Any:** Return data at any resource version. The newest available resource version is preferred, but strong consistency is not required; data at any resource version may be served. It is possible for the request to return data at a much older resource version that the client has previously observed, particularly in high availability configurations, due to partitions or stale caches. Clients that cannot tolerate this should not use this semantic.
- **Not older than:** Return data at least as new as the provided resource version. The newest available resource version is preferred, but any data not older than this resource version may be served.
+- **Any:** Return data at any resource version. The newest available resource version is preferred, but strong consistency is not required; data at any resource version may be served. It is possible for the request to return data at a much older resource version that the client has previously observed, particularly in high availabiliy configurations, due to partitions or stale caches. Clients that cannot tolerate this should not use this semantic.
+- **Not older than:** Return data at least as new as the provided resource version. The newest available data is preferred, but any data not older than this resource version may be served. Note that this ensures only that the objects returned are no older than they were at the time of the provided resource version. The resource version in the `ObjectMeta` of individual object may be older than the provide resource version so long it is for the latest modification to the object at the time of the provided resource version.
 - **Exact:** Return data at the exact resource version provided.
+- **Continue Token, Exact:** Return data at the resource version of the initial paginated list call. The returned Continue Tokens are responsible for keeping track of the initially provided resource version for all paginated list calls after the initial paginated list call.

 For watch, the semantics of resource version are:

 **Watch:**

-| resourceVersion unset               | resourceVersion="0"        | resourceVersion="{non-zero version}" |
-|-------------------------------------|----------------------------|--------------------------------------|
-| Get State and Start at Most Recent  | Get State and Start at Any | Start at Exact                       |
+| resourceVersion unset               | resourceVersion="0"        | resourceVersion="{value other than 0}" |
+|-------------------------------------|----------------------------|----------------------------------------|
+| Get State and Start at Most Recent  | Get State and Start at Any | Start at Exact                         |

 The meaning of the watch semantics are:

@@ -704,4 +729,8 @@ The meaning of the watch semantics are:

 Servers are not required to serve all older resource versions and may return a HTTP `410 (Gone)` status code if a client requests a resourceVersion older than the server has retained. Clients must be able to tolerate `410 (Gone)` responses. See [Efficient detection of changes](#efficient-detection-of-changes) for details on how to handle `410 (Gone)` responses when watching resources.

-For example, the kube-apiserver periodically compacts old resource versions from etcd based on its `--etcd-compaction-interval` setting. Also, the kube-apiserver's watch cache keeps `--watch-cache-sizes` resource versions in each resource cache. It depends on if a request is served from cache on which one of these limits applies, but if a resource version is unavailable in the one that applies, a `410 (Gone)` will be returned by the kube-apiserver.
+If you request a a resourceVersion outside the applicable limit then, depending on whether a request is served from cache or not, the API server may reply with a `410 Gone` HTTP response.
+
+### Unavailable resource versions
+
+Servers are not required to serve unrecognized resource versions. List and Get requests for unrecognized resource versions may wait briefly for the resource version to become available, should timeout with a `504 (Gateway Timeout)` if the provided resource versions does not become available in a resonable amount of time, and may respond with a `Retry-After` response header indicating how many seconds a client should wait before retrying the request. Currently the kube-apiserver also identifies these responses with a "Too large resource version" message. Watch requests for a unrecognized resource version may wait indefinitely (until the request timeout) for the resource version to become available.
@@ -41,7 +41,7 @@ If you're learning Kubernetes, use the Docker-based solutions: tools supported b
 |Community           |Ecosystem     |
 | ------------       | --------     |
 | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) |
-| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
+| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
 |                     | [Minishift](https://docs.okd.io/latest/minishift/)|
 |                     | [MicroK8s](https://microk8s.io/)|
 |                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
@@ -83,7 +83,7 @@ The following production environment solutions table lists the providers and the
 | [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
 | [Giant Swarm](https://www.giantswarm.io/)     | &#x2714;       | &#x2714; |   &#x2714;    |     |
 | [Google](https://cloud.google.com/)           |  [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/)       | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/)       |  |  |     |  |      |       |  |
-| [Hidora](https:/hidora.com/)           |  &#x2714;       | &#x2714;| &#x2714;       |  |  |     |  |      |       |  |
+| [Hidora](https://hidora.com/)           |  &#x2714;       | &#x2714;| &#x2714;       |  |  |     |  |      |       |  |
 | [IBM](https://www.ibm.com/in-en/cloud)        | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
 | [Ionos](https://www.ionos.com/enterprise-cloud)        | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
 | [Kontena Pharos](https://www.kontena.io/pharos/)          |    |&#x2714;|    &#x2714;    |        |         |
@@ -92,7 +92,7 @@ Hosts/SAN listed above are the recommended ones for getting a working cluster; i
 For kubeadm users only:

 * The scenario where you are copying to your cluster CA certificates without private keys is referred as external CA in the kubeadm documentation.
-* If you are comparing the above list with a kubeadm geneerated PKI, please be aware that `kube-etcd`, `kube-etcd-peer` and `kube-etcd-healthcheck-client` certificates
+* If you are comparing the above list with a kubeadm generated PKI, please be aware that `kube-etcd`, `kube-etcd-peer` and `kube-etcd-healthcheck-client` certificates
  are not generated in case of external etcd.

 {{< /note >}}
@@ -0,0 +1,23 @@
+---
+title: Installing Kubernetes with Kind
+weight: 40
+content_template: templates/concept
+---
+
+{{% capture overview %}}
+
+Kind is a tool for running local Kubernetes clusters using Docker container "nodes".
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Installation
+
+See [Installing Kind](https://kind.sigs.k8s.io/docs/user/quick-start/).
+
+{{% /capture %}}
+
+
+
+
@@ -205,7 +205,11 @@ plugins.
 * hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
 Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`.
 * vmware ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver)
-* none (Runs the Kubernetes components on the host and not in a VM. It is not recommended to run the none driver on personal workstations. Using this driver requires Docker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) and a Linux environment)
+* none (Runs the Kubernetes components on the host and not in a virtual machine. You need to be running Linux and to have {{< glossary_tooltip term_id="docker" >}} installed.)
+
+{{< caution >}}
+If you use the `none` driver, some Kubernetes components run as privileged containers that have side effects outside of the Minikube environment. Those side effects mean that the `none` driver is not recommended for personal workstations.
+{{< /caution >}}

 #### Starting a cluster on alternative container runtimes
 You can start Minikube on the following container runtimes.
@@ -263,11 +267,7 @@ When using a single VM for Kubernetes, it's useful to reuse Minikube's built-in
 Be sure to tag your Docker image with something other than latest and use that tag to pull the image. Because `:latest` is the default value, with a corresponding default image pull policy of `Always`, an image pull error (`ErrImagePull`) eventually results if you do not have the Docker image in the default Docker registry (usually DockerHub).
 {{< /note >}}

-To work with the Docker daemon on your Mac/Linux host, use the `docker-env command` in your shell:
-
-```shell
-eval $(minikube docker-env)
-```
+To work with the Docker daemon on your Mac/Linux host, run the last line from `minikube docker-env`.

 You can now use Docker at the command line of your host Mac/Linux machine to communicate with the Docker daemon inside the Minikube VM:

@@ -74,8 +74,8 @@ Use the following commands to install Docker on your system:
 # Install Docker CE
 ## Set up the repository:
 ### Install packages to allow apt to use a repository over HTTPS
-apt-get update && apt-get install \
-  apt-transport-https ca-certificates curl software-properties-common
+apt-get update && apt-get install -y \
+  apt-transport-https ca-certificates curl software-properties-common gnupg2

 ### Add Docker’s official GPG key
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
@@ -87,7 +87,7 @@ add-apt-repository \
  stable"

 ## Install Docker CE.
-apt-get update && apt-get install \
+apt-get update && apt-get install -y \
  containerd.io=1.2.10-3 \
  docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
  docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
@@ -115,14 +115,14 @@ systemctl restart docker
 # Install Docker CE
 ## Set up the repository
 ### Install required packages.
-yum install yum-utils device-mapper-persistent-data lvm2
+yum install -y yum-utils device-mapper-persistent-data lvm2

 ### Add Docker repository.
 yum-config-manager --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo

 ## Install Docker CE.
-yum update && yum install \
+yum update -y && yum install -y \
  containerd.io-1.2.10 \
  docker-ce-19.03.4 \
  docker-ce-cli-19.03.4
@@ -183,13 +183,13 @@ sysctl --system

 # Install prerequisites
 apt-get update
-apt-get install software-properties-common
+apt-get install -y software-properties-common

 add-apt-repository ppa:projectatomic/ppa
 apt-get update

 # Install CRI-O
-apt-get install cri-o-1.15
+apt-get install -y cri-o-1.15

 {{< /tab >}}
 {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
@@ -198,7 +198,7 @@ apt-get install cri-o-1.15
 yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/

 # Install CRI-O
-yum install --nogpgcheck cri-o
+yum install --nogpgcheck -y cri-o

 {{< /tab >}}
 {{< /tabs >}}
@@ -272,7 +272,7 @@ systemctl restart containerd
 # Install containerd
 ## Set up the repository
 ### Install required packages
-yum install yum-utils device-mapper-persistent-data lvm2
+yum install -y yum-utils device-mapper-persistent-data lvm2

 ### Add docker repository
 yum-config-manager \
@@ -280,7 +280,7 @@ yum-config-manager \
    https://download.docker.com/linux/centos/docker-ce.repo

 ## Install containerd
-yum update && yum install containerd.io
+yum update -y && yum install -y containerd.io

 # Configure containerd
 mkdir -p /etc/containerd
@@ -269,8 +269,7 @@ kubeadm only supports Container Network Interface (CNI) based networks (and does

 Several projects provide Kubernetes Pod networks using CNI, some of which also
 support [Network Policy](/docs/concepts/services-networking/networkpolicies/). See the [add-ons page](/docs/concepts/cluster-administration/addons/) for a complete list of available network add-ons.
- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0).
- [CNI bridge](https://github.com/containernetworking/plugins/blob/master/plugins/main/bridge/README.md) and [local-ipam](https://github.com/containernetworking/plugins/blob/master/plugins/ipam/host-local/README.md) are the only supported IPv6 network plugins in Kubernetes version 1.9.
+- IPv6 support was added in [CNI v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). See each plugin's documentation to see if it supports IPv6.

 Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/docs/reference/access-authn-authz/rbac/).
 Make sure that your network manifest supports RBAC.
@@ -290,12 +289,12 @@ Below you can find installation instructions for some popular Pod network plugin
 {{< tabs name="tabs-pod-install" >}}

 {{% tab name="Calico" %}}
-For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
+[Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`.

-For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64`, `arm64`, and `ppc64le` only.
+By default, Calico uses `192.168.0.0/16` as the Pod network CIDR, though this can be configured in the calico.yaml file. For Calico to work correctly, you need to pass this same CIDR to the kubeadm init command using the `--pod-network-cidr=192.168.0.0/16` flag or via the kubeadm configuration.

 ```shell
-kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
+kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml
 ```

 {{% /tab %}}
@@ -140,7 +140,7 @@ If the container runtime of choice is Docker, it is used through the built-in

 Other CRI-based runtimes include:

- [containerd](https://github.com/containerd/cri) (CRI plugin built into containerd)
+- [containerd/cri](https://github.com/containerd/cri) (CRI plugin built into containerd)
 - [cri-o](https://cri-o.io/)
 - [frakti](https://github.com/kubernetes/frakti)

@@ -62,9 +62,9 @@ Kubespray provides the ability to customize many aspects of the deployment:
 * Component versions
 * Calico route reflectors
 * Component runtime options
-  * docker
-  * rkt
-  * cri-o
+  * {{< glossary_tooltip term_id="docker" >}}
+  * {{< glossary_tooltip term_id="rkt" >}}
+  * {{< glossary_tooltip term_id="cri-o" >}}
 * Certificate generation methods (**Vault being discontinued**)

 Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
@@ -105,7 +105,7 @@ The Kubernetes in-tree storage plugin to Container Storage Interface (CSI) migra

 #### Storage

- All nodes need to be drained before upgrading Kubernetes cluster, because paths used for block volumes are changed in this release, so on-line upgrade of nodes aren't allowed. ([#74026](https://github.com/kubernetes/kubernetes/pull/74026), [@mkimuram](https://github.com/mkimuram))
+- A node that uses a CSI raw block volume needs to be drained before kubelet can be upgraded to 1.17. ([#74026](https://github.com/kubernetes/kubernetes/pull/74026), [@mkimuram](https://github.com/mkimuram))

 #### Windows

@@ -207,7 +207,7 @@ The Kubernetes apiserver has two client CA options:

 Each of these functions independently and can conflict with each other, if not used correctly.

-* `--client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file referenced by `--client-ca-file`, then the request is treated as a legitimate request, and the user is the value of the common name `CN=`, while the group is the organization `O=`. See the [documentaton on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certs).
+* `--client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file referenced by `--client-ca-file`, then the request is treated as a legitimate request, and the user is the value of the common name `CN=`, while the group is the organization `O=`. See the [documentation on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certs).
 * `--requestheader-client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file reference by `--requestheader-client-ca-file`, then the request is treated as a potentially legitimate request. The Kubernetes apiserver then checks if the common name `CN=` is one of the names in the list provided by `--requestheader-allowed-names`. If the name is allowed, the request is approved; if it is not, the request is not.

 If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided, then the request first checks the `--requestheader-client-ca-file` CA and then the `--client-ca-file`. Normally, different CAs, either root CAs or intermediate CAs, are used for each of these options; regular client requests match against `--client-ca-file`, while aggregation requests match against `--requestheader-client-ca-file`. However, if both use the _same_ CA, then client requests that normally would pass via `--client-ca-file` will fail, because the CA will match the CA in `--requestheader-client-ca-file`, but the common name `CN=` will **not** match one of the acceptable common names in `--requestheader-allowed-names`. This can cause your kubelets and other control plane components, as well as end-users, to be unable to authenticate to the Kubernetes apiserver.
@@ -5,6 +5,7 @@ reviewers:
 - liggitt
 content_template: templates/task
 weight: 30
+min-kubernetes-server-version: v1.16
 ---

 {{% capture overview %}}
@@ -16,11 +17,11 @@ level of your CustomResourceDefinitions or advance your API to a new version wit

 {{% capture prerequisites %}}

-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}

-* Make sure your Kubernetes cluster has a master version of 1.16.0 or higher for `apiextensions.k8s.io/v1`, or 1.11.0 or higher for `apiextensions.k8s.io/v1beta1`.
+You should have a initial understanding of [custom resources](/docs/concepts/api-extension/custom-resources/).

-* Read about [custom resources](/docs/concepts/api-extension/custom-resources/).
+{{< version-check >}}

 {{% /capture %}}

@@ -28,8 +29,6 @@ level of your CustomResourceDefinitions or advance your API to a new version wit

 ## Overview

-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
-
 The CustomResourceDefinition API provides a workflow for introducing and upgrading
 to new versions of a CustomResourceDefinition.

@@ -38,6 +38,8 @@ Get the API versions:

    curl http://localhost:8080/api/

+The output should look similar to this:
+
    {
      "kind": "APIVersions",
      "versions": [
@@ -55,6 +57,8 @@ Get a list of pods:

    curl http://localhost:8080/api/v1/namespaces/default/pods

+The output should look similar to this:
+
    {
      "kind": "PodList",
      "apiVersion": "v1",
@@ -43,7 +43,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
        pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
        pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3    manual                     3s

-   This list also includes the name of the claims that are bound to each volume
+     This list also includes the name of the claims that are bound to each volume
   for easier identification of dynamically provisioned volumes.

 1. Choose one of your PersistentVolumes and change its reclaim policy:
@@ -54,6 +54,15 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to

    where `<your-pv-name>` is the name of your chosen PersistentVolume.

+    {{< note >}}
+    On Windows, you must _double_ quote any JSONPath template that contains spaces (not single quote as shown above for bash). This in turn means that you must use a single quote or escaped double quote around any literals in the template. For example:
+
+```cmd
+kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
+```
+
+    {{< /note >}}
+
 1. Verify that your chosen PersistentVolume has the right policy:

    ```shell
@@ -215,8 +215,8 @@ etcd2 and etcd3 is as follows:
                      message `etcd2 is no longer a supported storage backend`

 Before upgrading a v1.12.x kube-apiserver using `--storage-backend=etcd2` to
-v1.13.x, etcd v2 data MUST by migrated to the v3 storage backend, and
-kube-apiserver invocations changed to use `--storage-backend=etcd3`.
+v1.13.x, etcd v2 data must be migrated to the v3 storage backend and
+kube-apiserver invocations must be changed to use `--storage-backend=etcd3`.

 The process for migrating from etcd2 to etcd3 is highly dependent on how the
 etcd cluster was deployed and configured, as well as how the Kubernetes
@@ -258,14 +258,7 @@ Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
 cluster DNS by default, because that process is inherently distribution-specific.
 This should probably be implemented eventually.

-Linux's libc is impossibly stuck ([see this bug from
-2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
-3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to
-consume 1 `nameserver` record and 3 `search` records. This means that if a
-local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
-some of those settings will be lost. As a partial workaround, the node can run
-`dnsmasq` which will provide more `nameserver` entries, but not more `search`
-entries. You can also use kubelet's `--resolv-conf` flag.
+Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glic-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc versions in the affected list, some of those settings will be lost. For the workaround of the DNS `nameserver` records limit, the node can run `dnsmasq` which will provide more `nameserver` entries, you can also use kubelet's `--resolv-conf` flag. For fixing the DNS `search` records limit, consider upgrading your linux distribution or glibc version.

 If you are using Alpine version 3.3 or earlier as your base image, DNS may not
 work properly owing to a known issue with Alpine.
@@ -97,7 +97,7 @@ kubectl apply -f dns-horizontal-autoscaler.yaml

 The output of a successful command is:

-    deployment.apps/kube-dns-autoscaler created
+    deployment.apps/dns-autoscaler created

 DNS horizontal autoscaling is now enabled.

@@ -0,0 +1,54 @@
+---
+reviewers:
+- andrewsykim
+- johnbelamaric
+- imroc
+title: Enabling Service Topology
+content_template: templates/task
+---
+
+{{% capture overview %}}
+This page provides an overview of enabling Service Topology in Kubernetes.
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+  {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Introduction
+
+_Service Topology_ enables a service to route traffic based upon the Node
+topology of the cluster. For example, a service can specify that traffic be
+preferentially routed to endpoints that are on the same Node as the client, or
+in the same availability zone.
+
+## Prerequisites
+
+The following prerequisites are needed in order to enable topology aware service
+routing:
+
+   * Kubernetes 1.17 or later
+   * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}} running in iptables mode or IPVS mode
+   * Enable [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
+
+## Enable Service Topology
+
+{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
+
+To enable service topology, enable the `ServiceTopology` and `EndpointSlice` feature gate for all Kubernetes components:
+
+```
+--feature-gates="ServiceTopology=true,EndpointSlice=true"
+```
+
+
+{{% capture whatsnext %}}
+
+* Read about the [Service Topology](/docs/concepts/services-networking/service-topology) concept
+* Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices)
+* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
+
+{{% /capture %}}
@@ -3,6 +3,7 @@ reviewers:
 - smarterclayton
 title: Encrypting Secret Data at Rest
 content_template: templates/task
+min-kubernetes-server-version: 1.13
 ---

 {{% capture overview %}}
@@ -13,9 +14,7 @@ This page shows how to enable and configure encryption of secret data at rest.

 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-* Kubernetes version 1.13.0 or later is required
-
-* etcd v3 or later is required
+* etcd v3.0 or later is required

 {{% /capture %}}

@@ -27,9 +26,6 @@ The `kube-apiserver` process accepts an argument `--encryption-provider-config`
 that controls how API data is encrypted in etcd. An example configuration
 is provided below.

-Note:
-The alpha version of the encryption feature prior to 1.13 used the `--experimental-encryption-provider-config` flag.
-
 ## Understanding the encryption at rest configuration.

 ```yaml
@@ -69,10 +65,6 @@ resources from storage each provider that matches the stored data attempts to de
 order. If no provider can read the stored data due to a mismatch in format or secret key, an error 
 is returned which prevents clients from accessing that resource. 

-Note:
-The alpha version of the encryption feature prior to 1.13 required to be configured with
-`kind: EncryptionConfig` and `apiVersion: v1`.
-
 {{< caution >}}
 **IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), 
 the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to 
@@ -81,11 +73,12 @@ read that resource will fail until it is deleted or a valid decryption key is pr

 ### Providers:

+{{< table caption="Providers for Kubernetes encryption at rest" >}}
 Name | Encryption | Strength | Speed | Key Length | Other Considerations
 -----|------------|----------|-------|------------|---------------------
 `identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
 `aescbc` | AES-CBC with PKCS#7 padding | Strongest | Fast | 32-byte | The recommended choice for encryption at rest but may be slightly slower than `secretbox`.
-`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review. 
+`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review.
 `aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented.
 `kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes |  The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)

@@ -95,12 +88,12 @@ is the first provider, the first key is used for encryption.
 __Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption.
 Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which
 provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key.
+
 Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise.
 Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and
-extract the encryption keys. This was a stepping stone in development to the `kms` provider, introduced in 1.10, and beta since 1.12. Envelope encryption
-creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the
-kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than
-locally-stored encryption keys.
+extract the encryption keys.
+
+Envelope encryption creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than locally-stored encryption keys.

 ## Encrypting your data

@@ -137,7 +130,7 @@ Your config file contains keys that can decrypt content in etcd, so you must pro
 {{< /caution >}}


-## Verifying that data is encrypted 
+## Verifying that data is encrypted

 Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or
 updated secret should be encrypted when stored. To check, you can use the `etcdctl` command line
@@ -217,5 +210,3 @@ and restart all `kube-apiserver` processes. Then run the command `kubectl get se
 to force all secrets to be decrypted.

 {{% /capture %}}
-
-
@@ -4,17 +4,20 @@ reviewers:
 - dawnchen
 title: Reconfigure a Node's Kubelet in a Live Cluster
 content_template: templates/task
+min-kubernetes-server-version: v1.11
 ---

 {{% capture overview %}}
 {{< feature-state for_k8s_version="v1.11" state="beta" >}}

 [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281)
-allows you to change the configuration of each Kubelet in a live Kubernetes
-cluster by deploying a ConfigMap and configuring each Node to use it.
+allows you to change the configuration of each
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} in a running Kubernetes cluster,
+by deploying a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} and configuring
+each {{< glossary_tooltip term_id="node" >}} to use it.

 {{< warning >}}
-All Kubelet configuration parameters can be changed dynamically,
+All kubelet configuration parameters can be changed dynamically,
 but this is unsafe for some parameters. Before deciding to change a parameter
 dynamically, you need a strong understanding of how that change will affect your
 cluster's behavior. Always carefully test configuration changes on a small set
@@ -25,38 +28,49 @@ fields is available in the inline `KubeletConfiguration`
 {{% /capture %}}

 {{% capture prerequisites %}}
- Kubernetes v1.11 or higher on both the Master and the Nodes
- kubectl v1.11 or higher, configured to communicate with the cluster
- The Kubelet's `--dynamic-config-dir` flag must be set to a writable
-  directory on the Node.
+You need to have a Kubernetes cluster.
+You also need kubectl v1.11 or higher, configured to communicate with your cluster.
+{{< version-check >}}
+Your cluster API server version (eg v1.12) must be no more than one minor
+version away from the version of kubectl that you are using. For example,
+if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
+or v1.17; other combinations
+[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
+
+Some of the examples use the commandline tool
+[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task,
+because there are manual alternatives.
+
+For each node that you're reconfiguring, you must set the kubelet
+`--dynamic-config-dir` flag to a writable directory.
 {{% /capture %}}

 {{% capture steps %}}

-## Reconfiguring the Kubelet on a Live Node in your Cluster
+## Reconfiguring the kubelet on a running node in your cluster

-### Basic Workflow Overview
+### Basic workflow overview

-The basic workflow for configuring a Kubelet in a live cluster is as follows:
+The basic workflow for configuring a kubelet in a live cluster is as follows:

 1. Write a YAML or JSON configuration file containing the
-Kubelet's configuration.
+kubelet's configuration.
 2. Wrap this file in a ConfigMap and save it to the Kubernetes control plane.
-3. Update the Kubelet's corresponding Node object to use this ConfigMap.
+3. Update the kubelet's corresponding Node object to use this ConfigMap.

-Each Kubelet watches a configuration reference on its respective Node object.
-When this reference changes, the Kubelet downloads the new configuration,
+Each kubelet watches a configuration reference on its respective Node object.
+When this reference changes, the kubelet downloads the new configuration,
 updates a local reference to refer to the file, and exits.
 For the feature to work correctly, you must be running an OS-level service
-manager (such as systemd), which will restart the Kubelet if it exits. When the
-Kubelet is restarted, it will begin using the new configuration.
+manager (such as systemd), which will restart the kubelet if it exits. When the
+kubelet is restarted, it will begin using the new configuration.

 The new configuration completely overrides configuration provided by `--config`,
 and is overridden by command-line flags. Unspecified values in the new configuration
 will receive default values appropriate to the configuration version
 (e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags.

-The status of the Node's Kubelet configuration is reported via 
+The status of the Node's kubelet configuration is reported via 
 `Node.Spec.Status.Config`. Once you have updated a Node to use the new
 ConfigMap, you can observe this status to confirm that the Node is using the
 intended configuration. 
@@ -70,7 +84,7 @@ mind that it is also valid for multiple Nodes to consume the same ConfigMap.

 {{< warning >}}
 While it is *possible* to change the configuration by
-updating the ConfigMap in-place, this causes all Kubelets configured with
+updating the ConfigMap in-place, this causes all kubelets configured with
 that ConfigMap to update simultaneously. It is much safer to treat ConfigMaps
 as immutable by convention, aided by `kubectl`'s `--append-hash` option,
 and incrementally roll out updates to `Node.Spec.ConfigSource`.
@@ -91,23 +105,35 @@ and debug issues. The compromise, however, is that you must start with knowledge
 of the existing configuration to ensure that you only change the fields you
 intend to change.

-Ideally, the Kubelet would be bootstrapped from a file on disk
-and you could edit this file (which could also be version-controlled),
-to create the first Kubelet ConfigMap
-(see [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)),
-Currently, the Kubelet is bootstrapped with **a combination of this file and command-line flags**
-that can override the configuration in the file.
-As a workaround, you can generate a config file containing a Node's current
-configuration by accessing the Kubelet server's `configz` endpoint via the
-kubectl proxy. This endpoint, in its current implementation, is intended to be
-used only as a debugging aid. Do not rely on the behavior of this endpoint for
-production scenarios. The examples below use the `jq` command to streamline
-working with JSON. To follow the tasks as written, you need to have `jq`
-installed, but you can adapt the tasks if you prefer to extract the
-`kubeletconfig` subobject manually.
+The kubelet loads settings from its configuration file, but you can set command
+line flags to override the configuration in the file. This means that if you
+only know the contents of the configuration file, and you don't know the
+command line overrides, then you do not know the running configuration either.
+
+Because you need to know the running configuration in order to override it,
+you can fetch the running configuration from the kubelet. You can generate a
+config file containing a Node's current configuration by accessing the kubelet's
+`configz` endpoint, through `kubectl proxy`. The next section explains how to
+do this.
+
+{{< caution >}}
+The kubelet's `configz` endpoint is there to help with debugging, and is not
+a stable part of kubelet behavior.
+Do not rely on the behavior of this endpoint for production scenarios or for
+use with automated tools.
+{{< /caution >}}
+
+For more information on configuring the kubelet via a configuration file, see
+[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)).

 #### Generate the configuration file

+{{< note >}}
+The steps below use the `jq` command to streamline working with JSON.
+To follow the tasks as written, you need to have `jq` installed. You can
+adapt the steps if you prefer to extract the `kubeletconfig` subobject manually.
+{{< /note >}}
+
 1.  Choose a Node to reconfigure. In this example, the name of this Node is
    referred to as `NODE_NAME`.
 2.  Start the kubectl proxy in the background using the following command: 
@@ -122,20 +148,22 @@ installed, but you can adapt the tasks if you prefer to extract the
    For example: `${NODE_NAME}` will be rewritten as `$\{NODE_NAME\}` during the paste.
    You must remove the backslashes before running the command, or the command will fail.

+
      ```bash
      NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
      ```

 {{< note >}}
 You need to manually add the `kind` and `apiVersion` to the downloaded
-object, because they are not reported by the `configz` endpoint.
+object, because those fields are not reported by the `configz` endpoint.
 {{< /note >}}

 #### Edit the configuration file

 Using a text editor, change one of the parameters in the
 file generated by the previous procedure. For example, you
-might edit the QPS parameter `eventRecordQPS`.
+might edit the parameter `eventRecordQPS`, that controls
+rate limiting for event recording.

 #### Push the configuration file to the control plane

@@ -162,12 +190,12 @@ data:
    {...}
 ```

-The ConfigMap is created in the `kube-system` namespace because this
-ConfigMap configures a Kubelet, which is Kubernetes system component.
+You created that ConfigMap inside the `kube-system` namespace because the kubelet
+is a Kubernetes system component.

 The `--append-hash` option appends a short checksum of the ConfigMap contents
 to the name. This is convenient for an edit-then-push workflow, because it
-automatically, yet deterministically, generates new names for new ConfigMaps.
+automatically, yet deterministically, generates new names for new resources.
 The name that includes this generated hash is referred to as `CONFIG_MAP_NAME`
 in the following examples.

@@ -185,13 +213,13 @@ In your text editor, add the following YAML under `spec`:
 ```yaml
 configSource:
    configMap:
-        name: CONFIG_MAP_NAME
+        name: CONFIG_MAP_NAME # replace CONFIG_MAP_NAME with the name of the ConfigMap
        namespace: kube-system
        kubeletConfigKey: kubelet
 ```

 You must specify all three of `name`, `namespace`, and `kubeletConfigKey`.
-The `kubeletConfigKey` parameter shows the Kubelet which key of the ConfigMap
+The `kubeletConfigKey` parameter shows the kubelet which key of the ConfigMap
 contains its config.

 #### Observe that the Node begins using the new configuration
@@ -200,16 +228,16 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and
 `Node.Status.Config`. The config sources corresponding to the `active`,
 `assigned`, and `lastKnownGood` configurations are reported in the status.

- The `active` configuration is the version the Kubelet is currently running with.
- The `assigned` configuration is the latest version the Kubelet has resolved based on
+- The `active` configuration is the version the kubelet is currently running with.
+- The `assigned` configuration is the latest version the kubelet has resolved based on
  `Node.Spec.ConfigSource`.
 - The `lastKnownGood` configuration is the version the
-  Kubelet will fall back to if an invalid config is assigned in `Node.Spec.ConfigSource`.
+  kubelet will fall back to if an invalid config is assigned in `Node.Spec.ConfigSource`.

 The`lastKnownGood` configuration might not be present if it is set to its default value,
 the local config deployed with the node. The status will update `lastKnownGood` to
-match a valid `assigned` config after the Kubelet becomes comfortable with the config. 
-The details of how the Kubelet determines a config should become the `lastKnownGood` are 
+match a valid `assigned` config after the kubelet becomes comfortable with the config. 
+The details of how the kubelet determines a config should become the `lastKnownGood` are 
 not guaranteed by the API, but is currently implemented as a 10-minute grace period.

 You can use the following command (using `jq`) to filter down
@@ -254,16 +282,19 @@ The following is an example response:

 ```

-If an error occurs, the Kubelet reports it in the `Node.Status.Config.Error`
+(if you do not have `jq`, you can look at the whole response and find `Node.Status.Config`
+by eye).
+
+If an error occurs, the kubelet reports it in the `Node.Status.Config.Error`
 structure. Possible errors are listed in
 [Understanding Node.Status.Config.Error messages](#understanding-node-status-config-error-messages).
-You can search for the identical text in the Kubelet log for additional details
+You can search for the identical text in the kubelet log for additional details
 and context about the error.

 #### Make more changes

 Follow the workflow above to make more changes and push them again. Each time
-you push a ConfigMap with new contents, the --append-hash kubectl option creates
+you push a ConfigMap with new contents, the `--append-hash` kubectl option creates
 the ConfigMap with a new name. The safest rollout strategy is to first create a
 new ConfigMap, and then update the Node to use the new ConfigMap.

@@ -283,7 +314,7 @@ error is reported.
 {{% /capture %}}

 {{% capture discussion %}}
-## Kubectl Patch Example
+## `kubectl patch` example

 You can change a Node's configSource using several different mechanisms.
 This example uses `kubectl patch`:
@@ -292,25 +323,25 @@ This example uses `kubectl patch`:
 kubectl patch node ${NODE_NAME} -p "{\"spec\":{\"configSource\":{\"configMap\":{\"name\":\"${CONFIG_MAP_NAME}\",\"namespace\":\"kube-system\",\"kubeletConfigKey\":\"kubelet\"}}}}"
 ```

-## Understanding how the Kubelet checkpoints config
+## Understanding how the kubelet checkpoints config

-When a new config is assigned to the Node, the Kubelet downloads and unpacks the
-config payload as a set of files on the local disk. The Kubelet also records metadata
+When a new config is assigned to the Node, the kubelet downloads and unpacks the
+config payload as a set of files on the local disk. The kubelet also records metadata
 that locally tracks the assigned and last-known-good config sources, so that the
-Kubelet knows which config to use across restarts, even if the API server becomes 
-unavailable. After checkpointing a config and the relevant metadata, the Kubelet 
-exits if it detects that the assigned config has changed. When the Kubelet is
+kubelet knows which config to use across restarts, even if the API server becomes
+unavailable. After checkpointing a config and the relevant metadata, the kubelet
+exits if it detects that the assigned config has changed. When the kubelet is
 restarted by the OS-level service manager (such as `systemd`), it reads the new
 metadata and uses the new config.

 The recorded metadata is fully resolved, meaning that it contains all necessary
 information to choose a specific config version - typically a `UID` and `ResourceVersion`.
 This is in contrast to `Node.Spec.ConfigSource`, where the intended config is declared
-via the idempotent `namespace/name` that identifies the target ConfigMap; the Kubelet 
+via the idempotent `namespace/name` that identifies the target ConfigMap; the kubelet
 tries to use the latest version of this ConfigMap.

-When you are debugging problems on a node, you can inspect the Kubelet's config
-metadata and checkpoints. The structure of the Kubelet's checkpointing directory is:
+When you are debugging problems on a node, you can inspect the kubelet's config
+metadata and checkpoints. The structure of the kubelet's checkpointing directory is:

 ```none
 - --dynamic-config-dir (root for managing dynamic config)
@@ -334,13 +365,18 @@ in the Kubelet log for additional details and context about the error.

 Error Message | Possible Causes
 :-------------| :--------------
-failed to load config, see Kubelet log for details | The Kubelet likely could not parse the downloaded config payload, or encountered a filesystem error attempting to load the payload from disk.
-failed to validate config, see Kubelet log for details | The configuration in the payload, combined with any command-line flag overrides, and the sum of feature gates from flags, the config file, and the remote payload, was determined to be invalid by the Kubelet.
-invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil | Since Node.Spec.ConfigSource is validated by the API server to contain at least one non-nil subfield, this likely means that the Kubelet is older than the API server and does not recognize a newer source type.
-failed to sync: failed to download config, see Kubelet log for details | The Kubelet could not download the config. It is possible that Node.Spec.ConfigSource could not be resolved to a concrete API object, or that network errors disrupted the download attempt. The Kubelet will retry the download when in this error state.
-failed to sync: internal failure, see Kubelet log for details | The Kubelet encountered some internal problem and failed to update its config as a result. Examples include filesystem errors and reading objects from the internal informer cache.
-internal failure, see Kubelet log for details | The Kubelet encountered some internal problem while manipulating config, outside of the configuration sync loop. 
+failed to load config, see Kubelet log for details | The kubelet likely could not parse the downloaded config payload, or encountered a filesystem error attempting to load the payload from disk.
+failed to validate config, see Kubelet log for details | The configuration in the payload, combined with any command-line flag overrides, and the sum of feature gates from flags, the config file, and the remote payload, was determined to be invalid by the kubelet.
+invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil | Since Node.Spec.ConfigSource is validated by the API server to contain at least one non-nil subfield, this likely means that the kubelet is older than the API server and does not recognize a newer source type.
+failed to sync: failed to download config, see Kubelet log for details | The kubelet could not download the config. It is possible that Node.Spec.ConfigSource could not be resolved to a concrete API object, or that network errors disrupted the download attempt. The kubelet will retry the download when in this error state.
+failed to sync: internal failure, see Kubelet log for details | The kubelet encountered some internal problem and failed to update its config as a result. Examples include filesystem errors and reading objects from the internal informer cache.
+internal failure, see Kubelet log for details | The kubelet encountered some internal problem while manipulating config, outside of the configuration sync loop.

-{{< /table >}} 
+{{< /table >}}

 {{% /capture %}}
+{{% capture whatsnext %}}
+ - For more information on configuring the kubelet via a configuration file, see
+[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
+- See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
+{{% /capture %}}
@@ -77,7 +77,7 @@ Cloud controller manager does not implement any of the volume controllers found

 ### Scalability

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

 ### Chicken and Egg

@@ -26,7 +26,7 @@ You can use either `kubectl create configmap` or a ConfigMap generator in `kusto

 ### Create a ConfigMap Using kubectl create configmap

-Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):
+Use the `kubectl create configmap` command to create ConfigMaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):

 ```shell
 kubectl create configmap <map-name> <data-source>
@@ -34,10 +34,7 @@ kubectl create configmap <map-name> <data-source>

 where \<map-name> is the name you want to assign to the ConfigMap and \<data-source> is the directory, file, or literal value to draw the data from.

-The data source corresponds to a key-value pair in the ConfigMap, where
-
-* key = the file name or the key you provided on the command line, and
-* value = the file contents or the literal value you provided on the command line.
+When you are creating a ConfigMap based on a file, the key in the \<data-source> defaults to the basename of the file, and the value defaults to the file content.

 You can use [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) or
 [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to retrieve information
@@ -45,7 +42,7 @@ about a ConfigMap.

 #### Create ConfigMaps from directories

-You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory.
+You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory. When you are creating a ConfigMap based on a directory, kubectl identifies files whose basename is a valid key in the directory and packages each of those files into the new ConfigMap. Any directory entries except regular files are ignored (e.g. subdirectories, symlinks, devices, pipes, etc).

 For example:

@@ -61,30 +58,36 @@ wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-con
 kubectl create configmap game-config --from-file=configure-pod-container/configmap/
 ```

-combines the contents of the `configure-pod-container/configmap/` directory
-
-```shell
-game.properties
-ui.properties
-```
-
-into the following ConfigMap:
+The above command packages each file, in this case, `game.properties` and `ui.properties` in the `configure-pod-container/configmap/` directory into the game-config ConfigMap. You can display details of the ConfigMap using the following command:

 ```shell
 kubectl describe configmaps game-config
 ```

-where the output is similar to this:
+The output is similar to this:
 ```
-Name:           game-config
-Namespace:      default
-Labels:         <none>
-Annotations:    <none>
+Name:         game-config
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>

 Data
 ====
-game.properties:        158 bytes
-ui.properties:          83 bytes
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+ui.properties:
+----
+color.good=purple
+color.bad=yellow
+allow.textmode=true
+how.nice.to.look=fairlyNice
 ```

 The `game.properties` and `ui.properties` files in the `configure-pod-container/configmap/` directory are represented in the `data` section of the ConfigMap.
@@ -138,14 +141,22 @@ kubectl describe configmaps game-config-2
 where the output is similar to this:

 ```
-Name:           game-config-2
-Namespace:      default
-Labels:         <none>
-Annotations:    <none>
+Name:         game-config-2
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>

 Data
 ====
-game.properties:        158 bytes
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
 ```

 You can pass in the `--from-file` argument multiple times to create a ConfigMap from multiple data sources.
@@ -154,7 +165,7 @@ You can pass in the `--from-file` argument multiple times to create a ConfigMap
 kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties
 ```

-Describe the above `game-config-2` configmap created
+You can display details of the `game-config-2` ConfigMap using the following command:

 ```shell
 kubectl describe configmaps game-config-2
@@ -163,15 +174,28 @@ kubectl describe configmaps game-config-2
 The output is similar to this:

 ```
-Name:           game-config-2
-Namespace:      default
-Labels:         <none>
-Annotations:    <none>
+Name:         game-config-2
+Namespace:    default
+Labels:       <none>
+Annotations:  <none>

 Data
 ====
-game.properties:        158 bytes
-ui.properties:          83 bytes
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+ui.properties:
+----
+color.good=purple
+color.bad=yellow
+allow.textmode=true
+how.nice.to.look=fairlyNice
 ```

 Use the option `--from-env-file` to create a ConfigMap from an env-file, for example:
@@ -227,11 +251,11 @@ data:
 When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used.
 {{< /caution >}}

-The behavior of passing `--from-env-file` multiple times is demonstrated by: 
+The behavior of passing `--from-env-file` multiple times is demonstrated by:

 ```shell
 # Download the sample files into `configure-pod-container/configmap/` directory
-wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
+wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties

 # Create the configmap
 kubectl create configmap config-multi-env-files \
@@ -656,4 +680,3 @@ data:
 * Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).

 {{% /capture %}}
-
@@ -123,6 +123,8 @@ As an example, to look at the logs from a running Cassandra pod, you might run:
 kubectl exec cassandra -- cat /var/log/cassandra/system.log
 ```

+If your cluster enabled it, you can also try adding an [ephemeral container](/docs/concepts/workloads/pods/ephemeral-containers/) into the existing pod. You can use the new temporary container to run arbitrary commands, for example, to diagnose problems inside the Pod. See the page about [ephemeral container](/docs/concepts/workloads/pods/ephemeral-containers/) for more details, including feature availability.
+
 If none of these approaches work, you can find the host machine that the pod is
 running on and SSH into that host.

@@ -2,6 +2,7 @@
 title: Distribute Credentials Securely Using Secrets
 content_template: templates/task
 weight: 50
+min-kubernetes-server-version: v1.6
 ---

 {{% capture overview %}}
@@ -11,7 +12,7 @@ encryption keys, into Pods.

 {{% capture prerequisites %}}

-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}

 {{% /capture %}}

@@ -52,7 +52,7 @@ cronjob.batch/hello created
 Alternatively, you can use `kubectl run` to create a cron job without writing a full config:

 ```shell
-kubectl run --generator=run-pod/v1 hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
+kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
 ```

 After creating the cron job, get its status using this command:
@@ -83,7 +83,14 @@ kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
 ```

 {{< note >}}
-`diff` uses [server-side dry-run](/docs/reference/using-api/api-concepts/#dry-run), which needs to be enabled on `kube-apiserver`.
+`diff` uses [server-side dry-run](/docs/reference/using-api/api-concepts/#dry-run),
+which needs to be enabled on `kube-apiserver`.
+
+Since `diff` performs a server-side apply request in dry-run mode,
+it requires granting `PATCH`, `CREATE`, and `UPDATE` permissions.
+See [Dry-Run Authorization](/docs/reference/using-api/api-concepts#dry-run-authorization)
+for details.
+
 {{< /note >}}

 Create the object using `kubectl apply`:
@@ -985,11 +992,11 @@ used only by the controller selector with no other semantic meaning.
 ```yaml
 selector:
  matchLabels:
-      controller-selector: "extensions/v1beta1/deployment/nginx"
+      controller-selector: "apps/v1/deployment/nginx"
 template:
  metadata:
    labels:
-      controller-selector: "extensions/v1beta1/deployment/nginx"
+      controller-selector: "apps/v1/deployment/nginx"
 ```

 {{% capture whatsnext %}}
@@ -135,11 +135,11 @@ Example label:
 ```yaml
 selector:
  matchLabels:
-      controller-selector: "extensions/v1beta1/deployment/nginx"
+      controller-selector: "apps/v1/deployment/nginx"
 template:
  metadata:
    labels:
-      controller-selector: "extensions/v1beta1/deployment/nginx"
+      controller-selector: "apps/v1/deployment/nginx"
 ```

 {{% /capture %}}
@@ -14,7 +14,7 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
 {{% capture prerequisites %}}

 * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
-* Kubenet network plugin
+* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico)
 * Kube-proxy running in mode IPVS
 * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster

@@ -39,7 +39,7 @@ a00:100::/24
 ```
 There should be one IPv4 block and one IPv6 block allocated.

-Validate that the node has an IPv4 and IPv6 interface detected (replace node name with a valid node from the cluster. In this example the node name is k8s-linuxpool1-34450317-0): 
+Validate that the node has an IPv4 and IPv6 interface detected (replace node name with a valid node from the cluster. In this example the node name is k8s-linuxpool1-34450317-0):
 ```shell
 kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s \n" .type .address}}{{end}}'
 ```
@@ -151,7 +151,7 @@ If the cloud provider supports the provisioning of IPv6 enabled external load ba

 {{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}

-Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port. 
+Validate that the Service receives a `CLUSTER-IP` address from the IPv6 address block along with an `EXTERNAL-IP`. You may then validate access to the service via the IP and port.
 ```
 kubectl get svc -l app=MyApp
 NAME         TYPE        CLUSTER-IP       EXTERNAL-IP                     PORT(S)        AGE
@@ -159,4 +159,3 @@ my-service   ClusterIP   fe80:20d::d06b   2001:db8:f100:4002::9d37:c0d7   80:318
 ```

 {{% /capture %}}
-
@@ -62,14 +62,19 @@ It defines an index.php page which performs some CPU intensive computations:
 ?>
 ```

-First, we will start a deployment running the image and expose it as a service:
+First, we will start a deployment running the image and expose it as a service
+using the following configuration:

+{{< codenew file="application/php-apache.yaml" >}}
+
+
+Run the following command:
 ```shell
-kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80
+kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
 ```
 ```
-service/php-apache created
 deployment.apps/php-apache created
+service/php-apache created
 ```

 ## Create Horizontal Pod Autoscaler
@@ -3,7 +3,6 @@ reviewers:
 - fgrzadkowski
 - jszczepkowski
 - directxman12
- josephburnett
 title: Horizontal Pod Autoscaler
 feature:
  title: Horizontal scaling
@@ -163,15 +162,11 @@ can be fetched, scaling is skipped. This means that the HPA is still capable
 of scaling up if one or more metrics give a `desiredReplicas` greater than
 the current value.

-Finally, just before HPA scales the target, the scale recommendation is
-recorded.  The controller considers all recommendations within a configurable
-window choosing the highest recommendation from within that window. This value
-can be configured using the
-`--horizontal-pod-autoscaler-downscale-stabilization` flag or the HPA object
-behavior `behavior.scaleDown.stabilizationWindowSeconds` (see [Support for
-configurable scaling behavior](#support-for-configurable-scaling-behavior)),
-which defaults to 5 minutes.  This means that scaledowns will occur gradually,
-smoothing out the impact of rapidly fluctuating metric values.
+Finally, just before HPA scales the target, the scale recommendation is recorded.  The
+controller considers all recommendations within a configurable window choosing the
+highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
+This means that scaledowns will occur gradually, smoothing out the impact of rapidly
+fluctuating metric values.

 ## API Object

@@ -218,7 +213,10 @@ When managing the scale of a group of replicas using the Horizontal Pod Autoscal
 it is possible that the number of replicas keeps fluctuating frequently due to the
 dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*.

-Starting from v1.12, a new algorithmic update removes the need for an
+Starting from v1.6, a cluster operator can mitigate this problem by tuning
+the global HPA settings exposed as flags for the `kube-controller-manager` component:
+
+Starting from v1.12, a new algorithmic update removes the need for the
 upscale delay.

 - `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a
@@ -234,11 +232,6 @@ the delay value is set too short, the scale of the replicas set may keep thrashi
 usual.
 {{< /note >}}

-Starting from v1.17 the downscale stabilization window can be set on a per-HPA
-basis by setting the `behavior.scaleDown.stabilizationWindowSeconds` field in
-the v2beta2 API. See [Support for configurable scaling
-behavior](#support-for-configurable-scaling-behavior).
-
 ## Support for multiple metrics

 Kubernetes 1.6 adds support for scaling based on multiple metrics. You can use the `autoscaling/v2beta2` API
@@ -84,7 +84,7 @@ weight: 10

        <div class="row">
            <div class="col-md-8">
-                <p>When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. <b>The nodes communicate with the master using the Kubernetes API</b>, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.</p>
+                <p>When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. <b>The nodes communicate with the master using the <a href="/docs/concepts/overview/kubernetes-api/">Kubernetes API</a></b>, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.</p>

                <p>A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use Minikube.  Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, macOS, and Windows systems. The Minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this tutorial, however, you'll use a provided online terminal with Minikube pre-installed.</p>

@@ -31,7 +31,7 @@ weight: 10
            <p>Users expect applications to be available all the time and developers are expected to deploy new versions of them several times a day. In Kubernetes this is done with rolling updates. <b>Rolling updates</b> allow Deployments' update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.</p>

            <p>In the previous module we scaled our application to run multiple instances. This is a requirement for performing updates without affecting application availability. By default, the maximum number of Pods that can be unavailable during the update and the maximum number of new Pods that can be created, is one. Both options can be configured to either numbers or percentages (of Pods).
-            In Kubernetes, updates are versioned and any Deployment update can be reverted to previous (stable) version.</p>
+            In Kubernetes, updates are versioned and any Deployment update can be reverted to a previous (stable) version.</p>

            </div>
            <div class="col-md-4">
@@ -34,7 +34,7 @@ document. The examples use a small nginx webserver that echoes back the source
 IP of requests it receives through an HTTP header. You can create it as follows:

 ```console
-kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
+kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4
 ```
 The output is:
 ```
@@ -80,8 +80,17 @@ The preceding command creates a
        NAME         TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)    AGE
        my-service   LoadBalancer   10.3.245.137   104.198.205.71   8080/TCP   54s

-    Note: If the external IP address is shown as \<pending\>, wait for a minute
-    and enter the same command again.
+    {{< note >}}
+
+    The `type=LoadBalancer` service is backed by external cloud providers, which is not covered in this example, please refer to [this page](/docs/concepts/services-networking/service/#loadbalancer) for the details.
+
+    {{< /note >}}
+
+    {{< note >}}
+
+    If the external IP address is shown as \<pending\>, wait for a minute and enter the same command again.
+
+    {{< /note >}}

 1. Display detailed information about the Service:

@@ -1,120 +0,0 @@
---
-reviewers:
- chenopis
-layout: docsportal
-css: /css/style_user_journeys.css
-js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
-title: Advanced Topics
-track: "USERS › APPLICATION DEVELOPER › ADVANCED"
-content_template: templates/user-journey-content
---
-
-{{% capture overview %}}
-
-{{< note  >}}
-This page assumes that you're familiar with core Kubernetes concepts, and are comfortable deploying your own apps. If not, you should review the {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} topics first.
-{{< /note  >}}
-After checking out the current page and its linked sections, you should have a better understanding of the following:
-* Advanced features that you can leverage in your application
-* The various ways of extending the Kubernetes API
-
-{{% /capture %}}
-
-
-{{% capture body %}}
-
-## Deploy an application with advanced features
-
-Now you know the set of API objects that Kubernetes provides. Understanding the difference between a {{< glossary_tooltip term_id="daemonset" >}} and a {{< glossary_tooltip term_id="deployment" >}} is oftentimes sufficient for app deployment. That being said, it's also worth familiarizing yourself with Kubernetes's lesser known features. They can be quite powerful when applied to the right use cases.
-
-#### Container-level features
-
-As you may know, it's an antipattern to migrate an entire app (e.g. containerized Rails app, MySQL database, and all) into a single Pod. That being said, there are some very useful patterns that go beyond a 1:1 correspondence between a container and its Pod:
-
-* **Sidecar container**: Although your Pod should still have a single main container, you can add a secondary container that acts as a helper (see a {{< link text="logging example" url="/docs/concepts/cluster-administration/logging/#sidecar-container-with-a-logging-agent" >}}). Two containers within a single Pod can communicate {{< link text="via a shared volume" url="/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/" >}}.
-* **Init containers**: *Init containers* run before any of a Pod's *app containers* (such as main and sidecar containers). {{< link text="Read more" url="/docs/concepts/workloads/pods/init-containers/" >}}, see an {{< link text="nginx server example" url="/docs/tasks/configure-pod-container/configure-pod-initialization/" >}}, and {{< link text="learn how to debug these containers" url="/docs/tasks/debug-application-cluster/debug-init-containers/" >}}.
-
-#### Pod configuration
-
-Usually, you use {{< glossary_tooltip text="labels" term_id="label" >}} and {{< glossary_tooltip text="annotations" term_id="annotation" >}} to attach metadata to your resources. To inject data into your resources, you'd likely create {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} (for nonconfidential data) or {{< glossary_tooltip text="Secrets" term_id="secret" >}} (for confidential data).
-
-Below are some other, lesser-known ways of configuring your resources' Pods:
-
-* **Taints and Tolerations** - These provide a way for nodes to "attract" or "repel" your Pods. They are often used when an application needs to be deployed onto specific hardware, such as GPUs for scientific computing. {{< link text="Read more" url="/docs/concepts/configuration/taint-and-toleration/" >}}.
-* **Downward API** - This allows your containers to consume information about themselves or the cluster, without being overly coupled to the Kubernetes API server. This can be achieved with {{< link text="environment variables" url="/docs/tasks/inject-data-application/environment-variable-expose-pod-information/" >}} or {{< link text="DownwardAPIVolumeFiles" url="/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/" >}}.
-* **Pod Presets** - Normally, to mount runtime requirements (such as environmental variables, ConfigMaps, and Secrets) into a resource, you specify them in the resource's configuration file. {{< link text="PodPresets" url="/docs/concepts/workloads/pods/podpreset/" >}} allow you to dynamically inject these requirements instead, when the resource is created. For instance, this allows team A to mount any number of new Secrets into the resources created by teams B and C, without requiring action from B and C. {{< link text="See an example" url="/docs/tasks/inject-data-application/podpreset/" >}}.
-
-#### Additional API Objects
-
-{{< note  >}}
-Before setting up the following resources, check to see if they are the responsibility of your organization's {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}}.
-{{< /note  >}}
-* **{{< glossary_tooltip text="Horizontal Pod Autoscaler (HPA)" term_id="horizontal-pod-autoscaler" >}}** - These resources are a great way to automate the process of scaling your application when CPU usage or other {{< link text="custom metrics" url="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md" >}} spike. {{< link text="See an example" url="/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/" >}} to understand how HPAs are set up.
-
-* **Federated cluster objects** - If you are running an application on multiple Kubernetes clusters using *federation*, you need to deploy the federated version of the standard Kubernetes API objects. For reference, check out the guides for setting up {{< link text="Federated ConfigMaps" url="/docs/tasks/administer-federation/configmap/" >}} and {{< link text="Federated Deployments" url="/docs/tasks/administer-federation/deployment/" >}}.
-
-## Extend the Kubernetes API
-
-Kubernetes is designed with extensibility in mind. If the API resources and features mentioned above are not enough for your needs, there are ways to customize its behavior without having to modify core Kubernetes code.
-
-#### Understand Kubernetes's default behavior
-
-Before making any customizations, it's important that you understand the general abstraction behind Kubernetes API objects. Although Deployments and Secrets may seem quite different, the following concepts are true for *any* object:
-
-* **Kubernetes objects are a way of storing structured data about your cluster.**
-  In the case of Deployments, this data represents desired state (such as "How many replicas should be running?"), but it can also be general metadata (such as database credentials).
-* **Kubernetes objects are modified via the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}**.
-  In other words, you can make `GET` and `POST` requests to a specific resource path (such as `<api-server-url>/api/v1/namespaces/default/deployments`) to read and write the corresponding object type.
-* **By leveraging the {{< link text="Controller pattern" url="/docs/concepts/api-extension/custom-resources/#custom-controllers" >}}, Kubernetes objects can be used to enforce desired state**. For simplicity, you can think of the Controller pattern as the following continuous loop:
-
-  <div class="emphasize-box" markdown="1">
-  1. Check current state (number of replicas, container image, etc)
-  2. Compare current state to desired state
-  3. Update if there's a mismatch
-  </div>
-
-  These states are obtained from the Kubernetes API.
-
-  {{< note  >}}
-  Not all Kubernetes objects need to have a Controller. Though Deployments trigger the cluster to make state changes, ConfigMaps act purely as storage.
-  {{< /note  >}}
-#### Create Custom Resources
-
-Based on the ideas above, you can define a new {{< link text="Custom Resource" url="/docs/concepts/api-extension/custom-resources/#custom-resources" >}} that is just as legitimate as a Deployment. For example, you might want to define a `Backup` object for periodic backups, if `CronJobs` don't provide all the functionality you need.
-
-There are two main ways of setting up custom resources:
-1. **Custom Resource Definitions (CRDs)** - This method requires the least amount of implementation work. See {{< link text="an example" url="/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/" >}}.
-2. **API aggregation** - This method requires some {{< link text="pre-configuration" url="/docs/tasks/access-kubernetes-api/configure-aggregation-layer/" >}} before you actually {{< link text="set up a separate, extension API server" url="/docs/tasks/access-kubernetes-api/setup-extension-api-server/" >}}.
-
-Note that unlike standard Kubernetes objects, which rely on the built-in {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}}, you'll need to write and run your own {{< link text="custom controllers" url="https://github.com/kubernetes/sample-controller" >}}.
-
-You may also find the following info helpful:
-* {{< link text="How to know if custom resources are right for your use case" url="/docs/concepts/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource" >}}
-* {{< link text="How to decide between CRDs and API aggregation" url="/docs/concepts/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources" >}}
-
-#### Service Catalog
-
-If you want to consume or provide complete services (rather than individual resources), **{{< glossary_tooltip text="Service Catalog" term_id="service-catalog" >}}** provides a {{< link text="specification" url="https://github.com/openservicebrokerapi/servicebroker" >}} for doing so. These services are registered using {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} (see {{< link text="some examples" url="https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#example-service-brokers" >}}).
-
-If you do not have a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} to manage the installation of Service Catalog, you can do so using {{< link text="Helm" url="/docs/tasks/service-catalog/install-service-catalog-using-helm/" >}} or an {{< link text="installer binary" url="/docs/tasks/service-catalog/install-service-catalog-using-sc/" >}}.
-
-
-## Explore additional resources
-
-#### References
-
-The following topics are also useful for building more complex applications:
-
-* {{< link text="Other points of extensibility within Kubernetes" url="/docs/concepts/overview/extending/" >}} -  A conceptual overview of where you can hook into the Kubernetes architecture.
-* {{< link text="Kubernetes Client Libraries" url="/docs/reference/using-api/client-libraries/" >}} - Useful for building apps that need to interact heavily with the Kubernetes API.
-
-#### What's next
-Congrats on completing the Application Developer user journey! You've covered the majority of features that Kubernetes has to offer. What now?
-
-* If you'd like to suggest new features or keep up with the latest developments around Kubernetes app development, consider joining a {{< glossary_tooltip term_id="sig" >}} such as {{< link text="SIG Apps" url="https://github.com/kubernetes/community/tree/master/sig-apps" >}}.
-
-* If you are interested in learning more about the inner workings of Kubernetes (e.g. networking), consider checking out the {{< link text="Cluster Operator journey" url="/docs/user-journeys/users/cluster-operator/foundational/" >}}.
-
-{{% /capture %}}
-
-
@@ -1,260 +0,0 @@
---
-reviewers:
- chenopis
-layout: docsportal
-css: /css/style_user_journeys.css
-js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
-title: Foundational
-track: "USERS › APPLICATION DEVELOPER › FOUNDATIONAL"
-content_template: templates/user-journey-content
---
-
-{{% capture overview %}}
-If you're a developer looking to run applications on Kubernetes, this page and its linked topics can help you get started with the fundamentals. Though this page primarily describes development workflows, {{< link text="the subsequent page in the series" url="/docs/home/?path=users&persona=app-developer&level=intermediate" >}} covers more advanced, production setups.
-
-{{< note  >}}
-**A quick note**<br>This app developer "user journey" is *not* a comprehensive overview of Kubernetes. It focuses more on *what* you develop, test, and deploy to Kubernetes, rather than *how* the underlying infrastructure works.<br><br>Though it's possible for a single person to manage both, in many organizations, it’s common to assign the latter to a dedicated {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}}.
-{{< /note  >}}
-{{% /capture %}}
-
-
-{{% capture body %}}
-## Get started with a cluster
-
-#### Web-based environment
-
-If you're brand new to Kubernetes and simply want to experiment without setting up a full development environment, *web-based environments* are a good place to start:
-
-* {{< link text="Kubernetes Basics" url="/docs/tutorials/kubernetes-basics/#basics-modules" >}} - Introduces you to six common Kubernetes workflows. Each section walks you through browser-based, interactive exercises complete with their own Kubernetes environment.
-
-* {{< link text="Katacoda" url="https://www.katacoda.com/courses/kubernetes/playground" >}} - The playground equivalent of the environment used in *Kubernetes Basics* above. Katacoda also provides {{< link text="more advanced tutorials" url="https://www.katacoda.com/courses/kubernetes/" >}}, such as "Liveness and Readiness Healthchecks".
-
-
-* {{< link text="Play with Kubernetes" url="http://labs.play-with-k8s.com/" >}} - A less structured environment than the *Katacoda* playground, for those who are more comfortable with Kubernetes concepts and want to explore further. It supports the ability to spin up multiple nodes.
-
-
-#### Minikube (recommended)
-
-Web-based environments are easy to access, but are not persistent. If you want to continue exploring Kubernetes in a workspace that you can come back to and change, *Minikube* is a good option.
-
-Minikube can be installed locally, and runs a simple, single-node Kubernetes cluster inside a virtual machine (VM). This cluster is fully functioning and contains all core Kubernetes components. Many developers have found this sufficient for local application development.
-
-* {{< link text="Install Minikube" url="/docs/tasks/tools/install-minikube/" >}}.
-
-* {{< link text="Install kubectl" url="/docs/tasks/tools/install-kubectl/" >}}. ({{< glossary_tooltip text="What is kubectl?" term_id="kubectl" >}})
-
-* *(Optional)* {{< link text="Install Docker" url="/docs/setup/production-environment/container-runtimes/#docker" >}} if you plan to run your Minikube cluster as part of a local development environment.
-
-   Minikube includes a Docker daemon, but if you're developing applications locally, you'll want an independent Docker instance to support your workflow. This allows you to create {{< glossary_tooltip text="containers" term_id="container" >}} and push them to a container registry.
-
-   {{< note  >}}
-   Version 1.12 is recommended for full compatibility with Kubernetes, but a few other versions are tested and known to work.
-   {{< /note  >}}
-
-You can get basic information about your cluster with the commands `kubectl cluster-info` and `kubectl get nodes`. However, to get a good idea of what's really going on, you need to deploy an application to your cluster. This is covered in the next section.
-
-#### MicroK8s
-
-On Linux, *MicroK8s* is a good alternative to Minikube for a local
-install of Kubernetes:
-
-* Runs on the native OS, so there is no overhead from running a virtual machine.
-* Always provides the latest stable version of Kubernetes, using built-in auto-upgrade functionality.
-* Installs in less than a minute.
-
-* {{< link text="Install microk8s" url="https://microk8s.io/" >}}.
-
-After you install MicroK8s, you can use its tab-completion
-functionality. All MicroK8s commands start with `microk8s.`. Type
-`microk8s.` (with the period) and then use the tab key to see a list
-of available commands.
-
-It also includes commands to enable Kubernetes subsystems. For example:
-
-* the Kubernetes Dashboard
-* the DNS service
-* GPU passthrough (for NVIDIA)
-* Ingress
-* Istio
-* Metrics server
-* Registry
-* Storage
-
-## Deploy an application
-
-#### Basic workloads
-
-The following examples demonstrate the fundamentals of deploying Kubernetes apps:
-
-  * **Stateless apps**: {{< link text="Deploy a simple nginx server" url="/docs/tasks/run-application/run-stateless-application-deployment/" >}}.
-
-  * **Stateful apps**: {{< link text="Deploy a MySQL database" url="/docs/tasks/run-application/run-single-instance-stateful-application/" >}}.
-
-Through these deployment tasks, you'll gain familiarity with the following:
-
-* General concepts
-
-  * **Configuration files** - Written in YAML or JSON, these files describe the desired state of your application in terms of Kubernetes API objects. A file can include one or more API object descriptions (*manifests*). (See [the example YAML](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment) from the stateless app).
-
-  * **{{< glossary_tooltip text="Pods" term_id="pod" >}}** - This is the basic unit for all of the workloads you run on Kubernetes. These workloads, such as *Deployments* and *Jobs*, are composed of one or more Pods. To learn more, check out {{< link text="this explanation of Pods and Nodes" url="/docs/tutorials/kubernetes-basics/explore-intro/" >}}.
-
-* Common workload objects
-  * **{{< glossary_tooltip text="Deployment" term_id="deployment" >}}** - The most common way of running *X* copies (Pods) of your application. Supports rolling updates to your container images.
-
-  * **{{< glossary_tooltip text="Service" term_id="service" >}}** - By itself, a Deployment can't receive traffic. Setting up a Service is one of the simplest ways to configure a Deployment to receive and loadbalance requests. Depending on the `type` of Service used, these requests can come from external client apps or be limited to apps within the same cluster. A Service is tied to a specific Deployment using {{< glossary_tooltip text="label" term_id="label" >}} selection.
-
-The subsequent topics are also useful to know for basic application deployment.
-
-#### Metadata
-
-You can also specify custom information about your Kubernetes API objects by attaching key/value fields. Kubernetes provides two ways of doing this:
-
-* **{{< glossary_tooltip text="Labels" term_id="label" >}}** - Identifying metadata that you can use to sort and select sets of API objects. Labels have many applications, including the following:
-
-  * *To keep the right number of replicas (Pods) running in a Deployment.* The specified label (`app: nginx` in the {{< link text="stateless app example" url="/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment" >}}) is used to stamp the Deployment's newly created Pods (as the value of the `spec.template.labels` configuration field), and to query which Pods it already manages (as the value of `spec.selector.matchLabels`).
-
-  * *To tie a Service to a Deployment* using the `selector` field, which is demonstrated in the {{< link text="stateful app example" url="/docs/tasks/run-application/run-single-instance-stateful-application/#deploy-mysql" >}}.
-
-  * *To look for specific subset of Kubernetes objects, when you are using {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}.* For instance, the command `kubectl get deployments --selector=app=nginx` only displays Deployments from the nginx app.
-
-* **{{< glossary_tooltip text="Annotations" term_id="annotation" >}}** - Nonidentifying metadata that you can attach to API objects, usually if you don't intend to use them for sorting purposes. These often serve as supplementary data about an app's deployment, such as Git SHAs, PR numbers, or URL pointers to observability dashboards.
-
-
-#### Storage
-
-You'll also want to think about storage. Kubernetes provides different types of storage API objects for different storage needs:
-
-* **{{< glossary_tooltip text="Volumes" term_id="volume" >}}** -  Let you define storage for your cluster that is tied to the lifecycle of a Pod. It is therefore more persistent than container storage. Learn {{< link text="how to configure volume storage" url="/docs/tasks/configure-pod-container/configure-volume-storage/" >}}, or {{< link text="read more about volume storage" url="/docs/concepts/storage/volumes/" >}}.
-
-* **{{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}** and **{{< glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" >}}** - Let you define storage at the cluster level. Typically a cluster operator defines the PersistentVolume objects for the cluster, and cluster users (application developers, you) define the PersistentVolumeClaim objects that your application requires. Learn {{< link text="how to set up persistent storage for your cluster" url="/docs/tasks/configure-pod-container/configure-persistent-volume-storage/" >}} or {{< link text="read more about persistent volumes" url="/docs/concepts/storage/persistent-volumes/" >}}.
-
-#### Configuration
-
-To avoid having to unnecessarily rebuild your container images, you should decouple your application's *configuration data* from the code required to run it. There are a couple ways of doing this, which you should choose according to your use case:
-
-<!-- Using HTML tables because the glossary_tooltip isn't compatible with the Markdown approach -->
-<table>
-  <thead>
-    <tr>
-      <th>Approach</th>
-      <th>Type of Data</th>
-      <th>How it's mounted</th>
-      <th>Example</th>
-    </tr>
-  </thead>
-  <tr>
-    <td><a href="/docs/tasks/inject-data-application/define-environment-variable-container/">Using a manifest's container definition</a></td>
-    <td>Non-confidential</td>
-    <td>Environment variable</td>
-    <td>Command-line flag</td>
-  </tr>
-  <tr>
-    <td>Using <b>{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}</b></td>
-    <td>Non-confidential</td>
-    <td>Environment variable OR local file</td>
-    <td>nginx configuration</td>
-  </tr>
-  <tr>
-    <td>Using <b>{{< glossary_tooltip text="Secrets" term_id="secret" >}}</b></td>
-    <td>Confidential</td>
-    <td>Environment variable OR local file</td>
-    <td>Database credentials</td>
-  </tr>
-</table>
-
-{{< note  >}}
-If you have any data that you want to keep private, you should be using a Secret. Otherwise there is nothing stopping that data from being exposed to malicious users.
-{{< /note  >}}
-
-## Understand basic Kubernetes architecture
-
-As an app developer, you don't need to know everything about the inner workings of Kubernetes, but you may find it helpful to understand it at a high level.
-
-#### What Kubernetes offers
-
-Say that your team is deploying an ordinary Rails application. You've run some calculations and determined that you need five instances of your app running at any given time, in order to handle external traffic.
-
-If you're not running Kubernetes or a similar automated system, you might find the following scenario familiar:
-
-{{< note >}}
-1. One instance of your app (a complete machine instance or just a container) goes down.</li>
-
-1. Because your team has monitoring set up, this pages the person on call.</li>
-
-1. The on-call person has to go in, investigate, and manually spin up a new instance.</li>
-
-1. Depending how your team handles DNS/networking, the on-call person may also need to also update the service discovery mechanism to point at the IP of the new Rails instance rather than the old.</li>
-{{< /note >}}
-
-This process can be tedious and also inconvenient, especially if (2) happens in the early hours of the morning!
-
-**If you have Kubernetes set up, however, manual intervention is not as necessary.** The Kubernetes {{< link text="control plane" url="/docs/concepts/overview/components/#master-components" >}}, which runs on your cluster's master node, gracefully handles (3) and (4) on your behalf. As a result, Kubernetes is often referred to as a *self-healing* system.
-
-There are two key parts of the control plane that facilitate this behavior: the *Kubernetes API server* and the *Controllers*.
-
-#### Kubernetes API server
-
-For Kubernetes to be useful, it needs to know *what* sort of cluster state you want it to maintain. Your YAML or JSON *configuration files* declare this desired state in terms of one or more API objects, such as {{< glossary_tooltip text="Deployments" term_id="deployment" >}}. To make updates to your cluster's state, you submit these files to the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server (`kube-apiserver`).
-
-Examples of state include but are not limited to the following:
-
-* The applications or other workloads to run
-* The container images for your applications and workloads
-* Allocation of network and disk resources
-
-Note that the API server is just the gateway, and that object data is actually stored in a highly available datastore called {{< link text="*etcd*" url="https://github.com/coreos/etcd" >}}. For most intents and purposes, though, you can focus on the API server. Most reads and writes to cluster state take place as API requests.
-
-For more information, see {{< link text="Understanding Kubernetes Objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}}.
-
-#### Controllers
-
-Once you’ve declared your desired state through the Kubernetes API, the *controllers* work to make the cluster’s current state match this desired state.
-
-The standard controller processes are {{< link text="`kube-controller-manager`" url="/docs/reference/generated/kube-controller-manager/" >}} and {{< link text="`cloud-controller-manager`" url="/docs/concepts/overview/components/#cloud-controller-manager" >}}, but you can also write your own controllers as well.
-
-All of these controllers implement a *control loop*. For simplicity, you can think of this as the following:
-
-{{< note >}}
-1. What is the current state of the cluster (X)?
-
-1. What is the desired state of the cluster (Y)?
-
-1. X == Y ?
-
-   * `true` - Do nothing.
-   * `false` - Perform tasks to get to Y, such as starting or restarting containers,
-   or scaling the number of replicas of a given application. Return to 1.
-{{< /note >}}
-
-By continuously looping, these controllers ensure the cluster can pick up new updates and avoid drifting from the desired state. These ideas are covered in more detail {{< link text="here" url="/docs/concepts/" >}}.
-
-## Additional resources
-
-The Kubernetes documentation is rich in detail. Here's a curated list of resources to help you start digging deeper.
-
-### Basic concepts
-
-* {{< link text="More about the components that run Kubernetes" url="/docs/concepts/overview/components/" >}}
-
-* {{< link text="Understanding Kubernetes objects" url="/docs/concepts/overview/working-with-objects/kubernetes-objects/" >}}
-
-* {{< link text="More about Node objects" url="/docs/concepts/architecture/nodes/" >}}
-
-* {{< link text="More about Pod objects" url="/docs/concepts/workloads/pods/pod-overview/" >}}
-
-### Tutorials
-
-* {{< link text="Kubernetes Basics" url="/docs/tutorials/kubernetes-basics/" >}}
-
-* {{< link text="Hello Minikube" url="/docs/tutorials/stateless-application/hello-minikube/" >}} *(Runs on Mac only)*
-
-* {{< link text="Kubernetes object management" url="/docs/tutorials/object-management-kubectl/object-management/" >}}
-
-### What's next
-
-If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys:
-
-* {{< link text="Intermediate App Developer" url="/docs/user-journeys/users/application-developer/intermediate/" >}} - Dive deeper, with the next level of this journey.
-* {{< link text="Foundational Cluster Operator" url="/docs/user-journeys/users/cluster-operator/foundational/" >}} - Build breadth, by exploring other journeys.
-
-{{% /capture %}}
@@ -1,166 +0,0 @@
---
-reviewers:
- chenopis
-layout: docsportal
-css: /css/style_user_journeys.css
-js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
-title: Intermediate
-track: "USERS › APPLICATION DEVELOPER › INTERMEDIATE"
-content_template: templates/user-journey-content
---
-
-
-{{% capture overview %}}
-
-{{< note  >}}
-  This page assumes that you've experimented with Kubernetes before. At this point, you should have basic experience interacting with a Kubernetes cluster (locally with Minikube, or elsewhere), and using API objects like Deployments to run your applications.<br><br>If not, you should review the {{< link text="Beginner App Developer" url="/docs/user-journeys/users/application-developer/foundational/" >}} topics first.
-{{< /note  >}}
-After checking out the current page and its linked sections, you should have a better understanding of the following:
-
-* Additional Kubernetes workload patterns, beyond Deployments
-* What it takes to make a Kubernetes application production-ready
-* Community tools that can improve your development workflow
-
-{{% /capture %}}
-
-
-{{% capture body %}}
-
-## Learn additional workload patterns
-
-As your Kubernetes use cases become more complex, you may find it helpful to familiarize yourself with more of the toolkit that Kubernetes provides. {{< link text="Basic workload" url="/docs/user-journeys/users/application-developer/foundational/#section-2" >}} objects like {{< glossary_tooltip text="Deployments" term_id="deployment" >}} make it straightforward to run, update, and scale applications, but they are not ideal for every scenario.
-
-The following API objects provide functionality for additional workload types, whether they are *persistent* or *terminating*.
-
-#### Persistent workloads
-
-Like Deployments, these API objects run indefinitely on a cluster until they are manually terminated. They are best for long-running applications.
-
-*  **{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}** - Like Deployments, StatefulSets allow you to specify that a
-   certain number of replicas should be running for your application.
-
-    {{< note  >}} It's misleading to say that Deployments can't handle stateful workloads. Using {{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}, you can persist data beyond the lifecycle of any individual Pod in your Deployment.
-    {{< /note  >}}
-
-    However, StatefulSets can provide stronger guarantees about "recovery" behavior than Deployments. StatefulSets maintain a sticky, stable identity for their Pods. The following table provides some concrete examples of what this might look like:
-
-    |   | Deployment | StatefulSet |
-    |---|---|---|
-    | **Example Pod name** | `example-b1c4` | `example-0` |
-    | **When a Pod dies** | Reschedule on *any* node, with new name `example-a51z` | Reschedule on same node, as `example-0` |
-    | **When a node becomes unreachable** | Pod(s) are scheduled onto new node, with new names | Pod(s) are marked as "Unknown", and aren't rescheduled unless the Node object is forcefully deleted |
-
-    In practice, this means that StatefulSets are best suited for scenarios where replicas (Pods) need to coordinate their workloads in a strongly consistent manner. Guaranteeing an identity for each Pod helps avoid {{< link text="split-brain" url="https://en.wikipedia.org/wiki/Split-brain_(computing)" >}} side effects in the case when a node becomes unreachable ({{< link text="network partition" url="https://en.wikipedia.org/wiki/Network_partition" >}}). This makes StatefulSets a great fit for distributed datastores like Cassandra or Elasticsearch.
-
-
-* **{{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}** - DaemonSets run continuously on every node in your cluster, even as nodes are added or swapped in. This guarantee is particularly useful for setting up global behavior across your cluster, such as:
-
-  * Logging and monitoring, from applications like `fluentd`
-  * Network proxy or {{< link text="service mesh" url="https://www.linux.com/news/whats-service-mesh-and-why-do-i-need-one" >}}
-
-
-#### Terminating workloads
-
-In contrast to Deployments, these API objects are finite. They stop once the specified number of Pods have completed successfully.
-
-* **{{< glossary_tooltip text="Jobs" term_id="job" >}}** - You can use these for one-off tasks like running a script or setting up a work queue. These tasks can be executed sequentially or in parallel. These tasks should be relatively independent, as Jobs do not support closely communicating parallel processes. {{< link text="Read more about Job patterns" url="/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-patterns" >}}.
-
-* **{{< glossary_tooltip text="CronJobs" term_id="cronjob" >}}** - These are similar to Jobs, but allow you to schedule their execution for a specific time or for periodic recurrence. You might use CronJobs to send reminder emails or to run backup jobs. They are set up with a similar syntax as *crontab*.
-
-#### Other resources
-
-For more info, you can check out {{< link text="a list of additional Kubernetes resource types" url="/docs/reference/kubectl/overview/#resource-types" >}} as well as the {{< link text="API reference docs" url="{{ reference_docs_url }}" >}}.
-
-There may be additional features not mentioned here that you may find useful, which are covered in the {{< link text="full Kubernetes documentation" url="/docs/home/?path=browse" >}}.
-
-## Deploy a production-ready workload
-
-The beginner tutorials on this site, such as the {{< link text="Guestbook app" url="/docs/tutorials/stateless-application/guestbook/" >}}, are geared towards getting workloads up and running on your cluster. This prototyping is great for building your intuition around Kubernetes! However, in order to reliably and securely promote your workloads to production, you need to follow some additional best practices.
-
-#### Declarative configuration
-
-You are likely interacting with your Kubernetes cluster via {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. kubectl can be used to debug the current state of your cluster (such as checking the number of nodes), or to modify live Kubernetes objects (such as updating a workload's replica count with `kubectl scale`).
-
-When using kubectl to update your Kubernetes objects, it's important to be aware that different commands correspond to different approaches:
-
-* {{< link text="Purely imperative" url="/docs/tutorials/object-management-kubectl/imperative-object-management-command/" >}}
-* {{< link text="Imperative with local configuration files" url="/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/" >}} (typically YAML)
-* {{< link text="Declarative with local configuration files" url="/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/" >}} (typically YAML)
-
-There are pros and cons to each approach, though the declarative approach (such as `kubectl apply -f`) may be most helpful in production. With this approach, you rely on local YAML files as the source of truth about your desired state. This enables you to version control your configuration, which is helpful for code reviews and audit tracking.
-
-For additional configuration best practices, familiarize yourself with {{< link text="this guide" url="/docs/concepts/configuration/overview/" >}}.
-
-#### Security
-
-You may be familiar with the *principle of least privilege*---if you are too generous with permissions when writing or using software, the negative effects of a compromise can escalate out of control. Would you be cautious handing out `sudo` privileges to software on your OS? If so, you should be just as careful when granting your workload permissions to the {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server! The API server is the gateway for your cluster's source of truth; it provides endpoints to read or modify cluster state.
-
-You (or your {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}}) can lock down API access with the following:
-
-* **{{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}** - An "identity" that your Pods can be tied to
-* **{{< glossary_tooltip text="RBAC" term_id="rbac" >}}** - One way of granting your ServiceAccount explicit permissions
-
-For even more comprehensive reading about security best practices, consider checking out the following topics:
-
-* {{< link text="Authentication" url="/docs/reference/access-authn-authz/authentication/" >}} (Is the user who they say they are?)
-* {{< link text="Authorization" url="/docs/admin/authorization/" >}} (Does the user actually have permissions to do what they're asking?)
-
-#### Resource isolation and management
-
-If your workloads are operating in a *multi-tenant* environment with multiple teams or projects, your container(s) are not necessarily running alone on their node(s). They are sharing node resources with other containers which you do not own.
-
-Even if your cluster operator is managing the cluster on your behalf, it is helpful to be aware of the following:
-
-* **{{< glossary_tooltip text="Namespaces" term_id="namespace" >}}**, used for isolation
-* **{{< link text="Resource quotas" url="/docs/concepts/policy/resource-quotas/" >}}**, which affect what your team's workloads can use
-* **{{< link text="Memory" url="/docs/tasks/configure-pod-container/assign-memory-resource/" >}} and {{< link text="CPU" url="/docs/tasks/configure-pod-container/assign-cpu-resource/" >}} requests**, for a given Pod or container
-* **{{< link text="Monitoring" url="/docs/tasks/debug-application-cluster/resource-usage-monitoring/" >}}**, both on the cluster level and the app level
-
-This list may not be completely comprehensive, but many teams have existing processes that take care of all this. If this is not the case, you'll find the Kubernetes documentation fairly rich in detail.
-
-## Improve your dev workflow with tooling
-
-As an app developer, you'll likely encounter the following tools in your workflow.
-
-#### kubectl
-
-`kubectl` is a command-line tool that allows you to easily read or modify your Kubernetes cluster. It provides convenient, short commands for common operations like scaling app instances and getting node info. How does kubectl do this? It's basically just a user-friendly wrapper for making API requests. It's written using {{< link text="client-go" url="https://github.com/kubernetes/client-go/#client-go" >}}, the Go library for the Kubernetes API.
-
-To learn about the most commonly used kubectl commands, check out the {{< link text="kubectl cheatsheet" url="/docs/reference/kubectl/cheatsheet/" >}}. It explains topics such as the following:
-
-* {{< link text="kubeconfig files" url="/docs/tasks/access-application-cluster/configure-access-multiple-clusters/" >}} - Your kubeconfig file tells kubectl what cluster to talk to, and can reference multiple clusters (such as dev and prod).
-* {{< link text="The various output formats available" url="/docs/reference/kubectl/cheatsheet/#formatting-output" >}} - This is useful to know when you are using `kubectl get` to list information about certain API objects.
-
-* {{< link text="The JSONPath output format" url="/docs/reference/kubectl/jsonpath/" >}} - This is related to the output formats above. JSONPath is especially useful for parsing specific subfields out of `kubectl get` output (such as the URL of a {{< glossary_tooltip text="Service" term_id="service" >}}).
-
-* {{< link text="`kubectl run` vs `kubectl apply`" url="/docs/reference/kubectl/conventions/" >}} - This ties into the [declarative configuration](#declarative-configuration) discussion in the previous section.
-
-For the full list of kubectl commands and their options, check out {{< link text="the reference guide" url="/docs/reference/generated/kubectl/kubectl-commands" >}}.
-
-#### Helm
-
-To leverage pre-packaged configurations from the community, you can use **{{< glossary_tooltip text="Helm charts" term_id="helm-chart" >}}**.
-
-Helm charts package up YAML configurations for specific apps like Jenkins and Postgres. You can then install and run these apps on your cluster with minimal extra configuration. This approach makes the most sense for "off-the-shelf" components which do not require much custom implementation logic.
-
-For writing your own Kubernetes app configurations, there is a {{< link text="thriving ecosystem of tools" url="https://docs.google.com/a/heptio.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit?usp=drive_web" >}} that you may find useful.
-
-## Explore additional resources
-
-#### References
-Now that you're fairly familiar with Kubernetes, you may find it useful to browse the following reference pages. Doing so provides a high level view of what other features may exist:
-
-* {{< link text="Commonly used `kubectl` commands" url="/docs/reference/kubectl/cheatsheet/" >}}
-* {{< link text="Kubernetes API reference" url="{{ reference_docs_url }}" >}}
-* {{< link text="Standardized Glossary" url="/docs/reference/glossary/" >}}
-
-In addition, {{< link text="the Kubernetes Blog" url="https://kubernetes.io/blog/" >}} often has helpful posts on Kubernetes design patterns and case studies.
-
-#### What's next
-If you feel fairly comfortable with the topics on this page and want to learn more, check out the following user journeys:
-
-* {{< link text="Advanced App Developer" url="/docs/user-journeys/users/application-developer/advanced/" >}} - Dive deeper, with the next level of this journey.
-* {{< link text="Foundational Cluster Operator" url="/docs/user-journeys/users/cluster-operator/foundational/" >}} - Build breadth, by exploring other journeys.
-{{% /capture %}}
-
-
@@ -1,96 +0,0 @@
---
-reviewers:
- chenopis
-layout: docsportal
-css: /css/style_user_journeys.css
-js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
-title: Foundational
-track: "USERS › CLUSTER OPERATOR › FOUNDATIONAL"
-content_template: templates/user-journey-content
---
-
-{{% capture overview %}}
-
-If you want to learn how to get started managing and operating a Kubernetes cluster, this page and the linked topics introduce you to the foundational concepts and tasks.
-This page introduces you to a Kubernetes cluster and key concepts to understand and manage it. The content focuses primarily on the cluster itself rather than the software running within the cluster.
-
-{{% /capture %}}
-
-<!-- Foundational
-Nodes, Pods, Networks, Deployments, Services, ConfigMaps, Secrets
-Labels, Selectors, Annotations
-Metrics
-->
-
-{{% capture body %}}
-
-## Get an overview of Kubernetes
-
-If you have not already done so, start your understanding by reading through [What is Kubernetes?](/docs/concepts/overview/what-is-kubernetes/), which introduces a number of basic concepts and terms.
-
-Kubernetes is quite flexible, and a cluster can be run in a wide variety of places. You can interact with Kubernetes entirely on your own laptop or local development machine with it running within a virtual machine. Kubernetes can also run on virtual machines hosted either locally or in a cloud provider, and you can run a Kubernetes cluster on bare metal.
-
-A cluster is made up of one or more [Nodes](/docs/concepts/architecture/nodes/); where a node is a physical or virtual machine.
-If there is more than one node in your cluster then the nodes are connected with a [cluster network](/docs/concepts/cluster-administration/networking/).
-Regardless of how many nodes, all Kubernetes clusters generally have the same components, which are described in [Kubernetes Components](/docs/concepts/overview/components).
-
-
-## Learn about Kubernetes basics
-
-A good way to become familiar with how to manage and operate a Kubernetes cluster is by setting one up.
-One of the most compact ways to experiment with a cluster is [Installing and using Minikube](/docs/tasks/tools/install-minikube/).
-Minikube is a command line tool for setting up and running a single-node cluster within a virtual machine on your local laptop or development computer. Minikube is even available through your browser at the [Katacoda Kubernetes Playground](https://www.katacoda.com/courses/kubernetes/playground).
-Katacoda provides a browser-based connection to a single-node cluster, using minikube behind the scenes, to support a number of tutorials to explore Kubernetes. You can also leverage the web-based [Play with Kubernetes](http://labs.play-with-k8s.com/) to the same ends - a temporary cluster to play with on the web.
-
-You interact with Kubernetes either through a dashboard, an API, or using a command-line tool (such as `kubectl`) that interacts with the Kubernetes API.
-Be familiar with [Organizing Cluster Access](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) by using configuration files.
-The Kubernetes API exposes a number of resources that provide the building blocks and abstractions that are used to run software on Kubernetes.
-Learn more about these resources at [Understanding Kubernetes Objects](/docs/concepts/overview/working-with-objects/kubernetes-objects).
-These resources are covered in a number of articles within the Kubernetes documentation.
-
-* [Pod Overview](/docs/concepts/workloads/pods/pod-overview/)
-  * [Pods](/docs/concepts/workloads/pods/pod/)
-  * [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/)
-  * [Deployments](/docs/concepts/workloads/controllers/deployment/)
-  * [Garbage Collection](/docs/concepts/workloads/controllers/garbage-collection/)
-  * [Container Images](/docs/concepts/containers/images/)
-  * [Container Environment Variables](/docs/concepts/containers/container-environment-variables/)
-* [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/)
-* [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/)
-  * [Namespaces Walkthrough](/docs/tasks/administer-cluster/namespaces-walkthrough/)
-* [Services](/docs/concepts/services-networking/service/)
-* [Annotations](/docs/concepts/overview/working-with-objects/annotations/)
-* [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
-* [Secrets](/docs/concepts/configuration/secret/)
-
-As a cluster operator you may not need to use all these resources, although you should be familiar with them to understand how the cluster is being used.
-There are a number of additional resources that you should be aware of, some listed under [Intermediate Resources](/docs/user-journeys/users/cluster-operator/intermediate#section-1).
-You should also be familiar with [how to manage kubernetes resources](/docs/concepts/cluster-administration/manage-deployment/)
-and [supported versions and version skew between cluster components](/docs/setup/release/version-skew-policy/).
-
-## Get information about your cluster
-
-You can [access clusters using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/).
-If you are not already familiar with how to do this, you can review the [introductory tutorial](/docs/tutorials/kubernetes-basics/explore-intro/).
-Using `kubectl`, you can retrieve information about your Kubernetes cluster very quickly.
-To get basic information about the nodes in your cluster run the command `kubectl get nodes`.
-You can get more detailed information for the same nodes with the command `kubectl describe nodes`.
-You can see the status of the core of kubernetes with the command `kubectl get componentstatuses`.
-
-Some additional resources for getting information about your cluster and how it is operating include:
-
-* [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
-* [Resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)
-  * [Metrics](/docs/concepts/cluster-administration/controller-metrics/)
-
-## Explore additional resources
-
-### Tutorials
-
-* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/)
-* [Configuring Redis with a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
-* Stateless Applications
-  * [Deploying PHP Guestbook with Redis](/docs/tutorials/stateless-application/guestbook/)
-  * [Expose an External IP address to access an application](/docs/tutorials/stateless-application/expose-external-ip-address/)
-
-{{% /capture %}}
@@ -1,109 +0,0 @@
---
-reviewers:
- chenopis
-layout: docsportal
-css: /css/style_user_journeys.css
-js: https://use.fontawesome.com/4bcc658a89.js, https://cdnjs.cloudflare.com/ajax/libs/prefixfree/1.0.7/prefixfree.min.js
-title: Intermediate
-track: "USERS > CLUSTER OPERATOR > INTERMEDIATE"
-content_template: templates/user-journey-content
---
-
-{{% capture overview %}}
-
-If you are a cluster operator looking to expand your grasp of Kubernetes, this page and its linked topics extend the information provided on the [foundational cluster operator page](/docs/user-journeys/users/cluster-operator/foundational). From this page you can get information on key Kubernetes tasks needed to manage a complete production cluster.
-
-{{% /capture %}}
-
-{{% capture body %}}
-
-## Work with ingress, networking, storage, and workloads
-
-Introductions to Kubernetes typically discuss simple stateless applications. As you move into more complex development, testing, and production environments, you need to consider more complex cases:
-
-Communication: Ingress and Networking
-
-* [Ingress](/docs/concepts/services-networking/ingress/)
-
-Storage: Volumes and PersistentVolumes
-
-* [Volumes](/docs/concepts/storage/volumes/)
-* [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
-
-Workloads
-
-* [DaemonSets](/docs/concepts/workloads/controllers/daemonset/)
-* [Stateful Sets](/docs/concepts/workloads/controllers/statefulset/)
-* [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
-* [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)
-
-Pods
-
-* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
-  * [Init Containers](/docs/concepts/workloads/pods/init-containers/)
-  * [Pod Presets](/docs/concepts/workloads/pods/podpreset/)
-  * [Container Lifecycle Hooks](/docs/concepts/containers/container-lifecycle-hooks/)
-
-And how Pods work with scheduling, priority, disruptions:
-
-* [Taints and Tolerations](/docs/concepts/configuration/taint-and-toleration/)
-* [Pods and Priority](/docs/concepts/configuration/pod-priority-preemption/)
-* [Disruptions](/docs/concepts/workloads/pods/disruptions/)
-* [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/)
-* [Managing Compute Resources for Containers](/docs/concepts/configuration/manage-compute-resources-container/)
-* [Configuration Best Practices](/docs/concepts/configuration/overview/)
-
-## Implement security best practices
-
-Securing your cluster includes work beyond the scope of Kubernetes itself.
-
-In Kubernetes, you configure access control:
-
-* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/)
-* [Authenticating](/docs/reference/access-authn-authz/authentication/)
-* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
-
-You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases.
-
-* [Authorization Overview](/docs/reference/access-authn-authz/authorization/)
-* [Using RBAC Authorization](/docs/reference/access-authn-authz/rbac/)
-
-You should create Secrets to hold sensitive data such as passwords, tokens, or keys. Be aware, however, that there are limitations to the protections that a Secret can provide. See [the Risks section of the Secrets documentation](/docs/concepts/configuration/secret/#risks).
-
-<!-- TODO: Other security content? -->
-
-## Implement custom logging and monitoring
-
-Monitoring the health and state of your cluster is important. Collecting metrics, logging, and providing access to that information are common needs. Kubernetes provides some basic logging structure, and you may want to use additional tools to help aggregate and analyze log data.
-
-Start with the [basics on Kubernetes logging](/docs/concepts/cluster-administration/logging/) to understand how containers do logging and common patterns. Cluster operators often want to add something to gather and aggregate those logs. See the following topics:
-
-* [Logging Using Elasticsearch and Kibana](/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)
-* [Logging Using Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)
-
-Like log aggregation, many clusters utilize additional software to help capture metrics and display them. There is an overview of tools at [Tools for Monitoring Compute, Storage, and Network Resources](/docs/tasks/debug-application-cluster/resource-usage-monitoring/).
-Kubernetes also supports a [resource metrics pipeline](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/) which can be used by Horizontal Pod Autoscaler with custom metrics.
-
-[Prometheus](https://prometheus.io/), another {{< glossary_tooltip text="CNCF" term_id="cncf" >}} project, is a common choice to support capture and temporary collection of metrics. There are several options for installing Prometheus, including using the [stable/prometheus](https://github.com/kubernetes/charts/tree/master/stable/prometheus) [helm](https://helm.sh/) chart, and CoreOS provides a [prometheus operator](https://github.com/coreos/prometheus-operator) and [kube-prometheus](https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus), which adds on Grafana dashboards and common configurations.
-
-A common configuration on [Minikube](https://github.com/kubernetes/minikube) and some Kubernetes clusters uses [Heapster](https://github.com/kubernetes/heapster)
-[along with InfluxDB and Grafana](https://github.com/kubernetes/heapster/blob/master/docs/influxdb.md).
-There is a [walkthrough of how to install this configuration in your cluster](https://blog.kublr.com/how-to-utilize-the-heapster-influxdb-grafana-stack-in-kubernetes-for-monitoring-pods-4a553f4d36c9).
-As of Kubernetes 1.11, Heapster is deprecated, as per [sig-instrumentation](https://github.com/kubernetes/community/tree/master/sig-instrumentation).  See [Prometheus vs. Heapster vs. Kubernetes Metrics APIs](https://brancz.com/2018/01/05/prometheus-vs-heapster-vs-kubernetes-metrics-apis/) for more information alternatives.
-
-Hosted monitoring, APM, or data analytics services such as [Datadog](https://docs.datadoghq.com/integrations/kubernetes/) or [Instana](https://www.instana.com/supported-integrations/kubernetes-monitoring/) also offer Kubernetes integration.
-
-## Additional resources
-
-Cluster Administration:
-
-* [Troubleshoot Clusters](/docs/tasks/debug-application-cluster/debug-cluster/)
-* [Debug Pods and Replication Controllers](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/)
-* [Debug Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
-* [Debug Stateful Sets](/docs/tasks/debug-application-cluster/debug-stateful-set/)
-* [Debug Applications](/docs/tasks/debug-application-cluster/debug-application/)
-* [Using explorer to investigate your cluster](https://github.com/kubernetes/examples/blob/master/staging/explorer/README.md)
-
-{{% /capture %}}
-
-
@@ -0,0 +1,39 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: php-apache
+spec:
+  selector:
+    matchLabels:
+      run: php-apache
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        run: php-apache
+    spec:
+      containers:
+      - name: php-apache
+        image: k8s.gcr.io/hpa-example
+        ports:
+        - containerPort: 80
+        resources:
+          limits:
+            cpu: 500m
+          requests:
+            cpu: 200m
+
+---
+
+apiVersion: v1
+kind: Service
+metadata:
+  name: php-apache
+  labels:
+    run: php-apache
+spec:
+  ports:
+  - port: 80
+  selector:
+    run: php-apache
+
@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-egress
+spec:
+  podSelector: {}
+  egress:
+  - {}
+  policyTypes:
+  - Egress
@@ -0,0 +1,11 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all-ingress
+spec:
+  podSelector: {}
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress
@@ -0,0 +1,9 @@
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-all
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
+  - Egress
@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-egress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Egress
@@ -0,0 +1,9 @@
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny-ingress
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress