Merge pull request #25469 from jrsapi/1.20-release-blog

Kubernetes 1.20 Release Blog

.github/OWNERS

@@ -0,0 +1,7 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+reviewers:
+- sig-docs-en-reviews # Defined in OWNERS_ALIASES
+
+approvers:
+- sig-docs-en-owners # Defined in OWNERS_ALIASES

.github/workflows/OWNERS

@@ -0,0 +1,11 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+# When modifying this file, consider the security implications of
+# allowing listed reviewers / approvals to modify or remove any
+# configured GitHub Actions.
+
+reviewers:
+- sig-docs-leads
+
+approvers:
+- sig-docs-leads

OWNERS_ALIASES

@@ -120,10 +120,11 @@ aliases:
     - bells17
     # cstoku
     - inductor
+    - kakts
     - makocchi-git
     # MasayaAoyama
     - nasa9084
-    - oke-py
+    # oke-py
   sig-docs-ko-owners: # Admins for Korean content
     - ClaudiaJKang
     - gochist

README-ko.md

@@ -1,69 +1,144 @@
 # 쿠버네티스 문서화
 
-[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
-[![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-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
 
-환영합니다! 이 저장소는 쿠버네티스 웹사이트 및 문서화를 만드는 데 필요로 하는 모든 asset에 대한 공간을 제공합니다. 여러분이 기여를 원한다는 사실에 매우 기쁩니다!
+이 저장소에는 [쿠버네티스 웹사이트 및 문서](https://kubernetes.io/)를 빌드하는 데 필요한 자산이 포함되어 있습니다. 기여해주셔서 감사합니다!
 
-## 문서에 기여하기
+# 저장소 사용하기
 
-이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
+Hugo(확장 버전)를 사용하여 웹사이트를 로컬에서 실행하거나, 컨테이너 런타임에서 실행할 수 있습니다. 라이브 웹사이트와의 배포 일관성을 제공하므로, 컨테이너 런타임을 사용하는 것을 적극 권장합니다.
 
-여러분의 풀 리퀘스트가 생성된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다.  그뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
+## 사전 준비 사항
 
-쿠버네티스 문서화에 기여하기와 관련된 보다 자세한 정보는, 다음을 살펴봅니다:
+이 저장소를 사용하기 위해, 로컬에 다음의 소프트웨어들이 설치되어 있어야 합니다.
 
-* [기여 시작하기](https://kubernetes.io/docs/contribute/start/)
-* [문서화 변경 사항 스테이징하기](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [페이지 템플릿 사용하기](https://kubernetes.io/docs/contribute/style/page-content-types/)
-* [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/)
-* [쿠버네티스 문서화 로컬라이징](https://kubernetes.io/docs/contribute/localization/)
+- [npm](https://www.npmjs.com/)
+- [Go](https://golang.org/)
+- [Hugo(확장 버전)](https://gohugo.io/)
+- [도커](https://www.docker.com/)와 같은 컨테이너 런타임.
 
-## `README.md`에 대한 쿠버네티스 문서화 번역
+시작하기 전에 의존성이 있는 소프트웨어를 설치합니다. 저장소를 복제(clone)하고 디렉터리로 이동합니다.
 
-### 한국어
-
-`README.md` 번역 및 한국어 기여자를 위한 보다 자세한 가이드를 [한국어 README](README-ko.md) 페이지 혹은 [쿠버네티스 문서 한글화 가이드](https://kubernetes.io/ko/docs/contribute/localization_ko/)에서 살펴봅니다.
-
-한국어 번역 메인테이너에게 다음을 통해 연락 가능합니다.
-
-* 이덕준 ([GitHub - @gochist](https://github.com/gochist))
-* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
-
-## 도커를 사용하여 사이트를 로컬에서 실행하기
-
-쿠버네티스 웹사이트를 로컬에서 실행하기 위한 추천하는 방식은 [Hugo](https://gohugo.io) 정적 사이트 생성기를 포함하는 특별한 [도커](https://docker.com) 이미지를 실행하는 것입니다.
-
-> Windows에서 실행하는 경우, [Chocolatey](https://chocolatey.org)로 설치할 수 있는 명명 추가 도구를 필요로 할 것입니다. `choco install make`
-
-> 도커를 사용하지 않고 웹사이트를 로컬에서 실행하기를 선호하는 경우에는, 아래 [Hugo를 사용한 로컬 사이트 실행하기](#hugo를-사용한-로컬-사이트-실행하기)를 살펴봅니다.
-
-도커 [동작 및 실행](https://www.docker.com/get-started) 환경이 있는 경우, 로컬에서 `kubernetes-hugo` 도커 이미지를 빌드 합니다:
-
-```bash
-make container-image
+```
+git clone https://github.com/kubernetes/website.git
+cd website
 ```
 
-해당 이미지가 빌드 된 이후, 사이트를 로컬에서 실행할 수 있습니다:
+쿠버네티스 웹사이트는 [Docsy Hugo 테마](https://github.com/google/docsy#readme)를 사용합니다. 웹사이트를 컨테이너에서 실행하려는 경우에도, 다음을 실행하여 하위 모듈 및 기타 개발 종속성을 가져오는 것이 좋습니다.
 
-```bash
+```
+# Docsy 하위 모듈 가져오기
+git submodule update --init --recursive --depth 1
+```
+
+## 컨테이너를 사용하여 웹사이트 실행하기
+
+컨테이너에서 사이트를 빌드하려면, 다음을 실행하여 컨테이너 이미지를 빌드하고 실행합니다.
+
+```
+make container-image
 make container-serve
 ```
 
-브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
+웹사이트를 보려면 브라우저를 http://localhost:1313 으로 엽니다. 소스 파일을 변경하면 Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다.
 
-## Hugo를 사용한 로컬 사이트 실행하기
+## Hugo를 사용하여 로컬에서 웹사이트 실행하기
 
-Hugo 설치 안내를 위해서는 [공식 Hugo 문서화](https://gohugo.io/getting-started/installing/)를 살펴봅니다. [`netlify.toml`](netlify.toml#L9) 파일에 있는 `HUGO_VERSION` 환경 변수에서 지정된 Hugo 버전이 설치되었는지를 확인합니다.
+[`netlify.toml`](netlify.toml#L10) 파일의 `HUGO_VERSION` 환경 변수에 지정된 Hugo 확장 버전을 설치해야 합니다.
 
-Hugo가 설치되었을 때 로컬에서 사이트를 실행하기 위해 (다음을 실행합니다):
+사이트를 로컬에서 빌드하고 테스트하려면, 다음을 실행합니다.
 
 ```bash
+# 의존성 있는 소프트웨어 설치
+npm ci
 make serve
 ```
 
-이를 통해 로컬 Hugo 서버를 1313번 포트에 시작합니다. 브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
+그러면 포트 1313에서 로컬 Hugo 서버가 시작됩니다. 웹사이트를 보려면 http://localhost:1313 으로 브라우저를 엽니다. 소스 파일을 변경하면, Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다.
 
-## 감사합니다!
+## 문제 해결
+### 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는 기술적인 이유로 2개의 바이너리 세트로 제공됩니다. 현재 웹사이트는 **Hugo 확장** 버전 기반에서만 실행됩니다. [릴리스 페이지](https://github.com/gohugoio/hugo/releases)에서 이름에 `extended` 가 포함된 아카이브를 찾습니다. 확인하려면, `hugo version` 을 실행하고 `extended` 라는 단어를 찾습니다.
+
+### too many open files 이슈에 대한 macOS 문제 해결
+
+macOS에서 `make serve` 를 실행하면 다음의 오류 메시지가 출력됩니다.
+
+```
+ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
+make: *** [serve] Error 1
+```
+
+파일 오픈 개수에 대한 현재 제한값을 확인합니다.
+
+`launchctl limit maxfiles`
+
+그리고 다음의 명령을 실행합니다(https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c 를 참고하여 적용).
+
+```
+#!/bin/sh
+
+# 코멘트 처리한 것은 원래 gist 링크들이며, 그 아래는 수정된 tombigel의 gist 링크입니다.
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist
+
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist
+
+sudo mv limit.maxfiles.plist /Library/LaunchDaemons
+sudo mv limit.maxproc.plist /Library/LaunchDaemons
+
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
+
+sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
+```
+
+이 내용은 Catalina와 Mojave macOS에서 작동합니다.
+
+
+# SIG Docs에 참여하기
+
+[커뮤니티 페이지](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)에서 SIG Docs 쿠버네티스 커뮤니티 및 회의에 대한 자세한 내용을 확인합니다.
+
+이 프로젝트의 메인테이너에게 연락을 할 수도 있습니다.
+
+- [슬랙](https://kubernetes.slack.com/messages/sig-docs) [슬랙에 초대 받기](https://slack.k8s.io/)
+- [메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+# 문서에 기여하기
+
+이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭하면 됩니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
+
+여러분의 풀 리퀘스트가 생성된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.**
+
+또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황이거나, 또는 원래 여러분에게 피드백을 제공하기로 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황도 있습니다.
+
+그뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
+
+쿠버네티스 문서화에 기여하기와 관련된 보다 자세한 정보는, 다음을 참고합니다.
+
+* [쿠버네티스 문서에 기여하기](https://kubernetes.io/docs/contribute/)
+* [페이지 콘텐트 타입](https://kubernetes.io/docs/contribute/style/page-content-types/)
+* [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [쿠버네티스 문서 현지화](https://kubernetes.io/docs/contribute/localization/)
+
+# `README.md`에 대한 쿠버네티스 문서 현지화(localization)
+
+## 한국어
+
+`README.md` 번역 및 한국어 기여자를 위한 보다 자세한 가이드는 [쿠버네티스 문서 한글화 가이드](https://kubernetes.io/ko/docs/contribute/localization_ko/)를 참고합니다.
+
+한국어 번역 메인테이너에게 다음을 통해 연락할 수 있습니다.
+
+* 손석호 ([GitHub - @seokho-son](https://github.com/seokho-son))
+* [슬랙 채널](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
+
+# 행동 강령
+
+쿠버네티스 커뮤니티 참여는 [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 따릅니다.
+
+# 감사합니다!
+
+쿠버네티스는 커뮤니티 참여를 통해 번창하며, 우리는 웹사이트 및 문서화에 대한 당신의 기여에 감사드립니다!

README-pl.md

@@ -17,7 +17,7 @@ Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz
 
 * [Jak rozpocząć współpracę](https://kubernetes.io/docs/contribute/start/)
 * [Podgląd wprowadzanych zmian w dokumentacji](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Szablony stron](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Szablony stron](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Lokalizacja dokumentacji Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 

README-vi.md

@@ -15,7 +15,7 @@ Một khi Pull Request của bạn được tạo, reviewer sẽ chịu trách n
 
 * [Bắt đầu đóng góp](https://kubernetes.io/docs/contribute/start/)
 * [Các giai đoạn thay đổi tài liệu](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
-* [Sử dụng các trang templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Sử dụng các trang templates](https://kubernetes.io/docs/contribute/style/page-content-types/)
 * [Hướng dẫn biểu mẫu tài liệu](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [Địa phương hóa tài liệu Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 

README-zh.md

@@ -13,52 +13,94 @@ This repository contains the assets required to build the [Kubernetes website an
 我们非常高兴您想要参与贡献！
 
 <!--
-## Running the website locally using Hugo
+# Using this repository
 
-See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file.
+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.
 -->
-## 在本地使用 Hugo 来运行网站
+## 使用这个仓库
 
-请参考 [Hugo 的官方文档](https://gohugo.io/getting-started/installing/)了解 Hugo 的安装指令。
-请确保安装的是 [`netlify.toml`](netlify.toml#L10) 文件中环境变量 `HUGO_VERSION` 所指定的
-Hugo 扩展版本。
+可以使用 Hugo（扩展版）在本地运行网站，也可以在容器中运行它。强烈建议使用容器，因为这样可以和在线网站的部署保持一致。
 
 <!--
-Before building the site, clone the Kubernetes website repository:
--->
-在构造网站之前，先克隆 Kubernetes website 仓库：
+## Prerequisites
 
-```bash
+To use this repository, you need the following installed locally:
+
+- [npm](https://www.npmjs.com/)
+- [Go](https://golang.org/)
+- [Hugo (Extended version)](https://gohugo.io/)
+- A container runtime, like [Docker](https://www.docker.com/).
+
+-->
+## 前提条件
+
+使用这个仓库，需要在本地安装以下软件：
+
+- [npm](https://www.npmjs.com/)
+- [Go](https://golang.org/)
+- [Hugo (Extended version)](https://gohugo.io/)
+- 容器运行时，比如 [Docker](https://www.docker.com/).
+
+<!--
+Before you start, install the dependencies. Clone the repository and navigate to the directory:
+-->
+开始前，先安装这些依赖。克隆本仓库并进入对应目录：
+
+```
 git clone https://github.com/kubernetes/website.git
 cd website
-git submodule update --init --recursive
 ```
 
 <!--
-**Note:**  The Kubernetes website deploys the [Docsy Hugo theme](https://github.com/google/docsy#readme).
-If you have not updated your website repository, the `website/themes/docsy` directory is empty.
-The site cannot build without a local copy of the theme.
-
-Update the website theme:
+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:
 -->
-**注意：** Kubernetes 网站要部署 [Docsy Hugo 主题](https://github.com/google/docsy#readme).
-如果你还没有更新你本地的 website 仓库，目录 `website/themes/docsy`
-会是空目录。
-在本地没有主题副本的情况下，网站无法正常构造。
 
-使用下面的命令更新网站主题：
+Kubernetes 网站使用的是 [Docsy Hugo 主题](https://github.com/google/docsy#readme)。 即使你打算在容器中运行网站，我们也强烈建议你通过运行以下命令来引入子模块和其他开发依赖项：
 
-```bash
+```
+# pull in the Docsy submodule
 git submodule update --init --recursive --depth 1
 ```
 
 <!--
+## Running the website using a container
+
+To build the site in a container, run the following to build the container image and run it:
+
+-->
+## 在容器中运行网站
+
+要在容器中构建网站，请通过以下命令来构建容器镜像并运行：
+
+```
+make container-image
+make container-serve
+```
+
+<!--
+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.
+-->
+启动浏览器，打开 http://localhost:1313 来查看网站。
+当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。
+
+<!--
+## Running the website locally using Hugo
+
+Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file.
+
 To build and test the site locally, run:
 -->
+## 在本地使用 Hugo 来运行网站
+
+请确保安装的是 [`netlify.toml`](netlify.toml#L10) 文件中环境变量 `HUGO_VERSION` 所指定的
+Hugo 扩展版本。
+
 若要在本地构造和测试网站，请运行：
 
 ```bash
-hugo server --buildFuture
+# install dependencies
+npm ci
+make serve
 ```
 
 <!--
@@ -68,6 +110,63 @@ This will start the local Hugo server on port 1313. Open up your browser to http
 启动浏览器，打开 http://localhost:1313 来查看网站。
 当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。
 
+<!--
+## 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`.
+
+-->
+## 故障排除
+
+###  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 会发布两套二进制文件。
+当前网站仅基于 **Hugo Extended** 版本运行。
+在 [发布页面](https://github.com/gohugoio/hugo/releases) 中查找名称为 `extended` 的归档。可以运行 `huge version` 查看是否有单词 `extended` 来确认。
+
+<!--
+### Troubleshooting macOS for too many open files
+
+If you run `make serve` on macOS and receive the following error:
+
+-->
+### 对 macOs 上打开太多文件的故障排除
+
+如果在 macOS 上运行 `make serve` 收到以下错误：
+
+```
+ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
+make: *** [serve] Error 1
+```
+
+试着查看一下当前打开文件数的限制：
+
+`launchctl limit maxfiles`
+
+然后运行以下命令（参考https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c）：
+
+```
+#!/bin/sh
+
+# These are the original gist links, linking to my gists now.
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist
+
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist
+
+sudo mv limit.maxfiles.plist /Library/LaunchDaemons
+sudo mv limit.maxproc.plist /Library/LaunchDaemons
+
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
+
+sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
+```
+
+这适用于 Catalina 和 Mojave macOS。
+
 <!--
 ## Get involved with SIG Docs
 
@@ -78,7 +177,7 @@ You can also reach the maintainers of this project at:
 - [Slack](https://kubernetes.slack.com/messages/sig-docs)
 - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 -->
-## 参与 SIG Docs 工作
+# 参与 SIG Docs 工作
 
 通过 [社区页面](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)
 进一步了解 SIG Docs Kubernetes 社区和会议信息。
@@ -95,7 +194,7 @@ You can click the **Fork** button in the upper-right area of the screen to creat
 
 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.**
 -->
-## 为文档做贡献
+# 为文档做贡献
 
 你也可以点击屏幕右上方区域的 **Fork** 按钮，在你自己的 GitHub
 账号下创建本仓库的拷贝。此拷贝被称作 *fork*。
@@ -133,7 +232,7 @@ For more information about contributing to the Kubernetes documentation, see:
 * [文档风格指南](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
 
-## 中文本地化
+# 中文本地化
 
 可以通过以下方式联系中文本地化的维护人员：
 
@@ -146,15 +245,15 @@ For more information about contributing to the Kubernetes documentation, see:
 
 Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
 -->
-### 行为准则
+# 行为准则
 
-参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)约束。
+参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 约束。
 
 <!--
 ## Thank you!
 
 Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
 -->
-## 感谢！
+# 感谢！
 
 Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！

assets/scss/_base.scss

@@ -88,6 +88,20 @@ footer {
   }
 }
 
+main {
+  .button {
+    display: inline-block;
+    border-radius: 6px;
+    padding: 6px 20px;
+    line-height: 1.3rem;
+    color: white;
+    background-color: $blue;
+    text-decoration: none;
+    font-size: 1rem;
+    border: 0px;
+  }
+}
+
 // HEADER
 
 #hamburger {

assets/scss/_custom.scss

@@ -71,6 +71,22 @@ body.td-404 main .error-details {
   max-width: 80%;
   border: 1px solid rgb(222, 226, 230);
   border-radius: 5px;
+  margin-bottom: 1rem;
+  padding-top: 1rem;
+  padding-bottom: 1rem;
+
+  // mermaid diagram - sequence diagram
+  .actor {
+    fill: #326ce5 !important;
+  }
+  text.actor {
+    font-size: 18px !important;
+    stroke: white !important;
+    fill: white !important;
+  }
+  .activation0 {
+    fill: #c9e9ec !important;
+  }
 }
 
 /* HEADER */

config.toml

@@ -138,10 +138,10 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.19"
+latest = "v1.20"
 
-fullversion = "v1.19.0"
-version = "v1.19"
+fullversion = "v1.20.0"
+version = "v1.20"
 githubbranch = "master"
 docsbranch = "master"
 deprecated = false
@@ -157,7 +157,7 @@ github_repo = "https://github.com/kubernetes/website"
 # param for displaying an announcement block on every page.
 # See /i18n/en.toml for message text and title.
 announcement = true
-announcement_bg = "#3f0374" # choose a dark color – text is white
+announcement_bg = "#000000" #choose a dark color – text is white
 
 #Searching
 k8s_search = true
@@ -183,40 +183,40 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.19.0"
-version = "v1.19"
-githubbranch = "v1.19.0"
+fullversion = "v1.20.0"
+version = "v1.20"
+githubbranch = "v1.20.0"
 docsbranch = "master"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.18.8"
+fullversion = "v1.19.4"
+version = "v1.19"
+githubbranch = "v1.19.4"
+docsbranch = "release-1.19"
+url = "https://v1-19.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.18.12"
 version = "v1.18"
-githubbranch = "v1.18.8"
+githubbranch = "v1.18.12"
 docsbranch = "release-1.18"
 url = "https://v1-18.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.17.11"
+fullversion = "v1.17.14"
 version = "v1.17"
-githubbranch = "v1.17.11"
+githubbranch = "v1.17.14"
 docsbranch = "release-1.17"
 url = "https://v1-17.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.16.14"
+fullversion = "v1.16.15"
 version = "v1.16"
-githubbranch = "v1.16.14"
+githubbranch = "v1.16.15"
 docsbranch = "release-1.16"
 url = "https://v1-16.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.15.12"
-version = "v1.15"
-githubbranch = "v1.15.12"
-docsbranch = "release-1.15"
-url = "https://v1-15.docs.kubernetes.io"
-
 
 # User interface configuration
 [params.ui]

content/de/docs/concepts/architecture/nodes.md

@@ -6,7 +6,7 @@ weight: 10
 
 <!-- overview -->
 
-Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node
+Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes. Ein Node
 kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält
 die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste
 und wird von den Master-Komponenten verwaltet.

content/de/docs/tasks/tools/install-minikube.md

@@ -69,7 +69,7 @@ sudo mv minikube /usr/local/bin
 ### Linux
 
 {{< note >}}
-Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://github.com/kubernetes/minikube#other-ways-to-install) im offiziellen Minikube-GitHub-Repository.
+Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://minikube.sigs.k8s.io/docs/start/) im offiziellen Minikube-GitHub-Repository.
 {{< /note >}}
 
 Sie können Minikube unter Linux installieren, indem Sie eine statische Binärdatei herunterladen:

content/en/_index.html

@@ -8,7 +8,7 @@ sitemap:
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-[Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications.
+[Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}), also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
 
 It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community.
 {{% /blocks/feature %}}
@@ -28,7 +28,7 @@ Whether testing locally or running a global enterprise, Kubernetes flexibility g
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="suitcase" %}}
-#### Run Anywhere
+#### Run K8s Anywhere
 
 Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.
 

content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md

@@ -12,7 +12,7 @@ Kubernetes is well-known for running scalable workloads. It scales your workload
 
 ## Guaranteed scheduling with controlled cost
 
-[Kubernetes Cluster Autoscaler](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling) is an excellent tool in the ecosystem which adds more nodes to your cluster when your applications need them. However, cluster autoscaler has some limitations and may not work for all users:
+[Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/) is an excellent tool in the ecosystem which adds more nodes to your cluster when your applications need them. However, cluster autoscaler has some limitations and may not work for all users:
 
 - It does not work in physical clusters.
 - Adding more nodes to the cluster costs more.

content/en/blog/_posts/2020-11-18-cloud-native-security-for-your-cluster/index.md

@@ -0,0 +1,57 @@
+---
+layout: blog
+title: "Cloud native security for your clusters"
+date: 2020-11-18
+slug: cloud-native-security-for-your-clusters
+---
+
+**Author**: [Pushkar Joglekar](https://twitter.com/pudijoglekar)
+
+Over the last few years a small, security focused community has been working diligently to deepen our understanding of security, given the evolving cloud native infrastructure and corresponding iterative deployment practices. To enable sharing of this knowledge with the rest of the community, members of [CNCF SIG Security](https://github.com/cncf/sig-security) (a group which reports into [CNCF TOC](https://github.com/cncf/toc#sigs) and who are friends with [Kubernetes SIG Security](https://github.com/kubernetes/community/tree/master/sig-security)) led by Emily Fox, collaborated on a whitepaper outlining holistic cloud native security concerns and best practices. After over 1200 comments, changes, and discussions from 35 members across the world, we are proud to share [cloud native security whitepaper v1.0](https://www.cncf.io/blog/2020/11/18/announcing-the-cloud-native-security-white-paper) that serves as essential reading for security leadership in enterprises, financial and healthcare industries, academia, government, and non-profit organizations.
+
+The paper attempts to _not_ focus on any specific [cloud native project](https://www.cncf.io/projects/). Instead, the intent is to model and inject security into four logical phases of cloud native application lifecycle: _Develop, Distribute, Deploy, and Runtime_.
+
+<img alt="Cloud native application lifecycle phases"
+     src="cloud-native-app-lifecycle-phases.svg"
+     style="width:60em;max-width:100%;">
+
+
+## Kubernetes native security controls
+When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are:
+* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/): Implement a single source of truth for “least privilege” workloads across the entire cluster
+* [Resource requests and limits](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits): Apply requests (soft constraint) and limits (hard constraint) for shared resources such as memory and CPU
+* [Audit log analysis](/docs/tasks/debug-application-cluster/audit/): Enable Kubernetes API auditing and filtering for security relevant events
+* [Control plane authentication and certificate root of trust](/docs/concepts/architecture/control-plane-node-communication/): Enable mutual TLS authentication with a trusted CA for communication within the cluster
+* [Secrets management](/docs/concepts/configuration/secret/): Integrate with a built-in or external secrets store
+
+## Cloud native complementary security controls
+
+Kubernetes has direct involvement in the _deploy_ phase and to a lesser extent in the _runtime_ phase. Ensuring the artifacts are securely _developed_ and _distributed_ is necessary for, enabling workloads in Kubernetes to run “secure by default”. Throughout all phases of the Cloud native application life cycle, several complementary security controls exist for Kubernetes orchestrated workloads, which includes but are not limited to:
+* Develop:
+  - Image signing and verification
+  - Image vulnerability scanners
+* Distribute:
+  - Pre-deployment checks for detecting excessive privileges
+  - Enabling observability and logging
+* Deploy:
+  - Using a service mesh for workload authentication and authorization
+  - Enforcing “default deny” network policies for inter-workload communication via [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+* Runtime:
+  - Deploying security monitoring agents for workloads
+  - Isolating applications that run on the same node using SELinux, AppArmor, etc.
+  - Scanning configuration against recognized secure baselines for node, workload and orchestrator
+
+## Understand first, secure next
+The cloud native way, including containers, provides great security benefits for its users: immutability, modularity, faster upgrades and consistent state across the environment. Realizing this fundamental change in “the way things are done”, motivates us to look at security with a cloud native lens. One of the things that was evident for all the authors of the paper was the fact that it’s tough to make smarter decisions on how and what to secure in a cloud native ecosystem if you do not understand the tools, patterns, and frameworks at hand (in addition to knowing your own critical assets). Hence, for all the security practitioners out there who want to be partners rather than a gatekeeper for your friends in Operations, Product Development, and Compliance, let’s make an attempt to _learn more so we can secure better_.
+
+We recommend following this **7 step R.U.N.T.I.M.E. path** to get started on cloud native security:
+1. <b>R</b>ead the paper and any linked material in it
+2. <b>U</b>nderstand challenges and constraints for your environment
+3. <b>N</b>ote the content and controls that apply to your environment
+4. <b>T</b>alk about your observations with your peers
+5. <b>I</b>nvolve your leadership and ask for help
+6. <b>M</b>ake a risk profile based on existing and missing security controls
+7. <b>E</b>xpend time, money, and resources that improve security posture and reduce risk where appropriate.
+
+## Acknowledgements
+Huge shout out to _Emily Fox, Tim Bannister (The Scale Factory), Chase Pettet (Mirantis), and Wayne Haber (GitLab)_ for contributing with their wonderful suggestions for this blog post.

content/en/blog/_posts/2020-12-02-dockershim-faq.md

@@ -0,0 +1,180 @@
+---
+layout: blog
+title: "Dockershim Deprecation FAQ"
+date: 2020-12-02
+slug: dockershim-faq
+aliases: [ '/dockershim' ]
+---
+
+This document goes over some frequently asked questions regarding the Dockershim
+deprecation announced as a part of the Kubernetes v1.20 release. For more detail
+on the deprecation of Docker as a container runtime for Kubernetes kubelets, and
+what that means, check out the blog post
+[Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
+
+### Why is dockershim being deprecated?
+
+Maintaining dockershim has become a heavy burden on the Kubernetes maintainers.
+The CRI standard was created to reduce this burden and allow smooth interoperability
+of different container runtimes. Docker itself doesn't currently implement CRI,
+thus the problem.
+
+Dockershim was always intended to be a temporary solution (hence the name: shim).
+You can read more about the community discussion and planning in the
+[Dockershim Removal Kubernetes Enhancement Proposal][drkep].
+
+Additionally, features that were largely incompatible with the dockershim, such
+as cgroups v2 and user namespaces are being implemented in these newer CRI
+runtimes. Removing support for the dockershim will allow further development in
+those areas.
+
+[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim
+
+### Can I still use Docker in Kubernetes 1.20?
+
+Yes, the only thing changing in 1.20 is a single warning log printed at [kubelet]
+startup if using Docker as the runtime.
+
+[kubelet]: /docs/reference/command-line-tools-reference/kubelet/
+
+
+### When will dockershim be removed?
+
+Given the impact of this change, we are using an extended deprecation timeline.
+It will not be removed before Kubernetes 1.22, meaning the earliest release without
+dockershim would be 1.23 in late 2021. We will be working closely with vendors
+and other ecosystem groups to ensure a smooth transition and will evaluate things
+as the situation evolves.
+
+
+### Will my existing Docker images still work?
+
+Yes, the images produced from `docker build` will work with all CRI implementations.
+All your existing images will still work exactly the same.
+
+
+### What about private images?
+
+Also yes. All CRI runtimes support the same pull secrets configuration used in
+Kubernetes, either via the PodSpec or ServiceAccount.
+
+
+### Are Docker and containers the same thing?
+
+Docker popularized the Linux containers pattern and has been instrumental in
+developing the underlying technology, however containers in Linux have existed
+for a long time. The container ecosystem has grown to be much broader than just
+Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
+ecosystem, some replacing aspects of Docker while others enhance existing
+functionality.
+
+
+### Are there examples of folks using other runtimes in production today?
+
+All Kubernetes project produced artifacts (Kubernetes binaries) are validated
+with each release.
+
+Additionally, the [kind] project has been using containerd for some time and has
+seen an improvement in stability for its use case. Kind and containerd are leveraged
+multiple times every day to validate any changes to the Kubernetes codebase. Other
+related projects follow a similar pattern as well, demonstrating the stability and
+usability of other container runtimes. As an example, OpenShift 4.x has been
+using the [CRI-O] runtime in production since June 2019.
+
+For other examples and references you can look at the adopters of containerd and
+cri-o, two container runtimes under the Cloud Native Computing Foundation ([CNCF]).
+- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md)
+- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md)
+
+[CRI-O]: https://cri-o.io/
+[kind]: https://kind.sigs.k8s.io/
+[CNCF]: https://cncf.io
+
+
+### People keep referencing OCI, what is that?
+
+OCI stands for the [Open Container Initiative], which standardized many of the
+interfaces between container tools and technologies. They maintain a standard
+specification for packaging container images (OCI image-spec) and running containers
+(OCI runtime-spec). They also maintain an actual implementation of the runtime-spec
+in the form of [runc], which is the underlying default runtime for both
+[containerd] and [CRI-O]. The CRI builds on these low-level specifications to
+provide an end-to-end standard for managing containers.
+
+[Open Container Initiative]: https://opencontainers.org/about/overview/
+[runc]: https://github.com/opencontainers/runc
+[containerd]: https://containerd.io/
+
+
+### Which CRI implementation should I use?
+
+That’s a complex question and it depends on a lot of factors. If Docker is
+working for you, moving to containerd should be a relatively easy swap and
+has have strictly better performance and less overhead. However we encourage you
+to explore all the options from the [CNCF landscape] in case another would be an
+even better fit for your environment.
+
+[CNCF landscape]: https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category
+
+
+### What should I look out for when changing CRI implementations?
+
+While the underlying containerization code is the same between Docker and most
+CRIs (including containerd), there are a few differences around the edges. Some
+common things to consider when migrating are:
+
+- Logging configuration
+- Runtime resource limitations
+- Node provisioning scripts that call docker or use docker via it's control socket
+- Kubectl plugins that require docker CLI or the control socket
+- Kubernetes tools that require direct access to Docker (e.g. kube-imagepuller)
+- Configuration of functionality like `registry-mirrors` and insecure registries 
+- Other support scripts or daemons that expect docker to be available and are run
+  outside of Kubernetes (e.g. monitoring or security agents)
+- GPUs or special hardware and how they integrate with your runtime and Kubernetes
+
+If you use Kubernetes resource requests/limits or file-based log collection
+DaemonSets then they will continue to work the same, but if you’ve customized
+your dockerd configuration, you’ll need to adapt that for your new container
+runtime where possible.
+
+Another thing to look out for is anything expecting to run for system maintenance
+or nested inside a container when building images will no longer work. For the
+former, you can use the [`crictl`][cr] tool as a drop-in replacement and for the
+latter you can use newer container build options like [img], [buildah], or
+[kaniko] that don’t require Docker.
+
+[cr]: https://github.com/kubernetes-sigs/cri-tools
+[img]: https://github.com/genuinetools/img
+[buildah]: https://github.com/containers/buildah
+[kaniko]: https://github.com/GoogleContainerTools/kaniko
+
+For containerd, you can start with their [documentation] to see what configuration
+options are available as you migrate things over.
+
+[documentation]: https://github.com/containerd/cri/blob/master/docs/registry.md
+
+For instructions on how to use containerd and CRI-O with Kubernetes, see the
+Kubernetes documentation on [Container Runtimes]
+
+[Container Runtimes]: /docs/setup/production-environment/container-runtimes
+
+
+### What if I have more questions?
+
+If you use a vendor-supported Kubernetes distribution, you can ask them about
+upgrade plans for their products. For end-user questions, please post them
+to our end user community forum: https://discuss.kubernetes.io/. 
+
+You can also check out the excellent blog post
+[Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical
+discussion of the changes.
+
+[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
+
+
+### Can I have a hug?
+
+Always and whenever you want!  🤗🤗
+
+

content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

@@ -0,0 +1,104 @@
+---
+layout: blog
+title: "Don't Panic: Kubernetes and Docker"
+date: 2020-12-02
+slug: dont-panic-kubernetes-and-docker
+---
+
+**Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
+
+Kubernetes is [deprecating
+Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
+as a container runtime after v1.20.
+
+**You do not need to panic. It’s not as dramatic as it sounds.**
+
+tl;dr Docker as an underlying runtime is being deprecated in favor of runtimes
+that use the [Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
+created for Kubernetes. Docker-produced images will continue to work in your
+cluster with all runtimes, as they always have.
+
+If you’re an end-user of Kubernetes, not a whole lot will be changing for you.
+This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or
+shouldn’t, use Docker as a development tool anymore. Docker is still a useful
+tool for building containers, and the images that result from running `docker
+build` can still run in your Kubernetes cluster. 
+ 
+If you’re using a managed Kubernetes service like GKE, EKS, or AKS (which [defaults to containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16)) you will need to
+make sure your worker nodes are using a supported container runtime before
+Docker support is removed in a future version of Kubernetes. If you have node
+customizations you may need to update them based on your environment and runtime
+requirements. Please work with your service provider to ensure proper upgrade
+testing and planning. 
+
+If you’re rolling your own clusters, you will also need to make changes to avoid
+your clusters breaking. At v1.20, you will get a deprecation warning for Docker.
+When Docker runtime support is removed in a future release (currently planned
+for the 1.22 release in late 2021) of Kubernetes it will no longer be supported
+and you will need to switch to one of the other compliant container runtimes,
+like containerd or CRI-O. Just make sure that the runtime you choose supports
+the docker daemon configurations you currently use (e.g. logging).
+
+## So why the confusion and what is everyone freaking out about?
+
+We’re talking about two different environments here, and that’s creating
+confusion. Inside of your Kubernetes cluster, there’s a thing called a container
+runtime that’s responsible for pulling and running your container images. Docker
+is a popular choice for that runtime (other common options include containerd
+and CRI-O), but Docker was not designed to be embedded inside Kubernetes, and
+that causes a problem. 
+
+You see, the thing we call “Docker” isn’t actually one thing -- it’s an entire
+tech stack, and one part of it is a thing called “containerd,” which is a
+high-level container runtime by itself. Docker is cool and useful because it has
+a lot of UX enhancements that make it really easy for humans to interact with
+while we’re doing development work, but those UX enhancements aren’t necessary
+for Kubernetes, because it isn’t a human. 
+
+As a result of this human-friendly abstraction layer, your Kubernetes cluster
+has to use another tool called Dockershim to get at what it really needs, which
+is containerd. That’s not great, because it gives us another thing that has to
+be maintained and can possibly break. What’s actually happening here is that
+Dockershim is being removed from Kubelet as early as v1.23 release, which
+removes support for Docker as a container runtime as a result. You might be
+thinking to yourself, but if containerd is included in the Docker stack, why
+does Kubernetes need the Dockershim?
+
+Docker isn’t compliant with CRI, the [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/).
+If it were, we wouldn’t need the shim, and this wouldn’t be a thing. But it’s
+not the end of the world, and you don’t need to panic -- you just need to change
+your container runtime from Docker to another supported container runtime.
+
+One thing to note: If you are relying on the underlying docker socket
+(/var/run/docker.sock) as part of a workflow within your cluster today, moving
+to a different runtime will break your ability to use it. This pattern is often
+called Docker in Docker. There are lots of options out there for this specific
+use case including things like
+[kaniko](https://github.com/GoogleContainerTools/kaniko),
+[img](https://github.com/genuinetools/img), and
+[buildah](https://github.com/containers/buildah). 
+ 
+## What does this change mean for developers, though? Do we still write Dockerfiles? Do we still build things with Docker?
+ 
+This change addresses a different environment than most folks use to interact
+with Docker. The Docker installation you’re using in development is unrelated to
+the Docker runtime inside your Kubernetes cluster. It’s confusing, I know. As a
+developer, Docker is still useful to you in all the ways it was before this
+change was announced. The image that Docker produces isn’t really a
+Docker-specific image -- it’s an OCI ([Open Container Initiative](https://opencontainers.org/)) image. 
+Any OCI-compliant image, regardless of the tool you use to build it, will look
+the same to Kubernetes. Both [containerd](https://containerd.io/) and
+[CRI-O](https://cri-o.io/) know how to pull those images and run them. This is
+why we have a standard for what containers should look like.
+
+So, this change is coming. It’s going to cause issues for some, but it isn’t
+catastrophic, and generally it’s a good thing. Depending on how you interact
+with Kubernetes, this could mean nothing to you, or it could mean a bit of work.
+In the long run, it’s going to make things easier. If this is still confusing
+for you, that’s okay -- there’s a lot going on here, Kubernetes has a lot of
+moving parts, and nobody is an expert in 100% of it. We encourage any and all
+questions regardless of experience level or complexity! Our goal is to make sure
+everyone is educated as much as possible on the upcoming changes. `<3` We hope
+this has answered most of your questions and soothed some anxieties!
+
+Looking for more answers? Check out our accompanying [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).

content/en/blog/_posts/2020-12-04-gsod-2020-improving-api-reference-experience.md

@@ -0,0 +1,92 @@
+---
+layout: blog
+title: "GSoD 2020: Improving the API Reference Experience"
+date: 2020-12-04
+slug: gsod-2020-improving-api-reference-experience
+---
+
+**Author**: [Philippe Martin](https://github.com/feloy)
+
+_Editor's note: Better API references have been my goal since I joined Kubernetes docs three and a half years ago. Philippe has succeeded fantastically. More than a better API reference, though, Philippe embodied the best of the Kubernetes community in this project: excellence through collaboration, and a process that made the community itself better. Thanks, Google Season of Docs, for making Philippe's work possible. —Zach Corleissen_
+
+## Introduction
+
+The [Google Season of Docs](https://developers.google.com/season-of-docs) project brings open source organizations and technical writers together to work closely on a specific documentation project.
+
+I was selected by the CNCF to work on Kubernetes documentation, specifically to make the API Reference documentation more accessible.
+
+I'm a software developer with a great interest in documentation systems. In the late 90's I started translating Linux-HOWTO documents into French. From one thing to another, I learned about documentation systems. Eventually, I wrote a Linux-HOWTO to help documentarians learn the language used at that time for writing documents, LinuxDoc/SGML.
+
+Shortly afterward, Linux documentation adopted the DocBook language. I helped some writers rewrite their documents in this format; for example, the Advanced Bash-Scripting Guide. I also worked on the GNU `makeinfo` program to add DocBook output, making it possible to transform *GNU Info* documentation into Docbook format.
+
+## Background
+
+The [Kubernetes website](https://kubernetes.io/docs/home/) is built with Hugo from documentation written in Markdown format in the [website repository](https://github.com/kubernetes/website), using the [Docsy Hugo theme](https://www.docsy.dev/about/).
+
+The existing API reference documentation is a large HTML file generated from the Kubernetes OpenAPI specification.
+
+On my side, I wanted for some time to make the API Reference more accessible, by:
+- building individual and autonomous pages for each Kubernetes resource
+- adapting the format to mobile reading
+- reusing the website's assets and theme to build, integrate, and display the reference pages
+- allowing the search engines to reference the content of the pages
+
+Around one year ago, I started to work on the generator building the current unique HTML page, to add a DocBook output, so the API Reference could be generated first in DocBook format, and after that in PDF or other formats supported by DocBook processors. The first result has been some [Ebook files for the API Reference](https://github.com/feloy/kubernetes-resources-reference/releases) and an auto-edited paper book.
+
+I decided later to add another output to this generator, to generate Markdown files and create [a website with the API Reference](https://web.archive.org/web/20201022201911/https://www.k8sref.io/docs/workloads/).
+
+When the CNCF proposed a project for the Google Season of Docs to work on the API Reference, I applied, and the match occurred.
+
+## The Project
+
+### swagger-ui
+
+The first idea of the CNCF members that proposed this project was to test the [`swagger-ui` tool](https://swagger.io/tools/swagger-ui/), to try and document the Kubernetes API Reference with this standard tool. 
+
+Because the Kubernetes API is much larger than many other APIs, it has been necessary to write a tool to split the complete API Reference by API Groups, and insert in the Documentation website several `swagger-ui` components, one for each API Group.
+
+Generally, APIs are used by developers by calling endpoints with a specific HTTP verb, with specific parameters and waiting for a response. The `swagger-ui` interface is built for this usage: the interface displays a list of endpoints and their associated verbs, and for each the parameters and responses formats. 
+
+The Kubernetes API is most of the time used differently: users create manifest files containing resources definitions in YAML format, and use the `kubectl` CLI to *apply* these manifests to the cluster. In this case, the most important information is the description of the structures used as parameters and responses (the Kubernetes Resources).
+
+Because of this specificity, we realized that it would be difficult to adapt the `swagger-ui` interface to satisfy the users of the Kubernetes API and this direction has been abandoned.
+
+### Markdown pages
+
+The second stage of the project has been to adapt the work I had done to create the k8sref.io website, to include it in the official documentation website.
+
+The main changes have been to:
+- use go-templates to represent the output pages, so non-developers can adapt the generated pages without having to edit the generator code
+- create a new custom [shortcode](https://gohugo.io/content-management/shortcodes/), to easily create links from inside the website to specific pages of the API reference
+- improve the navigation between the sections of the API reference
+- add the code of the generator to the Kubernetes GitHub repository containing the different reference generators
+
+All the discussions and work done can be found in website [pull request #23294](https://github.com/kubernetes/website/pull/23294).
+
+Adding the generator code to the Kubernetes project happened in [kubernetes-sigs/reference-docs#179](https://github.com/kubernetes-sigs/reference-docs/pull/179).
+
+Here are the features of the new API Reference to be included in the official documentation website:
+
+- the resources are categorized, in the categories Workloads, Services, Config & Storage, Authentication, Authorization, Policies, Extend, Cluster. This structure is configurable with a simple [`toc.yaml` file](https://github.com/kubernetes-sigs/reference-docs/blob/master/gen-resourcesdocs/config/v1.20/toc.yaml)
+- each page displays associated resources at the first level ; for example: Pod, PodSpec, PodStatus, PodList
+- most resource pages inline relevant definitions ; the exceptions are when those definitions are common to several resources, or are too complex to be displayed inline. With the old approach, you had to follow a hyperlink to read each extra detail.
+- some widely used definitions, such as `ObjectMeta`, are documented in a specific page
+- required fields are indicated, and placed first
+- fields of a resource can be categorized and ordered, with the help of a [`fields.yaml` file](https://github.com/kubernetes-sigs/reference-docs/blob/master/gen-resourcesdocs/config/v1.20/fields.yaml)
+- `map` fields are indicated. For example the `.spec.nodeSelector` for a `Pod` is `map[string]string`, instead of `object`, using the value of `x-kubernetes-list-type`
+- patch strategies are indicated
+- `apiVersion` and `kind` display the value, not the `string` type
+- At the top of a reference page, the page displays the Go import necessary to use these resources from a Go program.
+
+The work is currently on hold pending the 1.20 release. When the release finishes and the work is integrated, the API reference will be available at https://kubernetes.io/docs/reference/.
+
+### Future Work
+
+There are points to improve, particularly:
+
+- Some Kubernetes resources are deeply nested. Inlining the definition of these resources makes them difficult to understand.
+- The created `shortcode` uses the URL of the page to reference a Resource page. It would be easier for documentarians if they could reference a Resource by its group and name.
+
+## Appreciation
+
+I would like to thank my mentor [Zach Corleissen](https://github.com/zacharysarah) and the lead writers [Karen Bradshaw](https://github.com/kbhawkey), [Celeste Horgan](https://github.com/celestehorgan), [Tim Bannister](https://github.com/sftim) and [Qiming Teng](https://github.com/tengqm) who supervised me during all the season. They all have been very encouraging and gave me tons of great advice.

content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md

@@ -0,0 +1,143 @@
+---
+layout: blog
+title: 'Kubernetes 1.20: The Raddest Release'
+date: 2020-12-08
+slug: kubernetes-1-20-release-announcement
+---
+
+**Authors:** [Kubernetes 1.20 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.20/release_team.md)
+
+We’re pleased to announce the release of Kubernetes 1.20, our third and final release of 2020! This release consists of 42 enhancements: 11 enhancements have graduated to stable, 15 enhancements are moving to beta, and 16 enhancements are entering alpha.
+
+The 1.20 release cycle returned to its normal cadence of 11 weeks following the previous extended release cycle. This is one of the most feature dense releases in a while: the Kubernetes innovation cycle is still trending upward. This release has more alpha than stable enhancements, showing that there is still much to explore in the cloud native ecosystem.
+
+## Major Themes
+
+### Volume Snapshot Operations Goes Stable
+
+This feature provides a standard way to trigger volume snapshot operations and allows users to incorporate snapshot operations in a portable manner on any Kubernetes environment and supported storage providers.
+
+Additionally, these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise-grade, storage administration features for Kubernetes, including application or cluster level backup solutions.
+
+Note that snapshot support requires Kubernetes distributors to bundle the Snapshot controller, Snapshot CRDs, and validation webhook. A CSI driver supporting the snapshot functionality must also be deployed on the cluster.
+
+### Kubectl Debug Graduates to Beta
+
+The `kubectl alpha debug` features graduates to beta in 1.20, becoming `kubectl debug`. The feature provides support for common debugging workflows directly from kubectl. Troubleshooting scenarios supported in this release of kubectl include:
+
+* Troubleshoot workloads that crash on startup by creating a copy of the pod that uses a different container image or command.
+* Troubleshoot distroless containers by adding a new container with debugging tools, either in a new copy of the pod or using an ephemeral container. (Ephemeral containers are an alpha feature that are not enabled by default.)
+* Troubleshoot on a node by creating a container running in the host namespaces and with access to the host’s filesystem.
+Note that as a new built-in command, `kubectl debug` takes priority over any kubectl plugin named “debug”. You must rename the affected plugin.
+
+Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug`. For more information about `kubectl debug`, see [Debugging Running Pods](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/).
+
+### Beta: API Priority and Fairness
+
+Introduced in 1.18, Kubernetes 1.20 now enables API Priority and Fairness (APF) by default. This allows `kube-apiserver` to categorize incoming requests by priority levels.
+
+### Alpha with updates: IPV4/IPV6
+
+The IPv4/IPv6 dual stack has been reimplemented to support dual stack services based on user and community feedback. This allows both IPv4 and IPv6 service cluster IP addresses to be assigned to a single service, and also enables a service to be transitioned from single to dual IP stack and vice versa.
+
+### GA: Process PID Limiting for Stability
+
+Process IDs (pids) are a fundamental resource on Linux hosts. It is trivial to hit the task limit without hitting any other resource limits and cause instability to a host machine.
+
+Administrators require mechanisms to ensure that user pods cannot induce pid exhaustion that prevents host daemons (runtime, kubelet, etc) from running. In addition, it is important to ensure that pids are limited among pods in order to ensure they have limited impact to other workloads on the node.
+After being enabled-by-default for a year, SIG Node graduates PID Limits to GA on both `SupportNodePidsLimit` (node-to-pod PID isolation) and `SupportPodPidsLimit` (ability to limit PIDs per pod).
+
+### Alpha: Graceful node shutdown
+
+Users and cluster administrators expect that pods will adhere to expected pod lifecycle including pod termination. Currently, when a node shuts down, pods do not follow the expected pod termination lifecycle and are not terminated gracefully which can cause issues for some workloads.
+The `GracefulNodeShutdown` feature is now in Alpha. `GracefulNodeShutdown` makes the kubelet aware of node system shutdowns, enabling graceful termination of pods during a system shutdown.
+
+## Major Changes
+
+### Dockershim Deprecation
+
+Dockershim, the container runtime interface (CRI) shim for Docker is being deprecated. Support for Docker is deprecated and will be removed in a future release. Docker-produced images will continue to work in your cluster with all CRI compliant runtimes as Docker images follow the Open Container Initiative (OCI) image specification.
+The Kubernetes community has written a [detailed blog post about deprecation](https://blog.k8s.io/2020/12/02/dont-panic-kubernetes-and-docker/) with [a dedicated FAQ page for it](https://blog.k8s.io/2020/12/02/dockershim-faq/).
+
+### Exec Probe Timeout Handling
+
+A longstanding bug regarding exec probe timeouts that may impact existing pod definitions has been fixed. Prior to this fix, the field `timeoutSeconds` was not respected for exec probes. Instead, probes would run indefinitely, even past their configured deadline, until a result was returned. With this change, the default value of `1 second` will be applied if a value is not specified and existing pod definitions may no longer be sufficient if a probe takes longer than one second. A feature gate, called `ExecProbeTimeout`, has been added with this fix that enables cluster operators to revert to the previous behavior, but this will be locked and removed in subsequent releases. In order to revert to the previous behavior, cluster operators should set this feature gate to `false`.
+
+Please review the updated documentation regarding [configuring probes](docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for more details.
+
+## Other Updates
+
+### Graduated to Stable
+
+* [RuntimeClass](https://github.com/kubernetes/enhancements/issues/585)
+* [Built-in API Types Defaults](https://github.com/kubernetes/enhancements/issues/1929)
+* [Add Pod-Startup Liveness-Probe Holdoff](https://github.com/kubernetes/enhancements/issues/950)
+* [Support CRI-ContainerD On Windows](https://github.com/kubernetes/enhancements/issues/1001)
+* [SCTP Support for Services](https://github.com/kubernetes/enhancements/issues/614)
+* [Adding AppProtocol To Services And Endpoints](https://github.com/kubernetes/enhancements/issues/1507)
+
+### Notable Feature Updates
+
+* [CronJobs](https://github.com/kubernetes/enhancements/issues/19)
+
+# Release notes
+
+You can check out the full details of the 1.20 release in the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md).
+
+# Availability of release
+
+Kubernetes 1.20 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.20.0). There are some great resources out there for getting started with Kubernetes. You can check out some [interactive tutorials](https://kubernetes.io/docs/tutorials/) on the main Kubernetes site, or run a local cluster on your machine using Docker containers with [kind](https://kind.sigs.k8s.io). If you’d like to try building a cluster from scratch, check out the [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way) tutorial by Kelsey Hightower.
+
+# Release Team
+
+This release was made possible by a very dedicated group of individuals, who came together as a team in the midst of a lot of things happening out in the world. A huge thank you to the release lead Jeremy Rickard, and to everyone else on the release team for supporting each other, and working so hard to deliver the 1.20 release for the community.
+
+# Release Logo
+
+![Kubernetes 1.20 Release Logo](/images/blog/2020-12-08-kubernetes-1.20-release-announcement/laser.png)
+
+[raddest](https://www.dictionary.com/browse/rad): *adjective*, Slang. excellent; wonderful; cool:
+
+> The Kubernetes 1.20 Release has been the raddest release yet.
+
+2020 has been a challenging year for many of us, but Kubernetes contributors have delivered a record-breaking number of enhancements in this release. That is a great accomplishment, so the release lead wanted to end the year with a little bit of levity and pay homage to [Kubernetes 1.14 - Caturnetes](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.14) with a "rad" cat named Humphrey.
+
+Humphrey is the release lead's cat and has a permanent [`blep`](https://www.inverse.com/article/42316-why-do-cats-blep-science-explains). *Rad* was pretty common slang in the 1990s in the United States, and so were laser backgrounds. Humphrey in a 1990s style school picture felt like a fun way to end the year. Hopefully, Humphrey and his *blep* bring you a little joy at the end of 2020!
+
+The release logo was created by [Henry Hsu - @robotdancebattle](https://www.instagram.com/robotdancebattle/).
+
+# User Highlights
+
+- Apple is operating multi-thousand node Kubernetes clusters in data centers all over the world. Watch [Alena Prokharchyk's KubeCon NA Keynote](https://youtu.be/Tx8qXC-U3KM) to learn more about their cloud native journey.
+
+# Project Velocity
+
+The [CNCF K8s DevStats project](https://k8s.devstats.cncf.io/) aggregates a number of interesting data points related to the velocity of Kubernetes and various sub-projects. This includes everything from individual contributions to the number of companies that are contributing, and is a neat illustration of the depth and breadth of effort that goes into evolving this ecosystem.
+
+In the v1.20 release cycle, which ran for 11 weeks (September 25 to December 9), we saw contributions from [967 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.19.0%20-%20now&var-metric=contributions) and [1335 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.19.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All) ([44 of whom](https://k8s.devstats.cncf.io/d/52/new-contributors?orgId=1&from=1601006400000&to=1607576399000&var-repogroup_name=Kubernetes) made their first Kubernetes contribution) from [26 countries](https://k8s.devstats.cncf.io/d/50/countries-stats?orgId=1&from=1601006400000&to=1607576399000&var-period_name=Quarter&var-countries=All&var-repogroup_name=Kubernetes&var-metric=rcommitters&var-cum=countries).
+
+# Ecosystem Updates
+
+- KubeCon North America just wrapped up three weeks ago, the second such event to be virtual! All talks are [now available to all on-demand](https://www.youtube.com/playlist?list=PLj6h78yzYM2Pn8RxfLh2qrXBDftr6Qjut) for anyone still needing to catch up!
+- In June, the Kubernetes community formed a new working group as a direct response to the Black Lives Matter protests occurring across America. WG Naming's goal is to remove harmful and unclear language in the Kubernetes project as completely as possible and to do so in a way that is portable to other CNCF projects. A great introductory talk on this important work and how it is conducted was given [at KubeCon 2020 North America](https://sched.co/eukp), and the initial impact of this labor [can actually be seen in the v1.20 release](https://github.com/kubernetes/enhancements/issues/2067).
+- Previously announced this summer, [The Certified Kubernetes Security Specialist (CKS) Certification](https://www.cncf.io/announcements/2020/11/17/kubernetes-security-specialist-certification-now-available/) was released during Kubecon NA for immediate scheduling!  Following the model of CKA and CKAD, the CKS is a performance-based exam, focused on security-themed competencies and domains.  This exam is targeted at current CKA holders, particularly those who want to round out their baseline knowledge in securing cloud workloads (which is all of us, right?).
+
+# Event Updates
+
+KubeCon + CloudNativeCon Europe 2021 will take place May 4 - 7, 2021! Registration will open on January 11. You can find more information about the conference [here](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/). Remember that [the CFP](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/) closes on Sunday, December 13, 11:59pm PST!
+
+# Upcoming release webinar
+
+Stay tuned for the upcoming release webinar happening this January.
+
+# Get Involved
+
+If you’re interested in contributing to the Kubernetes community, Special Interest Groups (SIGs) are a great starting point. Many of them may align with your interests! If there are things you’d like to share with the community, you can join the weekly community meeting, or use any of the following channels:
+
+* Find out more about contributing to Kubernetes at the new [Kubernetes Contributor website](https://www.kubernetes.dev/)
+* Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
+* Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
+* Join the community on [Slack](http://slack.k8s.io/)
+* Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
+* Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
+* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)

content/en/case-studies/newyorktimes/index.html

@@ -26,10 +26,9 @@ case_study_details:
 
 <p>Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.</p>
 
-{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times">}}
-<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-<br>
+{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times" >}}
+{{< youtube DqS_IPw-c6o youtube-quote-sm >}}
+{{< youtube Tm4VfJtOHt8 youtube-quote-sm >}}
 "I think once you get over the initial hump, things get a lot easier and actually a lot faster."
 {{< /case-studies/quote >}}
 

content/en/docs/concepts/architecture/controller.md

@@ -92,9 +92,8 @@ Controllers that interact with external state find their desired state from
 the API server, then communicate directly with an external system to bring
 the current state closer in line.
 
-(There actually is a controller that horizontally scales the
-nodes in your cluster. See
-[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)).
+(There actually is a [controller](https://github.com/kubernetes/autoscaler/)
+that horizontally scales the nodes in your cluster.)
 
 The important point here is that the controller makes some change to bring about
 your desired state, and then reports current state back to your cluster's API server.

content/en/docs/concepts/architecture/nodes.md

@@ -330,6 +330,26 @@ the kubelet can use topology hints when making resource assignment decisions.
 See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/)
 for more information.
 
+## Graceful Node Shutdown {#graceful-node-shutdown}
+
+{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
+
+If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the node system shutdown and terminates pods running on the node.
+Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown.
+
+When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown kubelet terminates pods in two phases:
+
+1. Terminate regular pods running on the node.
+2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
+
+Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
+* `ShutdownGracePeriod`:
+  * Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
+* `ShutdownGracePeriodCriticalPods`:
+  * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This should be less than `ShutdownGracePeriod`.
+
+For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by 30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
+
 
 ## {{% heading "whatsnext" %}}
 
@@ -338,5 +358,4 @@ for more information.
 * Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
   section of the architecture design document.
 * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
-* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
 

content/en/docs/concepts/cluster-administration/_index.md

@@ -39,8 +39,6 @@ Before choosing a guide, here are some considerations:
 
 ## Managing a cluster
 
-* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster's master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
-
 * Learn how to [manage nodes](/docs/concepts/architecture/nodes/).
 
 * Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.

content/en/docs/concepts/cluster-administration/flow-control.md

@@ -6,7 +6,7 @@ min-kubernetes-server-version: v1.18
 
 <!-- overview -->
 
-{{< feature-state state="alpha"  for_k8s_version="v1.18" >}}
+{{< feature-state state="beta"  for_k8s_version="v1.20" >}}
 
 Controlling the behavior of the Kubernetes API server in an overload situation
 is a key task for cluster administrators. The {{< glossary_tooltip
@@ -37,25 +37,30 @@ Fairness feature enabled.
 
 <!-- body -->
 
-## Enabling API Priority and Fairness
+## Enabling/Disabling API Priority and Fairness
 
 The API Priority and Fairness feature is controlled by a feature gate
-and is not enabled by default.  See
+and is enabled by default.  See
 [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/)
-for a general explanation of feature gates and how to enable and disable them.  The
-name of the feature gate for APF is "APIPriorityAndFairness".  This
-feature also involves an {{< glossary_tooltip term_id="api-group"
-text="API Group" >}} that must be enabled.  You can do these
-things by adding the following command-line flags to your
-`kube-apiserver` invocation:
+for a general explanation of feature gates and how to enable and
+disable them.  The name of the feature gate for APF is
+"APIPriorityAndFairness".  This feature also involves an {{<
+glossary_tooltip term_id="api-group" text="API Group" >}} with: (a) a
+`v1alpha1` version, disabled by default, and (b) a `v1beta1`
+version,  enabled by default.  You can disable the feature
+gate and API group v1beta1 version by adding the following
+command-line flags to your `kube-apiserver` invocation:
 
 ```shell
 kube-apiserver \
---feature-gates=APIPriorityAndFairness=true \
---runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true \
+--feature-gates=APIPriorityAndFairness=false \
+--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=false \
  # …and other flags as usual
 ```
 
+Alternatively, you can enable the v1alpha1 version of the API group
+with `--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=true`.
+
 The command-line flag `--enable-priority-and-fairness=false` will disable the
 API Priority and Fairness feature, even if other flags have enabled it.
 
@@ -189,12 +194,14 @@ that originate from outside your cluster.
 
 ## Resources
 The flow control API involves two kinds of resources.
-[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io)
+[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1beta1-flowcontrol-apiserver-k8s-io)
 define the available isolation classes, the share of the available concurrency
 budget that each can handle, and allow for fine-tuning queuing behavior.
-[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io)
-are used to classify individual inbound requests, matching each to a single
-PriorityLevelConfiguration.
+[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1beta1-flowcontrol-apiserver-k8s-io)
+are used to classify individual inbound requests, matching each to a
+single PriorityLevelConfiguration.  There is also a `v1alpha1` version
+of the same API group, and it has the same Kinds with the same syntax and
+semantics.
 
 ### PriorityLevelConfiguration
 A PriorityLevelConfiguration represents a single isolation class. Each
@@ -331,6 +338,13 @@ PriorityLevelConfigurations.
 
 ### Metrics
 
+{{< note >}}
+In versions of Kubernetes before v1.20, the labels `flow_schema` and
+`priority_level` were inconsistently named `flowSchema` and `priorityLevel`,
+respectively. If you're running Kubernetes versions v1.19 and earlier, you
+should refer to the documentation for your version.
+{{< /note >}}
+
 When you enable the API Priority and Fairness feature, the kube-apiserver
 exports additional metrics. Monitoring these can help you determine whether your
 configuration is inappropriately throttling important traffic, or find
@@ -338,8 +352,8 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_rejected_requests_total` is a counter vector
   (cumulative since server start) of requests that were rejected,
-  broken down by the labels `flowSchema` (indicating the one that
-  matched the request), `priorityLevel` (indicating the one to which
+  broken down by the labels `flow_schema` (indicating the one that
+  matched the request), `priority_level` (indicating the one to which
   the request was assigned), and `reason`.  The `reason` label will be
   have one of the following values:
     * `queue-full`, indicating that too many requests were already
@@ -352,8 +366,8 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_dispatched_requests_total` is a counter
   vector (cumulative since server start) of requests that began
-  executing, broken down by the labels `flowSchema` (indicating the
-  one that matched the request) and `priorityLevel` (indicating the
+  executing, broken down by the labels `flow_schema` (indicating the
+  one that matched the request) and `priority_level` (indicating the
   one to which the request was assigned).
 
 * `apiserver_current_inqueue_requests` is a gauge vector of recent
@@ -384,17 +398,17 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_current_inqueue_requests` is a gauge vector
   holding the instantaneous number of queued (not executing) requests,
-  broken down by the labels `priorityLevel` and `flowSchema`.
+  broken down by the labels `priority_level` and `flow_schema`.
 
 * `apiserver_flowcontrol_current_executing_requests` is a gauge vector
   holding the instantaneous number of executing (not waiting in a
-  queue) requests, broken down by the labels `priorityLevel` and
-  `flowSchema`.
+  queue) requests, 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
-  values `waiting` and `executing`) and `priorityLevel`.  Each
+  values `waiting` and `executing`) and `priority_level`.  Each
   histogram gets observations taken periodically, up through the last
   activity of the relevant sort.  The observations are made at a high
   rate.
@@ -402,7 +416,7 @@ poorly-behaved workloads that may be harming system health.
 * `apiserver_flowcontrol_priority_level_request_count_watermarks` is a
   histogram vector of high or low water marks of the number of
   requests broken down by the labels `phase` (which takes on the
-  values `waiting` and `executing`) and `priorityLevel`; the label
+  values `waiting` and `executing`) and `priority_level`; the label
   `mark` takes on values `high` and `low`.  The water marks are
   accumulated over windows bounded by the times when an observation
   was added to
@@ -411,7 +425,7 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_request_queue_length_after_enqueue` is a
   histogram vector of queue lengths for the queues, broken down by
-  the labels `priorityLevel` and `flowSchema`, as sampled by the
+  the labels `priority_level` and `flow_schema`, as sampled by the
   enqueued requests.  Each request that gets queued contributes one
   sample to its histogram, reporting the length of the queue just
   after the request was added.  Note that this produces different
@@ -426,14 +440,14 @@ poorly-behaved workloads that may be harming system health.
     {{< /note >}}
 
 * `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector
-  hoding the computed concurrency limit (based on the API server's
+  holding the computed concurrency limit (based on the API server's
   total concurrency limit and PriorityLevelConfigurations' concurrency
-  shares), broken down by the label `priorityLevel`.
+  shares), broken down by the label `priority_level`.
 
 * `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram
   vector of how long requests spent queued, broken down by the labels
-  `flowSchema` (indicating which one matched the request),
-  `priorityLevel` (indicating the one to which the request was
+  `flow_schema` (indicating which one matched the request),
+  `priority_level` (indicating the one to which the request was
   assigned), and `execute` (indicating whether the request started
   executing).
     {{< note >}}
@@ -445,8 +459,8 @@ poorly-behaved workloads that may be harming system health.
 
 * `apiserver_flowcontrol_request_execution_seconds` is a histogram
   vector of how long requests took to actually execute, broken down by
-  the labels `flowSchema` (indicating which one matched the request)
-  and `priorityLevel` (indicating the one to which the request was
+  the labels `flow_schema` (indicating which one matched the request)
+  and `priority_level` (indicating the one to which the request was
   assigned).
 
 ### Debug endpoints
@@ -515,4 +529,3 @@ For background information on design details for API priority and fairness, see
 the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
 You can make suggestions and feature requests via [SIG API
 Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
-

content/en/docs/concepts/cluster-administration/logging.md

@@ -80,7 +80,7 @@ default rotation is configured to take place when log file exceeds 10MB.
 
 As an example, you can find detailed information about how `kube-up.sh` sets
 up logging for COS image on GCP in the corresponding
-[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
+[script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh).
 
 When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
 the basic logging example, the kubelet on the node handles the request and

content/en/docs/concepts/cluster-administration/networking.md

@@ -58,10 +58,11 @@ to containers.  If your job previously ran in a VM, your VM had an IP and could
 talk to other VMs in your project.  This is the same basic model.
 
 Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod`
-share their network namespaces - including their IP address.  This means that
-containers within a `Pod` can all reach each other's ports on `localhost`. This
-also means that containers within a `Pod` must coordinate port usage, but this
-is no different from processes in a VM.  This is called the "IP-per-pod" model.
+share their network namespaces - including their IP address and MAC address.
+This means that containers within a `Pod` can all reach each other's ports on
+`localhost`. This also means that containers within a `Pod` must coordinate port
+usage, but this is no different from processes in a VM.  This is called the
+"IP-per-pod" model.
 
 How this is implemented is a detail of the particular container runtime in use.
 
@@ -158,6 +159,11 @@ tables to provide per-instance subnets to each host (which is limited to 50-100
 entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the
 network complexity required to deploy Kubernetes at scale within AWS.
 
+### Coil
+
+[Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking.
+Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.
+
 ### Contiv
 
 [Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.
@@ -311,4 +317,4 @@ to run, and in both cases, the network provides one IP address per pod - as is s
 
 The early design of the networking model and its rationale, and some future
 plans are described in more detail in the
-[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
+[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).

content/en/docs/concepts/cluster-administration/system-logs.md

@@ -91,6 +91,27 @@ List of components currently supporting JSON format:
 * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
 * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
 
+### Log sanitization
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+{{<warning >}}
+Log sanitization might incur significant computation overhead and therefore should not be enabled in production.
+{{< /warning >}}
+
+The `--experimental-logging-sanitization` flag enables the klog sanitization filter.
+If enabled all log arguments are inspected for fields tagged as sensitive data (e.g. passwords, keys, tokens) and logging of these fields will be prevented.
+
+List of components currently supporting log sanitization:
+* kube-controller-manager
+* kube-apiserver
+* kube-scheduler
+* kubelet
+
+{{< note >}}
+The Log sanitization filter does not prevent user workload logs from leaking sensitive data.
+{{< /note >}}
+
 ### Log verbosity level
 
 The `-v` flag controls log verbosity. Increasing the value increases the number of logged events. Decreasing the value decreases the number of logged events.

content/en/docs/concepts/cluster-administration/system-metrics.md

@@ -104,7 +104,7 @@ The kubelet collects accelerator metrics through cAdvisor. To collect these metr
 
 The responsibility for collecting accelerator metrics now belongs to the vendor rather than the kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics service (for example, Prometheus).
 
-The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
+The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria).
 
 ## Component metrics
 
@@ -129,6 +129,28 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
 cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
 ```
 
+
+### kube-scheduler metrics
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+The scheduler exposes optional metrics that reports the requested resources and the desired limits of all running pods. These metrics can be used to build capacity planning dashboards, assess current or historical scheduling limits, quickly identify workloads that cannot schedule due to lack of resources, and compare actual usage to the pod's request.
+
+The kube-scheduler identifies the resource [requests and limits](/docs/concepts/configuration/manage-resources-containers/) configured for each Pod; when either a request or limit is non-zero, the kube-scheduler reports a metrics timeseries. The time series is labelled by:
+- namespace
+- pod name
+- the node where the pod is scheduled or an empty string if not yet scheduled
+- priority
+- the assigned scheduler for that pod
+- the name of the resource (for example, `cpu`)
+- the unit of the resource if known (for example, `cores`)
+
+Once a pod reaches completion (has a `restartPolicy` of `Never` or `OnFailure` and is in the `Succeeded` or `Failed` pod phase, or has been deleted and all containers have a terminated state) the series is no longer reported since the scheduler is now free to schedule other pods to run. The two metrics are called `kube_pod_resource_request` and `kube_pod_resource_limit`.
+
+The metrics are exposed at the HTTP endpoint `/metrics/resources` and require the same authorization as the `/metrics`
+endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1.20` flag to expose these alpha stability metrics.
+
+
 ## {{% heading "whatsnext" %}}
 
 * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics

content/en/docs/concepts/configuration/configmap.md

@@ -31,7 +31,7 @@ This lets you fetch a container image running in the cloud and
 debug the exact same code locally if needed.
 
 A ConfigMap is not designed to hold large chunks of data. The data stored in a
-ConfigMap cannot exeed 1 MiB. If you need to store settings that are
+ConfigMap cannot exceed 1 MiB. If you need to store settings that are
 larger than this limit, you may want to consider mounting a volume or use a
 separate database or file service.
 
@@ -88,7 +88,7 @@ data:
 There are four different ways that you can use a ConfigMap to configure
 a container inside a Pod:
 
-1. Command line arguments to the entrypoint of a container
+1. Inside a container command and args
 1. Environment variables for a container
 1. Add a file in read-only volume, for the application to read
 1. Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap

content/en/docs/concepts/configuration/manage-resources-containers.md

@@ -600,6 +600,10 @@ spec:
         example.com/foo: 1
 ```
 
+## PID limiting
+
+Process ID (PID) limits allow for the configuration of a kubelet to limit the number of PIDs that a given Pod can consume. See [Pid Limiting](/docs/concepts/policy/pid-limiting/) for information.
+
 ## Troubleshooting
 
 ### My Pods are pending with event message failedScheduling

content/en/docs/concepts/configuration/pod-priority-preemption.md

@@ -321,9 +321,7 @@ Pod may be created that fits on the same Node. In this case, the scheduler will
 schedule the higher priority Pod instead of the preemptor.
 
 This is expected behavior: the Pod with the higher priority should take the place
-of a Pod with a lower priority. Other controller actions, such as
-[cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling),
-may eventually provide capacity to schedule the pending Pods.
+of a Pod with a lower priority.
 
 ### Higher priority Pods are preempted before lower priority pods
 

content/en/docs/concepts/configuration/secret.md

@@ -137,7 +137,7 @@ See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-a
 documentation for more information on how service accounts work.
 You can also check the `automountServiceAccountToken` field and the
 `serviceAccountName` field of the
-[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 for information on referencing service account from Pods.
 
 ### Docker config Secrets
@@ -154,7 +154,7 @@ When using this Secret type, you have to ensure the Secret `data` field
 contains a `.dockercfg` key whose value is content of a `~/.dockercfg` file
 encoded in the base64 format.
 
-The `kubernetes/dockerconfigjson` type is designed for storing a serialized
+The `kubernetes.io/dockerconfigjson` type is designed for storing a serialized
 JSON that follows the same format rules as the `~/.docker/config.json` file
 which is a new format for `~/.dockercfg`.
 When using this Secret type, the `data` field of the Secret object must
@@ -248,7 +248,7 @@ configuration.
 
 The builtin type `kubernetes.io/ssh-auth` is provided for storing data used in
 SSH authentication. When using this Secret type, you will have to specify a
-`ssh-privatekey` key-value pair in the `data` (or `stringData`) field.
+`ssh-privatekey` key-value pair in the `data` (or `stringData`) field
 as the SSH credential to use.
 
 The following YAML is an example config for a SSH authentication Secret:
@@ -349,22 +349,21 @@ data:
   usage-bootstrap-signing: dHJ1ZQ==
 ```
 
-A bootstrap type has the following keys specified under `data`:
+A bootstrap type Secret has the following keys specified under `data`:
 
 - `token_id`: A random 6 character string as the token identifier. Required.
 - `token-secret`: A random 16 character string as the actual token secret. Required.
-- `description1`: A human-readable string that describes what the token is
+- `description`: A human-readable string that describes what the token is
   used for. Optional.
 - `expiration`: An absolute UTC time using RFC3339 specifying when the token
   should be expired. Optional.
 - `usage-bootstrap-<usage>`: A boolean flag indicating additional usage for
   the bootstrap token.
 - `auth-extra-groups`: A comma-separated list of group names that will be
-  authenticated as in addition to system:bootstrappers group.
+  authenticated as in addition to the `system:bootstrappers` group.
 
 The above YAML may look confusing because the values are all in base64 encoded
-strings. In fact, you can create an identical Secret using the following YAML
-which results in an identical Secret object:
+strings. In fact, you can create an identical Secret using the following YAML:
 
 ```yaml
 apiVersion: v1

content/en/docs/concepts/containers/images.md

@@ -84,7 +84,7 @@ Credentials can be provided in several ways:
       provider) can implement your mechanism for authenticating the node
       to the container registry.
 
-These options are explaind in more detail below.
+These options are explained in more detail below.
 
 ### Configuring nodes to authenticate to a private registry
 

content/en/docs/concepts/containers/runtime-class.md

@@ -9,7 +9,7 @@ weight: 20
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.14" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
 This page describes the RuntimeClass resource and runtime selection mechanism.
 
@@ -66,7 +66,7 @@ The RuntimeClass resource currently only has 2 significant fields: the RuntimeCl
 (`metadata.name`) and the handler (`handler`). The object definition looks like this:
 
 ```yaml
-apiVersion: node.k8s.io/v1beta1  # RuntimeClass is defined in the node.k8s.io API group
+apiVersion: node.k8s.io/v1  # RuntimeClass is defined in the node.k8s.io API group
 kind: RuntimeClass
 metadata:
   name: myclass  # The name the RuntimeClass will be referenced by
@@ -186,4 +186,3 @@ are accounted for in Kubernetes.
 - Read about the [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) concept
 - [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
 
-

content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

@@ -204,7 +204,8 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
 {{< glossary_tooltip term_id="volume" >}} in the plugin's
 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
 
-Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15.
+Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
+It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20.
 
 ## Device Plugin integration with the Topology Manager
 

content/en/docs/concepts/overview/kubernetes-api.md

@@ -77,19 +77,10 @@ about this format, see the [Kubernetes Protobuf serialization](https://github.co
 Interface Definition Language (IDL) files for each schema located in the Go
 packages that define the API objects.
 
-## API changes
+## Persistence
 
-Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
-Therefore, Kubernetes has designed its features to allow the Kubernetes API to continuously change and grow.
-The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
-compatibility for a length of time so that other projects have an opportunity to adapt.
-
-In general, new API resources and new resource fields can be added often and frequently.
-Elimination of resources or fields requires following the
-[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
-
-What constitutes a compatible change, and how to change the API, are detailed in
-[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).
+Kubernetes stores the serialized state of objects by writing them into
+{{< glossary_tooltip term_id="etcd" >}}.
 
 ## API groups and versioning
 
@@ -107,17 +98,44 @@ To make it easier to evolve and to extend its API, Kubernetes implements
 [enabled or disabled](/docs/reference/using-api/#enabling-or-disabling).
 
 API resources are distinguished by their API group, resource type, namespace
-(for namespaced resources), and name. The API server may serve the same
-underlying data through multiple API version and handle the conversion between
-API versions transparently. All these different versions are actually
-representations of the same resource. For example, suppose there are two
-versions `v1` and `v1beta1` for the same resource. An object created by the
-`v1beta1` version can then be read, updated, and deleted by either the
-`v1beta1` or the `v1` versions.
+(for namespaced resources), and name. The API server handles the conversion between
+API versions transparently: all the different versions are actually representations
+of the same persisted data. The API server may serve the same underlying data
+through multiple API versions.
+
+For example, suppose there are two API versions, `v1` and `v1beta1`, for the same
+resource. If you originally created an object using the `v1beta1` version of its
+API, you can later read, update, or delete that object
+using either the `v1beta1` or the `v1` API version.
+
+### API changes
+
+Any system that is successful needs to grow and change as new use cases emerge or existing ones change.
+Therefore, Kubernetes has designed the Kubernetes API to continuously change and grow.
+The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that
+compatibility for a length of time so that other projects have an opportunity to adapt.
+
+In general, new API resources and new resource fields can be added often and frequently.
+Elimination of resources or fields requires following the
+[API deprecation policy](/docs/reference/using-api/deprecation-policy/).
+
+Kubernetes makes a strong commitment to maintain compatibility for official Kubernetes APIs
+once they reach general availability (GA), typically at API version `v1`. Additionally,
+Kubernetes keeps compatibility even for _beta_ API versions wherever feasible:
+if you adopt a beta API you can continue to interact with your cluster using that API,
+even after the feature goes stable.
+
+{{< note >}}
+Although Kubernetes also aims to maintain compatibility for _alpha_ APIs versions, in some
+circumstances this is not possible. If you use any alpha API versions, check the release notes
+for Kubernetes when upgrading your cluster, in case the API did change.
+{{< /note >}}
 
 Refer to [API versions reference](/docs/reference/using-api/#api-versioning)
 for more details on the API version level definitions.
 
+
+
 ## API Extension
 
 The Kubernetes API can be extended in one of two ways:
@@ -135,3 +153,5 @@ The Kubernetes API can be extended in one of two ways:
   how the cluster manages authentication and authorization for API access.
 - Learn about API endpoints, resource types and samples by reading
   [API Reference](/docs/reference/kubernetes-api/).
+- Learn about what constitutes a compatible change, and how to change the API, from
+  [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme).

content/en/docs/concepts/overview/working-with-objects/labels.md

@@ -140,10 +140,11 @@ partition
 !partition
 ```
 
-The first example selects all resources with key equal to `environment` and value equal to `production` or `qa`.
-The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key.
-The third example selects all resources including a label with key `partition`; no values are checked.
-The fourth example selects all resources without a label with key `partition`; no values are checked.
+* The first example selects all resources with key equal to `environment` and value equal to `production` or `qa`.
+* The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key.
+* The third example selects all resources including a label with key `partition`; no values are checked.
+* The fourth example selects all resources without a label with key `partition`; no values are checked.
+
 Similarly the comma separator acts as an _AND_ operator. So filtering resources with a `partition` key (no matter the value) and with `environment` different than  `qa` can be achieved using `partition,environment notin (qa)`.
 The _set-based_ label selector is a general form of equality since `environment=production` is equivalent to `environment in (production)`; similarly for `!=` and `notin`.
 

content/en/docs/concepts/policy/pid-limiting.md

@@ -0,0 +1,99 @@
+---
+reviewers:
+- derekwaynecarr
+title: Process ID Limits And Reservations
+content_type: concept
+weight: 40
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
+
+Kubernetes allow you to limit the number of process IDs (PIDs) that a {{< glossary_tooltip term_id="Pod" text="Pod" >}} can use.
+You can also reserve a number of allocatable PIDs for each {{< glossary_tooltip term_id="node" text="node" >}}
+for use by the operating system and daemons (rather than by Pods).
+
+<!-- body -->
+
+Process IDs (PIDs) are a fundamental resource on nodes. It is trivial to hit the
+task limit without hitting any other resource limits, which can then cause
+instability to a host machine.
+
+Cluster administrators require mechanisms to ensure that Pods running in the
+cluster cannot induce PID exhaustion that prevents host daemons (such as the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} or
+{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}},
+and potentially also the container runtime) from running.
+In addition, it is important to ensure that PIDs are limited among Pods in order
+to ensure they have limited impact on other workloads on the same node.
+
+{{< note >}}
+On certain Linux installations, the operating system sets the PIDs limit to a low default,
+such as `32768`. Consider raising the value of `/proc/sys/kernel/pid_max`.
+{{< /note >}}
+
+You can configure a kubelet to limit the number of PIDs a given pod can consume.
+For example, if your node's host OS is set to use a maximum of `262144` PIDs and
+expect to host less than `250` pods, one can give each pod a budget of `1000`
+PIDs to prevent using up that node's overall number of available PIDs. If the
+admin wants to overcommit PIDs similar to CPU or memory, they may do so as well
+with some additional risks. Either way, a single pod will not be able to bring
+the whole machine down. This kind of resource limiting helps to prevent simple
+fork bombs from affecting operation of an entire cluster.
+
+Per-pod PID limiting allows administrators to protect one pod from another, but
+does not ensure that all Pods scheduled onto that host are unable to impact the node overall.
+Per-Pod limiting also does not protect the node agents themselves from PID exhaustion.
+
+You can also reserve an amount of PIDs for node overhead, separate from the
+allocation to Pods. This is similar to how you can reserve CPU, memory, or other
+resources for use by the operating system and other facilities outside of Pods
+and their containers.
+
+PID limiting is a an important sibling to [compute
+resource](/docs/concepts/configuration/manage-resources-containers/) requests
+and limits. However, you specify it in a different way: rather than defining a
+Pod's resource limit in the `.spec` for a Pod, you configure the limit as a
+setting on the kubelet. Pod-defined PID limits are not currently supported.
+
+{{< caution >}}
+This means that the limit that applies to a Pod may be different depending on
+where the Pod is scheduled. To make things simple, it's easiest if all Nodes use
+the same PID resource limits and reservations.
+{{< /caution >}}
+
+## Node PID limits
+
+Kubernetes allows you to reserve a number of process IDs for the system use. To
+configure the reservation, use the parameter `pid=<number>` in the
+`--system-reserved` and `--kube-reserved` command line options to the kubelet.
+The value you specified declares that the specified number of process IDs will
+be reserved for the system as a whole and for Kubernetes system daemons
+respectively.
+
+{{< note >}}
+Before Kubernetes version 1.20, PID resource limiting with Node-level
+reservations required enabling the [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`SupportNodePidsLimit` to work.
+{{< /note >}}
+
+## Pod PID limits
+
+Kubernetes allows you to limit the number of processes running in a Pod. You
+specify this limit at the node level, rather than configuring it as a resource
+limit for a particular Pod. Each Node can have a different PID limit.  
+To configure the limit, you can specify the command line parameter `--pod-max-pids` to the kubelet, or set `PodPidsLimit` in the kubelet [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/).
+
+{{< note >}}
+Before Kubernetes version 1.20, PID resource limiting for Pods required enabling
+the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`SupportPodPidsLimit` to work.
+{{< /note >}}
+
+## {{% heading "whatsnext" %}}
+
+- Refer to the [PID Limiting enhancement document](https://github.com/kubernetes/enhancements/blob/097b4d8276bc9564e56adf72505d43ce9bc5e9e8/keps/sig-node/20190129-pid-limiting.md) for more information.
+- For historical context, read [Process ID Limiting for Stability Improvements in Kubernetes 1.14](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/).
+- Read [Managing Resources for Containers](/docs/concepts/configuration/manage-resources-containers/).

content/en/docs/concepts/policy/pod-security-policy.md

@@ -4,7 +4,7 @@ reviewers:
 - tallclair
 title: Pod Security Policies
 content_type: concept
-weight: 20
+weight: 30
 ---
 
 <!-- overview -->

content/en/docs/concepts/policy/resource-quotas.md

@@ -3,7 +3,7 @@ reviewers:
 - derekwaynecarr
 title: Resource Quotas
 content_type: concept
-weight: 10
+weight: 20
 ---
 
 <!-- overview -->
@@ -76,8 +76,7 @@ The following resource types are supported:
 | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. |
 | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
-| `hugepages-<size>` | Across all pods in a non-terminal state, the number of
-huge page requests of the specified size cannot exceed this value. |
+| `hugepages-<size>` | Across all pods in a non-terminal state, the number of huge page requests of the specified size cannot exceed this value. |
 | `cpu` | Same as `requests.cpu` |
 | `memory` | Same as `requests.memory` |
 
@@ -237,7 +236,7 @@ one value. For example:
           - middle
 ```
 
-If the `operator` is `Exists` or `DoesNotExist`, the `values field must *NOT* be
+If the `operator` is `Exists` or `DoesNotExist`, the `values` field must *NOT* be
 specified.
 
 ### Resource Quota Per PriorityClass

content/en/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -158,6 +158,49 @@ If you remove or change the label of the node where the pod is scheduled, the po
 
 The `weight` field in `preferredDuringSchedulingIgnoredDuringExecution` is in the range 1-100. For each node that meets all of the scheduling requirements (resource request, RequiredDuringScheduling affinity expressions, etc.), the scheduler will compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding MatchExpressions. This score is then combined with the scores of other priority functions for the node. The node(s) with the highest total score are the most preferred.
 
+#### Node affinity per scheduling profile
+
+{{< feature-state for_k8s_version="v1.20" state="beta" >}}
+
+When configuring multiple [scheduling profiles](/docs/reference/scheduling/config/#multiple-profiles), you can associate
+a profile with a Node affinity, which is useful if a profile only applies to a specific set of Nodes.
+To do so, add an `addedAffinity` to the args of the [`NodeAffinity` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
+in the [scheduler configuration](/docs/reference/scheduling/config/). For example:
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - schedulerName: default-scheduler
+  - schedulerName: foo-scheduler
+    pluginConfig:
+      - name: NodeAffinity
+        args:
+          addedAffinity:
+            requiredDuringSchedulingIgnoredDuringExecution:
+              nodeSelectorTerms:
+              - matchExpressions:
+                - key: scheduler-profile
+                  operator: In
+                  values:
+                  - foo
+```
+
+The `addedAffinity` is applied to all Pods that set `.spec.schedulerName` to `foo-scheduler`, in addition to the
+NodeAffinity specified in the PodSpec.
+That is, in order to match the Pod, Nodes need to satisfy `addedAffinity` and the Pod's `.spec.NodeAffinity`.
+
+Since the `addedAffinity` is not visible to end users, its behavior might be unexpected to them. We
+recommend to use node labels that have clear correlation with the profile's scheduler name.
+
+{{< note >}}
+The DaemonSet controller, which [creates Pods for DaemonSets](/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)
+is not aware of scheduling profiles. For this reason, it is recommended that you keep a scheduler profile, such as the
+`default-scheduler`, without any `addedAffinity`. Then, the Daemonset's Pod template should use this scheduler name.
+Otherwise, some Pods created by the Daemonset controller might remain unschedulable.
+{{< /note >}}
+
 ### Inter-pod affinity and anti-affinity
 
 Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on

content/en/docs/concepts/scheduling-eviction/pod-overhead.md

@@ -48,7 +48,7 @@ that uses around 120MiB per Pod for the virtual machine and the guest OS:
 ```yaml
 ---
 kind: RuntimeClass
-apiVersion: node.k8s.io/v1beta1
+apiVersion: node.k8s.io/v1
 metadata:
     name: kata-fc
 handler: kata-fc

content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md

@@ -12,125 +12,147 @@ weight: 50
 
 {{< feature-state for_k8s_version="v1.16" state="alpha" >}}
 
-The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs. 
-
-
+The kube-scheduler can be configured to enable bin packing of resources along
+with extended resources using `RequestedToCapacityRatioResourceAllocation`
+priority function. Priority functions can be used to fine-tune the
+kube-scheduler as per custom needs. 
 
 <!-- body -->
 
 ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
 
-Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
-consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
+Kubernetes allows the users to specify the resources along with weights for
+each resource to score nodes based on the request to capacity ratio. This
+allows users to bin pack extended resources by using appropriate parameters
+and improves the utilization of scarce resources in large clusters. The
+behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
+can be controlled by a configuration option called
+`requestedToCapacityRatioArguments`. This argument consists of two parameters
+`shape` and `resources`. The `shape` parameter allows the user to tune the
+function as least requested or most requested based on `utilization` and
+`score` values.  The `resources` parameter consists of `name` of the resource
+to be considered during scoring and `weight` specify the weight of each
+resource.
 
-Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
+Below is an example configuration that sets
+`requestedToCapacityRatioArguments` to bin packing behavior for extended
+resources `intel.com/foo` and `intel.com/bar`.
 
-```json
-{
-    "kind" : "Policy",
-    "apiVersion" : "v1",
-
-    ...
-
-    "priorities" : [
-
-       ...
-
-      {
-        "name": "RequestedToCapacityRatioPriority",
-        "weight": 2,
-        "argument": {
-          "requestedToCapacityRatioArguments": {
-            "shape": [
-              {"utilization": 0, "score": 0},
-              {"utilization": 100, "score": 10}
-            ],
-            "resources": [
-              {"name": "intel.com/foo", "weight": 3},
-              {"name": "intel.com/bar", "weight": 5}
-            ]
-          }
-        }
-      }
-    ],
-  }
+```yaml
+apiVersion: v1
+kind: Policy
+# ...
+priorities:
+  # ...
+  - name: RequestedToCapacityRatioPriority
+    weight: 2
+    argument:
+      requestedToCapacityRatioArguments:
+        shape:
+          - utilization: 0
+            score: 0
+          - utilization: 100
+            score: 10
+        resources:
+          - name: intel.com/foo
+            weight: 3
+          - name: intel.com/bar
+            weight: 5
 ```
 
 **This feature is disabled by default**
 
-### Tuning RequestedToCapacityRatioResourceAllocation Priority Function
+### Tuning the Priority Function
 
-`shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function.
+`shape` is used to specify the behavior of the
+`RequestedToCapacityRatioPriority` function.
 
 ```yaml
- {"utilization": 0, "score": 0},
- {"utilization": 100, "score": 10}
+shape:
+ - utilization: 0
+   score: 0
+ - utilization: 100
+   score: 10
 ```
 
-The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows.
+The above arguments give the node a `score` of 0 if `utilization` is 0% and 10 for
+`utilization` 100%, thus enabling bin packing behavior. To enable least
+requested the score value must be reversed as follows.
 
 ```yaml
- {"utilization": 0, "score": 100},
- {"utilization": 100, "score": 0}
+shape:
+  - utilization: 0
+    score: 100
+  - utilization: 100
+    score: 0
 ```
 
-`resources` is an optional parameter which by defaults is set to:
+`resources` is an optional parameter which defaults to:
 
 ``` yaml
-"resources": [
-              {"name": "CPU", "weight": 1},
-              {"name": "Memory", "weight": 1}
-            ]
+resources:
+  - name: CPU
+    weight: 1
+  - name: Memory
+    weight: 1
 ```
 
 It can be used to add extended resources as follows: 
 
 ```yaml
-"resources": [
-              {"name": "intel.com/foo", "weight": 5},
-              {"name": "CPU", "weight": 3},
-              {"name": "Memory", "weight": 1}
-            ]
+resources:
+  - name: intel.com/foo
+    weight: 5
+  - name: CPU
+    weight: 3
+  - name: Memory
+    weight: 1
 ```
 
-The weight parameter is optional and is set to 1 if not specified. Also, the weight cannot be set to a negative value.
+The `weight` parameter is optional and is set to 1 if not specified. Also, the
+`weight` cannot be set to a negative value.
 
-### How the RequestedToCapacityRatioResourceAllocation Priority Function Scores Nodes
+### Node scoring for capacity allocation
 
 This section is intended for those who want to understand the internal details
 of this feature.
 Below is an example of how the node score is calculated for a given set of values.
 
-```
-Requested Resources
+Requested resources:
 
+```
 intel.com/foo : 2
 Memory: 256MB
 CPU: 2
+```
 
-Resource Weights
+Resource weights:
 
+```
 intel.com/foo : 5
 Memory: 1
 CPU: 3
+```
 
 FunctionShapePoint {{0, 0}, {100, 10}}
 
-Node 1 Spec
+Node 1 spec:
 
+```
 Available:
-intel.com/foo : 4
-Memory : 1 GB
-CPU: 8
+  intel.com/foo: 4
+  Memory: 1 GB
+  CPU: 8
 
 Used:
-intel.com/foo: 1
-Memory: 256MB
-CPU: 1
+  intel.com/foo: 1
+  Memory: 256MB
+  CPU: 1
+```
 
+Node score:
 
-Node Score:
-
+```
 intel.com/foo  = resourceScoringFunction((2+1),4)
                = (100 - ((4-3)*100/4)
                = (100 - 25)
@@ -152,24 +174,24 @@ CPU            = resourceScoringFunction((2+1),8)
 
 NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
             =  5
+```
 
+Node 2 spec:
 
-Node 2 Spec
-
+```
 Available:
-intel.com/foo: 8
-Memory: 1GB
-CPU: 8
-
+  intel.com/foo: 8
+  Memory: 1GB
+  CPU: 8
 Used:
+  intel.com/foo: 2
+  Memory: 512MB
+  CPU: 6
+```
 
-intel.com/foo: 2
-Memory: 512MB
-CPU: 6
-
-
-Node Score:
+Node score:
 
+```
 intel.com/foo  = resourceScoringFunction((2+2),8)
                =  (100 - ((8-4)*100/8)
                =  (100 - 50)
@@ -194,4 +216,8 @@ NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
 
 ```
 
+## {{% heading "whatsnext" %}}
+
+- Read more about the [scheduling framework](/docs/concepts/scheduling-eviction/scheduling-framework/)
+- Read more about [scheduler configuration](/docs/reference/scheduling/config/)
 

content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -32,15 +32,15 @@ You add a taint to a node using [kubectl taint](/docs/reference/generated/kubect
 For example,
 
 ```shell
-kubectl taint nodes node1 key=value:NoSchedule
+kubectl taint nodes node1 key1=value1:NoSchedule
 ```
 
-places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`.
+places a taint on node `node1`. The taint has key `key1`, value `value1`, and taint effect `NoSchedule`.
 This means that no pod will be able to schedule onto `node1` unless it has a matching toleration.
 
 To remove the taint added by the command above, you can run:
 ```shell
-kubectl taint nodes node1 key:NoSchedule-
+kubectl taint nodes node1 key1=value1:NoSchedule-
 ```
 
 You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the
@@ -49,15 +49,15 @@ to schedule onto `node1`:
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Equal"
-  value: "value"
+  value: "value1"
   effect: "NoSchedule"
 ```
 
 ```yaml
 tolerations:
-- key: "key"
+- key: "key1"
   operator: "Exists"
   effect: "NoSchedule"
 ```
@@ -80,7 +80,7 @@ There are two special cases:
 An empty `key` with operator `Exists` matches all keys, values and effects which means this
 will tolerate everything.
 
-An empty `effect` matches all effects with key `key`.
+An empty `effect` matches all effects with key `key1`.
 
 {{< /note >}}
 

content/en/docs/concepts/services-networking/dns-pod-service.md

@@ -168,11 +168,7 @@ record unless `publishNotReadyAddresses=True` is set on the Service.
 
 ### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field}
 
-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
-
-**Prerequisites**: The `SetHostnameAsFQDN` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-must be enabled for the
-{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}
+{{< feature-state for_k8s_version="v1.20" state="beta" >}}
 
 When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and  the `hostname --fqdn` command returns the FQDN.
 

content/en/docs/concepts/services-networking/dual-stack.md

@@ -3,6 +3,7 @@ reviewers:
 - lachie83
 - khenidak
 - aramase
+- bridgetkromhout
 title: IPv4/IPv6 dual-stack
 feature:
   title: IPv4/IPv6 dual-stack
@@ -30,14 +31,17 @@ If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the c
 Enabling IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features:
 
    * Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod)
-   * IPv4 and IPv6 enabled Services (each Service must be for a single address family)
+   * IPv4 and IPv6 enabled Services
    * Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces
 
 ## Prerequisites
 
 The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack Kubernetes clusters:
 
-   * Kubernetes 1.16 or later
+   * Kubernetes 1.20 or later  
+     For information about using dual-stack services with earlier
+     Kubernetes versions, refer to the documentation for that version
+     of Kubernetes.
    * 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 that supports dual-stack (such as Kubenet or Calico)
 
@@ -68,47 +72,173 @@ An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but
 
 ## Services
 
-If your cluster has IPv4/IPv6 dual-stack networking enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} with either an IPv4 or an IPv6 address. You can choose the address family for the Service's cluster IP by setting a field, `.spec.ipFamily`, on that Service.
-You can only set this field when creating a new Service. Setting the `.spec.ipFamily` field is optional and should only be used if you plan to enable IPv4 and IPv6 {{< glossary_tooltip text="Services" term_id="service" >}} and {{< glossary_tooltip text="Ingresses" term_id="ingress" >}} on your cluster. The configuration of this field not a requirement for [egress](#egress-traffic) traffic.
+If your cluster has dual-stack enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. 
+
+The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-controller-manager).
+
+When you define a Service you can optionally configure it as dual stack. To specify the behavior you want, you
+set the `.spec.ipFamilyPolicy` field to one of the following values:
+
+* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range.
+* `PreferDualStack`:
+  * Only used if the cluster has dual-stack enabled. Allocates IPv4 and IPv6 cluster IPs for the Service
+  * If the cluster does not have dual-stack enabled, this setting follows the same behavior as `SingleStack`.
+* `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges.
+  * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array.
+  * The cluster must have dual-stack networking configured.
+
+If you would like to define which IP family to use for single stack or define the order of IP families for dual-stack, you can choose the address families by setting an optional field, `.spec.ipFamilies`, on the Service. 
 
 {{< note >}}
-The default address family for your cluster is the address family of the first service cluster IP range configured via the `--service-cluster-ip-range` flag to the kube-controller-manager.
+The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the Service.
 {{< /note >}}
 
-You can set `.spec.ipFamily` to either:
+You can set `.spec.ipFamilies` to any of the following array values:
 
-   * `IPv4`: The API server will assign an IP from a `service-cluster-ip-range` that is `ipv4`
-   * `IPv6`: The API server will assign an IP from a `service-cluster-ip-range` that is `ipv6`
+- `["IPv4"]`
+- `["IPv6"]`
+- `["IPv4","IPv6"]` (dual stack)
+- `["IPv6","IPv4"]` (dual stack)
 
-The following Service specification does not include the `ipFamily` field. Kubernetes will assign an IP address (also known as a "cluster IP") from the first configured `service-cluster-ip-range` to this Service.
+The first family you list is used for the legacy `.spec.ClusterIP` field.
+
+### Dual-stack Service configuration scenarios
+
+These examples demonstrate the behavior of various dual-stack Service configuration scenarios.
+
+#### Dual-stack options on new Services
+
+1. This Service specification does not explicitly define `.spec.ipFamilyPolicy`. When you create this Service, Kubernetes assigns a cluster IP for the Service from the first configured `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors will behave in this same way.)
 
 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
 
-The following Service specification includes the `ipFamily` field. Kubernetes will assign an IPv6 address (also known as a "cluster IP") from the configured `service-cluster-ip-range` to this Service.
+1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 addresses for the service. The control plane updates the `.spec` for the Service to record the IP address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from `.spec.ClusterIPs`.
+   
+      * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the same address family as the first service cluster IP range. 
+      * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list one address. 
+      * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` behaves the same as `PreferDualStack`.
 
-{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
+{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
 
-For comparison, the following Service specification will be assigned an IPv4 address (also known as a "cluster IP") from the configured `service-cluster-ip-range` to this Service.
+1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is the first element in the `.spec.ClusterIPs` array, overriding the default.
 
-{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
+{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}
 
-### Type LoadBalancer
+#### Dual-stack defaults on existing Services
 
-On cloud providers which support IPv6 enabled external load balancers, setting the `type` field to `LoadBalancer` in additional to setting `ipFamily` field to `IPv6` provisions a cloud load balancer for your Service.
+These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist.
 
-## Egress Traffic
+1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP will be stored in `.spec.ClusterIPs`.
 
-The use of publicly routable and non-publicly routable IPv6 address blocks is acceptable provided the underlying {{< glossary_tooltip text="CNI" term_id="cni" >}} provider is able to implement the transport. If you have a Pod that uses non-publicly routable IPv6 and want that Pod to reach off-cluster destinations (eg. the public Internet), you must set up IP masquerading for the egress traffic and any replies. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) is dual-stack aware, so you can use ip-masq-agent for IP masquerading on dual-stack clusters.
+{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
 
-## Known Issues
+   You can validate this behavior by using kubectl to inspect an existing service.
 
-   * Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr)
+```shell
+kubectl get svc my-service -o yaml
+```
 
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: MyApp
+  name: my-service
+spec:
+  clusterIP: 10.0.197.123
+  clusterIPs:
+  - 10.0.197.123
+  ipFamilies:
+  - IPv4
+  ipFamilyPolicy: SingleStack
+  ports:
+  - port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:
+    app: MyApp
+  type: ClusterIP
+status:
+  loadBalancer: {}
+```
 
+1. When dual-stack is enabled on a cluster, existing [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-controller-manager) even though `.spec.ClusterIP` is set to `None`.
+
+{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+
+   You can validate this behavior by using kubectl to inspect an existing headless service with selectors.
+
+```shell
+kubectl get svc my-service -o yaml
+```
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: MyApp
+  name: my-service
+spec:
+  clusterIP: None
+  clusterIPs:
+  - None
+  ipFamilies:
+  - IPv4
+  ipFamilyPolicy: SingleStack
+  ports:
+  - port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:
+    app: MyApp
+```
+
+#### Switching Services between single-stack and dual-stack
+
+Services can be changed from single-stack to dual-stack and from dual-stack to single-stack.
+
+1. To change a Service from single-stack to dual-stack, change `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack` or `RequireDualStack` as desired. When you change this Service from single-stack to dual-stack, Kubernetes assigns the missing address family so that the Service now has IPv4 and IPv6 addresses.
+
+   Edit the Service specification updating the `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack`.
+
+Before:
+```yaml
+spec:
+  ipFamilyPolicy: SingleStack
+```
+After:
+```yaml
+spec:
+  ipFamilyPolicy: PreferDualStack
+```
+
+1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs` array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address family of `.spec.ClusterIPs`.
+
+### Headless Services without selector
+
+For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors) and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to `RequireDualStack`.
+
+### Service type LoadBalancer
+
+To provision a dual-stack load balancer for your Service:
+   * Set the `.spec.type` field to `LoadBalancer`
+   * Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack`
+
+{{< note >}}
+To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6 load balancers.
+{{< /note >}}
+
+## Egress traffic
+
+If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project supports IP masquerading on dual-stack clusters.
+
+{{< note >}}
+Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports IPv6.
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
 
 * [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
-
-

content/en/docs/concepts/services-networking/endpoint-slices.md

@@ -44,7 +44,7 @@ for any Kubernetes Service that has a {{< glossary_tooltip text="selector"
 term_id="selector" >}} specified. These EndpointSlices include
 references to all the Pods that match the Service selector. EndpointSlices group
 network endpoints together by unique combinations of protocol, port number, and
-Service name.  
+Service name.
 The name of a EndpointSlice object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
@@ -93,8 +93,58 @@ EndpointSlices support three address types:
 * IPv6
 * FQDN (Fully Qualified Domain Name)
 
+### Conditions
+
+The EndpointSlice API stores conditions about endpoints that may be useful for consumers.
+The three conditions are `ready`, `serving`, and `terminating`.
+
+#### Ready
+
+`ready` is a condition that maps to a Pod's `Ready` condition. A running Pod with the `Ready`
+condition set to `True` should have this EndpointSlice condition also set to `true`. For
+compatibility reasons, `ready` is NEVER `true` when a Pod is terminating. Consumers should refer
+to the `serving` condition to inspect the readiness of terminating Pods. The only exception to
+this rule is for Services with `spec.publishNotReadyAddresses` set to `true`. Endpoints for these
+Services will always have the `ready` condition set to `true`.
+
+#### Serving
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+`serving` is identical to the `ready` condition, except it does not account for terminating states.
+Consumers of the EndpointSlice API should check this condition if they care about pod readiness while
+the pod is also terminating.
+
+{{< note >}}
+
+Although `serving` is almost identical to `ready`, it was added to prevent break the existing meaning
+of `ready`. It may be unexpected for existing clients if `ready` could be `true` for terminating
+endpoints, since historically terminating endpoints were never included in the Endpoints or
+EndpointSlice API to begin with. For this reason, `ready` is _always_ `false` for terminating
+endpoints, and a new condition `serving` was added in v1.20 so that clients can track readiness
+for terminating pods independent of the existing semantics for `ready`.
+
+{{< /note >}}
+
+#### Terminating
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+`Terminating` is a condition that indicates whether an endpoint is terminating.
+For pods, this is any pod that has a deletion timestamp set.
+
 ### Topology information {#topology}
 
+{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
+
+{{< note >}}
+The topology field in EndpointSlices has been deprecated and will be removed in
+a future release. A new `nodeName` field will be used instead of setting
+`kubernetes.io/hostname` in topology. It was determined that other topology
+fields covering zone and region would be better represented as EndpointSlice
+labels that would apply to all endpoints within the EndpointSlice.
+{{< /note >}}
+
 Each endpoint within an EndpointSlice can contain relevant topology information.
 This is used to indicate where an endpoint is, containing information about the
 corresponding Node, zone, and region. When the values are available, the

content/en/docs/concepts/services-networking/ingress-controllers.md

@@ -13,40 +13,41 @@ Unlike other types of controllers which run as part of the `kube-controller-mana
 are not started automatically with a cluster. Use this page to choose the ingress controller implementation 
 that best fits your cluster.
 
-Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
-  [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
-  
+Kubernetes as a project supports and maintains [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme), and
+  [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) ingress controllers.
 
 
 <!-- body -->
 
 ## Additional controllers
 
-* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
-* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress 
-  controller with [community](https://www.getambassador.io/docs) or 
-  [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
-* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](https://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). 
-* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/).
-* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller
-  provided and supported by VMware.
-* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
-* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
-  for the [F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/).
-* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).  
-* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy.
-* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
-* [Istio](https://istio.io/) based ingress controller
-  [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
-* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or
-  [commercial](https://konghq.com/kong-enterprise/) support and maintenance for the
-  [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller).
-* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
-  [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
-* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy
-* [Traefik](https://github.com/traefik/traefik) is a fully featured ingress controller
-  ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
-  support by [Traefik Labs](https://traefik.io).
+{{% thirdparty-content %}}
+
+* [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
+* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress
+  controller.
+* The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with
+  Citrix Application Delivery Controller.
+* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based 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),
+  which offers API gateway functionality.
+* [HAProxy Ingress](https://haproxy-ingress.github.io/) is an ingress controller for
+  [HAProxy](http://www.haproxy.org/#desc).
+* The [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress#readme)
+  is also an ingress controller for [HAProxy](http://www.haproxy.org/#desc).
+* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)
+  is an [Istio](https://istio.io/) based ingress controller.
+* The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)
+  is an ingress controller driving [Kong Gateway](https://konghq.com/kong/).
+* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
+  works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy).
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy.
+* The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an
+  ingress controller for the [Traefik](https://traefik.io/traefik/) proxy.
+* [Voyager](https://appscode.com/products/voyager) is an ingress controller for
+  [HAProxy](http://www.haproxy.org/#desc).
 
 ## Using multiple Ingress controllers
 

content/en/docs/concepts/services-networking/service.md

@@ -203,10 +203,15 @@ described in detail in [EndpointSlices](/docs/concepts/services-networking/endpo
 
 ### Application protocol
 
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
-The `AppProtocol` field provides a way to specify an application protocol for each Service port.
-The value of this field is mirrored by corresponding Endpoints and EndpointSlice resources.
+The `appProtocol` field provides a way to specify an application protocol for
+each Service port. The value of this field is mirrored by the corresponding
+Endpoints and EndpointSlice objects.
+
+This field follows standard Kubernetes label syntax. Values should either be
+[IANA standard service names](http://www.iana.org/assignments/service-names) or
+domain prefixed names such as `mycompany.com/my-custom-protocol`.
 
 ## Virtual IPs and service proxies
 
@@ -578,21 +583,12 @@ status:
 
 Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced.
 
-For LoadBalancer type of Services, when there is more than one port defined, all
-ports must have the same protocol and the protocol must be one of `TCP`, `UDP`,
-and `SCTP`.
-
 Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created
 with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified,
 the loadBalancer is set up with an ephemeral IP address. If you specify a `loadBalancerIP`
 but your cloud provider does not support the feature, the `loadbalancerIP` field that you
 set is ignored.
 
-{{< note >}}
-If you're using SCTP, see the [caveat](#caveat-sctp-loadbalancer-service-type) below about the
-`LoadBalancer` Service type.
-{{< /note >}}
-
 {{< note >}}
 
 On **Azure**, if you want to use a user-specified public type `loadBalancerIP`, you first need
@@ -604,6 +600,34 @@ Specify the assigned IP address as loadBalancerIP. Ensure that you have updated
 
 {{< /note >}}
 
+#### Load balancers with mixed protocol types
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+By default, for LoadBalancer type of Services, when there is more than one port defined, all
+ports must have the same protocol, and the protocol must be one which is supported
+by the cloud provider.
+
+If the feature gate `MixedProtocolLBService` is enabled for the kube-apiserver it is allowed to use different protocols when there is more than one port defined.
+
+{{< note >}}
+
+The set of protocols that can be used for LoadBalancer type of Services is still defined by the cloud provider.
+
+{{< /note >}}
+
+#### Disabling load balancer NodePort allocation {#load-balancer-nodeport-allocation}
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+Starting in v1.20, you can optionally disable node port allocation for a Service Type=LoadBalancer by setting
+the field `spec.allocateLoadBalancerNodePorts` to `false`. This should only be used for load balancer implementations
+that route traffic directly to pods as opposed to using node ports. By default, `spec.allocateLoadBalancerNodePorts`
+is `true` and type LoadBalancer Services will continue to allocate node ports. If `spec.allocateLoadBalancerNodePorts`
+is set to `false` on an existing Service with allocated node ports, those node ports will NOT be de-allocated automatically.
+You must explicitly remove the `nodePorts` entry in every Service port to de-allocate those node ports.
+You must enable the `ServiceLBNodePortControl` feature gate to use this field.
+
 #### Internal load balancer
 
 In a mixed environment it is sometimes necessary to route traffic from Services inside the same
@@ -1184,6 +1208,36 @@ You can use TCP for any kind of Service, and it's the default network protocol.
 You can use UDP for most Services. For type=LoadBalancer Services, UDP support
 depends on the cloud provider offering this facility.
 
+### SCTP
+
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
+
+When using a network plugin that supports SCTP traffic, you can use SCTP for
+most Services. For type=LoadBalancer Services, SCTP support depends on the cloud
+provider offering this facility. (Most do not).
+
+#### Warnings {#caveat-sctp-overview}
+
+##### Support for multihomed SCTP associations {#caveat-sctp-multihomed}
+
+{{< warning >}}
+The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a Pod.
+
+NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.
+{{< /warning >}}
+
+##### Windows {#caveat-sctp-windows-os}
+
+{{< note >}}
+SCTP is not supported on Windows based nodes.
+{{< /note >}}
+
+##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace}
+
+{{< warning >}}
+The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
+{{< /warning >}}
+
 ### HTTP
 
 If your cloud provider supports it, you can use a Service in LoadBalancer mode
@@ -1211,42 +1265,6 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n
 
 followed by the data from the client.
 
-### SCTP
-
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
-Kubernetes supports SCTP as a `protocol` value in Service, Endpoints, EndpointSlice, NetworkPolicy and Pod definitions. As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`.
-
-When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoints, EndpointSlice, NetworkPolicy or Pod to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections.
-
-#### Warnings {#caveat-sctp-overview}
-
-##### Support for multihomed SCTP associations {#caveat-sctp-multihomed}
-
-{{< warning >}}
-The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a Pod.
-
-NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.
-{{< /warning >}}
-
-##### Service with type=LoadBalancer {#caveat-sctp-loadbalancer-service-type}
-
-{{< warning >}}
-You can only create a Service with `type` LoadBalancer plus `protocol` SCTP if the cloud provider's load balancer implementation supports SCTP as a protocol. Otherwise, the Service creation request is rejected. The current set of cloud load balancer providers (Azure, AWS, CloudStack, GCE, OpenStack) all lack support for SCTP.
-{{< /warning >}}
-
-##### Windows {#caveat-sctp-windows-os}
-
-{{< warning >}}
-SCTP is not supported on Windows based nodes.
-{{< /warning >}}
-
-##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace}
-
-{{< warning >}}
-The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
-{{< /warning >}}
-
 ## {{% heading "whatsnext" %}}
 
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)

content/en/docs/concepts/storage/ephemeral-volumes.md

@@ -46,7 +46,7 @@ different purposes:
   [downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
   [secret](/docs/concepts/storage/volumes/#secret): inject different
   kinds of Kubernetes data into a Pod
-- [CSI ephemeral volumes](#csi-ephemeral-volume):
+- [CSI ephemeral volumes](#csi-ephemeral-volumes):
   similar to the previous volume kinds, but provided by special
   [CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
   which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html)

content/en/docs/concepts/storage/persistent-volumes.md

@@ -308,28 +308,37 @@ If expanding underlying storage fails, the cluster administrator can manually re
 
 ## Types of Persistent Volumes
 
-PersistentVolume types are implemented as plugins.  Kubernetes currently supports the following plugins:
+PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins:
 
-* GCEPersistentDisk
-* AWSElasticBlockStore
-* AzureFile
-* AzureDisk
-* CSI
-* FC (Fibre Channel)
-* FlexVolume
-* Flocker
-* NFS
-* iSCSI
-* RBD (Ceph Block Device)
-* CephFS
-* Cinder (OpenStack block storage)
-* Glusterfs
-* VsphereVolume
-* Quobyte Volumes
-* HostPath (Single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
-* Portworx Volumes
-* ScaleIO Volumes
-* StorageOS
+* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)
+* [`azureDisk`](/docs/concepts/sotrage/volumes/#azuredisk) - Azure Disk
+* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File
+* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume
+* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
+  (**deprecated**)
+* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI)
+* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage
+* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
+* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage
+* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
+* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume
+* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume
+  (for single node testing only; WILL NOT WORK in a multi-node cluster;
+  consider using `local` volume instead)
+* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage
+* [`local`](/docs/concepts/storage/volumes/#local) - local storage devices
+  mounted on nodes.
+* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage
+* `photonPersistentDisk` - Photon controller persistent disk.
+  (This volume type no longer works since the removal of the corresponding
+  cloud provider.)
+* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume
+* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume
+* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume
+* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume
+  (**deprecated**)
+* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume
+* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume
 
 ## Persistent Volumes
 
@@ -723,12 +732,10 @@ Only statically provisioned volumes are supported for alpha release. Administrat
 
 ## Volume Snapshot and Restore Volume from Snapshot Support
 
-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
-Volume snapshot feature was added to support CSI Volume Plugins only. For details, see [volume snapshots](/docs/concepts/storage/volume-snapshots/).
-
-To enable support for restoring a volume from a volume snapshot data source, enable the
-`VolumeSnapshotDataSource` feature gate on the apiserver and controller-manager.
+Volume snapshots only support the out-of-tree CSI volume plugins. For details, see [Volume Snapshots](/docs/concepts/storage/volume-snapshots/).
+In-tree volume plugins are deprecated. You can read about the deprecated volume plugins in the [Volume Plugin FAQ] (https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md).
 
 ### Create a PersistentVolumeClaim from a Volume Snapshot {#create-persistent-volume-claim-from-volume-snapshot}
 

content/en/docs/concepts/storage/storage-classes.md

@@ -94,7 +94,7 @@ run, what volume plugin it uses (including Flex), etc. The repository
 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 houses a library for writing external provisioners that implements the bulk of
 the specification. Some external provisioners are listed under the repository
-[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns).
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner).
 
 For example, NFS doesn't provide an internal provisioner, but an external
 provisioner can be used. There are also cases when 3rd party storage

content/en/docs/concepts/storage/volume-snapshot-classes.md

@@ -40,7 +40,7 @@ of a class when first creating VolumeSnapshotClass objects, and the objects cann
 be updated once they are created.
 
 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotClass
 metadata:
   name: csi-hostpath-snapclass
@@ -54,7 +54,7 @@ that don't request any particular class to bind to by adding the
 `snapshot.storage.kubernetes.io/is-default-class: "true"` annotation:
 
 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotClass
 metadata:
   name: csi-hostpath-snapclass

content/en/docs/concepts/storage/volume-snapshots.md

@@ -13,7 +13,6 @@ weight: 20
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
 
 
@@ -37,7 +36,8 @@ Users need to be aware of the following when using this feature:
 
 * API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, not part of the core API.
 * `VolumeSnapshot` support is only available for CSI drivers.
-* As part of the deployment process in the beta version of `VolumeSnapshot`, the Kubernetes team provides a snapshot controller to be deployed into the control plane, and a sidecar helper container called csi-snapshotter to be deployed together with the CSI driver.  The snapshot controller watches `VolumeSnapshot` and `VolumeSnapshotContent` objects and is responsible for the creation and deletion of `VolumeSnapshotContent` object in dynamic provisioning.  The sidecar csi-snapshotter watches `VolumeSnapshotContent` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
+* As part of the deployment process of `VolumeSnapshot`, the Kubernetes team provides a snapshot controller to be deployed into the control plane, and a sidecar helper container called csi-snapshotter to be deployed together with the CSI driver.  The snapshot controller watches `VolumeSnapshot` and `VolumeSnapshotContent` objects and is responsible for the creation and deletion of `VolumeSnapshotContent` object.  The sidecar csi-snapshotter watches `VolumeSnapshotContent` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
+* There is also a validating webhook server which provides tightened validation on snapshot objects. This should be installed by the Kubernetes distros along with the snapshot controller and CRDs, not CSI drivers. It should be installed in all Kubernetes clusters that has the snapshot feature enabled.
 * CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use the csi-snapshotter. See [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) for details.
 * The CRDs and snapshot controller installations are the responsibility of the Kubernetes distribution.
 
@@ -78,7 +78,7 @@ Deletion is triggered by deleting the `VolumeSnapshot` object, and the `Deletion
 Each VolumeSnapshot contains a spec and a status.
 
 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshot
 metadata:
   name: new-snapshot-test
@@ -97,7 +97,7 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
 For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
 
 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshot
 metadata:
   name: test-snapshot
@@ -111,7 +111,7 @@ spec:
 Each VolumeSnapshotContent contains a spec and status. In dynamic provisioning, the snapshot common controller creates `VolumeSnapshotContent` objects. Here is an example:
 
 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotContent
 metadata:
   name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
@@ -132,7 +132,7 @@ spec:
 For pre-provisioned snapshots, you (as cluster administrator) are responsible for creating the `VolumeSnapshotContent` object as follows.
 
 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotContent
 metadata:
   name: new-snapshot-content-test
@@ -154,4 +154,4 @@ You can provision a new volume, pre-populated with data from a snapshot, by usin
 the *dataSource* field in the `PersistentVolumeClaim` object.
 
 For more details, see
-[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
+[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).

content/en/docs/concepts/storage/volumes.md

@@ -303,6 +303,12 @@ While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on
 node reboot and any files you write count against your container's
 memory limit.
 
+{{< note >}}
+If the `SizeMemoryBackedVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
+you can specify a size for memory backed volumes.  If no size is specified, memory
+backed volumes are sized to 50% of the memory on a Linux host.
+{{< /note>}}
+
 #### emptyDir configuration example
 
 ```yaml

content/en/docs/concepts/workloads/controllers/cron-jobs.md

@@ -32,8 +32,6 @@ The name must be no longer than 52 characters. This is because the CronJob contr
 append 11 characters to the job name provided and there is a constraint that the
 maximum length of a Job name is no more than 63 characters.
 
-
-
 <!-- body -->
 
 ## CronJob
@@ -82,6 +80,14 @@ be down for the same period as the previous example (`08:29:00` to `10:21:00`,)
 The CronJob is only responsible for creating Jobs that match its schedule, and
 the Job in turn is responsible for the management of the Pods it represents.
 
+## New controller
+
+There's an alternative implementation of the CronJob controller, available as an alpha feature since Kubernetes 1.20. To select version 2 of the CronJob controller, pass the following [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) flag to the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
+
+```
+--feature-gates="CronJobControllerV2=true"
+```
+
 
 ## {{% heading "whatsnext" %}}
 

content/en/docs/concepts/workloads/controllers/daemonset.md

@@ -87,12 +87,6 @@ When the two are specified the result is ANDed.
 
 If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API.
 
-Also you should not normally create any Pods whose labels match this selector, either directly, via
-another DaemonSet, or via another workload resource such as ReplicaSet.  Otherwise, the DaemonSet
-{{< glossary_tooltip term_id="controller" >}} will think that those Pods were created by it.
-Kubernetes will not stop you from doing this. One case where you might want to do this is manually
-create a Pod with a different value on a node for testing.
-
 ### Running Pods on select Nodes
 
 If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will

content/en/docs/concepts/workloads/controllers/garbage-collection.md

@@ -59,11 +59,22 @@ metadata:
 ```
 
 {{< note >}}
-Cross-namespace owner references are disallowed by design. This means:
-1) Namespace-scoped dependents can only specify owners in the same namespace,
-and owners that are cluster-scoped.
-2) Cluster-scoped dependents can only specify cluster-scoped owners, but not
-namespace-scoped owners.
+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 unresolveable 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

content/en/docs/concepts/workloads/controllers/statefulset.md

@@ -150,7 +150,7 @@ remembered and reused, even after the Pod is running, for at least a few seconds
 If you need to discover Pods promptly after they are created, you have a few options:
 
 - Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
-- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
+- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
 
 
 As mentioned in the [limitations](#limitations) section, you are responsible for

content/en/docs/concepts/workloads/pods/_index.md

@@ -172,14 +172,18 @@ spec:
     # The pod template ends here
 ```
 
-Modifying the pod template or switching to a new pod template has no effect on the
-Pods that already exist. Pods do not receive template updates directly. Instead,
-a new Pod is created to match the revised pod template.
+Modifying the pod template or switching to a new pod template has no direct effect
+on the Pods that already exist. If you change the pod template for a workload
+resource, that resource needs to create replacement Pods that use the updated template.
 
-For example, the deployment controller ensures that the running Pods match the current
-pod template for each Deployment object. If the template is updated, the Deployment has
-to remove the existing Pods and create new Pods based on the updated template. Each workload
-resource implements its own rules for handling changes to the Pod template.
+For example, the StatefulSet controller ensures that the running Pods match the current
+pod template for each StatefulSet object. If you edit the StatefulSet to change its pod
+template, the StatefulSet starts to create new Pods based on the updated template.
+Eventually, all of the old Pods are replaced with new Pods, and the update is complete.
+
+Each workload resource implements its own rules for handling changes to the Pod template.
+If you want to read more about StatefulSet specifically, read
+[Update strategy](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) in the StatefulSet Basics tutorial.
 
 On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not
 directly observe or manage any of the details around pod templates and updates; those
@@ -253,7 +257,6 @@ but cannot be controlled from there.
 ## {{% heading "whatsnext" %}}
 
 * Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
-* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
 * Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
   configure different Pods with different container runtime configurations.
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).

content/en/docs/concepts/workloads/pods/ephemeral-containers.md

@@ -90,7 +90,7 @@ enabled, and Kubernetes client and server version v1.16 or later.
 {{< /note >}}
 
 The examples in this section demonstrate how ephemeral containers appear in
-the API. You would normally use `kubectl alpha debug` or another `kubectl`
+the API. You would normally use `kubectl debug` or another `kubectl`
 [plugin](/docs/tasks/extend-kubectl/kubectl-plugins/) to automate these steps
 rather than invoking the API directly.
 

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -142,7 +142,7 @@ The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
 refers to restarts of the containers by the kubelet on the same node. After containers
 in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes
-without any problems, the kubelet resets the restart backoff timer forthat container.
+without any problems, the kubelet resets the restart backoff timer for that container.
 
 ## Pod conditions
 
@@ -315,7 +315,7 @@ to stop.
 
 ### When should you use a startup probe?
 
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
 Startup probes are useful for Pods that have containers that take a long time to
 come into service. Rather than set a long liveness interval, you can configure

content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -310,6 +310,7 @@ profiles:
             - maxSkew: 1
               topologyKey: topology.kubernetes.io/zone
               whenUnsatisfiable: ScheduleAnyway
+          defaultingType: List
 ```
 
 {{< note >}}
@@ -322,9 +323,9 @@ using default constraints for `PodTopologySpread`.
 
 #### Internal default constraints
 
-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.20" state="beta" >}}
 
-When you enable the `DefaultPodTopologySpread` feature gate, the
+With the `DefaultPodTopologySpread` feature gate, enabled by default, the
 legacy `SelectorSpread` plugin is disabled.
 kube-scheduler uses the following default topology constraints for the
 `PodTopologySpread` plugin configuration:
@@ -351,6 +352,22 @@ The `PodTopologySpread` plugin does not score the nodes that don't have
 the topology keys specified in the spreading constraints.
 {{< /note >}}
 
+If you don't want to use the default Pod spreading constraints for your cluster,
+you can disable those defaults by setting `defaultingType` to `List` and leaving
+empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints: []
+          defaultingType: List
+```
+
 ## Comparison with PodAffinity/PodAntiAffinity
 
 In Kubernetes, directives related to "Affinity" control how Pods are

content/en/docs/concepts/workloads/pods/podpreset.md

@@ -1,91 +0,0 @@
----
-reviewers:
-- jessfraz
-title: Pod Presets
-content_type: concept
-weight: 50
----
-
-<!-- overview -->
-{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-
-This page provides an overview of PodPresets, which are objects for injecting
-certain information into pods at creation time. The information can include
-secrets, volumes, volume mounts, and environment variables.
-
-
-
-<!-- body -->
-## Understanding Pod presets
-
-A PodPreset is an API resource for injecting additional runtime requirements
-into a Pod at creation time.
-You use [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
-to specify the Pods to which a given PodPreset applies.
-
-Using a PodPreset allows pod template authors to not have to explicitly provide
-all information for every pod. This way, authors of pod templates consuming a
-specific service do not need to know all the details about that service.
-
-
-## Enable PodPreset in your cluster {#enable-pod-preset}
-
-In order to use Pod presets in your cluster you must ensure the following:
-
-1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
-   example, this can be done by including `settings.k8s.io/v1alpha1=true` in
-   the `--runtime-config` option for the API server. In minikube add this flag
-   `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while
-   starting the cluster.
-1. You have enabled the admission controller named `PodPreset`. One way to doing this
-   is to include `PodPreset` in the `--enable-admission-plugins` option value specified
-   for the API server. For example, if you use Minikube, add this flag:
-
-   ```shell
-   --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
-   ```
-
-   while starting your cluster.
-
-## How it works
-
-Kubernetes provides an admission controller (`PodPreset`) which, when enabled,
-applies Pod Presets to incoming pod creation requests.
-When a pod creation request occurs, the system does the following:
-
-1. Retrieve all `PodPresets` available for use.
-1. Check if the label selectors of any `PodPreset` matches the labels on the
-   pod being created.
-1. Attempt to merge the various resources defined by the `PodPreset` into the
-   Pod being created.
-1. On error, throw an event documenting the merge error on the pod, and create
-   the pod _without_ any injected resources from the `PodPreset`.
-1. Annotate the resulting modified Pod spec to indicate that it has been
-   modified by a `PodPreset`. The annotation is of the form
-   `podpreset.admission.kubernetes.io/podpreset-<pod-preset name>: "<resource version>"`.
-
-Each Pod can be matched by zero or more PodPresets; and each PodPreset can be
-applied to zero or more Pods. When a PodPreset is applied to one or more
-Pods, Kubernetes modifies the Pod Spec. For changes to `env`, `envFrom`, and
-`volumeMounts`, Kubernetes modifies the container spec for all containers in
-the Pod; for changes to `volumes`, Kubernetes modifies the Pod Spec.
-
-{{< note >}}
-A Pod Preset is capable of modifying the following fields in a Pod spec when appropriate:
-- The `.spec.containers` field
-- The `.spec.initContainers` field
-{{< /note >}}
-
-### Disable Pod Preset for a specific pod
-
-There may be instances where you wish for a Pod to not be altered by any Pod
-preset mutations. In these cases, you can add an annotation in the Pod's `.spec`
-of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
-
-
-
-## {{% heading "whatsnext" %}}
-
-See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
-
-For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).

content/en/docs/contribute/_index.md

@@ -1,6 +1,6 @@
 ---
 content_type: concept
-title: Contribute to Kubernetes docs
+title: Contribute to K8s docs
 linktitle: Contribute
 main_menu: true
 no_list: true
@@ -8,7 +8,7 @@ weight: 80
 card:
   name: contribute
   weight: 10
-  title: Start contributing
+  title: Start contributing to K8s
 ---
 
 <!-- overview -->

content/en/docs/contribute/new-content/overview.md

@@ -43,7 +43,7 @@ When opening a pull request, you need to know in advance which branch to base yo
 Scenario | Branch
 :---------|:------------
 Existing or new English language content for the current release | `master`
-Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
+Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
 Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
 
 

content/en/docs/home/_index.md

@@ -32,7 +32,7 @@ cards:
   button: "View Tutorials"
   button_path: "/docs/tutorials"
 - name: setup
-  title: "Set up a cluster"
+  title: "Set up a K8s cluster"
   description: "Get Kubernetes running based on your resources and needs."
   button: "Set up Kubernetes"
   button_path: "/docs/setup"
@@ -57,7 +57,7 @@ cards:
   button: Contribute to the docs
   button_path: /docs/contribute
 - name: release-notes
-  title: Release Notes
+  title: K8s Release Notes
   description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
   button: "Download Kubernetes"
   button_path: "/docs/setup/release/notes"

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -91,7 +91,7 @@ To see which admission plugins are enabled:
 kube-apiserver -h | grep enable-admission-plugins
 ```
 
-In 1.18, they are:
+In the current version, the default ones are:
 
 ```shell
 NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota
@@ -725,10 +725,15 @@ See the [resourceQuota design doc](https://git.k8s.io/community/contributors/des
 
 ### RuntimeClass {#runtimeclass}
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
-For [RuntimeClass](/docs/concepts/containers/runtime-class/) definitions which describe an overhead associated with running a pod,
-this admission controller will set the pod.Spec.Overhead field accordingly.
+If you enable the `PodOverhead` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), and define a RuntimeClass with [Pod overhead](/docs/concepts/scheduling-eviction/pod-overhead/) configured, this admission controller checks incoming
+Pods. When enabled, this admission controller rejects any Pod create requests that have the overhead already set.
+For Pods that have a  RuntimeClass is configured and selected in their `.spec`, this admission controller sets `.spec.overhead` in the Pod based on the value defined in the corresponding RuntimeClass.
+
+{{< note >}}
+The `.spec.overhead` field for Pod and the `.overhead` field for RuntimeClass are both in beta. If you do not enable the `PodOverhead` feature gate, all Pods are treated as if `.spec.overhead` is unset.
+{{< /note >}}
 
 See also [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
 for more information.

content/en/docs/reference/access-authn-authz/authentication.md

@@ -282,7 +282,33 @@ from the OAuth2 [token response](https://openid.net/specs/openid-connect-core-1_
 as a bearer token.  See [above](#putting-a-bearer-token-in-a-request) for how the token
 is included in a request.
 
-![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg)
+{{< mermaid >}}
+sequenceDiagram
+    participant user as User
+    participant idp as Identity Provider
+    participant kube as Kubectl
+    participant api as API Server
+
+    user ->> idp: 1. Login to IdP
+    activate idp
+    idp -->> user: 2. Provide access_token,<br>id_token, and refresh_token
+    deactivate idp
+    activate user
+    user ->> kube: 3. Call Kubectl<br>with --token being the id_token<br>OR add tokens to .kube/config
+    deactivate user
+    activate kube
+    kube ->> api: 4. Authorization: Bearer...
+    deactivate kube
+    activate api
+    api ->> api: 5. Is JWT signature valid?
+    api ->> api: 6. Has the JWT expired? (iat+exp)
+    api ->> api: 7. User authorized?
+    api -->> kube: 8. Authorized: Perform<br>action and return result
+    deactivate api
+    activate kube
+    kube --x user: 9. Return result
+    deactivate kube
+{{< /mermaid >}}
 
 1.  Login to your identity provider
 2.  Your identity provider will provide you with an `access_token`, `id_token` and a `refresh_token`
@@ -328,7 +354,7 @@ tokens on behalf of another.
 Kubernetes does not provide an OpenID Connect Identity Provider.
 You can use an existing public OpenID Connect Identity Provider (such as Google, or
 [others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)).
-Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex),
+Or, you can run your own Identity Provider, such as [dex](https://dexidp.io/),
 [Keycloak](https://github.com/keycloak/keycloak),
 CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or
 Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison).
@@ -339,13 +365,13 @@ For an identity provider to work with Kubernetes it must:
 2.  Run in TLS with non-obsolete ciphers
 3.  Have a CA signed certificate (even if the CA is not a commercial CA or is self signed)
 
-A note about requirement #3 above, requiring a CA signed certificate.  If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed.  This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation.  If you don't have a CA handy, you can use [this script](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh) from the CoreOS team to create a simple CA and a signed certificate and key pair.
+A note about requirement #3 above, requiring a CA signed certificate.  If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed.  This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation.  If you don't have a CA handy, you can use [this script](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh) from the Dex team to create a simple CA and a signed certificate and key pair.
 Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh) that generates SHA256 certs with a longer life and larger key size.
 
 Setup instructions for specific systems:
 
 - [UAA](https://docs.cloudfoundry.org/concepts/architecture/uaa.html)
-- [Dex](https://github.com/dexidp/dex/blob/master/Documentation/kubernetes.md)
+- [Dex](https://dexidp.io/docs/kubernetes/)
 - [OpenUnison](https://www.tremolosecurity.com/orchestra-k8s/)
 
 #### Using kubectl
@@ -882,11 +908,22 @@ users:
         On Fedora: dnf install example-client-go-exec-plugin
 
         ...
+
+      # Whether or not to provide cluster information, which could potentially contain
+      # very large CA data, to this exec plugin as a part of the KUBERNETES_EXEC_INFO
+      # environment variable.
+      provideClusterInfo: true
 clusters:
 - name: my-cluster
   cluster:
     server: "https://172.17.4.100:6443"
     certificate-authority: "/etc/kubernetes/ca.pem"
+    extensions:
+    - name: client.authentication.k8s.io/exec # reserved extension name for per cluster exec config
+      extension:
+        arbitrary: config
+        this: can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo
+        you: ["can", "put", "anything", "here"]
 contexts:
 - name: my-cluster
   context:
@@ -968,3 +1005,28 @@ RFC3339 timestamp. Presence or absence of an expiry has the following impact:
 }
 ```
 
+The plugin can optionally be called with an environment variable, `KUBERNETES_EXEC_INFO`,
+that contains information about the cluster for which this plugin is obtaining
+credentials. This information can be used to perform cluster-specific credential
+acquisition logic. In order to enable this behavior, the `provideClusterInfo` field must
+be set on the exec user field in the
+[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Here is an
+example of the aforementioned `KUBERNETES_EXEC_INFO` environment variable.
+
+```json
+{
+  "apiVersion": "client.authentication.k8s.io/v1beta1",
+  "kind": "ExecCredential",
+  "spec": {
+    "cluster": {
+      "server": "https://172.17.4.100:6443",
+      "certificate-authority-data": "LS0t...",
+      "config": {
+        "arbitrary": "config",
+        "this": "can be provided via the KUBERNETES_EXEC_INFO environment variable upon setting provideClusterInfo",
+        "you": ["can", "put", "anything", "here"]
+      }
+    }
+  }
+}
+```

content/en/docs/reference/access-authn-authz/rbac.md

@@ -801,7 +801,12 @@ This is commonly used by add-on API servers for unified authentication and autho
 <td>None</td>
 <td>Allows access to the resources required by most <a href="/docs/concepts/storage/persistent-volumes/#provisioner">dynamic volume provisioners</a>.</td>
 </tr>
-<tbody>
+<tr>
+<td><b>system:monitoring</b></td>
+<td><b>system:monitoring</b> group</td>
+<td>Allows read access to control-plane monitoring endpoints (i.e. {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} liveness and readiness endpoints (<tt>/healthz</tt>, <tt>/livez</tt>, <tt>/readyz</tt>), the individual health-check endpoints (<tt>/healthz/*</tt>, <tt>/livez/*</tt>, <tt>/readyz/*</tt>),  and <tt>/metrics</tt>). Note that individual health check endpoints and the metric endpoint may expose sensitive information.</td>
+</tr>
+</tbody>
 </table>
 
 ### Roles for built-in controllers {#controller-roles}

content/en/docs/reference/access-authn-authz/service-accounts-admin.md

@@ -10,7 +10,7 @@ weight: 50
 ---
 
 <!-- overview -->
-This is a Cluster Administrator guide to service accounts. You should be familiar with 
+This is a Cluster Administrator guide to service accounts. You should be familiar with
 [configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/).
 
 Support for authorization and user accounts is planned but incomplete.  Sometimes
@@ -23,33 +23,33 @@ incomplete features are referred to in order to better describe service accounts
 Kubernetes distinguishes between the concept of a user account and a service account
 for a number of reasons:
 
-  - User accounts are for humans. Service accounts are for processes, which
-    run in pods.
-  - User accounts are intended to be global. Names must be unique across all
-    namespaces of a cluster, future user resource will not be namespaced.
-    Service accounts are namespaced.
-  - Typically, a cluster's User accounts might be synced from a corporate
-    database, where new user account creation requires special privileges and
-    is tied to complex business processes. Service account creation is intended
-    to be more lightweight, allowing cluster users to create service accounts for
-    specific tasks (i.e. principle of least privilege).
-  - Auditing considerations for humans and service accounts may differ.
-  - A config bundle for a complex system may include definition of various service
-    accounts for components of that system.  Because service accounts can be created
-    ad-hoc and have namespaced names, such config is portable.
+- User accounts are for humans. Service accounts are for processes, which run
+  in pods.
+- User accounts are intended to be global. Names must be unique across all
+  namespaces of a cluster. Service accounts are namespaced.
+- Typically, a cluster's user accounts might be synced from a corporate
+  database, where new user account creation requires special privileges and is
+  tied to complex business processes. Service account creation is intended to be
+  more lightweight, allowing cluster users to create service accounts for
+  specific tasks by following the principle of least privilege.
+- Auditing considerations for humans and service accounts may differ.
+- A config bundle for a complex system may include definition of various service
+  accounts for components of that system. Because service accounts can be created
+  without many constraints and have namespaced names, such config is portable.
 
 ## Service account automation
 
 Three separate components cooperate to implement the automation around service accounts:
 
-  - A Service account admission controller
-  - A Token controller
-  - A Service account controller
+- A `ServiceAccount` admission controller
+- A Token controller
+- A `ServiceAccount` controller
 
-### Service Account Admission Controller
+### ServiceAccount Admission Controller
 
 The modification of pods is implemented via a plugin
-called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/). It is part of the apiserver.
+called an [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/).
+It is part of the API server.
 It acts synchronously to modify pods as they are created or updated. When this plugin is active
 (and it is by default on most distributions), then it does the following when a pod is created or modified:
 
@@ -59,60 +59,85 @@ It acts synchronously to modify pods as they are created or updated. When this p
   1. It adds a `volume` to the pod which contains a token for API access.
   1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`.
 
-Starting from v1.13, you can migrate a service account volume to a projected volume when
+#### Bound Service Account Token Volume
+{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+
+When the `BoundServiceAccountTokenVolume` feature gate is enabled, the service account admission controller will
+add a projected service account token volume instead of a secret volume. The service account token will expire after 1 hour by default or the pod is deleted. See more details about [projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
+
+This feature depends on the `RootCAConfigMap` feature gate enabled which publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver.
+1. If the pod does not have a `serviceAccountName` set, it sets the
+   `serviceAccountName` to `default`.
+1. It ensures that the `serviceAccountName` referenced by the pod exists, and
+   otherwise rejects it.
+1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets`
+   of the ServiceAccount referenced by `serviceAccountName` are added to the pod.
+1. It adds a `volume` to the pod which contains a token for API access
+   if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's
+   `automountServiceAccountToken` is set to `false`.
+1. It adds a `volumeSource` to each container of the pod mounted at
+   `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has
+   created a volume for ServiceAccount token.
+
+You can migrate a service account volume to a projected volume when
 the `BoundServiceAccountTokenVolume` feature gate is enabled.
-The service account token will expire after 1 hour or the pod is deleted. See more details about [projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
+The service account token will expire after 1 hour or the pod is deleted. See
+more details about
+[projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
 
 ### Token Controller
 
-TokenController runs as part of controller-manager. It acts asynchronously. It:
+TokenController runs as part of `kube-controller-manager`. It acts asynchronously. It:
 
-- observes serviceAccount creation and creates a corresponding Secret to allow API access.
-- observes serviceAccount deletion and deletes all corresponding ServiceAccountToken Secrets.
-- observes secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the secret if needed.
-- observes secret deletion and removes a reference from the corresponding ServiceAccount if needed.
+- watches ServiceAccount creation and creates a corresponding
+  ServiceAccount token Secret to allow API access.
+- watches ServiceAccount deletion and deletes all corresponding ServiceAccount
+  token Secrets.
+- watches ServiceAccount token Secret addition, and ensures the referenced
+  ServiceAccount exists, and adds a token to the Secret if needed.
+- watches Secret deletion and removes a reference from the corresponding
+  ServiceAccount if needed.
 
-You must pass a service account private key file to the token controller in the controller-manager by using
-the `--service-account-private-key-file` option. The private key will be used to sign generated service account tokens.
-Similarly, you must pass the corresponding public key to the kube-apiserver using the `--service-account-key-file`
-option. The public key will be used to verify the tokens during authentication.
+You must pass a service account private key file to the token controller in
+the `kube-controller-manager` using the `--service-account-private-key-file`
+flag. The private key is used to sign generated service account tokens.
+Similarly, you must pass the corresponding public key to the `kube-apiserver`
+using the `--service-account-key-file` flag. The public key will be used to
+verify the tokens during authentication.
 
 #### To create additional API tokens
 
-A controller loop ensures a secret with an API token exists for each service
-account. To create additional API tokens for a service account, create a secret
-of type `ServiceAccountToken` with an annotation referencing the service
-account, and the controller will update it with a generated token:
+A controller loop ensures a Secret with an API token exists for each
+ServiceAccount. To create additional API tokens for a ServiceAccount, create a
+Secret of type `kubernetes.io/service-account-token` with an annotation
+referencing the ServiceAccount, and the controller will update it with a
+generated token:
 
-secret.json:
+Below is a sample configuration for such a Secret:
 
-```json
-{
-    "kind": "Secret",
-    "apiVersion": "v1",
-    "metadata": {
-        "name": "mysecretname",
-        "annotations": {
-            "kubernetes.io/service-account.name": "myserviceaccount"
-        }
-    },
-    "type": "kubernetes.io/service-account-token"
-}
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecretname
+  annotations:
+    kubernetes.io/service-account.name: myserviceaccount
+type: kubernetes.io/service-account-token
 ```
 
 ```shell
-kubectl create -f ./secret.json
+kubectl create -f ./secret.yaml
 kubectl describe secret mysecretname
 ```
 
-#### To delete/invalidate a service account token
+#### To delete/invalidate a ServiceAccount token Secret
 
 ```shell
 kubectl delete secret mysecretname
 ```
 
-### Service Account Controller
+### ServiceAccount controller
 
-Service Account Controller manages ServiceAccount inside namespaces, and ensures
-a ServiceAccount named "default" exists in every active namespace.
+A ServiceAccount controller manages the ServiceAccounts inside namespaces, and
+ensures a ServiceAccount named "default" exists in every active namespace.
 

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -51,8 +51,10 @@ different Kubernetes components.
 | `AnyVolumeDataSource` | `false` | Alpha | 1.18 | |
 | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
 | `APIListChunking` | `true` | Beta | 1.9 | |
-| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | |
+| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | 1.19 |
+| `APIPriorityAndFairness` | `true` | Beta | 1.20 | |
 | `APIResponseCompression` | `false` | Alpha | 1.7 | |
+| `APIServerIdentity` | `false` | Alpha | 1.20 | |
 | `AppArmor` | `true` | Beta | 1.4 | |
 | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | |
 | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | |
@@ -79,16 +81,23 @@ different Kubernetes components.
 | `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | |
 | `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
 | `CSIMigrationvSphereComplete` | `false` | Beta | 1.19 | |
+| `CSIServiceAccountToken` | `false` | Alpha | 1.20 | |
 | `CSIStorageCapacity` | `false` | Alpha | 1.19 | |
-| `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | |
-| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | |
+| `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | 1.19 |
+| `CSIVolumeFSGroupPolicy` | `true` | Beta | 1.20 | |
+| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | 1.19 |
+| `ConfigurableFSGroupPolicy` | `true` | Beta | 1.20 | |
+| `CronJobControllerV2` | `false` | Alpha | 1.20 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
 | `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | Beta | 1.16 | |
-| `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | |
+| `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | 1.19 |
+| `DefaultPodTopologySpread` | `true` | Beta | 1.20 | |
 | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | Beta | 1.10 | |
-| `DisableAcceleratorUsageMetrics` | `false` | Alpha | 1.19 | 1.20 |
+| `DisableAcceleratorUsageMetrics` | `false` | Alpha | 1.19 | 1.19 |
+| `DisableAcceleratorUsageMetrics` | `true` | Beta | 1.20 | 1.22 |
+| `DownwardAPIHugePages` | `false` | Alpha | 1.20 | |
 | `DryRun` | `false` | Alpha | 1.12 | 1.12 |
 | `DryRun` | `true` | Beta | 1.13 | |
 | `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
@@ -96,8 +105,10 @@ different Kubernetes components.
 | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | Beta | 1.17 | |
 | `EndpointSlice` | `true` | Beta | 1.18 | |
+| `EndpointSliceNodeName` | `false` | Alpha | 1.20 | |
 | `EndpointSliceProxying` | `false` | Alpha | 1.18 | 1.18 |
 | `EndpointSliceProxying` | `true` | Beta | 1.19 | |
+| `EndpointSliceTerminating` | `false` | Alpha | 1.20 | |
 | `EphemeralContainers` | `false` | Alpha | 1.16 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
@@ -107,6 +118,7 @@ different Kubernetes components.
 | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
 | `GenericEphemeralVolume` | `false` | Alpha | 1.19 | |
+| `GracefulNodeShutdown` | `false` | Alpha | 1.20 | |
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
 | `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 |
 | `HugePageStorageMediumSize` | `true` | Beta | 1.19 | |
@@ -114,12 +126,11 @@ different Kubernetes components.
 | `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 |
 | `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | |
 | `IPv6DualStack` | `false` | Alpha | 1.16 | |
-| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
-| `KubeletPodResources` | `true` | Beta | 1.15 | |
 | `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | |
 | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
+| `MixedProtocolLBService` | `false` | Alpha | 1.20 | |
 | `MountContainers` | `false` | Alpha | 1.9 | |
 | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | 1.18 |
 | `NodeDisruptionExclusion` | `true` | Beta | 1.19 | |
@@ -127,10 +138,13 @@ different Kubernetes components.
 | `NonPreemptingPriority` | `true` | Beta | 1.19 | |
 | `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 |
 | `PodDisruptionBudget` | `true` | Beta | 1.5 | |
-| `PodOverhead` | `false` | Alpha | 1.16 | - |
+| `PodOverhead` | `false` | Alpha | 1.16 | 1.17 |
+| `PodOverhead` | `true` | Beta | 1.18 |  |
 | `ProcMountType` | `false` | Alpha | 1.12 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
 | `RemainingItemCount` | `false` | Alpha | 1.15 | |
+| `RootCAConfigMap` | `false` | Alpha | 1.13 | 1.19 |
+| `RootCAConfigMap` | `true` | Beta | 1.20 | |
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
 | `RunAsGroup` | `true` | Beta | 1.14 | |
@@ -138,35 +152,23 @@ different Kubernetes components.
 | `RuntimeClass` | `true` | Beta | 1.14 | |
 | `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 |
 | `SCTPSupport` | `true` | Beta | 1.19 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
-| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
 | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | Beta | 1.16 | |
 | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
-| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
+| `ServiceLBNodePortControl` | `false` | Alpha | 1.20 | 1.20 |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 |
 | `ServiceNodeExclusion` | `true` | Beta | 1.19 | |
 | `ServiceTopology` | `false` | Alpha | 1.17 | |
-| `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | |
-| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
-| `StartupProbe` | `true` | Beta | 1.18 | |
+| `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | |
+| `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | 1.19 |
+| `SetHostnameAsFQDN` | `true` | Beta | 1.20 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
-| `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
-| `SupportNodePidsLimit` | `true` | Beta | 1.15 | |
-| `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
-| `SupportPodPidsLimit` | `true` | Beta | 1.14 | |
 | `Sysctls` | `true` | Beta | 1.11 | |
-| `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
-| `TokenRequest` | `true` | Beta | 1.12 | |
-| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
-| `TokenRequestProjection` | `true` | Beta | 1.12 | |
 | `TTLAfterFinished` | `false` | Alpha | 1.12 | |
 | `TopologyManager` | `false` | Alpha | 1.16 | |
 | `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 |
 | `ValidateProxyRedirects` | `true` | Beta | 1.14 | |
-| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 |
-| `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | - |
 | `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | |
 | `WindowsGMSA` | `false` | Alpha | 1.14 | |
 | `WindowsGMSA` | `true` | Beta | 1.16 | |
@@ -210,6 +212,9 @@ different Kubernetes components.
 | `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
 | `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 |
 | `CustomPodDNS` | `true` | GA | 1.14 | - |
+| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 |
+| `CustomResourceDefaulting` | `true` | Beta | 1.16 | 1.16 |
+| `CustomResourceDefaulting` | `true` | GA | 1.17 | - |
 | `CustomResourcePublishOpenAPI` | `false` | Alpha| 1.14 | 1.14 |
 | `CustomResourcePublishOpenAPI` | `true` | Beta| 1.15 | 1.15 |
 | `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - |
@@ -235,6 +240,7 @@ different Kubernetes components.
 | `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 |
 | `EvenPodsSpread` | `true` | Beta | 1.18 | 1.18 |
 | `EvenPodsSpread` | `true` | GA | 1.19 | - |
+| `ExecProbeTimeout` | `true` | GA | 1.20 | - |
 | `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | Alpha | 1.8 | 1.9 |
@@ -244,9 +250,13 @@ different Kubernetes components.
 | `Initializers` | - | Deprecated | 1.14 | - |
 | `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
 | `KubeletConfigFile` | - | Deprecated | 1.10 | - |
+| `KubeletCredentialProviders` | `false` | Alpha | 1.20 | 1.20 |
 | `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
 | `KubeletPluginsWatcher` | `true` | Beta | 1.12 | 1.12 |
 | `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
+| `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
+| `KubeletPodResources` | `true` | Beta | 1.15 | |
+| `KubeletPodResources` | `true` | GA | 1.20 | |
 | `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
 | `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
 | `MountPropagation` | `true` | GA | 1.12 | - |
@@ -275,12 +285,24 @@ different Kubernetes components.
 | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
 | `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | 1.18 |
 | `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
+| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
+| `RuntimeClass` | `true` | Beta | 1.14 | 1.19 |
+| `RuntimeClass` | `true` | GA | 1.20 | - |
 | `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 |
 | `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | 1.16  |
 | `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
+| `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 |
+| `SCTPSupport` | `true` | Beta | 1.19 | 1.19 |
+| `SCTPSupport` | `true` | GA | 1.20 | - |
+| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
+| `ServiceAppProtocol` | `true` | GA | 1.20 | - |
 | `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | 1.15 |
 | `ServiceLoadBalancerFinalizer` | `true` | Beta | 1.16 | 1.16 |
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
+| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
+| `StartupProbe` | `true` | Beta | 1.18 | 1.19 |
+| `StartupProbe` | `true` | GA | 1.20 | - |
 | `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 |
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
 | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 |
@@ -290,12 +312,27 @@ different Kubernetes components.
 | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 |
 | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
+| `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 |
+| `SupportNodePidsLimit` | `true` | Beta | 1.15 | 1.19 |
+| `SupportNodePidsLimit` | `true` | GA | 1.20 | - |
+| `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 |
+| `SupportPodPidsLimit` | `true` | Beta | 1.14 | 1.19 |
+| `SupportPodPidsLimit` | `true` | GA | 1.20 | - |
 | `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
 | `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 |
 | `TaintBasedEvictions` | `true` | GA | 1.18 | - |
 | `TaintNodesByCondition` | `false` | Alpha | 1.8 | 1.11 |
 | `TaintNodesByCondition` | `true` | Beta | 1.12 | 1.16 |
 | `TaintNodesByCondition` | `true` | GA | 1.17 | - |
+| `TokenRequest` | `false` | Alpha | 1.10 | 1.11 |
+| `TokenRequest` | `true` | Beta | 1.12 | 1.19 |
+| `TokenRequest` | `true` | GA | 1.20 | - |
+| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 |
+| `TokenRequestProjection` | `true` | Beta | 1.12 | 1.19 |
+| `TokenRequestProjection` | `true` | GA | 1.20 | - |
+| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 |
+| `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | 1.19 |
+| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - |
 | `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 |
 | `VolumePVCDataSource` | `true` | Beta | 1.16 | 1.17 |
 | `VolumePVCDataSource` | `true` | GA | 1.18 | - |
@@ -369,6 +406,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `APIListChunking`: Enable the API clients to retrieve (`LIST` or `GET`) resources from API server in chunks.
 - `APIPriorityAndFairness`: Enable managing request concurrency with prioritization and fairness at each server. (Renamed from `RequestManagement`)
 - `APIResponseCompression`: Compress the API responses for `LIST` or `GET` requests.
+- `APIServerIdentity`: Assign each kube-apiserver an ID in a cluster.
 - `AppArmor`: Enable AppArmor based mandatory access control on Linux nodes when using Docker.
    See [AppArmor Tutorial](/docs/tutorials/clusters/apparmor/) for more details.
 - `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes
@@ -381,10 +419,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
    See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
    for more details.
 - `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume consisting of a
-   ServiceAccountTokenVolumeProjection.
-   Check [Service Account Token Volumes](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)
+   ServiceAccountTokenVolumeProjection. Cluster admins can use metric `serviceaccount_stale_tokens_total` to
+   monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off
+   extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`.
+   Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
    for more details.
 - `ConfigurableFSGroupPolicy`: Allows user to configure volume permission change policy for fsGroups when mounting a volume in a Pod. See [Configure volume permission and ownership change policy for Pods](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods) for more details.
+- `CronJobControllerV2`: Use an alternative implementation of the {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} controller. Otherwise, version 1 of the same controller is selected. The version 2 controller provides experimental performance improvements.
 - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
 - `CRIContainerLogRotation`: Enable container log rotation for cri container runtime.
 - `CSIBlockVolume`: Enable external CSI volume drivers to support block storage. See the [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support) documentation for more details.
@@ -407,6 +448,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
   [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
   compatible volume plugin.
+- `CSIServiceAccountToken`: Enable CSI drivers to receive the pods' service account token that they mount volumes for. See [Token Requests](https://kubernetes-csi.github.io/docs/token-requests.html).
 - `CSIStorageCapacity`: Enables CSI drivers to publish storage capacity information and the Kubernetes scheduler to use that information when scheduling pods. See [Storage Capacity](/docs/concepts/storage/storage-capacity/).
   Check the [`csi` volume type](/docs/concepts/storage/volumes/#csi) documentation for more details.
 - `CSIVolumeFSGroupPolicy`: Allows CSIDrivers to use the `fsGroupPolicy` field. This field controls whether volumes created by a CSIDriver support volume ownership and permission modifications when these volumes are mounted.
@@ -423,11 +465,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `CustomResourceWebhookConversion`: Enable webhook-based conversion
   on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
   troubleshoot a running Pod.
-- `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/system-metrics/).
+- `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/system-metrics/#disable-accelerator-metrics).
 - `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
   based resource provisioning on nodes.
 - `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
   [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
+- `DownwardAPIHugePages`: Enables usage of hugepages in downward API.
 - `DryRun`: Enable server-side [dry run](/docs/reference/using-api/api-concepts/#dry-run) requests
   so that validation, merging, and mutation can be tested without committing.
 - `DynamicAuditing`(*deprecated*): Used to enable dynamic auditing before v1.19.
@@ -440,6 +483,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `EphemeralContainers`: Enable the ability to add {{< glossary_tooltip text="ephemeral containers"
   term_id="ephemeral-container" >}} to running pods.
 - `EvenPodsSpread`: Enable pods to be scheduled evenly across topology domains. See [Pod Topology Spread Constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+- `ExecProbeTimeout`: Ensure kubelet respects exec probe timeouts. This feature gate exists in case any of your existing workloads depend on a now-corrected fault where Kubernetes ignored exec probe timeouts. See [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes).
 - `ExpandInUsePersistentVolumes`: Enable expanding in-use PVCs. See [Resizing an in-use PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim).
 - `ExpandPersistentVolumes`: Enable the expanding of persistent volumes. See [Expanding Persistent Volumes Claims](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims).
 - `ExperimentalCriticalPodAnnotation`: Enable annotating specific pods as *critical* so that their [scheduling is guaranteed](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
@@ -451,6 +495,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
    if user namespace remapping is enabled in the Docker daemon.
 - `EndpointSlice`: Enables Endpoint Slices for more scalable and extensible
    network endpoints. See [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
+- `EndpointSliceNodeName`: Enables EndpointSlice `nodeName` field.
+- `EndpointSliceTerminating`: Enables EndpointSlice `terminating` and `serving`
+   condition fields.
 - `EndpointSliceProxying`: When this feature gate is enabled, kube-proxy running
    on Linux will use EndpointSlices as the primary data source instead of
    Endpoints, enabling scalability and performance improvements. See
@@ -461,6 +508,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
    [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/).
 - `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE.
 - `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features of normal volumes (can be provided by third-party storage vendors, storage capacity tracking, restore from snapshot, etc.). See [Ephemeral Volumes](/docs/concepts/storage/ephemeral-volumes/).
+- `GracefulNodeShutdown`: Enables support for graceful shutdown in kubelet. During a system shutdown, kubelet will attempt to detect the shutdown event and gracefully terminate pods running on the node. See [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown) for more details.
 - `HugePages`: Enable the allocation and consumption of pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
 - `HugePageStorageMediumSize`: Enable support for multiple sizes pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
 - `HyperVContainer`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers.
@@ -468,6 +516,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ImmutableEphemeralVolumes`: Allows for marking individual Secrets and ConfigMaps as immutable for better safety and performance.
 - `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file.
   See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details.
+- `KubeletCredentialProviders`: Enable kubelet exec credential providers for image pull credentials.
 - `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
   to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
 - `KubeletPodResources`: Enable the kubelet's pod resources grpc endpoint.
@@ -475,6 +524,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
 - `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
 - `LocalStorageCapacityIsolationFSQuotaMonitoring`: When `LocalStorageCapacityIsolation` is enabled for [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and the backing filesystem for [emptyDir volumes](/docs/concepts/storage/volumes/#emptydir) supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy.
+- `MixedProtocolLBService`: Enable using different protocols in the same LoadBalancer type Service instance.
 - `MountContainers`: Enable using utility containers on host as the volume mounter.
 - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
   For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
@@ -502,6 +552,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
   the input Pod's cpu and memory limits. The intent is to break ties between
   nodes with same scores.
 - `ResourceQuotaScopeSelectors`: Enable resource quota scope selectors.
+- `RootCAConfigMap`: Configure the kube-controller-manager to publish a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} named `kube-root-ca.crt` to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver.
+   See [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) for more details.
 - `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
   See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
 - `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet.
@@ -513,10 +565,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/server-side-apply/) path at the API Server.
 - `ServiceAccountIssuerDiscovery`: Enable OIDC discovery endpoints (issuer and JWKS URLs) for the service account issuer in the API server. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) for more details.
 - `ServiceAppProtocol`: Enables the `AppProtocol` field on Services and Endpoints.
+- `ServiceLBNodePortControl`: Enables the `spec.allocateLoadBalancerNodePorts` field on Services.
 - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
 - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider.
   A node is eligible for exclusion if labelled with "`alpha.service-controller.kubernetes.io/exclude-balancer`" key or `node.kubernetes.io/exclude-from-external-load-balancers`.
 - `ServiceTopology`: Enable service to route traffic based upon the Node topology of the cluster. See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details.
+- `SizeMemoryBackedVolumes`: Enables kubelet support to size memory backed volumes.  See [volumes](docs/concepts/storage/volumes) for more details.
 - `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain Name(FQDN) as hostname of pod. See [Pod's `setHostnameAsFQDN` field](/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field).
 - `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet.
 - `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
@@ -528,6 +582,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `SupportIPVSProxyMode`: Enable providing in-cluster service load balancing using IPVS.
   See [service proxies](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) for more details.
 - `SupportPodPidsLimit`: Enable the support to limiting PIDs in Pods.
+- `SupportNodePidsLimit`: Enable the support to limiting PIDs on the Node. The parameter `pid=<number>` in the `--system-reserved` and `--kube-reserved` options can be specified to ensure that the specified number of process IDs will be reserved for the system as a whole and for Kubernetes system daemons respectively.
 - `Sysctls`: Enable support for namespaced kernel parameters (sysctls) that can be set for each pod.
   See [sysctls](/docs/tasks/administer-cluster/sysctl-cluster/) for more details.
 - `TaintBasedEvictions`: Enable evicting pods from nodes based on taints on nodes and tolerations on Pods.

content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md

@@ -415,6 +415,17 @@ approve node _serving_ certificates for [security
 reasons](https://github.com/kubernetes/community/pull/1982). To use
 `RotateKubeletServerCertificate` operators need to run a custom approving
 controller, or manually approve the serving certificate requests.
+
+A deployment-specific approval process for kubelet serving certificates should typically only approve CSRs which:
+
+1. are requested by nodes (ensure the `spec.username` field is of the form 
+   `system:node:<nodeName>` and `spec.groups` contains `system:nodes`) 
+2. request usages for a serving certificate (ensure `spec.usages` contains `server auth`, 
+   optionally contains `digital signature` and `key encipherment`, and contains no other usages)
+3. only have IP and DNS subjectAltNames that belong to the requesting node, 
+   and have no URI and Email subjectAltNames (parse the x509 Certificate Signing Request 
+   in `spec.request` to verify `subjectAltNames`)
+
 {{< /note >}}
 
 ## Other authenticating components

content/en/docs/reference/command-line-tools-reference/kubelet.md

@@ -579,7 +579,7 @@ ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)<br/>
 CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>
 DefaultPodTopologySpread=true|false (ALPHA - default=false)<br/>
 DevicePlugins=true|false (BETA - default=true)<br/>
-DisableAcceleratorUsageMetrics=true|false (ALPHA - default=false)<br/>
+DisableAcceleratorUsageMetrics=true|false (BETA - default=true)<br/>
 DynamicKubeletConfig=true|false (BETA - default=true)<br/>
 EndpointSlice=true|false (BETA - default=true)<br/>
 EndpointSliceProxying=true|false (BETA - default=true)<br/>
@@ -617,7 +617,6 @@ ServiceAppProtocol=true|false (BETA - default=true)<br/>
 ServiceNodeExclusion=true|false (BETA - default=true)<br/>
 ServiceTopology=true|false (ALPHA - default=false)<br/>
 SetHostnameAsFQDN=true|false (ALPHA - default=false)<br/>
-StartupProbe=true|false (BETA - default=true)<br/>
 StorageVersionHash=true|false (BETA - default=true)<br/>
 SupportNodePidsLimit=true|false (BETA - default=true)<br/>
 SupportPodPidsLimit=true|false (BETA - default=true)<br/>

content/en/docs/reference/kubectl/cheatsheet.md

@@ -90,6 +90,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml      # create from multiple files
 kubectl apply -f ./dir                         # create resource(s) in all manifest files in dir
 kubectl apply -f https://git.io/vPieo          # create resource(s) from url
 kubectl create deployment nginx --image=nginx  # start a single instance of nginx
+
+# create a Job which prints "Hello World"
+kubectl create job hello --image=busybox -- echo "Hello World" 
+
+# create a CronJob that prints "Hello World" every minute
+kubectl create cronjob hello --image=busybox   --schedule="*/1 * * * *" -- echo "Hello World"    
+
 kubectl explain pods                           # get the documentation for pod manifests
 
 # Create multiple YAML objects from stdin
@@ -304,6 +311,7 @@ kubectl run nginx --image=nginx                     # Run pod nginx and write it
 kubectl attach my-pod -i                            # Attach to Running Container
 kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
 kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case)
+kubectl exec --stdin --tty my-pod -- /bin/sh        # Interactive shell access to a running pod (1 container case) 
 kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case)
 kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers
 ```

content/en/docs/reference/kubectl/kubectl.md

@@ -206,6 +206,13 @@ kubectl [flags]
 <td></td><td style="line-height: 130%; word-wrap: break-word;">If present, the namespace scope for this CLI request</td>
 </tr>
 
+<tr>
+<td colspan="2">--one-output</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, only write logs to their native severity level (vs also writing to each lower severity level</td>
+</tr>
+
 <tr>
 <td colspan="2">--password string</td>
 </tr>
@@ -325,7 +332,6 @@ kubectl [flags]
 
 ## {{% heading "seealso" %}}
 
-* [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha)	 - Commands for features in alpha
 * [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate)	 - Update the annotations on a resource
 * [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources)	 - Print the supported API resources on the server
 * [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions)	 - Print the supported API versions on the server, in the form of "group/version"
@@ -337,10 +343,10 @@ kubectl [flags]
 * [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info)	 - Display cluster info
 * [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion)	 - Output shell completion code for the specified shell (bash or zsh)
 * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)	 - Modify kubeconfig files
-* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert)	 - Convert config files between different API versions
 * [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon)	 - Mark node as unschedulable
 * [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp)	 - Copy files and directories to and from containers.
 * [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create)	 - Create a resource from a file or from stdin.
+* [kubectl debug](/docs/reference/generated/kubectl/kubectl-commands#debug)	 - Create debugging sessions for troubleshooting workloads and nodes
 * [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete)	 - Delete resources by filenames, stdin, resources and names, or by resources and label selector
 * [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe)	 - Show details of a specific resource or group of resources
 * [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff)	 - Diff live version against would-be applied version
@@ -354,7 +360,7 @@ kubectl [flags]
 * [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label)	 - Update the labels on a resource
 * [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs)	 - Print the logs for a container in a pod
 * [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options)	 - Print the list of flags inherited by all commands
-* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch)	 - Update field(s) of a resource using strategic merge patch
+* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch)	 - Update field(s) of a resource
 * [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin)	 - Provides utilities for interacting with plugins.
 * [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward)	 - Forward one or more local ports to a pod
 * [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy)	 - Run a proxy to the Kubernetes API server

content/en/docs/reference/kubectl/overview.md

@@ -61,7 +61,7 @@ for example `create`, `get`, `describe`, `delete`.
    * To specify resources with one or more files:  `-f file1 -f file2 -f file<#>`
 
       * [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-configuration-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
-     Example: `kubectl get pod -f ./pod.yaml`
+     Example: `kubectl get -f ./pod.yaml`
 
 * `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.<br/>
 

content/en/docs/reference/kubernetes-api/api-index.md

@@ -1,6 +1,6 @@
 ---
-title: v1.19
+title: v1.20
 weight: 50
 ---
 
-[Kubernetes API v1.19](/docs/reference/generated/kubernetes-api/v1.19/)
+[Kubernetes API v1.20](/docs/reference/generated/kubernetes-api/v1.20/)

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md

@@ -13,8 +13,8 @@ kubeadm alpha kubeconfig user [flags]
 ### Examples
 
 ```
-  # Output a kubeconfig file for an additional user named foo
-  kubeadm alpha kubeconfig user --client-name=foo
+  # Output a kubeconfig file for an additional user named foo using a kubeadm config file bar
+  kubeadm alpha kubeconfig user --client-name=foo --config=bar
 ```
 
 ### Options
@@ -26,27 +26,6 @@ kubeadm alpha kubeconfig user [flags]
 </colgroup>
 <tbody>
 
-<tr>
-<td colspan="2">--apiserver-advertise-address string</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The IP address the API server is accessible on</td>
-</tr>
-
-<tr>
-<td colspan="2">--apiserver-bind-port int32&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: 6443</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The port the API server is accessible on</td>
-</tr>
-
-<tr>
-<td colspan="2">--cert-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: "/etc/kubernetes/pki"</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The path where certificates are stored</td>
-</tr>
-
 <tr>
 <td colspan="2">--client-name string</td>
 </tr>
@@ -54,6 +33,13 @@ kubeadm alpha kubeconfig user [flags]
 <td></td><td style="line-height: 130%; word-wrap: break-word;">The name of user. It will be used as the CN if client certificates are created</td>
 </tr>
 
+<tr>
+<td colspan="2">--config string</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to a kubeadm configuration file.</td>
+</tr>
+
 <tr>
 <td colspan="2">-h, --help</td>
 </tr>

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md

@@ -11,7 +11,7 @@ generate and print one for you.
 
 
 ```
-kubeadm alpha certs certificate-key [flags]
+kubeadm certs certificate-key [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_check-expiration.md

@@ -5,7 +5,7 @@
 Checks expiration for the certificates in the local PKI managed by kubeadm.
 
 ```
-kubeadm alpha certs check-expiration [flags]
+kubeadm certs check-expiration [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md

@@ -9,7 +9,7 @@ This command is designed for use in [Kubeadm External CA Mode](https://kubernete
 The PEM encoded signed certificates should then be saved alongside the key files, using ".crt" as the file extension, or in the case of kubeconfig files, the PEM encoded signed certificate should be base64 encoded and added to the kubeconfig file in the "users > user > client-certificate-data" field.
 
 ```
-kubeadm alpha certs generate-csr [flags]
+kubeadm certs generate-csr [flags]
 ```
 
 ### Examples

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md

@@ -5,7 +5,7 @@
 This command is not meant to be run on its own. See list of available subcommands.
 
 ```
-kubeadm alpha certs renew [flags]
+kubeadm certs renew [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_admin.conf.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew admin.conf [flags]
+kubeadm certs renew admin.conf [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_all.md

@@ -5,7 +5,7 @@
 Renew all known certificates necessary to run the control plane. Renewals are run unconditionally, regardless of expiration date. Renewals can also be run individually for more control.
 
 ```
-kubeadm alpha certs renew all [flags]
+kubeadm certs renew all [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-etcd-client.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew apiserver-etcd-client [flags]
+kubeadm certs renew apiserver-etcd-client [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-kubelet-client.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew apiserver-kubelet-client [flags]
+kubeadm certs renew apiserver-kubelet-client [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew apiserver [flags]
+kubeadm certs renew apiserver [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_controller-manager.conf.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew controller-manager.conf [flags]
+kubeadm certs renew controller-manager.conf [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-healthcheck-client.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew etcd-healthcheck-client [flags]
+kubeadm certs renew etcd-healthcheck-client [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-peer.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew etcd-peer [flags]
+kubeadm certs renew etcd-peer [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-server.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew etcd-server [flags]
+kubeadm certs renew etcd-server [flags]
 ```
 
 ### Options

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_front-proxy-client.md

@@ -11,7 +11,7 @@ Renewal by default tries to use the certificate authority in the local PKI manag
 After renewal, in order to make changes effective, is required to restart control-plane components and eventually re-distribute the renewed certificate in case the file is used elsewhere.
 
 ```
-kubeadm alpha certs renew front-proxy-client [flags]
+kubeadm certs renew front-proxy-client [flags]
 ```
 
 ### Options