Merge pull request #35372 from Seo-yul/220725-dev-1.24-ko.2-M44-M50

[ko] Update outdated files dev-1.24-ko.2 (M44-M50)

.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

@@ -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

OWNERS_ALIASES

@@ -3,6 +3,7 @@ aliases:
     - onlydole
     - mrbobbytables
     - sftim
+    - nate-double-u
   sig-docs-blog-reviewers: # Reviewers for blog content
     - mrbobbytables
     - onlydole
@@ -24,6 +25,7 @@ aliases:
     - jimangel
     - jlbutler
     - kbhawkey
+    - kcmartin
     - natalisucks
     - onlydole
     - pi-victor
@@ -179,6 +181,7 @@ aliases:
     - tanjunchen
     - tengqm
     - xichengliudui
+    - ydFu
     # zhangxiaoyu-zidif
   sig-docs-pt-owners: # Admins for Portuguese content
     - edsoncelio
@@ -249,7 +252,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-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
 
 要在容器中构建网站，请通过以下命令来构建容器镜像并运行：
 
-```
+```bash
 make container-image
 make container-serve
 ```
 
 <!--
-Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+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,6 +252,9 @@ 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。
 
 <!--
@@ -174,7 +264,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 +275,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 +300,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 +312,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 +381,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"
 
@@ -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"
@@ -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/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

@@ -61,7 +61,7 @@ Dieses [Design](https://git.k8s.io/community/contributors/design-proposals/archi
 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/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/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-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-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-05-03-kubernetes-release-1.24.md

@@ -118,6 +118,13 @@ 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
@@ -200,7 +207,7 @@ all the stargazers out there. ✨
 
 ### 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/archive/2021/kubecon-cloudnativecon-europe/).
+* 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.
 
@@ -211,7 +218,7 @@ aggregates a number of interesting data points related to the velocity of Kubern
 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-%20now&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-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All&var-repo_name=kubernetes%2Fkubernetes).
+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
 

content/en/blog/_posts/2022-05-05-volume-expansion-ga.md

@@ -49,7 +49,7 @@ Not every volume type however is expandable by default. Some volume types such a
 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)
+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.
@@ -85,7 +85,7 @@ 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
+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.
 

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/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/command-line-tools-reference/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 
@@ -654,7 +654,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

@@ -63,8 +63,8 @@ Before choosing a guide, here are some considerations:
 
 ### 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/)
+  * [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+  * [Kubelet authentication/authorization](/docs/reference/acess-authn-authz/kubelet-authn-authz/)
 
 ## Optional Cluster Services
 

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/manage-resources-containers.md

@@ -799,7 +799,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

@@ -81,7 +81,7 @@ 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.

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

@@ -100,4 +100,4 @@ UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667.
 ## {{% heading "whatsnext" %}}
 
 * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes.
-* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document.
+* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) design document.

content/en/docs/concepts/policy/limit-range.md

@@ -53,7 +53,7 @@ Neither contention nor changes to a LimitRange will affect already created resou
 
 ## {{% heading "whatsnext" %}}
 
-Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
+Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for more information.
 
 For examples on using limits, see:
 

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

@@ -22,8 +22,7 @@ be consumed by resources in that namespace.
 
 Resource quotas work like this:
 
-- Different teams work in different namespaces.  Currently this is voluntary, but
-  support for making this mandatory via ACLs is planned.
+- Different teams work in different namespaces. This can be enforced with [RBAC](/docs/reference/access-authn-authz/rbac/).
 
 - The administrator creates one ResourceQuota for each namespace.
 
@@ -698,7 +697,7 @@ and it is to be created in a namespace other than `kube-system`.
 
 ## {{% heading "whatsnext" %}}
 
-- See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
+- See [ResourceQuota design doc](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md) for more information.
 - See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
-- Read [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md).
+- Read [Quota support for priority class design doc](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md).
 - See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)

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

@@ -124,8 +124,8 @@ For example, consider the following Pod spec:
 
 In this example, the following rules apply:
 
-  * The node *must* have a label with the key `kubernetes.io/os` and
-    the value `linux`.
+  * The node *must* have a label with the key `topology.kubernetes.io/zone` and
+    the value of that label *must* be either `antarctica-east1` or `antarctica-west1`.
   * The node *preferably* has a label with the key `another-node-label-key` and
     the value `another-node-label-value`.
 
@@ -302,9 +302,8 @@ the Pod onto a node that is in the same zone as one or more Pods with the label
 `topology.kubernetes.io/zone=R` label if there are other nodes in the
 same zone currently running Pods with the `Security=S2` Pod label.
 
-See the
-[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
-for many more examples of Pod affinity and anti-affinity.
+To get yourself more familiar with the examples of Pod affinity and anti-affinity,
+refer to the [design proposal](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
 
 You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the
 `operator` field for Pod affinity and anti-affinity.
@@ -472,8 +471,8 @@ The above Pod will only run on the node `kube-01`.
 ## {{% heading "whatsnext" %}}
 
 * Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
-* Read the design docs for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
-  and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
+* Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
+  and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
 * Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
   resource allocation decisions. 
 * Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).

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

@@ -97,7 +97,7 @@ The output is:
 map[cpu:250m memory:120Mi]
 ```
 
-If a ResourceQuota is defined, the sum of container requests as well as the
+If a [ResourceQuota](/docs/concepts/policy/resource-quotas/) is defined, the sum of container requests as well as the
 `overhead` field are counted.
 
 When the kube-scheduler is deciding which node should run a new Pod, the scheduler considers that Pod's

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

@@ -3,70 +3,100 @@ reviewers:
 - bsalamat
 - k82cn
 - ahg-g
-title: Resource Bin Packing for Extended Resources
+title: Resource Bin Packing
 content_type: concept
 weight: 80
 ---
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-The kube-scheduler can be configured to enable bin packing of resources along
-with extended resources using `RequestedToCapacityRatioResourceAllocation`
-priority function. Priority functions can be used to fine-tune the
-kube-scheduler as per custom needs. 
+In the [scheduling-plugin](/docs/reference/scheduling/config/#scheduling-plugins)  `NodeResourcesFit` of kube-scheduler, there are two 
+scoring strategies that support the bin packing of resources: `MostAllocated` and `RequestedToCapacityRatio`.
 
 <!-- body -->
 
-## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
+## Enabling bin packing using MostAllocated strategy
+The `MostAllocated` strategy scores the nodes based on the utilization of resources, favoring the ones with higher allocation.
+For each resource type, you can set a weight to modify its influence in the node score.
 
-Kubernetes allows the users to specify the resources along with weights for
+To set the `MostAllocated` strategy for the `NodeResourcesFit` plugin, use a
+[scheduler configuration](/docs/reference/scheduling/config) similar to the following:
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta3
+kind: KubeSchedulerConfiguration
+profiles:
+- pluginConfig:
+  - args:
+      scoringStrategy:
+        resources:
+        - name: cpu
+          weight: 1
+        - name: memory
+          weight: 1
+        - name: intel.com/foo
+          weight: 3
+        - name: intel.com/bar
+          weight: 3
+        type: MostAllocated
+    name: NodeResourcesFit
+```
+
+To learn more about other parameters and their default configuration, see the API documentation for 
+[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs).
+
+## Enabling bin packing using RequestedToCapacityRatio
+
+The `RequestedToCapacityRatio` strategy allows the users to specify the resources along with weights for
 each resource to score nodes based on the request to capacity ratio. This
 allows users to bin pack extended resources by using appropriate parameters
-and improves the utilization of scarce resources in large clusters. The
-behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
-can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. 
-This argument consists of two parameters `shape` and `resources`. The `shape` 
+to improve the utilization of scarce resources in large clusters. It favors nodes according to a
+configured function of the allocated resources. The behavior of the `RequestedToCapacityRatio` in
+the `NodeResourcesFit` score function can be controlled by the
+[scoringStrategy](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy) field.
+Within the `scoringStrategy` field, you can configure two parameters: `requestedToCapacityRatioParam` and
+`resources`. The `shape` in `requestedToCapacityRatioParam` 
 parameter allows the user to tune the function as least requested or most 
 requested based on `utilization` and `score` values.  The `resources` parameter 
 consists of `name` of the resource to be considered during scoring and `weight` 
 specify the weight of each resource.
 
 Below is an example configuration that sets
-`requestedToCapacityRatioArguments` to bin packing behavior for extended
-resources `intel.com/foo` and `intel.com/bar`.
+the bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
+using the `requestedToCapacityRatio` field.
 
 ```yaml
 apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
-# ...
-  pluginConfig:
-  - name: RequestedToCapacityRatio
-    args: 
-      shape:
-      - utilization: 0
-        score: 10
-      - utilization: 100
-        score: 0
-      resources:
-      - name: intel.com/foo
-        weight: 3
-      - name: intel.com/bar
-        weight: 5
+- pluginConfig:
+  - args:
+      scoringStrategy:
+        resources:
+        - name: intel.com/foo
+          weight: 3
+        - name: intel.com/bar
+          weight: 3
+        requestedToCapacityRatioParam:
+          shape:
+          - utilization: 0
+            score: 0
+          - utilization: 100
+            score: 10
+        type: RequestedToCapacityRatio
+    name: NodeResourcesFit
 ```
 
 Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler 
 flag `--config=/path/to/config/file` will pass the configuration to the 
 scheduler.
 
-**This feature is disabled by default**
+To learn more about other parameters and their default configuration, see the API documentation for 
+[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs).
 
-### Tuning the Priority Function
+### Tuning the score function
 
-`shape` is used to specify the behavior of the
-`RequestedToCapacityRatioPriority` function.
+`shape` is used to specify the behavior of the `RequestedToCapacityRatio` function.
 
 ```yaml
 shape:

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

@@ -15,8 +15,7 @@ is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attrac
 a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
 hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods.
 
-_Tolerations_ are applied to pods, and allow (but do not require) the pods to schedule
-onto nodes with matching taints.
+_Tolerations_ are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also [evaluates other parameters](/docs/concepts/scheduling-eviction/pod-priority-preemption/) as part of its function.
 
 Taints and tolerations work together to ensure that pods are not scheduled
 onto inappropriate nodes. One or more taints are applied to a node; this

content/en/docs/concepts/security/controlling-access.md

@@ -4,6 +4,7 @@ reviewers:
 - lavalamp
 title: Controlling Access to the Kubernetes API
 content_type: concept
+weight: 50
 ---
 
 <!-- overview -->

content/en/docs/concepts/security/multi-tenancy.md

@@ -0,0 +1,271 @@
+---
+title: Multi-tenancy
+content_type: concept
+weight: 70
+---
+
+<!-- overview -->
+
+This page provides an overview of available configuration options and best practices for cluster multi-tenancy.
+
+Sharing clusters saves costs and simplifies administration. However, sharing clusters also presents challenges such as security, fairness, and managing _noisy neighbors_.
+
+Clusters can be shared in many ways. In some cases, different applications may run in the same cluster. In other cases, multiple instances of the same application may run in the same cluster, one for each end user. All these types of sharing are frequently described using the umbrella term _multi-tenancy_.
+
+While Kubernetes does not have first-class concepts of end users or tenants, it provides several features to help manage different tenancy requirements. These are discussed below.
+
+<!-- body -->
+## Use cases
+
+The first step to determining how to share your cluster is understanding your use case, so you can evaluate the patterns and tools available. In general, multi-tenancy in Kubernetes clusters falls into two broad categories, though many variations and hybrids are also possible.
+
+### Multiple teams 
+
+A common form of multi-tenancy is to share a cluster between multiple teams within an organization, each of whom may operate one or more workloads. These workloads frequently need to communicate with each other, and with other workloads located on the same or different clusters.
+
+In this scenario, members of the teams often have direct access to Kubernetes resources via tools such as `kubectl`, or indirect access through GitOps controllers or other types of release automation tools. There is often some level of trust between members of different teams, but Kubernetes policies such as RBAC, quotas, and network policies are essential to safely and fairly share clusters.
+
+### Multiple customers 
+
+The other major form of multi-tenancy frequently involves a Software-as-a-Service (SaaS) vendor running multiple instances of a workload for customers. This business model is so strongly associated with this deployment style that many people call it "SaaS tenancy." However, a better term might be "multi-customer tenancy,” since SaaS vendors may also use other deployment models, and this deployment model can also be used outside of SaaS.
+
+
+In this scenario, the customers do not have access to the cluster; Kubernetes is invisible from their perspective and is only used by the vendor to manage the workloads. Cost optimization is frequently a critical concern, and Kubernetes policies are used to ensure that the workloads are strongly isolated from each other.
+
+
+## Terminology
+
+### Tenants
+
+When discussing multi-tenancy in Kubernetes, there is no single definition for a "tenant". Rather, the definition of a tenant will vary depending on whether multi-team or multi-customer tenancy is being discussed.
+
+In multi-team usage, a tenant is typically a team, where each team typically deploys a small number of workloads that scales with the complexity of the service. However, the definition of "team" may itself be fuzzy, as teams may be organized into higher-level divisions or subdivided into smaller teams.
+
+
+By contrast, if each team deploys dedicated workloads for each new client, they are using a multi-customer model of tenancy. In this case, a "tenant" is simply a group of users who share a single workload. This may be as large as an entire company, or as small as a single team at that company.
+
+In many cases, the same organization may use both definitions of "tenants" in different contexts. For example, a platform team may offer shared services such as security tools and databases to multiple internal “customers” and a SaaS vendor may also have multiple teams sharing a development cluster. Finally, hybrid architectures are also possible, such as a SaaS provider using a combination of per-customer workloads for sensitive data, combined with multi-tenant shared services.
+
+
+{{< figure src="/images/docs/multi-tenancy.png" title="A cluster showing coexisting tenancy models" class="diagram-large" >}}
+
+
+### Isolation
+
+There are several ways to design and build multi-tenant solutions with Kubernetes. Each of these methods comes with its own set of tradeoffs that impact the isolation level, implementation effort, operational complexity, and cost of service. 
+
+
+A Kubernetes cluster consists of a control plane which runs Kubernetes software, and a data plane consisting of worker nodes where tenant workloads are executed as pods. Tenant isolation can be applied in both the control plane and the data plane based on organizational requirements.
+
+The level of isolation offered is sometimes described using terms like “hard” multi-tenancy, which implies strong isolation, and “soft” multi-tenancy, which implies weaker isolation. In particular, "hard" multi-tenancy is often used to describe cases where the tenants do not trust each other, often from security and resource sharing perspectives (e.g. guarding against attacks such as data exfiltration or DoS). Since data planes typically have much larger attack surfaces, "hard" multi-tenancy often requires extra attention to isolating the data-plane, though control plane isolation  also remains critical. 
+
+However, the terms "hard" and "soft" can often be confusing, as there is no single definition that will apply to all users. Rather, "hardness" or "softness" is better understood as a broad spectrum, with many different techniques that can be used to maintain different types of isolation in your clusters, based on your requirements.
+
+
+In more extreme cases, it may be easier or necessary to forgo any cluster-level sharing at all and assign each tenant their dedicated cluster, possibly even running on dedicated hardware if VMs are not considered an adequate security boundary. This may be easier with managed Kubernetes clusters, where the overhead of creating and operating clusters is at least somewhat taken on by a cloud provider. The benefit of stronger tenant isolation must be evaluated against the cost and complexity of managing multiple clusters. The [Multi-cluster SIG](https://git.k8s.io/community/sig-multicluster/README.md) is responsible for addressing these types of use cases.
+
+
+
+The remainder of this page focuses on isolation techniques used for shared Kubernetes clusters. However, even if you are considering dedicated clusters, it may be valuable to review these recommendations, as it will give you the flexibility to shift to shared clusters in the future if your needs or capabilities change.
+
+
+## Control plane isolation
+
+Control plane isolation ensures that different tenants cannot access or affect each others' Kubernetes API resources. 
+
+### Namespaces
+
+In Kubernetes, a {{< glossary_tooltip text="Namespace" term_id="namespace" >}} provides a mechanism for isolating groups of API resources within a single cluster. This isolation has two key dimensions:
+
+1. Object names within a namespace can overlap with names in other namespaces, similar to files in folders. This allows tenants to name their resources without having to consider what other tenants are doing.
+
+2. Many Kubernetes security policies are scoped to namespaces. For example, RBAC Roles and Network Policies are namespace-scoped resources. Using RBAC, Users and Service Accounts can be restricted to a namespace.
+
+In a multi-tenant environment, a Namespace helps segment a tenant's workload into a logical and distinct management unit. In fact, a common practice is to isolate every workload in its own namespace, even if multiple workloads are operated by the same tenant. This ensures that each workload has its own identity and can be configured with an appropriate security policy.
+
+The namespace isolation model requires configuration of several other Kubernetes resources, networking plugins, and adherence to security best practices to properly isolate tenant workloads. These considerations are discussed below.
+
+### Access controls
+
+The most important type of isolation for the control plane is authorization. If teams or their workloads can access or modify each others' API resources, they can change or disable all other types of policies thereby negating any protection those policies may offer. As a result, it is critical to ensure that each tenant has the appropriate access to only the namespaces they need, and no more. This is known as the "Principle of Least Privilege."
+
+
+Role-based access control (RBAC) is commonly used to enforce authorization in the Kubernetes control plane, for both users and workloads (service accounts). [Roles](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) and [role bindings](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) are Kubernetes objects that are used at a namespace level to enforce access control in your application; similar objects exist for authorizing access to cluster-level objects, though these are less useful for multi-tenant clusters.
+
+In a multi-team environment, RBAC must be used to restrict tenants' access to the appropriate namespaces, and ensure that cluster-wide resources can only be accessed or modified by privileged users such as cluster administrators. 
+
+If a policy ends up granting a user more permissions than they need, this is likely a signal that the namespace containing the affected resources should be refactored into finer-grained namespaces. Namespace management tools may simplify the management of these finer-grained namespaces by applying common RBAC policies to different namespaces, while still allowing fine-grained policies where necessary.
+
+### Quotas 
+
+Kubernetes workloads consume node resources, like CPU and memory.  In a multi-tenant environment, you can use
+[Resource Quotas](/docs/concepts/policy/resource-quotas/) to manage resource usage of tenant workloads.
+For the multiple teams use case, where tenants have access to the Kubernetes API, you can use resource quotas
+to limit the number of API resources (for example: the number of Pods, or the number of ConfigMaps)
+that a tenant can create. Limits on object count ensure fairness and aim to avoid _noisy neighbor_ issues from
+affecting other tenants that share a control plane.
+
+Resource quotas are namespaced objects. By mapping tenants to namespaces, cluster admins can use quotas to ensure that a tenant cannot monopolize a cluster's resources or overwhelm its control plane. Namespace management tools simplify the administration of quotas. In addition, while Kubernetes quotas only apply within a single namespace, some namespace management tools allow groups of namespaces to share quotas, giving administrators far more flexibility with less effort than built-in quotas.
+
+Quotas prevent a single tenant from consuming greater than their allocated share of resources hence minimizing the “noisy neighbor” issue, where one tenant negatively impacts the performance of other tenants' workloads. 
+
+When you apply a quota to namespace, Kubernetes requires you to also specify resource requests and limits for each container. Limits are the upper bound for the amount of resources that a container can consume. Containers that attempt to consume resources that exceed the configured limits will either be throttled or killed, based on the resource type. When resource requests are set lower than limits, each container is guaranteed the requested amount but there may still be some potential for impact across workloads.
+
+Quotas cannot protect against all kinds of resource sharing, such as network traffic. Node isolation (described below) may be a better solution for this problem.
+
+## Data Plane Isolation
+
+Data plane isolation ensures that pods and workloads for different tenants are sufficiently isolated.
+
+### Network isolation
+
+By default, all pods in a Kubernetes cluster are allowed to communicate with each other, and all network traffic is unencrypted. This can lead to security vulnerabilities where traffic is accidentally or maliciously sent to an unintended destination, or is intercepted by a workload on a compromised node.
+
+Pod-to-pod communication can be controlled  using [Network Policies](/docs/concepts/services-networking/network-policies/), which restrict communication between pods using namespace labels or IP address ranges. In a multi-tenant environment where strict network isolation between tenants is required,   starting with a default policy that denies communication between pods is recommended with another rule that allows all pods to query the DNS server for name resolution. With such a default policy in place, you can begin adding more permissive rules that allow for communication within a namespace. This scheme can be further refined as required. Note that this only applies to pods within a single control plane; pods that belong to different virtual control planes cannot talk to each other via Kubernetes networking.
+
+Namespace management tools may simplify the creation of default or common network policies. In addition, some of these tools allow you to enforce a consistent set of namespace labels across your cluster, ensuring that they are a trusted basis for your policies.
+
+{{< warning >}}
+Network policies require a [CNI plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni) that supports the implementation of network policies. Otherwise, NetworkPolicy resources will be ignored.
+{{< /warning >}}
+
+More advanced network isolation may be provided by service meshes, which provide OSI Layer 7 policies based on workload identity, in addition to namespaces. These higher-level policies can make it easier to manage namespace-based multi-tenancy, especially when multiple namespaces are dedicated to a single tenant. They frequently also offer encryption using mutual TLS, protecting your data even in the presence of a compromised node, and work across dedicated or virtual clusters. However, they can be significantly more complex to manage and may not be appropriate for all users.
+
+### Storage isolation
+
+Kubernetes offers several types of volumes that can be used as persistent storage for workloads. For security and data-isolation, [dynamic volume provisioning](/docs/concepts/storage/dynamic-provisioning/) is recommended and volume types that use node resources should be avoided. 
+
+[StorageClasses](/docs/concepts/storage/storage-classes/) allow you to describe custom "classes" of storage offered by your cluster, based on quality-of-service levels, backup policies, or custom policies determined by the cluster administrators. 
+
+Pods can request storage using a [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). A PersistentVolumeClaim is a namespaced resource, which enables isolating portions of the storage system and dedicating it to tenants within the shared Kubernetes cluster. However, it is important to note that a PersistentVolume is a cluster-wide resource and has a lifecycle independent of workloads and namespaces.
+
+For example, you can configure a separate StorageClass for each tenant and use this to strengthen isolation.
+If a StorageClass is shared, you should set a [reclaim policy of `Delete`](/docs/concepts/storage/storage-classes/#reclaim-policy)
+to ensure that a PersistentVolume cannot be reused across different namespaces.
+
+### Sandboxing containers
+
+{{% thirdparty-content %}}
+
+Kubernetes pods are composed of one or more containers that execute on worker nodes. Containers utilize OS-level virtualization and hence offer a weaker isolation boundary than virtual machines that utilize hardware-based virtualization.
+
+In a shared environment, unpatched vulnerabilities in the application and system layers can be exploited by attackers for container breakouts and remote code execution that allow access to host resources. In some applications, like a Content Management System (CMS), customers may be allowed the ability to upload and execute untrusted scripts or code. In either case, mechanisms to further isolate and protect workloads using strong isolation are desirable.
+
+Sandboxing provides a way to isolate workloads running in a shared cluster. It typically involves running each pod in a separate execution environment such as a virtual machine or a userspace kernel. Sandboxing is often recommended when you are running untrusted code, where workloads are assumed to be malicious. Part of the reason this type of isolation is necessary is because containers are processes running on a shared kernel; they mount file systems like /sys and /proc from the underlying host, making them less secure than an application that runs on a virtual machine which has its own kernel. While controls such as seccomp, AppArmor, and SELinux can be used to strengthen the security of containers, it is hard to apply a universal set of rules to all workloads running in a shared cluster. Running workloads in a sandbox environment helps to insulate the host from container escapes, where an attacker exploits a vulnerability to gain access to the host system and all the processes/files running on that host.
+
+Virtual machines and userspace kernels are 2 popular approaches to sandboxing. The following sandboxing implementations are available:
+* [gVisor](https://gvisor.dev/) intercepts syscalls from containers and runs them through a userspace kernel, written in Go, with limited access to the underlying host.
+* [Kata Containers](https://katacontainers.io/) is an OCI compliant runtime that allows you to run containers in a VM. The hardware virtualization available in Kata offers an added layer of security for containers running untrusted code. 
+
+### Node Isolation
+
+Node isolation is another technique that you can use to isolate tenant workloads from each other. With node isolation, a set of nodes is dedicated to running pods from a particular tenant and co-mingling of tenant pods is prohibited. This configuration reduces the noisy tenant issue, as all pods running on a node will belong to a single tenant. The risk of information disclosure is slightly lower with node isolation because an attacker that manages to escape from a container will only have access to the containers and volumes mounted to that node.
+
+Although workloads from different tenants are running on different nodes, it is important to be aware that the kubelet and (unless using virtual control planes) the API service are still shared services. A skilled attacker could use the permissions assigned to the kubelet or other pods running on the node to move laterally within the cluster and gain access to tenant workloads running on other nodes. If this is a major concern, consider implementing compensating controls such as seccomp, AppArmor or SELinux or explore using sandboxed containers or creating separate clusters for each tenant. 
+
+Node isolation is a little easier to reason about from a billing standpoint than sandboxing containers since you can charge back per node rather than per pod. It also has fewer compatibility and performance issues and may be easier to implement than sandboxing containers. For example, nodes for each tenant can be configured with taints so that only pods with the corresponding toleration can run on them. A mutating webhook could then be used to automatically add tolerations and node affinities to pods deployed into tenant namespaces so that they run on a specific set of nodes designated for that tenant.
+
+Node isolation can be implemented using an [pod node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/) or a [Virtual Kubelet](https://github.com/virtual-kubelet).
+
+## Additional Considerations
+
+This section discusses other Kubernetes constructs and patterns that are relevant for multi-tenancy.
+
+### API Priority and Fairness
+
+[API priority and fairness](/docs/concepts/cluster-administration/flow-control/) is a Kubernetes feature that allows you to assign a priority to certain pods running within the cluster. When an application calls the Kubernetes API, the API server evaluates the priority assigned to pod. Calls from pods with higher priority are fulfilled before those with a lower priority. When contention is high, lower priority calls can be queued until the server is less busy or you can reject the requests. 
+
+Using API priority and fairness will not be very common in SaaS environments unless you are allowing customers to run applications that interface with the Kubernetes API, e.g. a controller.
+
+### Quality-of-Service (QoS) {#qos}
+
+When you’re running a SaaS application, you may want the ability to offer different Quality-of-Service (QoS) tiers of service to different tenants. For example, you may have freemium service that comes with fewer performance guarantees and features and a for-fee service tier with specific performance guarantees. Fortunately, there are several Kubernetes constructs that can help you accomplish this within a shared cluster, including network QoS, storage classes, and pod priority and preemption. The idea with each of these is to provide tenants with the quality of service that they paid for. Let’s start by looking at networking QoS. 
+
+Typically, all pods on a node share a network interface. Without network QoS, some pods may consume an unfair share of the available bandwidth at the expense of other pods. The Kubernetes [bandwidth plugin](https://www.cni.dev/plugins/current/meta/bandwidth/) creates an [extended resource](/docs/concepts/configuration/manage-resources-containers/#extended-resources) for networking that allows you to use Kubernetes resources constructs, i.e. requests/limits, to apply rate limits to pods by using Linux tc queues. Be aware that the plugin is considered experimental as per the [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#support-traffic-shaping) documentation and should be thoroughly tested before use in production environments. 
+
+For storage QoS, you will likely want to create different storage classes or profiles with different performance characteristics. Each storage profile can be associated with a different tier of service that is optimized for different workloads such IO, redundancy, or throughput. Additional logic might be necessary to allow the tenant to associate the appropriate storage profile with their workload.
+
+Finally, there’s [pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) where you can assign priority values to pods. When scheduling pods, the scheduler will try evicting pods with lower priority when there are insufficient resources to schedule pods that are assigned a higher priority. If you have a use case where tenants have different service tiers in in a shared cluster e.g. free and paid, you may want to give higher priority to certain tiers using this feature.
+
+### DNS
+
+Kubernetes clusters include a Domain Name System (DNS) service to provide translations from names to IP addresses, for all Services and Pods. By default, the Kubernetes DNS service allows lookups across all namespaces in the cluster.
+
+In multi-tenant environments where tenants can access pods and other Kubernetes resources, or where
+stronger isolation is required, it may be necessary to prevent pods from looking up services in other
+Namespaces.
+You can restrict cross-namespace DNS lookups by configuring security rules for the DNS service.
+For example, CoreDNS (the default DNS service for Kubernetes) can leverage Kubernetes metadata
+to restrict queries to Pods and Services within a namespace. For more information, read an
+[example](https://github.com/coredns/policy#kubernetes-metadata-multi-tenancy-policy) of configuring
+this within the CoreDNS documentation.
+
+When a [Virtual Control Plane per tenant](#virtual-control-plane-per-tenant) model is used, a DNS service must be configured per tenant or a multi-tenant DNS service must be used. Here is an example of a [customized version of CoreDNS](https://github.com/kubernetes-sigs/cluster-api-provider-nested/blob/main/virtualcluster/doc/tenant-dns.md) that supports multiple tenants.
+
+### Operators
+
+[Operators](/docs/concepts/extend-kubernetes/operator/) are Kubernetes controllers that manage applications. Operators can simplify the management of multiple instances of an application, like a database service, which makes them a common building block in the multi-consumer (SaaS) multi-tenancy use case.  
+
+Operators used in a multi-tenant environment should follow a stricter set of guidelines. Specifically, the Operator should: 
+* Support creating resources within different tenant namespaces, rather than just in the namespace in which the Operator is deployed.
+* Ensure that the Pods are configured with resource requests and limits, to ensure scheduling and fairness.  
+* Support configuration of Pods for data-plane isolation techniques such as node isolation and sandboxed containers.
+
+## Implementations
+
+{{% thirdparty-content %}}
+
+There are two primary ways to share a Kubernetes cluster for multi-tenancy: using Namespaces (i.e. a Namespace per tenant) or by virtualizing the control plane (i.e. Virtual control plane per tenant).
+
+In both cases, data plane isolation, and management of additional considerations such as API Priority and Fairness, is also recommended. 
+
+Namespace isolation is well-supported by Kubernetes, has a negligible resource cost, and provides mechanisms to allow tenants to interact appropriately, such as by allowing service-to-service communication. However, it can be difficult to configure, and doesn't apply to Kubernetes resources that can't be namespaced, such as Custom Resource Definitions, Storage Classes, and Webhooks.
+
+Control plane virtualization allows for isolation of non-namespaced resources at the cost of somewhat higher resource usage and more difficult cross-tenant sharing. It is a good option when namespace isolation is insufficient but dedicated clusters are undesirable, due to the high cost of maintaining them (especially on-prem) or due to their higher overhead and lack of resource sharing. However, even within a virtualized control plane, you will likely see benefits by using namespaces as well.
+
+The two options are discussed in more detail in the following sections:
+
+### Namespace per tenant
+
+As previously mentioned, you should consider isolating each workload in its own namespace, even if you are using dedicated clusters or virtualized control planes. This ensures that each workload only has access to its own resources, such as Config Maps and Secrets, and allows you to tailor dedicated security policies for each workload. In addition, it is a best practice to give each namespace names that are unique across your entire fleet (i.e., even if they are in separate clusters), as this gives you the flexibility to switch between dedicated and shared clusters in the future, or to use multi-cluster tooling such as service meshes.
+
+Conversely, there are also advantages to assigning namespaces at the tenant level, not just the workload level, since there are often policies that apply to all workloads owned by a single tenant. However, this raises its own problems. Firstly, this makes it difficult or impossible to customize policies to individual workloads, and secondly, it may be challenging to come up with a single level of "tenancy" that should be given a namespace. For example, an organization may have divisions, teams, and subteams - which should be assigned a namespace?
+
+To solve this, Kubernetes provides the [Hierarchical Namespace Controller (HNC)](https://github.com/kubernetes-sigs/hierarchical-namespaces), which allows you to organize your namespaces into hierarchies, and share certain policies and resources between them. It also helps you manage namespace labels, namespace lifecycles, and delegated management, and share resource quotas across related namespaces. These capabilities can be useful in both multi-team and multi-customer scenarios.
+
+Other projects that provide similar capabilities and aid in managing namespaced resources are listed below:
+
+#### Multi-team tenancy
+
+* [Capsule](https://github.com/clastix/capsule)
+* [Kiosk](https://github.com/loft-sh/kiosk)
+
+#### Multi-customer tenancy
+
+* [Kubeplus](https://github.com/cloud-ark/kubeplus)
+
+#### Policy engines
+
+Policy engines provide features to validate and generate tenant configurations:
+
+* [Kyverno](https://kyverno.io/)
+* [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper)
+
+### Virtual control plane per tenant
+
+Another form of control-plane isolation is to use Kubernetes extensions to provide each tenant a virtual control-plane that enables segmentation of cluster-wide API resources. [Data plane isolation](#data-plane-isolation) techniques can be used with this model to securely manage worker nodes across tenants.
+
+The virtual control plane based multi-tenancy model extends namespace-based multi-tenancy by providing each tenant with dedicated control plane components, and hence complete control over cluster-wide resources and add-on services. Worker nodes are shared across all tenants, and are managed by a Kubernetes cluster that is normally inaccessible to tenants. This cluster is often referred to as a _super-cluster_ (or sometimes as a _host-cluster_). Since a tenant’s control-plane is not directly associated with underlying compute resources it is referred to as a _virtual control plane_.
+
+A virtual control plane typically consists of the Kubernetes API server, the controller manager, and the etcd data store. It interacts with the super cluster via a metadata synchronization controller which coordinates changes across tenant control planes and the control plane of the super--cluster. 
+
+By using per-tenant dedicated control planes, most of the isolation problems due to sharing one API server among all tenants are solved. Examples include noisy neighbors in the control plane, uncontrollable blast radius of policy misconfigurations, and conflicts between cluster scope objects such as webhooks and CRDs.  Hence, the virtual control plane model is particularly suitable for cases where each tenant requires access to a Kubernetes API server and expects the full cluster manageability. 
+
+The improved isolation comes at the  cost of running and maintaining an individual virtual control plane per tenant. In addition, per-tenant control planes do not solve isolation problems in the data plane, such as node-level noisy neighbors or security threats. These must still be addressed separately.
+
+The Kubernetes [Cluster API - Nested (CAPN)](https://github.com/kubernetes-sigs/cluster-api-provider-nested/tree/main/virtualcluster) project provides an implementation of virtual control planes. 
+
+#### Other implementations
+* [Kamaji](https://github.com/clastix/kamaji)
+* [vcluster](https://github.com/loft-sh/vcluster)
+

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

@@ -37,8 +37,8 @@ To use this mechanism, your cluster must enforce Pod Security admission.
 
 ### Built-in Pod Security admission enforcement
 
-In Kubernetes v{{< skew currentVersion >}}, the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-is a beta feature and is enabled by default. You must have this feature gate enabled.
+From Kubernetes v1.23, the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is a beta feature and is enabled by default.
+This page is part of the documentation for Kubernetes v{{< skew currentVersion >}}.
 If you are running a different version of Kubernetes, consult the documentation for that release.
 
 ### Alternative: installing the `PodSecurity` admission webhook {#webhook}
@@ -102,7 +102,7 @@ For each mode, there are two labels that determine the policy used:
 pod-security.kubernetes.io/<MODE>: <LEVEL>
 
 # Optional: per-mode version label that can be used to pin the policy to the
-# version that shipped with a given Kubernetes minor version (for example v{{< skew latestVersion >}}).
+# version that shipped with a given Kubernetes minor version (for example v{{< skew currentVersion >}}).
 #
 # MODE must be one of `enforce`, `audit`, or `warn`.
 # VERSION must be a valid Kubernetes minor version, or `latest`.

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

@@ -29,10 +29,9 @@ This guide outlines the requirements of each policy.
 **The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is
 typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
 
-The Privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
-mechanisms (such as gatekeeper), the Privileged policy may be an absence of applied constraints
-rather than an instantiated profile. In contrast, for a deny-by-default mechanism (such as Pod
-Security Policy) the Privileged policy should enable all controls (disable all restrictions).
+The Privileged policy is defined by an absence of restrictions. Allow-by-default
+mechanisms (such as gatekeeper) may be Privileged by default. In contrast, for a deny-by-default mechanism (such as Pod
+Security Policy) the Privileged policy should disable all restrictions.
 
 ### Baseline
 
@@ -58,7 +57,7 @@ fail validation.
 		<tr>
 			<td style="white-space: nowrap">HostProcess</td>
 			<td>
-				<p>Windows pods offer the ability to run <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess containers</a> which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. HostProcess pods are an <strong>alpha</strong> feature as of Kubernetes <strong>v1.22</strong>.</p>
+				<p>Windows pods offer the ability to run <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess containers</a> which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. {{< feature-state for_k8s_version="v1.23" state="beta" >}}</p>
 				<p><strong>Restricted Fields</strong></p>
 				<ul>
 					<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
@@ -458,6 +457,16 @@ of individual policies are not defined here.
 - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
 - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
 
+### Alternatives
+
+{{% thirdparty-content %}}
+
+Other alternatives for enforcing policies are being developed in the Kubernetes ecosystem, such as: 
+- [Kubewarden](https://github.com/kubewarden)
+- [Kyverno](https://kyverno.io/policies/pod-security/)
+- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)
+
+
 ## FAQ
 
 ### Why isn't there a profile between privileged and baseline?
@@ -481,14 +490,6 @@ as well as other related parameters outside the Security Context. As of July 202
 [Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the
 built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/). 
 
-{{% thirdparty-content %}}
-
-Other alternatives for enforcing security profiles are being developed in the Kubernetes
-ecosystem, such as: 
-- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
-- [Kubewarden](https://github.com/kubewarden).
-- [Kyverno](https://kyverno.io/policies/pod-security/).
-
 ### What profiles should I apply to my Windows Pods?
 
 Windows in Kubernetes has some limitations and differentiators from standard Linux-based