Merge remote-tracking branch 'upstream/main' into dev-1.25

2022-06-23 18:39:26 +01:00
parent fdc9cc8041 60390ff3c0
commit d1847d5a4d
1825 changed files with 63412 additions and 33035 deletions
@@ -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.
@@ -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
@@ -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 \
@@ -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.
+# no build lock to allow for read-only mounts
-	$(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
+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
@@ -3,6 +3,7 @@ aliases:
    - onlydole
    - mrbobbytables
    - sftim
    - nate-double-u
  sig-docs-blog-reviewers: # Reviewers for blog content
    - mrbobbytables
    - onlydole
@@ -24,8 +25,8 @@ aliases:
    - jimangel
    - jlbutler
    - kbhawkey
    - kcmartin
    - natalisucks
    - nate-double-u # RT 1.24 Docs Lead
    - onlydole
    - pi-victor
    - reylejano
@@ -128,6 +129,7 @@ aliases:
    # MasayaAoyama
    - nasa9084
    # oke-py
    - ptux
  sig-docs-ko-owners: # Admins for Korean content
    - ClaudiaJKang
    - gochist
@@ -179,6 +181,7 @@ aliases:
    - tanjunchen
    - tengqm
    - xichengliudui
    - ydFu
    # zhangxiaoyu-zidif
  sig-docs-pt-owners: # Admins for Portuguese content
    - edsoncelio
@@ -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:
@@ -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,7 +64,7 @@ The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/doc
 Kubernetes 网站使用的是 [Docsy Hugo 主题](https://github.com/google/docsy#readme)。 即使你打算在容器中运行网站，我们也强烈建议你通过运行以下命令来引入子模块和其他开发依赖项：
-```
+```bash
 # pull in the Docsy submodule
 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 会更新网站并强制浏览器执行刷新操作。
 <!--
@@ -104,18 +119,84 @@ 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/)
+- [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
-* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
+- [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
-* [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
+- [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
-* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
+- [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
 -->
 有关为 Kubernetes 文档做出贡献的更多信息，请参阅：
-* [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/)
+- [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/)
-* [页面内容类型](https://kubernetes.io/docs/contribute/style/page-content-types/)
+- [页面内容类型](https://kubernetes.io/docs/contribute/style/page-content-types/)
-* [文档风格指南](https://kubernetes.io/docs/contribute/style/style-guide/)
+- [文档风格指南](https://kubernetes.io/docs/contribute/style/style-guide/)
-* [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
+- [本地化 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 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！
@@ -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
@@ -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 {
@@ -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'.
+  # a branch like 'main' or 'release-0.2', or a tag like 'v0.2'.
-  _PULL_BASE_REF: "master"
+  _PULL_BASE_REF: "main"
@@ -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"
+languageName = "Português (Portuguese)"
-weight = 9
+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"
+languageName = "हिन्दी (Hindi)"
-weight = 11
+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 = "Русский"
+languageName = "Русский (Russian)"
-weight = 12
+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"
+languageName = "Polski (Polish)"
-weight = 13
+languageNameLatinScript = "Polski"
 weight = 15
 contentDir = "content/pl"
 languagedirection = "ltr"
@@ -478,8 +493,9 @@ language_alternatives = ["en"]
 [languages.uk]
 title = "Kubernetes"
 description = "Довершена система оркестрації контейнерів"
-languageName = "Українська"
+languageName = "Українська (Ukrainian)"
-weight = 14
+languageNameLatinScript = "Ukrainian"
 weight = 16
 contentDir = "content/uk"
 languagedirection = "ltr"
@@ -1,4 +1,4 @@
 ---
-title: "Kubernets erweitern"
+title: "Kubernetes erweitern"
 weight: 110
 ---
@@ -1,6 +1,6 @@
 ---
 content_type: concept
-title: Zur Kubernets-Dokumentation beitragen
+title: Zur Kubernetes-Dokumentation beitragen
 linktitle: Mitmachen
 main_menu: true
 weight: 80
@@ -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 >}}
@@ -1,5 +1,6 @@
 ---
 title: "Jobs ausführen"
 description: Führen Sie Jobs mit paralleler Verarbeitung aus.
 weight: 50
 ---
@@ -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">
@@ -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.
@@ -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
@@ -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:
@@ -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:  
@@ -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. &nbsp;In fact, we like containers so much that even our Google Compute Engine VMs run in containers! &nbsp;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.
@@ -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!  
 &nbsp;- David Aronchick, Senior Product Manager for Kubernetes and Google Container Engine
@@ -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)&nbsp;
+* “Kubernetes Documentation: Contributing, fixing issues, collecting bounties” by John Mulhausen, Lead Technical Writer, Google [https://sched.co/6BUP](http://sched.co/6BUP)&nbsp;
 * “[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 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)
+* “[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)
-* “[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/
+* “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  
@@ -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.&nbsp;
-### What’s new:&nbsp;
+## 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**.&nbsp;
+- **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.&nbsp;
  - 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.&nbsp;
@@ -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).&nbsp;
-#### Community&nbsp;
+## 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).&nbsp;
+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&nbsp;
+## 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.&nbsp;
+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&nbsp;
+## 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):&nbsp;
@@ -64,7 +67,7 @@ Kubernetes 1.2 is available for download at [get.k8s.io](http://get.k8s.io/) and
-#### Connect&nbsp;
+## Connect
 We’d love to hear from you and see you participate in this growing community:&nbsp;
@@ -73,8 +76,7 @@ We’d love to hear from you and see you participate in this growing community:&
 - &nbsp;Connect with the community on [Slack](http://slack.kubernetes.io/)&nbsp;
 - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates&nbsp;
-Thank you for your support!&nbsp;
+Thank you for your support!
 &nbsp;-&nbsp;_David Aronchick, Senior Product Manager for Kubernetes, Google_
@@ -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)).&nbsp;
+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)).&nbsp;
@@ -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.&nbsp;  
 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/)&nbsp;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!&nbsp;
+Thank you for your support!
 -- Aparna Sinha, Product Manager, Google
@@ -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.
@@ -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_
@@ -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)._
@@ -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.&nbsp;[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.&nbsp;[~Register here~](https://zoom.us/webinar/register/WN_oVjQMwyzQFOmWsfVzDsa2A).  
 ## Get involved:
@@ -1,13 +1,9 @@
 ---
-title: 'Kubernetes 1.10: Stabilizing Storage, Security, and Networking '
+title: 'Kubernetes 1.10: Stabilizing Storage, Security, and Networking'
 author: kbarnard
 tags:
 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
@@ -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)
@@ -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)
@@ -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)
+[Bob Killen][bob] (University of Michigan), [Sahdev Zala][sahdev] (IBM), [Ihor Dvoretskyi][ihor] (CNCF)
 [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:
+### Docs sprint
-SIG-Docs will have a curated list of issues and challenges to be tackled closer
+
 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.
@@ -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)
@@ -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)
@@ -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 ;) )...  
+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  
+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
@@ -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)
@@ -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._
@@ -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)
@@ -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
+In record time, we’ve hit capacity for the *new contributor workshop* session of
-*new contributor workshop* session of the event! Waitlist is now available.
+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
@@ -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)
 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])
 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,
@@ -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!
@@ -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!
@@ -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.
@@ -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. 
@@ -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?
@@ -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.
@@ -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
@@ -5,8 +5,6 @@ date: 2022-05-03
 slug: kubernetes-1-24-release-announcement
 ---
 # Kubernetes 1.24
 **Authors**: [Kubernetes 1.24 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.24/release-team.md)
 We are excited to announce the release of Kubernetes 1.24, the first release of 2022!
@@ -120,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
@@ -202,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.
@@ -213,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
@@ -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.
@@ -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
 ---
@@ -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.
@@ -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.
@@ -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).
@@ -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).
@@ -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!
@@ -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.
@@ -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&mdash;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)
@@ -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)
@@ -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>
@@ -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 -->
+     https://github.com/cncf/foundation/blob/main/code-of-conduct.md -->
-## CNCF Community Code of Conduct v1.0
+## 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
+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,
 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
+This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
-* Personal attacks
+
-* Trolling or insulting/derogatory comments
+### 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,
+* Publishing others' private information, such as a physical or email
- without explicit permission
+  address, without their explicit permission
-* Other unethical or unprofessional conduct.
+* Other conduct which could reasonably be considered inappropriate in a
  professional setting
-Project maintainers have the right and responsibility to remove, edit, or reject
+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.
-comments, commits, code, wiki edits, issues, and other contributions that are not
+By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect
-aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
+of managing this project.
-commit themselves to fairly and consistently applying these principles to every aspect
+Project maintainers who do not follow or enforce the Code of
 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
+## Reporting
 when an individual is representing the project or its community.
-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
+(http://contributor-covenant.org), version 2.0 available at
-https://contributor-covenant.org/version/1/2/0/
+http://contributor-covenant.org/version/2/0/code_of_conduct/
 ### 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.
@@ -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**
@@ -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>
@@ -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.
+Nodes should be provisioned with the public root certificate for the cluster such that they can
-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.
+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.
+Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this
-This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running.
+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.
+As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the
-After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.
+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.
@@ -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/).
@@ -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/)
+  * [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
-  * [Kubelet authentication/authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
+  * [Kubelet authentication/authorization](/docs/reference/acess-authn-authz/kubelet-authn-authz/)
 ## Optional Cluster Services
@@ -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
+* [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.
+* [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
@@ -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.
@@ -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/).
@@ -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).
@@ -279,5 +279,6 @@ to the deleted ConfigMap, it is recommended to recreate these pods.
 * Read about [Secrets](/docs/concepts/configuration/secret/).
 * Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
 * Read about [changing a ConfigMap (or any other Kubernetes object)](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
 * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
  separating code from configuration.
@@ -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
 ```
@@ -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
+service account name. If you are creating both the ServiceAccount and
-{{< glossary_tooltip text="controller" term_id="controller" >}} fills in some
+the Secret objects, you should create the ServiceAccount object first.
-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
+After the Secret is created, a Kubernetes {{< glossary_tooltip text="controller" term_id="controller" >}}
-token.
+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
+After creating the Secret, wait for Kubernetes to populate the `token` key in the `data` field.
 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.
 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);
@@ -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
+## CPU management {#resource-management-cpu}
 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.
-{{< note >}}
+Windows can limit the amount of CPU time allocated for different processes but cannot
-When you set memory resource limits for Windows containers, you should either set a
+guarantee a minimum amount of CPU time.
 limit and leave the memory request unspecified, or set the request equal to the limit.
 {{< /note >}}
-On Windows, good practice to avoid over-provisioning is to configure the kubelet
+On Windows, the kubelet supports a command-line flag to set the
-with a system reserved memory of at least 2GiB to account for Windows, Kubernetes
+[scheduling priority](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities) of the
 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
 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.
@@ -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
@@ -160,7 +160,7 @@ After a request is authorized, if it is a write operation, it also goes through
 ### Storage Plugins
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
+[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.
@@ -191,7 +191,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.
@@ -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" >}}.
@@ -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
+{{< note >}}
-* `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`.
+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.
+### Support hostPort
 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
 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" %}}
@@ -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)
@@ -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.
@@ -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.
@@ -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:
@@ -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
+- Different teams work in different namespaces. This can be enforced with [RBAC](/docs/reference/access-authn-authz/rbac/).
  support for making this mandatory via ACLs is planned.
 - 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)
@@ -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
+To get yourself more familiar with the examples of Pod affinity and anti-affinity,
-[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
+refer to the [design proposal](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
 for many more examples of Pod affinity and anti-affinity.
 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)
+* 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/community/contributors/design-proposals/scheduling/podaffinity.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/).
@@ -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
@@ -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" >}}
+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`.
 The kube-scheduler can be configured to enable bin packing of resources along
 with extended resources using `RequestedToCapacityRatioResourceAllocation`
 priority function. Priority functions can be used to fine-tune the
 kube-scheduler as per custom needs. 
 <!-- body -->
-## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
+## 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
+to improve the utilization of scarce resources in large clusters. It favors nodes according to a
-behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
+configured function of the allocated resources. The behavior of the `RequestedToCapacityRatio` in
-can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. 
+the `NodeResourcesFit` score function can be controlled by the
-This argument consists of two parameters `shape` and `resources`. The `shape` 
+[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
+the bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
-resources `intel.com/foo` and `intel.com/bar`.
+using the `requestedToCapacityRatio` field.
 ```yaml
 apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
-# ...
+- pluginConfig:
-  pluginConfig:
+  - args:
-  - name: RequestedToCapacityRatio
+      scoringStrategy:
-    args: 
+        resources:
-      shape:
+        - name: intel.com/foo
-      - utilization: 0
+          weight: 3
-        score: 10
+        - name: intel.com/bar
-      - utilization: 100
+          weight: 3
-        score: 0
+        requestedToCapacityRatioParam:
-      resources:
+          shape:
-      - name: intel.com/foo
+          - utilization: 0
-        weight: 3
+            score: 0
-      - name: intel.com/bar
+          - utilization: 100
-        weight: 5
+            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
+`shape` is used to specify the behavior of the `RequestedToCapacityRatio` function.
 `RequestedToCapacityRatioPriority` function.
 ```yaml
 shape:
@@ -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
+_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](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) as part of its function.
 onto nodes with matching taints.
 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
@@ -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/)
+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.
-is a beta feature and is enabled by default. You must have this feature gate enabled.
+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`.
@@ -658,7 +658,7 @@ added. Capabilities listed in `RequiredDropCapabilities` must not be included in
 **DefaultAddCapabilities** - The capabilities which are added to containers by
 default, in addition to the runtime defaults. See the
-the documentation for your container runtime for information on working with Linux capabilities.
+documentation for your container runtime for information on working with Linux capabilities.
 ### SELinux
@@ -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
+The Privileged policy is defined by an absence of restrictions. Allow-by-default
-mechanisms (such as gatekeeper), the Privileged policy may be an absence of applied constraints
+mechanisms (such as gatekeeper) may be Privileged by default. In contrast, for a deny-by-default mechanism (such as Pod
-rather than an instantiated profile. In contrast, for a deny-by-default mechanism (such as Pod
+Security Policy) the Privileged policy should disable all restrictions.
 Security Policy) the Privileged policy should enable all controls (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
@@ -0,0 +1,179 @@
 ---
 reviewers:
 title: Role Based Access Control Good Practices
 description: >
  Principles and practices for good RBAC design for cluster operators.
 content_type: concept
 ---
 <!-- overview -->
 Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control 
 to ensure that cluster users and workloads have only the access to resources required to 
 execute their roles. It is important to ensure that, when designing permissions for cluster
 users, the cluster administrator understands the areas where privilge escalation could occur, 
 to reduce the risk of excessive access leading to security incidents.
 The good practices laid out here should be read in conjunction with the general [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update).
 <!-- body -->
 ## General good practice
 ### Least privilege
 Ideally minimal RBAC rights should be assigned to users and service accounts. Only permissions 
 explicitly required for their operation should be used. Whilst each cluster will be different, 
 some general rules that can be applied are :
 - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to 
   ClusterRoleBindings to give users rights only within a specific namespace.
 - Avoid providing wildcard permissions when possible, especially to all resources.
   As Kubernetes is an extensible system, providing wildcard access gives rights
   not just to all object types presently in the cluster, but also to all future object types
   which are created in the future.
 - Administrators should not use `cluster-admin` accounts except where specifically needed. 
   Providing a low privileged account with [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation)
   can avoid accidental modification of cluster resources.
 - Avoid adding users to the `system:masters` group. Any user who is a member of this group 
   bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be 
   revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is 
   using an authorization webhook, membership of this group also bypasses that webhook (requests 
   from users who are members of that group are never sent to the webhook)
 ### Minimize distribution of privileged tokens
 Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions (for example, any of the rights listed under
 [privilege escalation risks](#privilege-escalation-risks)). 
 In cases where a workload requires powerful permissions, consider the following practices:
 - Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run
  are necessary and are run with least privilege to limit the blast radius of container escapes.
 - Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using 
   [Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/), [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), or [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) to ensure 
   pods don't run alongside untrusted or less-trusted Pods. Pay especial attention to
   situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard.
 ### Hardening
 Kubernetes defaults to providing access which may not be required in every cluster. Reviewing 
 the RBAC rights provided by default can provide opportunities for security hardening.
 In general, changes should not be made to rights provided to `system:` accounts some options 
 to harden cluster rights exist:
 - Review bindings for the `system:unauthenticated` group and remove where possible, as this gives 
  access to anyone who can contact the API server at a network level.
 - Avoid the default auto-mounting of service account tokens by setting
  `automountServiceAccountToken: false`. For more details, see
  [using default service account token](/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server).
  Setting this value for a Pod will overwrite the service account setting, workloads
  which require service account tokens can still mount them.
 ### Periodic review
 It is vital to periodically review the Kubernetes RBAC settings for redundant entries and 
 possible privilege escalations.
 If an attacker is able to create a user account with the same name as a deleted user,
 they can automatically inherit all the rights of the deleted user, especially the
 rights assigned to that user.
 ## Kubernetes RBAC - privilege escalation risks {#privilege-escalation-risks}
 Within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account
 to escalate their privileges in the cluster or affect systems outside the cluster.
 This section is intended to provide visibility of the areas where cluster operators 
 should take care, to ensure that they do not inadvertently allow for more access to clusters than intended.
 ### Listing secrets
 It is generally clear that allowing `get` access on Secrets will allow a user to read their contents.
 It is also important to note that `list` and `watch` access also effectively allow for users to reveal the Secret contents.
 For example, when a List response is returned (for example, via `kubectl get secrets -A -o yaml`), the response
 includes the contents of all Secrets.
 ### Workload creation
 Users who are able to create workloads (either Pods, or
 [workload resources](/docs/concepts/workloads/controllers/) that manage Pods) will
 be able to gain access to the underlying node unless restrictions based on the Kubernetes
 [Pod Security Standards](/docs/concepts/security/pod-security-standards/) are in place.
 Users who can run privileged Pods can use that access to gain node access and potentially to
 further elevate their privileges. Where you do not fully trust a user or other principal
 with the ability to create suitably secure and isolated Pods, you should enforce either the
 **Baseline** or **Restricted** Pod Security Standard.
 You can use [Pod Security admission](/docs/concepts/security/pod-security-admission/)
 or other (third party) mechanisms to implement that enforcement.
 You can also use the deprecated [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) mechanism
 to restrict users' abilities to create privileged Pods (N.B. PodSecurityPolicy is scheduled for removal
 in version 1.25).
 Creating a workload in a namespace also grants indirect access to Secrets in that namespace. 
 Creating a pod in kube-system or a similarly privileged namespace can grant a user access to 
 Secrets they would not have through RBAC directly.
 ### Persistent volume creation
 As noted in the [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) documentation, access to create PersistentVolumes can allow for escalation of access to the underlying host. Where access to persistent storage is required trusted administrators should create 
 PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.
 ### Access to `proxy` subresource of Nodes
 Users with access to the proxy sub-resource of node objects have rights to the Kubelet API, 
 which allows for command execution on every pod on the node(s) which they have rights to. 
 This access bypasses audit logging and admission control, so care should be taken before 
 granting rights to this resource.
 ### Escalate verb
 Generally the RBAC system prevents users from creating clusterroles with more rights than 
 they possess. The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update),
 users with this right can effectively escalate their privileges.
 ### Bind verb
 Similar to the `escalate` verb, granting users this right allows for bypass of Kubernetes 
 in-built protections against privilege escalation, allowing users to create bindings to 
 roles with rights they do not already have.
 ### Impersonate verb
 This verb allows users to impersonate and gain the rights of other users in the cluster. 
 Care should be taken when granting it, to ensure that excessive permissions cannot be gained 
 via one of the impersonated accounts.
 ### CSRs and certificate issuing
 The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval` 
 where the signer is `kubernetes.io/kube-apiserver-client` to create new client certificates 
 which allow users to authenticate to the cluster. Those client certificates can have arbitrary 
 names including duplicates of Kubernetes system components. This will effectively allow for privilege escalation.
 ### Token request
 Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue 
 tokens for existing service accounts. 
 ### Control admission webhooks
 Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` 
 can control webhooks that can read any object admitted to the cluster, and in the case of 
 mutating webhooks, also mutate admitted objects.
 ## Kubernetes RBAC - denial of service risks {#denial-of-service-risks}
 ### Object creation denial-of-service {#object-creation-dos}
 Users who have rights to create objects in a cluster may be able to create sufficient large 
 objects to create a denial of service condition either based on the size or number of objects, as discussed in
 [etcd used by Kubernetes is vulnerable to OOM attack](https://github.com/kubernetes/kubernetes/issues/107325). This may be
 specifically relevant in multi-tenant clusters if semi-trusted or untrusted users 
 are allowed limited access to a system.
 One option for mitigation of this issue would be to use [resource quotas](/docs/concepts/policy/resource-quotas/#object-count-quota)
 to limit the quantity of objects which can be created.
 ## {{% heading "whatsnext" %}}
 * To learn more about RBAC, see the [RBAC documentation](/docs/reference/access-authn-authz/rbac/).
@@ -51,5 +51,5 @@ Windows containers can also run as Active Directory identities by utilizing [Gro
 Linux-specific pod security context mechanisms (such as SELinux, AppArmor, Seccomp, or custom
 POSIX capabilities) are not supported on Windows nodes.
-Privileged containers are [not supported](#compatibility-v1-pod-spec-containers-securitycontext) on Windows.
+Privileged containers are [not supported](/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext) on Windows.
 Instead [HostProcess containers](/docs/tasks/configure-pod-container/create-hostprocess-pod) can be used on Windows to perform many of the tasks performed by privileged containers on Linux.
@@ -7,26 +7,25 @@ description: >
 ## The Kubernetes network model
-Every [`Pod`](/docs/concepts/workloads/pods/) gets its own IP address. 
+Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address. 
 This means you do not need to explicitly create links between `Pods` and you 
 almost never need to deal with mapping container ports to host ports.  
 This creates a clean, backwards-compatible model where `Pods` can be treated 
 much like VMs or physical hosts from the perspectives of port allocation, 
-naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), application configuration, 
+naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), 
-and migration.
+application configuration, and migration.
 Kubernetes imposes the following fundamental requirements on any networking
 implementation (barring any intentional network segmentation policies):
-   * pods on a [node](/docs/concepts/architecture/nodes/) can communicate with all pods on all nodes without NAT
+   * pods can communicate with all other pods on any other [node](/docs/concepts/architecture/nodes/) 
     without NAT
   * agents on a node (e.g. system daemons, kubelet) can communicate with all
     pods on that node
 Note: For those platforms that support `Pods` running in the host network (e.g.
-Linux):
+Linux), when pods are attached to the host network of a node they can still communicate 
-
+with all pods on all nodes without NAT.
   * pods in the host network of a node can communicate with all pods on all
     nodes without NAT
 This model is not only less complex overall, but it is principally compatible
 with the desire for Kubernetes to enable low-friction porting of apps from VMs
@@ -8,8 +8,8 @@ weight: 20
 ---
 <!-- overview -->
-Kubernetes creates DNS records for services and pods. You can contact
+Kubernetes creates DNS records for Services and Pods. You can contact
-services with consistent DNS names instead of IP addresses. 
+Services with consistent DNS names instead of IP addresses. 
 <!-- body -->
@@ -25,20 +25,20 @@ Pod's own namespace and the cluster's default domain.
 ### Namespaces of Services 
-A DNS query may return different results based on the namespace of the pod making 
+A DNS query may return different results based on the namespace of the Pod making 
-it. DNS queries that don't specify a namespace are limited to the pod's 
+it. DNS queries that don't specify a namespace are limited to the Pod's 
-namespace. Access services in other namespaces by specifying it in the DNS query. 
+namespace. Access Services in other namespaces by specifying it in the DNS query. 
-For example, consider a pod in a `test` namespace. A `data` service is in 
+For example, consider a Pod in a `test` namespace. A `data` Service is in 
 the `prod` namespace. 
-A query for `data` returns no results, because it uses the pod's `test` namespace. 
+A query for `data` returns no results, because it uses the Pod's `test` namespace. 
 A query for `data.prod` returns the intended result, because it specifies the 
 namespace. 
-DNS queries may be expanded using the pod's `/etc/resolv.conf`. Kubelet 
+DNS queries may be expanded using the Pod's `/etc/resolv.conf`. Kubelet 
-sets this file for each pod. For example, a query for just `data` may be 
+sets this file for each Pod. For example, a query for just `data` may be 
 expanded to `data.test.svc.cluster.local`. The values of the `search` option 
 are used to expand queries. To learn more about DNS queries, see 
 [the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) 
@@ -49,7 +49,7 @@ search <namespace>.svc.cluster.local svc.cluster.local cluster.local
 options ndots:5
 ```
-In summary, a pod in the _test_ namespace can successfully resolve either 
+In summary, a Pod in the _test_ namespace can successfully resolve either 
 `data.prod` or `data.prod.svc.cluster.local`.
 ### DNS Records
@@ -70,14 +70,14 @@ For more up-to-date specification, see
 ### A/AAAA records
 "Normal" (not headless) Services are assigned a DNS A or AAAA record,
-depending on the IP family of the service, for a name of the form
+depending on the IP family of the Service, for a name of the form
 `my-svc.my-namespace.svc.cluster-domain.example`.  This resolves to the cluster IP
 of the Service.
 "Headless" (without a cluster IP) Services are also assigned a DNS A or AAAA record,
-depending on the IP family of the service, for a name of the form
+depending on the IP family of the Service, for a name of the form
 `my-svc.my-namespace.svc.cluster-domain.example`.  Unlike normal
-Services, this resolves to the set of IPs of the pods selected by the Service.
+Services, this resolves to the set of IPs of the Pods selected by the Service.
 Clients are expected to consume the set or else use standard round-robin
 selection from the set.
@@ -87,36 +87,36 @@ SRV Records are created for named ports that are part of normal or [Headless
 Services](/docs/concepts/services-networking/service/#headless-services).
 For each named port, the SRV record would have the form
 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
-For a regular service, this resolves to the port number and the domain name:
+For a regular Service, this resolves to the port number and the domain name:
 `my-svc.my-namespace.svc.cluster-domain.example`.
-For a headless service, this resolves to multiple answers, one for each pod
+For a headless Service, this resolves to multiple answers, one for each Pod
-that is backing the service, and contains the port number and the domain name of the pod
+that is backing the Service, and contains the port number and the domain name of the Pod
 of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
 ## Pods
 ### A/AAAA records
-In general a pod has the following DNS resolution:
+In general a Pod has the following DNS resolution:
 `pod-ip-address.my-namespace.pod.cluster-domain.example`.
-For example, if a pod in the `default` namespace has the IP address 172.17.0.3,
+For example, if a Pod in the `default` namespace has the IP address 172.17.0.3,
 and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name:
 `172-17-0-3.default.pod.cluster.local`.
-Any pods exposed by a Service have the following DNS resolution available:
+Any Pods exposed by a Service have the following DNS resolution available:
 `pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`.
 ### Pod's hostname and subdomain fields
-Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
+Currently when a Pod is created, its hostname is the Pod's `metadata.name` value.
 The Pod spec has an optional `hostname` field, which can be used to specify the
 Pod's hostname. When specified, it takes precedence over the Pod's name to be
-the hostname of the pod. For example, given a Pod with `hostname` set to
+the hostname of the Pod. For example, given a Pod with `hostname` set to
 "`my-host`", the Pod will have its hostname set to "`my-host`".
 The Pod spec also has an optional `subdomain` field which can be used to specify
@@ -173,14 +173,14 @@ spec:
    name: busybox
 ```
-If there exists a headless service in the same namespace as the pod and with
+If there exists a headless Service in the same namespace as the Pod and with
 the same name as the subdomain, the cluster's DNS Server also returns an A or AAAA
 record for the Pod's fully qualified hostname.
 For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to
 "`default-subdomain`", and a headless Service named "`default-subdomain`" in
-the same namespace, the pod will see its own FQDN as
+the same namespace, the Pod will see its own FQDN as
 "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an
-A or AAAA record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
+A or AAAA record at that name, pointing to the Pod's IP. Both Pods "`busybox1`" and
 "`busybox2`" can have their distinct A or AAAA records.
 The Endpoints object can specify the `hostname` for any endpoint addresses,
@@ -189,7 +189,7 @@ along with its IP.
 {{< note >}}
 Because A or AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
 record to be created. A Pod with no `hostname` but with `subdomain` will only create the
-A or AAAA record for the headless service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
+A or AAAA record for the headless Service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
 pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a
 record unless `publishNotReadyAddresses=True` is set on the Service.
 {{< /note >}}
@@ -205,17 +205,17 @@ When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the P
 {{< note >}}
 In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
-If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
+If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
 {{< /note >}}
 ### Pod's DNS Policy
-DNS policies can be set on a per-pod basis. Currently Kubernetes supports the
+DNS policies can be set on a per-Pod basis. Currently Kubernetes supports the
-following pod-specific DNS policies. These policies are specified in the
+following Pod-specific DNS policies. These policies are specified in the
 `dnsPolicy` field of a Pod Spec.
 - "`Default`": The Pod inherits the name resolution configuration from the node
-  that the pods run on.
+  that the Pods run on.
  See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
  for more details.
 - "`ClusterFirst`": Any DNS query that does not match the configured cluster
@@ -226,6 +226,7 @@ following pod-specific DNS policies. These policies are specified in the
  for details on how DNS queries are handled in those cases.
 - "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should
  explicitly set its DNS policy "`ClusterFirstWithHostNet`".
  - Note: This is not supported on Windows. See [below](#dns-windows) for details
 - "`None`": It allows a Pod to ignore DNS settings from the Kubernetes
  environment. All DNS settings are supposed to be provided using the
  `dnsConfig` field in the Pod Spec.
@@ -306,7 +307,7 @@ For IPv6 setup, search path and name server should be setup like this:
 kubectl exec -it dns-example -- cat /etc/resolv.conf
 ```
 The output is similar to this:
-```shell
+```
 nameserver fd00:79:30::a
 search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
 options ndots:5
@@ -323,8 +324,25 @@ If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and
 the kubelet, it is allowed for Kubernetes to have at most 32 search domains and
 a list of search domains of up to 2048 characters.
-## {{% heading "whatsnext" %}}
+## DNS resolution on Windows nodes {#dns-windows}
 - ClusterFirstWithHostNet is not supported for Pods that run on Windows nodes.
  Windows treats all names with a `.` as a FQDN and skips FQDN resolution.
 - On Windows, there are multiple DNS resolvers that can be used. As these come with
  slightly different behaviors, using the
  [`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
  powershell cmdlet for name query resolutions is recommended.
 - On Linux, you have a DNS suffix list, which is used after resolution of a name as fully
  qualified has failed.
  On Windows, you can only have 1 DNS suffix, which is the DNS suffix associated with that
  Pod's namespace (example: `mydns.svc.cluster.local`). Windows can resolve FQDNs, Services,
  or network name which can be resolved with this single suffix. For example, a Pod spawned
  in the `default` namespace, will have the DNS suffix `default.svc.cluster.local`.
  Inside a Windows Pod, you can resolve both `kubernetes.default.svc.cluster.local`
  and `kubernetes`, but not the partially qualified names (`kubernetes.default` or
  `kubernetes.default.svc`).
 ## {{% heading "whatsnext" %}}
 For guidance on administering DNS configurations, check
 [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
@@ -1,16 +1,15 @@
 ---
 reviewers:
 - lachie83
 - khenidak
 - aramase
 - bridgetkromhout
 title: IPv4/IPv6 dual-stack
 feature:
  title: IPv4/IPv6 dual-stack
  description: >
    Allocation of IPv4 and IPv6 addresses to Pods and Services
 content_type: concept
 reviewers:
  - lachie83
  - khenidak
  - aramase
  - bridgetkromhout
 weight: 70
 ---
@@ -18,11 +17,11 @@ weight: 70
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
-IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}.
+IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to
-
+{{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}.
 IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in 1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses.
 IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in
 1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses.
 <!-- body -->
@@ -30,68 +29,78 @@ IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluste
 IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features:
-   * Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod)
+* Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod)
-   * IPv4 and IPv6 enabled Services
+* IPv4 and IPv6 enabled Services
-   * Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces
+* Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces
 ## Prerequisites
 The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack Kubernetes clusters:
-   * Kubernetes 1.20 or later  
+* Kubernetes 1.20 or later  
-     For information about using dual-stack services with earlier
+
-     Kubernetes versions, refer to the documentation for that version
+  For information about using dual-stack services with earlier
-     of Kubernetes.
+  Kubernetes versions, refer to the documentation for that version
-   * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
+  of Kubernetes.
-   * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack networking.
+
 * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide
  Kubernetes nodes with routable IPv4/IPv6 network interfaces)
 * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that
  supports dual-stack networking.
 ## Configure IPv4/IPv6 dual-stack
 To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments:
-   * kube-apiserver:
+* kube-apiserver:
-      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
+  * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
-   * kube-controller-manager:
+* kube-controller-manager:
-      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
+  * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
-      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
+  * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
-      * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6
+  * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6
-   * kube-proxy:
+* kube-proxy:
-      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
+  * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
-   * kubelet:
+* kubelet:
-      * when there is no `--cloud-provider` the administrator can pass a comma-separated pair
+  * when there is no `--cloud-provider` the administrator can pass a comma-separated pair of IP
-        of IP addresses via `--node-ip` to manually configure dual-stack `.status.addresses`
+    addresses via `--node-ip` to manually configure dual-stack `.status.addresses` for that Node.
-        for that Node.
+    If a Pod runs on that node in HostNetwork mode, the Pod reports these IP addresses in its
-        If a Pod runs on that node in HostNetwork mode, the Pod reports these IP addresses in its
+    `.status.podIPs` field.
-        `.status.podIPs` field.
+    All `podIPs` in a node match the IP family preference defined by the `.status.addresses`
-        All `podIPs` in a node match the IP family preference defined by the
+    field for that Node.
        `.status.addresses` field for that Node.
 {{< note >}}
 An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own address range)
-An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193))
+An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid
-
+address - see [RFC 4193](https://tools.ietf.org/html/rfc4193))
 {{< /note >}}
 ## Services
 You can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both.
-The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver).
+The address family of a Service defaults to the address family of the first service cluster IP
 range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver).
 When you define a Service you can optionally configure it as dual stack. To specify the behavior you want, you
 set the `.spec.ipFamilyPolicy` field to one of the following values:
-* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range.
+* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service,
  using the first configured service cluster IP range.
 * `PreferDualStack`:
  * Allocates IPv4 and IPv6 cluster IPs for the Service.
 * `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges.
-  * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array.
+  * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family
    of the first element in the `.spec.ipFamilies` array.
-If you would like to define which IP family to use for single stack or define the order of IP families for dual-stack, you can choose the address families by setting an optional field, `.spec.ipFamilies`, on the Service. 
+If you would like to define which IP family to use for single stack or define the order of IP
 families for dual-stack, you can choose the address families by setting an optional field,
 `.spec.ipFamilies`, on the Service. 
 {{< note >}}
-The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the Service.
+The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a
 Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the
 Service.
 {{< /note >}}
 You can set `.spec.ipFamilies` to any of the following array values:
@@ -109,139 +118,197 @@ These examples demonstrate the behavior of various dual-stack Service configurat
 #### Dual-stack options on new Services
-1. This Service specification does not explicitly define `.spec.ipFamilyPolicy`. When you create this Service, Kubernetes assigns a cluster IP for the Service from the first configured `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors will behave in this same way.)
+1. This Service specification does not explicitly define `.spec.ipFamilyPolicy`. When you create
   this Service, Kubernetes assigns a cluster IP for the Service from the first configured
   `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services
   without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and
   [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors
   will behave in this same way.)
-{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+   {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
-1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 addresses for the service. The control plane updates the `.spec` for the Service to record the IP address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from `.spec.ClusterIPs`.
+1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When
   you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6
   addresses for the service. The control plane updates the `.spec` for the Service to record the IP
   address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned
   IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from
   `.spec.ClusterIPs`.
-      * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the same address family as the first service cluster IP range. 
+   * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the
-      * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list one address. 
+     same address family as the first service cluster IP range. 
-      * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` behaves the same as `PreferDualStack`.
+   * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list
     one address. 
   * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy`
     behaves the same as `PreferDualStack`.
-{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
+   {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
-1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is the first element in the `.spec.ClusterIPs` array, overriding the default.
+1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well
   as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and
   IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is
   the first element in the `.spec.ClusterIPs` array, overriding the default.
-{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}
+   {{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}
 #### Dual-stack defaults on existing Services
-These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. (Upgrading an existing cluster to 1.21 or beyond will enable dual-stack.)
+These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster
 where Services already exist. (Upgrading an existing cluster to 1.21 or beyond will enable
 dual-stack.)
-1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP will be stored in `.spec.ClusterIPs`.
+1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are
   configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set
   `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP
   will be stored in `.spec.ClusterIPs`.
-{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+   {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
   You can validate this behavior by using kubectl to inspect an existing service.
-```shell
+   ```shell
-kubectl get svc my-service -o yaml
+   kubectl get svc my-service -o yaml
-```
+   ```
-```yaml
+   ```yaml
-apiVersion: v1
+   apiVersion: v1
-kind: Service
+   kind: Service
-metadata:
+   metadata:
-  labels:
+     labels:
-    app: MyApp
+       app: MyApp
-  name: my-service
+     name: my-service
-spec:
+   spec:
-  clusterIP: 10.0.197.123
+     clusterIP: 10.0.197.123
-  clusterIPs:
+     clusterIPs:
-  - 10.0.197.123
+     - 10.0.197.123
-  ipFamilies:
+     ipFamilies:
-  - IPv4
+     - IPv4
-  ipFamilyPolicy: SingleStack
+     ipFamilyPolicy: SingleStack
-  ports:
+     ports:
-  - port: 80
+     - port: 80
-    protocol: TCP
+       protocol: TCP
-    targetPort: 80
+       targetPort: 80
-  selector:
+     selector:
-    app: MyApp
+       app: MyApp
-  type: ClusterIP
+     type: ClusterIP
-status:
+   status:
-  loadBalancer: {}
+     loadBalancer: {}
-```
+   ```
-1. When dual-stack is enabled on a cluster, existing [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.ClusterIP` is set to `None`.
+1. When dual-stack is enabled on a cluster, existing
   [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are
   configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set
   `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the
   `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.ClusterIP` is set to
   `None`.
-{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+   {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
   You can validate this behavior by using kubectl to inspect an existing headless service with selectors.
-```shell
+   ```shell
-kubectl get svc my-service -o yaml
+   kubectl get svc my-service -o yaml
-```
+   ```
-```yaml
+   ```yaml
-apiVersion: v1
+   apiVersion: v1
-kind: Service
+   kind: Service
-metadata:
+   metadata:
-  labels:
+     labels:
-    app: MyApp
+       app: MyApp
-  name: my-service
+     name: my-service
-spec:
+   spec:
-  clusterIP: None
+     clusterIP: None
-  clusterIPs:
+     clusterIPs:
-  - None
+     - None
-  ipFamilies:
+     ipFamilies:
-  - IPv4
+     - IPv4
-  ipFamilyPolicy: SingleStack
+     ipFamilyPolicy: SingleStack
-  ports:
+     ports:
-  - port: 80
+     - port: 80
-    protocol: TCP
+       protocol: TCP
-    targetPort: 80
+       targetPort: 80
-  selector:
+     selector:
-    app: MyApp
+       app: MyApp
-```
+   ```
 #### Switching Services between single-stack and dual-stack
 Services can be changed from single-stack to dual-stack and from dual-stack to single-stack.
-1. To change a Service from single-stack to dual-stack, change `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack` or `RequireDualStack` as desired. When you change this Service from single-stack to dual-stack, Kubernetes assigns the missing address family so that the Service now has IPv4 and IPv6 addresses.
+1. To change a Service from single-stack to dual-stack, change `.spec.ipFamilyPolicy` from
   `SingleStack` to `PreferDualStack` or `RequireDualStack` as desired. When you change this
   Service from single-stack to dual-stack, Kubernetes assigns the missing address family so that the
   Service now has IPv4 and IPv6 addresses.
   Edit the Service specification updating the `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack`.
-Before:
+   Before:
 ```yaml
 spec:
  ipFamilyPolicy: SingleStack
 ```
 After:
 ```yaml
 spec:
  ipFamilyPolicy: PreferDualStack
 ```
-1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs` array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address family of `.spec.ClusterIPs`.
+   ```yaml
   spec:
     ipFamilyPolicy: SingleStack
   ```
   After:
   ```yaml
   spec:
     ipFamilyPolicy: PreferDualStack
   ```
 1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from
   `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from
   dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs`
   array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address
   family of `.spec.ClusterIPs`.
 ### Headless Services without selector
-For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors) and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to `RequireDualStack`.
+For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors)
 and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to
 `RequireDualStack`.
 ### Service type LoadBalancer
 To provision a dual-stack load balancer for your Service:
-   * Set the `.spec.type` field to `LoadBalancer`
+
-   * Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack`
+* Set the `.spec.type` field to `LoadBalancer`
 * Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack`
 {{< note >}}
-To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6 load balancers.
+To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6
 load balancers.
 {{< /note >}}
 ## Egress traffic
-If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project supports IP masquerading on dual-stack clusters.
+If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public
 Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to
 use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP
 masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project
 supports IP masquerading on dual-stack clusters.
 {{< note >}}
 Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports IPv6.
 {{< /note >}}
 ## Windows support
 Kubernetes on Windows does not support single-stack "IPv6-only" networking. However,
 dual-stack IPv4/IPv6 networking for pods and nodes with single-family services
 is supported.
 You can use IPv4/IPv6 dual-stack networking with `l2bridge` networks.
 {{< note >}}
 Overlay (VXLAN) networks on Windows **do not** support dual-stack networking.
 {{< /note >}}
 You can read more about the different network modes for Windows within the
 [Networking on Windows](/docs/concepts/services-networking/windows-networking#network-modes) topic.
 ## {{% heading "whatsnext" %}}
 * [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
-* [Enable dual-stack networking using kubeadm
+* [Enable dual-stack networking using kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
-](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)
+
@@ -30,23 +30,8 @@ For clarity, this guide defines the following terms:
 Traffic routing is controlled by rules defined on the Ingress resource.
 Here is a simple example where an Ingress sends all its traffic to one Service:
 {{< mermaid >}}
 graph LR;
  client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress];
  ingress-->|routing rule|service[Service];
  subgraph cluster
  ingress;
  service-->pod1[Pod];
  service-->pod2[Pod];
  end
  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
  class ingress,service,pod1,pod2 k8s;
  class client plain;
  class cluster cluster;
 {{</ mermaid >}}
 {{< figure src="/docs/images/ingress.svg" alt="ingress-diagram" class="diagram-large" caption="Figure. Ingress" link="https://mermaid.live/edit#pako:eNqNkstuwyAQRX8F4U0r2VHqPlSRKqt0UamLqlnaWWAYJygYLB59KMm_Fxcix-qmGwbuXA7DwAEzzQETXKutof0Ovb4vaoUQkwKUu6pi3FwXM_QSHGBt0VFFt8DRU2OWSGrKUUMlVQwMmhVLEV1Vcm9-aUksiuXRaO_CEhkv4WjBfAgG1TrGaLa-iaUw6a0DcwGI-WgOsF7zm-pN881fvRx1UDzeiFq7ghb1kgqFWiElyTjnuXVG74FkbdumefEpuNuRu_4rZ1pqQ7L5fL6YQPaPNiFuywcG9_-ihNyUkm6YSONWkjVNM8WUIyaeOJLO3clTB_KhL8NQDmVe-OJjxgZM5FhFiiFTK5zjDkxHBQ9_4zB4a-x20EGNSZhyaKmXrg7f5hSsvufUwTMXThtMWiot5Jh6p9ffimHijIezaSVoeN0uiqcfMJvf7w" >}}
 An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
@@ -398,25 +383,8 @@ A fanout configuration routes traffic from a single IP address to more than one
 based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers
 down to a minimum. For example, a setup like:
-{{< mermaid >}}
+{{< figure src="/docs/images/ingressFanOut.svg" alt="ingress-fanout-diagram" class="diagram-large" caption="Figure. Ingress Fan Out" link="https://mermaid.live/edit#pako:eNqNUslOwzAQ_RXLvYCUhMQpUFzUUzkgcUBwbHpw4klr4diR7bCo8O8k2FFbFomLPZq3jP00O1xpDpjijWHtFt09zAuFUCUFKHey8vf6NE7QrdoYsDZumGIb4Oi6NAskNeOoZJKpCgxK4oXwrFVgRyi7nCVXWZKRPMlysv5yD6Q4Xryf1Vq_WzDPooJs9egLNDbolKTpT03JzKgh3zWEztJZ0Niu9L-qZGcdmAMfj4cxvWmreba613z9C0B-AMQD-V_AdA-A4j5QZu0SatRKJhSqhZR0wjmPrDP6CeikrutQxy-Cuy2dtq9RpaU2dJKm6fzI5Glmg0VOLio4_5dLjx27hFSC015KJ2VZHtuQvY2fuHcaE43G0MaCREOow_FV5cMxHZ5-oPX75UM5avuXhXuOI9yAaZjg_aLuBl6B3RYaKDDtSw4166QrcKE-emrXcubghgunDaY1kxYizDqnH99UhakzHYykpWD9hjS--fEJoIELqQ" >}}
-graph LR;
+
  client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress, 178.91.123.132];
  ingress-->|/foo|service1[Service service1:4200];
  ingress-->|/bar|service2[Service service2:8080];
  subgraph cluster
  ingress;
  service1-->pod1[Pod];
  service1-->pod2[Pod];
  service2-->pod3[Pod];
  service2-->pod4[Pod];
  end
  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
  class client plain;
  class cluster cluster;
 {{</ mermaid >}}
 would require an Ingress such as:
@@ -460,25 +428,7 @@ you are using, you may need to create a default-http-backend
 Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
-{{< mermaid >}}
+{{< figure src="/docs/images/ingressNameBased.svg" alt="ingress-namebase-diagram" class="diagram-large" caption="Figure. Ingress Name Based Virtual hosting" link="https://mermaid.live/edit#pako:eNqNkl9PwyAUxb8KYS-atM1Kp05m9qSJJj4Y97jugcLtRqTQAPVPdN_dVlq3qUt8gZt7zvkBN7xjbgRgiteW1Rt0_zjLNUJcSdD-ZBn21WmcoDu9tuBcXDHN1iDQVWHnSBkmUMEU0xwsSuK5DK5l745QejFNLtMkJVmSZmT1Re9NcTz_uDXOU1QakxTMJtxUHw7ss-SQLhehQEODTsdH4l20Q-zFyc84-Y67pghv5apxHuweMuj9eS2_NiJdPhix-kMgvwQShOyYMNkJoEUYM3PuGkpUKyY1KqVSdCSEiJy35gnoqCzLvo5fpPAbOqlfI26UsXQ0Ho9nB5CnqesRGTnncPYvSqsdUvqp9KRdlI6KojjEkB0mnLgjDRONhqENBYm6oXbLV5V1y6S7-l42_LowlIN2uFm_twqOcAW2YlK0H_i9c-bYb6CCHNO2FFCyRvkc53rbWptaMA83QnpjMS2ZchBh1nizeNMcU28bGEzXkrV_pArN7Sc0rBTu" >}}
 graph LR;
  client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress, 178.91.123.132];
  ingress-->|Host: foo.bar.com|service1[Service service1:80];
  ingress-->|Host: bar.foo.com|service2[Service service2:80];
  subgraph cluster
  ingress;
  service1-->pod1[Pod];
  service1-->pod2[Pod];
  service2-->pod3[Pod];
  service2-->pod4[Pod];
  end
  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
  class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s;
  class client plain;
  class cluster cluster;
 {{</ mermaid >}}
 The following Ingress tells the backing load balancer to route requests based on
@@ -54,7 +54,7 @@ POSTing this to the API server for your cluster will have no effect unless your
 __Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy
 needs `apiVersion`, `kind`, and `metadata` fields.  For general information
 about working with config files, see
-[Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+[Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
 and [Object Management](/docs/concepts/overview/working-with-objects/object-management).
 __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace.
@@ -258,7 +258,7 @@ standardized label to target a specific namespace.
 ## What you can't do with network policies (at least, not yet)
-As of Kubernetes {{< skew latestVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.
+As of Kubernetes {{< skew currentVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.
 - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy).
 - Anything TLS related (use a service mesh or ingress controller for this).
@@ -60,12 +60,6 @@ considered.
 When the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `ServiceInternalTrafficPolicy` is enabled, `spec.internalTrafficPolicy` defaults to "Cluster".
 ## Constraints
 * Service Internal Traffic Policy is not used when `externalTrafficPolicy` is set
  to `Local` on a Service. It is possible to use both features in the same cluster
  on different Services, just not on the same Service.
 ## {{% heading "whatsnext" %}}
 * Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints)
@@ -122,7 +122,7 @@ metadata:
 spec:
  containers:
  - name: nginx
-    image: nginx:11.14.2
+    image: nginx:stable
    ports:
      - containerPort: 80
        name: http-web-svc
@@ -192,6 +192,7 @@ where it's running, by adding an Endpoints object manually:
 apiVersion: v1
 kind: Endpoints
 metadata:
  # the name here should match the name of the Service
  name: my-service
 subsets:
  - addresses:
@@ -203,6 +204,10 @@ subsets:
 The name of the Endpoints object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 When you create an [Endpoints](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
 object for a Service, you set the name of the new object to be the same as that
 of the Service.
 {{< note >}}
 The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or
 link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6).
@@ -394,6 +399,10 @@ You can also set the maximum session sticky time by setting
 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately.
 (the default value is 10800, which works out to be 3 hours).
 {{< note >}}
 On Windows, setting the maximum session sticky time for Services is not supported.
 {{< /note >}}
 ## Multi-Port Services
 For some Services, you need to expose more than one port.
@@ -447,7 +456,7 @@ server will return a 422 HTTP status code to indicate that there's a problem.
 You can set the `spec.externalTrafficPolicy` field to control how traffic from external sources is routed.
 Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route external traffic to all ready endpoints
-and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are are no node-local
+and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local
 endpoints, the kube-proxy does not forward any traffic for the relevant Service.
 {{< note >}}
@@ -853,6 +862,17 @@ metadata:
 [...]
 ```
 {{% /tab %}}
 {{% tab name="OCI" %}}
 ```yaml
 [...]
 metadata:
    name: my-service
    annotations:
        service.beta.kubernetes.io/oci-load-balancer-internal: true
 [...]
 ```
 {{% /tab %}}
 {{< /tabs >}}
@@ -0,0 +1,164 @@
 ---
 reviewers:
 - aravindhp
 - jayunit100
 - jsturtevant
 - marosset
 title: Networking on Windows
 content_type: concept
 weight: 75
 ---
 <!-- overview -->
 Kubernetes supports running nodes on either Linux or Windows. You can mix both kinds of node
 within a single cluster.
 This page provides an overview to networking specific to the Windows operating system.
 <!-- body -->
 ## Container networking on Windows {#networking}
 Networking for Windows containers is exposed through
 [CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
 Windows containers function similarly to virtual machines in regards to
 networking. Each container has a virtual network adapter (vNIC) which is connected
 to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the
 Host Compute Service (HCS) work together to create containers and attach container
 vNICs to networks. HCS is responsible for the management of containers whereas HNS
 is responsible for the management of networking resources such as:
 * Virtual networks (including creation of vSwitches)
 * Endpoints / vNICs
 * Namespaces
 * Policies including packet encapsulations, load-balancing rules, ACLs, and NAT rules.
 The Windows HNS and vSwitch implement namespacing and can
 create virtual NICs as needed for a pod or container. However, many configurations such
 as DNS, routes, and metrics are stored in the Windows registry database rather than as
 files inside `/etc`, which is how Linux stores those configurations. The Windows registry for the container
 is separate from that of the host, so concepts like mapping `/etc/resolv.conf` from
 the host into a container don't have the same effect they would on Linux. These must
 be configured using Windows APIs run in the context of that container. Therefore
 CNI implementations need to call the HNS instead of relying on file mappings to pass
 network details into the pod or container.
 ## Network modes
 Windows supports five different networking drivers/modes: L2bridge, L2tunnel,
 Overlay (Beta), Transparent, and NAT. In a heterogeneous cluster with Windows and Linux
 worker nodes, you need to select a networking solution that is compatible on both
 Windows and Linux. The following table lists the out-of-tree plugins are supported on Windows,
 with recommendations on when to use each CNI:
 | Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics |
 | -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
 | L2bridge       | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. | MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS OutboundNAT policy. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. |
 | L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/azure/aks/concepts-network#azure-cni-advanced-networking) |
 | Overlay | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags)  if you are restricted on IPs in your datacenter.  This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. |
 | Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.  <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. |
 | NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://techcommunity.microsoft.com/t5/virtualization/windows-nat-winnat-capabilities-and-limitations/ba-p/382303) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
 As outlined above, the [Flannel](https://github.com/coreos/flannel)
 [CNI plugin](https://github.com/flannel-io/cni-plugin)
 is also [supported](https://github.com/flannel-io/cni-plugin#windows-support-experimental) on Windows via the
 [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**Beta support** ; delegates to win-overlay)
 and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge).
 This plugin supports delegating to one of the reference CNI plugins (win-overlay,
 win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for
 automatic node subnet lease assignment and HNS network creation. This plugin reads
 in its own configuration file (cni.conf), and aggregates it with the environment
 variables from the FlannelD generated subnet.env file. It then delegates to one of
 the reference CNI plugins for network plumbing, and sends the correct configuration
 containing the node-assigned subnet to the IPAM plugin (for example: `host-local`).
 For Node, Pod, and Service objects, the following network flows are supported for
 TCP/UDP traffic:
 * Pod → Pod (IP)
 * Pod → Pod (Name)
 * Pod → Service (Cluster IP)
 * Pod → Service (PQDN, but only if there are no ".")
 * Pod → Service (FQDN)
 * Pod → external (IP)
 * Pod → external (DNS)
 * Node → Pod
 * Pod → Node
 ## IP address management (IPAM) {#ipam}
 The following IPAM options are supported on Windows:
 * [host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
 * [azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only)
 * [Windows Server IPAM](https://docs.microsoft.com/windows-server/networking/technologies/ipam/ipam-top) (fallback option if no IPAM is set)
 ## Load balancing and Services
 A Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}} is an abstraction
 that defines a logical set of Pods and a means to access them over a network.
 In a cluster that includes Windows nodes, you can use the following types of Service:
 * `NodePort`
 * `ClusterIP`
 * `LoadBalancer`
 * `ExternalName`
 Windows container networking differs in some important ways from Linux networking.
 The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)
 provides additional details and background.
 On Windows, you can use the following settings to configure Services and load
 balancing behavior:
 {{< table caption="Windows Service Settings" >}}
 | Feature | Description | Minimum Supported Windows OS build | How to enable |
 | ------- | ----------- | -------------------------- | ------------- |
 | Session affinity | Ensures that connections from a particular client are passed to the same Pod each time. | Windows Server 2022 | Set `service.spec.sessionAffinity` to "ClientIP" |
 | Direct Server Return (DSR) | Load balancing mode where the IP address fixups and the LBNAT occurs at the container vSwitch port directly; service traffic arrives with the source IP set as the originating pod IP. | Windows Server 2019 | Set the following flags in kube-proxy: `--feature-gates="WinDSR=true" --enable-dsr=true` |
 | Preserve-Destination | Skips DNAT of service traffic, thereby preserving the virtual IP of the target service in packets reaching the backend Pod. Also disables node-node forwarding. | Windows Server, version 1903 | Set `"preserve-destination": "true"` in service annotations and enable DSR in kube-proxy. |
 | IPv4/IPv6 dual-stack networking | Native IPv4-to-IPv4 in parallel with IPv6-to-IPv6 communications to, from, and within a cluster | Windows Server 2019 | See [IPv4/IPv6 dual-stack](#ipv4ipv6-dual-stack) |
 | Client IP preservation | Ensures that source IP of incoming ingress traffic gets preserved. Also disables node-node forwarding. |  Windows Server 2019  | Set `service.spec.externalTrafficPolicy` to "Local" and enable DSR in kube-proxy |
 {{< /table >}}
 {{< warning >}}
 There are known issue with NodePort Services on overlay networking, if the destination node is running Windows Server 2022.
 To avoid the issue entirely, you can configure the service with `externalTrafficPolicy: Local`.
 There are known issues with Pod to Pod connectivity on l2bridge network on Windows Server 2022 with KB5005619 or higher installed.
 To workaround the issue and restore Pod to Pod connectivity, you can disable the WinDSR feature in kube-proxy.
 These issues require OS fixes.
 Please follow https://github.com/microsoft/Windows-Containers/issues/204 for updates.
 {{< /warning >}}
 ## Limitations
 The following networking functionality is _not_ supported on Windows nodes:
 * Host networking mode
 * Local NodePort access from the node itself (works for other nodes or external clients)
 * More than 64 backend pods (or unique destination addresses) for a single Service
 * IPv6 communication between Windows pods connected to overlay networks
 * Local Traffic Policy in non-DSR mode
 * Outbound communication using the ICMP protocol via the `win-overlay`, `win-bridge`, or using the Azure-CNI plugin.\
  Specifically, the Windows data plane ([VFP](https://www.microsoft.com/research/project/azure-virtual-filtering-platform/))
  doesn't support ICMP packet transpositions, and this means:
  * ICMP packets directed to destinations within the same network (such as pod to pod communication via ping) 
    work as expected;
  * TCP/UDP packets work as expected;
  * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) 
    cannot be transposed and thus will not be routed back to their source;
  * Since TCP/UDP packets can still be transposed, you can substitute `ping <destination>` with
    `curl <destination>` when debugging connectivity with the outside world.
 Other limitations:
 * Windows reference network plugins win-bridge and win-overlay do not implement
  [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0,
  due to a missing `CHECK` implementation.
 * The Flannel VXLAN CNI plugin has the following limitations on Windows:
  * Node-pod connectivity is only possible for local pods with Flannel v0.12.0 (or higher).
  * Flannel is restricted to using VNI 4096 and UDP port 4789. See the official
    [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)
    backend docs for more details on these parameters.
--- a/Show More
+++ b/Show More
		`@@ -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.`
`@@ -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)).