Merge pull request #35229 from sethmccombs/merged-main-dev-1.25

Merge main into dev-1.25 branch: July 21st

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,4 @@
-<!-- 🛈
+<!-- ℹ️
 
  Hello!
 
@@ -9,7 +9,7 @@
  PLEASE title the FIRST commit appropriately, so that if you squash all
  your commits into one, the combined commit message makes sense.
  For overall help on editing and submitting pull requests, visit:
-  https://kubernetes.io/docs/contribute/start/#improve-existing-content
+  https://kubernetes.io/docs/contribute/suggest-improvements/
 
  Use the default base branch, “main”, if you're documenting existing
  features in the English localization.

CONTRIBUTING.md

@@ -9,7 +9,7 @@ These are just guidelines, not rules. Use your best judgment, and feel free to p
 
 ### Code of Conduct
 
-Kubernetes follows the [Cloud Native Computing Foundation (CNCF) Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to the
+Kubernetes follows the [Cloud Native Computing Foundation (CNCF) Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to the
 [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) <conduct@kubernetes.io>.
 
 ### Documentation and Site Decisions

Dockerfile

@@ -4,7 +4,7 @@
 # change is that the Hugo version is now an overridable argument rather than a fixed
 # environment variable.
 
-FROM golang:1.16-alpine
+FROM golang:1.18-alpine
 
 LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"
 
@@ -24,7 +24,7 @@ RUN mkdir $HOME/src && \
     cd "hugo-${HUGO_VERSION}" && \
     go install --tags extended
 
-FROM golang:1.16-alpine
+FROM golang:1.18-alpine
 
 RUN apk add --no-cache \
     runuser \

Makefile

@@ -9,7 +9,7 @@ CONTAINER_ENGINE ?= docker
 IMAGE_REGISTRY ?= gcr.io/k8s-staging-sig-docs
 IMAGE_VERSION=$(shell scripts/hash-files.sh Dockerfile Makefile | cut -c 1-12)
 CONTAINER_IMAGE   = $(IMAGE_REGISTRY)/k8s-website-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION)
-CONTAINER_RUN     = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src
+CONTAINER_RUN     = "$(CONTAINER_ENGINE)" run --rm --interactive --tty --volume "$(CURDIR):/src"
 
 CCRED=\033[0;31m
 CCEND=\033[0m
@@ -71,11 +71,15 @@ container-image: ## Build a container image for the preview of the website
 		--tag $(CONTAINER_IMAGE) \
 		--build-arg HUGO_VERSION=$(HUGO_VERSION)
 
+container-push: container-image ## Push container image for the preview of the website
+	$(CONTAINER_ENGINE) push $(CONTAINER_IMAGE)
+
 container-build: module-check
 	$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development"
 
-container-serve: module-check ## Boot the development server using container. Run `make container-image` before this.
-	$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
+# no build lock to allow for read-only mounts
+container-serve: module-check ## Boot the development server using container.
+	$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir --noBuildLock
 
 test-examples:
 	scripts/test_examples.sh install
@@ -91,7 +95,7 @@ docker-internal-linkcheck:
 
 container-internal-linkcheck: link-checker-image-pull
 	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test
-	$(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest
+	$(CONTAINER_ENGINE) run --mount "type=bind,source=$(CURDIR),target=/test" --rm wjdp/htmltest htmltest
 
 clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md
 	rm -rf content/en/docs/reference/kubernetes-api/*/

OWNERS_ALIASES

@@ -3,6 +3,7 @@ aliases:
     - onlydole
     - mrbobbytables
     - sftim
+    - nate-double-u
   sig-docs-blog-reviewers: # Reviewers for blog content
     - mrbobbytables
     - onlydole
@@ -24,8 +25,8 @@ aliases:
     - jimangel
     - jlbutler
     - kbhawkey
+    - kcmartin
     - natalisucks
-    - nate-double-u # RT 1.24 Docs Lead
     - onlydole
     - pi-victor
     - reylejano
@@ -128,6 +129,7 @@ aliases:
     # MasayaAoyama
     - nasa9084
     # oke-py
+    - ptux
   sig-docs-ko-owners: # Admins for Korean content
     - ClaudiaJKang
     - gochist
@@ -179,6 +181,7 @@ aliases:
     - tanjunchen
     - tengqm
     - xichengliudui
+    - ydFu
     # zhangxiaoyu-zidif
   sig-docs-pt-owners: # Admins for Portuguese content
     - edsoncelio
@@ -197,6 +200,7 @@ aliases:
     - devlware
     - jhonmike
     - rikatz
+    - stormqueen1990
     - yagonobre
   sig-docs-vi-owners: # Admins for Vietnamese content
     - huynguyennovem
@@ -249,7 +253,6 @@ aliases:
     - cpanato # SIG Technical Lead
     - jeremyrickard # SIG Technical Lead
     - justaugustus # SIG Chair
-    - LappleApple # SIG Program Manager
     - puerco # SIG Technical Lead
     - saschagrunert # SIG Chair
   release-engineering-approvers:

README-ko.md

@@ -4,6 +4,9 @@
 
 이 저장소에는 [쿠버네티스 웹사이트 및 문서](https://kubernetes.io/)를 빌드하는 데 필요한 자산이 포함되어 있습니다. 기여해주셔서 감사합니다!
 
+- [문서에 기여하기](#contributing-to-the-docs)
+- [`README.md`에 대한 쿠버네티스 문서 현지화](#localization-readmemds)
+
 # 저장소 사용하기
 
 Hugo(확장 버전)를 사용하여 웹사이트를 로컬에서 실행하거나, 컨테이너 런타임에서 실행할 수 있습니다. 라이브 웹사이트와의 배포 일관성을 제공하므로, 컨테이너 런타임을 사용하는 것을 적극 권장합니다.
@@ -40,6 +43,8 @@ make container-image
 make container-serve
 ```
 
+에러가 발생한다면, Hugo 컨테이너를 위한 컴퓨팅 리소스가 충분하지 않기 때문일 수 있습니다. 이를 해결하려면, 머신에서 도커에 허용할 CPU 및 메모리 사용량을 늘립니다([MacOSX](https://docs.docker.com/docker-for-mac/#resources) / [Windows](https://docs.docker.com/docker-for-windows/#resources)).
+
 웹사이트를 보려면 브라우저를 http://localhost:1313 으로 엽니다. 소스 파일을 변경하면 Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다.
 
 ## Hugo를 사용하여 로컬에서 웹사이트 실행하기
@@ -56,7 +61,45 @@ make serve
 
 그러면 포트 1313에서 로컬 Hugo 서버가 시작됩니다. 웹사이트를 보려면 http://localhost:1313 으로 브라우저를 엽니다. 소스 파일을 변경하면, Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다.
 
+## API 레퍼런스 페이지 빌드하기
+
+`content/en/docs/reference/kubernetes-api`에 있는 API 레퍼런스 페이지는 <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>를 사용하여 Swagger 명세로부터 빌드되었습니다.
+
+새로운 쿠버네티스 릴리스를 위해 레퍼런스 페이지를 업데이트하려면 다음 단계를 수행합니다.
+
+1. `api-ref-generator` 서브모듈을 받아옵니다.
+
+   ```bash
+   git submodule update --init --recursive --depth 1
+   ```
+
+2. Swagger 명세를 업데이트합니다.
+
+   ```bash
+   curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json
+   ```
+
+3. `api-ref-assets/config/`에서, 새 릴리스의 변경 사항이 반영되도록 `toc.yaml` 및 `fields.yaml` 파일을 업데이트합니다.
+
+4. 다음으로, 페이지를 빌드합니다.
+
+   ```bash
+   make api-reference
+   ```
+
+   로컬에서 결과를 테스트하기 위해 컨테이너 이미지를 이용하여 사이트를 빌드 및 실행합니다.
+
+   ```bash
+   make container-image
+   make container-serve
+   ```
+
+   웹 브라우저에서, <http://localhost:1313/docs/reference/kubernetes-api/>로 이동하여 API 레퍼런스를 확인합니다.
+
+5. 모든 API 변경사항이 `toc.yaml` 및 `fields.yaml` 구성 파일에 반영되었다면, 새로 생성된 API 레퍼런스 페이지에 대한 PR을 엽니다.
+
 ## 문제 해결
+
 ### 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` 라는 단어를 찾습니다.
@@ -97,17 +140,17 @@ 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://kubernetes.slack.com/messages/sig-docs)
+  - [슬랙에 초대 받기](https://slack.k8s.io/)
 - [메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
-# 문서에 기여하기
+# 문서에 기여하기 {#contributing-to-the-docs}
 
 이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭하면 됩니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
 
@@ -124,7 +167,15 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 * [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/)
 * [쿠버네티스 문서 현지화](https://kubernetes.io/docs/contribute/localization/)
 
-# `README.md`에 대한 쿠버네티스 문서 현지화(localization)
+### 신규 기여자 대사(ambassadors)
+
+기여 과정에서 도움이 필요하다면, [신규 기여자 대사](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador)에게 연락하는 것이 좋습니다. 이들은 신규 기여자를 멘토링하고 첫 PR 과정에서 도움을 주는 역할도 담당하는 SIG Docs 승인자입니다. 신규 기여자 대사에게 문의할 가장 좋은 곳은 [쿠버네티스 슬랙](https://slack.k8s.io/)입니다. 현재 SIG Docs 신규 기여자 대사는 다음과 같습니다.
+
+| Name                       | Slack                      | GitHub                     |                   
+| -------------------------- | -------------------------- | -------------------------- |
+| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+
+# `README.md`에 대한 쿠버네티스 문서 현지화(localization) {#localization-readmemds}
 
 ## 한국어
 
@@ -135,6 +186,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 * 손석호 ([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-zh.md

@@ -13,7 +13,14 @@ This repository contains the assets required to build the [Kubernetes website an
 我们非常高兴您想要参与贡献！
 
 <!--
-# Using this repository
+- [Contributing to the docs](#contributing-to-the-docs)
+- [Localization ReadMes](#localization-readmemds)
+-->
+- [为文档做贡献](#为文档做贡献)
+- [README.md 本地化](#readmemd-本地化)
+
+<!--
+## Using this repository
 
 You can run the website locally using Hugo (Extended version), or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website.
 -->
@@ -46,7 +53,7 @@ Before you start, install the dependencies. Clone the repository and navigate to
 -->
 开始前，先安装这些依赖。克隆本仓库并进入对应目录：
 
-```
+```bash
 git clone https://github.com/kubernetes/website.git
 cd website
 ```
@@ -57,8 +64,8 @@ The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/doc
 
 Kubernetes 网站使用的是 [Docsy Hugo 主题](https://github.com/google/docsy#readme)。 即使你打算在容器中运行网站，我们也强烈建议你通过运行以下命令来引入子模块和其他开发依赖项：
 
-```
-# pull in the Docsy submodule
+```bash
+# 引入 Docsy 子模块
 git submodule update --init --recursive --depth 1
 ```
 
@@ -72,15 +79,23 @@ To build the site in a container, run the following to build the container image
 
 要在容器中构建网站，请通过以下命令来构建容器镜像并运行：
 
-```
-make container-image
+```bash
+# 你可以将 $CONTAINER_ENGINE 设置为任何 Docker 类容器工具的名称
 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.
+If you see errors, it probably means that the hugo container did not have enough computing resources available. To solve it, increase the amount of allowed CPU and memory usage for Docker on your machine ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) and [Windows](https://docs.docker.com/docker-for-windows/#resources)).
 -->
-启动浏览器，打开 http://localhost:1313 来查看网站。
+如果您看到错误，这可能意味着 hugo 容器没有足够的可用计算资源。
+要解决这个问题，请增加机器（[MacOSX](https://docs.docker.com/docker-for-mac/#resources)
+和 [Windows](https://docs.docker.com/docker-for-windows/#resources)）上
+Docker 允许的 CPU 和内存使用量。
+
+<!--
+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 会更新网站并强制浏览器执行刷新操作。
 
 <!--
@@ -98,24 +113,90 @@ Hugo 扩展版本。
 若要在本地构造和测试网站，请运行：
 
 ```bash
-# install dependencies
+# 安装依赖
 npm ci
 make serve
 ```
 
 <!--
-This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+This will start the local Hugo server on port 1313. Open up your browser to <http://localhost:1313> to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
 -->
 上述命令会在端口 1313 上启动本地 Hugo 服务器。
-启动浏览器，打开 http://localhost:1313 来查看网站。
+启动浏览器，打开 <http://localhost:1313> 来查看网站。
 当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。
 
+<!--
+## Building the API reference pages
+-->
+## 构建 API 参考页面
+
+<!--
+The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, using <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>.
+
+To update the reference pages for a new Kubernetes release follow these steps:
+-->
+位于 `content/en/docs/reference/kubernetes-api` 的 API 参考页面是根据 Swagger 规范构建的，使用 <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>。
+
+要更新新 Kubernetes 版本的参考页面，请执行以下步骤：
+
+<!--
+1. Pull in the `api-ref-generator` submodule:
+-->
+1. 拉取 `api-ref-generator` 子模块：
+
+   ```bash
+   git submodule update --init --recursive --depth 1
+   ```
+
+<!--
+2. Update the Swagger specification:
+-->
+2. 更新 Swagger 规范：
+
+   ```bash
+   curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json
+   ```
+
+<!--
+3. In `api-ref-assets/config/`, adapt the files `toc.yaml` and `fields.yaml` to reflect the changes of the new release.
+-->
+3. 在 `api-ref-assets/config/` 中，调整文件 `toc.yaml` 和 `fields.yaml` 以反映新版本的变化。
+
+<!--
+4. Next, build the pages:
+-->
+4. 接下来，构建页面：
+
+   ```bash
+   make api-reference
+   ```
+
+<!--
+   You can test the results locally by making and serving the site from a container image:
+-->
+   您可以通过从容器映像创建和提供站点来在本地测试结果：
+
+   ```bash
+   make container-image
+   make container-serve
+   ```
+
+<!--
+   In a web browser, go to <http://localhost:1313/docs/reference/kubernetes-api/> to view the API reference.
+-->
+   在 Web 浏览器中，打开 <http://localhost:1313/docs/reference/kubernetes-api/> 查看 API 参考。
+
+<!--
+5. When all changes of the new contract are reflected into the configuration files `toc.yaml` and `fields.yaml`, create a Pull Request with the newly generated API reference pages.
+-->
+5. 当所有新的更改都反映到配置文件 `toc.yaml` 和 `fields.yaml` 中时，使用新生成的 API 参考页面创建一个 Pull Request。
+
 <!--
 ## 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`.
-
 -->
 ## 故障排除
 
@@ -135,18 +216,24 @@ If you run `make serve` on macOS and receive the following error:
 
 如果在 macOS 上运行 `make serve` 收到以下错误：
 
-```
+```bash
 ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
 make: *** [serve] Error 1
 ```
 
+<!--
+Try checking the current limit for open files:
+-->
 试着查看一下当前打开文件数的限制：
 
 `launchctl limit maxfiles`
 
-然后运行以下命令（参考https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c）：
+<!--
+Then run the following commands (adapted from <https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c>):
+-->
+然后运行以下命令（参考 <https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c>）：
 
-```
+```shell
 #!/bin/sh
 
 # These are the original gist links, linking to my gists now.
@@ -165,8 +252,56 @@ sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
 sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 ```
 
+<!--
+This works for Catalina as well as Mojave macOS.
+-->
 这适用于 Catalina 和 Mojave macOS。
 
+### 对执行 make container-image 命令部分地区访问超时的故障排除
+
+现象如下：
+
+```shell
+langs/language.go:23:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+langs/language.go:24:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+common/text/transform.go:21:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+common/text/transform.go:22:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+common/text/transform.go:23:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+hugolib/integrationtest_builder.go:29:2: golang.org/x/tools@v0.1.11: Get "https://proxy.golang.org/golang.org/x/tools/@v/v0.1.11.zip": dial tcp 142.251.42.241:443: i/o timeout
+deploy/google.go:24:2: google.golang.org/api@v0.76.0: Get "https://proxy.golang.org/google.golang.org/api/@v/v0.76.0.zip": dial tcp 142.251.43.17:443: i/o timeout
+parser/metadecoders/decoder.go:32:2: gopkg.in/yaml.v2@v2.4.0: Get "https://proxy.golang.org/gopkg.in/yaml.v2/@v/v2.4.0.zip": dial tcp 142.251.42.241:443: i/o timeout
+The command '/bin/sh -c mkdir $HOME/src &&     cd $HOME/src &&     curl -L https://github.com/gohugoio/hugo/archive/refs/tags/v${HUGO_VERSION}.tar.gz | tar -xz &&     cd "hugo-${HUGO_VERS    ION}" &&     go install --tags extended' returned a non-zero code: 1
+make: *** [Makefile:69：container-image] error 1
+```
+
+请修改 `Dockerfile` 文件，为其添加网络代理。修改内容如下：
+
+```dockerfile
+...
+FROM golang:1.18-alpine
+
+LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"
+
+ENV GO111MODULE=on                            # 需要添加内容1
+
+ENV GOPROXY=https://proxy.golang.org,direct   # 需要添加内容2
+
+RUN apk add --no-cache \
+    curl \
+    gcc \
+    g++ \
+    musl-dev \
+    build-base \
+    libc6-compat
+
+ARG HUGO_VERSION
+...
+```
+
+将 "https://proxy.golang.org" 替换为本地可以使用的代理地址。
+
+**注意：** 此部分仅适用于中国大陆 
+
 <!--
 ## Get involved with SIG Docs
 
@@ -174,7 +309,8 @@ Learn more about SIG Docs Kubernetes community and meetings on the [community pa
 
 You can also reach the maintainers of this project at:
 
-- [Slack](https://kubernetes.slack.com/messages/sig-docs) [Get an invite for this Slack](https://slack.k8s.io/)
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+  - [Get an invite for this Slack](https://slack.k8s.io/)
 - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 -->
 # 参与 SIG Docs 工作
@@ -184,20 +320,21 @@ You can also reach the maintainers of this project at:
 
 你也可以通过以下渠道联系本项目的维护人员：
 
-- [Slack](https://kubernetes.slack.com/messages/sig-docs) [加入Slack](https://slack.k8s.io/)
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+  - [获得此 Slack 的邀请](https://slack.k8s.io/)
 - [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
 <!--
 ## Contributing to the docs
 
-You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
+You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a _fork_. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
 
-Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.  As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
+Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
 -->
 # 为文档做贡献
 
 你也可以点击屏幕右上方区域的 **Fork** 按钮，在你自己的 GitHub
-账号下创建本仓库的拷贝。此拷贝被称作 *fork*。
+账号下创建本仓库的拷贝。此拷贝被称作 _fork_。
 你可以在自己的拷贝中任意地修改文档，并在你已准备好将所作修改提交给我们时，
 在你自己的拷贝下创建一个拉取请求（Pull Request），以便让我们知道。
 
@@ -208,7 +345,7 @@ Once your pull request is created, a Kubernetes reviewer will take responsibilit
 <!--
 Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.
 
-Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed.  Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
+Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
 -->
 还要提醒的一点，有时可能会有不止一个 Kubernetes 评审人为你提供反馈意见。
 有时候，某个评审人的意见和另一个最初被指派的评审人的意见不同。
@@ -220,17 +357,65 @@ Furthermore, in some cases, one of your reviewers might ask for a technical revi
 <!--
 For more information about contributing to the Kubernetes documentation, see:
 
-* [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
-* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
-* [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
-* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
+- [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
+- [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
+- [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
+- [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
 -->
 有关为 Kubernetes 文档做出贡献的更多信息，请参阅：
 
-* [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/)
-* [页面内容类型](https://kubernetes.io/docs/contribute/style/page-content-types/)
-* [文档风格指南](https://kubernetes.io/docs/contribute/style/style-guide/)
-* [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
+- [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/)
+- [页面内容类型](https://kubernetes.io/docs/contribute/style/page-content-types/)
+- [文档风格指南](https://kubernetes.io/docs/contribute/style/style-guide/)
+- [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
+
+<!--
+### New contributor ambassadors
+-->
+### 新贡献者大使
+
+<!--
+If you need help at any point when contributing, the [New Contributor Ambassadors](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador) are a good point of contact. These are SIG Docs approvers whose responsibilities include mentoring new contributors and helping them through their first few pull requests. The best place to contact the New Contributors Ambassadors would be on the [Kubernetes Slack](https://slack.k8s.io/). Current New Contributors Ambassadors for SIG Docs:
+-->
+如果您在贡献时需要帮助，[新贡献者大使](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador)是一个很好的联系人。
+这些是 SIG Docs 批准者，其职责包括指导新贡献者并帮助他们完成最初的几个拉取请求。
+联系新贡献者大使的最佳地点是 [Kubernetes Slack](https://slack.k8s.io/)。
+SIG Docs 的当前新贡献者大使：
+
+<!--
+| Name                       | Slack                      | GitHub                     |                   
+| -------------------------- | -------------------------- | -------------------------- |
+| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+-->
+| 姓名                       | Slack                      | GitHub                     |                   
+| -------------------------- | -------------------------- | -------------------------- |
+| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+
+<!--
+## Localization `README.md`'s
+-->
+## `README.md` 本地化
+
+<!--
+| Language                   | Language                   |
+| -------------------------- | -------------------------- |
+| [Chinese](README-zh.md)    | [Korean](README-ko.md)     |
+| [French](README-fr.md)     | [Polish](README-pl.md)     |
+| [German](README-de.md)     | [Portuguese](README-pt.md) |
+| [Hindi](README-hi.md)      | [Russian](README-ru.md)    |
+| [Indonesian](README-id.md) | [Spanish](README-es.md)    |
+| [Italian](README-it.md)    | [Ukrainian](README-uk.md)  |
+| [Japanese](README-ja.md)   | [Vietnamese](README-vi.md) |
+-->
+| 语言                       | 语言                       |
+| -------------------------- | -------------------------- |
+| [中文](README-zh.md)       | [韩语](README-ko.md)       |
+| [法语](README-fr.md)       | [波兰语](README-pl.md)     |
+| [德语](README-de.md)       | [葡萄牙语](README-pt.md)   |
+| [印地语](README-hi.md)     | [俄语](README-ru.md)       |
+| [印尼语](README-id.md)     | [西班牙语](README-es.md)   |
+| [意大利语](README-it.md)   | [乌克兰语](README-uk.md)   |
+| [日语](README-ja.md)       | [越南语](README-vi.md)     |
 
 # 中文本地化
 
@@ -241,19 +426,19 @@ For more information about contributing to the Kubernetes documentation, see:
 * [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-zh)
 
 <!--
-### Code of conduct
+## Code of conduct
 
 Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
 -->
-# 行为准则
+## 行为准则
 
 参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 约束。
 
 <!--
-## Thank you!
+## Thank you
 
 Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
 -->
-# 感谢！
+## 感谢你
 
 Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！

README.md

@@ -36,10 +36,10 @@ 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:
+To build the site in a container, run the following:
 
 ```bash
-make container-image
+# You can set $CONTAINER_ENGINE to the name of any Docker-like container tool
 make container-serve
 ```
 
@@ -189,7 +189,7 @@ If you need help at any point when contributing, the [New Contributor Ambassador
 
 ## Code of conduct
 
-Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
+Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).
 
 ## Thank you
 

assets/scss/_custom.scss

@@ -634,12 +634,12 @@ body.td-documentation {
 
   a {
     color: inherit;
-    border-bottom: 1px solid #fff;
+    text-decoration: underline;
   }
 
   a:hover {
     color: inherit;
-    border-bottom: none;
+    text-decoration: initial;
   }
 }
 
@@ -648,6 +648,9 @@ body.td-documentation {
 }
 
 #announcement {
+  // default background is blue; overrides are possible
+  color: #fff;
+
   .announcement-main {
     margin-left: auto;
     margin-right: auto;
@@ -660,9 +663,8 @@ body.td-documentation {
   }
 
 
-  /* always white */
   h1, h2, h3, h4, h5, h6, p * {
-    color: #ffffff;
+    color: inherit; /* defaults to white */
     background: transparent;
 
     img.event-logo {

cloudbuild.yaml

@@ -9,17 +9,20 @@ options:
 steps:
     # It's fine to bump the tag to a recent version, as needed
   - name: "gcr.io/k8s-staging-test-infra/gcb-docker-gcloud:v20210917-12df099d55"
-    entrypoint: make
+    entrypoint: 'bash'
     env:
       - DOCKER_CLI_EXPERIMENTAL=enabled
       - TAG=$_GIT_TAG
       - BASE_REF=$_PULL_BASE_REF
     args:
-      - container-image
+      - -c
+      - |
+        gcloud auth configure-docker \
+        && make container-push
 substitutions:
   # _GIT_TAG will be filled with a git-based tag for the image, of the form vYYYYMMDD-hash, and
   # can be used as a substitution
   _GIT_TAG: "12345"
   # _PULL_BASE_REF will contain the ref that was pushed to to trigger this build -
-  # a branch like 'master' or 'release-0.2', or a tag like 'v0.2'.
-  _PULL_BASE_REF: "master"
+  # a branch like 'main' or 'release-0.2', or a tag like 'v0.2'.
+  _PULL_BASE_REF: "main"

config.toml

@@ -122,7 +122,7 @@ id = "UA-00000000-0"
 
 [params]
 copyright_k8s = "The Kubernetes Authors"
-copyright_linux =  "Copyright © 2020 The Linux Foundation ®."
+copyright_linux = "Copyright © 2020 The Linux Foundation ®."
 
 # privacy_policy = "https://policies.google.com/privacy"
 
@@ -139,10 +139,10 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.24"
+latest = "v1.25"
 
-fullversion = "v1.24.0"
-version = "v1.24"
+fullversion = "v1.25.0"
+version = "v1.25"
 githubbranch = "main"
 docsbranch = "main"
 deprecated = false
@@ -155,10 +155,10 @@ githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"
 # GitHub repository link for editing a page and opening issues.
 github_repo = "https://github.com/kubernetes/website"
 
-#Searching
+# Searching
 k8s_search = true
 
-#The following search parameters are specific to Docsy's implementation. Kubernetes implementes its own search-related partials and scripts.
+# The following search parameters are specific to Docsy's implementation. Kubernetes implementes its own search-related partials and scripts.
 
 # Google Custom Search Engine ID. Remove or comment out to disable search.
 #gcs_engine_id = "011737558837375720776:fsdu1nryfng"
@@ -179,40 +179,40 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.24.0"
-version = "v1.24"
-githubbranch = "v1.24.0"
+fullversion = "v1.25.0"
+version = "v1.25"
+githubbranch = "v1.25.0"
 docsbranch = "main"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.23.6"
+fullversion = "v1.24.2"
+version = "v1.24"
+githubbranch = "v1.24.2"
+docsbranch = "release-1.24"
+url = "https://v1-24.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.23.8"
 version = "v1.23"
-githubbranch = "v1.23.6"
+githubbranch = "v1.23.8"
 docsbranch = "release-1.23"
 url = "https://v1-23.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.22.9"
+fullversion = "v1.22.11"
 version = "v1.22"
-githubbranch = "v1.22.9"
+githubbranch = "v1.22.11"
 docsbranch = "release-1.22"
 url = "https://v1-22.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.21.12"
+fullversion = "v1.21.14"
 version = "v1.21"
-githubbranch = "v1.21.12"
+githubbranch = "v1.21.14"
 docsbranch = "release-1.21"
 url = "https://v1-21.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.20.15"
-version = "v1.20"
-githubbranch = "v1.20.15"
-docsbranch = "release-1.20"
-url = "https://v1-20.docs.kubernetes.io"
-
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.
@@ -221,11 +221,11 @@ sidebar_menu_compact = false
 sidebar_menu_foldable = true
 # https://github.com/gohugoio/hugo/issues/8918#issuecomment-903314696
 sidebar_cache_limit = 1
-#  Set to true to disable breadcrumb navigation.
+# Set to true to disable breadcrumb navigation.
 breadcrumb_disable = false
-#  Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)
+# Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)
 sidebar_search_disable = false
-#  Set to false if you don't want to display a logo (/assets/icons/logo.svg) in the top nav bar
+# Set to false if you don't want to display a logo (/assets/icons/logo.svg) in the top nav bar
 navbar_logo = true
 # Set to true to disable the About link in the site footer
 footer_about_disable = false
@@ -246,50 +246,50 @@ no = 'Sorry to hear that. Please <a href="https://github.com/USERNAME/REPOSITORY
 	name = "User mailing list"
 	url = "https://discuss.kubernetes.io"
 	icon = "fa fa-envelope"
-  desc = "Discussion and help from your fellow users"
+	desc = "Discussion and help from your fellow users"
 
 [[params.links.user]]
 	name = "Twitter"
 	url = "https://twitter.com/kubernetesio"
 	icon = "fab fa-twitter"
-  desc = "Follow us on Twitter to get the latest news!"
+	desc = "Follow us on Twitter to get the latest news!"
 
 [[params.links.user]]
 	name = "Calendar"
 	url = "https://calendar.google.com/calendar/embed?src=calendar%40kubernetes.io"
 	icon = "fas fa-calendar-alt"
-  desc = "Google Calendar for Kubernetes"
+	desc = "Google Calendar for Kubernetes"
 
 [[params.links.user]]
 	name = "Youtube"
 	url = "https://youtube.com/kubernetescommunity"
 	icon = "fab fa-youtube"
-  desc = "Youtube community videos"
+	desc = "Youtube community videos"
 
 # Developer relevant links. These will show up on right side of footer and in the community page if you have one.
 [[params.links.developer]]
 	name = "GitHub"
 	url = "https://github.com/kubernetes/kubernetes"
 	icon = "fab fa-github"
-  desc = "Development takes place here!"
+	desc = "Development takes place here!"
 
 [[params.links.developer]]
 	name = "Slack"
 	url = "https://slack.k8s.io"
 	icon = "fab fa-slack"
-  desc = "Chat with other project developers"
+	desc = "Chat with other project developers"
 
 [[params.links.developer]]
 	name = "Contribute"
 	url = "https://git.k8s.io/community/contributors/guide"
 	icon = "fas fa-edit"
-  desc = "Contribute to the Kubernetes website"
+	desc = "Contribute to the Kubernetes website"
 
 [[params.links.developer]]
 	name = "Stack Overflow"
 	url = "https://stackoverflow.com/questions/tagged/kubernetes"
 	icon = "fab fa-stack-overflow"
-  desc = "Practical questions and curated answers"
+	desc = "Practical questions and curated answers"
 
 # Language definitions.
 
@@ -297,27 +297,29 @@ no = 'Sorry to hear that. Please <a href="https://github.com/USERNAME/REPOSITORY
 [languages.en]
 title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
-languageName ="English"
+languageName = "English"
 # Weight used for sorting.
 weight = 1
 languagedirection = "ltr"
 
-[languages.zh]
+[languages.zh-cn]
 title = "Kubernetes"
 description = "生产级别的容器编排系统"
-languageName = "中文 Chinese"
+languageName = "中文 (Chinese)"
+languageNameLatinScript = "Chinese"
 weight = 2
-contentDir = "content/zh"
+contentDir = "content/zh-cn"
 languagedirection = "ltr"
 
-[languages.zh.params]
+[languages.zh-cn.params]
 time_format_blog = "2006.01.02"
 language_alternatives = ["en"]
 
 [languages.ko]
 title = "Kubernetes"
 description = "운영 수준의 컨테이너 오케스트레이션"
-languageName = "한국어 Korean"
+languageName = "한국어 (Korean)"
+languageNameLatinScript = "Korean"
 weight = 3
 contentDir = "content/ko"
 languagedirection = "ltr"
@@ -329,7 +331,8 @@ language_alternatives = ["en"]
 [languages.ja]
 title = "Kubernetes"
 description = "プロダクショングレードのコンテナ管理基盤"
-languageName = "日本語 Japanese"
+languageName = "日本語 (Japanese)"
+languageNameLatinScript = "Japanese"
 weight = 4
 contentDir = "content/ja"
 languagedirection = "ltr"
@@ -341,7 +344,8 @@ language_alternatives = ["en"]
 [languages.fr]
 title = "Kubernetes"
 description = "Solution professionnelle d’orchestration de conteneurs"
-languageName ="Français"
+languageName = "Français (French)"
+languageNameLatinScript = "Français"
 weight = 5
 contentDir = "content/fr"
 languagedirection = "ltr"
@@ -354,7 +358,8 @@ language_alternatives = ["en"]
 [languages.it]
 title = "Kubernetes"
 description = "Orchestrazione di Container in produzione"
-languageName = "Italiano"
+languageName = "Italiano (Italian)"
+languageNameLatinScript = "Italiano"
 weight = 6
 contentDir = "content/it"
 languagedirection = "ltr"
@@ -367,7 +372,8 @@ language_alternatives = ["en"]
 [languages.no]
 title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
-languageName ="Norsk"
+languageName = "Norsk (Norwegian)"
+languageNameLatinScript = "Norsk"
 weight = 7
 contentDir = "content/no"
 languagedirection = "ltr"
@@ -380,7 +386,8 @@ language_alternatives = ["en"]
 [languages.de]
 title = "Kubernetes"
 description = "Produktionsreife Container-Orchestrierung"
-languageName ="Deutsch"
+languageName = "Deutsch (German)"
+languageNameLatinScript = "Deutsch"
 weight = 8
 contentDir = "content/de"
 languagedirection = "ltr"
@@ -393,7 +400,8 @@ language_alternatives = ["en"]
 [languages.es]
 title = "Kubernetes"
 description = "Orquestación de contenedores para producción"
-languageName ="Español"
+languageName = "Español (Spanish)"
+languageNameLatinScript = "Español"
 weight = 9
 contentDir = "content/es"
 languagedirection = "ltr"
@@ -406,8 +414,10 @@ language_alternatives = ["en"]
 [languages.pt-br]
 title = "Kubernetes"
 description = "Orquestração de contêineres em nível de produção"
-languageName ="Português"
-weight = 9
+languageName = "Português (Portuguese)"
+languageNameLatinScript = "Português"
+weight = 10
+
 contentDir = "content/pt-br"
 languagedirection = "ltr"
 
@@ -420,7 +430,8 @@ language_alternatives = ["en"]
 title = "Kubernetes"
 description = "Orkestrasi Kontainer dengan Skala Produksi"
 languageName ="Bahasa Indonesia"
-weight = 10
+languageNameLatinScript = "Bahasa Indonesia"
+weight = 11
 contentDir = "content/id"
 languagedirection = "ltr"
 
@@ -432,8 +443,9 @@ language_alternatives = ["en"]
 [languages.hi]
 title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
-languageName = "Hindi"
-weight = 11
+languageName = "हिन्दी (Hindi)"
+languageNameLatinScript = "Hindi"
+weight = 12
 contentDir = "content/hi"
 languagedirection = "ltr"
 
@@ -444,16 +456,18 @@ language_alternatives = ["en"]
 [languages.vi]
 title = "Kubernetes"
 description = "Giải pháp điều phối container trong môi trường production"
-languageName = "Tiếng Việt"
+languageName = "Tiếng Việt (Vietnamese)"
+languageNameLatinScript = "Tiếng Việt"
 contentDir = "content/vi"
-weight = 12
+weight = 13
 languagedirection = "ltr"
 
 [languages.ru]
 title = "Kubernetes"
 description = "Первоклассная оркестрация контейнеров"
-languageName = "Русский"
-weight = 12
+languageName = "Русский (Russian)"
+languageNameLatinScript = "Russian"
+weight = 14
 contentDir = "content/ru"
 languagedirection = "ltr"
 
@@ -465,8 +479,9 @@ language_alternatives = ["en"]
 [languages.pl]
 title = "Kubernetes"
 description = "Produkcyjny system zarządzania kontenerami"
-languageName = "Polski"
-weight = 13
+languageName = "Polski (Polish)"
+languageNameLatinScript = "Polski"
+weight = 15
 contentDir = "content/pl"
 languagedirection = "ltr"
 
@@ -478,8 +493,9 @@ language_alternatives = ["en"]
 [languages.uk]
 title = "Kubernetes"
 description = "Довершена система оркестрації контейнерів"
-languageName = "Українська"
-weight = 14
+languageName = "Українська (Ukrainian)"
+languageNameLatinScript = "Ukrainian"
+weight = 16
 contentDir = "content/uk"
 languagedirection = "ltr"
 

content/de/docs/concepts/cluster-administration/addons.md

@@ -21,15 +21,15 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
 
 * [ACI](https://www.github.com/noironetworks/aci-containers) bietet Container-Networking und Network-Security mit Cisco ACI.
 * [Calico](https://docs.projectcalico.org/latest/introduction/) ist ein Networking- und Network-Policy-Provider. Calico unterstützt eine Reihe von Networking-Optionen, damit Du die richtige für deinen Use-Case wählen kannst. Dies beinhaltet Non-Overlaying and Overlaying-Networks mit oder ohne BGP. Calico nutzt die gleiche Engine um Network-Policies für Hosts, Pods und (falls Du Istio & Envoy benutzt) Anwendungen auf Service-Mesh-Ebene durchzusetzen.
-* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen.
+* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen.
 * [Cilium](https://github.com/cilium/cilium) ist ein L3 Network- and Network-Policy-Plugin welches das transparent HTTP/API/L7-Policies durchsetzen kann. Sowohl Routing- als auch Overlay/Encapsulation-Modes werden uterstützt. Außerdem kann Cilium auf andere CNI-Plugins aufsetzen.
-* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
+* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
 * [Contiv](https://contivpp.io/) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
 * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
 * [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
-* Multus ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
-* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
+* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
+* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt.
 * [Romana](https://github.com/romana/romana) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.
 * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) bietet Networking and Network-Policies und arbeitet auf beiden Seiten der Network-Partition ohne auf eine externe Datenbank angwiesen zu sein.

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

@@ -16,7 +16,7 @@ Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die
 
 ## Aktualisieren von Images
 
-Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu, dass das Kubelet Images überspringt, die bereits auf einem Node vorliegen.
+Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu, dass das Image wird nur heruntergeladen wenn es noch nicht lokal verfügbar ist.
 Wenn sie stattdessen möchten, dass ein Image immer forciert heruntergeladen wird, können sie folgendes tun:
 
 

content/de/docs/concepts/extend-kubernetes/_index.md

@@ -1,4 +1,4 @@
 ---
-title: "Kubernets erweitern"
+title: "Kubernetes erweitern"
 weight: 110
 ---

content/de/docs/concepts/overview/what-is-kubernetes.md

@@ -54,14 +54,14 @@ die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigen
 ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
 universellen [Kommandozeilen-Tool](/docs/user-guide/kubectl-overview/) angesprochen werden können.
 
-Dieses [Design](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.
+Dieses [Design](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.
 
 ## Was Kubernetes nicht ist
 
 Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-,
 sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind,
 wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung.
-Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar.
+Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular erweiterbar.
 Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die
 Wahlmöglichkeiten und Flexibilität der Benutzer, wo es wichtig ist.
 
@@ -79,7 +79,7 @@ Kubernetes:
   Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können
   auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über
   portable Mechanismen wie den Open Service Broker angesprochen werden.
-* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)).
+* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B. [jsonnet](https://github.com/google/jsonnet)).
   Es bietet eine deklarative API, die von beliebigen Formen deklarativer Spezifikationen angesprochen werden kann.
 * Bietet keine umfassenden Systeme zur Maschinenkonfiguration, Wartung, Verwaltung oder Selbstheilung.
 
@@ -135,17 +135,17 @@ Zusammenfassung der Container-Vorteile:
 * **Dev und Ops Trennung der Bedenken**:
     Erstellen Sie Anwendungscontainer-Images nicht zum Deployment-, sondern zum Build-Releasezeitpunkt
     und entkoppeln Sie so Anwendungen von der Infrastruktur.
-* **Überwachbarkeit**
+* **Überwachbarkeit**:
     Nicht nur Informationen und Metriken auf Betriebssystemebene werden angezeigt,
     sondern auch der Zustand der Anwendung und andere Signale.
 * **Umgebungskontinuität in Entwicklung, Test und Produktion**:
     Läuft auf einem Laptop genauso wie in der Cloud.
-* **Cloud- und OS-Distribution portabilität**:
+* **Cloud- und OS-Distribution-Portabilität**:
     Läuft auf Ubuntu, RHEL, CoreOS, On-Prem, Google Kubernetes Engine und überall sonst.
 * **Anwendungsorientiertes Management**:
     Erhöht den Abstraktionsgrad vom Ausführen eines Betriebssystems auf virtueller Hardware
     bis zum Ausführen einer Anwendung auf einem Betriebssystem unter Verwendung logischer Ressourcen.
-* **Locker gekoppelte, verteilte, elastische, freie [micro-services](https://martinfowler.com/articles/microservices.html)**:
+* **Locker gekoppelte, verteilte, elastische, freie [Microservices](https://martinfowler.com/articles/microservices.html)**:
     Anwendungen werden in kleinere, unabhängige Teile zerlegt und können dynamisch bereitgestellt
     und verwaltet werden -- nicht ein monolithischer Stack, der auf einer großen Single-Purpose-Maschine läuft.
 * **Ressourcenisolierung**:

content/de/docs/contribute/_index.md

@@ -1,6 +1,6 @@
 ---
 content_type: concept
-title: Zur Kubernets-Dokumentation beitragen
+title: Zur Kubernetes-Dokumentation beitragen
 linktitle: Mitmachen
 main_menu: true
 weight: 80

content/de/docs/contribute/participate/pr-wranglers.md

@@ -76,6 +76,6 @@ Um eine Pull-Anfrage zu schließen, hinterlasse einen `/close`-Kommentar zu dem
 
 {{< note >}}
 
-Der [`fejta-bot`](https://github.com/fejta-bot) Bot markiert Themen nach 90 Tagen Inaktivität als veraltet. Nach weiteren 30 Tagen markiert er Issues als faul und schließt sie.  PR-Beauftragte sollten Themen nach 14-30 Tagen Inaktivität schließen.
+Der [`k8s-ci-robot`](https://github.com/k8s-ci-robot) Bot markiert Themen nach 90 Tagen Inaktivität als veraltet. Nach weiteren 30 Tagen markiert er Issues als faul und schließt sie.  PR-Beauftragte sollten Themen nach 14-30 Tagen Inaktivität schließen.
 
 {{< /note >}}

content/de/docs/reference/_index.md

@@ -56,6 +56,6 @@ Offiziell unterstützte Clientbibliotheken:
 
 ## Design Dokumentation
 
-Ein Archiv der Designdokumente für Kubernetes-Funktionalität. Gute Ansatzpunkte sind [Kubernetes Architektur](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) und [Kubernetes Design Übersicht](https://git.k8s.io/community/contributors/design-proposals).
+Ein Archiv der Designdokumente für Kubernetes-Funktionalität. Gute Ansatzpunkte sind [Kubernetes Architektur](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) und [Kubernetes Design Übersicht](https://git.k8s.io/community/contributors/design-proposals).
 
 

content/de/docs/setup/minikube.md

@@ -424,7 +424,7 @@ export no_proxy=$no_proxy,$(minikube ip)
 
 Minikube verwendet [libmachine](https://github.com/docker/machine/tree/master/libmachine) zur Bereitstellung von VMs, und [kubeadm](https://github.com/kubernetes/kubeadm) um einen Kubernetes-Cluster in Betrieb zu nehmen.
 
-Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
+Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/local-cluster-ux.md).
 
 ## Zusätzliche Links
 

content/de/docs/tasks/job/_index.md

@@ -1,5 +1,6 @@
 ---
 title: "Jobs ausführen"
+description: Führen Sie Jobs mit paralleler Verarbeitung aus.
 weight: 50
 ---
 

content/de/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -11,7 +11,7 @@ weight: 90
 
 <!-- overview -->
 
-Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets.
+Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets.
 
 Der Horizontal Pod Autoscaler ist als Kubernetes API-Ressource und einem Controller implementiert.
 Die Ressource bestimmt das Verhalten des Controllers.
@@ -46,7 +46,7 @@ Das Verwenden von Metriken aus Heapster ist seit der Kubernetes Version 1.11 ver
 
 Siehe [Unterstützung der Metrik APIs](#unterstützung-der-metrik-apis) für weitere Details.
 
-Der Autoscaler greift über die Scale Sub-Ressource auf die entsprechenden skalierbaren Controller (z.B. Replication Controller, Deployments und Replika Sets) zu. Scale ist eine Schnittstelle, mit der Sie die Anzahl der Replikate dynamisch einstellen und jeden ihrer aktuellen Zustände untersuchen können. Weitere Details zu der Scale Sub-Ressource findest du [hier](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
+Der Autoscaler greift über die Scale Sub-Ressource auf die entsprechenden skalierbaren Controller (z.B. Replication Controller, Deployments und Replika Sets) zu. Scale ist eine Schnittstelle, mit der Sie die Anzahl der Replikate dynamisch einstellen und jeden ihrer aktuellen Zustände untersuchen können. Weitere Details zu der Scale Sub-Ressource findest du [hier](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
 
 ### Details zum Algorithmus
 
@@ -90,7 +90,7 @@ Die aktuelle stabile Version, die nur die Unterstützung für die automatische S
 
 Die Beta-Version, welche die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.
 
-Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden.
+Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden.
 
 ## Unterstützung des Horizontal Pod Autoscaler in kubectl
 
@@ -166,7 +166,7 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R
 ## {{% heading "whatsnext" %}}
 
 
-* Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
+* Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md).
 * kubectl autoscale Befehl: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
 * Verwenden des [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
 

content/de/docs/tutorials/kubernetes-basics/_index.html

@@ -46,7 +46,7 @@ card:
     </div>
 
     <div id="basics-modules" class="content__modules">
-      <h2>Kubernets Grundlagen Module</h2>
+      <h2>Kubernetes Grundlagen Module</h2>
       <div class="row">
         <div class="col-md-12">
           <div class="row">

content/de/includes/default-storage-class-prereqs.md

@@ -1 +1 @@
-Sie benötigen entweder einen dynamischen PersistentVolume-Anbieter mit einer [Standard-Speicherklasse](/docs/concepts/storage/storage-classes/), oder Sie selbst stellen statische [PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning) bereit, um die [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) zu erfüllen, die hier verwendet werden.
+Sie benötigen entweder einen dynamischen PersistentVolume-Anbieter mit einer [Standard-Speicherklasse](/docs/concepts/storage/storage-classes/), oder Sie selbst stellen statische [PersistentVolumes](/docs/concepts/storage/persistent-volumes/#provisioning) bereit, um die [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) zu erfüllen, die hier verwendet werden.

content/en/_index.html

@@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Attend KubeCon Europe on May 17-20, 2022</a>
-        <br>
-        <br>
-        <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a>
+        <br>
+        <br>
+        <br>
+        <br>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu23" button id="desktopKCButton">Attend KubeCon Europe on April 17-21, 2023</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md

@@ -1,9 +1,13 @@
 ---
-title: Welcome to the Kubernetes Blog! 
+title: Welcome to the Kubernetes Blog!
 date: 2015-03-20
 slug: welcome-to-kubernetes-blog
 url: /blog/2015/03/Welcome-To-Kubernetes-Blog
+evergreen: true
 ---
+
+**Author:** Kit Merker (Google)
+
 Welcome to the new Kubernetes Blog. Follow this blog to learn about the Kubernetes Open Source project. We plan to post release notes, how-to articles, events, and maybe even some off topic fun here from time to time.
 
 
@@ -25,6 +29,3 @@ To start things off, here's a roundup of recent Kubernetes posts from other site
 
 
 Happy cloud computing!
-
-
- - Kit Merker - Product Manager, Google Cloud Platform

content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md

@@ -1,8 +1,9 @@
 ---
-title: " Kubernetes Release: 0.16.0 "
+title: "Kubernetes Release: 0.16.0"
 date: 2015-05-11
 slug: kubernetes-release-0160
 url: /blog/2015/05/Kubernetes-Release-0160
+evergreen: true
 ---
 Release Notes:
 

content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md

@@ -1,8 +1,9 @@
 ---
-title: " Kubernetes Release: 0.17.0 "
+title: "Kubernetes Release: 0.17.0"
 date: 2015-05-15
 slug: kubernetes-release-0170
 url: /blog/2015/05/Kubernetes-Release-0170
+evergreen: true
 ---
 Release Notes:  
 

content/en/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md

@@ -1,9 +1,10 @@
 ---
-title: " Announcing the First Kubernetes Enterprise Training Course "
+title: "Announcing the First Kubernetes Enterprise Training Course"
 date: 2015-07-08
 slug: announcing-first-kubernetes-enterprise
 url: /blog/2015/07/Announcing-First-Kubernetes-Enterprise
 ---
+
 At Google we rely on Linux application containers to run our core infrastructure. Everything from Search to Gmail runs in containers.  In fact, we like containers so much that even our Google Compute Engine VMs run in containers!  Because containers are critical to our business, we have been working with the community on many of the basic container technologies (from cgroups to Docker’s LibContainer) and even decided to build the next generation of Google’s container scheduling technology, Kubernetes, in the open.
 
 

content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md

@@ -1,9 +1,13 @@
 ---
-title: " Kubernetes 1.1 Performance upgrades, improved tooling and a growing community  "
+title: "Kubernetes 1.1 Performance upgrades, improved tooling and a growing community"
 date: 2015-11-09
 slug: kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
 url: /blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community
+evergreen: true
 ---
+
+**Author:** David Aronchick (Google)
+
 Since the Kubernetes 1.0 release in July, we’ve seen tremendous adoption by companies building distributed systems to manage their container clusters. We’re also been humbled by the rapid growth of the community who help make Kubernetes better everyday. We have seen commercial offerings such as Tectonic by CoreOS and RedHat Atomic Host emerge to deliver deployment and support of Kubernetes. And a growing ecosystem has added Kubernetes support including tool vendors such as Sysdig and Project Calico.  
 
 With the help of hundreds of contributors, we’re proud to announce the availability of Kubernetes 1.1, which offers major performance upgrades, improved tooling, and new features that make applications even easier to build and deploy.  
@@ -50,4 +54,3 @@ As we mentioned above, we would love your help:
 
 But, most of all, just let us know how you are transforming your business using Kubernetes, and how we can help you do it even faster. Thank you for your support!  
 
- - David Aronchick, Senior Product Manager for Kubernetes and Google Container Engine

content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md

@@ -1,37 +1,41 @@
 ---
-title: " KubeCon EU 2016: Kubernetes Community in London "
+title: "KubeCon EU 2016: Kubernetes Community in London"
 date: 2016-02-24
 slug: kubecon-eu-2016-kubernetes-community-in
 url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In
+evergreen: true
 ---
 
-KubeCon EU 2016 is the inaugural [European Kubernetes](http://kubernetes.io/) community conference that follows on the American launch in November 2015. KubeCon is fully dedicated to education and community engagement for[Kubernetes](http://kubernetes.io/) enthusiasts, production users and the surrounding ecosystem.
+**Author:** Sarah Novotny (Google)
+
+KubeCon EU 2016 is the inaugural European Kubernetes community conference that follows on the American launch in November 2015. KubeCon is fully dedicated to education and community engagement for [Kubernetes](/) enthusiasts, production users and the surrounding ecosystem.
 
 Come join us in London and hang out with hundreds from the Kubernetes community and experience a wide variety of deep technical expert talks and use cases.
 
 Don’t miss these great speaker sessions at the conference:
 
-* “Kubernetes Hardware Hacks: Exploring the Kubernetes API Through Knobs, Faders, and Sliders” by Ian Lewis and Brian Dorsey, Developer Advocate, Google -* [http://sched.co/6Bl3](http://sched.co/6Bl3)  
+* “Kubernetes Hardware Hacks: Exploring the Kubernetes API Through Knobs, Faders, and Sliders” by Ian Lewis and Brian Dorsey, Developer Advocate, Google [https://sched.co/6Bl3](http://sched.co/6Bl3)
 
-* “rktnetes: what's new with container runtimes and Kubernetes” by Jonathan Boulle, Developer and Team Lead at CoreOS -* [http://sched.co/6BY7](http://sched.co/6BY7)
+* “rktnetes: what's new with container runtimes and Kubernetes” by Jonathan Boulle, Developer and Team Lead at CoreOS [https://sched.co/6BY7](http://sched.co/6BY7)
 
-* “Kubernetes Documentation: Contributing, fixing issues, collecting bounties” by John Mulhausen, Lead Technical Writer, Google -* [http://sched.co/6BUP](http://sched.co/6BUP) 
-* “[What is OpenStack's role in a Kubernetes world?](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” By Thierry Carrez, Director of Engineering, OpenStack Foundation -* http://sched.co/6BYC
-* “A Practical Guide to Container Scheduling” by Mandy Waite, Developer Advocate, Google -* [http://sched.co/6BZa](http://sched.co/6BZa)  
+* “Kubernetes Documentation: Contributing, fixing issues, collecting bounties” by John Mulhausen, Lead Technical Writer, Google [https://sched.co/6BUP](http://sched.co/6BUP) 
 
-* “[Kubernetes in Production in The New York Times newsroom](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis, Web Developer, New York Times -* [http://sched.co/67f2](http://sched.co/67f2)
-* “[Creating an Advanced Load Balancing Solution for Kubernetes with NGINX](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” by Andrew Hutchings, Technical Product Manager, NGINX -* http://sched.co/6Bc9
-* And many more http://kubeconeurope2016.sched.org/
+* “[What is OpenStack's role in a Kubernetes world?](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” By Thierry Carrez, Director of Engineering, OpenStack Foundation [https://sched.co/6BYC](http://sched.co/6BYC)
+
+* “A Practical Guide to Container Scheduling” by Mandy Waite, Developer Advocate, Google [https://sched.co/6BZa](http://sched.co/6BZa)
+
+* “[Kubernetes in Production in The New York Times newsroom](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis, Web Developer, New York Times [https://sched.co/67f2](http://sched.co/67f2)
+
+* “[Creating an Advanced Load Balancing Solution for Kubernetes with NGINX](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” by Andrew Hutchings, Technical Product Manager, NGINX [https://sched.co/6Bc9](https://sched.co/6Bc9)
+
+…and many more https://kubeconeurope2016.sched.org/
 
 
-Get your KubeCon EU [tickets here](https://ti.to/kubecon/kubecon-eu-2016).
+~Get your KubeCon EU [tickets here](https://ti.to/kubecon/kubecon-eu-2016)~.
 
 Venue Location: CodeNode * 10 South Pl, London, United Kingdom  
 Accommodations: [hotels](https://skillsmatter.com/contact-us#hotels)   
 Website: [kubecon.io](https://www.kubecon.io/)   
 Twitter: [@KubeConio](https://twitter.com/kubeconio) #KubeCon
+
 Google is a proud Diamond sponsor of KubeCon EU 2016. Come to London next month, March 10th & 11th, and visit booth #13 to learn all about Kubernetes, Google Container Engine (GKE) and Google Cloud Platform!  
-
-_KubeCon is organized by KubeAcademy, LLC, a community-driven group of developers focused on the education of developers and the promotion of Kubernetes._  
-
--* Sarah Novotny, Kubernetes Community Manager, Google  

content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md

@@ -1,17 +1,20 @@
 ---
-title: " Kubernetes 1.2: Even more performance upgrades, plus easier application deployment and management  "
+title: "Kubernetes 1.2: Even more performance upgrades, plus easier application deployment and management"
 date: 2016-03-17
 slug: kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management
 url: /blog/2016/03/Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management
+evergreen: true
 ---
-Today we released Kubernetes 1.2. This release represents significant improvements for large organizations building distributed systems. Now with over 680 unique contributors to the project, this release represents our largest yet.  
+**Author:** David Aronchick (Google)
+
+Today the Kubernetes project released Kubernetes 1.2. This release represents significant improvements for large organizations building distributed systems. Now with over 680 unique contributors to the project, this release represents our largest yet.  
 
 From the beginning, our mission has been to make building distributed systems easy and accessible for all. With the Kubernetes 1.2 release we’ve made strides towards our goal by increasing scale, decreasing latency and overall simplifying the way applications are deployed and managed. Now, developers at organizations of all sizes can build production scale apps more easily than ever before. 
 
-### What’s new: 
+## What’s new
 
 - **Significant scale improvements**. Increased cluster scale by 400% to 1,000 nodes and 30,000 containers per cluster.
-- **Simplified application deployment and management**. 
+- **Simplified application deployment and management**.
 
   - Dynamic Configuration (via the ConfigMap API) enables applications to pull their configuration when they run rather than packaging it in at build time. 
   - Turnkey Deployments (via the Beta Deployment API) let you declare your application and Kubernetes will do the rest. It handles versioning, multiple simultaneous rollouts, aggregating status across all pods, maintaining application availability and rollback. 
@@ -28,15 +31,15 @@ From the beginning, our mission has been to make building distributed systems ea
 
 - **And many more**. For a complete list of updates, see the [release notes on github](https://github.com/kubernetes/kubernetes/releases/tag/v1.2.0). 
 
-#### Community 
+## Community
 
-All these improvements would not be possible without our enthusiastic and global community. The momentum is astounding. We’re seeing over 400 pull requests per week, a 50% increase since the previous 1.1 release. There are meetups and conferences discussing Kubernetes nearly every day, on top of the 85 Kubernetes related [meetup groups](http://www.meetup.com/topics/kubernetes/) around the world. We’ve also seen significant participation in the community in the form of Special Interest Groups, with 18 active SIGs that cover topics from AWS and OpenStack to big data and scalability, to get involved [join or start a new SIG](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)). Lastly, we’re proud that Kubernetes is the first project to be accepted to the Cloud Native Computing Foundation (CNCF), read more about the announcement [here](https://cncf.io/news/announcement/2016/03/cloud-native-computing-foundation-accepts-kubernetes-first-hosted-projec-0). 
+All these improvements would not be possible without our enthusiastic and global community. The momentum is astounding. We’re seeing over 400 pull requests per week, a 50% increase since the previous 1.1 release. There are meetups and conferences discussing Kubernetes nearly every day, on top of the 85 Kubernetes related [meetup groups](http://www.meetup.com/topics/kubernetes/) around the world. We’ve also seen significant participation in the community in the form of Special Interest Groups, with 18 active SIGs that cover topics from AWS and OpenStack to big data and scalability, to get involved [join or start a new SIG](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)). Lastly, we’re proud that Kubernetes is the first project to be accepted to the Cloud Native Computing Foundation (CNCF), read more about the announcement [here](https://cncf.io/news/announcement/2016/03/cloud-native-computing-foundation-accepts-kubernetes-first-hosted-projec-0).
 
 
 
-#### Documentation 
+## Documentation
 
-With Kubernetes 1.2 comes a relaunch of our website at [kubernetes.io](http://kubernetes.io/). We’ve slimmed down the docs contribution process so that all you have to do is fork/clone and send a PR. And the site works the same whether you’re staging it on your laptop, on github.io, or viewing it in production. It’s a pure GitHub Pages project; no scripts, no plugins. 
+With Kubernetes 1.2 comes a relaunch of our website at [kubernetes.io](http://kubernetes.io/). We’ve slimmed down the docs contribution process so that all you have to do is fork/clone and send a PR. And the site works the same whether you’re staging it on your laptop, on github.io, or viewing it in production. It’s a pure GitHub Pages project; no scripts, no plugins.
 
 
 
@@ -48,7 +51,7 @@ To entice you even further to contribute, we’re also announcing our new bounty
 
 
 
-#### Roadmap 
+## Roadmap
 
 All of our work is done in the open, to learn the latest about the project j[oin the weekly community meeting](https://groups.google.com/forum/#!forum/kubernetes-community-video-chat) or [watch a recorded hangout](https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ). In keeping with our major release schedule of every three to four months, here are just a few items that are in development for [next release and beyond](https://github.com/kubernetes/kubernetes/wiki/Release-1.3): 
 
@@ -64,7 +67,7 @@ Kubernetes 1.2 is available for download at [get.k8s.io](http://get.k8s.io/) and
 
 
 
-#### Connect 
+## Connect
 
 We’d love to hear from you and see you participate in this growing community: 
 
@@ -73,8 +76,7 @@ We’d love to hear from you and see you participate in this growing community:&
 -  Connect with the community on [Slack](http://slack.kubernetes.io/) 
 - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates 
 
-Thank you for your support! 
+Thank you for your support!
 
 
 
- - _David Aronchick, Senior Product Manager for Kubernetes, Google_

content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md

@@ -131,7 +131,7 @@ In this example, the ‘ **tenant-a** ’ namespace would get policy ‘ **pol1*
 
 
 
-Today, [Romana](http://romana.io/), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) and [Calico](http://projectcalico.org/) support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)). 
+Today, Romana, OpenShift, OpenContrail and Calico support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)). 
 
 
 

content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md

@@ -1,9 +1,13 @@
 ---
-title: " Kubernetes 1.3: Bridging Cloud Native and Enterprise Workloads "
+title: "Kubernetes 1.3: Bridging Cloud Native and Enterprise Workloads"
 date: 2016-07-06
 slug: kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads
 url: /blog/2016/07/Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads
+evergreen: true
 ---
+
+**Author:** Aparna Sinha, Google
+
 Nearly two years ago, when we officially kicked off the Kubernetes project, we wanted to simplify distributed systems management and provide the core technology required to everyone. The community’s response to this effort has blown us away. Today, thousands of customers, partners and developers are running clusters in production using Kubernetes and have joined the cloud native revolution.   
 
 Thanks to the help of over 800 contributors, we are pleased to announce today the availability of Kubernetes 1.3, our most robust and feature-rich release to date.  
@@ -14,7 +18,7 @@ Product highlights in Kubernetes 1.3 include the ability to bridge services acro
 
 
 
-**What’s new:**
+## What’s new
 
 - **Increased scale and automation** - Customers want to scale their services up and down automatically in response to application demand. In 1.3 we have made it easier to autoscale clusters up and down while doubling the maximum number of nodes per cluster. Customers no longer need to think about cluster size, and can allow the underlying cluster to respond to demand.
 
@@ -31,13 +35,13 @@ Product highlights in Kubernetes 1.3 include the ability to bridge services acro
 - **Updated Kubernetes dashboard UI** - Customers can now use the Kubernetes open source dashboard for the majority of interactions with their clusters, rather than having to use the CLI. The updated UI lets users control, edit and create all workload resources (including Deployments and PetSets).
 - And many more. For a complete list of updates, see the [_release notes on GitHub_](https://github.com/kubernetes/kubernetes/releases/tag/v1.3.0).
 
-**Community**
+## Community
 
 We could not have achieved this milestone without the tireless effort of countless people that are part of the Kubernetes community. We have [19 different Special Interest Groups](https://github.com/kubernetes/community/blob/master/README.md#special-interest-groups-sig), and over 100 meetups around the world. Kubernetes is a community project, built in the open, and it truly would not be possible without the over 233 person-years of effort the community has put in to date. Woot!
 
 
 
-**Availability**
+## Availability
 
 Kubernetes 1.3 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](http://github.com/kubernetes/kubernetes). To get started with Kubernetes try our [Hello World app](/docs/hellonode/).
 
@@ -47,7 +51,7 @@ To learn the latest about the project, we encourage everyone to [join the weekly
 
 
 
-**Connect**
+## Connect
 
 We’d love to hear from you and see you participate in this growing community:
 
@@ -58,8 +62,4 @@ We’d love to hear from you and see you participate in this growing community:
 
 
 
-Thank you for your support! 
-
-
-
--- Aparna Sinha, Product Manager, Google
+Thank you for your support!

content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md

@@ -65,7 +65,7 @@ Network policies are an exciting feature, which the Kubernetes community has wor
 
 
 
-There are only a few policy-capable networking backends available for Kubernetes today: [Romana](http://romana.io/), [Calico](http://projectcalico.org/), and [Canal](https://github.com/tigera/canal); with [Weave](http://www.weave.works/) indicating support in the near future. Red Hat’s OpenShift includes network policy features as well.
+There are only a few policy-capable networking backends available for Kubernetes today: Romana, [Calico](http://projectcalico.org/), and [Canal](https://github.com/tigera/canal); with [Weave](http://www.weave.works/) indicating support in the near future. Red Hat’s OpenShift includes network policy features as well.
 
 
 
@@ -100,7 +100,7 @@ This is because during a typical network performance benchmark, there’s no app
 - Hardware: Two servers with Intel Core i5-5250U CPUs (2 core, 2 threads per core) running at 1.60GHz, 16GB RAM and 512GB SSD. NIC: Intel Ethernet Connection I218-V (rev 03)
 - Ubuntu 14.04.5
 - Kubernetes 1.3 for data collection (verified samples on [v1.4.0-beta.5](http://v1.4.0-beta.5/))
-- [Romana v0.9.3.1](https://github.com/romana/romana)
+- Romana v0.9.3.1
 - Client and server load test [software](https://github.com/paninetworks/testing-tools)
 
 For the tests we had a client pod send 2,000 HTTP requests to a server pod. HTTP requests were sent by the client pod at a rate that ensured that neither the server nor network ever saturated. We also made sure each request started a new TCP session by disabling persistent connections (i.e. HTTP [keep-alive](https://en.wikipedia.org/wiki/HTTP_persistent_connection)). We ran each test with different response sizes and measured the average request duration time (how long does it take to complete a request of that size). Finally, we repeated each set of measurements with different policy configurations.
@@ -189,4 +189,4 @@ These tests were performed using Romana as the backend policy provider and other
 
 
 
-If you wish to try it for yourself, we invite you to check out [Romana](http://romana.io/). In our [GitHub repo](https://github.com/romana/romana) you can find an easy to use installer, which works with AWS, Vagrant VMs or any other servers. You can use it to quickly get you started with a Romana powered Kubernetes or OpenStack cluster.
+If you wish to try it for yourself, we invite you to check out Romana. In our GitHub repo you can find an easy to use installer, which works with AWS, Vagrant VMs or any other servers. You can use it to quickly get you started with a Romana powered Kubernetes or OpenStack cluster.

content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md

@@ -9,7 +9,7 @@ url: /blog/2017/08/High-Performance-Networking-With-Ec2
 One of the most popular platforms for running Kubernetes is Amazon Web Services’ Elastic Compute Cloud (AWS EC2). With more than a decade of experience delivering IaaS, and expanding over time to include a rich set of services with easy to consume APIs, EC2 has captured developer mindshare and loyalty worldwide.
 
 
-When it comes to networking, however, EC2 has some limits that hinder performance and make deploying Kubernetes clusters to production unnecessarily complex. The preview release of [Romana v2.0](http://romana.io/), a network and security automation solution for Cloud Native applications, includes features that address some well known network issues when running Kubernetes in EC2.
+When it comes to networking, however, EC2 has some limits that hinder performance and make deploying Kubernetes clusters to production unnecessarily complex. The preview release of Romana v2.0, a network and security automation solution for Cloud Native applications, includes features that address some well known network issues when running Kubernetes in EC2.
 
 
 ## Traditional VPC Networking Performance Roadblocks
@@ -40,7 +40,7 @@ Whether you were interested in advanced networking for traffic isolation or runn
 The way to avoid running out of VPC routes is to use them sparingly by making them forward pod traffic for multiple instances. From a networking perspective, what that means is that the VPC route needs to forward to a router, which can then forward traffic on to the final destination instance.
 
 
-[Romana](http://romana.io/) is a CNI network provider that configures routes on the host to forward pod network traffic without an overlay. Since inter-node routes are installed on hosts, no VPC routes are necessary at all. However, when the VPC is split into subnets for an HA deployment across zones, VPC routes are necessary.
+Romana is a CNI network provider that configures routes on the host to forward pod network traffic without an overlay. Since inter-node routes are installed on hosts, no VPC routes are necessary at all. However, when the VPC is split into subnets for an HA deployment across zones, VPC routes are necessary.
 
 
 Fortunately, inter-node routes on hosts allows them to act as a network router and forward traffic inbound from another zone just as it would for traffic from local pods. This makes any Kubernetes node configured by Romana able to accept inbound pod traffic from other zones and forward it to the proper destination node on the subnet.
@@ -73,8 +73,5 @@ When using Romana v2.0, native VPC networking is now available for clusters of a
 ![](https://archive.org/download/hpc-ec2-vpc-2/hpc-ec2-vpc-2.png)
 
 
-The preview release of Romana v2.0 is available [here](http://romana.io/preview). We welcome comments and feedback so we can make EC2 deployments of Kubernetes as fast and reliable as possible.    
-
-
 
 -- _Juergen Brendel and Chris Marino, co-founders of Pani Networks, sponsor of the Romana project_

content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md

@@ -3,8 +3,10 @@ title: " Kubernetes 1.8: Security, Workloads and Feature Depth "
 date: 2017-09-29
 slug: kubernetes-18-security-workloads-and
 url: /blog/2017/09/Kubernetes-18-Security-Workloads-And
+evergreen: true
 ---
-_Editor's note: today's post is by Aparna Sinha, Group Product Manager, Kubernetes, Google; Ihor Dvoretskyi, Developer Advocate, CNCF; Jaice Singer DuMars, Kubernetes Ambassador, Microsoft; and Caleb Miles, Technical Program Manager, CoreOS on the latest release of Kubernetes 1.8._  
+
+**Authors:** Kubernetes v1.8 release team
 
 
 We’re pleased to announce the delivery of Kubernetes 1.8, our third release this year. Kubernetes 1.8 represents a snapshot of many exciting enhancements and refinements underway. In addition to functional improvements, we’re increasing project-wide focus on maturing [process](https://github.com/kubernetes/sig-release), formalizing [architecture](https://github.com/kubernetes/community/tree/master/sig-architecture), and strengthening Kubernetes’ [governance model](https://github.com/kubernetes/community/tree/master/community/elections/2017). The evolution of mature processes clearly signals that sustainability is a driving concern, and helps to ensure that Kubernetes is a viable and thriving project far into the future.  
@@ -50,7 +52,7 @@ The [Release team](https://github.com/kubernetes/features/blob/master/release-1.
 As the Kubernetes community has grown, our release process has become an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid clip. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem.  
 
 
-## User Highlights
+## User highlights
 
 According to [Redmonk](http://redmonk.com/fryan/2017/09/10/cloud-native-technologies-in-the-fortune-100/), 54 percent of Fortune 100 companies are running Kubernetes in some form with adoption coming from every sector across the world. Recent user stories from the community include:   
 
@@ -91,3 +93,6 @@ The simplest way to get involved with Kubernetes is by joining one of the many [
 - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
 - Chat with the community on [Slack](http://slack.k8s.io/).
 - [Share your Kubernetes story.](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
+
+
+_Editor's note: this announcement was authored by Aparna Sinha (Google), Ihor Dvoretskyi (CNCF), Jaice Singer DuMars (Microsoft), and Caleb Miles (CoreOS)._

content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md

@@ -1,9 +1,13 @@
 ---
-title: " Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem "
+title: "Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem"
 date: 2017-12-15
 slug: kubernetes-19-workloads-expanded-ecosystem
 url: /blog/2017/12/Kubernetes-19-Workloads-Expanded-Ecosystem
+evergreen: true
 ---
+
+**Authors:** Kubernetes v1.9 release team
+
 We’re pleased to announce the delivery of Kubernetes 1.9, our fourth and final release this year.  
 
 Today’s release continues the evolution of an increasingly rich feature set, more robust stability, and even greater community contributions. As the fourth release of the year, it gives us an opportunity to look back at the progress made in key areas. Particularly notable is the advancement of the Apps Workloads API to stable. This removes any reservations potential adopters might have had about the functional stability required to run mission-critical workloads. Another big milestone is the beta release of Windows support, which opens the door for many Windows-specific applications and workloads to run in Kubernetes, significantly expanding the implementation scenarios and enterprise readiness of Kubernetes.  
@@ -87,7 +91,7 @@ For recorded sessions from the largest Kubernetes gathering, [KubeCon + CloudNat
 
 ## Webinar
 
-Join members of the Kubernetes 1.9 release team on **January 9th from 10am-11am PT** to learn about the major features in this release as they demo some of the highlights in the areas of Windows and Docker support, storage, admission control, and the workloads API. [Register here](https://zoom.us/webinar/register/WN_oVjQMwyzQFOmWsfVzDsa2A).  
+Join members of the Kubernetes 1.9 release team on **January 9th from 10am-11am PT** to learn about the major features in this release as they demo some of the highlights in the areas of Windows and Docker support, storage, admission control, and the workloads API. [~Register here~](https://zoom.us/webinar/register/WN_oVjQMwyzQFOmWsfVzDsa2A).  
 
 
 ## Get involved:

content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md

@@ -1,13 +1,9 @@
 ---
-title: 'Kubernetes 1.10: Stabilizing Storage, Security, and Networking '
-author: kbarnard
-tags:
+title: 'Kubernetes 1.10: Stabilizing Storage, Security, and Networking'
 date: 2018-03-26
 modified_time: '2018-03-27T11:01:39.569-07:00'
-blogger_id: tag:blogger.com,1999:blog-112706738355446097.post-6519705795358457586
-blogger_orig_url: https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/
 slug: kubernetes-1.10-stabilizing-storage-security-networking
-date: 2018-03-26
+evergreen: true
 ---
 
 ***Editor's note: today's post is by the [1.10 Release

content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md

@@ -3,6 +3,7 @@ layout: blog
 title: 'Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability'
 date:  2018-06-27
 slug: kubernetes-1.11-release-announcement
+evergreen: true
 ---
 
 **Author**: Kubernetes 1.11 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.11/release_team.md)

content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md

@@ -2,6 +2,7 @@
 layout: blog
 title:  'Kubernetes 1.12: Kubelet TLS Bootstrap and Azure Virtual Machine Scale Sets (VMSS) Move to General Availability'
 date:   2018-09-27
+evergreen: true
 ---
 
 **Author**: The 1.12 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.12/release_team.md)

content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md

@@ -1,13 +1,12 @@
 ---
-layout: "Blog"
+layout: blog
 title: "Kubernetes 2018 North American Contributor Summit"
-date: 2018-10-16    
+date: 2018-10-16
+evergreen: true
 ---
 
 **Authors:**
-[Bob Killen][bob] (University of Michigan)
-[Sahdev Zala][sahdev] (IBM),
-[Ihor Dvoretskyi][ihor] (CNCF) 
+[Bob Killen][bob] (University of Michigan), [Sahdev Zala][sahdev] (IBM), [Ihor Dvoretskyi][ihor] (CNCF)
 
 
 The 2018 North American Kubernetes Contributor Summit to be hosted right before
@@ -22,32 +21,34 @@ Unlike previous Contributor Summits, the event now spans two-days with a more
 relaxed ‘hallway’ track and general Contributor get-together to be hosted from
 5-8pm on Sunday December 9th at the [Garage Lounge and Gaming Hall][garage], just
 a short walk away from the Convention Center. There, contributors can enjoy
-billiards, bowling, trivia and more; accompanied by a variety of food and drink. 
+billiards, bowling, trivia and more; accompanied by a variety of food and drink.
 
 Things pick up the following day, Monday the 10th with three separate tracks: 
 
-### New Contributor Workshop:
+### New contributor workshop
 A half day workshop aimed at getting new and first time contributors onboarded
 and comfortable with working within the Kubernetes Community. Staying for the
 duration is required; this is not a workshop you can drop into. 
 
-### Current Contributor Track:
+### Current contributor track
 Reserved for those that are actively engaged with the development of the
 project; the Current Contributor Track includes Talks, Workshops, Birds of a
 Feather, Unconferences, Steering Committee Sessions, and more! Keep an eye on
 the [schedule in GitHub][schedule] as content is frequently being updated.
 
-### Docs Sprint:
-SIG-Docs will have a curated list of issues and challenges to be tackled closer
+### Docs sprint
+
+SIG Docs will have a curated list of issues and challenges to be tackled closer
 to the event date.
 
-## To Register:
+## How To Register {#to-register}
+
 To register for the Contributor Summit, see the [Registration section of the
 Event Details in GitHub][register]. Please note that registrations are being
 reviewed. If you select the “Current Contributor Track” and are not an active
 contributor, you will be asked to attend the New Contributor Workshop, or asked
 to be put on a waitlist. With thousands of contributors and only 300 spots, we
-need to make sure the right folks are in the room. 
+need to make sure the right folks are in the room.
 
 If you have any questions or concerns, please don’t hesitate to reach out to
 the Contributor Summit Events Team at community@kubernetes.io.

content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md

@@ -41,7 +41,7 @@ These repo labels let reviewers filter for PRs and issues by language. For examp
 
 ### Team review 
 
-L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are [assigned in an OWNERS file](https://github.com/kubernetes/website/blob/master/content/en/OWNERS) in the top subfolder for English content. 
+L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are [assigned in an OWNERS file](https://github.com/kubernetes/website/blob/main/content/en/OWNERS) in the top subfolder for English content.
 
 Adding `OWNERS` files to subdirectories lets localization teams review and approve changes without requiring a rubber stamp approval from reviewers who may lack fluency.
 

content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md

@@ -3,6 +3,7 @@ layout: blog
 title: 'Kubernetes 1.13: Simplified Cluster Management with Kubeadm, Container Storage Interface (CSI), and CoreDNS as Default DNS are Now Generally Available'
 date: 2018-12-03
 slug: kubernetes-1-13-release-announcement
+evergreen: true
 ---
 
 **Author**: The 1.13 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.13/release_team.md)

content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md

@@ -2,6 +2,7 @@
 layout: blog
 title: Production-Ready Kubernetes Cluster Creation with kubeadm
 date: 2018-12-04
+evergreen: true
 ---
 
 **Authors**: Lucas Käldström (CNCF Ambassador) and Luc Perkins (CNCF Developer Advocate)

content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md

@@ -1,13 +1,13 @@
 ---
 title: A Look Back and What's in Store for Kubernetes Contributor Summits
 date: 2019-03-20
+layout: blog
+evergreen: true
 ---
 
 **Authors:**
 Paris Pittman (Google), Jonas Rosland (VMware)
 
-**tl;dr** - [click here] for Barcelona Contributor Summit information.
-
 {{<figure width="600" src="/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/celebrationsig.jpg" caption="Seattle Contributor Summit">}}
 
 As our contributing community grows in great numbers, with more than 16,000 contributors this year across 150+ GitHub repositories, it’s important to provide face to face connections for our large distributed teams to have opportunities for collaboration and learning. In [Contributor Experience], our methodology with planning events is a lot like our documentation; we build from personas -- interests, skills, and motivators to name a few. This way we ensure there is valuable content and learning for everyone.
@@ -28,13 +28,14 @@ We build the contributor summits around you:
 
 These personas combined with ample feedback from previous events, produce the   altogether experience that welcomed over 600 contributors in Copenhagen (May), Shanghai(November), and Seattle(December) in 2018. Seattle's event drew over 300+ contributors, equal to Shanghai and Copenhagen combined, for the 6th contributor event in Kubernetes history. In true Kubernetes fashion, we expect another record breaking year of attendance. We've pre-ordered 900+ [contributor patches], a tradition, and we are   looking forward to giving them to you!
 
-With that said...  
+With that said…
+
 **Save the Dates:**  
 Barcelona: May 19th (evening) and 20th (all day)  
 Shanghai: June 24th (all day)  
 San Diego: November 18th, 19th, and activities in KubeCon/CloudNativeCon week
 
-In an effort of continual improvement, here's what to expect from us this year:  
+In an effort of continual improvement, here's what to expect from us this year:
 
 * Large new contributor workshops and contributor socials at all three events expected to break previous attendance records
 * A multiple track event in San Diego for all contributor types including workshops, birds of a feather, lightning talks and more
@@ -42,7 +43,8 @@ In an effort of continual improvement, here's what to expect from us this year:
 * [An event website]!
 * Follow along with updates: kubernetes-dev@googlegroups.com is our main communication hub as always; however, we will also blog here, our [Thursday Kubernetes Community Meeting], [twitter], SIG meetings, event site, discuss.kubernetes.io, and #contributor-summit on Slack.
 * Opportunities to get involved: We still have 2019 roles available!
-Reach out to Contributor Experience via community@kubernetes.io, stop by a Wednesday SIG update meeting, or catch us on Slack (#sig-contribex).  
+Reach out to Contributor Experience via community@kubernetes.io, stop by a Wednesday SIG update meeting, or catch us on Slack (#sig-contribex).
+
 
 {{<figure width="600" src="/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/unconference.jpg" caption="Unconference voting">}}
 
@@ -51,11 +53,11 @@ Reach out to Contributor Experience via community@kubernetes.io, stop by a Wedne
 Our 2018 crew 🥁  
 Jorge Castro, Paris Pittman, Bob Killen, Jeff Sica, Megan Lehn, Guinevere Saenger, Josh Berkus, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Lindsey Tulloch, Zach Corleissen, Tim Pepper, Ihor Dvoretskyi, Nancy Mohamed, Chris Short, Mario Loria, Jason DeTiberus, Sahdev Zala, Mithra Raja
 
-And an introduction to our 2019 crew (a thanks in advance ;) )...  
-Jonas Rosland, Josh Berkus, Paris Pittman, Jorge Castro, Bob Killen, Deb Giles, Guinevere Saenger, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Rui Chen, Tim Pepper, Ihor Dvoretskyi, Dawn Foster  
+And an introduction to our 2019 crew (a thanks in advance ;) )…  
+Jonas Rosland, Josh Berkus, Paris Pittman, Jorge Castro, Bob Killen, Deb Giles, Guinevere Saenger, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Rui Chen, Tim Pepper, Ihor Dvoretskyi, Dawn Foster
 
 
-## Relive Seattle Contributor Summit 
+## Relive Seattle Contributor Summit
 
 📈 80% growth rate since the Austin 2017 December event
 
@@ -81,15 +83,11 @@ Jonas Rosland, Josh Berkus, Paris Pittman, Jorge Castro, Bob Killen, Deb Giles,
 
 📸 Pictures (special thanks to [rdodev])
 
-Garage Pic
-Reg Desk
-
 {{<figure width="600" src="/images/blog/2019-03-14-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits/grouppicseatle.JPG" caption="Some of the group in Seattle">}}
 
 “I love Contrib Summit! The intros and deep dives during KubeCon were a great extension of Contrib Summit. Y'all did an excellent job in the morning to level set expectations and prime everyone.” -- julianv    
 “great work! really useful and fun!” - coffeepac
 
-[click here]: https://events.linuxfoundation.org/events/contributor-summit-europe-2019/
 [Contributor Experience]: https://github.com/kubernetes/community/tree/master/sig-contributor-experience
 [Subproject OWNERs]: https://github.com/kubernetes/community/blob/master/community-membership.md
 [Chair or Tech Lead]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md

content/en/blog/_posts/2019-03-25-1-14-release-announcement.md

@@ -2,6 +2,7 @@
 title: 'Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA'
 date: 2019-03-25
 slug: kubernetes-1-14-release-announcement
+evergreen: true
 ---
 
 **Authors:** The 1.14 [Release Team](https://bit.ly/k8s114-team)

content/en/blog/_posts/2019-04-26-latest-on-localization.md

@@ -8,7 +8,7 @@ date: 2019-04-26
 
 Last year we optimized the Kubernetes website for [hosting multilingual content](/blog/2018/11/08/kubernetes-docs-updates-international-edition/). Contributors responded by adding multiple new localizations: as of April 2019, Kubernetes docs are partially available in nine different languages, with six added in 2019 alone. You can see a list of available languages in the language selector at the top of each page.
 
-By _partially available_, I mean that localizations are ongoing projects. They range from mostly complete ([Chinese docs for 1.12](https://v1-12.docs.kubernetes.io/zh/)) to brand new (1.14 docs in [Portuguese](https://kubernetes.io/pt/)). If you're interested in helping an existing localization, read on!
+By _partially available_, I mean that localizations are ongoing projects. They range from mostly complete ([Chinese docs for 1.12](https://v1-12.docs.kubernetes.io/zh-cn/)) to brand new (1.14 docs in [Portuguese](https://kubernetes.io/pt/)). If you're interested in helping an existing localization, read on!
 
 ## What is a localization?
 

content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md

@@ -2,6 +2,7 @@
 title: "Join us for the 2019 KubeCon Diversity Lunch & Hack"
 date: 2019-05-02
 slug: kubecon-diversity-lunch-and-hack
+evergreen: false
 ---
 
 **Authors:** Kiran Oliver, Podcast Producer, The New Stack
@@ -36,4 +37,4 @@ To make this all possible, we need you. Yes, you, to register. As much as we lov
 
 We look forward to seeing you!
 
-_Special thanks to [Leah Petersen](https://www.linkedin.com/in/leahstunts/), [Sarah Conway](https://www.linkedin.com/in/sarah-conway-6166151/) and [Paris Pittman](https://www.linkedin.com/in/parispittman/) for their help in editing this post._ 
+_Special thanks to [Leah Petersen](https://www.linkedin.com/in/leahstunts/), [Sarah Conway](https://www.linkedin.com/in/sarah-conway-6166151/) and [Paris Pittman](https://www.linkedin.com/in/parispittman/) for their help in editing this post._

content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md

@@ -3,6 +3,7 @@ layout: blog
 title: "Kubernetes 1.15: Extensibility and Continuous Improvement"
 date: 2019-06-19
 slug: kubernetes-1-15-release-announcement
+evergreen: true
 ---
 **Authors:** The 1.15 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.15/release_team.md)
 

content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md

@@ -3,19 +3,18 @@ layout: blog
 title: "Contributor Summit San Diego Registration Open!"
 date: 2019-09-24
 slug: san-diego-contributor-summit
+evergreen: true
 ---
 
-**Authors: Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware)**
-
-
+**Authors:** Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware)
 
 [Contributor Summit San Diego 2019 Event Page]  
-Registration is now open and in record time, we’ve hit capacity for the
-*new contributor workshop* session of the event! Waitlist is now available.
+In record time, we’ve hit capacity for the *new contributor workshop* session of
+the event!
 
 **Sunday, November 17**  
 Evening Contributor Celebration:  
-[QuartYard]*  
+[QuartYard]†  
 Address: 1301 Market Street, San Diego, CA 92101  
 Time: 6:00PM - 9:00PM  
 
@@ -68,7 +67,7 @@ Check out past blogs on [persona building around our events] and the [Barcelona
 
 ![Group Picture in 2018](/images/blog/2019-09-24-san-diego-contributor-summit/IMG_2588.JPG)
 
-*=QuartYard has a huge stage! Want to perform something in front of your contributor peers? Reach out to us! community@kubernetes.io
+†=QuartYard has a huge stage! Want to perform something in front of your contributor peers? Reach out to us! community@kubernetes.io
 
 
 

content/en/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md

@@ -5,13 +5,7 @@ date: 2019-10-10
 slug: contributor-summit-san-diego-schedule
 ---
 
-
-Authors: Josh Berkus (Red Hat), Paris Pittman (Google), Jonas Rosland (VMware)
-
-tl;dr A week ago we announced that [registration is open][reg] for the contributor
-summit , and we're now live with [the full Contributor Summit schedule!][schedule]
-Grab your spot while tickets are still available. There is currently a waitlist
-for new contributor workshop.  ([Register here!][reg])
+**Authors:** Josh Berkus (Red Hat), Paris Pittman (Google), Jonas Rosland (VMware)
 
 There are many great sessions planned for the Contributor Summit, spread across
 five rooms of current contributor content in addition to the new contributor
@@ -32,7 +26,7 @@ While the schedule contains difficult decisions in every timeslot, we've picked
 a few below to give you a taste of what you'll hear, see, and participate in, at
 the summit:
 
-* **[Vision]**: SIG-Architecture will be sharing their vision of where we're going
+* **[Vision]**: SIG Architecture will be sharing their vision of where we're going
   with Kubernetes development for the next year and beyond.
 * **[Security]**: Tim Allclair and CJ Cullen will present on the current state of
   Kubernetes security. In another security talk, Vallery Lancey will lead a
@@ -47,7 +41,7 @@ the summit:
   one, or at least pass one.
 * **[End Users]**: Several end users from the CNCF partner ecosystem, invited by
   Cheryl Hung, will hold a Q&A with contributors to strengthen our feedback loop.
-* **[Docs]**: As always, SIG-Docs will run a three-hour contributing-to-documentation
+* **[Docs]**: As always, SIG Docs will run a three-hour contributing-to-documentation
   workshop.
 
 We're also giving out awards to contributors who distinguished themselves in 2019,

content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md

@@ -5,11 +5,28 @@ date: 2020-02-18
 slug: Contributor-Summit-Amsterdam-Schedule-Announced
 ---
 
-**Authors:** Jeffrey Sica (Red Hat), Amanda Katona (VMware) 
+**Authors:** Jeffrey Sica (Red Hat), Amanda Katona (VMware)
 
-tl;dr [Registration is open](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/) and the [schedule is live](https://kcseu2020.sched.com/) so register now and we’ll see you in Amsterdam!
+![Contributor Summit](/images/blog/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced/contribsummit.jpg)
 
-## Kubernetes Contributor Summit 
+Hello everyone and Happy 2020! It’s hard to believe that KubeCon EU 2020 is less than six weeks away, and with that another contributor summit! This year we have the pleasure of being in Amsterdam in early spring, so be sure to pack some warmer clothing. This summit looks to be exciting with a lot of fantastic community-driven content. We received **26** submissions from the CFP. From that, the events team selected **12** sessions. Each of the sessions falls into one of four categories:
+
+*   Community
+*   Contributor Improvement
+*   Sustainability
+*   In-depth Technical
+
+On top of the presentations, there will be a dedicated Docs Sprint as well as the New Contributor Workshop 101 and 201 Sessions. All told, we will have five separate rooms of content throughout the day on Monday. Please **[see the full schedule](https://kcseu2020.sched.com/)** to see what sessions you’d be interested in. We hope between the content provided and the inevitable hallway track, everyone has a fun and enriching experience. 
+
+Speaking of fun, the social Sunday night should be a blast! We’re hosting this summit’s social close to the conference center, at [ZuidPool](https://www.zuid-pool.nl/en/). There will be games, bingo, and unconference sign-up throughout the evening. It should be a relaxed way to kick off the week. 
+
+[~Registration is open~](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/)! Space is limited so it’s always a good idea to register early.
+
+If you have any questions, reach out to the [Amsterdam Team](https://github.com/kubernetes/community/tree/master/events/2020/03-contributor-summit#team) on Slack in the [#contributor-summit](https://kubernetes.slack.com/archives/C7J893413) channel.
+
+Hope to see you there!
+
+## Kubernetes Contributor Summit schedule
 
 **Sunday, March 29, 2020**
 
@@ -25,21 +42,3 @@ tl;dr [Registration is open](https://events.linuxfoundation.org/kubernetes-contr
 - Address: [Europaplein 24, 1078 GZ Amsterdam, Netherlands](https://www.google.com/search?q=kubecon+amsterdam+2020&oq=kubecon+amste&aqs=chrome.0.35i39j69i57j0l4j69i61l2.3957j1j4&sourceid=chrome&ie=UTF-8&ibp=htl;events&rciv=evn&sa=X&ved=2ahUKEwiZoLvQ0dvnAhVST6wKHScBBZ8Q5bwDMAB6BAgSEAE#)
 - Time:  09:00 - 17:00 (Breakfast at 08:00)
 
-![Contributor Summit](/images/blog/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced/contribsummit.jpg)
-
-Hello everyone and Happy 2020! It’s hard to believe that KubeCon EU 2020 is less than six weeks away, and with that another contributor summit! This year we have the pleasure of being in Amsterdam in early spring, so be sure to pack some warmer clothing. This summit looks to be exciting with a lot of fantastic community-driven content. We received **26** submissions from the CFP. From that, the events team selected **12** sessions. Each of the sessions falls into one of four categories:
-
-*   Community
-*   Contributor Improvement
-*   Sustainability
-*   In-depth Technical 
-
-On top of the presentations, there will be a dedicated Docs Sprint as well as the New Contributor Workshop 101 and 201 Sessions. All told, we will have five separate rooms of content throughout the day on Monday. Please **[see the full schedule](https://kcseu2020.sched.com/)** to see what sessions you’d be interested in. We hope between the content provided and the inevitable hallway track, everyone has a fun and enriching experience. 
-
-Speaking of fun, the social Sunday night should be a blast! We’re hosting this summit’s social close to the conference center, at [ZuidPool](https://www.zuid-pool.nl/en/). There will be games, bingo, and unconference sign-up throughout the evening. It should be a relaxed way to kick off the week. 
-
-[Registration is open](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/)! Space is limited so it’s always a good idea to register early. 
-
-If you have any questions, reach out to the [Amsterdam Team](https://github.com/kubernetes/community/tree/master/events/2020/03-contributor-summit#team) on Slack in the [#contributor-summit](https://kubernetes.slack.com/archives/C7J893413) channel.
-
-Hope to see you there!

content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md

@@ -3,13 +3,14 @@ layout: blog
 title: Contributor Summit Amsterdam Postponed
 date: 2020-03-04
 slug: Contributor-Summit-Delayed
+evergreen: true
 ---
 
-**Authors:** Dawn Foster (VMware), Jorge Castro (VMware) 
+**Authors:** Dawn Foster (VMware), Jorge Castro (VMware)
 
 The CNCF has announced that [KubeCon + CloudNativeCon EU has been delayed](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/) until July/August of 2020. As a result the Contributor Summit planning team is weighing options for how to proceed. Here’s the current plan:
 
 - There will be an in-person Contributor Summit as planned when KubeCon + CloudNativeCon is rescheduled.
-- We are looking at options for having additional virtual contributor activities in the meantime. 
+- We are looking at options for having additional virtual contributor activities in the meantime.
 
 We will communicate via this blog and the usual communications channels on the final plan. Please bear with us as we adapt when we get more information. Thank you for being patient as the team pivots to bring you a great Contributor Summit!

content/en/blog/_posts/2020-09-03-warnings/index.md

@@ -60,7 +60,7 @@ so we added two administrator-facing tools to help track use of deprecated APIs
 Starting in Kubernetes v1.19, when a request is made to a deprecated REST API endpoint,
 an `apiserver_requested_deprecated_apis` gauge metric is set to `1` in the kube-apiserver process.
 This metric has labels for the API `group`, `version`, `resource`, and `subresource`,
-and a `removed_version` label that indicates the Kubernetes release in which the API will no longer be served.
+and a `removed_release` label that indicates the Kubernetes release in which the API will no longer be served.
 
 This is an example query using `kubectl`, [prom2json](https://github.com/prometheus/prom2json),
 and [jq](https://stedolan.github.io/jq/) to determine which deprecated APIs have been requested
@@ -169,7 +169,7 @@ You can also find that information through the following Prometheus query,
 which returns information about requests made to deprecated APIs which will be removed in v1.22:
 
 ```promql
-apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource)
+apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource)
 group_right() apiserver_request_total
 ```
 

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

@@ -155,7 +155,7 @@ 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 (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the
+former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from dockercli to crictl](/docs/reference/tools/map-crictl-dockercli/)) and for the
 latter you can use newer container build options like [img], [buildah],
 [kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
 

content/en/blog/_posts/2021-04-22-gateway-api/index.md

@@ -30,9 +30,9 @@ This led to design principles that allow the Gateway API to improve upon Ingress
 
 The Gateway API introduces a few new resource types:
 
-- **[GatewayClasses](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes.
-- **[Gateways](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.Gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs.
-- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TCPRoute), [UDPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.UDPRoute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TLSRoute) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future.
+- **[GatewayClasses](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gatewayclass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes.
+- **[Gateways](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs.
+- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/concepts/api-overview/#httproute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), [UDPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future.
 
 ![The resources of the Gateway API](gateway-api-resources.png)
 

content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md

@@ -108,7 +108,7 @@ metadata:
   uid: 93a37fed-23e3-45e8-b6ee-b2521db81638
 ```
 
-In short, what’s happened is that the object was updated, not deleted. That’s because Kubernetes saw that the object contained finalizers and put it into a read-only state. The deletion timestamp signals that the object can only be read, with the exception of removing the finalizer key updates. In other words, the deletion will not be complete until we edit the object and remove the finalizer.
+In short, what’s happened is that the object was updated, not deleted. That’s because Kubernetes saw that the object contained finalizers and blocked removal of the object from etcd. The deletion timestamp signals that deletion was requested, but the deletion will not be complete until we edit the object and remove the finalizer.
 
 Here's a demonstration of using the `patch` command to remove finalizers. If we want to delete an object, we can simply patch it on the command line to remove the finalizers. In this way, the deletion that was running in the background will complete and the object will be deleted. When we attempt to `get` that configmap, it will be gone. 
 

content/en/blog/_posts/2021-09-03-api-server-tracing.md

@@ -42,7 +42,7 @@ samplingRatePerMillion: 10000
 
 ### Enabling Etcd Tracing
 
-Add `--experimental-enable-distributed-tracing`,  `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing.  Note that this traces every request, so it will probably generate a lot of traces if you enable it.
+Add `--experimental-enable-distributed-tracing`,  `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing.  Note that this traces every request, so it will probably generate a lot of traces if you enable it. Required etcd version is [v3.5+](https://etcd.io/docs/v3.5/op-guide/monitoring/#distributed-tracing).
 
 ### Example Trace: List Nodes
 

content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md

@@ -255,7 +255,7 @@ The minimum required versions are:
 
 ## What’s next?
 
-As part of the beta graduation for this feature, SIG Storage plans to update the Kubenetes scheduler to support pod preemption in relation to ReadWriteOncePod storage.
+As part of the beta graduation for this feature, SIG Storage plans to update the Kubernetes scheduler to support pod preemption in relation to ReadWriteOncePod storage.
 This means if two pods request a PersistentVolumeClaim with ReadWriteOncePod, the pod with highest priority will gain access to the PersistentVolumeClaim and any pod with lower priority will be preempted from the node and be unable to access the PersistentVolumeClaim.
 
 ## How can I learn more?

content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md

@@ -1,9 +1,9 @@
 ---
 layout: blog
 title: "Meet Our Contributors - APAC (India region)"
-date: 2022-01-10T12:00:00+0000
+date: 2022-01-10
 slug: meet-our-contributors-india-ep-01
-canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
+canonicalUrl: https://www.kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
 ---
 
 **Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
@@ -19,7 +19,7 @@ Welcome to the first episode of the APAC edition of the "Meet Our Contributors"
 
 In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives.
 
-💫 *Let's get started, so without further ado…* 
+💫 *Let's get started, so without further ado…*
 
 
 ## [Arsh Sharma](https://github.com/RinkiyaKeDad)
@@ -39,7 +39,7 @@ To the newcomers, Arsh helps plan their early contributions sustainably.
 
 Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle.
 
-At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in. 
+At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in.
 
 As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer.
 
@@ -103,4 +103,3 @@ If you have any recommendations/suggestions for who we should interview next, pl
 
 
 We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
-

content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md

@@ -86,7 +86,7 @@ in Kubernetes 1.24.
 
 If you're running Kubernetes v1.24 or later, see [Can I still use Docker Engine as my container runtime?](#can-i-still-use-docker-engine-as-my-container-runtime).
 (Remember, you can switch away from the dockershim if you're using any supported Kubernetes release; from release v1.24, you
-**must** switch as Kubernetes no longer incluides the dockershim).
+**must** switch as Kubernetes no longer includes the dockershim).
 
 [kubelet]: /docs/reference/command-line-tools-reference/kubelet/
 
@@ -175,7 +175,7 @@ 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 (see
-[mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))
+[mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl))
 and for the latter you can use newer container build options like [img], [buildah],
 [kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
 

content/en/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-02.md

@@ -1,7 +1,7 @@
 ---
 layout: blog
 title: "Meet Our Contributors - APAC (Aus-NZ region)"
-date: 2022-03-16T12:00:00+0000
+date: 2022-03-16
 slug: meet-our-contributors-au-nz-ep-02
 canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
 ---
@@ -60,19 +60,13 @@ Nick Young works at VMware as a technical lead for Contour, a CNCF ingress contr
 
 His contribution path was notable in that he began working on major areas of the Kubernetes project early on, skewing his trajectory.
 
-He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions. 
+He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions.
 
 > _Just being active and contributing will get you a long way. Once you've been active for a while, you'll find that you're able to answer questions, which will mean you're asked questions, and before you know it you are an expert._
 
-
-
-
 ---
 
 If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community.
 
 
 We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
-
-
-

content/en/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md

@@ -69,11 +69,11 @@ been deprecated. These removals have been superseded by newer, stable/generally
 
 * [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information. 
 * [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=).
-* In-tree provisioner to CSI driver migration: This applies to a number of in-tree plugins, including [Portworx](https://github.com/kubernetes/enhancements/issues/2589). Refer to the [In-tree Storage Plugin to CSI Migration Design Doc](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/csi-migration.md#background-and-motivations) for more information. 
+* In-tree provisioner to CSI driver migration: This applies to a number of in-tree plugins, including [Portworx](https://github.com/kubernetes/enhancements/issues/2589). Refer to the [In-tree Storage Plugin to CSI Migration Design Doc](https://git.k8s.io/design-proposals-archive/storage/csi-migration.md#background-and-motivations) for more information. 
 * [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/). 
 * [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information. 
 * [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint).
-* [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.21 and is now unsupported. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0) for more information. 
+* [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and will become unsupported with the v1.24 release. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and the [Volume Snapshot GA blog](/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/) blog article for more information. 
 
 ## What to do
 

content/en/blog/_posts/2022-04-28-Increasing-the-security-bar-in-Ingress-NGINX/index.md

@@ -144,7 +144,7 @@ as we may have a different controller as soon as it "knows" what to provide to t
 (we need some help here!!)
 
 Some other projects in Kubernetes already take this approach
-(like [KPNG](​​https://github.com/kubernetes-sigs/kpng), the proposed replacement for `kube-proxy`),
+(like [KPNG](https://github.com/kubernetes-sigs/kpng), the proposed replacement for `kube-proxy`),
 and we plan to align with them and get the same experience for Ingress-NGINX.
 
 ## Further reading

content/en/blog/_posts/2022-05-03-kubernetes-release-1.24.md

@@ -0,0 +1,242 @@
+---
+layout: blog
+title: "Kubernetes 1.24: Stargazer"
+date: 2022-05-03
+slug: kubernetes-1-24-release-announcement
+---
+
+**Authors**: [Kubernetes 1.24 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.24/release-team.md)
+
+We are excited to announce the release of Kubernetes 1.24, the first release of 2022!
+
+This release consists of 46 enhancements: fourteen enhancements have graduated to stable, 
+fifteen enhancements are moving to beta, and thirteen enhancements are entering alpha. 
+Also, two features have been deprecated, and two features have been removed.     
+
+## Major Themes
+
+### Dockershim Removed from kubelet
+
+After its deprecation in v1.20, the dockershim component has been removed from the kubelet in Kubernetes v1.24.
+From v1.24 onwards, you will need to either use one of the other [supported runtimes](/docs/setup/production-environment/container-runtimes/) (such as containerd or CRI-O) 
+or use cri-dockerd if you are relying on Docker Engine as your container runtime. 
+For more information about ensuring your cluster is ready for this removal, please 
+see [this guide](/blog/2022/03/31/ready-for-dockershim-removal/). 
+
+### Beta APIs Off by Default 
+
+[New beta APIs will not be enabled in clusters by default](https://github.com/kubernetes/enhancements/issues/3136). 
+Existing beta APIs and new versions of existing beta APIs will continue to be enabled by default.
+  
+### Signing Release Artifacts
+
+Release artifacts are [signed](https://github.com/kubernetes/enhancements/issues/3031) using [cosign](https://github.com/sigstore/cosign) 
+signatures,
+and there is experimental support for [verifying image signatures](/docs/tasks/administer-cluster/verify-signed-images/). 
+Signing and verification of release artifacts is part of [increasing software supply chain security for the Kubernetes release process](https://github.com/kubernetes/enhancements/issues/3027). 
+
+### OpenAPI v3
+
+Kubernetes 1.24 offers beta support for publishing its APIs in the [OpenAPI v3 format](https://github.com/kubernetes/enhancements/issues/2896). 
+  
+### Storage Capacity and Volume Expansion Are Generally Available
+
+[Storage capacity tracking](https://github.com/kubernetes/enhancements/issues/1472) 
+supports exposing currently available storage capacity via [CSIStorageCapacity objects](/docs/concepts/storage/storage-capacity/#api) 
+and enhances scheduling of pods that use CSI volumes with late binding.
+
+[Volume expansion](https://github.com/kubernetes/enhancements/issues/284) adds support 
+for resizing existing persistent volumes. 
+
+### NonPreemptingPriority to Stable
+
+This feature adds [a new option to PriorityClasses](https://github.com/kubernetes/enhancements/issues/902), 
+which can enable or disable pod preemption. 
+
+### Storage Plugin Migration
+
+Work is underway to [migrate the internals of in-tree storage plugins](https://github.com/kubernetes/enhancements/issues/625) to call out to CSI Plugins
+while maintaining the original API.
+The [Azure Disk](https://github.com/kubernetes/enhancements/issues/1490)
+and [OpenStack Cinder](https://github.com/kubernetes/enhancements/issues/1489) plugins
+have both been migrated.
+
+### gRPC Probes Graduate to Beta
+
+With Kubernetes 1.24, the [gRPC probes functionality](https://github.com/kubernetes/enhancements/issues/2727) 
+has entered beta and is available by default. You can now [configure startup, liveness, and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for your gRPC app 
+natively within Kubernetes without exposing an HTTP endpoint or
+using an extra executable.
+
+### Kubelet Credential Provider Graduates to Beta
+
+Originally released as Alpha in Kubernetes 1.20, the kubelet's support for
+[image credential providers](/docs/tasks/kubelet-credential-provider/kubelet-credential-provider/)
+has now graduated to Beta.
+This allows the kubelet to dynamically retrieve credentials for a container image registry
+using exec plugins rather than storing credentials on the node's filesystem.
+
+### Contextual Logging in Alpha
+
+Kubernetes 1.24 has introduced [contextual logging](https://github.com/kubernetes/enhancements/issues/3077) 
+that enables the caller of a function to control all aspects of logging (output formatting, verbosity, additional values, and names).
+
+### Avoiding Collisions in IP allocation to Services
+
+Kubernetes 1.24 introduces a new opt-in feature that allows you to
+[soft-reserve a range for static IP address assignments](/docs/concepts/services-networking/service/#service-ip-static-sub-range)
+to Services.
+With the manual enablement of this feature, the cluster will prefer automatic assignment from 
+the pool of Service IP addresses, thereby reducing the risk of collision. 
+
+A Service `ClusterIP` can be assigned:
+
+* dynamically, which means the cluster will automatically pick a free IP within the configured Service IP range.
+* statically, which means the user will set one IP within the configured Service IP range.
+
+Service `ClusterIP` are unique; hence, trying to create a Service with a `ClusterIP` that has already been allocated will return an error.
+
+### Dynamic Kubelet Configuration is Removed from the Kubelet
+
+After being deprecated in Kubernetes 1.22, Dynamic Kubelet Configuration has been removed from the kubelet. The feature will be removed from the API server in Kubernetes 1.26.
+
+## CNI Version-Related Breaking Change
+
+Before you upgrade to Kubernetes 1.24, please verify that you are using/upgrading to a container 
+runtime that has been tested to work correctly with this release.
+
+For example, the following container runtimes are being prepared, or have already been prepared, for Kubernetes:
+
+* containerd v1.6.4 and later, v1.5.11 and later
+* CRI-O 1.24 and later
+
+Service issues exist for pod CNI network setup and tear down in containerd
+v1.6.0–v1.6.3 when the CNI plugins have not been upgraded and/or the CNI config
+version is not declared in the CNI config files. The containerd team reports, "these issues are resolved in containerd v1.6.4."
+
+With containerd v1.6.0–v1.6.3, if you do not upgrade the CNI plugins and/or
+declare the CNI config version, you might encounter the following "Incompatible
+CNI versions" or "Failed to destroy network for sandbox" error conditions.
+
+## CSI Snapshot
+
+_This information was added after initial publication._
+
+[VolumeSnapshot v1beta1 CRD has been removed](https://github.com/kubernetes/enhancements/issues/177). 
+Volume snapshot and restore functionality for Kubernetes and the Container Storage Interface (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and is now unsupported. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and [Volume Snapshot GA blog](https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/) for more information.
+
+## Other Updates
+
+### Graduations to Stable
+
+This release saw fourteen enhancements promoted to stable: 
+
+* [Container Storage Interface (CSI) Volume Expansion](https://github.com/kubernetes/enhancements/issues/284)
+* [Pod Overhead](https://github.com/kubernetes/enhancements/issues/688): Account for resources tied to the pod sandbox but not specific containers.
+* [Add non-preempting option to PriorityClasses](https://github.com/kubernetes/enhancements/issues/902)
+* [Storage Capacity Tracking](https://github.com/kubernetes/enhancements/issues/1472) 
+* [OpenStack Cinder In-Tree to CSI Driver Migration](https://github.com/kubernetes/enhancements/issues/1489)
+* [Azure Disk In-Tree to CSI Driver Migration](https://github.com/kubernetes/enhancements/issues/1490)
+* [Efficient Watch Resumption](https://github.com/kubernetes/enhancements/issues/1904): Watch can be efficiently resumed after kube-apiserver reboot. 
+* [Service Type=LoadBalancer Class Field](https://github.com/kubernetes/enhancements/issues/1959): Introduce a new Service annotation `service.kubernetes.io/load-balancer-class` that allows multiple implementations of `type: LoadBalancer` Services in the same cluster.
+* [Indexed Job](https://github.com/kubernetes/enhancements/issues/2214): Add a completion index to Pods of Jobs with a fixed completion count.
+* [Add Suspend Field to Jobs API](https://github.com/kubernetes/enhancements/issues/2232): Add a suspend field to the Jobs API to allow orchestrators to create jobs with more control over when pods are created.
+* [Pod Affinity NamespaceSelector](https://github.com/kubernetes/enhancements/issues/2249): Add a `namespaceSelector` field for to pod affinity/anti-affinity spec.
+* [Leader Migration for Controller Managers](https://github.com/kubernetes/enhancements/issues/2436): kube-controller-manager and cloud-controller-manager can apply new controller-to-controller-manager assignment in HA control plane without downtime.
+* [CSR Duration](https://github.com/kubernetes/enhancements/issues/2784): Extend the CertificateSigningRequest API with a mechanism to allow clients to request a specific duration for the issued certificate.
+
+### Major Changes
+
+This release saw two major changes: 
+
+* [Dockershim Removal](https://github.com/kubernetes/enhancements/issues/2221)
+* [Beta APIs are off by Default](https://github.com/kubernetes/enhancements/issues/3136)
+
+### Release Notes
+
+Check out the full details of the Kubernetes 1.24 release in our [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md).
+    
+### Availability
+
+Kubernetes 1.24 is available for download on [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.24.0).
+To get started with Kubernetes, check out these [interactive tutorials](/docs/tutorials/) or run local 
+Kubernetes clusters using containers as “nodes”, with [kind](https://kind.sigs.k8s.io/).
+You can also easily install 1.24 using [kubeadm](/docs/setup/independent/create-cluster-kubeadm/).
+
+### Release Team
+
+This release would not have been possible without the combined efforts of committed individuals 
+comprising the Kubernetes 1.24 release team. This team came together to deliver all of the components 
+that go into each Kubernetes release, including code, documentation, release notes, and more. 
+
+Special thanks to James Laverack, our release lead, for guiding us through a successful release cycle, 
+and to all of the release team members for the time and effort they put in to deliver the v1.24 
+release for the Kubernetes community. 
+
+### Release Theme and Logo 
+
+**Kubernetes 1.24: Stargazer**
+
+{{< figure src="/images/blog/2022-05-03-kubernetes-release-1.24/kubernetes-1.24.png" alt="" class="release-logo" >}}
+
+The theme for Kubernetes 1.24 is _Stargazer_.
+
+Generations of people have looked to the stars in awe and wonder, from ancient astronomers to the 
+scientists who built the James Webb Space Telescope. The stars have inspired us, set our imagination 
+alight, and guided us through long nights on difficult seas.
+
+With this release we gaze upwards, to what is possible when our community comes together. Kubernetes 
+is the work of hundreds of contributors across the globe and thousands of end-users supporting 
+applications that serve millions. Every one is a star in our sky, helping us chart our course.
+
+The release logo is made by [Britnee Laverack](https://www.instagram.com/artsyfie/), and depicts a telescope set upon starry skies and the 
+[Pleiades](https://en.wikipedia.org/wiki/Pleiades), often known in mythology as the “Seven Sisters”. The number seven is especially auspicious 
+for the Kubernetes project, and is a reference back to our original “Project Seven” name.
+
+This release of Kubernetes is named for those that would look towards the night sky and wonder — for 
+all the stargazers out there. ✨
+   
+### User Highlights
+
+* Check out how leading retail e-commerce company [La Redoute used Kubernetes, alongside other CNCF projects, to transform and streamline its software delivery lifecycle](https://www.cncf.io/case-studies/la-redoute/) - from development to operations. 
+* Trying to ensure no change to an API call would cause any breaks, [Salt Security built its microservices entirely on Kubernetes, and it communicates via gRPC while Linkerd ensures messages are encrypted](https://www.cncf.io/case-studies/salt-security/).
+* In their effort to migrate from private to public cloud, [Allainz Direct engineers redesigned its CI/CD pipeline in just three months while managing to condense 200 workflows down to 10-15](https://www.cncf.io/case-studies/allianz/).
+* Check out how [Bink, a UK based fintech company, updated its in-house Kubernetes distribution with Linkerd to build a cloud-agnostic platform that scales as needed whilst allowing them to keep a close eye on performance and stability](https://www.cncf.io/case-studies/bink/).
+* Using Kubernetes, the Dutch organization [Stichting Open Nederland](http://www.stichtingopennederland.nl/) created a testing portal in just one-and-a-half months to help safely reopen events in the Netherlands. The [Testing for Entry (Testen voor Toegang)](https://www.testenvoortoegang.org/) platform [leveraged the performance and scalability of Kubernetes to help individuals book over 400,000 COVID-19 testing appointments per day. ](https://www.cncf.io/case-studies/true/)
+* Working alongside SparkFabrik and utilizing Backstage, [Santagostino created the developer platform Samaritan to centralize services and documentation, manage the entire lifecycle of services, and simplify the work of Santagostino developers](https://www.cncf.io/case-studies/santagostino/).
+
+### Ecosystem Updates
+
+* KubeCon + CloudNativeCon Europe 2022 will take place in Valencia, Spain, from 16 – 20 May 2022! You can find more information about the conference and registration on the [event site](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/).
+* In the [2021 Cloud Native Survey](https://www.cncf.io/announcements/2022/02/10/cncf-sees-record-kubernetes-and-container-adoption-in-2021-cloud-native-survey/), the CNCF saw record Kubernetes and container adoption. Take a look at the [results of the survey](https://www.cncf.io/reports/cncf-annual-survey-2021/). 
+* The [Linux Foundation](https://www.linuxfoundation.org/) and [The Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF) announced the availability of a new [Cloud Native Developer Bootcamp](https://training.linuxfoundation.org/training/cloudnativedev-bootcamp/?utm_source=lftraining&utm_medium=pr&utm_campaign=clouddevbc0322) to provide participants with the knowledge and skills to design, build, and deploy cloud native applications. Check out the [announcement](https://www.cncf.io/announcements/2022/03/15/new-cloud-native-developer-bootcamp-provides-a-clear-path-to-cloud-native-careers/) to learn more.
+
+### Project Velocity
+
+The [CNCF K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1&refresh=15m) project 
+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 an illustration of the depth and breadth of effort that goes into evolving this ecosystem.
+
+In the v1.24 release cycle, which [ran for 17 weeks](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.24) (January 10 to May 3), we saw contributions from [1029 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.23.0%20-%20v1.24.0&var-metric=contributions) and [1179 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.23.0%20-%20v1.24.0&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All&var-repo_name=kubernetes%2Fkubernetes).
+
+## Upcoming Release Webinar
+
+Join members of the Kubernetes 1.24 release team on Tue May 24, 2022 9:45am – 11am PT to learn about 
+the major features of this release, as well as deprecations and removals to help plan for upgrades. 
+For more information and registration, visit the [event page](https://community.cncf.io/e/mck3kd/) 
+on the CNCF Online Programs site.
+
+## Get Involved
+
+The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. 
+Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below:
+
+* Find out more about contributing to Kubernetes at the [Kubernetes Contributors](https://www.kubernetes.dev/) website
+* Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for the latest updates
+* Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
+* Join the community on [Slack](http://slack.k8s.io/)
+* Post questions (or answer questions) on [Server Fault](https://serverfault.com/questions/tagged/kubernetes).
+* 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/blog/_posts/2022-05-05-volume-expansion-ga.md

@@ -0,0 +1,103 @@
+---
+layout: blog
+title: "Kubernetes 1.24: Volume Expansion Now A Stable Feature"
+date: 2022-05-05
+slug: volume-expansion-ga
+---
+
+**Author:** Hemant Kumar (Red Hat)
+
+Volume expansion was introduced as a alpha feature in Kubernetes 1.8 and it went beta in 1.11 and with Kubernetes 1.24 we are excited to announce general availability(GA)
+of volume expansion.
+
+This feature allows Kubernetes users to simply edit their `PersistentVolumeClaim` objects and specify new size in PVC Spec and Kubernetes will automatically expand the volume
+using storage backend and also expand the underlying file system in-use by the Pod without requiring any downtime at all if possible.
+
+
+### How to use volume expansion
+
+You can trigger expansion for a PersistentVolume by editing the `spec` field of a PVC, specifying a different
+(and larger) storage request. For example, given following PVC:
+
+```
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: myclaim
+spec:
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 1Gi # specify new size here
+```
+
+You can request expansion of the underlying PersistentVolume by specifying a new value instead of old `1Gi` size.
+Once you've changed the requested size, watch the `status.conditions` field of the PVC to see if the
+resize has completed.
+
+When Kubernetes starts expanding the volume - it will add `Resizing` condition to the PVC, which will be removed once expansion completes. More information about progress of
+expansion operation can also be obtained by monitoring events associated with the PVC:
+
+```
+kubectl describe pvc <pvc>
+```
+
+### Storage driver support
+
+Not every volume type however is expandable by default. Some volume types such as - intree hostpath volumes are not expandable at all. For CSI volumes - the CSI driver
+must have capability `EXPAND_VOLUME` in controller or node service (or both if appropriate). Please refer to documentation of your CSI driver, to find out
+if it supports volume expansion.
+
+Please refer to volume expansion documentation for intree volume types which support volume expansion - [Expanding Persistent Volumes](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims).
+
+
+In general to provide some degree of control over volumes that can be expanded, only dynamically provisioned PVCs whose storage class has `allowVolumeExpansion` parameter set to `true` are expandable.
+
+A Kubernetes cluster administrator must edit the appropriate StorageClass object and set
+the `allowVolumeExpansion` field to `true`. For example:
+
+```
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: gp2-default
+provisioner: kubernetes.io/aws-ebs
+parameters:
+  secretNamespace: ""
+  secretName: ""
+allowVolumeExpansion: true
+```
+
+### Online expansion compared to offline expansion
+
+By default, Kubernetes attempts to expand volumes immediately after user requests a resize.
+If one or more Pods are using the volume, Kubernetes tries to expands the volume using an online resize;
+as a result volume expansion usually requires no application downtime.
+Filesystem expansion on the node is also performed online and hence does not require shutting
+down any Pod that was using the PVC.
+
+If you expand a PersistentVolume that is not in use, Kubernetes does an offline resize (and,
+because the volume isn't in use, there is again no workload disruption).
+
+In some cases though - if underlying Storage Driver can only support offline expansion, users of the PVC must take down their Pod before expansion can succeed. Please refer to documentation of your storage
+provider to find out - what mode of volume expansion it supports.
+
+When volume expansion was introduced as an alpha feature, Kubernetes only supported offline filesystem
+expansion on the node and hence required users to restart their pods for file system resizing to finish. 
+His behaviour has been changed and Kubernetes tries its best to fulfil any resize request regardless
+of whether the underlying PersistentVolume volume is online or offline. If your storage provider supports
+online expansion then no Pod restart should be necessary for volume expansion to finish.
+
+## Next steps
+
+Although volume expansion is now stable as part of the recent v1.24 release,
+SIG Storage are working to make it even simpler for users of Kubernetes to expand their persistent storage.
+Kubernetes 1.23 introduced features for triggering recovery from failed volume expansion, allowing users
+to attempt self-service healing after a failed resize.
+See [Recovering from volume expansion failure](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes) for more details.
+
+The Kubernetes contributor community is also discussing the potential for StatefulSet-driven storage expansion. This proposed
+feature would let you trigger expansion for all underlying PVs that are providing storage to a StatefulSet,
+by directly editing the StatefulSet object.
+See the [Support Volume Expansion Through StatefulSets](https://github.com/kubernetes/enhancements/issues/661) enhancement proposal for more details.

content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md

@@ -1,6 +1,6 @@
 ---
 layout: blog
-title: "Storage Capacity Tracking reaches GA in Kubernetes 1.24"
+title: "Kubernetes 1.24: Storage Capacity Tracking Now Generally Available"
 date: 2022-05-06
 slug: storage-capacity-ga
 ---

content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md

@@ -0,0 +1,209 @@
+---
+layout: blog
+title: "Kubernetes 1.24: gRPC container probes in beta"
+date: 2022-05-13
+slug: grpc-probes-now-in-beta
+---
+
+**Author**: Sergey Kanzhelev (Google)
+
+
+With Kubernetes 1.24 the gRPC probes functionality entered beta and is available by default.
+Now you can configure startup, liveness, and readiness probes for your gRPC app
+without exposing any HTTP endpoint, nor do you need an executable. Kubernetes can natively connect to your your workload via gRPC and query its status.
+
+## Some history
+
+It's useful to let the system managing your workload check that the app is
+healthy, has started OK, and whether the app considers itself good to accept
+traffic. Before the gRPC support was added, Kubernetes already allowed you to
+check for health based on running an executable from inside the container image,
+by making an HTTP request, or by checking whether a TCP connection succeeded.
+
+For most apps, those checks are enough. If your app provides a gRPC endpoint
+for a health (or readiness) check, it is easy
+to repurpose the `exec` probe to use it for gRPC health checking.
+In the blog article [Health checking gRPC servers on Kubernetes](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/),
+Ahmet Alp Balkan described how you can do that — a mechanism that still works today.
+
+There is a commonly used tool to enable this that was [created](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d)
+on August 21, 2018, and with
+the first release at [Sep 19, 2018](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1).
+
+This approach for gRPC apps health checking is very popular. There are [3,626 Dockerfiles](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code)
+with the `grpc_health_probe` and [6,621 yaml](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code) files that are discovered with the
+basic search on GitHub (at the moment of writing). This is good indication of the tool popularity
+and the need to support this natively.
+
+Kubernetes v1.23 introduced an alpha-quality implementation of native support for
+querying a workload status using gRPC. Because it was an alpha feature,
+this was disabled by default for the v1.23 release.
+
+## Using the feature
+
+We built gRPC health checking in similar way with other probes and believe
+it will be [easy to use](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)
+if you are familiar with other probe types in Kubernetes.
+The natively supported health probe has many benefits over the workaround involving `grpc_health_probe` executable.
+
+With the native gRPC support you don't need to download and carry `10MB` of an additional executable with your image.
+Exec probes are generally slower than a gRPC call as they require instantiating a new process to run an executable.
+It also makes the checks less sensible for edge cases when the pod is running at maximum resources and has troubles
+instantiating new processes.
+
+There are a few limitations though. Since configuring a client certificate for probes is hard,
+services that require client authentication are not supported. The built-in probes are also
+not checking the server certificates and ignore related problems.
+
+Built-in checks also cannot be configured to ignore certain types of errors
+(`grpc_health_probe` returns different exit codes for different errors),
+and cannot be "chained" to run the health check on multiple services in a single probe.
+
+But all these limitations are quite standard for gRPC and there are easy workarounds
+for those.
+
+## Try it for yourself
+
+### Cluster-level setup
+
+You can try this feature today. To try native gRPC probes, you can spin up a Kubernetes cluster
+yourself with the `GRPCContainerProbe` feature gate enabled, there are many [tools available](/docs/tasks/tools/).
+
+Since the feature gate `GRPCContainerProbe` is enabled by default in 1.24,
+many vendors will have this functionality working out of the box.
+So you may just create an 1.24 cluster on platform of your choice. Some vendors
+allow to enable alpha features on 1.23 clusters.
+
+For example, at the moment of writing, you can spin up the test cluster on GKE for a quick test.
+Other vendors may also have similar capabilities, especially if you
+are reading this blog post long after the Kubernetes 1.24 release.
+
+On GKE use the following command (note, version is `1.23` and `enable-kubernetes-alpha` are specified).
+
+```shell
+gcloud container clusters create test-grpc \
+    --enable-kubernetes-alpha \
+    --no-enable-autorepair \
+    --no-enable-autoupgrade \
+    --release-channel=rapid \
+    --cluster-version=1.23
+```
+
+You will also need to configure `kubectl` to access the cluster:
+
+```shell
+gcloud container clusters get-credentials test-grpc
+```
+
+### Trying the feature out
+
+Let's create the pod to test how gRPC probes work. For this test we will use the `agnhost` image.
+This is a k8s maintained image with that can be used for all sorts of workload testing.
+For example, it has a useful [grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking) module
+that exposes two ports - one is serving health checking service,
+another - http port to react on commands `make-serving` and `make-not-serving`.
+
+Here is an example pod definition. It starts the `grpc-health-checking` module,
+exposes ports `5000` and `8080`, and configures gRPC readiness probe:
+
+``` yaml
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test-grpc
+spec:
+  containers:
+  - name: agnhost
+    image: k8s.gcr.io/e2e-test-images/agnhost:2.35
+    command: ["/agnhost", "grpc-health-checking"]
+    ports:
+    - containerPort: 5000
+    - containerPort: 8080
+    readinessProbe:
+      grpc:
+        port: 5000
+```
+
+If the file called `test.yaml`, you can create the pod and check it's status.
+The pod will be in ready state as indicated by the snippet of the output.
+
+```shell
+kubectl apply -f test.yaml
+kubectl describe test-grpc
+```
+
+The output will contain something like this:
+
+```
+Conditions:
+  Type              Status
+  Initialized       True
+  Ready             True
+  ContainersReady   True
+  PodScheduled      True
+```
+
+Now let's change the health checking endpoint status to NOT_SERVING.
+In order to call the http port of the Pod, let's create a port forward:
+
+```shell
+kubectl port-forward test-grpc 8080:8080
+```
+
+You can `curl` to call the command...
+
+```shell
+curl http://localhost:8080/make-not-serving
+```
+
+... and in a few seconds the port status will switch to not ready.
+
+```shell
+kubectl describe pod test-grpc
+```
+
+The output now will have:
+
+```
+Conditions:
+  Type              Status
+  Initialized       True
+  Ready             False
+  ContainersReady   False
+  PodScheduled      True
+
+...
+
+  Warning  Unhealthy  2s (x6 over 42s)  kubelet            Readiness probe failed: service unhealthy (responded with "NOT_SERVING")
+```
+
+Once it is switched back, in about one second the Pod will get back to ready status:
+
+``` bsh
+curl http://localhost:8080/make-serving
+kubectl describe test-grpc
+```
+
+The output indicates that the Pod went back to being `Ready`:
+
+```
+Conditions:
+  Type              Status
+  Initialized       True
+  Ready             True
+  ContainersReady   True
+  PodScheduled      True
+```
+
+This new built-in gRPC health probing on Kubernetes makes implementing a health-check via gRPC
+much easier than the older approach that relied on using a separate `exec` probe. Read through
+the official
+[documentation](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)
+to learn more and provide feedback before the feature will be promoted to GA.
+
+## Summary
+
+Kubernetes is a popular workload orchestration platform and we add features based on feedback and demand.
+Features like gRPC probes support is a minor improvement that will make life of many app developers
+easier and apps more resilient. Try it today and give feedback, before the feature went into GA.

content/en/blog/_posts/2022-05-16-volume-populators-beta.md

@@ -8,11 +8,11 @@ slug: volume-populators-beta
 **Author:**
 Ben Swartzlander (NetApp)
 
-The volume populators feature is now two releases old and entering beta! The `AnyVolumeDataSouce` feature
+The volume populators feature is now two releases old and entering beta! The `AnyVolumeDataSource` feature
 gate defaults to enabled in Kubernetes v1.24, which means that users can specify any custom resource
 as the data source of a PVC.
 
-An [earlier blog article](/blog/2021/08/30-volume-populators-redesigned/) detailed how the
+An [earlier blog article](/blog/2021/08/30/volume-populators-redesigned/) detailed how the
 volume populators feature works. In short, a cluster administrator can install a CRD and
 associated populator controller in the cluster, and any user who can create instances of 
 the CR can create pre-populated volumes by taking advantage of the populator.

content/en/blog/_posts/2022-05-18-prevent-unauthorised-volume-mode-conversion.md

@@ -0,0 +1,117 @@
+---
+layout: blog
+title: 'Kubernetes 1.24: Prevent unauthorised volume mode conversion'
+date: 2022-05-18
+slug: prevent-unauthorised-volume-mode-conversion-alpha
+---
+
+**Author:** Raunak Pradip Shah (Mirantis)
+
+Kubernetes v1.24 introduces a new alpha-level feature that prevents unauthorised users 
+from modifying the volume mode of a [`PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/) created from an 
+existing [`VolumeSnapshot`](/docs/concepts/storage/volume-snapshots/) in the Kubernetes cluster.  
+
+
+
+### The problem
+
+The [Volume Mode](/docs/concepts/storage/persistent-volumes/#volume-mode) determines whether a volume 
+is formatted into a filesystem or presented as a raw block device.   
+
+Users can leverage the `VolumeSnapshot` feature, which has been stable since Kubernetes v1.20, 
+to create a `PersistentVolumeClaim` (shortened as PVC) from an existing `VolumeSnapshot` in
+the Kubernetes cluster. The PVC spec includes a `dataSource` field, which can point to an 
+existing `VolumeSnapshot` instance.
+Visit [Create a PersistentVolumeClaim from a Volume Snapshot](/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot) for more details.
+
+When leveraging the above capability, there is no logic that validates whether the mode of the
+original volume, whose snapshot was taken, matches the mode of the newly created volume.
+
+This presents a security gap that allows malicious users to potentially exploit an 
+as-yet-unknown vulnerability in the host operating system.
+
+Many popular storage backup vendors convert the volume mode during the course of a 
+backup operation, for efficiency purposes, which prevents Kubernetes from blocking
+the operation completely and presents a challenge in distinguishing trusted
+users from malicious ones.
+
+### Preventing unauthorised users from converting the volume mode
+
+In this context, an authorised user is one who has access rights to perform `Update` 
+or `Patch` operations on `VolumeSnapshotContents`, which is a cluster-level resource.  
+It is upto the cluster administrator to provide these rights only to trusted users
+or applications, like backup vendors.
+
+If the alpha feature is [enabled](https://kubernetes-csi.github.io/docs/) in 
+`snapshot-controller`, `snapshot-validation-webhook` and `external-provisioner`,
+then unauthorised users will not be allowed to modify the volume mode of a PVC
+when it is being created from a `VolumeSnapshot`.
+
+To convert the volume mode, an authorised user must do the following:
+
+1. Identify the `VolumeSnapshot` that is to be used as the data source for a newly 
+created PVC in the given namespace. 
+2. Identify the `VolumeSnapshotContent` bound to the above `VolumeSnapshot`.
+
+  ```shell
+  kubectl get volumesnapshot -n <namespace>
+  ```
+
+3. Add the annotation [`snapshot.storage.kubernetes.io/allowVolumeModeChange`](/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange)
+to the `VolumeSnapshotContent`. 
+
+4. This annotation can be added either via software or manually by the authorised 
+user. The `VolumeSnapshotContent` annotation must look like following manifest fragment:
+
+  ```yaml
+  kind: VolumeSnapshotContent
+  metadata:
+    annotations:
+      - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"
+  ...
+  ```
+
+**Note**: For pre-provisioned `VolumeSnapshotContents`, you must take an extra
+step of setting `spec.sourceVolumeMode` field to either `Filesystem` or `Block`,
+depending on the mode of the volume from which this snapshot was taken.
+
+An example is shown below:
+
+   ```yaml
+   apiVersion: snapshot.storage.k8s.io/v1
+   kind: VolumeSnapshotContent
+   metadata:
+     annotations:
+     - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"
+     name: new-snapshot-content-test
+   spec:
+     deletionPolicy: Delete
+     driver: hostpath.csi.k8s.io
+     source:
+       snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
+     sourceVolumeMode: Filesystem
+     volumeSnapshotRef:
+       name: new-snapshot-test
+       namespace: default
+   ```
+
+Repeat steps 1 to 3 for all `VolumeSnapshotContents` whose volume mode needs to be 
+converted during a backup or restore operation.
+
+If the annotation shown in step 4 above is present on a `VolumeSnapshotContent`
+object, Kubernetes will not prevent the volume mode from being converted.
+Users should keep this in mind before they attempt to add the annotation 
+to any `VolumeSnapshotContent`. 
+
+
+### What's next
+
+[Enable this feature](https://kubernetes-csi.github.io/docs/) and let us know 
+what you think!
+
+We hope this feature causes no disruption to existing workflows while preventing
+malicious users from exploiting security vulnerabilities in their clusters. 
+
+For any queries or issues, join [Kubernetes on Slack](https://slack.k8s.io/) and
+create a thread in the #sig-storage channel. Alternately, create an issue in the
+CSI external-snapshotter [repository](https://github.com/kubernetes-csi/external-snapshotter).

content/en/blog/_posts/2022-05-20-non-graceful-node-shutdown.md

@@ -0,0 +1,96 @@
+---
+layout: blog
+title: "Kubernetes 1.24: Introducing Non-Graceful Node Shutdown Alpha"
+date: 2022-05-20
+slug: kubernetes-1-24-non-graceful-node-shutdown-alpha
+---
+
+**Authors** Xing Yang and Yassine Tijani (VMware)
+
+Kubernetes v1.24 introduces alpha support for [Non-Graceful Node Shutdown](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2268-non-graceful-shutdown). This feature allows stateful workloads to failover to a different node after the original node is shutdown or in a non-recoverable state such as hardware failure or broken OS.
+
+## How is this different from Graceful Node Shutdown
+
+You might have heard about the [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown) capability of Kubernetes,
+and are wondering how the Non-Graceful Node Shutdown feature is different from that. Graceful Node Shutdown
+allows Kubernetes to detect when a node is shutting down cleanly, and handles that situation appropriately.
+A Node Shutdown can be "graceful" only if the node shutdown action can be detected by the kubelet ahead
+of the actual shutdown. However, there are cases where a node shutdown action may not be detected by
+the kubelet. This could happen either because the shutdown command does not trigger the systemd inhibitor
+locks mechanism that kubelet relies upon, or because of a configuration error
+(the `ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are not configured properly).
+
+Graceful node shutdown relies on Linux-specific support. The kubelet does not watch for upcoming
+shutdowns on Windows nodes (this may change in a future Kubernetes release).
+
+When a node is shutdown but without the kubelet detecting it, pods on that node
+also shut down ungracefully. For stateless apps, that's often not a problem (a ReplicaSet adds a new pod once
+the cluster detects that the affected node or pod has failed). For stateful apps, the story is more complicated.
+If you use a StatefulSet and have a pod from that StatefulSet on a node that fails uncleanly, that affected pod
+will be marked as terminating; the StatefulSet cannot create a replacement pod because the pod
+still exists in the cluster.
+As a result, the application running on the StatefulSet may be degraded or even offline. If the original, shut
+down node comes up again, the kubelet on that original node reports in, deletes the existing pods, and
+the control plane makes a replacement pod for that StatefulSet on a different running node.
+If the original node has failed and does not come up, those stateful pods would be stuck in a
+terminating status on that failed node indefinitely.
+
+```
+$ kubectl get pod -o wide
+NAME    READY   STATUS        RESTARTS   AGE   IP           NODE                      NOMINATED NODE   READINESS GATES
+web-0   1/1     Running       0          100m   10.244.2.4   k8s-node-876-1639279816   <none>           <none>
+web-1   1/1     Terminating   0          100m   10.244.1.3   k8s-node-433-1639279804   <none>           <none>
+```
+
+## Try out the new non-graceful shutdown handling
+
+To use the non-graceful node shutdown handling, you must enable the `NodeOutOfServiceVolumeDetach`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the `kube-controller-manager`
+component.
+
+In the case of a node shutdown, you can manually taint that node as out of service. You should make certain that
+the node is truly shutdown (not in the middle of restarting) before you add that taint. You could add that
+taint following a shutdown that the kubelet did not detect and handle in advance; another case where you
+can use that taint is when the node is in a non-recoverable state due to a hardware failure or a broken OS.
+The values you set for that taint can be `node.kubernetes.io/out-of-service=nodeshutdown: "NoExecute"`
+or `node.kubernetes.io/out-of-service=nodeshutdown:" NoSchedule"`.
+Provided you have enabled the feature gate mentioned earlier, setting the out-of-service taint on a Node
+means that pods on the node will be deleted unless if there are matching tolerations on the pods.
+Persistent volumes attached to the shutdown node will be detached, and for StatefulSets, replacement pods will
+be created successfully on a different running node.
+
+```
+$ kubectl taint nodes <node-name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute
+
+$ kubectl get pod -o wide
+NAME    READY   STATUS    RESTARTS   AGE    IP           NODE                      NOMINATED NODE   READINESS GATES
+web-0   1/1     Running   0          150m   10.244.2.4   k8s-node-876-1639279816   <none>           <none>
+web-1   1/1     Running   0          10m    10.244.1.7   k8s-node-433-1639279804   <none>           <none>
+```
+
+Note: Before applying the out-of-service taint, you **must** verify that a node is already in shutdown or power off state (not in the middle of restarting), either because the user intentionally shut it down or the node is down due to hardware failures, OS issues, etc.
+
+Once all the workload pods that are linked to the out-of-service node are moved to a new running node, and the shutdown node has been recovered, you should remove
+that taint on the affected node after the node is recovered.
+If you know that the node will not return to service, you could instead delete the node from the cluster.
+
+## What’s next?
+
+Depending on feedback and adoption, the Kubernetes team plans to push the Non-Graceful Node Shutdown implementation to Beta in either 1.25 or 1.26.
+
+This feature requires a user to manually add a taint to the node to trigger workloads failover and remove the taint after the node is recovered. In the future, we plan to find ways to automatically detect and fence nodes that are shutdown/failed and automatically failover workloads to another node.
+
+## How can I learn more?
+
+Check out the [documentation](/docs/concepts/architecture/nodes/#non-graceful-node-shutdown)
+for non-graceful node shutdown.
+
+## How to get involved?
+
+This feature has a long story. Yassine Tijani ([yastij](https://github.com/yastij)) started the KEP more than two years ago. Xing Yang ([xing-yang](https://github.com/xing-yang)) continued to drive the effort. There were many discussions among SIG Storage, SIG Node, and API reviewers to nail down the design details. Ashutosh Kumar ([sonasingh46](https://github.com/sonasingh46)) did most of the implementation and brought it to Alpha in Kubernetes 1.24.
+
+We want to thank the following people for their insightful reviews: Tim Hockin  ([thockin](https://github.com/thockin)) for his guidance on the design, Jing Xu ([jingxu97](https://github.com/jingxu97)), Hemant Kumar ([gnufied](https://github.com/gnufied)), and Michelle Au ([msau42](https://github.com/msau42)) for reviews from SIG Storage side, and Mrunal Patel ([mrunalp](https://github.com/mrunalp)), David Porter ([bobbypage](https://github.com/bobbypage)), Derek Carr ([derekwaynecarr](https://github.com/derekwaynecarr)), and Danielle Endocrimes ([endocrimes](https://github.com/endocrimes)) for reviews from SIG Node side.
+
+There are many people who have helped review the design and implementation along the way. We want to thank everyone who has contributed to this effort including the about 30 people who have reviewed the [KEP](https://github.com/kubernetes/enhancements/pull/1116) and implementation over the last couple of years.
+
+This feature is a collaboration between SIG Storage and SIG Node. For those interested in getting involved with the design and development of any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). For those interested in getting involved with the design and development of the components that support the controlled interactions between pods and host resources, join the [Kubernetes Node SIG](https://github.com/kubernetes/community/tree/master/sig-node).

content/en/blog/_posts/2022-05-23-service-ip-dynamic-and-static-allocation.md

@@ -0,0 +1,137 @@
+---
+layout: blog
+title: "Kubernetes 1.24: Avoid Collisions Assigning IP Addresses to Services"
+date: 2022-05-23
+slug: service-ip-dynamic-and-static-allocation
+---
+
+**Author:** Antonio Ojea (Red Hat)
+
+
+In Kubernetes, [Services](/docs/concepts/services-networking/service/) are an abstract way to expose
+an application running on a set of Pods. Services
+can have a cluster-scoped virtual IP address (using a Service of `type: ClusterIP`).
+Clients can connect using that virtual IP address, and Kubernetes then load-balances traffic to that
+Service across the different backing Pods.
+
+## How Service ClusterIPs are allocated?
+
+A Service `ClusterIP` can be assigned:
+
+_dynamically_
+: the cluster's control plane automatically picks a free IP address from within the configured IP range for `type: ClusterIP` Services.
+
+_statically_
+: you specify an IP address of your choice, from within the configured IP range for Services.
+
+Across your whole cluster, every Service `ClusterIP` must be unique.
+Trying to create a Service with a specific `ClusterIP` that has already
+been allocated will return an error.
+
+## Why do you need to reserve Service Cluster IPs?
+
+Sometimes you may want to have Services running in well-known IP addresses, so other components and
+users in the cluster can use them.
+
+The best example is the DNS Service for the cluster. Some Kubernetes installers assign the 10th address from
+the Service IP range to the DNS service. Assuming you configured your cluster with Service IP range
+10.96.0.0/16 and you want your DNS Service IP to be 10.96.0.10, you'd have to create a Service like
+this:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    k8s-app: kube-dns
+    kubernetes.io/cluster-service: "true"
+    kubernetes.io/name: CoreDNS
+  name: kube-dns
+  namespace: kube-system
+spec:
+  clusterIP: 10.96.0.10
+  ports:
+  - name: dns
+    port: 53
+    protocol: UDP
+    targetPort: 53
+  - name: dns-tcp
+    port: 53
+    protocol: TCP
+    targetPort: 53
+  selector:
+    k8s-app: kube-dns
+  type: ClusterIP
+```
+
+but as I explained before, the IP address 10.96.0.10 has not been reserved; if other Services are created
+before or in parallel with dynamic allocation, there is a chance they can allocate this IP, hence,
+you will not be able to create the DNS Service because it will fail with a conflict error.
+
+## How can you avoid Service ClusterIP conflicts? {#avoid-ClusterIP-conflict}
+
+In Kubernetes 1.24, you can enable a new feature gate `ServiceIPStaticSubrange`.
+Turning this on allows you to use a different IP
+allocation strategy for Services, reducing the risk of collision.
+
+The `ClusterIP` range will be divided, based on the formula `min(max(16, cidrSize / 16), 256)`,
+described as _never less than 16 or more than 256 with a graduated step between them_.
+
+Dynamic IP assignment will use the upper band by default, once this has been exhausted it will
+use the lower range. This will allow users to use static allocations on the lower band with a low
+risk of collision.
+
+Examples:
+
+#### Service IP CIDR block: 10.96.0.0/24
+
+Range Size: 2<sup>8</sup> - 2 = 254  
+Band Offset: `min(max(16, 256/16), 256)` = `min(16, 256)` = 16  
+Static band start: 10.96.0.1  
+Static band end: 10.96.0.16  
+Range end: 10.96.0.254   
+
+{{< mermaid >}}
+pie showData
+    title 10.96.0.0/24
+    "Static" : 16
+    "Dynamic" : 238
+{{< /mermaid >}}
+
+#### Service IP CIDR block: 10.96.0.0/20
+
+Range Size: 2<sup>12</sup> - 2 = 4094  
+Band Offset: `min(max(16, 4096/16), 256)` = `min(256, 256)` = 256  
+Static band start: 10.96.0.1  
+Static band end: 10.96.1.0  
+Range end: 10.96.15.254  
+
+{{< mermaid >}}
+pie showData
+    title 10.96.0.0/20
+    "Static" : 256
+    "Dynamic" : 3838
+{{< /mermaid >}}
+
+#### Service IP CIDR block: 10.96.0.0/16
+
+Range Size: 2<sup>16</sup> - 2 = 65534  
+Band Offset: `min(max(16, 65536/16), 256)` = `min(4096, 256)` = 256  
+Static band start: 10.96.0.1  
+Static band ends: 10.96.1.0  
+Range end: 10.96.255.254  
+
+{{< mermaid >}}
+pie showData
+    title 10.96.0.0/16
+    "Static" : 256
+    "Dynamic" : 65278
+{{< /mermaid >}}
+
+## Get involved with SIG Network
+
+The current SIG-Network [KEPs](https://github.com/orgs/kubernetes/projects/10) and [issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork) on GitHub illustrate the SIG’s areas of emphasis.
+
+[SIG Network meetings](https://github.com/kubernetes/community/tree/master/sig-network) are a friendly, welcoming venue for you to connect with the community and share your ideas.
+Looking forward to hearing from you!
+

content/en/blog/_posts/2022-05-25-contextual-logging/index.md

@@ -0,0 +1,251 @@
+---
+layout: blog
+title: "Contextual Logging in Kubernetes 1.24"
+date: 2022-05-25
+slug: contextual-logging
+canonicalUrl: https://kubernetes.dev/blog/2022/05/25/contextual-logging/
+---
+
+ **Authors:** Patrick Ohly (Intel)
+
+The [Structured Logging Working
+Group](https://github.com/kubernetes/community/blob/master/wg-structured-logging/README.md)
+has added new capabilities to the logging infrastructure in Kubernetes
+1.24. This blog post explains how developers can take advantage of those to
+make log output more useful and how they can get involved with improving Kubernetes.
+
+## Structured logging
+
+The goal of [structured
+logging](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/1602-structured-logging/README.md)
+is to replace C-style formatting and the resulting opaque log strings with log
+entries that have a well-defined syntax for storing message and parameters
+separately, for example as a JSON struct.
+
+When using the traditional klog text output format for structured log calls,
+strings were originally printed with `\n` escape sequences, except when
+embedded inside a struct. For structs, log entries could still span multiple
+lines, with no clean way to split the log stream into individual entries:
+
+```
+I1112 14:06:35.783529  328441 structured_logging.go:51] "using InfoS" longData={Name:long Data:Multiple
+lines
+with quite a bit
+of text. internal:0}
+I1112 14:06:35.783549  328441 structured_logging.go:52] "using InfoS with\nthe message across multiple lines" int=1 stringData="long: Multiple\nlines\nwith quite a bit\nof text." str="another value"
+```
+
+Now, the `<` and `>` markers along with indentation are used to ensure that splitting at a
+klog header at the start of a line is reliable and the resulting output is human-readable:
+
+```
+I1126 10:31:50.378204  121736 structured_logging.go:59] "using InfoS" longData=<
+	{Name:long Data:Multiple
+	lines
+	with quite a bit
+	of text. internal:0}
+ >
+I1126 10:31:50.378228  121736 structured_logging.go:60] "using InfoS with\nthe message across multiple lines" int=1 stringData=<
+	long: Multiple
+	lines
+	with quite a bit
+	of text.
+ > str="another value"
+```
+
+Note that the log message itself is printed with quoting. It is meant to be a
+fixed string that identifies a log entry, so newlines should be avoided there.
+
+Before Kubernetes 1.24, some log calls in kube-scheduler still used `klog.Info`
+for multi-line strings to avoid the unreadable output. Now all log calls have
+been updated to support structured logging.
+
+## Contextual logging
+
+[Contextual logging](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/3077-contextual-logging/README.md)
+is based on the [go-logr API](https://github.com/go-logr/logr#a-minimal-logging-api-for-go). The key
+idea is that libraries are passed a logger instance by their caller and use
+that for logging instead of accessing a global logger. The binary decides about
+the logging implementation, not the libraries. The go-logr API is designed
+around structured logging and supports attaching additional information to a
+logger.
+
+This enables additional use cases:
+
+- The caller can attach additional information to a logger:
+  - [`WithName`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithName) adds a prefix
+  - [`WithValues`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithValues) adds key/value pairs
+
+  When passing this extended logger into a function and a function uses it
+  instead of the global logger, the additional information is
+  then included in all log entries, without having to modify the code that
+  generates the log entries. This is useful in highly parallel applications
+  where it can become hard to identify all log entries for a certain operation
+  because the output from different operations gets interleaved.
+
+- When running unit tests, log output can be associated with the current test.
+  Then when a test fails, only the log output of the failed test gets shown
+  by `go test`. That output can also be more verbose by default because it
+  will not get shown for successful tests. Tests can be run in parallel
+  without interleaving their output.
+
+One of the design decisions for contextual logging was to allow attaching a
+logger as value to a `context.Context`. Since the logger encapsulates all
+aspects of the intended logging for the call, it is *part* of the context and
+not just *using* it. A practical advantage is that many APIs already have a
+`ctx` parameter or adding one has additional advantages, like being able to get
+rid of `context.TODO()` calls inside the functions.
+
+Another decision was to not break compatibility with klog v2:
+
+- Libraries that use the traditional klog logging calls in a binary that has
+  set up contextual logging will work and log through the logging backend
+  chosen by the binary. However, such log output will not include the
+  additional information and will not work well in unit tests, so libraries
+  should be modified to support contextual logging. The [migration guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md)
+  for structured logging has been extended to also cover contextual logging.
+
+- When a library supports contextual logging and retrieves a logger from its
+  context, it will still work in a binary that does not initialize contextual
+  logging because it will get a logger that logs through klog.
+
+In Kubernetes 1.24, contextual logging is a new alpha feature with
+`ContextualLogging` as feature gate. When disabled (the default), the new klog
+API calls for contextual logging (see below) become no-ops to avoid performance
+or functional regressions.
+
+No Kubernetes component has been converted yet. An [example program](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go)
+in the Kubernetes repository demonstrates how to enable contextual logging in a
+binary and how the output depends on the binary's parameters:
+
+```console
+$ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/
+$ go run . --help
+...
+      --feature-gates mapStringBool  A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
+                                     AllAlpha=true|false (ALPHA - default=false)
+                                     AllBeta=true|false (BETA - default=false)
+                                     ContextualLogging=true|false (ALPHA - default=false)
+$ go run . --feature-gates ContextualLogging=true
+...
+I0404 18:00:02.916429  451895 logger.go:94] "example/myname: runtime" foo="bar" duration="1m0s"
+I0404 18:00:02.916447  451895 logger.go:95] "example: another runtime" foo="bar" duration="1m0s"
+```
+
+The `example` prefix and `foo="bar"` were added by the caller of the function
+which logs the `runtime` message and `duration="1m0s"` value.
+
+The sample code for klog includes an
+[example](https://github.com/kubernetes/klog/blob/v2.60.1/ktesting/example/example_test.go)
+for a unit test with per-test output.
+
+## klog enhancements
+
+### Contextual logging API
+
+The following calls manage the lookup of a logger:
+
+[`FromContext`](https://pkg.go.dev/k8s.io/klog/v2#FromContext)
+: from a `context` parameter, with fallback to the global logger
+
+[`Background`](https://pkg.go.dev/k8s.io/klog/v2#Background)
+: the global fallback, with no intention to support contextual logging
+
+[`TODO`](https://pkg.go.dev/k8s.io/klog/v2#TODO)
+: the global fallback, but only as a temporary solution until the function gets extended to accept
+  a logger through its parameters
+
+[`SetLoggerWithOptions`](https://pkg.go.dev/k8s.io/klog/v2#SetLoggerWithOptions)
+: changes the fallback logger; when called with [`ContextualLogger(true)`](https://pkg.go.dev/k8s.io/klog/v2#ContextualLogger),
+  the logger is ready to be called directly, in which case logging will be done
+  without going through klog
+
+To support the feature gate mechanism in Kubernetes, klog has wrapper calls for
+the corresponding go-logr calls and a global boolean controlling their behavior:
+
+- [`LoggerWithName`](https://pkg.go.dev/k8s.io/klog/v2#LoggerWithName)
+- [`LoggerWithValues`](https://pkg.go.dev/k8s.io/klog/v2#LoggerWithValues)
+- [`NewContext`](https://pkg.go.dev/k8s.io/klog/v2#NewContext)
+- [`EnableContextualLogging`](https://pkg.go.dev/k8s.io/klog/v2#EnableContextualLogging)
+
+Usage of those functions in Kubernetes code is enforced with a linter
+check. The klog default for contextual logging is to enable the functionality
+because it is considered stable in klog. It is only in Kubernetes binaries
+where that default gets overridden and (in some binaries) controlled via the
+`--feature-gate` parameter.
+
+### ktesting logger
+
+The new [ktesting](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting) package
+implements logging through `testing.T` using klog's text output format. It has
+a [single API call](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting#NewTestContext) for
+instrumenting a test case and [support for command line flags](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting/init).
+
+### klogr
+
+[`klog/klogr`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr) continues to be
+supported and it's default behavior is unchanged: it formats structured log
+entries using its own, custom format and prints the result via klog.
+
+However, this usage is discouraged because that format is neither
+machine-readable (in contrast to real JSON output as produced by zapr, the
+go-logr implementation used by Kubernetes) nor human-friendly (in contrast to
+the klog text format).
+
+Instead, a klogr instance should be created with
+[`WithFormat(FormatKlog)`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr#WithFormat)
+which chooses the klog text format. A simpler construction method with the same
+result is the new
+[`klog.NewKlogr`](https://pkg.go.dev/k8s.io/klog/v2#NewKlogr). That is the
+logger that klog returns as fallback when nothing else is configured.
+
+### Reusable output test
+
+A lot of go-logr implementations have very similar unit tests where they check
+the result of certain log calls. If a developer didn't know about certain
+caveats like for example a `String` function that panics when called, then it
+is likely that both the handling of such caveats and the unit test are missing.
+
+[`klog.test`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/test) is a reusable set
+of test cases that can be applied to a go-logr implementation.
+
+### Output flushing
+
+klog used to start a goroutine unconditionally during `init` which flushed
+buffered data at a hard-coded interval. Now that goroutine is only started on
+demand (i.e. when writing to files with buffering) and can be controlled with
+[`StopFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StopFlushDaemon) and
+[`StartFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StartFlushDaemon).
+
+When a go-logr implementation buffers data, flushing that data can be
+integrated into [`klog.Flush`](https://pkg.go.dev/k8s.io/klog/v2#Flush) by
+registering the logger with the
+[`FlushLogger`](https://pkg.go.dev/k8s.io/klog/v2#FlushLogger) option.
+
+### Various other changes
+
+For a description of all other enhancements see in the [release notes](https://github.com/kubernetes/klog/releases).
+
+## logcheck
+
+Originally designed as a linter for structured log calls, the
+ [`logcheck`](https://github.com/kubernetes/klog/tree/788efcdee1e9be0bfbe5b076343d447314f2377e/hack/tools/logcheck)
+tool has been enhanced to support also contextual logging and traditional klog
+log calls. These enhanced checks already found bugs in Kubernetes, like calling
+`klog.Info` instead of `klog.Infof` with a format string and parameters.
+
+It can be included as a plugin in a `golangci-lint` invocation, which is how
+[Kubernetes uses it now](https://github.com/kubernetes/kubernetes/commit/17e3c555c5115f8c9176bae10ba45baa04d23a7b),
+or get invoked stand-alone.
+
+We are in the process of [moving the tool](https://github.com/kubernetes/klog/issues/312) into a new repository because it isn't
+really related to klog and its releases should be tracked and tagged properly.
+
+## Next steps
+
+The [Structured Logging WG](https://github.com/kubernetes/community/tree/master/wg-structured-logging)
+is always looking for new contributors. The migration
+away from C-style logging is now going to target structured, contextual logging
+in one step to reduce the overall code churn and number of PRs. Changing log
+calls is good first contribution to Kubernetes and an opportunity to get to
+know code in various different areas.

content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md

@@ -0,0 +1,148 @@
+---
+layout: blog
+title: 'Kubernetes 1.24: Maximum Unavailable Replicas for StatefulSet'
+date: 2022-05-27
+slug: maxunavailable-for-statefulset
+---
+
+**Author:** Mayank Kumar (Salesforce)
+
+Kubernetes [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), since their introduction in 
+1.5 and becoming stable in 1.9, have been widely used to run stateful applications. They provide stable pod identity, persistent
+per pod storage and ordered graceful deployment, scaling and rolling updates. You can think of StatefulSet as the atomic building
+block for running complex stateful applications. As the use of Kubernetes has grown, so has the number of scenarios requiring
+StatefulSets. Many of these scenarios, require faster rolling updates than the currently supported one-pod-at-a-time updates, in the 
+case where you're using the `OrderedReady` Pod management policy for a StatefulSet.
+
+ 
+Here are some examples:
+
+-  I am using a StatefulSet to orchestrate a multi-instance, cache based application where the size of the cache is large. The cache 
+   starts cold and requires some siginificant amount of time before the container can start. There could be more initial startup tasks
+   that are required. A RollingUpdate on this StatefulSet would take a lot of time before the application is fully updated. If the 
+   StatefulSet supported updating more than one pod at a time, it would result in a much faster update.
+
+-  My stateful application is composed of leaders and followers or one writer and multiple readers. I have multiple readers or 
+   followers and my application can tolerate multiple pods going down at the same time. I want to update this application more than
+   one pod at a time so that i get the new updates rolled out quickly, especially if the number of instances of my application are
+   large. Note that my application still requires unique identity per pod.
+
+
+In order to support such scenarios, Kubernetes 1.24 includes a new alpha feature to help. Before you can use the new feature you must
+enable the `MaxUnavailableStatefulSet` feature flag. Once you enable that, you can specify a new field called `maxUnavailable`, part 
+of the `spec` for a StatefulSet. For example: 
+
+```
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: web
+  namespace: default
+spec:
+  podManagementPolicy: OrderedReady  # you must set OrderedReady
+  replicas: 5
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: k8s.gcr.io/nginx-slim:0.8
+        imagePullPolicy: IfNotPresent
+        name: nginx
+  updateStrategy:
+    rollingUpdate:
+      maxUnavailable: 2 # this is the new alpha field, whose default value is 1
+      partition: 0
+    type: RollingUpdate
+```
+
+If you enable the new feature and you don't specify a value for `maxUnavailable` in a StatefulSet, Kubernetes applies a default
+`maxUnavailable: 1`. This matches the behavior you would see if you don't enable the new feature.
+
+I'll run through a scenario based on that example manifest to demonstrate how this feature works. I will deploy a StatefulSet that
+has 5 replicas, with `maxUnavailable` set to 2 and `partition` set to 0.
+
+I can trigger a rolling update by changing the image to `k8s.gcr.io/nginx-slim:0.9`. Once I initiate the rolling update, I can 
+watch the pods update 2 at a time as the current value of maxUnavailable is 2. The below output shows a span of time and is not 
+complete.  The maxUnavailable can be an absolute number (for example, 2) or a percentage of desired Pods (for example, 10%). The 
+absolute number is calculated from percentage by rounding down.  
+```
+kubectl get pods --watch 
+```
+
+```
+NAME    READY   STATUS    RESTARTS   AGE
+web-0   1/1     Running   0          85s
+web-1   1/1     Running   0          2m6s
+web-2   1/1     Running   0          106s
+web-3   1/1     Running   0          2m47s
+web-4   1/1     Running   0          2m27s
+web-4   1/1     Terminating   0          5m43s ----> start terminating 4
+web-3   1/1     Terminating   0          6m3s  ----> start terminating 3
+web-3   0/1     Terminating   0          6m7s
+web-3   0/1     Pending       0          0s
+web-3   0/1     Pending       0          0s
+web-4   0/1     Terminating   0          5m48s
+web-4   0/1     Terminating   0          5m48s
+web-3   0/1     ContainerCreating   0          2s
+web-3   1/1     Running             0          2s
+web-4   0/1     Pending             0          0s
+web-4   0/1     Pending             0          0s
+web-4   0/1     ContainerCreating   0          0s
+web-4   1/1     Running             0          1s
+web-2   1/1     Terminating         0          5m46s ----> start terminating 2 (only after both 4 and 3 are running)
+web-1   1/1     Terminating         0          6m6s  ----> start terminating 1
+web-2   0/1     Terminating         0          5m47s
+web-1   0/1     Terminating         0          6m7s
+web-1   0/1     Pending             0          0s
+web-1   0/1     Pending             0          0s
+web-1   0/1     ContainerCreating   0          1s
+web-1   1/1     Running             0          2s
+web-2   0/1     Pending             0          0s
+web-2   0/1     Pending             0          0s
+web-2   0/1     ContainerCreating   0          0s
+web-2   1/1     Running             0          1s
+web-0   1/1     Terminating         0          6m6s ----> start terminating 0 (only after 2 and 1 are running)
+web-0   0/1     Terminating         0          6m7s
+web-0   0/1     Pending             0          0s
+web-0   0/1     Pending             0          0s
+web-0   0/1     ContainerCreating   0          0s
+web-0   1/1     Running             0          1s
+```
+Note that as soon as the rolling update starts, both 4 and 3 (the two highest ordinal pods) start terminating at the same time. Pods 
+with ordinal 4 and 3 may become ready at their own pace. As soon as both pods 4 and 3 are ready, pods 2 and 1 start terminating at the
+same time. When pods 2 and 1 are both running and ready, pod 0 starts terminating. 
+
+In Kubernetes, updates to StatefulSets follow a strict ordering when updating Pods. In this example, the update starts at replica 4, then
+replica 3, then replica 2, and so on, one pod at a time. When going one pod at a time, its not possible for 3 to be running and ready 
+before 4. When `maxUnavailable` is more than 1 (in the example scenario I set `maxUnavailable` to 2), it is possible that replica 3 becomes 
+ready and running before replica 4 is ready—and that is ok. If you're a developer and you set `maxUnavailable` to more than 1, you should 
+know that this outcome is possible and you must ensure that your application is able to handle such ordering issues that occur
+if any. When you set `maxUnavailable` greater than 1, the ordering is guaranteed in between each batch of pods being updated. That guarantee
+means that pods in update batch 2 (replicas 2 and 1) cannot start updating until the pods from batch 0 (replicas 4 and 3) are ready.
+
+Although Kubernetes refers to these as _replicas_, your stateful application may have a different view and each pod of the StatefulSet may
+be holding completely different data than other pods. The important thing here is that updates to StatefulSets happen in batches, and you can
+now have a batch size larger than 1 (as an alpha feature).
+
+Also note, that the above behavior is with `podManagementPolicy: OrderedReady`. If you defined a StatefulSet as `podManagementPolicy: Parallel`,
+not only `maxUnavailable` number of replicas are terminated at the same time; `maxUnavailable` number of replicas start in `ContainerCreating`
+phase at the same time as well. This is called bursting.
+
+So, now you may have a lot of questions about:-
+- What is the behavior when you set `podManagementPolicy: Parallel`?
+- What is the behavior when `partition` to a value other than `0`?
+
+It might be better to try and see it for yourself. This is an alpha feature, and the Kubernetes contributors are looking for feedback on this feature. Did
+this help you achieve your stateful scenarios Did you find a bug or do you think the behavior as implemented is not intuitive or can
+break applications or catch them by surprise? Please [open an issue](https://github.com/kubernetes/kubernetes/issues) to let us know.
+
+## Further reading and next steps {#next-steps}
+- [Maximum unavailable Pods](/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods)
+- [KEP for MaxUnavailable for StatefulSet](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/961-maxunavailable-for-statefulset)
+- [Implementation](https://github.com/kubernetes/kubernetes/pull/82162/files)
+- [Enhancement Tracking Issue](https://github.com/kubernetes/enhancements/issues/961)

content/en/blog/_posts/2022-06-01-annual-report-2021.md

@@ -0,0 +1,19 @@
+---
+layout: blog
+title: "Annual Report Summary 2021"
+date: 2022-06-01
+slug: annual-report-summary-2021
+---
+
+**Author:** Paris Pittman (Steering Committee)
+
+Last year, we published our first [Annual Report Summary](/blog/2021/06/28/announcing-kubernetes-community-group-annual-reports/) for 2020 and it's already time for our second edition!
+
+[2021 Annual Report Summary](https://www.cncf.io/reports/kubernetes-annual-report-2021/)
+
+This summary reflects the work that has been done in 2021 and the initiatives on deck for the rest of 2022. Please forward to organizations and indidviduals participating in upstream activities, planning cloud native strategies, and/or those looking to help out. To find a specific community group's complete report, go to the [kubernetes/community repo](https://github.com/kubernetes/community) under the groups folder. Example: [sig-api-machinery/annual-report-2021.md](https://github.com/kubernetes/community/blob/master/sig-api-machinery/annual-report-2021.md)
+
+You’ll see that this report summary is a growth area in itself. It takes us roughly 6 months to prepare and execute, which isn’t helpful or valuable to anyone as a fast moving project with short and long term needs. How can we make this better? Provide your feedback here: https://github.com/kubernetes/steering/issues/242
+
+Reference:
+[Annual Report Documentation](https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md)

content/en/blog/_posts/2022-07-13-gateway-api-in-beta.md

@@ -0,0 +1,178 @@
+---
+layout: blog
+title: Kubernetes Gateway API Graduates to Beta
+date: 2022-07-13
+slug: gateway-api-graduates-to-beta
+canonicalUrl: https://gateway-api.sigs.k8s.io/blog/2022/graduating-to-beta/
+---
+
+**Authors:** Shane Utt (Kong), Rob Scott (Google), Nick Young (VMware), Jeff Apple (HashiCorp)
+
+We are excited to announce the v0.5.0 release of Gateway API. For the first
+time, several of our most important Gateway API resources are graduating to
+beta. Additionally, we are starting a new initiative to explore how Gateway API
+can be used for mesh and introducing new experimental concepts such as URL
+rewrites. We'll cover all of this and more below.
+
+## What is Gateway API?
+
+Gateway API is a collection of resources centered around [Gateway][gw] resources
+(which represent the underlying network gateways / proxy servers) to enable
+robust Kubernetes service networking through expressive, extensible and
+role-oriented interfaces that are implemented by many vendors and have broad
+industry support.
+
+Originally conceived as a successor to the well known [Ingress][ing] API, the
+benefits of Gateway API include (but are not limited to) explicit support for
+many commonly used networking protocols (e.g. `HTTP`, `TLS`, `TCP`, `UDP`) as
+well as tightly integrated support for Transport Layer Security (TLS). The
+`Gateway` resource in particular enables implementations to manage the lifecycle
+of network gateways as a Kubernetes API.
+
+If you're an end-user interested in some of the benefits of Gateway API we
+invite you to jump in and find an implementation that suits you. At the time of
+this release there are over a dozen [implementations][impl] for popular API
+gateways and service meshes and guides are available to start exploring quickly.
+
+[gw]:https://gateway-api.sigs.k8s.io/api-types/gateway/
+[ing]:https://kubernetes.io/docs/reference/kubernetes-api/service-resources/ingress-v1/
+[impl]:https://gateway-api.sigs.k8s.io/implementations/
+
+### Getting started
+
+Gateway API is an official Kubernetes API like
+[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
+Gateway API represents a superset of Ingress functionality, enabling more
+advanced concepts. Similar to Ingress, there is no default implementation of
+Gateway API built into Kubernetes. Instead, there are many different
+[implementations][impl] available, providing significant choice in terms of underlying
+technologies while providing a consistent and portable experience.
+
+Take a look at the [API concepts documentation][concepts] and check out some of
+the [Guides][guides] to start familiarizing yourself with the APIs and how they
+work. When you're ready for a practical application open the [implementations
+page][impl] and select an implementation that belongs to an existing technology
+you may already be familiar with or the one your cluster provider uses as a
+default (if applicable). Gateway API is a [Custom Resource Definition
+(CRD)][crd] based API so you'll need to [install the CRDs][install-crds] onto a
+cluster to use the API.
+
+If you're specifically interested in helping to contribute to Gateway API, we
+would love to have you! Please feel free to [open a new issue][issue] on the
+repository, or join in the [discussions][disc]. Also check out the [community
+page][community] which includes links to the Slack channel and community meetings.
+
+[crd]:https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
+[concepts]:https://gateway-api.sigs.k8s.io/concepts/api-overview/
+[guides]:https://gateway-api.sigs.k8s.io/guides/getting-started/
+[impl]:https://gateway-api.sigs.k8s.io/implementations/
+[install-crds]:https://gateway-api.sigs.k8s.io/guides/getting-started/#install-the-crds
+[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose
+[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions
+[community]:https://gateway-api.sigs.k8s.io/contributing/community/
+
+## Release highlights
+
+### Graduation to beta
+
+The `v0.5.0` release is particularly historic because it marks the growth in
+maturity to a beta API version (`v1beta1`) release for some of the key APIs:
+
+- [GatewayClass](https://gateway-api.sigs.k8s.io/api-types/gatewayclass/)
+- [Gateway](https://gateway-api.sigs.k8s.io/api-types/gateway/)
+- [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/)
+
+This achievement was marked by the completion of several graduation criteria:
+
+- API has been [widely implemented][impl].
+- Conformance tests provide basic coverage for all resources and have multiple implementations passing tests.
+- Most of the API surface is actively being used.
+- Kubernetes SIG Network API reviewers have approved graduation to beta.
+
+For more information on Gateway API versioning, refer to the [official
+documentation](https://gateway-api.sigs.k8s.io/concepts/versioning/). To see
+what's in store for future releases check out the [next steps](#next-steps)
+section.
+
+[impl]:https://gateway-api.sigs.k8s.io/implementations/
+
+### Release channels
+
+This release introduces the `experimental` and `standard` [release channels][ch]
+which enable a better balance of maintaining stability while still enabling
+experimentation and iterative development.
+
+The `standard` release channel includes:
+
+- resources that have graduated to beta
+- fields that have graduated to standard (no longer considered experimental)
+
+The `experimental` release channel includes everything in the `standard` release
+channel, plus:
+
+- `alpha` API resources
+- fields that are considered experimental and have not graduated to `standard` channel
+
+Release channels are used internally to enable iterative development with
+quick turnaround, and externally to indicate feature stability to implementors
+and end-users.
+
+For this release we've added the following experimental features:
+
+- [Routes can attach to Gateways by specifying port numbers](https://gateway-api.sigs.k8s.io/geps/gep-957/)
+- [URL rewrites and path redirects](https://gateway-api.sigs.k8s.io/geps/gep-726/)
+
+[ch]:https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels-eg-experimental-standard
+
+### Other improvements
+
+For an exhaustive list of changes included in the `v0.5.0` release, please see
+the [v0.5.0 release notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.5.0).
+
+## Gateway API for service mesh: the GAMMA Initiative
+Some service mesh projects have [already implemented support for the Gateway
+API](https://gateway-api.sigs.k8s.io/implementations/). Significant overlap
+between the Service Mesh Interface (SMI) APIs and the Gateway API has [inspired
+discussion in the SMI
+community](https://github.com/servicemeshinterface/smi-spec/issues/249) about
+possible integration.
+
+We are pleased to announce that the service mesh community, including
+representatives from Cilium Service Mesh, Consul, Istio, Kuma, Linkerd, NGINX
+Service Mesh and Open Service Mesh, is coming together to form the [GAMMA
+Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/), a dedicated
+workstream within the Gateway API subproject focused on Gateway API for Mesh
+Management and Administration.
+
+This group will deliver [enhancement
+proposals](https://gateway-api.sigs.k8s.io/v1beta1/contributing/gep/) consisting
+of resources, additions, and modifications to the Gateway API specification for
+mesh and mesh-adjacent use-cases.
+
+This work has begun with [an exploration of using Gateway API for
+service-to-service
+traffic](https://docs.google.com/document/d/1T_DtMQoq2tccLAtJTpo3c0ohjm25vRS35MsestSL9QU/edit#heading=h.jt37re3yi6k5)
+and will continue with enhancement in areas such as authentication and
+authorization policy.
+
+## Next steps
+
+As we continue to mature the API for production use cases, here are some of the highlights of what we'll be working on for the next Gateway API releases:
+
+- [GRPCRoute][gep1016] for [gRPC][grpc] traffic routing
+- [Route delegation][pr1085]
+- Layer 4 API maturity: Graduating [TCPRoute][tcpr], [UDPRoute][udpr] and
+  [TLSRoute][tlsr] to beta
+- [GAMMA Initiative](https://gateway-api.sigs.k8s.io/contributing/gamma/) - Gateway API for Service Mesh
+
+If there's something on this list you want to get involved in, or there's
+something not on this list that you want to advocate for to get on the roadmap
+please join us in the #sig-network-gateway-api channel on Kubernetes Slack or our weekly [community calls](https://gateway-api.sigs.k8s.io/contributing/community/#meetings).
+
+[gep1016]:https://github.com/kubernetes-sigs/gateway-api/blob/master/site-src/geps/gep-1016.md
+[grpc]:https://grpc.io/
+[pr1085]:https://github.com/kubernetes-sigs/gateway-api/pull/1085
+[tcpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tcproute_types.go
+[udpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/udproute_types.go
+[tlsr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tlsroute_types.go
+[community]:https://gateway-api.sigs.k8s.io/contributing/community/

content/en/community/code-of-conduct.md

@@ -8,9 +8,9 @@ community_styles_migrated: true
 <div class="community-section" id="cncf-code-of-conduct-intro">
 <p>
 Kubernetes follows the
-<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF Code of Conduct</a>.
+<a href="https://github.com/cncf/foundation/blob/main/code-of-conduct.md">CNCF Code of Conduct</a>.
 The text of the CNCF CoC is replicated below, as of
-<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">commit 214585e</a>.
+<a href="https://github.com/cncf/foundation/blob/71b12a2f8b4589788ef2d69b351a3d035c68d927/code-of-conduct.md">commit 71b12a2</a>.
 If you notice that this is out of date, please
 <a href="https://github.com/kubernetes/website/issues/new">file an issue</a>.
 </p>

content/en/community/static/cncf-code-of-conduct.md

@@ -1,45 +1,72 @@
 <!-- Do not edit this file directly. Get the latest from
-     https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
-## CNCF Community Code of Conduct v1.0
+     https://github.com/cncf/foundation/blob/main/code-of-conduct.md -->
+## CNCF Community Code of Conduct v1.1
 
 ### Contributor Code of Conduct
 
-As contributors and maintainers of this project, and in the interest of fostering
+As contributors and maintainers in the CNCF community, and in the interest of fostering
 an open and welcoming community, we pledge to respect all people who contribute
 through reporting issues, posting feature requests, updating documentation,
 submitting pull requests or patches, and other activities.
 
-We are committed to making participation in this project a harassment-free experience for
-everyone, regardless of level of experience, gender, gender identity and expression,
+We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression,
 sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
 religion, or nationality.
 
-Examples of unacceptable behavior by participants include:
+## Scope
 
-* The use of sexualized language or imagery
-* Personal attacks
-* Trolling or insulting/derogatory comments
+This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
+
+### CNCF Events
+
+CNCF events, or events run by the Linux Foundation with professional events staff, are governed by the Linux Foundation [Events Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be used in conjunction with the CNCF Code of Conduct.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
 * Public or private harassment
-* Publishing other's private information, such as physical or electronic addresses,
- without explicit permission
-* Other unethical or unprofessional conduct.
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
 
-Project maintainers have the right and responsibility to remove, edit, or reject
-comments, commits, code, wiki edits, issues, and other contributions that are not
-aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
-commit themselves to fairly and consistently applying these principles to every aspect
-of managing this project. Project maintainers who do not follow or enforce the Code of
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct.
+By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect
+of managing this project.
+Project maintainers who do not follow or enforce the Code of
 Conduct may be permanently removed from the project team.
 
-This code of conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community.
+## Reporting
 
-Instances of abusive, harassing, or otherwise unacceptable behavior in Kubernetes may be reported by contacting the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via <conduct@kubernetes.io>. For other projects, please contact a CNCF project maintainer or our mediator, Mishi Choudhary <mishi@linux.com>.
+For incidents occurring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via <conduct@kubernetes.io>. You can expect a response within three business days.
+
+For other projects, please contact the CNCF staff via <conduct@cncf.io>. You can expect a response within three business days.
+
+In matters that require an outside mediator, CNCF has retained Mishi Choudhary (mishi@linux.com). Use of an outside mediator can be requested when reporting or used at CNCF staff's discretion. In general, contacting <conduct@cncf.io> directly is preferred.
+
+
+## Enforcement
+
+The Kubernetes project's [Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) enforces code of conduct issues. For all other projects, the CNCF enforces code of conduct issues.
+
+Both bodies try to resolve incidents without punishment, but may remove people from the project or CNCF communities at their discretion.
+
+## Acknowledgements
 
 This Code of Conduct is adapted from the Contributor Covenant
-(https://contributor-covenant.org), version 1.2.0, available at
-https://contributor-covenant.org/version/1/2/0/
-
-### CNCF Events Code of Conduct
-
-CNCF events are governed by the Linux Foundation [Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents.
+(http://contributor-covenant.org), version 2.0 available at
+http://contributor-covenant.org/version/2/0/code_of_conduct/

content/en/community/static/community-values.md

@@ -3,26 +3,26 @@
 
 # Kubernetes Community Values
 
-Kubernetes Community culture is frequently cited as a substantial contributor to the meteoric rise of this Open Source project.  Below are the distilled values which have evolved over the last many years in our community pushing our project and peers toward constant improvement.
+Kubernetes Community culture contributes substantially to the project's success. The following values have evolved over time, pushing our project and peers toward constant improvement.
 
 ## Distribution is better than centralization
 
-The scale of the Kubernetes project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation.  Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstone of our world-wide community.
+The scale of the Kubernetes project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation.  Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstones of our world-wide community.
 
 ## Community over product or company
 
-We are here as a community first, our allegiance is to the intentional stewardship of the Kubernetes project for the benefit of all its members and users everywhere.  We support working together publicly for the common goal of a vibrant interoperable ecosystem providing an excellent experience for our users. Individuals gain status through work, companies gain status through their commitments to support this community and fund the resources necessary for the project  to operate.
+We are here as a community first. Our allegiance is to the intentional stewardship of the Kubernetes project for the benefit of all its members and users everywhere. We support working together publicly for the common goal of a vibrant interoperable ecosystem, providing an excellent experience for our users. Individuals gain status through work. Companies gain status through their commitments to support this community and fund the resources necessary for the project to operate.
 
 ## Automation over process
 
-Large projects have a lot of less exciting, yet, hard work.  We value time spent automating repetitive work more highly than toil. Where that work cannot be automated, it is our culture to recognize and reward all types of contributions. However, heroism is not sustainable.
+Large projects have a lot of hard yet less exciting work. We value time spent automating repetitive work more highly than toil. Where work cannot be automated, our culture recognizes and rewards all types of contributions while recognizing that heroism is not sustainable.
 
 ## Inclusive is better than exclusive
 
-Broadly successful and useful technology requires different perspectives and skill sets which can only be heard in a welcoming and respectful environment.  Community membership is a privilege, not a right. Community Leadership is earned through effort, scope, quality, quantity, and duration of contributions. Our community shows respect for the time and effort put into a discussion regardless of where a contributor is on their growth path.
+Broadly successful and useful technologies require different perspectives and skill sets, which can only be heard in a welcoming and respectful environment. Community membership is a privilege, not a right. Community members earn leadership through effort, scope, quality, quantity, and duration of contributions. Our community respects the time and effort put into a discussion, regardless of where a contributor is on their growth path.
 
 ## Evolution is better than stagnation
 
-Openness to new ideas and studied technological evolution make Kubernetes a stronger project.  Continual improvement, servant leadership, mentorship and respect are the foundations of the Kubernetes project culture. It is the duty for leaders in the Kubernetes community to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up.
+Openness to new ideas and studied technological evolution make Kubernetes a stronger project. Continual improvement, servant leadership, mentorship, and respect are the foundations of Kubernetes culture. Kubernetes community leaders have a duty to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up.
 
 **"Culture eats strategy for breakfast."   --Peter Drucker**

content/en/community/values.md

@@ -9,7 +9,15 @@ community_styles_migrated: true
 sitemap:
   priority: 0.1
 ---
+
 <div class="community-section" id="values-legacy">
+<p>
+This page is a replicated version of
+<a href="https://www.kubernetes.dev/community/values/">Kubernetes Community Values</a>, as of
+<a href="https://github.com/kubernetes/community/blob/5c642749a030c5f7b2363a6bb9bad00a56a92161/values.md">commit 5c64274</a>.
+If you notice that this is out of date, please
+<a href="https://github.com/kubernetes/website/issues/new">file an issue</a>.
+</p>
 {{< include "/static/community-values.md" >}}
 </div>
 

content/en/docs/concepts/architecture/control-plane-node-communication.md

@@ -2,7 +2,7 @@
 reviewers:
 - dchen1107
 - liggitt
-title: Control Plane-Node Communication
+title: Communication between Nodes and the Control Plane
 content_type: concept
 weight: 20
 aliases:
@@ -11,62 +11,109 @@ aliases:
 
 <!-- overview -->
 
-This document catalogs the communication paths between the control plane (apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).
-
-
+This document catalogs the communication paths between the API server and the Kubernetes cluster.
+The intent is to allow users to customize their installation to harden the network configuration
+such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud
+provider).
 
 <!-- body -->
 
 ## Node to Control Plane
-Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminates at the apiserver. None of the other control plane components are designed to expose remote services. The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
-One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed.
 
-Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
+Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run)
+terminates at the API server. None of the other control plane components are designed to expose
+remote services. The API server is configured to listen for remote connections on a secure HTTPS
+port (typically 443) with one or more forms of client
+[authentication](/docs/reference/access-authn-authz/authentication/) enabled.
+One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be
+enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
+or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
+are allowed.
 
-Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated.
-The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.
+Nodes should be provisioned with the public root certificate for the cluster such that they can
+connect securely to the API server along with valid client credentials. A good approach is that the
+client credentials provided to the kubelet are in the form of a client certificate. See
+[kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+for automated provisioning of kubelet client certificates.
 
-The control plane components also communicate with the cluster apiserver over the secure port.
+Pods that wish to connect to the API server can do so securely by leveraging a service account so
+that Kubernetes will automatically inject the public root certificate and a valid bearer token
+into the pod when it is instantiated.
+The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is
+redirected (via `kube-proxy`) to the HTTPS endpoint on the API server.
 
-As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
+The control plane components also communicate with the API server over the secure port.
 
-## Control Plane to node
+As a result, the default operating mode for connections from the nodes and pods running on the
+nodes to the control plane is secured by default and can run over untrusted and/or public
+networks.
 
-There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality.
+## Control plane to node
 
-### apiserver to kubelet
+There are two primary communication paths from the control plane (the API server) to the nodes.
+The first is from the API server to the kubelet process which runs on each node in the cluster.
+The second is from the API server to any node, pod, or service through the API server's _proxy_
+functionality.
 
-The connections from the apiserver to the kubelet are used for:
+### API server to kubelet
+
+The connections from the API server to the kubelet are used for:
 
 * Fetching logs for pods.
-* Attaching (through kubectl) to running pods.
+* Attaching (usually through `kubectl`) to running pods.
 * Providing the kubelet's port-forwarding functionality.
 
-These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks and **unsafe** to run over untrusted and/or public networks.
+These connections terminate at the kubelet's HTTPS endpoint. By default, the API server does not
+verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle
+attacks and **unsafe** to run over untrusted and/or public networks.
 
-To verify this connection, use the `--kubelet-certificate-authority` flag to provide the apiserver with a root certificate bundle to use to verify the kubelet's serving certificate.
+To verify this connection, use the `--kubelet-certificate-authority` flag to provide the API
+server with a root certificate bundle to use to verify the kubelet's serving certificate.
 
-If that is not possible, use [SSH tunneling](#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an
+If that is not possible, use [SSH tunneling](#ssh-tunnels) between the API server and kubelet if
+required to avoid connecting over an
 untrusted or public network.
 
-Finally, [Kubelet authentication and/or authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
 
-### apiserver to nodes, pods, and services
+Finally, [Kubelet authentication and/or authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/)
+should be enabled to secure the kubelet API.
 
-The connections from the apiserver to a node, pod, or service default to plain HTTP connections and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS connection by prefixing `https:` to the node, pod, or service name in the API URL, but they will not validate the certificate provided by the HTTPS endpoint nor provide client credentials. So while the connection will be encrypted, it will not provide any guarantees of integrity. These connections **are not currently safe** to run over untrusted or public networks.
+### API server to nodes, pods, and services
+
+The connections from the API server to a node, pod, or service default to plain HTTP connections
+and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS
+connection by prefixing `https:` to the node, pod, or service name in the API URL, but they will
+not validate the certificate provided by the HTTPS endpoint nor provide client credentials. So
+while the connection will be encrypted, it will not provide any guarantees of integrity. These
+connections **are not currently safe** to run over untrusted or public networks.
 
 ### SSH tunnels
 
-Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel.
-This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running.
+Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this
+configuration, the API server initiates an SSH tunnel to each node in the cluster (connecting to
+the SSH server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or
+service through the tunnel.
+This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are
+running.
 
-SSH tunnels are currently deprecated, so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
+{{< note >}}
+SSH tunnels are currently deprecated, so you shouldn't opt to use them unless you know what you
+are doing. The [Konnectivity service](#konnectivity-service) is a replacement for this
+communication channel.
+{{< /note >}}
 
 ### Konnectivity service
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server in the control plane network and the Konnectivity agents in the nodes network. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections.
-After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.
+As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the
+control plane to cluster communication. The Konnectivity service consists of two parts: the
+Konnectivity server in the control plane network and the Konnectivity agents in the nodes network.
+The Konnectivity agents initiate connections to the Konnectivity server and maintain the network
+connections.
+After enabling the Konnectivity service, all control plane to nodes traffic goes through these
+connections.
+
+Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set
+up the Konnectivity service in your cluster.
 
-Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster.

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

@@ -458,7 +458,7 @@ Message:        Pod was terminated in response to imminent node shutdown.
 
 {{< feature-state state="alpha" for_k8s_version="v1.24" >}}
 
-A node shutdown action may not be detected by kubelet's Node Shutdown Mananger, 
+A node shutdown action may not be detected by kubelet's Node Shutdown Manager, 
 either because the command does not trigger the inhibitor locks mechanism used by 
 kubelet or because of a user error, i.e., the ShutdownGracePeriod and 
 ShutdownGracePeriodCriticalPods are not configured properly. Please refer to above 
@@ -479,29 +479,24 @@ these pods will be stuck in terminating status on the shutdown node forever.
 To mitigate the above situation, a  user can manually add the taint `node 
 kubernetes.io/out-of-service` with either `NoExecute` or `NoSchedule` effect to 
 a Node marking it out-of-service. 
-If the `NodeOutOfServiceVolumeDetach`  [feature gate](/docs/reference/
-command-line-tools-reference/feature-gates/) is enabled on
-`kube-controller-manager`, and a Node is marked out-of-service with this taint, the 
-pods on the node will be forcefully deleted if there are no matching tolerations on
-it and volume detach operations for the pods terminating on the node will happen
-immediately. This allows the Pods on the out-of-service node to recover quickly on a
-different node. 
+If the `NodeOutOfServiceVolumeDetach`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+is enabled on `kube-controller-manager`, and a Node is marked out-of-service with this taint, the
+pods on the node will be forcefully deleted if there are no matching tolerations on it and volume
+detach operations for the pods terminating on the node will happen immediately. This allows the
+Pods on the out-of-service node to recover quickly on a different node. 
 
 During a non-graceful shutdown, Pods are terminated in the two phases:
 
 1. Force delete the Pods that do not have matching `out-of-service` tolerations.
 2. Immediately perform detach volume operation for such pods. 
 
-
 {{< note >}}
 - Before adding the taint `node.kubernetes.io/out-of-service` , it should be verified
-that the node is already in shutdown or power off state (not in the middle of
-restarting).
+  that the node is already in shutdown or power off state (not in the middle of
+  restarting).
 - The user is required to manually remove the out-of-service taint after the pods are
-moved to a new node and the user has checked that the shutdown node has been
-recovered since the user was the one who originally added the taint.
-
-
+  moved to a new node and the user has checked that the shutdown node has been
+  recovered since the user was the one who originally added the taint.
 {{< /note >}}
 
 ### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown}
@@ -654,7 +649,7 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
 
 * Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node.
 * Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
-* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
+* Read the [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
   section of the architecture design document.
 * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
 

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

@@ -11,31 +11,37 @@ no_list: true
 ---
 
 <!-- overview -->
+
 The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
 It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
 
-
 <!-- body -->
+
 ## Planning a cluster
 
-See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
+See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure
+Kubernetes clusters. The solutions listed in this article are called *distros*.
 
-   {{< note  >}}
-   Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
-   {{< /note >}}
+{{< note  >}}
+Not all distros are actively maintained. Choose distros which have been tested with a recent
+version of Kubernetes.
+{{< /note >}}
 
 Before choosing a guide, here are some considerations:
 
- - Do you want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- - Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
-   latter, choose an actively-developed distro. Some distros only use binary releases, but
-   offer a greater variety of choices.
- - Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
-
+- Do you want to try out Kubernetes on your computer, or do you want to build a high-availability,
+  multi-node cluster? Choose distros best suited for your needs.
+- Will you be using **a hosted Kubernetes cluster**, such as
+  [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
+- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly
+  support hybrid clusters. Instead, you can set up multiple clusters.
+- **If you are configuring Kubernetes on-premises**, consider which
+  [networking model](/docs/concepts/cluster-administration/networking/) fits best.
+- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
+- Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**?
+  If the latter, choose an actively-developed distro. Some distros only use binary releases, but
+  offer a greater variety of choices.
+- Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
 
 ## Managing a cluster
 
@@ -45,29 +51,43 @@ Before choosing a guide, here are some considerations:
 
 ## Securing a cluster
 
-* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains.
+* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to
+  generate certificates using different tool chains.
 
-* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
+* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes
+  the environment for Kubelet managed containers on a Kubernetes node.
 
-* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) describes how Kubernetes implements access control for its own API.
+* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) describes
+  how Kubernetes implements access control for its own API.
 
-* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
+* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in
+  Kubernetes, including the various authentication options.
 
-* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
+* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from
+  authentication, and controls how HTTP calls are handled.
 
-* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
+* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
+  explains plug-ins which intercepts requests to the Kubernetes API server after authentication
+  and authorization.
 
-* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
+* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/)
+  describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters
+.
 
-* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs.
+* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes'
+  audit logs.
 
 ### Securing the kubelet
-  * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
-  * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
-  * [Kubelet authentication/authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
+
+* [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
+* [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+* [Kubelet authentication/authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/)
 
 ## Optional Cluster Services
 
-* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
+* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve
+  a DNS name directly to a Kubernetes service.
+
+* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/)
+  explains how logging in Kubernetes works and how to implement it.
 
-* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.

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

@@ -18,19 +18,19 @@ This page lists some of the available add-ons and links to their respective inst
 * [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI.
 * [Antrea](https://antrea.io/) operates at Layer 3/4 to provide networking and security services for Kubernetes, leveraging Open vSwitch as the networking data plane.
 * [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer.
-* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
+* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) unites Flannel and Calico, providing networking and network policy.
 * [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins.
-* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
+* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, or Weave.
 * [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
-* Multus is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
+* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
-* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
-* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
+* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking.
+* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
-* **Romana** is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
+* [Romana](https://github.com/romana) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy](/docs/concepts/services-networking/network-policies/) API.
 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
 
 ## Service Discovery

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

@@ -174,7 +174,7 @@ to balance progress between request flows.
 
 The queuing configuration allows tuning the fair queuing algorithm for a
 priority level. Details of the algorithm can be read in the
-[enhancement proposal](#whats-next), but in short:
+[enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness), but in short:
 
 * Increasing `queues` reduces the rate of collisions between different flows, at
   the cost of increased memory usage. A value of 1 here effectively disables the
@@ -331,7 +331,7 @@ Thus, in a situation with a mixture of servers of different versions
 there may be thrashing as long as different servers have different
 opinions of the proper content of these objects.
 
-Each `kube-apiserver` makes an inital maintenance pass over the
+Each `kube-apiserver` makes an initial maintenance pass over the
 mandatory and suggested configuration objects, and after that does
 periodic maintenance (once per minute) of those objects.
 
@@ -471,11 +471,15 @@ poorly-behaved workloads that may be harming system health.
   requests, broken down by the labels `phase` (which takes on the
   values `waiting` and `executing`) and `request_kind` (which takes on
   the values `mutating` and `readOnly`).  The observations are made
-  periodically at a high rate.
+  periodically at a high rate.  Each observed value is a ratio,
+  between 0 and 1, of a number of requests divided by the
+  corresponding limit on the number of requests (queue length limit
+  for waiting and concurrency limit for executing).
 
 * `apiserver_flowcontrol_read_vs_write_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
+  requests (divided by the corresponding limit to get a ratio in the
+  range 0 to 1) broken down by the labels `phase` (which takes on the
   values `waiting` and `executing`) and `request_kind` (which takes on
   the values `mutating` and `readOnly`); the label `mark` takes on
   values `high` and `low`.  The water marks are accumulated over
@@ -502,11 +506,15 @@ poorly-behaved workloads that may be harming system health.
   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.
+  rate.  Each observed value is a ratio, between 0 and 1, of a number
+  of requests divided by the corresponding limit on the number of
+  requests (queue length limit for waiting and concurrency limit for
+  executing).
 
 * `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
+  requests (divided by the corresponding limit to get a ratio in the
+  range 0 to 1) broken down by the labels `phase` (which takes on the
   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
@@ -514,6 +522,31 @@ poorly-behaved workloads that may be harming system health.
   `apiserver_flowcontrol_priority_level_request_count_samples`.  These
   water marks show the range of values that occurred between samples.
 
+* `apiserver_flowcontrol_priority_level_seat_count_samples` is a
+  histogram vector of observations of the utilization of a priority
+  level's concurrency limit, broken down by `priority_level`.  This
+  utilization is the fraction (number of seats occupied) /
+  (concurrency limit).  This metric considers all stages of execution
+  (both normal and the extra delay at the end of a write to cover for
+  the corresponding notification work) of all requests except WATCHes;
+  for those it considers only the initial stage that delivers
+  notifications of pre-existing objects.  Each histogram in the vector
+  is also labeled with `phase: executing` (there is no seat limit for
+  the waiting phase).  Each histogram gets observations taken
+  periodically, up through the last activity of the relevant sort.
+  The observations
+  are made at a high rate.  
+
+* `apiserver_flowcontrol_priority_level_seat_count_watermarks` is a
+  histogram vector of high or low water marks of the utilization of a
+  priority level's concurrency limit, broken down by `priority_level`
+  and `mark` (which takes on values `high` and `low`).  Each histogram
+  in the vector is also labeled with `phase: executing` (there is no
+  seat limit for the waiting phase).  The water marks are accumulated
+  over windows bounded by the times when an observation was added to
+  `apiserver_flowcontrol_priority_level_seat_count_samples`.  These
+  water marks show the range of values that occurred between samples.
+
 * `apiserver_flowcontrol_request_queue_length_after_enqueue` is a
   histogram vector of queue lengths for the queues, broken down by
   the labels `priority_level` and `flow_schema`, as sampled by the
@@ -556,6 +589,22 @@ poorly-behaved workloads that may be harming system health.
   and `priority_level` (indicating the one to which the request was
   assigned).
 
+* `apiserver_flowcontrol_watch_count_samples` is a histogram vector of
+  the number of active WATCH requests relevant to a given write,
+  broken down by `flow_schema` and `priority_level`.
+
+* `apiserver_flowcontrol_work_estimated_seats` is a histogram vector
+  of the number of estimated seats (maximum of initial and final stage
+  of execution) associated with requests, broken down by `flow_schema`
+  and `priority_level`.
+
+* `apiserver_flowcontrol_request_dispatch_no_accommodation_total` is a
+  counter vec of the number of events that in principle could have led
+  to a request being dispatched but did not, due to lack of available
+  concurrency, broken down by `flow_schema` and `priority_level`.  The
+  relevant sorts of events are arrival of a request and completion of
+  a request.
+
 ### Debug endpoints
 
 When you enable the API Priority and Fairness feature, the `kube-apiserver`

content/en/docs/concepts/cluster-administration/manage-deployment.md

@@ -461,7 +461,7 @@ That's it! The Deployment will declaratively update the deployed nginx applicati
 ## {{% heading "whatsnext" %}}
 
 
-- Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/).
+- Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug/debug-application/debug-running-pod/).
 - See [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/).
 
 

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

@@ -203,4 +203,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/design-proposals-archive/network/networking.md).

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

@@ -279,5 +279,6 @@ to the deleted ConfigMap, it is recommended to recreate these pods.
 
 * Read about [Secrets](/docs/concepts/configuration/secret/).
 * Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+* Read about [changing a ConfigMap (or any other Kubernetes object)](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
 * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
   separating code from configuration.

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

@@ -332,7 +332,7 @@ container of a Pod can specify either or both of the following:
 
 Limits and requests for `ephemeral-storage` are measured in byte quantities.
 You can express storage as a plain integer or as a fixed-point number using one of these suffixes:
-E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
+E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
 Mi, Ki. For example, the following quantities all represent roughly the same value:
 
 - `128974848`
@@ -340,6 +340,10 @@ Mi, Ki. For example, the following quantities all represent roughly the same val
 - `129M`
 - `123Mi`
 
+Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request
+for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
+or 400 megabytes (`400M`).
+
 In the following example, the Pod has two containers. Each container has a request of
 2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral
 storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and
@@ -799,7 +803,7 @@ memory limit (and possibly request) for that container.
 * Get hands-on experience [assigning Memory resources to containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
 * Get hands-on experience [assigning CPU resources to containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
 * Read how the API reference defines a [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)
-  and its [resource requirements](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)
+  and its [resource requirements](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)
 * Read about [project quotas](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F) in XFS
 * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 

content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -18,7 +18,7 @@ It does not mean that there is a file named `kubeconfig`.
 {{< /note >}}
 
 {{< warning >}}
-Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. 
+Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure.
 If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script.
 {{< /warning>}}
 
@@ -53,7 +53,7 @@ clusters and namespaces.
 A *context* element in a kubeconfig file is used to group access parameters
 under a convenient name. Each context has three parameters: cluster, namespace, and user.
 By default, the `kubectl` command-line tool uses parameters from
-the *current context* to communicate with the cluster. 
+the *current context* to communicate with the cluster.
 
 To choose the current context:
 ```
@@ -150,16 +150,16 @@ are stored absolutely.
 
 ## Proxy
 
-You can configure `kubectl` to use proxy by setting `proxy-url` in the kubeconfig file, like:
+You can configure `kubectl` to use a proxy per cluster using `proxy-url` in your kubeconfig file, like this:
 
 ```yaml
 apiVersion: v1
 kind: Config
 
-proxy-url: https://proxy.host:3128
-
 clusters:
 - cluster:
+    proxy-url: http://proxy.example.org:3128
+    server: https://k8s.example.org/k8s/clusters/c-xxyyzz
   name: development
 
 users:
@@ -168,7 +168,6 @@ users:
 contexts:
 - context:
   name: development
-
 ```
 
 

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

@@ -247,6 +247,8 @@ You can still [manually create](/docs/tasks/configure-pod-container/configure-se
 a service account token Secret; for example, if you need a token that never expires.
 However, using the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
 subresource to obtain a token to access the API is recommended instead.
+You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
+command to obtain a token from the `TokenRequest` API.
 {{< /note >}}
 
 #### Projection of Secret keys to specific paths
@@ -886,15 +888,30 @@ In this case, `0` means you have created an empty Secret.
 ### Service account token Secrets
 
 A `kubernetes.io/service-account-token` type of Secret is used to store a
-token that identifies a
+token credential that identifies a
 {{< glossary_tooltip text="service account" term_id="service-account" >}}.
+
+Since 1.22, this type of Secret is no longer used to mount credentials into Pods,
+and obtaining tokens via the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
+API is recommended instead of using service account token Secret objects.
+Tokens obtained from the `TokenRequest` API are more secure than ones stored in Secret objects,
+because they have a bounded lifetime and are not readable by other API clients.
+You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
+command to obtain a token from the `TokenRequest` API.
+
+You should only create a service account token Secret object
+if you can't use the `TokenRequest` API to obtain a token,
+and the security exposure of persisting a non-expiring token credential
+in a readable API object is acceptable to you.
+
 When using this Secret type, you need to ensure that the
 `kubernetes.io/service-account.name` annotation is set to an existing
-service account name. A Kubernetes
-{{< glossary_tooltip text="controller" term_id="controller" >}} fills in some
-other fields such as the `kubernetes.io/service-account.uid` annotation, and the
-`token` key in the `data` field, which is set to contain an authentication
-token.
+service account name. If you are creating both the ServiceAccount and
+the Secret objects, you should create the ServiceAccount object first.
+
+After the Secret is created, a Kubernetes {{< glossary_tooltip text="controller" term_id="controller" >}}
+fills in some other fields such as the `kubernetes.io/service-account.uid` annotation, and the
+`token` key in the `data` field, which is populated with an authentication token.
 
 The following example configuration declares a service account token Secret:
 
@@ -911,20 +928,14 @@ data:
   extra: YmFyCg==
 ```
 
-When creating a `Pod`, Kubernetes automatically finds or creates a service account
-Secret and then automatically modifies your Pod to use this Secret. The service account
-token Secret contains credentials for accessing the Kubernetes API.
-
-The automatic creation and use of API credentials can be disabled or
-overridden if desired. However, if all you need to do is securely access the
-API server, this is the recommended workflow.
+After creating the Secret, wait for Kubernetes to populate the `token` key in the `data` field.
 
 See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)
 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" >}}/#pod-v1-core)
-for information on referencing service account from Pods.
+for information on referencing service account credentials from within Pods.
 
 ### Docker config Secrets
 
@@ -982,7 +993,7 @@ kubectl create secret docker-registry secret-tiger-docker \
 ```
 
 That command creates a Secret of type `kubernetes.io/dockerconfigjson`.
-If you dump the `.data.dockercfgjson` field from that new Secret and then
+If you dump the `.data.dockerconfigjson` field from that new Secret and then
 decode it from base64:
 
 ```shell
@@ -1291,7 +1302,7 @@ on that node.
 - When deploying applications that interact with the Secret API, you should
   limit access using
   [authorization policies](/docs/reference/access-authn-authz/authorization/) such as
-  [RBAC]( /docs/reference/access-authn-authz/rbac/).
+  [RBAC](/docs/reference/access-authn-authz/rbac/).
 - In the Kubernetes API, `watch` and `list` requests for Secrets within a namespace
   are extremely powerful capabilities. Avoid granting this access where feasible, since
   listing Secrets allows the clients to inspect the values of every Secret in that
@@ -1310,7 +1321,7 @@ have access to run a Pod that then exposes the Secret.
 - When deploying applications that interact with the Secret API, you should
   limit access using
   [authorization policies](/docs/reference/access-authn-authz/authorization/) such as
-  [RBAC]( /docs/reference/access-authn-authz/rbac/).
+  [RBAC](/docs/reference/access-authn-authz/rbac/).
 - In the API server, objects (including Secrets) are persisted into
   {{< glossary_tooltip term_id="etcd" >}}; therefore:
   - only allow cluster admistrators to access etcd (this includes read-only access);

content/en/docs/concepts/configuration/windows-resource-management.md

@@ -32,52 +32,48 @@ host, and thus privileged containers are not available on Windows.
 Containers cannot assume an identity from the host because the Security Account Manager
 (SAM) is separate.
 
-## Memory reservations {#resource-management-memory}
+## Memory management {#resource-management-memory}
 
 Windows does not have an out-of-memory process killer as Linux does. Windows always
 treats all user-mode memory allocations as virtual, and pagefiles are mandatory.
 
-Windows nodes do not overcommit memory for processes running in containers. The
+Windows nodes do not overcommit memory for processes. The
 net effect is that Windows won't reach out of memory conditions the same way Linux
 does, and processes page to disk instead of being subject to out of memory (OOM)
 termination. If memory is over-provisioned and all physical memory is exhausted,
 then paging can slow down performance.
 
-You can place bounds on memory use for workloads using the kubelet
-parameters `--kubelet-reserve` and/or `--system-reserve`; these account
-for memory usage on the node (outside of containers), and reduce
-[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
-As you deploy workloads, set resource limits on containers. This also subtracts from
-`NodeAllocatable` and prevents the scheduler from adding more pods once a node is full.
+## CPU management {#resource-management-cpu}
 
-{{< note >}}
-When you set memory resource limits for Windows containers, you should either set a
-limit and leave the memory request unspecified, or set the request equal to the limit.
-{{< /note >}}
+Windows can limit the amount of CPU time allocated for different processes but cannot
+guarantee a minimum amount of CPU time.
 
-On Windows, good practice to avoid over-provisioning is to configure the kubelet
-with a system reserved memory of at least 2GiB to account for Windows, Kubernetes
-and container runtime overheads.
-
-## CPU reservations {#resource-management-cpu}
-
-To account for CPU use by the operating system, the container runtime, and by
-Kubernetes host processes such as the kubelet, you can (and should) reserve a
-percentage of total CPU. You should determine this CPU reservation taking account of
-to the number of CPU cores available on the node. To decide on the CPU percentage to
-reserve, identify the maximum pod density for each node and monitor the CPU usage of
-the system services running there, then choose a value that meets your workload needs.
-
-You can place bounds on CPU usage for workloads using the
-kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to
-account for CPU usage on the node (outside of containers).
-This reduces `NodeAllocatable`.
-The cluster-wide scheduler then takes this reservation into account when determining
-pod placement.
-
-On Windows, the kubelet supports a command-line flag to set the priority of the
+On Windows, the kubelet supports a command-line flag to set the
+[scheduling priority](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities) of the
 kubelet process: `--windows-priorityclass`. This flag allows the kubelet process to get
 more CPU time slices when compared to other processes running on the Windows host.
 More information on the allowable values and their meaning is available at
 [Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class).
 To ensure that running Pods do not starve the kubelet of CPU cycles, set this flag to `ABOVE_NORMAL_PRIORITY_CLASS` or above.
+
+## Resource reservation {#resource-reservation}
+
+To account for memory and CPU used by the operating system, the container runtime, and by
+Kubernetes host processes such as the kubelet, you can (and should) reserve
+memory and CPU resources with the  `--kube-reserved` and/or `--system-reserved` kubelet flags.
+On Windows these values are only used to calculate the node's
+[allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) resources.
+
+{{< caution >}}
+As you deploy workloads, set resource memory and CPU limits on containers.
+This also subtracts from `NodeAllocatable` and helps the cluster-wide scheduler in determining which pods to place on which nodes.
+
+Scheduling pods without limits may over-provision the Windows nodes and in extreme
+cases can cause the nodes to become unhealthy.
+{{< /caution >}}
+
+On Windows, a good practice is to reserve at least 2GiB of memory.
+
+To determine how much CPU to reserve,
+identify the maximum pod density for each node and monitor the CPU usage of
+the system services running there, then choose a value that meets your workload needs.

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

@@ -97,7 +97,7 @@ spec:
 This will instruct the kubelet to use the named RuntimeClass to run this pod. If the named
 RuntimeClass does not exist, or the CRI cannot run the corresponding handler, the pod will enter the
 `Failed` terminal [phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase). Look for a
-corresponding [event](/docs/tasks/debug-application-cluster/debug-application-introspection/) for an
+corresponding [event](/docs/tasks/debug/debug-application/debug-running-pod/) for an
 error message.
 
 If no `runtimeClassName` is specified, the default RuntimeHandler will be used, which is equivalent

content/en/docs/concepts/extend-kubernetes/_index.md

@@ -17,26 +17,29 @@ no_list: true
 
 <!-- overview -->
 
-Kubernetes is highly configurable and extensible. As a result,
-there is rarely a need to fork or submit patches to the Kubernetes
-project code.
+Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or
+submit patches to the Kubernetes project code.
 
-This guide describes the options for customizing a Kubernetes
-cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to
-understand how to adapt their Kubernetes cluster to the needs of
-their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it
-useful as an introduction to what extension points and patterns
-exist, and their trade-offs and limitations.
+This guide describes the options for customizing a Kubernetes cluster. It is aimed at
+{{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to understand
+how to adapt their Kubernetes cluster to the needs of their work environment. Developers who are
+prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or
+Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also
+find it useful as an introduction to what extension points and patterns exist, and their
+trade-offs and limitations.
 
 <!-- body -->
 
 ## Overview
 
-Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions.
+Customization approaches can be broadly divided into *configuration*, which only involves changing
+flags, local configuration files, or API resources; and *extensions*, which involve running
+additional programs or services. This document is primarily about extensions.
 
 ## Configuration
 
-*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
+*Configuration files* and *flags* are documented in the Reference section of the online
+documentation, under each binary:
 
 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
 * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
@@ -44,9 +47,22 @@ Customization approaches can be broadly divided into *configuration*, which only
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
 
-Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
+Flags and configuration files may not always be changeable in a hosted Kubernetes service or a
+distribution with managed installation. When they are changeable, they are usually only changeable
+by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and
+setting them may require restarting processes. For those reasons, they should be used only when
+there are no other options.
 
-*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
+*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/),
+[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/),
+[NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control
+([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs.
+APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations.
+They are declarative and use the same conventions as other Kubernetes resources like pods,
+so new cluster configuration can be repeatable and be managed the same way as applications.
+And, where they are stable, they enjoy a
+[defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs.
+For these reasons, they are preferred over *configuration files* and *flags* where suitable.
 
 ## Extensions
 
@@ -70,10 +86,9 @@ There is a specific pattern for writing client programs that work well with
 Kubernetes called the *Controller* pattern. Controllers typically read an
 object's `.spec`, possibly do things, and then update the object's `.status`.
 
-A controller is a client of Kubernetes. When Kubernetes is the client and
-calls out to a remote service, it is called a *Webhook*. The remote service
-is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
-failure.
+A controller is a client of Kubernetes. When Kubernetes is the client and calls out to a remote
+service, it is called a *Webhook*. The remote service is called a *Webhook Backend*. Like
+Controllers, Webhooks do add a point of failure.
 
 In the webhook model, Kubernetes makes a network request to a remote service.
 In the *Binary Plugin* model, Kubernetes executes a binary (program).
@@ -95,15 +110,35 @@ This diagram shows the extension points in a Kubernetes system.
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
 ![Extension Points](/docs/concepts/extend-kubernetes/extension-points.png)
 
-1.   Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
-2.   The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section.
-3.   The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](#user-defined-types) section. Custom Resources are often used with API Access Extensions.
-4.   The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section.
-5.   Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
-6.   The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](#network-plugins) allow for different implementations of pod networking.
-7.  The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](#storage-plugins).
+1. Users often interact with the Kubernetes API using `kubectl`.
+   [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary.
+   They only affect the individual user's local environment, and so cannot enforce site-wide policies.
 
-If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
+1. The API server handles all requests. Several types of extension points in the API server allow
+   authenticating requests, or blocking them based on their content, editing content, and handling
+   deletion. These are described in the [API Access Extensions](#api-access-extensions) section.
+
+1. The API server serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are
+   defined by the Kubernetes project and can't be changed. You can also add resources that you
+   define, or that other projects have defined, called *Custom Resources*, as explained in the
+   [Custom Resources](#user-defined-types) section. Custom Resources are often used with API access
+   extensions.
+
+1. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend
+   scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section.
+
+1. Much of the behavior of Kubernetes is implemented by programs called Controllers which are
+   clients of the API server. Controllers are often used in conjunction with Custom Resources.
+
+1. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on
+   the cluster network. [Network Plugins](#network-plugins) allow for different implementations of
+   pod networking.
+
+1. The kubelet also mounts and unmounts volumes for containers. New types of storage can be
+   supported via [Storage Plugins](#storage-plugins).
+
+If you are unsure where to start, this flowchart can help. Note that some solutions may involve
+several types of extensions.
 
 <!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
 ![Flowchart for Extension](/docs/concepts/extend-kubernetes/flowchart.png)
@@ -112,60 +147,86 @@ If you are unsure where to start, this flowchart can help. Note that some soluti
 
 ### User-Defined Types
 
-Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
+Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application
+configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such
+as `kubectl`.
 
 Do not use a Custom Resource as data storage for application, user, or monitoring data.
 
-For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
+For more about Custom Resources, see the
+[Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 
 
 ### Combining New APIs with Automation
 
-The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
+The combination of a custom resource API and a control loop is called the
+[Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage
+specific, usually stateful, applications. These custom APIs and control loops can also be used to
+control other resources, such as storage or policies.
 
 ### Changing Built-in Resources
 
-When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
-Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
+When you extend the Kubernetes API by adding custom resources, the added resources always fall
+into a new API Groups. You cannot replace or change existing API groups.
+Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API
+Access Extensions do.
 
 
 ### API Access Extensions
 
-When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow.
+When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then
+subject to various types of Admission Control. See
+[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/)
+for more on this flow.
 
 Each of these steps offers extension points.
 
-Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
+Kubernetes has several built-in authentication methods that it supports. It can also sit behind an
+authenticating proxy, and it can send a token from an Authorization header to a remote service for
+verification (a webhook). All of these methods are covered in the
+[Authentication documentation](/docs/reference/access-authn-authz/authentication/).
 
 ### Authentication
 
-[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
-
-Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
+[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates
+in all requests to a username for the client making the request.
 
+Kubernetes provides several built-in authentication methods, and an
+[Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
+method if those don't meet your needs.
 
 ### Authorization
 
-[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
-
+[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific
+users can read, write, and do other operations on API resources. It works at the level of whole
+resources -- it doesn't discriminate based on arbitrary object fields. If the built-in
+authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/)
+allows calling out to user-provided code to make an authorization decision.
 
 ### Dynamic Admission Control
 
-After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
+After a request is authorized, if it is a write operation, it also goes through
+[Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps.
+In addition to the built-in steps, there are several extensions:
 
-*   The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
-*   To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
+* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
+  restricts what images can be run in containers.
+* To make arbitrary admission control decisions, a general
+  [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
+  can be used. Admission Webhooks can reject creations or updates.
 
 ## Infrastructure Extensions
 
 ### Storage Plugins
 
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
-) allow users to mount volume types without built-in support by having the
-Kubelet call a Binary Plugin to mount the volume.
-
-FlexVolume is deprecated since Kubernetes v1.23. The Out-of-tree CSI driver is the recommended way to write volume drivers in Kubernetes. See [Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) for more information.
+[Flex Volumes](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md)
+allow users to mount volume types without built-in support by having the kubelet call a binary
+plugin to mount the volume.
 
+FlexVolume is deprecated since Kubernetes v1.23. The out-of-tree CSI driver is the recommended way
+to write volume drivers in Kubernetes. See
+[Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)
+for more information.
 
 ### Device Plugins
 
@@ -173,7 +234,6 @@ Device plugins allow a node to discover new Node resources (in addition to the
 builtin ones like cpu and memory) via a
 [Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/).
 
-
 ### Network Plugins
 
 Different networking fabrics can be supported via node-level
@@ -191,7 +251,7 @@ This is a significant undertaking, and almost all Kubernetes users find they
 do not need to modify the scheduler.
 
 The scheduler also supports a
-[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
+[webhook](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)
 that permits a webhook backend (scheduler extension) to filter and prioritize
 the nodes chosen for a pod.
 

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

@@ -8,7 +8,7 @@ weight: 20
 <!-- overview -->
 {{< feature-state for_k8s_version="v1.10" state="beta" >}}
 
-Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
+Kubernetes provides a [device plugin framework](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)
 that you can use to advertise system hardware resources to the
 {{< glossary_tooltip term_id="kubelet" >}}.
 

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

@@ -14,6 +14,8 @@ weight: 10
 Kubernetes {{< skew currentVersion >}} supports [Container Network Interface](https://github.com/containernetworking/cni)
 (CNI) plugins for cluster networking. You must use a CNI plugin that is compatible with your cluster and that suits your needs. Different plugins are available (both open- and closed- source) in the wider Kubernetes ecosystem.
 
+A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). 
+
 You must use a CNI plugin that is compatible with the 
 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) or later
 releases of the CNI specification. The Kubernetes project recommends using a plugin that is
@@ -24,26 +26,37 @@ CNI specification (plugins can be compatible with multiple spec versions).
 
 ## Installation
 
-A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). The CRI manages its own CNI plugins. There are two Kubelet command line parameters to keep in mind when using plugins:
+A Container Runtime, in the networking context, is a daemon on a node configured to provide CRI Services for kubelet. In particular, the Container Runtime must be configured to load the CNI plugins required to implement the Kubernetes network model.
 
-* `cni-bin-dir`: Kubelet probes this directory for plugins on startup
-* `network-plugin`: The network plugin to use from `cni-bin-dir`.  It must match the name reported by a plugin probed from the plugin directory.  For CNI plugins, this is `cni`.
+{{< note >}}
+Prior to Kubernetes 1.24, the CNI plugins could also be managed by the kubelet using the `cni-bin-dir` and `network-plugin` command-line parameters.
+These command-line parameters were removed in Kubernetes 1.24, with management of the CNI no longer in scope for kubelet.
+
+See [Troubleshooting CNI plugin-related errors](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)
+if you are facing issues following the removal of dockershim.
+{{< /note >}}
+
+For specific information about how a Container Runtime manages the CNI plugins, see the documentation for that Container Runtime, for example:
+- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
+- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
+
+For specific information about how to install and manage a CNI plugin, see the documentation for that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
 
 ## Network Plugin Requirements
 
-Besides providing the [`NetworkPlugin` interface](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) to configure and clean up pod networking, the plugin may also need specific support for kube-proxy.  The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables.  For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly.  If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy.
+For plugin developers and users who regularly build or deploy Kubernetes, the plugin may also need specific configuration to support kube-proxy.
+The iptables proxy depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables.
+For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly.
+If the plugin does not use a Linux bridge, but uses something like Open vSwitch or some other mechanism instead, it should ensure container traffic is appropriately routed for the proxy.
 
-By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy.
+By default, if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy.
 
-### CNI
+### Loopback CNI
 
-The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option.  Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network.  The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`).
+In addition to the CNI plugin installed on the nodes for implementing the Kubernetes network model, Kubernetes also requires the container runtimes to provide a loopback interface `lo`, which is used for each sandbox (pod sandboxes, vm sandboxes, ...).
+Implementing the loopback interface can be accomplished by re-using the [CNI loopback plugin.](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) or by developing your own code to achieve this (see [this example from CRI-O](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)).
 
-If there are multiple CNI configuration files in the directory, the kubelet uses the configuration file that comes first by name in lexicographic order.
-
-In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0
-
-#### Support hostPort
+### Support hostPort
 
 The CNI networking plugin supports `hostPort`. You can use the official [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
 plugin offered by the CNI plugin team or use your own plugin with portMapping functionality.
@@ -80,7 +93,7 @@ For example:
 }
 ```
 
-#### Support traffic shaping
+### Support traffic shaping
 
 **Experimental Feature**
 
@@ -132,8 +145,4 @@ metadata:
 ...
 ```
 
-## Usage Summary
-
-* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`).
-
 ## {{% heading "whatsnext" %}}

content/en/docs/concepts/extend-kubernetes/operator.md

@@ -111,7 +111,9 @@ Operator.
 {{% thirdparty-content %}}
 
 * [Charmed Operator Framework](https://juju.is/)
+* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk)
 * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
+* [kube-rs](https://kube.rs/) (Rust)
 * [kubebuilder](https://book.kubebuilder.io/)
 * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK)
 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)

content/en/docs/concepts/extend-kubernetes/service-catalog.md

@@ -1,237 +0,0 @@
----
-title: Service Catalog
-reviewers:
-- chenopis
-content_type: concept
-weight: 40
----
-
-<!-- overview -->
-{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}  
-
-A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure.
-Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple Queue Service, and Google Cloud Pub/Sub, but they can be any software offering that can be used by an application.
-
-Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster.
-
-
-
-
-<!-- body -->
-## Example use case
-
-An {{< glossary_tooltip text="application developer" term_id="application-developer" >}} wants to use message queuing as part of their application running in a Kubernetes cluster.
-However, they do not want to deal with the overhead of setting such a service up and administering it themselves.
-Fortunately, there is a cloud provider that offers message queuing as a managed service through its service broker.
-
-A cluster operator can setup Service Catalog and use it to communicate with the cloud provider's service broker to provision an instance of the message queuing service and make it available to the application within the Kubernetes cluster.
-The application developer therefore does not need to be concerned with the implementation details or management of the message queue.
-The application can access the message queue as a service.
-
-## Architecture
-
-Service Catalog uses the [Open service broker API](https://github.com/openservicebrokerapi/servicebroker) to communicate with service brokers, acting as an intermediary for the Kubernetes API Server to negotiate the initial provisioning and retrieve the credentials necessary for the application to use a managed service.
-
-It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) architecture.
-
-<br>
-
-![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg)
-
-
-### API Resources
-
-Service Catalog installs the `servicecatalog.k8s.io` API and provides the following Kubernetes resources:
-
-* `ClusterServiceBroker`: An in-cluster representation of a service broker, encapsulating its server connection details.
-These are created and managed by cluster operators who wish to use that broker server to make new types of managed services available within their cluster.
-* `ClusterServiceClass`: A managed service offered by a particular service broker.
-When a new `ClusterServiceBroker` resource is added to the cluster, the Service Catalog controller connects to the service broker to obtain a list of available managed services. It then creates a new `ClusterServiceClass` resource corresponding to each managed service.
-* `ClusterServicePlan`: A specific offering of a managed service. For example, a managed service may have different plans available, such as a free tier or paid tier, or it may have different configuration options, such as using SSD storage or having more resources. Similar to `ClusterServiceClass`, when a new `ClusterServiceBroker` is added to the cluster, Service Catalog creates a new `ClusterServicePlan` resource corresponding to each Service Plan available for each managed service.
-* `ServiceInstance`: A provisioned instance of a `ClusterServiceClass`.
-These are created by cluster operators to make a specific instance of a managed service available for use by one or more in-cluster applications.
-When a new `ServiceInstance` resource is created, the Service Catalog controller connects to the appropriate service broker and instruct it to provision the service instance.
-* `ServiceBinding`: Access credentials to a `ServiceInstance`.
-These are created by cluster operators who want their applications to make use of a `ServiceInstance`.
-Upon creation, the Service Catalog controller creates a Kubernetes `Secret` containing connection details and credentials for the Service Instance, which can be mounted into Pods.
-
-### Authentication
-
-Service Catalog supports these methods of authentication:
-
-* Basic (username/password)
-* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
-
-## Usage
-
-A cluster operator can use Service Catalog API Resources to provision managed services and make them available within a Kubernetes cluster. The steps involved are:
-
-1. Listing the managed services and Service Plans available from a service broker.
-1. Provisioning a new instance of the managed service.
-1. Binding to the managed service, which returns the connection credentials.
-1. Mapping the connection credentials into the application.
-
-### Listing managed services and Service Plans
-
-First, a cluster operator must create a `ClusterServiceBroker` resource within the `servicecatalog.k8s.io` group. This resource contains the URL and connection details necessary to access a service broker endpoint.
-
-This is an example of a `ClusterServiceBroker` resource:
-
-```yaml
-apiVersion: servicecatalog.k8s.io/v1beta1
-kind: ClusterServiceBroker
-metadata:
-  name: cloud-broker
-spec:
-  # Points to the endpoint of a service broker. (This example is not a working URL.)
-  url:  https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
-  #####
-  # Additional values can be added here, which may be used to communicate
-  # with the service broker, such as bearer token info or a caBundle for TLS.
-  #####
-```
-
-The following is a sequence diagram illustrating the steps involved in listing managed services and Plans available from a service broker:
-
-![List Services](/images/docs/service-catalog-list.svg)
-
-1. Once the `ClusterServiceBroker` resource is added to Service Catalog, it triggers a call to the external service broker for a list of available services.
-1. The service broker returns a list of available managed services and a list of Service Plans, which are cached locally as `ClusterServiceClass` and `ClusterServicePlan` resources respectively.
-1. A cluster operator can then get the list of available managed services using the following command:
-
-        kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
-
-    It should output a list of service names with a format similar to:
-
-        SERVICE NAME                           EXTERNAL NAME
-        4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468   cloud-provider-service
-        ...                                    ...
-
-    They can also view the Service Plans available using the following command:
-
-        kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
-
-    It should output a list of plan names with a format similar to:
-
-        PLAN NAME                              EXTERNAL NAME
-        86064792-7ea2-467b-af93-ac9694d96d52   service-plan-name
-        ...                                    ...
-
-
-### Provisioning a new instance
-
-A cluster operator can initiate the provisioning of a new instance by creating a `ServiceInstance` resource.
-
-This is an example of a `ServiceInstance` resource:
-
-```yaml
-apiVersion: servicecatalog.k8s.io/v1beta1
-kind: ServiceInstance
-metadata:
-  name: cloud-queue-instance
-  namespace: cloud-apps
-spec:
-  # References one of the previously returned services
-  clusterServiceClassExternalName: cloud-provider-service
-  clusterServicePlanExternalName: service-plan-name
-  #####
-  # Additional parameters can be added here,
-  # which may be used by the service broker.
-  #####
-```
-
-The following sequence diagram illustrates the steps involved in provisioning a new instance of a managed service:
-
-![Provision a Service](/images/docs/service-catalog-provision.svg)
-
-1. When the `ServiceInstance` resource is created, Service Catalog initiates a call to the external service broker to provision an instance of the service.
-1. The service broker creates a new instance of the managed service and returns an HTTP response.
-1. A cluster operator can then check the status of the instance to see if it is ready.
-
-### Binding to a managed service
-
-After a new instance has been provisioned, a cluster operator must bind to the managed service to get the connection credentials and service account details necessary for the application to use the service. This is done by creating a `ServiceBinding` resource.
-
-The following is an example of a `ServiceBinding` resource:
-
-```yaml
-apiVersion: servicecatalog.k8s.io/v1beta1
-kind: ServiceBinding
-metadata:
-  name: cloud-queue-binding
-  namespace: cloud-apps
-spec:
-  instanceRef:
-    name: cloud-queue-instance
-  #####
-  # Additional information can be added here, such as a secretName or
-  # service account parameters, which may be used by the service broker.
-  #####
-```
-
-The following sequence diagram illustrates the steps involved in binding to a managed service instance:
-
-![Bind to a managed service](/images/docs/service-catalog-bind.svg)
-
-1. After the `ServiceBinding` is created, Service Catalog makes a call to the external service broker requesting the information necessary to bind with the service instance.
-1. The service broker enables the application permissions/roles for the appropriate service account.
-1. The service broker returns the information necessary to connect and access the managed service instance. This is provider and service-specific so the information returned may differ between Service Providers and their managed services.
-
-### Mapping the connection credentials
-
-After binding, the final step involves mapping the connection credentials and service-specific information into the application.
-These pieces of information are stored in secrets that the application in the cluster can access and use to connect directly with the managed service.
-
-<br>
-
-![Map connection credentials](/images/docs/service-catalog-map.svg)
-
-#### Pod configuration File
-
-One method to perform this mapping is to use a declarative Pod configuration.
-
-The following example describes how to map service account credentials into the application. A key called `sa-key` is stored in a volume named `provider-cloud-key`, and the application mounts this volume at `/var/secrets/provider/key.json`. The environment variable `PROVIDER_APPLICATION_CREDENTIALS` is mapped from the value of the mounted file.
-
-```yaml
-...
-    spec:
-      volumes:
-        - name: provider-cloud-key
-          secret:
-            secretName: sa-key
-      containers:
-...
-          volumeMounts:
-          - name: provider-cloud-key
-            mountPath: /var/secrets/provider
-          env:
-          - name: PROVIDER_APPLICATION_CREDENTIALS
-            value: "/var/secrets/provider/key.json"
-```
-
-The following example describes how to map secret values into application environment variables. In this example, the messaging queue topic name is mapped from a secret named `provider-queue-credentials` with a key named `topic` to the environment variable `TOPIC`.
-
-
-```yaml
-...
-          env:
-          - name: "TOPIC"
-            valueFrom:
-                secretKeyRef:
-                   name: provider-queue-credentials
-                   key: topic
-```
-
-
-
-
-## {{% heading "whatsnext" %}}
-
-* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
-* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
-* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
-
-
-
-
-

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

@@ -76,7 +76,7 @@ request headers as follows:
 
 Kubernetes implements an alternative Protobuf based serialization format that
 is primarily intended for intra-cluster communication. For more information
-about this format, see the [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) design proposal and the
+about this format, see the [Kubernetes Protobuf serialization](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) design proposal and the
 Interface Definition Language (IDL) files for each schema located in the Go
 packages that define the API objects.
 

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

@@ -8,21 +8,29 @@ card:
 ---
 
 <!-- overview -->
-This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
-
+This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can
+express them in `.yaml` format.
 
 <!-- body -->
 ## Understanding Kubernetes objects {#kubernetes-objects}
 
-*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
+*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these
+entities to represent the state of your cluster. Specifically, they can describe:
 
 * What containerized applications are running (and on which nodes)
 * The resources available to those applications
 * The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
 
-A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*.
+A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system
+will constantly work to ensure that object exists. By creating an object, you're effectively
+telling the Kubernetes system what you want your cluster's workload to look like; this is your
+cluster's *desired state*.
 
-To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/).
+To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the
+[Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line
+interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use
+the Kubernetes API directly in your own programs using one of the
+[Client Libraries](/docs/reference/using-api/client-libraries/).
 
 ### Object Spec and Status
 
@@ -48,11 +56,17 @@ the status to match your spec. If any of those instances should fail
 between spec and status by making a correction--in this case, starting
 a replacement instance.
 
-For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+For more information on the object spec, status, and metadata, see the
+[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
 
 ### Describing a Kubernetes object
 
-When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
+When you create an object in Kubernetes, you must provide the object spec that describes its
+desired state, as well as some basic information about the object (such as a name). When you use
+the Kubernetes API to create the object (either directly or via `kubectl`), that API request must
+include that information as JSON in the request body. **Most often, you provide the information to
+`kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API
+request.
 
 Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
 
@@ -81,7 +95,9 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
 * `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
 * `spec` - What state you desire for the object
 
-The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes.
+The precise format of the object `spec` is different for every Kubernetes object, and contains
+nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/)
+can help you find the spec format for all of the objects you can create using Kubernetes.
 
 For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
 for the Pod API reference.
@@ -103,5 +119,3 @@ detail the structure of that `.status` field, and its content for each different
 * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes.
 * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts.
 
-
-