Merge pull request #30481 from jihoon-seo/211115_Update_outdated_files_in_dev-1.21-ko.8

[ko] Update outdated in dev-1.21-ko.8 (M13-M40)
Merge pull request #30483 from jihoon-seo/211115_ko_Update_links_in_dev-1.21-ko.8
2021-11-22 03:49:09 -08:00 · 2021-11-15 18:23:26 -08:00 · 2021-11-14 21:58:47 -08:00 · 2021-11-14 21:56:47 -08:00 · 2021-11-15 14:38:04 +09:00 · 2021-11-15 14:14:47 +09:00
202 changed files with 4153 additions and 2512 deletions
@@ -132,10 +132,11 @@ aliases:
    - ClaudiaJKang
    - gochist
    - ianychoi
-    - seokho-son
-    - ysyukr
+    - jihoon-seo
    - pjhwa
+    - seokho-son
    - yoonian
+    - ysyukr
  sig-docs-leads: # Website chairs and tech leads
    - irvifa
    - jimangel
@@ -157,8 +158,10 @@ aliases:
    # zhangxiaoyu-zidif
  sig-docs-zh-reviews: # PR reviews for Chinese content
    - chenrui333
+    - chenxuc
    - howieyuen
    - idealhack
+    - mengjiao-liu
    - pigletfly
    - SataQiu
    - tanjunchen
@@ -1,6 +1,6 @@
 # 쿠버네티스 문서화

-[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)

 이 저장소에는 [쿠버네티스 웹사이트 및 문서](https://kubernetes.io/)를 빌드하는 데 필요한 자산이 포함되어 있습니다. 기여해주셔서 감사합니다!

@@ -1,6 +1,6 @@
 # Dokumentacja projektu Kubernetes

-[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)

 W tym repozytorium znajdziesz wszystko, czego potrzebujesz do zbudowania [strony internetowej Kubernetesa wraz z dokumentacją](https://kubernetes.io/). Bardzo nam miło, że chcesz wziąć udział w jej współtworzeniu!

@@ -1,6 +1,6 @@
 # A documentação do Kubernetes

-[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)

 Bem-vindos! Este repositório contém todos os recursos necessários para criar o [website e documentação do Kubernetes](https://kubernetes.io/). Estamos muito satisfeitos por você querer contribuir!

@@ -1,7 +1,7 @@
 <!-- # The Kubernetes documentation -->
 # Документація Kubernetes

-[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)

 <!-- This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute! -->
 Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [сайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок!
@@ -4,10 +4,10 @@

 This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute!

-+ [Contributing to the docs](#contributing-to-the-docs)
-+ [Localization ReadMes](#localization-readmemds)
+- [Contributing to the docs](#contributing-to-the-docs)
+- [Localization ReadMes](#localization-readmemds)

-# Using this repository
+## Using this repository

 You can run the website locally using Hugo (Extended version), or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website.

@@ -22,14 +22,14 @@ To use this repository, you need the following installed locally:

 Before you start, install the dependencies. Clone the repository and navigate to the directory:

-```
+```bash
 git clone https://github.com/kubernetes/website.git
 cd website
 ```

 The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:

-```
+```bash
 # pull in the Docsy submodule
 git submodule update --init --recursive --depth 1
 ```
@@ -38,14 +38,14 @@ git submodule update --init --recursive --depth 1

 To build the site in a container, run the following to build the container image and run it:

-```
+```bash
 make container-image
 make container-serve
 ```

 If you see errors, it probably means that the hugo container did not have enough computing resources available. To solve it, increase the amount of allowed CPU and memory usage for Docker on your machine ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) and [Windows](https://docs.docker.com/docker-for-windows/#resources)).

-Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+Open up your browser to <http://localhost:1313> to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.

 ## Running the website locally using Hugo

@@ -59,54 +59,55 @@ npm ci
 make serve
 ```

-This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+This will start the local Hugo server on port 1313. Open up your browser to <http://localhost:1313> to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.

 ## Building the API reference pages

-The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, using https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs.
+The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, using <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>.

 To update the reference pages for a new Kubernetes release (replace v1.20 in the following examples with the release to update to):

 1. Pull the `kubernetes-resources-reference` submodule:

-```
-git submodule update --init --recursive --depth 1
-```
+   ```bash
+   git submodule update --init --recursive --depth 1
+   ```

 2. Create a new API revision into the submodule, and add the Swagger specification:

-```
-mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
-curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-generator/gen-resourcesdocs/api/v1.20/swagger.json
-```
+   ```bash
+   mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
+   curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-generator/gen-resourcesdocs/api/v1.20/swagger.json
+   ```

 3. Copy the table of contents and fields configuration for the new release from a previous one:

-```
-mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
-cp api-ref-generator/gen-resourcesdocs/api/v1.19/* api-ref-generator/gen-resourcesdocs/api/v1.20/
-```
+   ```bash
+   mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
+   cp api-ref-generator/gen-resourcesdocs/api/v1.19/* api-ref-generator/gen-resourcesdocs/api/v1.20/
+   ```

 4. Adapt the files `toc.yaml` and `fields.yaml` to reflect the changes between the two releases

 5. Next, build the pages:

-```
-make api-reference
-```
+   ```bash
+   make api-reference
+   ```

-You can test the results locally by making and serving the site from a container image:
+   You can test the results locally by making and serving the site from a container image:

-```
-make container-image
-make container-serve
-```
+   ```bash
+   make container-image
+   make container-serve
+   ```

-In a web browser, go to http://localhost:1313/docs/reference/kubernetes-api/ to view the API reference.
+   In a web browser, go to <http://localhost:1313/docs/reference/kubernetes-api/> to view the API reference.

 6. When all changes of the new contract are reflected into the configuration files `toc.yaml` and `fields.yaml`, create a Pull Request with the newly generated API reference pages.

 ## Troubleshooting
+
 ### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version

 Hugo is shipped in two set of binaries for technical reasons. The current website runs based on the **Hugo Extended** version only. In the [release page](https://github.com/gohugoio/hugo/releases) look for archives with `extended` in the name. To confirm, run `hugo version` and look for the word `extended`.
@@ -115,7 +116,7 @@ Hugo is shipped in two set of binaries for technical reasons. The current websit

 If you run `make serve` on macOS and receive the following error:

-```
+```bash
 ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
 make: *** [serve] Error 1
 ```
@@ -124,7 +125,7 @@ Try checking the current limit for open files:

 `launchctl limit maxfiles`

-Then run the following commands (adapted from https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c):
+Then run the following commands (adapted from <https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c>):

 ```shell
 #!/bin/sh
@@ -147,8 +148,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist

 This works for Catalina as well as Mojave macOS.

-
-# Get involved with SIG Docs
+## Get involved with SIG Docs

 Learn more about SIG Docs Kubernetes community and meetings on the [community page](https://github.com/kubernetes/community/tree/master/sig-docs#meetings).

@@ -157,39 +157,39 @@ You can also reach the maintainers of this project at:
 - [Slack](https://kubernetes.slack.com/messages/sig-docs) [Get an invite for this Slack](https://slack.k8s.io/)
 - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)

-# Contributing to the docs
+## Contributing to the docs

-You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
+You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a _fork_. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.

-Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.  As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
+Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**

 Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.

-Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed.  Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
+Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.

 For more information about contributing to the Kubernetes documentation, see:

-* [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
-* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
-* [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
-* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
+- [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
+- [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
+- [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
+- [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)

-# Localization `README.md`'s
+## Localization `README.md`'s

-| Language  | Language |
-|---|---|
-|[Chinese](README-zh.md)|[Korean](README-ko.md)|
-|[French](README-fr.md)|[Polish](README-pl.md)|
-|[German](README-de.md)|[Portuguese](README-pt.md)|
-|[Hindi](README-hi.md)|[Russian](README-ru.md)|
-|[Indonesian](README-id.md)|[Spanish](README-es.md)|
-|[Italian](README-it.md)|[Ukrainian](README-uk.md)|
-|[Japanese](README-ja.md)|[Vietnamese](README-vi.md)|
+| Language                   | Language                   |
+| -------------------------- | -------------------------- |
+| [Chinese](README-zh.md)    | [Korean](README-ko.md)     |
+| [French](README-fr.md)     | [Polish](README-pl.md)     |
+| [German](README-de.md)     | [Portuguese](README-pt.md) |
+| [Hindi](README-hi.md)      | [Russian](README-ru.md)    |
+| [Indonesian](README-id.md) | [Spanish](README-es.md)    |
+| [Italian](README-it.md)    | [Ukrainian](README-uk.md)  |
+| [Japanese](README-ja.md)   | [Vietnamese](README-vi.md) |

-# Code of conduct
+## Code of conduct

 Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

-# Thank you!
+## Thank you

 Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
@@ -138,13 +138,13 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.21"
+latest = "v1.22"

-fullversion = "v1.21.0"
+fullversion = "v1.21.4"
 version = "v1.21"
-githubbranch = "master"
-docsbranch = "master"
-deprecated = false
+githubbranch = "release-1.21"
+docsbranch = "release-1.21"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"

@@ -178,41 +178,40 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.21.0"
-version = "v1.21"
-githubbranch = "v1.21.0"
-docsbranch = "master"
+fullversion = "v1.22.0"
+version = "v1.22"
+githubbranch = "v1.22.0"
+docsbranch = "main"
 url = "https://kubernetes.io"

 [[params.versions]]
-fullversion = "v1.20.5"
+fullversion = "v1.21.4"
+version = "v1.21"
+githubbranch = "v1.21.4"
+docsbranch = "release-1.21"
+url = "https://v1-21.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.20.10"
 version = "v1.20"
-githubbranch = "v1.20.5"
+githubbranch = "v1.20.10"
 docsbranch = "release-1.20"
 url = "https://v1-20.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.19.9"
+fullversion = "v1.19.14"
 version = "v1.19"
-githubbranch = "v1.19.9"
+githubbranch = "v1.19.14"
 docsbranch = "release-1.19"
 url = "https://v1-19.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.18.17"
+fullversion = "v1.18.20"
 version = "v1.18"
-githubbranch = "v1.18.17"
+githubbranch = "v1.18.20"
 docsbranch = "release-1.18"
 url = "https://v1-18.docs.kubernetes.io"

-[[params.versions]]
-fullversion = "v1.17.17"
-version = "v1.17"
-githubbranch = "v1.17.17"
-docsbranch = "release-1.17"
-url = "https://v1-17.docs.kubernetes.io"
-
-
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.
@@ -26,7 +26,7 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
 * [Contiv](http://contiv.github.io) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
 * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
-* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
+* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
 * [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
 * [Multus](https://github.com/Intel-Corp/multus-cni) ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
@@ -104,7 +104,7 @@ Master and Worker nodes should be protected from overload and resource exhaustio

 Resource consumption by the control plane will correlate with the number of pods and the pod churn rate. Very large and very small clusters will benefit from non-default [settings](/docs/reference/command-line-tools-reference/kube-apiserver/) of kube-apiserver request throttling and memory. Having these too high can lead to request limit exceeded and out of memory errors.

-On worker nodes, [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) should be configured based on a reasonable supportable workload density at each node. Namespaces can be created to subdivide the worker node cluster into multiple virtual clusters with resource CPU and memory [quotas](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). Kubelet handling of [out of resource](/docs/tasks/administer-cluster/out-of-resource/) conditions can be configured.
+On worker nodes, [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) should be configured based on a reasonable supportable workload density at each node. Namespaces can be created to subdivide the worker node cluster into multiple virtual clusters with resource CPU and memory [quotas](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). Kubelet handling of [out of resource](/docs/concepts/scheduling-eviction/node-pressure-eviction/) conditions can be configured.

 ## Security

@@ -154,7 +154,7 @@ removals before you upgrade to Kubernetes v1.22.

 To do that, add the following to the kube-apiserver command line arguments:

-`--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1=false,apiregistration.k8s.io/v1beta1=false,authentication.k8s.io/v1beta1=false,authorization.k9s.io/v1=false,certificates.k8s.io/v1beta=false,coordination.k8s.io/v1beta1=false,extensions/v1beta1/ingresses=false,networking.k8s.io/v1beta1=false`
+`--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1=false,apiregistration.k8s.io/v1beta1=false,authentication.k8s.io/v1beta1=false,authorization.k8s.io/v1beta1=false,certificates.k8s.io/v1beta1=false,coordination.k8s.io/v1beta1=false,extensions/v1beta1/ingresses=false,networking.k8s.io/v1beta1=false`

 (as a side effect, this also turns off v1beta1 of EndpointSlice - watch out for
 that when you're testing).
@@ -0,0 +1,83 @@
+---
+layout: blog
+title: "Kubernetes Release Cadence Change: Here’s What You Need To Know"
+date: 2021-07-20
+slug: new-kubernetes-release-cadence
+---
+
+**Authors**: Celeste Horgan, Adolfo García Veytia, James Laverack, Jeremy Rickard
+
+On April 23, 2021, the Release Team merged a Kubernetes Enhancement Proposal (KEP) changing the Kubernetes release cycle from four releases a year (once a quarter) to three releases a year. 
+
+This blog post provides a high level overview about what this means for the Kubernetes community's contributors and maintainers.
+
+## What's changing and when
+
+Starting with the [Kubernetes 1.22 release](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.22), a lightweight policy will drive the creation of each release schedule. This policy states:
+
+* The first Kubernetes release of a calendar year should start at the second or third
+   week of January to provide people more time for contributors coming back from the
+   end of year holidays.
+* The last Kubernetes release of a calendar year should be finished by the middle of
+   December.
+* A Kubernetes release cycle has a length of approximately 15 weeks.
+* The week of KubeCon + CloudNativeCon is not considered a 'working week' for SIG Release. The Release Team will not hold meetings or make decisions in this period.
+* An explicit SIG Release break of at least two weeks between each cycle will
+   be enforced.
+
+As a result, Kubernetes will follow a three releases per year cadence. Kubernetes 1.23 will be the final release of the 2021 calendar year. This new policy results in a very predictable release schedule, allowing us to forecast upcoming release dates:
+
+
+*Proposed Kubernetes Release Schedule for the remainder of 2021*
+
+| Week Number in Year | Release Number | Release Week | Note |
+| -------- | -------- | -------- | -------- |
+| 35 | 1.23 | 1 (August 23) | | 
+| 50 | 1.23 | 16 (December 07) | KubeCon + CloudNativeCon NA Break (Oct 11-15) | 
+
+*Proposed Kubernetes Release Schedule for 2022*
+
+| Week Number in Year | Release Number | Release Week | Note |
+| -------- | -------- | -------- | -------- |
+| 1  | 1.24 | 1 (January 03) | |
+| 15 | 1.24 | 15 (April 12) | | 
+| 17 | 1.25 | 1 (April 26) | KubeCon + CloudNativeCon EU likely to occur |
+| 32 | 1.25 | 15 (August 09) | |
+| 34 | 1.26 | 1 (August 22 | KubeCon + CloudNativeCon NA likely to occur |
+| 49 | 1.26 | 14 (December 06) |
+
+These proposed dates reflect only the start and end dates, and they are subject to change. The Release Team will select dates for enhancement freeze, code freeze, and other milestones at the start of each release. For more information on these milestones, please refer to the [release phases](https://www.k8s.dev/resources/release/#phases) documentation. Feedback from prior releases will feed into this process.
+
+## What this means for end users 
+
+The major change end users will experience is a slower release cadence and a slower rate of enhancement graduation. Kubernetes release artifacts, release notes, and all other aspects of any given release will stay the same.
+
+Prior to this change an enhancement could graduate from alpha to stable in 9 months. With the change in cadence, this will stretch to 12 months. Additionally, graduation of features over the last few releases has in some part been driven by release team activities.
+
+With fewer releases, users can expect to see the rate of feature graduation slow. Users can also expect releases to contain a larger number of enhancements that they need to be aware of during upgrades. However, with fewer releases to consume per year, it's intended that end user organizations will spend less time on upgrades and gain more time on supporting their Kubernetes clusters. It also means that Kubernetes releases are in support for a slightly longer period of time, so bug fixes and security patches will be available for releases for a longer period of time.
+
+
+## What this means for Kubernetes contributors 
+
+With a lower release cadence, contributors have more time for project enhancements, feature development, planning, and testing. A slower release cadence also provides more room for maintaining their mental health, preparing for events like KubeCon + CloudNativeCon or work on downstream integrations.
+
+
+## Why we decided to change the release cadence
+
+The Kubernetes 1.19 cycle was far longer than usual. SIG Release extended it to lessen the burden on both Kubernetes contributors and end users due the COVID-19 pandemic. Following this extended release, the Kubernetes 1.20 release became the third, and final, release for 2020. 
+
+As the Kubernetes project matures, the number of enhancements per cycle grows, along with the burden on contributors, the Release Engineering team.  Downstream consumers and integrators also face increased challenges keeping up with [ever more feature-packed releases](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/). A wider project adoption means the complexity of supporting a rapidly evolving platform affects a bigger downstream chain of consumers.
+
+Changing the release cadence from four to three releases per year balances a variety of factors for stakeholders: while it's not strictly an LTS policy, consumers and integrators will get longer support terms for each minor version as the extended release cycles lead to the [previous three releases being supported](https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/) for a longer period. Contributors get more time to [mature enhancements](https://www.cncf.io/blog/2021/04/12/enhancing-the-kubernetes-enhancements-process/) and [get them ready for production](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md). 
+
+Finally, the management overhead for SIG Release and the Release Engineering team diminishes allowing the team to spend more time on improving the quality of the software releases and the tooling that drives them.
+
+## How you can help
+
+Join the [discussion](https://github.com/kubernetes/sig-release/discussions/1566) about communicating future release dates and be sure to be on the lookout for post release surveys. 
+
+## Where you can find out more
+
+-  Read the KEP [here](https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/2572-release-cadence)
+-  Join the [kubernetes-dev](https://groups.google.com/g/kubernetes-dev) mailing list
+-  Join [Kubernetes Slack](https://slack.k8s.io) and follow the #announcements channel
@@ -0,0 +1,71 @@
+---
+layout: blog
+title: 'Updating NGINX-Ingress to use the stable Ingress API'
+date: 2021-07-26
+slug: update-with-ingress-nginx
+---
+
+**Authors:** James Strong, Ricardo Katz
+
+With all Kubernetes APIs, there is a process to creating, maintaining, and
+ultimately deprecating them once they become GA. The networking.k8s.io API group is no
+different. The upcoming Kubernetes 1.22 release will remove several deprecated APIs
+that are relevant to networking:
+
+- the `networking.k8s.io/v1beta1` API version of [IngressClass](/docs/concepts/services-networking/ingress/#ingress-class)
+- all beta versions of [Ingress](/docs/concepts/services-networking/ingress/): `extensions/v1beta1` and `networking.k8s.io/v1beta1`
+
+On a v1.22 Kubernetes cluster, you'll be able to access Ingress and IngressClass
+objects through the stable (v1) APIs, but access via their beta APIs won't be possible.
+This change has been in
+in discussion since
+[2017](https://github.com/kubernetes/kubernetes/issues/43214),
+[2019](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) with 
+1.16 Kubernetes API deprecations, and most recently in
+KEP-1453: 
+[Graduate Ingress API to GA](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/1453-ingress-api#122).
+
+During community meetings, the networking Special Interest Group has decided to continue 
+supporting Kubernetes versions older than 1.22 with Ingress-NGINX version 0.47.0. 
+Support for Ingress-NGINX will continue for six months after Kubernetes 1.22 
+is released. Any additional bug fixes and CVEs for Ingress-NGINX will be 
+addressed on a need-by-need basis.
+
+Ingress-NGINX will have separate branches and releases of Ingress-NGINX to 
+support this model, mirroring the Kubernetes project process. Future 
+releases of the Ingress-NGINX project will track and support the latest 
+versions of Kubernetes.
+
+{{< table caption="Ingress NGINX supported version with Kubernetes Versions" >}}
+Kubernetes version  | Ingress-NGINX version | Notes
+:-------------------|:----------------------|:------------
+v1.22              | v1.0.0-alpha.2     | New features, plus bug fixes.
+v1.21              | v0.47.x        | Bugfixes only, and just for security issues or crashes. No end-of-support date announced.
+v1.20              | v0.47.x        | Bugfixes only, and just  for security issues or crashes. No end-of-support date announced.
+v1.19              | v0.47.x        | Bugfixes only, and just  for security issues or crashes. Fixes only provided until 6 months after Kubernetes v1.22.0 is released.
+{{< /table >}}    
+
+Because of the updates in Kubernetes 1.22, **v0.47.0** will not work with 
+Kubernetes 1.22. 
+
+# What you need to do
+
+The team is currently in the process of upgrading ingress-nginx to support 
+the v1 migration, you can track the progress 
+[here](https://github.com/kubernetes/ingress-nginx/pull/7156).  
+We're not making feature improvements to `ingress-nginx` until after the support for
+Ingress v1 is complete.
+
+In the meantime to ensure no compatibility issues: 
+
+* Update to the latest version of Ingress-NGINX; currently
+  [v0.47.0](https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v0.47.0) 
+* After Kubernetes 1.22 is released, ensure you are using the latest version of 
+  Ingress-NGINX that supports the stable APIs for Ingress and IngressClass.
+* Test Ingress-NGINX version v1.0.0-alpha.2 with Cluster versions >= 1.19 
+  and report any issues to the projects Github page. 
+
+The community’s feedback and support in this effort is welcome. The
+Ingress-NGINX Sub-project regularly holds community meetings where we discuss
+this and other issues facing the project. For more information on the sub-project, 
+please see [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network).
@@ -0,0 +1,231 @@
+---
+layout: blog
+title: "Roorkee robots, releases and racing: the Kubernetes 1.21 release interview"
+date: 2021-07-29
+---
+
+**Author**: Craig Box (Google)
+
+With Kubernetes 1.22 due out next week, now is a great time to look back on 1.21. The release team for that version was led by [Nabarun Pal](https://twitter.com/theonlynabarun) from VMware.
+
+Back in April I [interviewed Nabarun](https://kubernetespodcast.com/episode/146-kubernetes-1.21/) on the weekly [Kubernetes Podcast from Google](https://kubernetespodcast.com/); the latest in a series of release lead conversations that started back with 1.11, not long after the show started back in 2018.
+
+In these interviews we learn a little about the release, but also about the process behind it, and the story behind the person chosen to lead it. Getting to know a community member is my favourite part of the show each week, and so I encourage you to [subscribe wherever you get your podcasts](https://kubernetespodcast.com/subscribe/). With a release coming next week, you can probably guess what our next topic will be!
+
+*This transcript has been edited and condensed for clarity.*
+
+---
+
+**CRAIG BOX: You have a Bachelor of Technology in Metallurgical and Materials Engineering. How are we doing at turning lead into gold?**
+
+NABARUN PAL: Well, last I checked, we have yet to find the philosopher's stone!
+
+**CRAIG BOX: One of the more important parts of the process?**
+
+NABARUN PAL: We're not doing that well in terms of getting alchemists up and running. There is some improvement in nuclear technology, where you can turn lead into gold, but I would guess buying gold would be much more efficient.
+
+**CRAIG BOX: Or Bitcoin? It depends what you want to do with the gold.**
+
+NABARUN PAL: Yeah, seeing the increasing prices of Bitcoin, you'd probably prefer to bet on that. But, don't take this as a suggestion. I'm not a registered investment advisor, and I don't give investment advice!
+
+**CRAIG BOX: But you are, of course, a trained materials engineer. How did you get into that line of education?**
+
+NABARUN PAL: We had a graded and equated exam structure, where you sit a single exam, and then based on your performance in that exam, you can try any of the universities which take those scores into account. I went to the Indian Institute of Technology, Roorkee.
+
+Materials engineering interested me a lot. I had a passion for computer science since childhood, but I also liked material science, so I wanted to explore that field. I did a lot of exploration around material science and metallurgy in my freshman and sophomore years, but then computing, since it was a passion, crept into the picture.
+
+**CRAIG BOX: Let's dig in there a little bit. What did computing look like during your childhood?**
+
+NABARUN PAL: It was a very interesting journey. I started exploring computers back when I was seven or eight. For my first programming language, if you call it a programming language, I explored LOGO.
+
+You have a turtle on the screen, and you issue commands to it, like move forward or rotate or pen up or pen down. You basically draw geometric figures. I could visually see how I could draw a square and how I could draw a triangle. It was an interesting journey after that. I learned BASIC, then went to some amount of HTML, JavaScript.
+
+**CRAIG BOX: It's interesting to me because Logo and BASIC were probably my first two programming languages, but I think there was probably quite a gap in terms of when HTML became a thing after those two! Did your love of computing always lead you down the path towards programming, or were you interested as a child in using computers for games or application software? What led you specifically into programming?**
+
+NABARUN PAL: Programming came in late. Not just in computing, but in life, I'm curious with things. When my parents got me my first computer, I was curious. I was like, "how does this operating system work?" What even is running it? Using a television and using a computer is a different experience, but usability is kind of the same thing. The HCI device for a television is a remote, whereas with a computer, I had a keyboard and a mouse. I used to tinker with the box and reinstall operating systems.
+
+We used to get magazines back then. They used to bundle OpenSuse or Debian, and I used to install them. It was an interesting experience, 15 years back, how Linux used to be. I have been a tinkerer all around, and that's what eventually led me to programming.
+
+**CRAIG BOX: With an interest in both the physical and ethereal aspects of technology, you did a lot of robotics challenges during university. That's something that I am not surprised to hear from someone who has a background in Logo, to be honest. There's Mindstorms, and a lot of other technology that is based around robotics that a lot of LOGO people got into. How was that something that came about for you?**
+
+NABARUN PAL: When I joined my university, apart from studying materials, one of the things they used to really encourage was to get involved in a lot of extracurricular activities. One which interested me was robotics. I joined [my college robotics team](https://github.com/marsiitr) and participated in a lot of challenges.
+
+Predominantly, we used to participate in this competition called [ABU Robocon](https://en.wikipedia.org/wiki/ABU_Robocon), which is an event conducted by the Asia-Pacific Broadcasting Union. What they used to do was, every year, one of the participating countries in the contest would provide a problem statement. For example, one year, they asked us to build a badminton-playing robot.  They asked us to build a rugby playing robot or a Frisbee thrower, and there are some interesting problem statements around the challenge: you can't do this. You can't do that. Weight has to be like this. Dimensions have to be like that.
+
+I got involved in that, and most of my time at university, I used to spend there. Material science became kind of a backburner for me, and my hobby became my full time thing.
+
+**CRAIG BOX: And you were not only involved there in terms of the project and contributions to it, but you got involved as a secretary of the team, effectively, doing a lot of the organization, which is a thread that will come up as we speak about Kubernetes.**
+
+NABARUN PAL: Over the course of time, when I gained more knowledge into how the team works, it became very natural that I graduated up the ladder and then managed juniors. I became the joint secretary of the robotics club in our college. This was more of a broad, engaging role in evangelizing robotics at the university, to promote events, to help students to see the value in learning robotics - what you gain out of that mechanically or electronically, or how do you develop your logic by programming robots.
+
+**CRAIG BOX: Your first job after graduation was working at a company called Algoshelf, but you were also an intern there while you were at school?**
+
+NABARUN PAL: Algoshelf was known as Rorodata when I joined them as an intern. This was also an interesting opportunity for me in the sense that I was always interested in writing programs which people would use. One of the things that I did there was  build an open source Function as a Service framework, if I may call it that - it was mostly turning Python functions into web servers without even writing any code. The interesting bit there was that it was targeted toward data scientists, and not towards programmers. We had to understand the pain of data scientists, that they had to learn a lot of programming in order to even deploy their machine learning models, and we wanted to solve that problem.
+
+They offered me a job after my internship, and I kept on working for them after I graduated from university. There, I got introduced to Kubernetes, so we pivoted into a product structure where the very same thing I told you, the Functions as a Service thing, could be deployed in Kubernetes. I was exploring Kubernetes to use it as a scalable platform. Instead of managing pets, we wanted to manage cattle, as in, we wanted to have a very highly distributed architecture.
+
+**CRAIG BOX: Not actual cattle. I've been to India. There are a lot of cows around.**
+
+NABARUN PAL: Yeah, not actual cattle. That is a bit tough.
+
+**CRAIG BOX: When Algoshelf we're looking at picking up Kubernetes, what was the evaluation process like? Were you looking at other tools at the time? Or had enough time passed that Kubernetes was clearly the platform that everyone was going to use?**
+
+NABARUN PAL: Algoshelf was a natural evolution. Before Kubernetes, we used to deploy everything on a single big AWS server, using systemd. Everything was a systemd service, and everything was deployed using Fabric. Fabric is a Python package which essentially is like Ansible, but much leaner, as it does not have all the shims and things that Ansible has.
+
+Then we asked "what if we need to scale out to different machines?" Kubernetes was in the hype. We hopped onto the hype train to see whether Kubernetes was worth it for us. And that's where my journey started, exploring the ecosystem, exploring the community. How can we improve the community in essence?
+
+**CRAIG BOX: A couple of times now you've mentioned as you've grown in a role, becoming part of the organization and the arranging of the group. You've talked about working in Python. You had submitted some talks to Pycon India. And I understand you're now a tech lead for that conference. What does the tech community look like in India and how do you describe your involvement in it?**
+
+NABARUN PAL: My involvement with the community began when I was at university. When I was working as an intern at Algoshelf, I was introduced to this-- I never knew about PyCon India, or tech conferences in general.
+
+The person that I was working with just asked me, like hey, did you submit a talk to PyCon India? It's very useful, the library that we were making. So I [submitted a talk](https://www.nabarun.in/talk/2017/pyconindia/#1) to PyCon India in 2017. Eventually the talk got selected. That was not my first speaking opportunity, it was my second. I also spoke at PyData Delhi on a similar thing that I worked on in my internship.
+
+It has been a journey since then. I talked about the same thing at FOSSASIA Summit in Singapore, and got really involved with the Python community because it was what I used to work on back then.
+
+After giving all those talks at conferences, I got also introduced to this amazing group called [dgplug](https://dgplug.org/), which is an acronym for the Durgapur Linux Users Group. It is a group started in-- I don't remember the exact year, but it was around 12 to 13 years back, by someone called Kushal Das, with the ideology of [training students into being better open source contributors](https://foss.training/).
+
+I liked the idea and got involved with in teaching last year. It is not limited to students. Professionals can also join in. It's about making anyone better at upstream contributions, making things sustainable. I started training people on Vim, on how to use text editors. so they are more efficient and productive. In general life, text editors are a really good tool.
+
+The other thing was the shell. How do you navigate around the Linux shell and command line? That has been a fun experience.
+
+**CRAIG BOX: It's very interesting to think about that, because my own involvement with a Linux User Group was probably around the year 2000. And back then we were teaching people how to install things-- Linux on CD was kinda new at that point in time. There was a lot more of, what is this new thing and how do we get involved? When the internet took off around that time, all of that stuff moved online - you no longer needed to go meet a group of people in a room to talk about Linux. And I haven't really given much thought to the concept of a LUG since then, but it's great to see it having turned into something that's now about contributing, rather than just about how you get things going for yourself.**
+
+NABARUN PAL: Exactly. So as I mentioned earlier, my journey into Linux was installing SUSE from DVDs that came bundled with magazines. Back then it was a pain installing things because you did not get any instructions. There has certainly been a paradigm shift now. People are more open to reading instructions online, downloading ISOs, and then just installing them. So we really don't need to do that as part of LUGs.
+
+We have shifted more towards enabling people to contribute to whichever project that they use. For example, if you're using Fedora, contribute to Fedora; make things better. It's just about giving back to the community in any way possible.
+
+**CRAIG BOX: You're also involved in the [Kubernetes Bangalore meetup group](https://www.meetup.com/Bangalore-Kubernetes-Meetup/). Does that group have a similar mentality?**
+
+NABARUN PAL: The Kubernetes Bangalore meetup group is essentially focused towards spreading the knowledge of Kubernetes and the aligned products in the ecosystem, whatever there is in the Cloud Native Landscape, in various ways. For example, to evangelize about using them in your company or how people use them in existing ways.
+
+So a few months back in February, we did something like a [Kubernetes contributor workshop](https://www.youtube.com/watch?v=FgsXbHBRYIc). It was one of its kind in India. It was the first one if I recall correctly. We got a lot of traction and community members interested in contributing to Kubernetes and a lot of other projects. And this is becoming a really valuable thing.
+
+I'm not much involved in the organization of the group. There are really great people already organizing it. I keep on being around and attending the meetups and trying to answer any questions if people have any.
+
+**CRAIG BOX: One way that it is possible to contribute to the Kubernetes ecosystem is through the release process. You've [written a blog](https://blog.naba.run/posts/release-enhancements-journey/) which talks about your journey through that. It started in Kubernetes 1.17, where you took a shadow role for that release. Tell me about what it was like to first take that plunge.**
+
+NABARUN PAL: Taking the plunge was a big step, I would say. It should not have been that way. After getting into the team, I saw that it is really encouraged that you should just apply to the team - but then write truthfully about yourself. What do you want? Write your passionate goal, why you want to be in the team.
+
+So even right now the shadow applications are open for the next release. I wanted to give that a small shoutout. If you want to contribute to the Kubernetes release team, please do apply. The form is pretty simple. You just need to say why do you want to contribute to the release team.
+
+**CRAIG BOX: What was your answer to that question?**
+
+NABARUN PAL: It was a bit tricky. I have this philosophy of contributing to projects that I use in my day-to-day life. I use a lot of open source projects daily, and I started contributing to Kubernetes primarily because I was using the Kubernetes Python client. That was one of my first contributions.
+
+When I was contributing to that, I explored the release team and it interested me a lot, particularly how interesting and varied the mechanics of releasing Kubernetes are. For most software projects, it's usually whenever you decide that you have made meaningful progress in terms of features, you release it. But Kubernetes is not like that. We follow a regular release cadence. And all those aspects really interested me. I actually applied for the first time in Kubernetes 1.16, but got rejected.
+
+But I still applied to Kubernetes 1.17, and I got into the enhancements team. That team was led by [MrBobbyTables, Bob Killen](https://kubernetespodcast.com/episode/126-research-steering-honking/), back then, and [Jeremy Rickard](https://kubernetespodcast.com/episode/131-kubernetes-1.20/) was one of my co-shadows in the team. I shadowed enhancements again. Then I lead enhancements in 1.19. I then shadowed the lead in 1.20 and eventually led the 1.21 team. That's what my journey has been.
+
+My suggestion to people is don't be afraid of failure. Even if you don't get selected, it's perfectly fine. You can still contribute to the release team. Just hop on the release calls, raise your hand, and introduce yourself.
+
+**CRAIG BOX: Between the 1.20 and 1.21 releases, you moved to work on the upstream contribution team at VMware. I've noticed that VMware is hiring a lot of great upstream contributors at the moment. Is this something that [Stephen Augustus](https://kubernetespodcast.com/episode/130-kubecon-na-2020/) had his fingerprints all over? Is there something in the water?**
+
+NABARUN PAL: A lot of people have fingerprints on this process. Stephen certainly had his fingerprints on it, I would say. We are expanding the team of upstream contributors primarily because the product that we are working for is based on Kubernetes. It helps us a lot in driving processes upstream and helping out the community as a whole, because everyone then gets enabled and benefits from what we contribute to the community.
+
+**CRAIG BOX: I understand that the Tanzu team is being built out in India at the moment, but I guess you probably haven't been able to meet them in person yet?**
+
+NABARUN PAL: Yes and no. I did not meet any of them after joining VMware, but I met a lot of my teammates, before I joined VMware, at KubeCons. For example, I met Nikhita, I met Dims, I met Stephen at KubeCon. I am yet to meet other members of the team and I'm really excited to catch up with them once everything comes out of lockdown and we go back to our normal lives.
+
+**CRAIG BOX: Yes, everyone that I speak to who has changed jobs in the pandemic says it's a very odd experience, just nothing really being different. And the same perhaps for people who are working on open source moving companies as well. They're doing the same thing, perhaps just for a different employer.**
+
+NABARUN PAL: As we say in the community, see you in another Slack in some time.
+
+**CRAIG BOX: We now turn to the recent release of Kubernetes 1.21. First of all, congratulations on that.**
+
+NABARUN PAL: Thank you.
+
+**CRAIG BOX: [The announcement](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/) says the release consists of 51 enhancements, 13 graduating to stable, 16 moving to beta, 20 entering alpha, and then two features that have been deprecated. How would you summarize this release?**
+
+NABARUN PAL: One of the big points for this release is that it is the largest release of all time.
+
+**CRAIG BOX: Really?**
+
+NABARUN PAL: Yep. 1.20 was the largest release back then, but 1.21 got more enhancements, primarily due to a lot of changes that we did to the process.
+
+In the 1.21 release cycle, we did a few things differently compared to other release cycles-- for example, in the enhancement process. An enhancement, in the Kubernetes context, is basically a feature proposal. You will hear the terminology [Kubernetes Enhancement Proposals](https://github.com/kubernetes/enhancements/blob/master/keps/README.md), or KEP, a lot in the community. An enhancement is a broad thing encapsulated in a specific document.
+
+**CRAIG BOX: I like to think of it as a thing that's worth having a heading in the release notes.**
+
+NABARUN PAL: Indeed. Until the 1.20 release cycle, what we used to do was-- the release team has a vertical called enhancements. The enhancements team members used to ping each of the enhancement issues and ask whether they want to be part of the release cycle or not. The authors would decide, or talk to their SIG, and then come back with the answer, as to whether they wanted to be part of the cycle.
+
+In this release, what we did was we eliminated that process and asked the SIGs proactively to discuss amongst themselves, what they wanted to pitch in for this release cycle. What set of features did they want to graduate this release? They may introduce things in alpha, graduate things to beta or stable, or they may also deprecate features.
+
+What this did was promote a lot of async processes, and at the same time, give power back to the community. The community decides what they want in the release and then comes back collectively. It also reduces a lot of stress on the release team who previously had to ask people consistently what they wanted to pitch in for the release. You now have a deadline. You discuss amongst your SIG what your roadmap is and what it looks like for the near future. Maybe this release, and the next two. And you put all of those answers into a Google spreadsheet. Spreadsheets are still a thing.
+
+**CRAIG BOX: The Kubernetes ecosystem runs entirely on Google Spreadsheets.**
+
+NABARUN PAL: It does, and a lot of Google Docs for meeting notes! We did a lot of process improvements, which essentially led to a better release. This release cycle we had 13 enhancements graduating to stable, 16 which moved to beta, and 20 enhancements which were net new features into the ecosystem, and came in as alpha.
+
+Along with that are features set for deprecation. One of them was PodSecurityPolicy. That has been a point of discussion in the Kubernetes user base and we also published [a blog post about it](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). All credit to SIG Security who have been on top of things as to find a replacement for PodSecurityPolicy even before this release cycle ended, so that they could at least have a proposal of what will happen next.
+
+**CRAIG BOX: Let's talk about some old things and some new things. You mentioned PodSecurityPolicy there. That's a thing that's been around a long time and is being deprecated. Two things that have been around a long time and that are now being promoted to stable are CronJobs and PodDisruptionBudgets, both of which were introduced in Kubernetes 1.4, which came out in 2016. Why do you think it took so long for them both to go stable?**
+
+NABARUN PAL: I might not have a definitive answer to your question. One of the things that I feel is they might be already so good that nobody saw that they were beta features, and just kept on using them.
+
+One of the things that I noticed when reading for the CronJobs graduation from beta to stable was the new controller. Users might not see this, but there has been a drastic change in the CronJob controller v2. What it essentially does is goes from a poll-based method of checking what users have defined as CronJobs to a queue architecture, which is the modern method of defining controllers. That has been one of the really good improvements in the case of CronJobs. Instead of the controller working in O(N) time, you now have constant time complexity.
+
+**CRAIG BOX: A lot of these features that have been in beta for a long time, like you say, people have an expectation that they are complete. With PodSecurityPolicy, it's being deprecated, which is allowed because it's a feature that never made it out of beta. But how do you think people will react to it going away? And does that say something about the need for the process to make sure that features don't just languish in beta forever, which has been introduced recently?**
+
+NABARUN PAL: That's true. One of the driving factors, when contributors are thinking of graduating beta features has been the ["prevention of perma-beta" KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/1635-prevent-permabeta/README.md). Back in 1.19 we [introduced this process](https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/) where each of the beta resources were marked for deprecation and removal in a certain time frame-- three releases for deprecation and another  release for removal. That's also a motivating factor for eventually rethinking as to how beta resources work for us in the community. That is also very effective, I would say.
+
+**CRAIG BOX: Do remember that Gmail was in beta for eight years.**
+
+NABARUN PAL: I did not know that!
+
+**CRAIG BOX: Nothing in Kubernetes is quite that old yet, but we'll get there. Of the 20 new enhancements, do you have a favorite or any that you'd like to call out?**
+
+NABARUN PAL: There are two specific features in 1.21 that I'm really interested in, and are coming as net new features. One of them is the [persistent volume health monitor](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor), which gives the users the capability to actually see whether the backing volumes, which power persistent volumes in Kubernetes, are deleted or not. For example, the volumes may get deleted due to an inadvertent event, or they may get corrupted. That information is basically surfaced out as a field so that the user can leverage it in any way.
+
+The other feature is the proposal for [adding headers with the command name to kubectl requests](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/859-kubectl-headers). We have always set the user-agent information when doing those kind of requests, but the proposal is to add what command the user put in so that we can enable more telemetry, and cluster administrators can determine the usage patterns of how people are using the cluster. I'm really excited about these kind of features coming into play.
+
+**CRAIG BOX: You're the first release lead from the Asia-Pacific region, or more accurately, outside of the US and Europe. Most meetings in the Kubernetes ecosystem are traditionally in the window of overlap between the US and Europe, in the morning in California and the evening here in the UK. What's it been like to work outside of the time zones that the community had previously been operating in?**
+
+NABARUN PAL: It has been a fun and a challenging proposition, I would say. In the last two-ish years that I have been contributing to Kubernetes, the community has also transformed from a lot of early morning Pacific calls to more towards async processes. For example, we in the release team have transformed our processes so we don't do updates in the calls anymore. What we do is ask for updates ahead of time, and then in the call, we just discuss things which need to be discussed synchronously in the team.
+
+We leverage the meetings right now more for discussions. But we also don't come to decisions in those discussions, because if any stakeholder is not present on the call, it puts them at a disadvantage. We are trying to talk more on Slack, publicly, or talk on mailing lists. That's where most of the discussion should happen, and also to gain lazy consensus. What I mean by lazy consensus is come up with a pre-decision kind of thing, but then also invite feedback from the broader community about what people would like them to see about that specific thing being discussed. This is where we as a community are also transforming a lot, but there is a lot more headroom to grow.
+
+The release team also started to have EU/APAC burndown meetings. In addition to having one meeting focused towards the US and European time zones, we also do a meeting which is more suited towards European and Asia-Pacific time zones. One of the driving factors for those decisions was that the release team is seeing a lot of participation from a variety of time zones. To give you one metric, we had release team members this cycle from UTC+8 all through UTC-8 - 16 hours of span. It's really difficult to accommodate all of those zones in a single meeting. And it's not just those 16 hours of span - what about the other eight hours?
+
+**CRAIG BOX: Yeah, you're missing New Zealand. You could add another 5 hours of span right there.**
+
+NABARUN PAL: Exactly. So we will always miss people in meetings, and that's why we should also innovate more, have different kinds of meetings. But that also may not be very sustainable in the future. Will people attend duplicate meetings? Will people follow both of the meetings? More meetings is one of the solutions.
+
+The other solution is you have threaded discussions on some medium, be it Slack or be it a mailing list. Then, people can just pitch in whenever it is work time for them. Then, at the end of the day, a 24-hour rolling period, you digest it, and then push it out as meeting notes. That's what the Contributor Experience Special Interest Group is doing - shout-out to them for moving to that process. I may be wrong here, but I think once every two weeks, they do async updates on Slack. And that is a really nice thing to have, improving variety of geographies that people can contribute from.
+
+**CRAIG BOX: Once you've put everything together that you hope to be in your release, you create a release candidate build. How do you motivate people to test those?**
+
+NABARUN PAL: That's a very interesting question. It is difficult for us to motivate people into trying out these candidates. It's mostly people who are passionate about Kubernetes who try out the release candidates and see for themselves what the bugs are. I remember [Dims tweeting out a call](https://twitter.com/dims/status/1377272238420934656) that if somebody tries out the release candidate and finds a good bug or caveat, they could get a callout in the KubeCon keynote. That's one of the incentives - if you want to be called out in a KubeCon keynote, please try our release candidates.
+
+**CRAIG BOX: Or get a new pair of Kubernetes socks?**
+
+NABARUN PAL: We would love to give out goodies to people who try out our release candidates and find bugs. For example, if you want the brand new release team logo as a sticker, just hit me up. If you find a bug in a 1.22 release candidate, I would love to be able to send you some coupon codes for the store. Don't quote me on this, but do reach out.
+
+**CRAIG BOX: Now the release is out, is it time for you to put your feet up? What more things do you have to do, and how do you feel about the path ahead for yourself?**
+
+NABARUN PAL: I was discussing this with the team yesterday. Even after the release, we had kind of a water-cooler conversation. I just pasted in a Zoom link to all the release team members and said, hey, do you want to chat? One of the things that I realized that I'm really missing is the daily burndowns right now. I will be around in the release team and the SIG Release meetings, helping out the new lead in transitioning. And even my job, right now, is not over. I'm working with Taylor, who is the emeritus advisor for 1.21, on figuring out some of the mechanics for the next release cycle. I'm also documenting what all we did as part of the process and as part of the process changes, and making sure the next release cycle is up and running.
+
+**CRAIG BOX: We've done a lot of these release lead interviews now, and there's a question which we always like to ask, which is, what will you write down in the transition envelope? Savitha Raghunathan is the release lead for 1.22. What is the advice that you will pass on to her?**
+
+NABARUN PAL: Three words-- **Do, Delegate, and Defer**. Categorize things into those three buckets as to what you should do right away, what you need to defer, and things that you can delegate to your shadows or other release team members. That's one of the mantras that works really well when leading a team. It is not just in the context of the release team, but it's in the context of managing any team.
+
+The other bit is **over-communicate**. No amount of communication is enough. What I've realized is the community is always willing to help you. One of the big examples that I can give is the day before release was supposed to happen, we were seeing a lot of test failures, and then one of the community members had an idea-- why don't you just send an email? I was like, "that sounds good. We can send an email mentioning all the flakes and call out for help to the broader Kubernetes developer community." And eventually, once we sent out the email, lots of people came in to help us in de-flaking the tests and trying to find out the root cause as to why those tests were failing so often. Big shout out to Antonio and all the SIG Network folks who came to pitch in.
+
+No matter how many names I mention, it will never be enough. A lot of people, even outside the release team, have helped us a lot with this release. And that's where the release theme comes in - **Power to the Community**. I'm really stoked by how this community behaves and how people are willing to help you all the time. It's not about what they're telling you to do, but it's what they're also interested in, they're passionate about.
+
+**CRAIG BOX: One of the things you're passionate about is Formula One. Do you think Lewis Hamilton is going to take it away this year?**
+
+NABARUN PAL: It's a fair probability that Lewis will win the title this year as well.
+
+**CRAIG BOX: Which would take him to eight all time career wins. And thus-- [he's currently tied with Michael Schumacher](https://www.nytimes.com/2020/11/15/sports/autoracing/lewis-hamilton-schumacher-formula-one-record.html)-- would pull him ahead.**
+
+NABARUN PAL: Yes. Michael Schumacher was my first favorite F1 driver, I would say. It feels a bit heartbreaking to see someone break Michael's record.
+
+**CRAIG BOX: How do you feel about [Michael Schumacher's son joining the contest?](https://www.formula1.com/en/latest/article.breaking-mick-schumacher-to-race-for-haas-in-2021-as-famous-surname-returns.66XTVfSt80GrZe91lvWVwJ.html)**
+
+NABARUN PAL: I feel good. Mick Schumacher is in the fray right now. And I wish we could see him, in a few years, in a Ferrari. The Schumacher family back to Ferrari would be really great to see. But then, my fan favorite has always been McLaren, partly because I like the chemistry of Lando and Carlos over the last two years. It was heartbreaking to see Carlos go to Ferrari. But then we have Lando and Daniel Ricciardo in the team. They're also fun people.
+
+---
+
+_[Nabarun Pal](https://twitter.com/theonlynabarun) is on the Tanzu team at VMware and served as the Kubernetes 1.21 release team lead._
+
+_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._
@@ -13,7 +13,7 @@ cid: community
 <div class="intro">
 <br class="mobile">
 <p>The Kubernetes community -- users, contributors, and the culture we've built together -- is one of the biggest reasons for the meteoric rise of this open source project. Our culture and values continue to grow and change as the project itself grows and changes. We all work together toward constant improvement of the project and the ways we work on it.
-<br><br>We are the people who file issues and pull requests, attend SIG meetings, Kubernetes meetups, and KubeCon, advocate for it's adoption and innovation, run <code>kubectl get pods</code>, and contribute in a thousand other vital ways. Read on to learn how you can get involved and become part of this amazing community.</p>
+<br><br>We are the people who file issues and pull requests, attend SIG meetings, Kubernetes meetups, and KubeCon, advocate for its adoption and innovation, run <code>kubectl get pods</code>, and contribute in a thousand other vital ways. Read on to learn how you can get involved and become part of this amazing community.</p>
 <br class="mobile">
 </div>

@@ -0,0 +1,164 @@
+---
+title: Garbage Collection
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+{{<glossary_definition term_id="garbage-collection" length="short">}} This
+allows the clean up of resources like the following:
+
+  * [Failed pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
+  * [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
+  * [Objects without owner references](#owners-dependents)
+  * [Unused containers and container images](#containers-images)
+  * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
+  * [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
+  * {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
+    * On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
+    * On-premises when the cluster uses an addon similar to a cloud controller
+      manager
+  * [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats)
+
+## Owners and dependents {#owners-dependents}
+
+Many objects in Kubernetes link to each other through [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/). 
+Owner references tell the control plane which objects are dependent on others.
+Kubernetes uses owner references to give the control plane, and other API
+clients, the opportunity to clean up related resources before deleting an
+object. In most cases, Kubernetes manages owner references automatically.
+
+Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
+mechanism that some resources also use. For example, consider a
+{{<glossary_tooltip text="Service" term_id="service">}} that creates
+`EndpointSlice` objects. The Service uses *labels* to allow the control plane to
+determine which `EndpointSlice` objects are used for that Service. In addition
+to the labels, each `EndpointSlice` that is managed on behalf of a Service has
+an owner reference. Owner references help different parts of Kubernetes avoid
+interfering with objects they don’t control.
+
+## Cascading deletion {#cascading-deletion}
+
+Kubernetes checks for and deletes objects that no longer have owner
+references, like the pods left behind when you delete a ReplicaSet. When you
+delete an object, you can control whether Kubernetes deletes the object's
+dependents automatically, in a process called *cascading deletion*. There are
+two types of cascading deletion, as follows: 
+
+  * Foreground cascading deletion
+  * Background cascading deletion
+
+You can also control how and when garbage collection deletes resources that have
+owner references using Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}. 
+
+### Foreground cascading deletion {#foreground-deletion}
+
+In foreground cascading deletion, the owner object you're deleting first enters
+a *deletion in progress* state. In this state, the following happens to the
+owner object: 
+
+  * The Kubernetes API server sets the object's `metadata.deletionTimestamp`
+    field to the time the object was marked for deletion.
+  * The Kubernetes API server also sets the `metadata.finalizers` field to
+    `foregroundDeletion`. 
+  * The object remains visible through the Kubernetes API until the deletion
+    process is complete.
+
+After the owner object enters the deletion in progress state, the controller
+deletes the dependents. After deleting all the dependent objects, the controller
+deletes the owner object. At this point, the object is no longer visible in the
+Kubernetes API. 
+
+During foreground cascading deletion, the only dependents that block owner
+deletion are those that have the `ownerReference.blockOwnerDeletion=true` field.
+See [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
+to learn more.
+
+### Background cascading deletion {#background-deletion}
+
+In background cascading deletion, the Kubernetes API server deletes the owner
+object immediately and the controller cleans up the dependent objects in
+the background. By default, Kubernetes uses background cascading deletion unless
+you manually use foreground deletion or choose to orphan the dependent objects.
+
+See [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
+to learn more.
+
+### Orphaned dependents
+
+When Kubernetes deletes an owner object, the dependents left behind are called
+*orphan* objects. By default, Kubernetes deletes dependent objects. To learn how
+to override this behaviour, see [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
+
+## Garbage collection of unused containers and images {#containers-images}
+
+The {{<glossary_tooltip text="kubelet" term_id="kubelet">}} performs garbage
+collection on unused images every five minutes and on unused containers every
+minute. You should avoid using external garbage collection tools, as these can
+break the kubelet behavior and remove containers that should exist. 
+
+To configure options for unused container and image garbage collection, tune the
+kubelet using a [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/)
+and change the parameters related to garbage collection using the
+[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
+resource type.
+
+### Container image lifecycle
+
+Kubernetes manages the lifecycle of all images through its *image manager*,
+which is part of the kubelet, with the cooperation of cadvisor. The kubelet
+considers the following disk usage limits when making garbage collection
+decisions:
+
+  * `HighThresholdPercent`
+  * `LowThresholdPercent`
+
+Disk usage above the configured `HighThresholdPercent` value triggers garbage
+collection, which deletes images in order based on the last time they were used,
+starting with the oldest first. The kubelet deletes images
+until disk usage reaches the `LowThresholdPercent` value.
+
+### Container image garbage collection {#container-image-garbage-collection}
+
+The kubelet garbage collects unused containers based on the following variables,
+which you can define: 
+
+  * `MinAge`: the minimum age at which the kubelet can garbage collect a
+    container. Disable by setting to `0`.
+  * `MaxPerPodContainer`: the maximum number of dead containers each Pod pair
+    can have. Disable by setting to less than `0`.
+  * `MaxContainers`: the maximum number of dead containers the cluster can have.
+    Disable by setting to less than `0`. 
+
+In addition to these variables, the kubelet garbage collects unidentified and
+deleted containers, typically starting with the oldest first. 
+
+`MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other
+in situations where retaining the maximum number of containers per Pod
+(`MaxPerPodContainer`) would go outside the allowable total of global dead
+containers (`MaxContainers`). In this situation, the kubelet adjusts
+`MaxPodPerContainer` to address the conflict. A worst-case scenario would be to
+downgrade `MaxPerPodContainer` to `1` and evict the oldest containers.
+Additionally, containers owned by pods that have been deleted are removed once
+they are older than `MinAge`.
+
+{{<note>}}
+The kubelet only garbage collects the containers it manages.
+{{</note>}}
+
+## Configuring garbage collection {#configuring-gc}
+
+You can tune garbage collection of resources by configuring options specific to
+the controllers managing those resources. The following pages show you how to
+configure garbage collection:
+
+  * [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/)
+  * [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
+  
+<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
+
+## {{% heading "whatsnext" %}}
+
+* Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).
+* Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
+* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.
@@ -412,6 +412,10 @@ poorly-behaved workloads that may be harming system health.
  queue) requests, broken down by the labels `priority_level` and
  `flow_schema`.

+* `apiserver_flowcontrol_request_concurrency_in_use` is a gauge vector
+  holding the instantaneous number of occupied seats, broken down by
+  the labels `priority_level` and `flow_schema`.
+
 * `apiserver_flowcontrol_priority_level_request_count_samples` is a
  histogram vector of observations of the then-current number of
  requests broken down by the labels `phase` (which takes on the
@@ -1,98 +0,0 @@
---
-title: Garbage collection for container images
-content_type: concept
-weight: 70
---
-
-<!-- overview -->
-
-Garbage collection is a helpful function of kubelet that will clean up unused
-[images](/docs/concepts/containers/#container-images) and unused
-[containers](/docs/concepts/containers/). Kubelet will perform garbage collection
-for containers every minute and garbage collection for images every five minutes.
-
-External garbage collection tools are not recommended as these tools can potentially
-break the behavior of kubelet by removing containers expected to exist.
-
-<!-- body -->
-
-## Image Collection
-
-Kubernetes manages lifecycle of all images through imageManager, with the cooperation
-of cadvisor.
-
-The policy for garbage collecting images takes two factors into consideration:
-`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold
-will trigger garbage collection. The garbage collection will delete least recently used images until the low
-threshold has been met.
-
-## Container Collection
-
-The policy for garbage collecting containers considers three user-defined variables.
-`MinAge` is the minimum age at which a container can be garbage collected.
-`MaxPerPodContainer` is the maximum number of dead containers every single
-pod (UID, container name) pair is allowed to have.
-`MaxContainers` is the maximum number of total dead containers.
-These variables can be individually disabled by setting `MinAge` to zero and
-setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero.
-
-Kubelet will act on containers that are unidentified, deleted, or outside of
-the boundaries set by the previously mentioned flags. The oldest containers
-will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may
-potentially conflict with each other in situations where retaining the maximum
-number of containers per pod (`MaxPerPodContainer`) would go outside the
-allowable range of global dead containers (`MaxContainers`).
-`MaxPerPodContainer` would be adjusted in this situation: A worst case
-scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest
-containers. Additionally, containers owned by pods that have been deleted are
-removed once they are older than `MinAge`.
-
-Containers that are not managed by kubelet are not subject to container garbage collection.
-
-## User Configuration
-
-You can adjust the following thresholds to tune image garbage collection with the following kubelet flags :
-
-1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection.
-   Default is 85%.
-2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts
-   to free. Default is 80%.
-
-You can customize the garbage collection policy through the following kubelet flags:
-
-1. `minimum-container-ttl-duration`, minimum age for a finished container before it is
-   garbage collected. Default is 0 minute, which means every finished container will be garbage collected.
-2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained
-   per container. Default is 1.
-3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally.
-   Default is -1, which means there is no global limit.
-
-Containers can potentially be garbage collected before their usefulness has expired. These containers
-can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for
-`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be
-retained per expected container. A larger value for `maximum-dead-containers` is also recommended for a
-similar reason.
-See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details.
-
-
-## Deprecation
-
-Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future.
-
-Including:
-
-| Existing Flag | New Flag | Rationale |
-| ------------- | -------- | --------- |
-| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
-| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
-| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
-| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
-| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
-| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
-| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |
-
-## {{% heading "whatsnext" %}}
-
-See [Configuring Out Of Resource Handling](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
-for more details.
-
@@ -115,7 +115,7 @@ CPU is always requested as an absolute quantity, never as a relative quantity;

 Limits and requests for `memory` are measured in bytes. You can express memory as
 a plain integer or as a fixed-point number using one of these suffixes:
-E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
+E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
 Mi, Ki. For example, the following represent roughly the same value:

 ```shell
@@ -12,26 +12,33 @@ weight: 30

 <!-- overview -->

-Kubernetes Secrets let you store and manage sensitive information, such
-as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret
-is safer and more flexible than putting it verbatim in a
-{{< glossary_tooltip term_id="pod" >}} definition or in a
-{{< glossary_tooltip text="container image" term_id="image" >}}.
-See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
-
 A Secret is an object that contains a small amount of sensitive data such as
 a password, a token, or a key. Such information might otherwise be put in a
-Pod specification or in an image. Users can create Secrets and the system
-also creates some Secrets.
+{{< glossary_tooltip term_id="pod" >}} specification or in a
+{{< glossary_tooltip text="container image" term_id="image" >}}. Using a
+Secret means that you don't need to include confidential data in your
+application code.
+
+Because Secrets can be created independently of the Pods that use them, there
+is less risk of the Secret (and its data) being exposed during the workflow of
+creating, viewing, and editing Pods. Kubernetes, and applications that run in
+your cluster, can also take additional precautions with Secrets, such as
+avoiding writing confidential data to nonvolatile storage.
+
+Secrets are similar to {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}
+but are specifically intended to hold confidential data.

 {{< caution >}}
-Kubernetes Secrets are, by default, stored as unencrypted base64-encoded
-strings. By default they can be retrieved - as plain text - by anyone with API
-access, or anyone with access to Kubernetes' underlying data store, etcd. In
-order to safely use Secrets, it is recommended you (at a minimum):
+Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd.
+Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.
+
+In order to safely use Secrets, take at least the following steps:

 1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets.
-2. [Enable or configure RBAC rules](/docs/reference/access-authn-authz/authorization/) that restrict reading and writing the Secret. Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod.
+2. Enable or configure [RBAC rules](/docs/reference/access-authn-authz/authorization/) that
+   restrict reading data in Secrets (including via indirect means).
+3. Where appropriate, also use mechanisms such as RBAC to limit which principals are allowed to create new Secrets or replace existing ones.
+
 {{< /caution >}}

 <!-- body -->
@@ -47,6 +54,10 @@ A Secret can be used with a Pod in three ways:
 - As [container environment variable](#using-secrets-as-environment-variables).
 - By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.

+The Kubernetes control plane also uses Secrets; for example,
+[bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to
+help automate node registration.
+
 The name of a Secret object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 You can specify the `data` and/or the `stringData` field when creating a
@@ -407,9 +418,9 @@ stringData:

 There are several options to create a Secret:

- [create Secrets using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [create Secrets from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [create Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)

 ## Editing a Secret

@@ -1164,7 +1175,7 @@ limit access using [authorization policies](
 Secrets often hold values that span a spectrum of importance, many of which can
 cause escalations within Kubernetes (e.g. service account tokens) and to
 external systems. Even if an individual app can reason about the power of the
-secrets it expects to interact with, other apps within the same namespace can
+Secrets it expects to interact with, other apps within the same namespace can
 render those assumptions invalid.

 For these reasons `watch` and `list` requests for secrets within a namespace are
@@ -1236,10 +1247,8 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa
   if the API server policy does not allow that user to read the Secret, the user could
   run a Pod which exposes the secret.

-
 ## {{% heading "whatsnext" %}}

- Learn how to [manage Secrets using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
-
+- Learn how to [manage Secret using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
@@ -330,4 +330,5 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.

 ## {{% heading "whatsnext" %}}

-* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
+* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md).
+* Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection).
@@ -118,7 +118,7 @@ Runtime handlers are configured through containerd's configuration at
 `/etc/containerd/config.toml`. Valid handlers are configured under the runtimes section:

 ```
-[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
 ```

 See containerd's config documentation for more details:
@@ -45,7 +45,7 @@ Containers have become popular because they provide extra benefits, such as:
 * Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use.
 * Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and efficient rollbacks (due to image immutability).
 * Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure.
-* Observability not only surfaces OS-level information and metrics, but also application health and other signals.
+* Observability: not only surfaces OS-level information and metrics, but also application health and other signals.
 * Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud.
 * Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-premises, on major public clouds, and anywhere else.
 * Application-centric management: Raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources.
@@ -30,6 +30,11 @@ Annotations, like labels, are key/value maps:
 }
 ```

+{{<note>}}
+The keys and the values in the map must be strings. In other words, you cannot use
+numeric, boolean, list or other types for either the keys or the values.
+{{</note>}}
+
 Here are some examples of information that could be recorded in annotations:

 * Fields managed by a declarative configuration layer. Attaching these fields
@@ -0,0 +1,80 @@
+---
+title: Finalizers
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+{{<glossary_definition term_id="finalizer" length="long">}}
+
+You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
+of resources by alerting {{<glossary_tooltip text="controllers" term_id="controller">}} to perform specific cleanup tasks before
+deleting the target resource. 
+
+Finalizers don't usually specify the code to execute. Instead, they are
+typically lists of keys on a specific resource similar to annotations.
+Kubernetes specifies some finalizers automatically, but you can also specify
+your own.
+
+## How finalizers work
+
+When you create a resource using a manifest file, you can specify finalizers in
+the `metadata.finalizers` field. When you attempt to delete the resource, the
+controller that manages it notices the values in the `finalizers` field and does
+the following: 
+
+  * Modifies the object to add a `metadata.deletionTimestamp` field with the
+    time you started the deletion.
+  * Marks the object as read-only until its `metadata.finalizers` field is empty.
+
+The controller then attempts to satisfy the requirements of the finalizers
+specified for that resource. Each time a finalizer condition is satisfied, the
+controller removes that key from the resource's `finalizers` field. When the
+field is empty, garbage collection continues. You can also use finalizers to
+prevent deletion of unmanaged resources.
+
+A common example of a finalizer is `kubernetes.io/pv-protection`, which prevents
+accidental deletion of `PersistentVolume` objects. When a `PersistentVolume`
+object is in use by a Pod, Kubernetes adds the `pv-protection` finalizer. If you
+try to delete the `PersistentVolume`, it enters a `Terminating` status, but the
+controller can't delete it because the finalizer exists. When the Pod stops
+using the `PersistentVolume`, Kubernetes clears the `pv-protection` finalizer,
+and the controller deletes the volume.
+
+## Owner references, labels, and finalizers {#owners-labels-finalizers}
+
+Like {{<glossary_tooltip text="labels" term_id="label">}}, [owner references](/concepts/overview/working-with-objects/owners-dependents/)
+describe the relationships between objects in Kubernetes, but are used for a
+different purpose. When a
+{{<glossary_tooltip text="controllers" term_id="controller">}} manages objects
+like Pods, it uses labels to track changes to groups of related objects. For
+example, when a {{<glossary_tooltip text="Job" term_id="job">}} creates one or
+more Pods, the Job controller applies labels to those pods and tracks changes to
+any Pods in the cluster with the same label.
+
+The Job controller also adds *owner references* to those Pods, pointing at the
+Job that created the Pods. If you delete the Job while these Pods are running,
+Kubernetes uses the owner references (not labels) to determine which Pods in the
+cluster need cleanup.
+
+Kubernetes also processes finalizers when it identifies owner references on a
+resource targeted for deletion. 
+
+In some situations, finalizers can block the deletion of dependent objects,
+which can cause the targeted owner object to remain in a read-only state for
+longer than expected without being fully deleted. In these situations, you
+should check finalizers and owner references on the target owner and dependent
+objects to troubleshoot the cause. 
+
+{{<note>}}
+In cases where objects are stuck in a deleting state, try to avoid manually
+removing finalizers to allow deletion to continue. Finalizers are usually added
+to resources for a reason, so forcefully removing them can lead to issues in
+your cluster. 
+{{</note>}}
+
+## {{% heading "whatsnext" %}}
+
+* Read [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/)
+  on the Kubernetes blog.
@@ -42,7 +42,7 @@ Example labels:
   * `"partition" : "customerA"`, `"partition" : "customerB"`
   * `"track" : "daily"`, `"track" : "weekly"`

-These are examples of commonly used labels; you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
+These are examples of [commonly used labels](/docs/concepts/overview/working-with-objects/common-labels/); you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.

 ## Syntax and character set

@@ -50,7 +50,7 @@ _Labels_ are key/value pairs. Valid label keys have two segments: an optional pr

 If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix.

-The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.
+The `kubernetes.io/` and `k8s.io/` prefixes are [reserved](/docs/reference/labels-annotations-taints/) for Kubernetes core components.

 Valid label value:
 * must be 63 characters or less (can be empty),
@@ -28,7 +28,7 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/conc
 In cases when objects represent a physical entity, like a Node representing a physical host, when the host is re-created under the same name without deleting and re-creating the Node, Kubernetes treats the new host as the old one, which may lead to inconsistencies.
 {{< /note >}}

-Below are three types of commonly used name constraints for resources.
+Below are four types of commonly used name constraints for resources.

 ### DNS Subdomain Names

@@ -41,7 +41,7 @@ This means the name must:
 - start with an alphanumeric character
 - end with an alphanumeric character

-### DNS Label Names
+### RFC 1123 Label Names {#dns-label-names}

 Some resource types require their names to follow the DNS
 label standard as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).
@@ -52,6 +52,17 @@ This means the name must:
 - start with an alphanumeric character
 - end with an alphanumeric character

+### RFC 1035 Label Names
+
+Some resource types require their names to follow the DNS
+label standard as defined in [RFC 1035](https://tools.ietf.org/html/rfc1035).
+This means the name must:
+
+- contain at most 63 characters
+- contain only lowercase alphanumeric characters or '-'
+- start with an alphabetic character
+- end with an alphanumeric character
+
 ### Path Segment Names

 Some resource types require their names to be able to be safely encoded as a
@@ -0,0 +1,71 @@
+---
+title: Owners and Dependents
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+
+In Kubernetes, some objects are *owners* of other objects. For example, a
+{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner of a set of Pods. These owned objects are *dependents*
+of their owner. 
+
+Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
+mechanism that some resources also use. For example, consider a Service that 
+creates `EndpointSlice` objects. The Service uses labels to allow the control plane to
+determine which `EndpointSlice` objects are used for that Service. In addition
+to the labels, each `EndpointSlice` that is managed on behalf of a Service has
+an owner reference. Owner references help different parts of Kubernetes avoid
+interfering with objects they don’t control. 
+
+## Owner references in object specifications
+
+Dependent objects have a `metadata.ownerReferences` field that references their
+owner object. A valid owner reference consists of the object name and a UID
+within the same namespace as the dependent object. Kubernetes sets the value of
+this field automatically for objects that are dependents of other objects like
+ReplicaSets, DaemonSets, Deployments, Jobs and CronJobs, and ReplicationControllers.
+You can also configure these relationships manually by changing the value of
+this field. However, you usually don't need to and can allow Kubernetes to
+automatically manage the relationships.
+
+Dependent objects also have an `ownerReferences.blockOwnerDeletion` field that
+takes a boolean value and controls whether specific dependents can block garbage
+collection from deleting their owner object. Kubernetes automatically sets this
+field to `true` if a {{<glossary_tooltip text="controller" term_id="controller">}} 
+(for example, the Deployment controller) sets the value of the
+`metadata.ownerReferences` field. You can also set the value of the
+`blockOwnerDeletion` field manually to control which dependents block garbage
+collection.
+
+A Kubernetes admission controller controls user access to change this field for
+dependent resources, based on the delete permissions of the owner. This control
+prevents unauthorized users from delaying owner object deletion.
+
+## Ownership and finalizers
+
+When you tell Kubernetes to delete a resource, the API server allows the
+managing controller to process any [finalizer rules](/docs/concepts/overview/working-with-objects/finalizers/)
+for the resource. {{<glossary_tooltip text="Finalizers" term_id="finalizer">}}
+prevent accidental deletion of resources your cluster may still need to function
+correctly. For example, if you try to delete a `PersistentVolume` that is still
+in use by a Pod, the deletion does not happen immediately because the
+`PersistentVolume` has the `kubernetes.io/pv-protection` finalizer on it.
+Instead, the volume remains in the `Terminating` status until Kubernetes clears
+the finalizer, which only happens after the `PersistentVolume` is no longer
+bound to a Pod. 
+
+Kubernetes also adds finalizers to an owner resource when you use either
+[foreground or orphan cascading deletion](/docs/concepts/architecture/garbage-collection/#cascading-deletion).
+In foreground deletion, it adds the `foreground` finalizer so that the
+controller must delete dependent resources that also have
+`ownerReferences.blockOwnerDeletion=true` before it deletes the owner. If you
+specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so
+that the controller ignores dependent resources after it deletes the owner
+object. 
+
+## {{% heading "whatsnext" %}}
+
+* Learn more about [Kubernetes finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
+* Learn about [garbage collection](/docs/concepts/architecture/garbage-collection).
+* Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System).
@@ -353,7 +353,7 @@ the removal of the lowest priority Pods is not sufficient to allow the scheduler
 to schedule the preemptor Pod, or if the lowest priority Pods are protected by
 `PodDisruptionBudget`.

-The kubelet uses Priority to determine pod order for [out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/).
+The kubelet uses Priority to determine pod order for [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
 You can use the QoS class to estimate the order in which pods are most likely
 to get evicted. The kubelet ranks pods for eviction based on the following factors:

@@ -361,10 +361,10 @@ to get evicted. The kubelet ranks pods for eviction based on the following facto
  1. Pod Priority
  1. Amount of resource usage relative to requests 

-See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
+See [Pod selection for kubelet eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)
 for more details.

-kubelet out-of-resource eviction does not evict Pods when their
+kubelet node-pressure eviction does not evict Pods when their
 usage does not exceed their requests. If a Pod with lower priority is not
 exceeding its requests, it won't be evicted. Another Pod with higher priority
 that exceeds its requests may be evicted.
@@ -8,7 +8,7 @@ weight: 90

 <!-- overview -->

-{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.19" state="stable" >}}

 The scheduling framework is a pluggable architecture for the Kubernetes scheduler.
 It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled into the scheduler. The APIs allow most scheduling features to be implemented as plugins, while keeping the
@@ -267,7 +267,7 @@ This ensures that DaemonSet pods are never evicted due to these problems.
 ## Taint Nodes by Condition

 The control plane, using the node {{<glossary_tooltip text="controller" term_id="controller">}},
-automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/pod-eviction#node-conditions).
+automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions).

 The scheduler checks taints, not node conditions, when it makes scheduling
 decisions. This ensures that node conditions don't directly affect scheduling.
@@ -298,7 +298,7 @@ arbitrary tolerations to DaemonSets.

 ## {{% heading "whatsnext" %}}

-* Read about [out of resource handling](/docs/concepts/scheduling-eviction/out-of-resource/) and how you can configure it
-* Read about [pod priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+* Read about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) and how you can configure it
+* Read about [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)


@@ -32,6 +32,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
  Citrix Application Delivery Controller.
 * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller.
 * [EnRoute](https://getenroute.io/) is an [Envoy](https://www.envoyproxy.io) based API gateway that can run as an ingress controller.
+* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md) is an [Easegress](https://megaease.com/easegress/) based API gateway that can run as an ingress controller.
 * F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)
  lets you use an Ingress to configure F5 BIG-IP virtual servers.
 * [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io),
@@ -255,7 +255,7 @@ The above rule allows any Pod with label `db` on the namespace `default` to comm

 The following restrictions apply when using this field:
 * As an alpha feature, this is disabled by default. To enable the `endPort` field at a cluster level, you (or your cluster administrator) need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=NetworkPolicyEndPort=true,…`.
-* The `endPort` field must be equal than or greater to the `port` field.
+* The `endPort` field must be equal to or greater than the `port` field.
 * `endPort` can only be defined if `port` is also defined.
 * Both ports must be numeric.

@@ -72,7 +72,7 @@ A Service in Kubernetes is a REST object, similar to a Pod.  Like all of the
 REST objects, you can `POST` a Service definition to the API server to create
 a new instance.
 The name of a Service object must be a valid
-[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names).
+[RFC 1035 label name](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names).

 For example, suppose you have a set of Pods where each listens on TCP port 9376
 and contains a label `app=MyApp`:
@@ -188,7 +188,7 @@ selectors and uses DNS names instead. For more information, see the
 [ExternalName](#externalname) section later in this document.

 ### Over Capacity Endpoints
-If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.21 (or later)
+If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.21
 cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: warning`.
 This annotation indicates that the affected Endpoints object is over capacity.

@@ -76,7 +76,7 @@ for provisioning PVs. This field must be specified.
 | Glusterfs            | &#x2713;            | [Glusterfs](#glusterfs)              |
 | iSCSI                | -                   | -                                    |
 | Quobyte              | &#x2713;            | [Quobyte](#quobyte)                  |
-| NFS                  | -                   | -                                    |
+| NFS                  | -                   | [NFS](#nfs)       |
 | RBD                  | &#x2713;            | [Ceph RBD](#ceph-rbd)                |
 | VsphereVolume        | &#x2713;            | [vSphere](#vsphere)                  |
 | PortworxVolume       | &#x2713;            | [Portworx Volume](#portworx-volume)  |
@@ -423,6 +423,29 @@ parameters:
    `gluster-dynamic-<claimname>`. The dynamic endpoint and service are automatically
    deleted when the persistent volume claim is deleted.

+### NFS
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: example-nfs
+provisioner: example.com/external-nfs
+parameters:
+  server: nfs-server.example.com
+  path: /share
+  readOnly: false
+```
+
+* `server`: Server is the hostname or IP address of the NFS server.
+* `path`: Path that is exported by the NFS server.
+* `readOnly`: A flag indicating whether the storage will be mounted as read only (default false).
+
+Kubernetes doesn't include an internal NFS provisioner. You need to use an external provisioner to create a StorageClass for NFS.
+Here are some examples:
+* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
+* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
+
 ### OpenStack Cinder

 ```yaml
@@ -230,6 +230,8 @@ storage servers).
 Use a Deployment for stateless services, like frontends, where scaling up and down the
 number of replicas and rolling out updates are more important than controlling exactly which host
 the Pod runs on.  Use a DaemonSet when it is important that a copy of a Pod always run on
-all or certain hosts, and when it needs to start before other Pods.
+all or certain hosts, if the DaemonSet provides node-level functionality that allows other Pods to run correctly on that particular node.
+
+For example, [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) often include a component that runs as a DaemonSet. The DaemonSet component makes sure that the node where it's running has working cluster networking.


@@ -1,184 +0,0 @@
---
-title: Garbage Collection
-content_type: concept
-weight: 60
---
-
-<!-- overview -->
-
-The role of the Kubernetes garbage collector is to delete certain objects
-that once had an owner, but no longer have an owner.
-
-
-<!-- body -->
-
-## Owners and dependents
-
-Some Kubernetes objects are owners of other objects. For example, a ReplicaSet
-is the owner of a set of Pods. The owned objects are called *dependents* of the
-owner object. Every dependent object has a `metadata.ownerReferences` field that
-points to the owning object.
-
-Sometimes, Kubernetes sets the value of `ownerReference` automatically. For
-example, when you create a ReplicaSet, Kubernetes automatically sets the
-`ownerReference` field of each Pod in the ReplicaSet. In 1.8, Kubernetes
-automatically sets the value of `ownerReference` for objects created or adopted
-by ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job
-and CronJob.
-
-You can also specify relationships between owners and dependents by manually
-setting the `ownerReference` field.
-
-Here's a configuration file for a ReplicaSet that has three Pods:
-
-{{< codenew file="controllers/replicaset.yaml" >}}
-
-If you create the ReplicaSet and then view the Pod metadata, you can see
-OwnerReferences field:
-
-```shell
-kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
-kubectl get pods --output=yaml
-```
-
-The output shows that the Pod owner is a ReplicaSet named `my-repset`:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  ...
-  ownerReferences:
-  - apiVersion: apps/v1
-    controller: true
-    blockOwnerDeletion: true
-    kind: ReplicaSet
-    name: my-repset
-    uid: d9607e19-f88f-11e6-a518-42010a800195
-  ...
-```
-
-{{< note >}}
-Cross-namespace owner references are disallowed by design.
-
-Namespaced dependents can specify cluster-scoped or namespaced owners.
-A namespaced owner **must** exist in the same namespace as the dependent.
-If it does not, the owner reference is treated as absent, and the dependent
-is subject to deletion once all owners are verified absent.
-
-Cluster-scoped dependents can only specify cluster-scoped owners.
-In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner,
-it is treated as having an unresolvable owner reference, and is not able to be garbage collected.
-
-In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`,
-or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event 
-with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported.
-You can check for that kind of Event by running
-`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
-{{< /note >}}
-
-## Controlling how the garbage collector deletes dependents
-
-When you delete an object, you can specify whether the object's dependents are
-also deleted automatically. Deleting dependents automatically is called *cascading
-deletion*.  There are two modes of *cascading deletion*: *background* and *foreground*.
-
-If you delete an object without deleting its dependents
-automatically, the dependents are said to be *orphaned*.
-
-### Foreground cascading deletion
-
-In *foreground cascading deletion*, the root object first
-enters a "deletion in progress" state. In the "deletion in progress" state,
-the following things are true:
-
- * The object is still visible via the REST API
- * The object's `deletionTimestamp` is set
- * The object's `metadata.finalizers` contains the value "foregroundDeletion".
-
-Once the "deletion in progress" state is set, the garbage
-collector deletes the object's dependents. Once the garbage collector has deleted all
-"blocking" dependents (objects with `ownerReference.blockOwnerDeletion=true`), it deletes
-the owner object.
-
-Note that in the "foregroundDeletion", only dependents with
-`ownerReference.blockOwnerDeletion=true` block the deletion of the owner object.
-Kubernetes version 1.7 added an [admission controller](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) that controls user access to set
-`blockOwnerDeletion` to true based on delete permissions on the owner object, so that
-unauthorized dependents cannot delay deletion of an owner object.
-
-If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet),
-blockOwnerDeletion is set automatically and you do not need to manually modify this field.
-
-### Background cascading deletion
-
-In *background cascading deletion*, Kubernetes deletes the owner object
-immediately and the garbage collector then deletes the dependents in
-the background.
-
-### Setting the cascading deletion policy
-
-To control the cascading deletion policy, set the `propagationPolicy`
-field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan",
-"Foreground", or "Background".
-
-Here's an example that deletes dependents in background:
-
-```shell
-kubectl proxy --port=8080
-curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-  -H "Content-Type: application/json"
-```
-
-Here's an example that deletes dependents in foreground:
-
-```shell
-kubectl proxy --port=8080
-curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-  -H "Content-Type: application/json"
-```
-
-Here's an example that orphans dependents:
-
-```shell
-kubectl proxy --port=8080
-curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-  -H "Content-Type: application/json"
-```
-
-kubectl also supports cascading deletion.
-
-To delete dependents in the foreground using kubectl, set `--cascade=foreground`.  To
-orphan dependents, set `--cascade=orphan`. 
-
-The default behavior is to delete the dependents in the background which is the
-behavior when `--cascade` is omitted or explicitly set to `background`.
-
-Here's an example that orphans the dependents of a ReplicaSet:
-
-```shell
-kubectl delete replicaset my-repset --cascade=orphan
-```
-
-### Additional note on Deployments
-
-Prior to 1.7, When using cascading deletes with Deployments you *must* use `propagationPolicy: Foreground`
-to delete not only the ReplicaSets created, but also their Pods. If this type of _propagationPolicy_
-is not used, only the ReplicaSets will be deleted, and the Pods will be orphaned.
-See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) for more information.
-
-## Known issues
-
-Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
-
-[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
@@ -255,7 +255,8 @@ from failed Jobs is not lost inadvertently.

 ## Job termination and cleanup

-When a Job completes, no more Pods are created, but the Pods are not deleted either.  Keeping them around
+When a Job completes, no more Pods are created, but the Pods are [usually](#pod-backoff-failure-policy) not deleted either.
+Keeping them around
 allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
 The job object also remains after it is completed so that you can view its status.  It is up to the user to delete
 old jobs after noting their status.  Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
@@ -282,6 +282,17 @@ on the Kubernetes API server for each static Pod.
 This means that the Pods running on a node are visible on the API server,
 but cannot be controlled from there.

+## Container probes
+
+A _probe_ is a diagnostic performed periodically by the kubelet on a container. To perform a diagnostic, the kubelet can invoke different actions:
+
+- `ExecAction` (performed with the help of the container runtime)
+- `TCPSocketAction` (checked directly by the kubelet)
+- `HTTPGetAction` (checked directly by the kubelet)
+
+You can read more about [probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) 
+in the Pod Lifecycle documentation.
+
 ## {{% heading "whatsnext" %}}

 * Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
@@ -31,7 +31,7 @@ an application.  Examples are:
 - cloud provider or hypervisor failure makes VM disappear
 - a kernel panic
 - the node disappears from the cluster due to cluster network partition
- eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource/).
+- eviction of a pod due to the node being [out-of-resources](/docs/concepts/scheduling-eviction/node-pressure-eviction/).

 Except for the out-of-resources condition, all these conditions
 should be familiar to most users; they are not specific
@@ -291,7 +291,8 @@ Given the ordering and execution for init containers, the following rules
 for resource usage apply:

 * The highest of any particular resource request or limit defined on all init
-  containers is the *effective init request/limit*
+  containers is the *effective init request/limit*. If any resource has no
+  resource limit specified this is considered as the highest limit.
 * The Pod's *effective request/limit* for a resource is the higher of:
  * the sum of all app containers request/limit for a resource
  * the effective init request/limit for a resource
@@ -311,7 +311,7 @@ is different from the liveness probe.

 If your app has a strict dependency on back-end services, you can implement both
 a liveness and a readiness probe. The liveness probe passes when the app itself
-is healthy, but the readiness problem additionally checks that each required
+is healthy, but the readiness probe additionally checks that each required
 back-end service is available. This helps you avoid directing traffic to Pods
 that can only respond with error messages.

@@ -379,7 +379,7 @@ An example flow:
   as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
   shutdown process.
   1. If one of the Pod's containers has defined a `preStop`
-      [hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet
+      [hook](/docs/concepts/containers/container-lifecycle-hooks), the kubelet
      runs that hook inside of the container. If the `preStop` hook is still running after the
      grace period expires, the kubelet requests a small, one-off grace period extension of 2
      seconds.
@@ -6,7 +6,7 @@ weight: 40

 <!-- overview -->

-This page shows how to use the `update-imported-docs` script to generate
+This page shows how to use the `update-imported-docs.py` script to generate
 the Kubernetes reference documentation. The script automates
 the build setup and generates the reference documentation for a release.

@@ -39,7 +39,7 @@ see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contrib

 ## Overview of update-imported-docs

-The `update-imported-docs` script is located in the `<web-base>/update-imported-docs/`
+The `update-imported-docs.py` script is located in the `<web-base>/update-imported-docs/`
 directory.

 The script builds the following references:
@@ -48,7 +48,7 @@ The script builds the following references:
 * The `kubectl` command reference
 * The Kubernetes API reference

-The `update-imported-docs` script generates the Kubernetes reference documentation
+The `update-imported-docs.py` 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.
@@ -69,7 +69,7 @@ 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:
+The `update-imported-docs.py` 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
@@ -152,17 +152,17 @@ For example:

 ## Running the update-imported-docs tool

-You can run the `update-imported-docs` tool as follows:
+You can run the `update-imported-docs.py` tool as follows:

 ```shell
 cd <web-base>/update-imported-docs
-./update-imported-docs <configuration-file.yml> <release-version>
+./update-imported-docs.py <configuration-file.yml> <release-version>
 ```

 For example:

 ```shell
-./update-imported-docs reference.yml 1.17
+./update-imported-docs.py reference.yml 1.17
 ```

 <!-- Revisit: is the release configuration used -->
@@ -254,4 +254,3 @@ running the build targets, see the following guides:
 * [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/)

-
@@ -39,7 +39,7 @@ client libraries:
 - [Kubernetes Java client library](https://github.com/kubernetes-client/java)
 - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
 - [Kubernetes C# client library](https://github.com/kubernetes-client/csharp)
- [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell)
+- [Kubernetes Haskell client library](https://github.com/kubernetes-client/haskell)

 ## CLI

@@ -3,6 +3,7 @@ reviewers:
 - liggitt
 - mikedanese
 - munnerz
+- enj
 title: Certificate Signing Requests
 content_type: concept
 weight: 20
@@ -56,7 +57,9 @@ state for some duration:

 * Approved requests: automatically deleted after 1 hour
 * Denied requests: automatically deleted after 1 hour
+* Failed requests: automatically deleted after 1 hour
 * Pending requests: automatically deleted after 24 hours
+* All requests: automatically deleted after the issued certificate has expired

 ## Signers

@@ -64,12 +67,11 @@ Custom signerNames can also be specified. All signers should provide information
 This includes:

 1. **Trust distribution**: how trust (CA bundles) are distributed.
-1. **Permitted subjects**: any restrictions on and behavior when a disallowed subject is requested.
-1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and behavior when a disallowed extension is requested.
-1. **Permitted key usages / extended key usages**: any restrictions on and behavior when usages different than the signer-determined usages are specified in the CSR.
-1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc
-   and the behavior when an expiration is different than the signer-determined expiration that is specified in the CSR.
-1. **CA bit allowed/disallowed**: and behavior if a CSR contains a request a for a CA certificate when the signer does not permit it.
+1. **Permitted subjects**: any restrictions on requested subjects, and the behavior when a disallowed subject is requested.
+1. **Permitted x509 extensions**: including IP subjectAltNames, DNS subjectAltNames, Email subjectAltNames, URI subjectAltNames etc, and the behavior when a disallowed extension is requested.
+1. **Permitted key usages / extended key usages**: any restrictions on requested usages, and the behavior when usages different than the signer-determined usages are specified in the CSR.
+1. **Expiration/certificate lifetime**: whether it is fixed by the signer, configurable by the admin, determined by the CSR object etc, and the behavior when an expiration different than the signer-determined expiration is specified in the CSR.
+1. **CA bit allowed/disallowed**: the behavior if a CSR contains a request for a CA certificate when the signer does not permit it.

 Commonly, the `status.certificate` field contains a single PEM-encoded X.509
 certificate once the CSR is approved and the certificate is issued. Some
@@ -78,7 +80,7 @@ that case, the documentation for the signer should specify the meaning of
 additional certificates; for example, this might be the certificate plus
 intermediates to be presented during TLS handshakes.

-The PKCS#10 signing request format doesn't allow to specify a certificate
+The PKCS#10 signing request format does not allow to specify a certificate
 expiration or lifetime. The expiration or lifetime therefore has to be set
 through e.g. an annotation on the CSR object. While it's theoretically
 possible for a signer to use that expiration date, there is currently no
@@ -185,8 +187,7 @@ To allow signing a CertificateSigningRequest:

 A few steps are required in order to get a normal user to be able to
 authenticate and invoke an API. First, this user must have certificate issued
-by the Kubernetes cluster, and then present that Certificate to the API call
-as the Certificate Header or through the kubectl.
+by the Kubernetes cluster, and then present that certificate to the Kubernetes API.

 ### Create private key

@@ -211,8 +212,6 @@ kind: CertificateSigningRequest
 metadata:
  name: myuser
 spec:
-  groups:
-  - system:authenticated
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  signerName: kubernetes.io/kube-apiserver-client
  usages:
@@ -2,6 +2,9 @@
 title: Feature Gates
 weight: 10
 content_type: concept
+card:
+  name: reference
+  weight: 60
 ---

 <!-- overview -->
@@ -10,7 +10,7 @@ content_type: concept

 <!-- overview -->

-In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver.
+In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver.
 In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly
 recommend using client TLS certificates on nodes.

@@ -44,7 +44,7 @@ Note that the above process depends upon:
 All of the following are responsibilities of whoever sets up and manages the cluster:

 1. Creating the CA key and certificate
-2. Distributing the CA certificate to the master nodes, where kube-apiserver is running
+2. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running
 3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet
 4. Signing the kubelet certificate using the CA key
 5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running
@@ -90,9 +90,9 @@ In addition, you need your Kubernetes Certificate Authority (CA).
 ## Certificate Authority

 As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used
-to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes.
+to sign the kubelet certificate. As before, it is your responsibility to distribute them to control plane nodes.

-For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
+For the purposes of this document, we will assume these have been distributed to control plane nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
 We will refer to these as "Kubernetes CA certificate and key".

 All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.
@@ -167,7 +167,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t

 #### Token authentication file

-kube-apiserver has an ability to accept tokens as authentication.
+kube-apiserver has the ability to accept tokens as authentication.
 These tokens are arbitrary but should represent at least 128 bits of entropy derived
 from a secure random number generator (such as `/dev/urandom` on most modern Linux
 systems). There are multiple ways you can generate a token. For example:
@@ -234,7 +234,7 @@ In order for the controller-manager to sign certificates, it needs the following

 ### Access to key and certificate

-As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes.
+As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes.
 These will be used by the controller-manager to sign the kubelet certificates.

 Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA
@@ -319,7 +319,7 @@ collection.

 ## kubelet configuration

-Finally, with the master nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
+Finally, with the control plane nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.

 The kubelet requires the following configuration to bootstrap:

@@ -116,7 +116,7 @@ The ClusterConfiguration type should be used to configure cluster-wide settings,
 including settings for:

 - Networking, that holds configuration for the networking topology of the cluster; use it e.g. to customize
-  node subnet or services subnet.
+  pod subnet or services subnet.
 - Etcd configurations; use it e.g. to customize the local etcd or to configure the API server
  for using an external etcd cluster.
 - kube-apiserver, kube-scheduler, kube-controller-manager configurations; use it to customize control-plane
@@ -164,19 +164,19 @@ bootstrapTokens:
    groups:
      - system:bootstrappers:kubeadm:default-node-token
 nodeRegistration:
-	 name: "ec2-10-100-0-1"
-	 criSocket: "/var/run/dockershim.sock"
-	 taints:
-	   - key: "kubeadmNode"
-	     value: "master"
-	     effect: "NoSchedule"
-	 kubeletExtraArgs:
-	   cgroup-driver: "cgroupfs"
-	 ignorePreflightErrors:
-	   - IsPrivilegedUser
+  name: "ec2-10-100-0-1"
+  criSocket: "/var/run/dockershim.sock"
+  taints:
+    - key: "kubeadmNode"
+      value: "master"
+      effect: "NoSchedule"
+  kubeletExtraArgs:
+    cgroup-driver: "cgroupfs"
+  ignorePreflightErrors:
+    - IsPrivilegedUser
 localAPIEndpoint:
-	 advertiseAddress: "10.100.0.1"
-	 bindPort: 6443
+  advertiseAddress: "10.100.0.1"
+  bindPort: 6443
 certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
 ---
 apiVersion: kubeadm.k8s.io/v1beta2
@@ -184,59 +184,59 @@ kind: ClusterConfiguration
 etcd:
  # one of local or external
  local:
-	   imageRepository: "k8s.gcr.io"
-	   imageTag: "3.2.24"
-	   dataDir: "/var/lib/etcd"
-	   extraArgs:
-	     listen-client-urls: "http://10.100.0.1:2379"
-	   serverCertSANs:
-	     -  "ec2-10-100-0-1.compute-1.amazonaws.com"
-	   peerCertSANs:
-	     - "10.100.0.1"
-	 # external:
-	   # endpoints:
-	   # - "10.100.0.1:2379"
-	   # - "10.100.0.2:2379"
-	   # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
-	   # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
-	   # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"
-	networking:
-	  serviceSubnet: "10.96.0.0/12"
-	  podSubnet: "10.100.0.1/24"
-	  dnsDomain: "cluster.local"
-	kubernetesVersion: "v1.12.0"
-	controlPlaneEndpoint: "10.100.0.1:6443"
-	apiServer:
-	  extraArgs:
-	    authorization-mode: "Node,RBAC"
-	  extraVolumes:
-	  - name: "some-volume"
-	    hostPath: "/etc/some-path"
-	    mountPath: "/etc/some-pod-path"
-	    readOnly: false
-	    pathType: File
-	  certSANs:
-	  - "10.100.1.1"
-	  - "ec2-10-100-0-1.compute-1.amazonaws.com"
-	  timeoutForControlPlane: 4m0s
-	controllerManager:
-	  extraArgs:
-	    "node-cidr-mask-size": "20"
-	  extraVolumes:
-	  - name: "some-volume"
-	    hostPath: "/etc/some-path"
-	    mountPath: "/etc/some-pod-path"
-	    readOnly: false
-	    pathType: File
-	scheduler:
-	  extraArgs:
-	    address: "10.100.0.1"
-	  extraVolumes:
-	  - name: "some-volume"
-	    hostPath: "/etc/some-path"
-	    mountPath: "/etc/some-pod-path"
-	    readOnly: false
-	    pathType: File
+    imageRepository: "k8s.gcr.io"
+    imageTag: "3.2.24"
+    dataDir: "/var/lib/etcd"
+    extraArgs:
+      listen-client-urls: "http://10.100.0.1:2379"
+    serverCertSANs:
+      - "ec2-10-100-0-1.compute-1.amazonaws.com"
+    peerCertSANs:
+      - "10.100.0.1"
+  # external:
+    # endpoints:
+    # - "10.100.0.1:2379"
+    # - "10.100.0.2:2379"
+    # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt"
+    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
+    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"
+ networking:
+   serviceSubnet: "10.96.0.0/12"
+   podSubnet: "10.100.0.1/24"
+   dnsDomain: "cluster.local"
+ kubernetesVersion: "v1.12.0"
+ controlPlaneEndpoint: "10.100.0.1:6443"
+ apiServer:
+   extraArgs:
+     authorization-mode: "Node,RBAC"
+   extraVolumes:
+     - name: "some-volume"
+       hostPath: "/etc/some-path"
+       mountPath: "/etc/some-pod-path"
+       readOnly: false
+       pathType: File
+   certSANs:
+     - "10.100.1.1"
+     - "ec2-10-100-0-1.compute-1.amazonaws.com"
+   timeoutForControlPlane: 4m0s
+ controllerManager:
+   extraArgs:
+     "node-cidr-mask-size": "20"
+   extraVolumes:
+     - name: "some-volume"
+       hostPath: "/etc/some-path"
+       mountPath: "/etc/some-pod-path"
+       readOnly: false
+       pathType: File
+ scheduler:
+   extraArgs:
+     address: "10.100.0.1"
+   extraVolumes:
+     - name: "some-volume"
+       hostPath: "/etc/some-path"
+       mountPath: "/etc/some-pod-path"
+       readOnly: false
+       pathType: File
 certificatesDir: "/etc/kubernetes/pki"
 imageRepository: "k8s.gcr.io"
 useHyperKubeImage: false
@@ -663,7 +663,7 @@ APIServer holds settings necessary for API server deployments in the cluster
    
  
 <tr><td><code>timeoutForControlPlane</code> <B>[Required]</B><br/>
-<code>invalid type</code>
+<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
 </td>
 <td>
   `timeoutForControlPlane` controls the timeout that we use for API server to appear</td>
@@ -712,7 +712,7 @@ for, so other administrators can know its purpose.</td>
    
  
 <tr><td><code>ttl</code> <B>[Required]</B><br/>
-<code>invalid type</code>
+<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
 </td>
 <td>
   `ttl` defines the time to live for this token. Defaults to "24h".
@@ -721,7 +721,7 @@ for, so other administrators can know its purpose.</td>
    
  
 <tr><td><code>expires</code> <B>[Required]</B><br/>
-<code>invalid type</code>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#time-v1-meta"><code>meta/v1.Time</code></a>
 </td>
 <td>
   `expires` specifies the timestamp when this token expires. Defaults to being set
@@ -1004,7 +1004,7 @@ not contain any other authentication information</td>
    
  
 <tr><td><code>timeout</code> <B>[Required]</B><br/>
-<code>invalid type</code>
+<a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
 </td>
 <td>
   `timeout` modifies the discovery timeout.</td>
@@ -1199,7 +1199,7 @@ HostPathMount contains elements describing volumes that are mounted from the hos
    
  
 <tr><td><code>pathType</code> <B>[Required]</B><br/>
-<code>invalid type</code>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#hostpathtype-v1-core"><code>core/v1.HostPathType</code></a>
 </td>
 <td>
   `pathType` is the type of the `hostPath` volume.</td>
@@ -1451,7 +1451,7 @@ annotated to the Node API object, for later re-use.</td>
    
  
 <tr><td><code>taints</code> <B>[Required]</B><br/>
-<code>[]invalid type</code>
+<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#taint-v1-core"><code>[]core/v1.Taint</code></a>
 </td>
 <td>
   `taints` specifies the taints the Node API object should be registered with. If
@@ -2,7 +2,7 @@
 title: API-initiated eviction
 id: api-eviction
 date: 2021-04-27
-full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
+full_link: /docs/concepts/scheduling-eviction/api-eviction/
 short_description: >
  API-initiated eviction is the process by which you use the Eviction API to create an
  Eviction object that triggers graceful pod termination.
@@ -0,0 +1,31 @@
+---
+title: Finalizer
+id: finalizer
+date: 2021-07-07
+full_link: /docs/concepts/overview/working-with-objects/finalizers/
+short_description: >
+  A namespaced key that tells Kubernetes to wait until specific conditions are met
+  before it fully deletes an object marked for deletion.
+aka: 
+tags:
+- fundamental
+- operation
+---
+Finalizers are namespaced keys that tell Kubernetes to wait until specific
+conditions are met before it fully deletes resources marked for deletion.
+Finalizers alert {{<glossary_tooltip text="controllers" term_id="controller">}}
+to clean up resources the deleted object owned.
+
+<!--more-->
+
+When you tell Kubernetes to delete an object that has finalizers specified for
+it, the Kubernetes API marks the object for deletion, putting it into a
+read-only state. The target object remains in a terminating state while the
+control plane, or other components, take the actions defined by the finalizers.
+After these actions are complete, the controller removes the relevant finalizers
+from the target object. When the `metadata.finalizers` field is empty,
+Kubernetes considers the deletion complete.
+
+You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
+of resources. For example, you can define a finalizer to clean up related resources or
+infrastructure before the controller deletes the target resource.
@@ -0,0 +1,24 @@
+---
+title: Garbage Collection
+id: garbage-collection
+date: 2021-07-07
+full_link: /docs/concepts/workloads/controllers/garbage-collection/
+short_description: >
+  A collective term for the various mechanisms Kubernetes uses to clean up cluster
+  resources.
+
+aka: 
+tags:
+- fundamental
+- operation
+---
+ Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
+ cluster resources. 
+
+<!--more-->
+
+Kubernetes uses garbage collection to clean up resources like [unused containers and images](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
+[failed Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
+[objects owned by the targeted resource](/docs/concepts/overview/working-with-objects/owners-dependents/),
+[completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
+that have expired or failed.
@@ -2,7 +2,7 @@
 title: kube-scheduler
 id: kube-scheduler
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-scheduler/
+full_link: /docs/reference/command-line-tools-reference/kube-scheduler/
 short_description: >
  Control plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.

@@ -89,7 +89,7 @@ Operation       | Syntax    |       Description
 `cluster-info`    | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster.
 `completion`    | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh).
 `config`        | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.
-`convert`    | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted.
+`convert`    | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. Note - requires `kubectl-convert` plugin to be installed.
 `cordon`    | `kubectl cordon NODE [options]` | Mark node as unschedulable.
 `cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | Copy files and directories to and from containers.
 `create`        | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin.
@@ -200,7 +200,7 @@ Used on: Service

 The kube-proxy has this label for custom proxy, which delegates service control to custom proxy.

-## experimental.windows.kubernetes.io/isolation-type
+## experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type}

 Example: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`

@@ -210,6 +210,7 @@ The annotation is used to run Windows containers with Hyper-V isolation. To use

 {{< note >}}
 You can only set this annotation on Pods that have a single container.
+Starting from v1.20, this annotation is deprecated. Experimental Hyper-V support was removed in 1.21.
 {{< /note >}}

 ## ingressclass.kubernetes.io/is-default-class
@@ -119,16 +119,16 @@ Use the following phase to configure bootstrap tokens.
 {{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}}
 {{< /tabs >}}

-## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all}
+## kubeadm init phase kubelet-finalize {#cmd-phase-kubelet-finalize-all}

 Use the following phase to update settings relevant to the kubelet after TLS
 bootstrap. You can use the `all` subcommand to run all `kubelet-finalize`
 phases.

 {{< tabs name="tab-kubelet-finalize" >}}
-{{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}}
-{{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}}
-{{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}}
+{{< tab name="kubelet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}}
+{{< tab name="kubelet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}}
+{{< tab name="kubelet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}}
 {{< /tabs >}}

 ## kubeadm init phase addon {#cmd-phase-addon}
@@ -142,7 +142,7 @@ For information about passing flags to control plane components see:

 By default, kubeadm pulls images from `k8s.gcr.io`. If the
 requested Kubernetes version is a CI label (such as `ci/latest`)
-`gcr.io/kubernetes-ci-images` is used.
+`gcr.io/k8s-staging-ci-images` is used.

 You can override this behavior by using [kubeadm with a configuration file](#config-file).
 Allowed customization are:
@@ -8,7 +8,7 @@ no_list: true
 ---

 <!-- overview -->
-Kubernetes contains several built-in tools to help you work with the Kubernetes system.
+Kubernetes contains several built-in tools and external tools that are commonly used or relevant that may as well be seen as required for Kubernetes to function.


 <!-- body -->
@@ -25,7 +25,7 @@ The more verbose options shown below are intended to be used by human operators
 The following examples will show how you can interact with the health API endpoints.

 For all endpoints you can use the `verbose` parameter to print out the checks and their status.
-This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
+This can be useful for a human operator to debug the current status of the API server, it is not intended to be consumed by a machine:

 ```shell
 curl -k https://localhost:6443/livez?verbose
@@ -93,7 +93,7 @@ The output show that the `etcd` check is excluded:

 {{< feature-state state="alpha" >}}

-Each individual health check exposes an http endpoint and could can be checked individually.
+Each individual health check exposes an HTTP endpoint and could can be checked individually.
 The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server.
 The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
 These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
@@ -124,3 +124,6 @@ components, including cluster-critical addons.
 The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
 integrates with a number of cloud providers to help you run the right number of
 nodes for the level of resource demand in your cluster.
+
+The [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)
+helps you in resizing the addons automatically as your cluster's scale changes.
@@ -415,7 +415,7 @@ and make sure that the node is empty, then deconfigure the node.
 Talking to the control-plane node with the appropriate credentials, run:

 ```bash
-kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
+kubectl drain <node name> --delete-emptydir-data --force --ignore-daemonsets
 ```

 Before removing the node, reset the state installed by `kubeadm`:
@@ -11,7 +11,7 @@ card:
 <!-- overview -->

 <img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
-For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
+For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.



@@ -240,8 +240,9 @@ Install CNI plugins (required for most pod network):

 ```bash
 CNI_VERSION="v0.8.2"
+ARCH="amd64"
 sudo mkdir -p /opt/cni/bin
-curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
+curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
 ```

 Define the directory to download command files
@@ -260,15 +261,17 @@ Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI)

 ```bash
 CRICTL_VERSION="v1.17.0"
-curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
+ARCH="amd64"
+curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
 ```

 Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service:

 ```bash
 RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
+ARCH="amd64"
 cd $DOWNLOAD_DIR
-sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
+sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
 sudo chmod +x {kubeadm,kubelet,kubectl}

 RELEASE_VERSION="v0.4.0"
@@ -314,4 +317,3 @@ If you are running into difficulties with kubeadm, please consult our [troublesh
 ## {{% heading "whatsnext" %}}

 * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
-
@@ -163,7 +163,7 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw

 ## Pods are not accessible via their Service IP

- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
+- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip)
  which allows pods to access themselves via their Service IP. This is an issue related to
  [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
  add-on provider to get the latest status of their support for hairpin mode.
@@ -26,7 +26,7 @@ This guide walks you through the steps to configure and deploy a Windows contain
 ## Before you begin

 * Create a Kubernetes cluster that includes a 
-[master and a worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)
+control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
 * It is important to note that creating and deploying services and workloads on Kubernetes 
 behaves in much the same way for Linux and Windows containers. 
 [Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. 
@@ -105,15 +105,15 @@ the container port 80 is exposed directly to the service.
 1. Check that the deployment succeeded. To verify:

    * Two containers per pod on the Windows node, use `docker ps` 
-    * Two pods listed from the Linux master, use `kubectl get pods` 
-    * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master 
+    * Two pods listed from the Linux control plane node, use `kubectl get pods` 
+    * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux control plane node 
      to check for a web server response
    * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) 
      using docker exec or kubectl exec
    * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) 
-      from the Linux master and from individual pods
+      from the Linux control plane node and from individual pods
    * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services)
-    * Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster
+    * Inbound connectivity, `curl` the NodePort from the Linux control plane node or machines outside of the cluster
    * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec

 {{< note >}}
@@ -184,7 +184,7 @@ For example:  `--register-with-taints='os=windows:NoSchedule'`

 By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). 
 In order for a Windows Pod to be scheduled on a Windows node, 
-it would need both the nodeSelector to choose Windows, and the appropriate matching toleration.
+it would need both the nodeSelector and the appropriate matching toleration to choose Windows.

 ```yaml
 nodeSelector:
@@ -31,7 +31,7 @@ for database debugging.
 1. Create a Deployment that runs MongoDB:

    ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
+    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
    ```

    The output of a successful command verifies that the deployment was created:
@@ -84,7 +84,7 @@ for database debugging.
 2. Create a Service to expose MongoDB on the network:

    ```shell
-    kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
+    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
    ```

    The output of a successful command verifies that the Service was created:
@@ -157,7 +157,7 @@ program to retrieve the contents of your secret.
   kubectl describe secret secret1 -n default
   ```

-   should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to
+   should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret) to
   completely decode the secret.


@@ -163,7 +163,7 @@ Instructions to do so are available at [Install Docker Engine - Enterprise on Wi
 #### Install wins, kubelet, and kubeadm  

 ```PowerShell
-curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
 ```

@@ -206,7 +206,7 @@ If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2")
 #### Install wins, kubelet, and kubeadm

 ```PowerShell
-curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
 ```

@@ -126,7 +126,18 @@ command. In that case, you should explicitly set `--certificate-renewal=true`.

 You can renew your certificates manually at any time with the `kubeadm certs renew` command.

-This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`.
+This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. 
+
+After running the command you should restart the control plane Pods. This is required since
+dynamic certificate reload is currently not supported for all components and certificates.
+[Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet
+and not by the API Server, thus kubectl cannot be used to delete and restart them.
+To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` 
+and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/
+reference/config-api/kubelet-config.v1beta1/).
+The kubelet will terminate the Pod if it's no longer in the manifest directory.
+You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate
+the Pod and the certificate renewal for the component can complete.

 {{< warning >}}
 If you are running an HA cluster, this command needs to be executed on all the control-plane nodes.
@@ -9,17 +9,17 @@ weight: 20
 <!-- overview -->

 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
-{{< skew latestVersionAddMinor -1 >}}.x to version {{< skew latestVersion >}}.x, and from version
-{{< skew latestVersion >}}.x to {{< skew latestVersion >}}.y (where `y > x`). Skipping MINOR versions
+{{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version
+{{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions
 when upgrading is unsupported.

 To see information about upgrading clusters created using older versions of kubeadm,
 please refer to following pages instead:

- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -2 >}} to {{< skew latestVersionAddMinor -1 >}}](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -3 >}} to {{< skew latestVersionAddMinor -2 >}}](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -4 >}} to {{< skew latestVersionAddMinor -3 >}}](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -5 >}} to {{< skew latestVersionAddMinor -4 >}}](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -2 >}} to {{< skew currentVersionAddMinor -1 >}}](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -3 >}} to {{< skew currentVersionAddMinor -2 >}}](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -4 >}} to {{< skew currentVersionAddMinor -3 >}}](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -5 >}} to {{< skew currentVersionAddMinor -4 >}}](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)

 The upgrade workflow at high level is the following:

@@ -45,19 +45,19 @@ The upgrade workflow at high level is the following:

 ## Determine which version to upgrade to

-Find the latest stable {{< skew latestVersion >}} version using the OS package manager:
+Find the latest stable {{< skew currentVersion >}} version using the OS package manager:

 {{< tabs name="k8s_install_versions" >}}
 {{% tab name="Ubuntu, Debian or HypriotOS" %}}
    apt update
    apt-cache madison kubeadm
-    # find the latest {{< skew latestVersion >}} version in the list
-    # it should look like {{< skew latestVersion >}}.x-00, where x is the latest patch
+    # find the latest {{< skew currentVersion >}} version in the list
+    # it should look like {{< skew currentVersion >}}.x-00, where x is the latest patch
 {{% /tab %}}
 {{% tab name="CentOS, RHEL or Fedora" %}}
    yum list --showduplicates kubeadm --disableexcludes=kubernetes
-    # find the latest {{< skew latestVersion >}} version in the list
-    # it should look like {{< skew latestVersion >}}.x-0, where x is the latest patch
+    # find the latest {{< skew currentVersion >}} version in the list
+    # it should look like {{< skew currentVersion >}}.x-0, where x is the latest patch
 {{% /tab %}}
 {{< /tabs >}}

@@ -74,18 +74,18 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc

 {{< tabs name="k8s_install_kubeadm_first_cp" >}}
 {{% tab name="Ubuntu, Debian or HypriotOS" %}}
-    # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version
+    # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
    apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubeadm
    -
    # since apt-get version 1.1 you can also use the following method
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL or Fedora" %}}
-    # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version
-    yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
+    yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}

@@ -120,13 +120,13 @@ Failing to do so will cause `kubeadm upgrade apply` to exit with an error and no

    ```shell
    # replace x with the patch version you picked for this upgrade
-    sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x
+    sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x
    ```

    Once the command finishes you should see:

    ```
-    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy!
+    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!

    [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
    ```
@@ -171,20 +171,20 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
 {{< tabs name="k8s_install_kubelet" >}}
 {{< tab name="Ubuntu, Debian or HypriotOS" >}}
    <pre>
-    # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version
+    # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
    apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubelet kubectl
    -
    # since apt-get version 1.1 you can also use the following method
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
    </pre>
 {{< /tab >}}
 {{< tab name="CentOS, RHEL or Fedora" >}}
    <pre>
-    # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version
-    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
+    yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
    </pre>
 {{< /tab >}}
 {{< /tabs >}}
@@ -216,18 +216,18 @@ without compromising the minimum required capacity for running your workloads.

 {{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
 {{% tab name="Ubuntu, Debian or HypriotOS" %}}
-    # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version
+    # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
    apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubeadm
    -
    # since apt-get version 1.1 you can also use the following method
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL or Fedora" %}}
-    # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version
-    yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
+    yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}

@@ -254,18 +254,18 @@ without compromising the minimum required capacity for running your workloads.

 {{< tabs name="k8s_kubelet_and_kubectl" >}}
 {{% tab name="Ubuntu, Debian or HypriotOS" %}}
-    # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version
+    # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
    apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
    apt-mark hold kubelet kubectl
    -
    # since apt-get version 1.1 you can also use the following method
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
+    apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL or Fedora" %}}
-    # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version
-    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
+    yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}

@@ -30,11 +30,15 @@ Here is an example of what this file might look like:
 ```
 apiVersion: kubelet.config.k8s.io/v1beta1
 kind: KubeletConfiguration
+address: "192.168.0.8",
+port: 20250,
+serializeImagePulls: false,
 evictionHard:
    memory.available:  "200Mi"
 ```

-In the example, the Kubelet is configured to evict Pods when available memory drops below 200Mi.
+In the example, the Kubelet is configured to serve on IP address 192.168.0.8 and port 20250, pull images in parallel,
+and evict Pods when available memory drops below 200Mi.
 All other Kubelet configuration values are left at their built-in defaults, unless overridden
 by flags. Command line flags which target the same value as a config file will override that value.

@@ -24,45 +24,59 @@ For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.
 ## Deploying Cilium on Minikube for Basic Testing

 To get familiar with Cilium easily you can follow the
-[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/)
+[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)
 to perform a basic DaemonSet installation of Cilium in minikube.

-To start minikube, minimal version required is >= v1.3.1, run the with the
+To start minikube, minimal version required is >= v1.5.2, run the with the
 following arguments:

 ```shell
 minikube version
 ```
 ```
-minikube version: v1.3.1
+minikube version: v1.5.2
 ```

 ```shell
-minikube start --network-plugin=cni --memory=4096
+minikube start --network-plugin=cni
 ```

-Mount the BPF filesystem:
+For minikube you can install Cilium using its CLI tool. Cilium will
+automatically detect the cluster configuration and will install the appropriate
+components for a successful installation:

 ```shell
-minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
-```
-
-For minikube you can deploy this simple ''all-in-one'' YAML file that includes
-DaemonSet configurations for Cilium as well as appropriate RBAC settings:
-
-```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
+curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
+sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
+rm cilium-linux-amd64.tar.gz
+cilium install
 ```
 ```
-configmap/cilium-config created
-serviceaccount/cilium created
-serviceaccount/cilium-operator created
-clusterrole.rbac.authorization.k8s.io/cilium created
-clusterrole.rbac.authorization.k8s.io/cilium-operator created
-clusterrolebinding.rbac.authorization.k8s.io/cilium created
-clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
-daemonset.apps/cilium create
-deployment.apps/cilium-operator created
+🔮 Auto-detected Kubernetes kind: minikube
+✨ Running "minikube" validation checks
+✅ Detected minikube version "1.20.0"
+ℹ️  Cilium version not set, using default version "v1.10.0"
+🔮 Auto-detected cluster name: minikube
+🔮 Auto-detected IPAM mode: cluster-pool
+🔮 Auto-detected datapath mode: tunnel
+🔑 Generating CA...
+2021/05/27 02:54:44 [INFO] generate received request
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
+🔑 Generating certificates for Hubble...
+2021/05/27 02:54:44 [INFO] generate received request
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
+🚀 Creating Service accounts...
+🚀 Creating Cluster roles...
+🚀 Creating ConfigMap...
+🚀 Creating Agent DaemonSet...
+🚀 Creating Operator Deployment...
+⌛ Waiting for Cilium to be installed...
 ```

 The remainder of the Getting Started Guide explains how to enforce both L3/L4
@@ -85,14 +99,14 @@ Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see
 this list of Pods run:

 ```shell
-kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system -l k8s-app=cilium
 ```

 You'll see a list of Pods similar to this:

 ```console
-NAME            READY   STATUS    RESTARTS   AGE
-cilium-6rxbd    1/1     Running   0          1m
+NAME           READY   STATUS    RESTARTS   AGE
+cilium-kkdhz   1/1     Running   0          3m23s
 ...
 ```

@@ -26,7 +26,7 @@ and provides recommendations on overall security.

 ## Controlling access to the Kubernetes API

-As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions
+As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions
 they are allowed to perform is the first line of defense.

 ### Use Transport Layer Security (TLS) for all API traffic
@@ -40,7 +40,7 @@ potentially unsecured traffic.
 ### API Authentication

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

@@ -54,7 +54,7 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
 Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships
 an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a
 set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
-resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
+resources (pods, services, nodes) and can be namespace-scoped or cluster-scoped. A set of out-of-the-box
 roles are provided that offer reasonable default separation of responsibility depending on what
 actions a client might want to perform. It is recommended that you use the
 [Node](/docs/reference/access-authn-authz/node/) and
@@ -69,8 +69,8 @@ With authorization, it is important to understand how updates on one object may
 other places. For instance, a user may not be able to create pods directly, but allowing them to
 create a deployment, which creates pods on their behalf, will let them create those pods
 indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node
-being terminated and recreated on other nodes. The out of the box roles represent a balance
-between flexibility and the common use cases, but more limited roles should be carefully reviewed
+being terminated and recreated on other nodes. The out-of-the box roles represent a balance
+between flexibility and common use cases, but more limited roles should be carefully reviewed
 to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.

 Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
@@ -104,7 +104,7 @@ reserved resources like memory, or to provide default limits when none are speci
 ### Controlling what privileges containers run with

 A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/)
-that allows it to request access to running as a specific Linux user on a node (like root),
+that allows it to request access to run as a specific Linux user on a node (like root),
 access to run privileged or access the host network, and other controls that would otherwise
 allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
 can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
@@ -155,10 +155,10 @@ within their namespaces. Many of the supported [Kubernetes networking providers]
 now respect network policy.

 Quota and limit ranges can also be used to control whether users may request node ports or
-load balanced services, which on many clusters can control whether those users applications
+load-balanced services, which on many clusters can control whether those users applications
 are visible outside of the cluster.

-Additional protections may be available that control network rules on a per plugin or per
+Additional protections may be available that control network rules on a per-plugin or per-
 environment basis, such as per-node firewalls, physically separating cluster nodes to
 prevent cross talk, or advanced networking policy.

@@ -169,7 +169,7 @@ By default these APIs are accessible by pods running on an instance and can cont
 credentials for that node, or provisioning data such as kubelet credentials. These credentials
 can be used to escalate within the cluster or to other cloud services under the same account.

-When running Kubernetes on a cloud platform limit permissions given to instance credentials, use
+When running Kubernetes on a cloud platform, limit permissions given to instance credentials, use
 [network policies](/docs/tasks/administer-cluster/declare-network-policy/) to restrict pod access
 to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -177,7 +177,7 @@ to the metadata API, and avoid using provisioning data to deliver secrets.

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

@@ -223,8 +223,9 @@ do not use.
 The shorter the lifetime of a secret or credential the harder it is for an attacker to make
 use of that credential. Set short lifetimes on certificates and automate their rotation. Use
 an authentication provider that can control how long issued tokens are available and use short
-lifetimes where possible. If you use service account tokens in external integrations, plan to
-rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed.
+lifetimes where possible. If you use service-account tokens in external integrations, plan to
+rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap 
+token used for setting up nodes should be revoked or its authorization removed.

 ### Review third party integrations before enabling them

@@ -246,7 +247,8 @@ and may grant an attacker significant visibility into the state of your cluster.
 your backups using a well reviewed backup and encryption solution, and consider using full disk
 encryption where possible.

-Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
+Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature 
+introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing
 parties that gain access to your etcd backups from viewing the content of those secrets. While
 this feature is currently beta, it offers an additional level of defense when backups
 are not encrypted or an attacker gains read access to etcd.
@@ -0,0 +1,352 @@
+---
+title: Use Cascading Deletion in a Cluster
+content_type: task
+---
+
+<!--overview-->
+
+This page shows you how to specify the type of [cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#cascading-deletion)
+to use in your cluster during {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+You also need to [create a sample Deployment](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment) 
+to experiment with the different types of cascading deletion. You will need to
+recreate the Deployment for each type.
+
+## Check owner references on your pods
+
+Check that the `ownerReferences` field is present on your pods:
+
+```shell 
+kubectl get pods -l app=nginx --output=yaml
+```
+
+The output has an `ownerReferences` field similar to this:
+
+```
+apiVersion: v1
+    ...
+    ownerReferences:
+    - apiVersion: apps/v1
+      blockOwnerDeletion: true
+      controller: true
+      kind: ReplicaSet
+      name: nginx-deployment-6b474476c4
+      uid: 4fdcd81c-bd5d-41f7-97af-3a3b759af9a7
+    ...
+```
+
+## Use foreground cascading deletion {#use-foreground-cascading-deletion}
+
+By default, Kubernetes uses [background cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#background-deletion)
+to delete dependents of an object. You can switch to foreground cascading deletion
+using either `kubectl` or the Kubernetes API, depending on the Kubernetes
+version your cluster runs. {{<version-check>}}
+
+{{<tabs name="foreground_deletion">}}
+{{% tab name="Kubernetes 1.20.x and later" %}}
+You can delete objects using foreground cascading deletion using `kubectl` or the
+Kubernetes API.
+
+**Using kubectl**
+
+Run the following command:
+<!--TODO: verify release after which the --cascade flag is switched to a string in https://github.com/kubernetes/kubectl/commit/fd930e3995957b0093ecc4b9fd8b0525d94d3b4e-->
+
+```shell
+kubectl delete deployment nginx-deployment --cascade=foreground
+```
+
+**Using the Kubernetes API**
+
+1. Start a local proxy session:
+
+    ```shell
+    kubectl proxy --port=8080
+    ```
+
+1. Use `curl` to trigger deletion:
+
+   ```shell
+   curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
+       -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+       -H "Content-Type: application/json"
+   ```
+
+   The output contains a `foregroundDeletion` {{<glossary_tooltip text="finalizer" term_id="finalizer">}}
+   like this:
+
+   ```
+    "kind": "Deployment",
+    "apiVersion": "apps/v1",
+    "metadata": {
+        "name": "nginx-deployment",
+        "namespace": "default",
+        "uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505",
+        "resourceVersion": "1363097",
+        "creationTimestamp": "2021-07-08T20:24:37Z",
+        "deletionTimestamp": "2021-07-08T20:27:39Z",
+        "finalizers": [
+          "foregroundDeletion"
+        ]
+        ...
+   ```
+
+{{% /tab %}}
+{{% tab name="Versions prior to Kubernetes 1.20.x" %}}
+You can delete objects using foreground cascading deletion by calling the
+Kubernetes API.
+
+For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/).
+
+1. Start a local proxy session:
+
+    ```shell
+    kubectl proxy --port=8080
+    ```
+
+1. Use `curl` to trigger deletion:
+
+   ```shell
+   curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
+       -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+       -H "Content-Type: application/json"
+   ```
+
+   The output contains a `foregroundDeletion` {{<glossary_tooltip text="finalizer" term_id="finalizer">}}
+   like this:
+
+   ```
+    "kind": "Deployment",
+    "apiVersion": "apps/v1",
+    "metadata": {
+        "name": "nginx-deployment",
+        "namespace": "default",
+        "uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505",
+        "resourceVersion": "1363097",
+        "creationTimestamp": "2021-07-08T20:24:37Z",
+        "deletionTimestamp": "2021-07-08T20:27:39Z",
+        "finalizers": [
+          "foregroundDeletion"
+        ]
+        ...
+   ```
+{{% /tab %}}
+{{</tabs>}}
+
+## Use background cascading deletion {#use-background-cascading-deletion}
+
+1. [Create a sample Deployment](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment).
+1. Use either `kubectl` or the Kubernetes API to delete the Deployment,
+   depending on the Kubernetes version your cluster runs. {{<version-check>}}
+
+{{<tabs name="background_deletion">}}
+{{% tab name="Kubernetes version 1.20.x and later" %}}
+
+You can delete objects using background cascading deletion using `kubectl`
+or the Kubernetes API.
+
+Kubernetes uses background cascading deletion by default, and does so
+even if you run the following commands without the `--cascade` flag or the
+`propagationPolicy` argument.
+
+**Using kubectl**
+
+Run the following command:
+
+```shell
+kubectl delete deployment nginx-deployment --cascade=background
+```
+
+**Using the Kubernetes API**
+
+1. Start a local proxy session:
+
+    ```shell
+    kubectl proxy --port=8080
+    ```
+
+1. Use `curl` to trigger deletion:
+
+    ```shell
+    curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
+        -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+        -H "Content-Type: application/json"
+    ```
+
+    The output is similar to this:
+
+    ```
+    "kind": "Status",
+    "apiVersion": "v1",
+    ...
+    "status": "Success",
+    "details": {
+        "name": "nginx-deployment",
+        "group": "apps",
+        "kind": "deployments",
+        "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456"
+    }
+    ```
+{{% /tab %}}
+{{% tab name="Versions prior to Kubernetes 1.20.x" %}}
+Kubernetes uses background cascading deletion by default, and does so
+even if you run the following commands without the `--cascade` flag or the
+`propagationPolicy: Background` argument.
+
+For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/).
+
+**Using kubectl**
+
+Run the following command:
+
+```shell
+kubectl delete deployment nginx-deployment --cascade=true
+```
+
+**Using the Kubernetes API**
+
+1. Start a local proxy session:
+
+    ```shell
+    kubectl proxy --port=8080
+    ```
+
+1. Use `curl` to trigger deletion:
+
+    ```shell
+    curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
+        -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+        -H "Content-Type: application/json"
+    ```
+
+    The output is similar to this:
+
+    ```
+    "kind": "Status",
+    "apiVersion": "v1",
+    ...
+    "status": "Success",
+    "details": {
+        "name": "nginx-deployment",
+        "group": "apps",
+        "kind": "deployments",
+        "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456"
+    }
+    ```
+{{% /tab %}}
+{{</tabs>}}
+
+
+## Delete owner objects and orphan dependents {#set-orphan-deletion-policy}
+
+By default, when you tell Kubernetes to delete an object, the
+{{<glossary_tooltip text="controller" term_id="controller">}} also deletes
+dependent objects. You can make Kubernetes *orphan* these dependents using
+`kubectl` or the Kubernetes API, depending on the Kubernetes version your
+cluster runs. {{<version-check>}}
+
+{{<tabs name="orphan_objects">}}
+{{% tab name="Kubernetes version 1.20.x and later" %}}
+
+**Using kubectl**
+
+Run the following command:
+
+```shell
+kubectl delete deployment nginx-deployment --cascade=orphan
+```
+
+**Using the Kubernetes API**
+
+1. Start a local proxy session:
+
+    ```shell
+    kubectl proxy --port=8080
+    ```
+
+1. Use `curl` to trigger deletion:
+
+    ```shell
+    curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
+        -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+        -H "Content-Type: application/json"
+    ```
+
+    The output contains `orphan` in the `finalizers` field, similar to this:
+
+    ```
+    "kind": "Deployment",
+    "apiVersion": "apps/v1",
+    "namespace": "default",
+    "uid": "6f577034-42a0-479d-be21-78018c466f1f",
+    "creationTimestamp": "2021-07-09T16:46:37Z",
+    "deletionTimestamp": "2021-07-09T16:47:08Z",
+    "deletionGracePeriodSeconds": 0,
+    "finalizers": [
+      "orphan"
+    ],
+    ...
+    ```
+
+{{% /tab %}}
+{{% tab name="Versions prior to Kubernetes 1.20.x" %}}
+
+For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/).
+
+**Using kubectl**
+
+Run the following command:
+
+```shell
+kubectl delete deployment nginx-deployment --cascade=false
+```
+
+**Using the Kubernetes API**
+
+1. Start a local proxy session:
+
+    ```shell
+    kubectl proxy --port=8080
+    ```
+
+1. Use `curl` to trigger deletion:
+
+    ```shell
+    curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
+        -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+        -H "Content-Type: application/json"
+    ```
+
+    The output contains `orphan` in the `finalizers` field, similar to this:
+
+    ```
+    "kind": "Deployment",
+    "apiVersion": "apps/v1",
+    "namespace": "default",
+    "uid": "6f577034-42a0-479d-be21-78018c466f1f",
+    "creationTimestamp": "2021-07-09T16:46:37Z",
+    "deletionTimestamp": "2021-07-09T16:47:08Z",
+    "deletionGracePeriodSeconds": 0,
+    "finalizers": [
+      "orphan"
+    ],
+    ...
+    ```
+{{% /tab %}}
+{{</tabs>}}
+
+You can check that the Pods managed by the Deployment are still running:
+
+```shell
+kubectl get pods -l app=nginx
+```
+
+## {{% heading "whatsnext" %}}
+
+* Learn about [owners and dependents](/docs/concepts/overview/working-with-objects/owners-dependents/) in Kubernetes.
+* Learn about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
+* Learn about [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/).
@@ -67,7 +67,7 @@ single quotes (`'`). For example, if your password is `S!B\*d$zDsb=`,
 run the following command:

 ```shell
-kubectl create secret generic dev-db-secret \
+kubectl create secret generic db-user-pass \
  --from-literal=username=devuser \
  --from-literal=password='S!B\*d$zDsb='
 ```
@@ -349,8 +349,11 @@ JSON Web Key Set (JWKS) at `/openid/v1/jwks`. The OpenID Provider Configuration
 is sometimes referred to as the _discovery document_.

 Clusters include a default RBAC ClusterRole called
-`system:service-account-issuer-discovery`. No role bindings are provided
-by default. Administrators may, for example, choose whether to bind the role to
+`system:service-account-issuer-discovery`. A default RBAC ClusterRoleBinding
+assigns this role to the `system:serviceaccounts` group, which all service
+accounts implicitly belong to. This allows pods running on the cluster to access
+the service account discovery document via their mounted service account token.
+Administrators may, additionally, choose to bind the role to
 `system:authenticated` or `system:unauthenticated` depending on their security
 requirements and which external systems they intend to federate with.

@@ -17,7 +17,7 @@ Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extensi
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

 {{< note >}}
-There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
+There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the Kubernetes general CA.
 {{< /note >}}

 {{< caution >}}
@@ -11,6 +11,8 @@ This page shows how to perform a rolling update on a DaemonSet.

 ## {{% heading "prerequisites" %}}

+{{< include "task-tutorial-prereqs.md" >}}
+
 <!-- steps -->

 ## DaemonSet Update Strategy
@@ -189,4 +191,3 @@ kubectl delete ds fluentd-elasticsearch -n kube-system

 * See [Performing a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
 * See [Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-
@@ -16,7 +16,7 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu


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

 {{< version-check >}}
@@ -189,7 +189,7 @@ by making use of the `autoscaling/v2beta2` API version.
 First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:

 ```shell
-kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
+kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
 ```

 Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
@@ -198,14 +198,17 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe

 ## Autoscaling during rolling update

-Currently in Kubernetes, it is possible to perform a rolling update by using the deployment object, which manages the underlying replica sets for you.
-Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
-it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
+Kubernetes lets you perform a rolling update on a Deployment. In that
+case, the Deployment manages the underlying ReplicaSets for you.
+When you configure autoscaling for a Deployment, you bind a
+HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler
+manages the `replicas` field of the Deployment. The deployment controller is responsible
+for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable
+number during the rollout and also afterwards.

-Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
-i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
-The reason this doesn't work is that when rolling update creates a new replication controller,
-the Horizontal Pod Autoscaler will not be bound to the new replication controller.
+If you perform a rolling update of a StatefulSet that has an autoscaled number of
+replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource
+similar to ReplicaSet).

 ## Support for cooldown/delay

@@ -379,7 +379,7 @@ This might impact other applications on the Node, so it's best to
 **only do this in a test cluster**.

 ```shell
-kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets
+kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets
 ```

 Now you can watch as the Pod reschedules on a different Node:
@@ -185,7 +185,7 @@ Below are the procedures to set up autocompletion for Bash and Zsh.

 1. Validate the binary (optional)

-   Download the kubectl checksum file:
+   Download the kubectl-convert checksum file:

   {{< tabs name="download_convert_checksum_macos" >}}
   {{< tab name="Intel" codelang="bash" >}}
@@ -228,7 +228,7 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
 1. Move the kubectl-convert binary to a file location on your system `PATH`.

   ```bash
-   sudo mv ./kubectl /usr/local/bin/kubectl-convert
+   sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
   sudo chown root: /usr/local/bin/kubectl-convert
   ```

@@ -348,6 +348,11 @@ node with the required profile.

 ### Restricting profiles with the PodSecurityPolicy

+{{< note >}}
+PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25.
+See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information.
+{{< /note >}}
+
 If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
 enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:

@@ -26,7 +26,7 @@ weight: 20
        <div class="row">
            <div class="col-md-12">
            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
-                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Continue to Module 2 &gt<span class=""></span></a>
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Continue to Module 2 &gt;<span class=""></span></a>
            </div>
        </div>

@@ -37,9 +37,9 @@ weight: 20
        </div>
        <div class="row">
            <div class="col-md-12">
-            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> &lt Return to Module 1<span class=""></span></a>
+            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/" role="button"> &lt; Return to Module 1<span class=""></span></a>
            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
-                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Continue to Module 3 &gt<span class=""></span></a>
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Continue to Module 3 &gt;<span class=""></span></a>
            </div>
        </div>

@@ -29,9 +29,9 @@ weight: 20
        </div>
        <div class="row">
            <div class="col-md-12">
-            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">&lt Return to Module 2<span class="btn"></span></a>
+            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">&lt; Return to Module 2<span class="btn"></span></a>
            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
-                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">Continue to Module 4 &gt<span class="btn"></span></a>
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-intro/" role="button">Continue to Module 4 &gt;<span class="btn"></span></a>
            </div>
        </div>

@@ -26,9 +26,9 @@ weight: 20
        </div>
        <div class="row">
            <div class="col-md-12">
-            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">&lt Return to Module 3<span class=""></span></a>
+            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">&lt; Return to Module 3<span class=""></span></a>
            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
-                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">Continue to Module 5 &gt<span class=""></span></a>
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">Continue to Module 5 &gt;<span class=""></span></a>
            </div>
        </div>

@@ -37,7 +37,7 @@ weight: 10
 				<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
 				<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code>&lt;NodeIP&gt;:&lt;NodePort&gt;</code>. Superset of ClusterIP.</li>
 				<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
-				<li><i>ExternalName</i> - Maps the Service to the contents of the <code>externalName</code> field (e.g. `foo.bar.example.com`), by returning a <code>CNAME</code> record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of <code>kube-dns</code>, or CoreDNS version 0.0.8 or higher.</li>
+				<li><i>ExternalName</i> - Maps the Service to the contents of the <code>externalName</code> field (e.g. <code>foo.bar.example.com</code>), by returning a <code>CNAME</code> record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of <code>kube-dns</code>, or CoreDNS version 0.0.8 or higher.</li>
 			</ul>
 			<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
 			<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
@@ -26,9 +26,9 @@ weight: 20
        </div>
        <div class="row">
            <div class="col-md-12">
-            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">&lt Return to Module 4<span class=""></span></a>
+            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">&lt; Return to Module 4<span class=""></span></a>
            	<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Home<span class=""></span></a>
-                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">Continue to Module 6 &gt<span class=""></span></a>
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update/update-intro/" role="button">Continue to Module 6 &gt;<span class=""></span></a>
            </div>
        </div>

@@ -26,7 +26,7 @@ weight: 20
        </div>
        <div class="row">
            <div class="col-md-12">
-               <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">&lt Return to Module 5<span class=""></span></a>
+               <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">&lt; Return to Module 5<span class=""></span></a>
               <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/" role="button">Return to Kubernetes Basics<span class=""></span></a>
            </div>
        </div>
@@ -50,7 +50,7 @@ To complete this tutorial, you should already have a basic familiarity with
 ### Additional Minikube setup instructions

 {{< caution >}}
-[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 1024MiB of memory and 1 CPU.
+[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 2048MB of memory and 2 CPU.
 Running Minikube with the default resource configuration results in insufficient resource
 errors during this tutorial. To avoid these errors, start Minikube with the following settings:

@@ -266,7 +266,7 @@ to also be deleted. Never assume you'll be able to access data if its volume cla

 The Pods in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)
 image from Google's [container registry](https://cloud.google.com/container-registry/docs/).
-The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)
+The Docker image above is based on [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)
 and includes OpenJDK 8.

 This image includes a standard Cassandra installation from the Apache Debian repo.
@@ -937,7 +937,7 @@ Use [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)
 drain the node on which the `zk-0` Pod is scheduled.

 ```shell
-kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
+kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
 ```

 ```
@@ -972,7 +972,7 @@ Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node
 `zk-1` is scheduled.

 ```shell
-kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
+kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned
 ```

 ```
@@ -1015,7 +1015,7 @@ Continue to watch the Pods of the stateful set, and drain the node on which
 `zk-2` is scheduled.

 ```shell
-kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
+kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
 ```

 ```
@@ -1101,7 +1101,7 @@ zk-1      1/1       Running   0         13m
 Attempt to drain the node on which `zk-2` is scheduled.

 ```shell
-kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
+kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
 ```

 The output:
@@ -19,7 +19,7 @@ ready)_, multi-tier web application using Kubernetes and
 [Docker](https://www.docker.com/). This example consists of the following
 components:

-* A single-instance [Redis](https://www.redis.com/) to store guestbook entries
+* A single-instance [Redis](https://www.redis.io/) to store guestbook entries
 * Multiple web frontend instances

 ## {{% heading "objectives" %}}
@@ -0,0 +1,31 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: mongo
+  labels:
+    app.kubernetes.io/name: mongo
+    app.kubernetes.io/component: backend
+spec:
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: mongo
+      app.kubernetes.io/component: backend
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app.kubernetes.io/name: mongo
+        app.kubernetes.io/component: backend
+    spec:
+      containers:
+      - name: mongo
+        image: mongo:4.2
+        args:
+          - --bind_ip
+          - 0.0.0.0
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        ports:
+        - containerPort: 27017
--- a/Show More
+++ b/Show More