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

Merge main into dev-1.25 branch: July 21st
Merge remote-tracking branch 'upstream/main' into dev-1.25
2022-07-27 09:30:29 -07:00 · 2022-07-21 13:48:12 -07:00 · 2022-07-21 11:01:55 -07:00 · 2022-07-21 10:23:54 -07:00 · 2022-07-21 08:39:55 -07:00 · 2022-07-21 04:35:54 -07:00
198 changed files with 18737 additions and 3497 deletions
@@ -9,7 +9,7 @@ CONTAINER_ENGINE ?= docker
 IMAGE_REGISTRY ?= gcr.io/k8s-staging-sig-docs
 IMAGE_VERSION=$(shell scripts/hash-files.sh Dockerfile Makefile | cut -c 1-12)
 CONTAINER_IMAGE   = $(IMAGE_REGISTRY)/k8s-website-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION)
-CONTAINER_RUN     = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src
+CONTAINER_RUN     = "$(CONTAINER_ENGINE)" run --rm --interactive --tty --volume "$(CURDIR):/src"

 CCRED=\033[0;31m
 CCEND=\033[0m
@@ -95,7 +95,7 @@ docker-internal-linkcheck:

 container-internal-linkcheck: link-checker-image-pull
 	$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test
-	$(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest
+	$(CONTAINER_ENGINE) run --mount "type=bind,source=$(CURDIR),target=/test" --rm wjdp/htmltest htmltest

 clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md
 	rm -rf content/en/docs/reference/kubernetes-api/*/
@@ -200,6 +200,7 @@ aliases:
    - devlware
    - jhonmike
    - rikatz
+    - stormqueen1990
    - yagonobre
  sig-docs-vi-owners: # Admins for Vietnamese content
    - huynguyennovem
@@ -80,7 +80,7 @@ To build the site in a container, run the following to build the container image
 要在容器中构建网站，请通过以下命令来构建容器镜像并运行：

 ```bash
-make container-image
+# 你可以将 $CONTAINER_ENGINE 设置为任何 Docker 类容器工具的名称
 make container-serve
 ```

@@ -257,6 +257,51 @@ This works for Catalina as well as Mojave macOS.
 -->
 这适用于 Catalina 和 Mojave macOS。

+### 对执行 make container-image 命令部分地区访问超时的故障排除
+
+现象如下：
+
+```shell
+langs/language.go:23:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+langs/language.go:24:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+common/text/transform.go:21:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+common/text/transform.go:22:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+common/text/transform.go:23:2: golang.org/x/text@v0.3.7: Get "https://proxy.golang.org/golang.org/x/text/@v/v0.3.7.zip": dial tcp 142.251.43.17:443: i/o timeout
+hugolib/integrationtest_builder.go:29:2: golang.org/x/tools@v0.1.11: Get "https://proxy.golang.org/golang.org/x/tools/@v/v0.1.11.zip": dial tcp 142.251.42.241:443: i/o timeout
+deploy/google.go:24:2: google.golang.org/api@v0.76.0: Get "https://proxy.golang.org/google.golang.org/api/@v/v0.76.0.zip": dial tcp 142.251.43.17:443: i/o timeout
+parser/metadecoders/decoder.go:32:2: gopkg.in/yaml.v2@v2.4.0: Get "https://proxy.golang.org/gopkg.in/yaml.v2/@v/v2.4.0.zip": dial tcp 142.251.42.241:443: i/o timeout
+The command '/bin/sh -c mkdir $HOME/src &&     cd $HOME/src &&     curl -L https://github.com/gohugoio/hugo/archive/refs/tags/v${HUGO_VERSION}.tar.gz | tar -xz &&     cd "hugo-${HUGO_VERS    ION}" &&     go install --tags extended' returned a non-zero code: 1
+make: *** [Makefile:69：container-image] error 1
+```
+
+请修改 `Dockerfile` 文件，为其添加网络代理。修改内容如下：
+
+```dockerfile
+...
+FROM golang:1.18-alpine
+
+LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"
+
+ENV GO111MODULE=on                            # 需要添加内容1
+
+ENV GOPROXY=https://proxy.golang.org,direct   # 需要添加内容2
+
+RUN apk add --no-cache \
+    curl \
+    gcc \
+    g++ \
+    musl-dev \
+    build-base \
+    libc6-compat
+
+ARG HUGO_VERSION
+...
+```
+
+将 "https://proxy.golang.org" 替换为本地可以使用的代理地址。
+
+**注意：** 此部分仅适用于中国大陆 
+
 <!--
 ## Get involved with SIG Docs

@@ -139,10 +139,10 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.24"
+latest = "v1.25"

-fullversion = "v1.24.0"
-version = "v1.24"
+fullversion = "v1.25.0"
+version = "v1.25"
 githubbranch = "main"
 docsbranch = "main"
 deprecated = false
@@ -179,40 +179,40 @@ js = [
 ]

 [[params.versions]]
-fullversion = "v1.24.0"
-version = "v1.24"
-githubbranch = "v1.24.0"
+fullversion = "v1.25.0"
+version = "v1.25"
+githubbranch = "v1.25.0"
 docsbranch = "main"
 url = "https://kubernetes.io"

 [[params.versions]]
-fullversion = "v1.23.6"
+fullversion = "v1.24.2"
+version = "v1.24"
+githubbranch = "v1.24.2"
+docsbranch = "release-1.24"
+url = "https://v1-24.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.23.8"
 version = "v1.23"
-githubbranch = "v1.23.6"
+githubbranch = "v1.23.8"
 docsbranch = "release-1.23"
 url = "https://v1-23.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.22.9"
+fullversion = "v1.22.11"
 version = "v1.22"
-githubbranch = "v1.22.9"
+githubbranch = "v1.22.11"
 docsbranch = "release-1.22"
 url = "https://v1-22.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.21.12"
+fullversion = "v1.21.14"
 version = "v1.21"
-githubbranch = "v1.21.12"
+githubbranch = "v1.21.14"
 docsbranch = "release-1.21"
 url = "https://v1-21.docs.kubernetes.io"

-[[params.versions]]
-fullversion = "v1.20.15"
-version = "v1.20"
-githubbranch = "v1.20.15"
-docsbranch = "release-1.20"
-url = "https://v1-20.docs.kubernetes.io"
-
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.
@@ -21,15 +21,15 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf

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

 ## Aktualisieren von Images

-Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu, dass das Kubelet Images überspringt, die bereits auf einem Node vorliegen.
+Die Standardregel für das Herunterladen von Images ist `IfNotPresent`, dies führt dazu, dass das Image wird nur heruntergeladen wenn es noch nicht lokal verfügbar ist.
 Wenn sie stattdessen möchten, dass ein Image immer forciert heruntergeladen wird, können sie folgendes tun:


@@ -54,7 +54,7 @@ die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigen
 ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
 universellen [Kommandozeilen-Tool](/docs/user-guide/kubectl-overview/) angesprochen werden können.

-Dieses [Design](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.
+Dieses [Design](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.

 ## Was Kubernetes nicht ist

@@ -56,6 +56,6 @@ Offiziell unterstützte Clientbibliotheken:

 ## Design Dokumentation

-Ein Archiv der Designdokumente für Kubernetes-Funktionalität. Gute Ansatzpunkte sind [Kubernetes Architektur](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) und [Kubernetes Design Übersicht](https://git.k8s.io/community/contributors/design-proposals).
+Ein Archiv der Designdokumente für Kubernetes-Funktionalität. Gute Ansatzpunkte sind [Kubernetes Architektur](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) und [Kubernetes Design Übersicht](https://git.k8s.io/community/contributors/design-proposals).


@@ -424,7 +424,7 @@ export no_proxy=$no_proxy,$(minikube ip)

 Minikube verwendet [libmachine](https://github.com/docker/machine/tree/master/libmachine) zur Bereitstellung von VMs, und [kubeadm](https://github.com/kubernetes/kubeadm) um einen Kubernetes-Cluster in Betrieb zu nehmen.

-Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
+Weitere Informationen zu Minikube finden Sie im [Vorschlag](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/local-cluster-ux.md).

 ## Zusätzliche Links

@@ -11,7 +11,7 @@ weight: 90

 <!-- overview -->

-Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets.
+Der Horizontal Pod Autoscaler skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployment oder Replikat Set basierend auf der beobachteten CPU-Auslastung (oder, mit Unterstützung von [benutzerdefinierter Metriken](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md), von der Anwendung bereitgestellten Metriken). Beachte, dass die horizontale Pod Autoskalierung nicht für Objekte gilt, die nicht skaliert werden können, z. B. DaemonSets.

 Der Horizontal Pod Autoscaler ist als Kubernetes API-Ressource und einem Controller implementiert.
 Die Ressource bestimmt das Verhalten des Controllers.
@@ -46,7 +46,7 @@ Das Verwenden von Metriken aus Heapster ist seit der Kubernetes Version 1.11 ver

 Siehe [Unterstützung der Metrik APIs](#unterstützung-der-metrik-apis) für weitere Details.

-Der Autoscaler greift über die Scale Sub-Ressource auf die entsprechenden skalierbaren Controller (z.B. Replication Controller, Deployments und Replika Sets) zu. Scale ist eine Schnittstelle, mit der Sie die Anzahl der Replikate dynamisch einstellen und jeden ihrer aktuellen Zustände untersuchen können. Weitere Details zu der Scale Sub-Ressource findest du [hier](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
+Der Autoscaler greift über die Scale Sub-Ressource auf die entsprechenden skalierbaren Controller (z.B. Replication Controller, Deployments und Replika Sets) zu. Scale ist eine Schnittstelle, mit der Sie die Anzahl der Replikate dynamisch einstellen und jeden ihrer aktuellen Zustände untersuchen können. Weitere Details zu der Scale Sub-Ressource findest du [hier](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).

 ### Details zum Algorithmus

@@ -90,7 +90,7 @@ Die aktuelle stabile Version, die nur die Unterstützung für die automatische S

 Die Beta-Version, welche die Skalierung des Speichers und benutzerdefinierte Metriken unterstützt, befindet sich unter `autoscaling/v2beta2`. Die in `autoscaling/v2beta2` neu eingeführten Felder bleiben bei der Arbeit mit `autoscaling/v1` als Anmerkungen erhalten.

-Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden.
+Weitere Details über das API Objekt kann unter dem [HorizontalPodAutoscaler Objekt](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object) gefunden werden.

 ## Unterstützung des Horizontal Pod Autoscaler in kubectl

@@ -166,7 +166,7 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R
 ## {{% heading "whatsnext" %}}


-* Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
+* Design Dokument [Horizontal Pod Autoscaling](https://git.k8s.io/design-proposals-archive/autoscaling/horizontal-pod-autoscaler.md).
 * kubectl autoscale Befehl: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
 * Verwenden des [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).

@@ -1,9 +1,9 @@
 ---
 layout: blog
 title: "Meet Our Contributors - APAC (India region)"
-date: 2022-01-10T12:00:00+0000
+date: 2022-01-10
 slug: meet-our-contributors-india-ep-01
-canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
+canonicalUrl: https://www.kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
 ---

 **Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
@@ -19,7 +19,7 @@ Welcome to the first episode of the APAC edition of the "Meet Our Contributors"

 In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives.

-💫 *Let's get started, so without further ado…* 
+💫 *Let's get started, so without further ado…*


 ## [Arsh Sharma](https://github.com/RinkiyaKeDad)
@@ -39,7 +39,7 @@ To the newcomers, Arsh helps plan their early contributions sustainably.

 Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle.

-At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in. 
+At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in.

 As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer.

@@ -103,4 +103,3 @@ If you have any recommendations/suggestions for who we should interview next, pl


 We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
-
@@ -1,7 +1,7 @@
 ---
 layout: blog
 title: "Meet Our Contributors - APAC (Aus-NZ region)"
-date: 2022-03-16T12:00:00+0000
+date: 2022-03-16
 slug: meet-our-contributors-au-nz-ep-02
 canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
 ---
@@ -60,19 +60,13 @@ Nick Young works at VMware as a technical lead for Contour, a CNCF ingress contr

 His contribution path was notable in that he began working on major areas of the Kubernetes project early on, skewing his trajectory.

-He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions. 
+He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions.

 > _Just being active and contributing will get you a long way. Once you've been active for a while, you'll find that you're able to answer questions, which will mean you're asked questions, and before you know it you are an expert._

-
-
-
 ---

 If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community.


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

 Pods that wish to connect to the API server can do so securely by leveraging a service account so
@@ -479,29 +479,24 @@ these pods will be stuck in terminating status on the shutdown node forever.
 To mitigate the above situation, a  user can manually add the taint `node 
 kubernetes.io/out-of-service` with either `NoExecute` or `NoSchedule` effect to 
 a Node marking it out-of-service. 
-If the `NodeOutOfServiceVolumeDetach`  [feature gate](/docs/reference/
-command-line-tools-reference/feature-gates/) is enabled on
-`kube-controller-manager`, and a Node is marked out-of-service with this taint, the 
-pods on the node will be forcefully deleted if there are no matching tolerations on
-it and volume detach operations for the pods terminating on the node will happen
-immediately. This allows the Pods on the out-of-service node to recover quickly on a
-different node. 
+If the `NodeOutOfServiceVolumeDetach`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+is enabled on `kube-controller-manager`, and a Node is marked out-of-service with this taint, the
+pods on the node will be forcefully deleted if there are no matching tolerations on it and volume
+detach operations for the pods terminating on the node will happen immediately. This allows the
+Pods on the out-of-service node to recover quickly on a different node. 

 During a non-graceful shutdown, Pods are terminated in the two phases:

 1. Force delete the Pods that do not have matching `out-of-service` tolerations.
 2. Immediately perform detach volume operation for such pods. 

-
 {{< note >}}
 - Before adding the taint `node.kubernetes.io/out-of-service` , it should be verified
-that the node is already in shutdown or power off state (not in the middle of
-restarting).
+  that the node is already in shutdown or power off state (not in the middle of
+  restarting).
 - The user is required to manually remove the out-of-service taint after the pods are
-moved to a new node and the user has checked that the shutdown node has been
-recovered since the user was the one who originally added the taint.
-
-
+  moved to a new node and the user has checked that the shutdown node has been
+  recovered since the user was the one who originally added the taint.
 {{< /note >}}

 ### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown}
@@ -11,31 +11,37 @@ no_list: true
 ---

 <!-- overview -->
+
 The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
 It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).

-
 <!-- body -->
+
 ## Planning a cluster

-See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
+See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure
+Kubernetes clusters. The solutions listed in this article are called *distros*.

-   {{< note  >}}
-   Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
-   {{< /note >}}
+{{< note  >}}
+Not all distros are actively maintained. Choose distros which have been tested with a recent
+version of Kubernetes.
+{{< /note >}}

 Before choosing a guide, here are some considerations:

- - Do you want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- - Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- - Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- - **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- - Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- - Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
-   latter, choose an actively-developed distro. Some distros only use binary releases, but
-   offer a greater variety of choices.
- - Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.
-
+- Do you want to try out Kubernetes on your computer, or do you want to build a high-availability,
+  multi-node cluster? Choose distros best suited for your needs.
+- Will you be using **a hosted Kubernetes cluster**, such as
+  [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
+- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly
+  support hybrid clusters. Instead, you can set up multiple clusters.
+- **If you are configuring Kubernetes on-premises**, consider which
+  [networking model](/docs/concepts/cluster-administration/networking/) fits best.
+- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
+- Do you **want to run a cluster**, or do you expect to do **active development of Kubernetes project code**?
+  If the latter, choose an actively-developed distro. Some distros only use binary releases, but
+  offer a greater variety of choices.
+- Familiarize yourself with the [components](/docs/concepts/overview/components/) needed to run a cluster.

 ## Managing a cluster

@@ -45,29 +51,43 @@ Before choosing a guide, here are some considerations:

 ## Securing a cluster

-* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to generate certificates using different tool chains.
+* [Generate Certificates](/docs/tasks/administer-cluster/certificates/) describes the steps to
+  generate certificates using different tool chains.

-* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
+* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes
+  the environment for Kubelet managed containers on a Kubernetes node.

-* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) describes how Kubernetes implements access control for its own API.
+* [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access) describes
+  how Kubernetes implements access control for its own API.

-* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
+* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in
+  Kubernetes, including the various authentication options.

-* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
+* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from
+  authentication, and controls how HTTP calls are handled.

-* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
+* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
+  explains plug-ins which intercepts requests to the Kubernetes API server after authentication
+  and authorization.

-* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
+* [Using Sysctls in a Kubernetes Cluster](/docs/tasks/administer-cluster/sysctl-cluster/)
+  describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters
+.

-* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs.
+* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes'
+  audit logs.

 ### Securing the kubelet
-  * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
-  * [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
-  * [Kubelet authentication/authorization](/docs/reference/acess-authn-authz/kubelet-authn-authz/)
+
+* [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/)
+* [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
+* [Kubelet authentication/authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/)

 ## Optional Cluster Services

-* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
+* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve
+  a DNS name directly to a Kubernetes service.
+
+* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/)
+  explains how logging in Kubernetes works and how to implement it.

-* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
@@ -332,7 +332,7 @@ container of a Pod can specify either or both of the following:

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

 - `128974848`
@@ -340,6 +340,10 @@ Mi, Ki. For example, the following quantities all represent roughly the same val
 - `129M`
 - `123Mi`

+Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request
+for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
+or 400 megabytes (`400M`).
+
 In the following example, the Pod has two containers. Each container has a request of
 2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral
 storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and
@@ -8,21 +8,29 @@ card:
 ---

 <!-- overview -->
-This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
-
+This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can
+express them in `.yaml` format.

 <!-- body -->
 ## Understanding Kubernetes objects {#kubernetes-objects}

-*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
+*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these
+entities to represent the state of your cluster. Specifically, they can describe:

 * What containerized applications are running (and on which nodes)
 * The resources available to those applications
 * The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

-A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's *desired state*.
+A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system
+will constantly work to ensure that object exists. By creating an object, you're effectively
+telling the Kubernetes system what you want your cluster's workload to look like; this is your
+cluster's *desired state*.

-To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use the Kubernetes API directly in your own programs using one of the [Client Libraries](/docs/reference/using-api/client-libraries/).
+To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the
+[Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line
+interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use
+the Kubernetes API directly in your own programs using one of the
+[Client Libraries](/docs/reference/using-api/client-libraries/).

 ### Object Spec and Status

@@ -48,11 +56,17 @@ the status to match your spec. If any of those instances should fail
 between spec and status by making a correction--in this case, starting
 a replacement instance.

-For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+For more information on the object spec, status, and metadata, see the
+[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).

 ### Describing a Kubernetes object

-When you create an object in Kubernetes, you must provide the object spec that describes its desired state, as well as some basic information about the object (such as a name). When you use the Kubernetes API to create the object (either directly or via `kubectl`), that API request must include that information as JSON in the request body. **Most often, you provide the information to `kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API request.
+When you create an object in Kubernetes, you must provide the object spec that describes its
+desired state, as well as some basic information about the object (such as a name). When you use
+the Kubernetes API to create the object (either directly or via `kubectl`), that API request must
+include that information as JSON in the request body. **Most often, you provide the information to
+`kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API
+request.

 Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:

@@ -81,7 +95,9 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
 * `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
 * `spec` - What state you desire for the object

-The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes.
+The precise format of the object `spec` is different for every Kubernetes object, and contains
+nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/)
+can help you find the spec format for all of the objects you can create using Kubernetes.

 For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
 for the Pod API reference.
@@ -103,5 +119,3 @@ detail the structure of that `.status` field, and its content for each different
 * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes.
 * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts.

-
-
@@ -169,9 +169,9 @@ Disadvantages compared to imperative object configuration:
 ## {{% heading "whatsnext" %}}

 - [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Managing Kubernetes Objects Using Kustomize (Declarative)](/docs/tasks/manage-kubernetes-objects/kustomization/)
+- [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
+- [Declarative Management of Kubernetes Objects Using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/)
 - [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
@@ -66,8 +66,8 @@ the signal.

 The value for `memory.available` is derived from the cgroupfs instead of tools
 like `free -m`. This is important because `free -m` does not work in a
-container, and if users use the [node
-allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
+container, and if users use the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
+feature, out of resource decisions
 are made local to the end user Pod part of the cgroup hierarchy as well as the
 root node. This [script](/examples/admin/resource/memory-available.sh)
 reproduces the same set of steps that the kubelet performs to calculate
@@ -85,10 +85,15 @@ The kubelet supports the following filesystem partitions:
 Kubelet auto-discovers these filesystems and ignores other filesystems. Kubelet
 does not support other configurations.

-{{<note>}}
-Some kubelet garbage collection features are deprecated in favor of eviction.
-For a list of the deprecated features, see [kubelet garbage collection deprecation](/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation).
-{{</note>}}
+Some kubelet garbage collection features are deprecated in favor of eviction:
+
+| Existing Flag | New Flag | Rationale |
+| ------------- | -------- | --------- |
+| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
+| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
+| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
+| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
+| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |

 ### Eviction thresholds

@@ -15,14 +15,15 @@ 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. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also [evaluates other parameters](/docs/concepts/scheduling-eviction/pod-priority-preemption/) as part of its function.
+_Tolerations_ are applied to pods. Tolerations allow the scheduler to schedule pods with matching
+taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also
+[evaluates other parameters](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+as part of its function.

 Taints and tolerations work together to ensure that pods are not scheduled
 onto inappropriate nodes. One or more taints are applied to a node; this
 marks that the node should not accept any pods that do not tolerate the taints.

-
-
 <!-- body -->

 ## Concepts
@@ -266,7 +267,8 @@ This ensures that DaemonSet pods are never evicted due to these problems.
 ## Taint Nodes by Condition

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

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

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

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

-
@@ -23,10 +23,11 @@ following diagram:

 ## Transport security

-In a typical Kubernetes cluster, the API serves on port 443, protected by TLS.
+By default, the Kubernetes API server listens on port 6443 on the first non-localhost network interface, protected by TLS. In a typical production Kubernetes cluster, the API serves on port 443. The port can be changed with the `--secure-port`, and the listening IP address with the `--bind-address` flag.
+
 The API server presents a certificate. This certificate may be signed using
 a private certificate authority (CA), or based on a public key infrastructure linked
-to a generally recognized CA.
+to a generally recognized CA. The certificate and corresponding private key can be set by using the `--tls-cert-file` and `--tls-private-key-file` flags.

 If your cluster uses a private certificate authority, you need a copy of that CA
 certificate configured into your `~/.kube/config` on the client, so that you can
@@ -137,34 +138,6 @@ The cluster audits the activities generated by users, by applications that use t

 For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/).

-## API server ports and IPs
-
-The previous discussion applies to requests sent to the secure port of the API server
-(the typical case).  The API server can actually serve on 2 ports:
-
-By default, the Kubernetes API server serves HTTP on 2 ports:
-
-  1. `localhost` port:
-
-      - is intended for testing and bootstrap, and for other components of the master node
-        (scheduler, controller-manager) to talk to the API
-      - no TLS
-      - default is port 8080
-      - default IP is localhost, change with `--insecure-bind-address` flag.
-      - request **bypasses** authentication and authorization modules.
-      - request handled by admission control module(s).
-      - protected by need to have host access
-
-  2. “Secure port”:
-
-      - use whenever possible
-      - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
-      - default is port 6443, change with `--secure-port` flag.
-      - default IP is first non-localhost network interface, change with `--bind-address` flag.
-      - request handled by authentication and authorization modules.
-      - request handled by admission control module(s).
-      - authentication and authorization modules run.
-
 ## {{% heading "whatsnext" %}}

 Read more documentation on authentication, authorization and API access control:
@@ -462,11 +462,11 @@ of individual policies are not defined here.
 {{% 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?
@@ -493,9 +493,9 @@ built-in [Pod Security Admission Controller](/docs/concepts/security/pod-securit
 ### What profiles should I apply to my Windows Pods?

 Windows in Kubernetes has some limitations and differentiators from standard Linux-based
-workloads. Specifically, many of the Pod SecurityContext fields [have no effect on
-Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As
-such, no standardized Pod Security profiles currently exist.
+workloads. Specifically, many of the Pod SecurityContext fields
+[have no effect on Windows](/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext).
+As such, no standardized Pod Security profiles currently exist.

 If you apply the restricted profile for a Windows pod, this **may** have an impact on the pod
 at runtime. The restricted profile requires enforcing Linux-specific restrictions (such as seccomp
@@ -504,7 +504,9 @@ these Linux-specific values, then the Windows pod should still work normally wit
 profile. However, the lack of enforcement means that there is no additional restriction, for Pods
 that use Windows containers, compared to the baseline profile.

-The use of the HostProcess flag to create a HostProcess pod should only be done in alignment with the privileged policy. Creation of a Windows HostProcess pod is blocked under the baseline and restricted policies, so any HostProcess pod should be considered privileged.
+The use of the HostProcess flag to create a HostProcess pod should only be done in alignment with the privileged policy.
+Creation of a Windows HostProcess pod is blocked under the baseline and restricted policies,
+so any HostProcess pod should be considered privileged.

 ### What about sandboxed Pods?

@@ -518,3 +520,4 @@ kernel. This allows for workloads requiring heightened permissions to still be i

 Additionally, the protection of sandboxed workloads is highly dependent on the method of
 sandboxing. As such, no single recommended profile is recommended for all sandboxed workloads.
+
@@ -15,7 +15,8 @@ execute their roles. It is important to ensure that, when designing permissions
 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).
+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 -->

@@ -34,7 +35,8 @@ some general rules that can be applied are :
   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)
+   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 
@@ -44,15 +46,17 @@ some general rules that can be applied are :

 ### 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)). 
+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
+   [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
@@ -107,7 +111,7 @@ with the ability to create suitably secure and isolated Pods, you should enforce
 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
+You can also use the deprecated [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) mechanism
 to restrict users' abilities to create privileged Pods (N.B. PodSecurityPolicy is scheduled for removal
 in version 1.25).

@@ -117,7 +121,9 @@ 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 
+As noted in the [PodSecurityPolicy](/docs/concepts/security/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
@@ -130,7 +136,8 @@ 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),
+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
@@ -173,8 +180,11 @@ objects to create a denial of service condition either based on the size or numb
 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)
+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/).
+
@@ -22,34 +22,41 @@ storage (as compared to using tmpfs / in-memory filesystems on Linux). As a clus
 operator, you should take both of the following additional measures:

 1. Use file ACLs to secure the Secrets' file location.
-1. Apply volume-level encryption using [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server).
+1. Apply volume-level encryption using
+   [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server).

 ## Container users

 [RunAsUsername](/docs/tasks/configure-pod-container/configure-runasusername)
 can be specified for Windows Pods or containers to execute the container
 processes as specific user. This is roughly equivalent to
-[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups).
+[RunAsUser](/docs/concepts/security/pod-security-policy/#users-and-groups).

 Windows containers offer two default user accounts, ContainerUser and ContainerAdministrator.
 The differences between these two user accounts are covered in
-[When to use ContainerAdmin and ContainerUser user accounts](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts) within Microsoft's _Secure Windows containers_ documentation.
+[When to use ContainerAdmin and ContainerUser user accounts](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)
+within Microsoft's _Secure Windows containers_ documentation.

 Local users can be added to container images during the container build process.

 {{< note >}}

-* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) based images run as `ContainerUser` by default
-* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) based images run as `ContainerAdministrator` by default
+* [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) based images run as
+  `ContainerUser` by default
+* [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) based images run as
+  `ContainerAdministrator` by default

 {{< /note >}}

-Windows containers can also run as Active Directory identities by utilizing [Group Managed Service Accounts](/docs/tasks/configure-pod-container/configure-gmsa/)
+Windows containers can also run as Active Directory identities by utilizing
+[Group Managed Service Accounts](/docs/tasks/configure-pod-container/configure-gmsa/)

 ## Pod-level security isolation

 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](/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.
+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.
@@ -299,9 +299,14 @@ thus is only available to use as-is.
 ### Configuration

 Note that the kube-proxy starts up in different modes, which are determined by its configuration.
- The kube-proxy's configuration is done via a ConfigMap, and the ConfigMap for kube-proxy effectively deprecates the behaviour for almost all of the flags for the kube-proxy.
+- The kube-proxy's configuration is done via a ConfigMap, and the ConfigMap for kube-proxy
+  effectively deprecates the behaviour for almost all of the flags for the kube-proxy.
 - The ConfigMap for the kube-proxy does not support live reloading of configuration.
- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup.  For example, if your operating system doesn't allow you to run iptables commands, the standard kernel kube-proxy implementation will not work.  Likewise, if you have an operating system which doesn't support `netsh`, it will not run in Windows userspace mode.
+- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup.
+  For example, if your operating system doesn't allow you to run iptables commands,
+  the standard kernel kube-proxy implementation will not work.
+  Likewise, if you have an operating system which doesn't support `netsh`,
+  it will not run in Windows userspace mode.

 ### User space proxy mode {#proxy-mode-userspace}

@@ -492,7 +497,11 @@ variables and DNS.
 ### Environment variables

 When a Pod is run on a Node, the kubelet adds a set of environment variables
-for each active Service. It adds `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. It also supports variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) that are compatible with Docker Engine's "_[legacy container links](https://docs.docker.com/network/links/)_" feature.
+for each active Service. It adds `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
+where the Service name is upper-cased and dashes are converted to underscores.
+It also supports variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72))
+that are compatible with Docker Engine's
+"_[legacy container links](https://docs.docker.com/network/links/)_" feature.

 For example, the Service `redis-master` which exposes TCP port 6379 and has been
 allocated cluster IP address 10.0.0.11, produces the following environment
@@ -604,8 +613,10 @@ The default is `ClusterIP`.
  to use the `ExternalName` type.
  {{< /note >}}

-You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules
-into a single resource as it can expose multiple services under the same IP address.
+You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service.
+Ingress is not a Service type, but it acts as the entry point for your cluster.
+It lets you consolidate your routing rules into a single resource as it can expose multiple
+services under the same IP address.

 ### Type NodePort {#type-nodeport}

@@ -620,9 +631,14 @@ field of the
 [kube-proxy configuration file](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
 to particular IP block(s).

-This flag takes a comma-delimited list of IP blocks (e.g. `10.0.0.0/8`, `192.0.2.0/25`) to specify IP address ranges that kube-proxy should consider as local to this node.
+This flag takes a comma-delimited list of IP blocks (e.g. `10.0.0.0/8`, `192.0.2.0/25`)
+to specify IP address ranges that kube-proxy should consider as local to this node.

-For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag, kube-proxy only selects the loopback interface for NodePort Services. The default for `--nodeport-addresses` is an empty list. This means that kube-proxy should consider all available network interfaces for NodePort. (That's also compatible with earlier Kubernetes releases).
+For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag,
+kube-proxy only selects the loopback interface for NodePort Services.
+The default for `--nodeport-addresses` is an empty list. 
+his means that kube-proxy should consider all available network interfaces for NodePort.
+(That's also compatible with earlier Kubernetes releases).

 If you want a specific port number, you can specify a value in the `nodePort`
 field. The control plane will either allocate you that port or report that
@@ -689,7 +705,8 @@ status:
    - ip: 192.0.2.127
 ```

-Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced.
+Traffic from the external load balancer is directed at the backend Pods.
+The cloud provider decides how it is load balanced.

 Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created
 with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified,
@@ -704,7 +721,11 @@ to create a static type public IP address resource. This public IP address resou
 be in the same resource group of the other automatically created resources of the cluster.
 For example, `MC_myResourceGroup_myAKSCluster_eastus`.

-Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).
+Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the
+`securityGroupName` in the cloud provider configuration file.
+For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see,
+[Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip)
+or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).

 {{< /note >}}

@@ -760,7 +781,8 @@ Unprefixed names are reserved for end-users.
 In a mixed environment it is sometimes necessary to route traffic from Services inside the same
 (virtual) network address block.

-In a split-horizon DNS environment you would need two Services to be able to route both external and internal traffic to your endpoints.
+In a split-horizon DNS environment you would need two Services to be able to route both external
+and internal traffic to your endpoints.

 To set an internal load balancer, add one of the following annotations to your Service
 depending on the cloud Service provider you're using.
@@ -925,7 +947,9 @@ you can use the following annotations:
 In the above example, if the Service contained three ports, `80`, `443`, and
 `8443`, then `443` and `8443` would use the SSL certificate, but `80` would be proxied HTTP.

-From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services.
+From Kubernetes v1.9 onwards you can use
+[predefined AWS SSL policies](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)
+with HTTPS or SSL listeners for your Services.
 To see which policies are available for use, you can use the `aws` command line tool:

 ```bash
@@ -981,14 +1005,17 @@ specifies the logical hierarchy you created for your Amazon S3 bucket.
    metadata:
      name: my-service
      annotations:
-        service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
        # Specifies whether access logs are enabled for the load balancer
-        service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
+        service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true"
+
        # The interval for publishing the access logs. You can specify an interval of either 5 or 60 (minutes).
-        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
+        service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60"
+
        # The name of the Amazon S3 bucket where the access logs are stored
-        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
+        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket"
+
        # The logical hierarchy you created for your Amazon S3 bucket, for example `my-bucket-prefix/prod`
+        service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod"
 ```

 #### Connection Draining on AWS
@@ -997,7 +1024,8 @@ Connection draining for Classic ELBs can be managed with the annotation
 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` set
 to the value of `"true"`. The annotation
 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` can
-also be used to set maximum time, in seconds, to keep the existing connections open before deregistering the instances.
+also be used to set maximum time, in seconds, to keep the existing connections open before
+deregistering the instances.

 ```yaml
    metadata:
@@ -1015,50 +1043,56 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
    metadata:
      name: my-service
      annotations:
+        # The time, in seconds, that the connection is allowed to be idle (no data has been sent
+        # over the connection) before it is closed by the load balancer
        service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
-        # The time, in seconds, that the connection is allowed to be idle (no data has been sent over the connection) before it is closed by the load balancer

-        service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
        # Specifies whether cross-zone load balancing is enabled for the load balancer
+        service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"

-        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"
        # A comma-separated list of key-value pairs which will be recorded as
        # additional tags in the ELB.
+        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "environment=prod,owner=devops"

-        service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""
        # The number of successive successful health checks required for a backend to
        # be considered healthy for traffic. Defaults to 2, must be between 2 and 10
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: ""

-        service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
        # The number of unsuccessful health checks required for a backend to be
        # considered unhealthy for traffic. Defaults to 6, must be between 2 and 10
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"

-        service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
        # The approximate interval, in seconds, between health checks of an
        # individual instance. Defaults to 10, must be between 5 and 300
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"

-        service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
        # The amount of time, in seconds, during which no response means a failed
        # health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval
        # value. Defaults to 5, must be between 2 and 60
+        service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"

-        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
        # A list of existing security groups to be configured on the ELB created. Unlike the annotation
-        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB and also overrides the creation 
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other
+        # security groups previously assigned to the ELB and also overrides the creation 
        # of a uniquely generated security group for this ELB.
-        # The first security group ID on this list is used as a source to permit incoming traffic to target worker nodes (service traffic and health checks).
-        # If multiple ELBs are configured with the same security group ID, only a single permit line will be added to the worker node security groups, that means if you delete any
+        # The first security group ID on this list is used as a source to permit incoming traffic to
+        # target worker nodes (service traffic and health checks).
+        # If multiple ELBs are configured with the same security group ID, only a single permit line
+        # will be added to the worker node security groups, that means if you delete any
        # of those ELBs it will remove the single permit line and block access for all ELBs that shared the same security group ID.
        # This can cause a cross-service outage if not used properly
+        service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"

-        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
-        #  A list of additional security groups to be added to the created ELB, this leaves the uniquely generated security group in place, this ensures that every ELB
-        # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes (service traffic and health checks).
+        # A list of additional security groups to be added to the created ELB, this leaves the uniquely
+        # generated security group in place, this ensures that every ELB
+        # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes
+        # (service traffic and health checks).
        # Security groups defined here can be shared between services. 
+        service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"

-        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
        # A comma separated list of key-value pairs which are used
        # to select the target nodes for the load balancer
+        service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
 ```

 #### Network Load Balancer support on AWS {#aws-nlb-support}
@@ -1075,7 +1109,8 @@ To use a Network Load Balancer on AWS, use the annotation `service.beta.kubernet
 ```

 {{< note >}}
-NLB only works with certain instance classes; see the [AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
+NLB only works with certain instance classes; see the
+[AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
 on Elastic Load Balancing for a list of supported instance types.
 {{< /note >}}

@@ -1182,7 +1217,8 @@ spec:
 ```

 {{< note >}}
-ExternalName accepts an IPv4 address string, but as a DNS name comprised of digits, not as an IP address. ExternalNames that resemble IPv4 addresses are not resolved by CoreDNS or ingress-nginx because ExternalName
+ExternalName accepts an IPv4 address string, but as a DNS name comprised of digits, not as an IP address.
+ExternalNames that resemble IPv4 addresses are not resolved by CoreDNS or ingress-nginx because ExternalName
 is intended to specify a canonical DNS name. To hardcode an IP address, consider using
 [headless Services](#headless-services).
 {{< /note >}}
@@ -1196,9 +1232,13 @@ can start its Pods, add appropriate selectors or endpoints, and change the
 Service's `type`.

 {{< warning >}}
-You may have trouble using ExternalName for some common protocols, including HTTP and HTTPS. If you use ExternalName then the hostname used by clients inside your cluster is different from the name that the ExternalName references.
+You may have trouble using ExternalName for some common protocols, including HTTP and HTTPS.
+If you use ExternalName then the hostname used by clients inside your cluster is different from
+the name that the ExternalName references.

-For protocols that use hostnames this difference may lead to errors or unexpected responses. HTTP requests will have a `Host:` header that the origin server does not recognize; TLS servers will not be able to provide a certificate matching the hostname that the client connected to.
+For protocols that use hostnames this difference may lead to errors or unexpected responses.
+HTTP requests will have a `Host:` header that the origin server does not recognize;
+TLS servers will not be able to provide a certificate matching the hostname that the client connected to.
 {{< /warning >}}

 {{< note >}}
@@ -1357,12 +1397,15 @@ through a load-balancer, though in those cases the client IP does get altered.
 #### IPVS

 iptables operations slow down dramatically in large scale cluster e.g 10,000 Services.
-IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence).
+IPVS is designed for load balancing and based on in-kernel hash tables.
+So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy.
+Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms
+(least conns, locality, weighted, persistence).

 ## API Object

 Service is a top-level resource in the Kubernetes REST API. You can find more details
-about the API object at: [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).
+about the [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core).

 ## Supported protocols {#protocol-support}

@@ -1388,7 +1431,8 @@ provider offering this facility. (Most do not).
 ##### Support for multihomed SCTP associations {#caveat-sctp-multihomed}

 {{< warning >}}
-The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a Pod.
+The support of multihomed SCTP associations requires that the CNI plugin can support the
+assignment of multiple interfaces and IP addresses to a Pod.

 NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.
 {{< /warning >}}
@@ -1437,3 +1481,4 @@ followed by the data from the client.
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 * Read about [Ingress](/docs/concepts/services-networking/ingress/)
 * Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
+
@@ -76,8 +76,8 @@ is managed by kubelet, or injecting different data.

 {{< feature-state for_k8s_version="v1.16" state="beta" >}}

-This feature requires the `CSIInlineVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It
-is enabled by default starting with Kubernetes 1.16.
+This feature requires the `CSIInlineVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+to be enabled. It is enabled by default starting with Kubernetes 1.16.

 {{< note >}}
 CSI ephemeral volumes are only supported by a subset of CSI drivers.
@@ -136,8 +136,11 @@ should not be exposed to users through the use of inline ephemeral volumes.

 Cluster administrators who need to restrict the CSI drivers that are
 allowed to be used as inline volumes within a Pod spec may do so by:
- Removing `Ephemeral` from `volumeLifecycleModes` in the CSIDriver spec, which prevents the driver from being used as an inline ephemeral volume.
- Using an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) to restrict how this driver is used.
+
+- Removing `Ephemeral` from `volumeLifecycleModes` in the CSIDriver spec, which prevents the
+  driver from being used as an inline ephemeral volume.
+- Using an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+  to restrict how this driver is used.

 ### Generic ephemeral volumes

@@ -207,7 +210,7 @@ because then the scheduler is free to choose a suitable node for
 the Pod. With immediate binding, the scheduler is forced to select a node that has
 access to the volume once it is available.

-In terms of [resource ownership](/docs/concepts/workloads/controllers/garbage-collection/#owners-dependents),
+In terms of [resource ownership](/docs/concepts/architecture/garbage-collection/#owners-dependents),
 a Pod that has generic ephemeral storage is the owner of the PersistentVolumeClaim(s)
 that provide that ephemeral storage. When the Pod is deleted,
 the Kubernetes garbage collector deletes the PVC, which then usually
@@ -252,10 +255,11 @@ Enabling the GenericEphemeralVolume feature allows users to create
 PVCs indirectly if they can create Pods, even if they do not have
 permission to create PVCs directly. Cluster administrators must be
 aware of this. If this does not fit their security model, they should
-use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) that rejects objects like Pods that have a generic ephemeral volume.
+use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
+that rejects objects like Pods that have a generic ephemeral volume.

-The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota) still applies, so
-even if users are allowed to use this new mechanism, they cannot use
+The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota)
+still applies, so even if users are allowed to use this new mechanism, they cannot use
 it to circumvent other policies.

 ## {{% heading "whatsnext" %}}
@@ -266,11 +270,13 @@ See [local ephemeral storage](/docs/concepts/configuration/manage-resources-cont

 ### CSI ephemeral volumes

- For more information on the design, see the [Ephemeral Inline CSI
-  volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md).
- For more information on further development of this feature, see the [enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596).
+- For more information on the design, see the
+  [Ephemeral Inline CSI volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md).
+- For more information on further development of this feature, see the
+  [enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596).

 ### Generic ephemeral volumes

 - For more information on the design, see the
-[Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md).
+  [Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md).
+
@@ -558,7 +558,7 @@ If the access modes are specified as ReadWriteOncePod, the volume is constrained
 | AzureFile            | &#x2713;               | &#x2713;              | &#x2713;      | -                      |
 | AzureDisk            | &#x2713;               | -                     | -             | -                      |
 | CephFS               | &#x2713;               | &#x2713;              | &#x2713;      | -                      |
-| Cinder               | &#x2713;               | -                     | -             | -                      |
+| Cinder               | &#x2713;               | -                     | ([if multi-attach volumes are available](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/features.md#multi-attach-volumes))            | -                      |
 | CSI                  | depends on the driver  | depends on the driver | depends on the driver | depends on the driver |
 | FC                   | &#x2713;               | &#x2713;              | -             | -                      |
 | FlexVolume           | &#x2713;               | &#x2713;              | depends on the driver | -              |
@@ -73,7 +73,7 @@ volume mount will not receive updates for those volume sources.

 ## SecurityContext interactions

-The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set.
+The [proposal](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the correct owner permissions set.

 ### Linux

@@ -99,6 +99,7 @@ into their own volume mount outside of `C:\`.

 By default, the projected files will have the following ownership as shown for
 an example projected volume file:
+
 ```powershell
 PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List

@@ -111,6 +112,7 @@ Access : NT AUTHORITY\SYSTEM Allow  FullControl
 Audit  :
 Sddl   : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
 ```
+
 This implies all administrator users like `ContainerAdministrator` will have
 read, write and execute access while, non-administrator users will have read and
 execute access.
@@ -132,7 +132,7 @@ section refers to several key workload abstractions and how they map to Windows.
  * CronJob
  * ReplicationController
 * {{< glossary_tooltip text="Services" term_id="service" >}}
-  See [Load balancing and Services](#load-balancing-and-services) for more details.
+  See [Load balancing and Services](/docs/concepts/services-networking/windows-networking/#load-balancing-and-services) for more details.

 Pods, workload resources, and Services are critical elements to managing Windows
 workloads on Kubernetes. However, on their own they are not enough to enable
@@ -70,7 +70,7 @@ visit [Configuration](/docs/concepts/configuration/).

 There are two supporting concepts that provide backgrounds about how Kubernetes manages pods
 for applications:
-* [Garbage collection](/docs/concepts/workloads/controllers/garbage-collection/) tidies up objects
+* [Garbage collection](/docs/concepts/architecture/garbage-collection/) tidies up objects
  from your cluster after their _owning resource_ has been removed.
 * The [_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/)
  removes Jobs once a defined time has passed since they completed.
@@ -71,7 +71,7 @@ Pod Template:
           job-name=pi
  Containers:
   pi:
-    Image:      perl
+    Image:      perl:5.34.0
    Port:       <none>
    Host Port:  <none>
    Command:
@@ -125,7 +125,7 @@ spec:
        - -Mbignum=bpi
        - -wle
        - print bpi(2000)
-        image: perl
+        image: perl:5.34.0
        imagePullPolicy: Always
        name: pi
        resources: {}
@@ -356,7 +356,7 @@ spec:
    spec:
      containers:
      - name: pi
-        image: perl
+        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
 ```
@@ -402,7 +402,7 @@ spec:
    spec:
      containers:
      - name: pi
-        image: perl
+        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
 ```
@@ -13,9 +13,6 @@ weight: 20
 A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often
 used to guarantee the availability of a specified number of identical Pods.

-
-
-
 <!-- body -->

 ## How a ReplicaSet works
@@ -26,14 +23,14 @@ it should create to meet the number of replicas criteria. A ReplicaSet then fulf
 and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod
 template.

-A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
+A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/architecture/garbage-collection/#owners-and-dependents)
 field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning
 ReplicaSet's identifying information within their ownerReferences field. It's through this link that the ReplicaSet
 knows of the state of the Pods it is maintaining and plans accordingly.

-A ReplicaSet identifies new Pods to acquire by using its selector. If there is a Pod that has no OwnerReference or the
-OwnerReference is not a {{< glossary_tooltip term_id="controller" >}} and it matches a ReplicaSet's selector, it will be immediately acquired by said
-ReplicaSet.
+A ReplicaSet identifies new Pods to acquire by using its selector. If there is a Pod that has no
+OwnerReference or the OwnerReference is not a {{< glossary_tooltip term_id="controller" >}} and it
+matches a ReplicaSet's selector, it will be immediately acquired by said ReplicaSet.

 ## When to use a ReplicaSet

@@ -253,7 +250,9 @@ In the ReplicaSet, `.spec.template.metadata.labels` must match `spec.selector`,
 be rejected by the API.

 {{< note >}}
-For 2 ReplicaSets specifying the same `.spec.selector` but different `.spec.template.metadata.labels` and `.spec.template.spec` fields, each ReplicaSet ignores the Pods created by the other ReplicaSet.
+For 2 ReplicaSets specifying the same `.spec.selector` but different
+`.spec.template.metadata.labels` and `.spec.template.spec` fields, each ReplicaSet ignores the
+Pods created by the other ReplicaSet.
 {{< /note >}}

 ### Replicas
@@ -267,11 +266,14 @@ If you do not specify `.spec.replicas`, then it defaults to 1.

 ### Deleting a ReplicaSet and its Pods

-To delete a ReplicaSet and all of its Pods, use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). The [Garbage collector](/docs/concepts/workloads/controllers/garbage-collection/) automatically deletes all of the dependent Pods by default.
+To delete a ReplicaSet and all of its Pods, use
+[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). The
+[Garbage collector](/docs/concepts/architecture/garbage-collection/) automatically deletes all of
+the dependent Pods by default.
+
+When using the REST API or the `client-go` library, you must set `propagationPolicy` to
+`Background` or `Foreground` in the `-d` option. For example:

-When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Background` or `Foreground` in
-the -d option.
-For example:
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@@ -281,9 +283,12 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron

 ### Deleting just a ReplicaSet

-You can delete a ReplicaSet without affecting any of its Pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=orphan` option.
+You can delete a ReplicaSet without affecting any of its Pods using
+[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)
+with the `--cascade=orphan` option.
 When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Orphan`.
 For example:
+
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@@ -295,7 +300,8 @@ Once the original is deleted, you can create a new ReplicaSet to replace it.  As
 as the old and new `.spec.selector` are the same, then the new one will adopt the old Pods.
 However, it will not make any effort to make existing Pods match a new, different pod template.
 To update Pods to a new spec in a controlled way, use a
-[Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), as ReplicaSets do not support a rolling update directly.
+[Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), as
+ReplicaSets do not support a rolling update directly.

 ### Isolating Pods from a ReplicaSet

@@ -310,17 +316,19 @@ ensures that a desired number of Pods with a matching label selector are availab

 When scaling down, the ReplicaSet controller chooses which pods to delete by sorting the available pods to
 prioritize scaling down pods based on the following general algorithm:
- 1. Pending (and unschedulable) pods are scaled down first
- 2. If `controller.kubernetes.io/pod-deletion-cost` annotation is set, then
-    the pod with the lower value will come first.
- 3. Pods on nodes with more replicas come before pods on nodes with fewer replicas.
- 4. If the pods' creation times differ, the pod that was created more recently
-    comes before the older pod (the creation times are bucketed on an integer log scale
-    when the `LogarithmicScaleDown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
+
+1. Pending (and unschedulable) pods are scaled down first
+1. If `controller.kubernetes.io/pod-deletion-cost` annotation is set, then
+   the pod with the lower value will come first.
+1. Pods on nodes with more replicas come before pods on nodes with fewer replicas.
+1. If the pods' creation times differ, the pod that was created more recently
+   comes before the older pod (the creation times are bucketed on an integer log scale
+   when the `LogarithmicScaleDown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled)
    
 If all of the above match, then selection is random.

 ### Pod deletion cost 
+
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}

 Using the [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 
@@ -344,6 +352,7 @@ This feature is beta and enabled by default. You can disable it using the
 {{< /note >}}

 #### Example Use Case
+
 The different pods of an application could have different utilization levels. On scale down, the application 
 may prefer to remove the pods with lower utilization. To avoid frequently updating the pods, the application
 should update `controller.kubernetes.io/pod-deletion-cost` once before issuing a scale down (setting the 
@@ -387,12 +396,17 @@ As such, it is recommended to use Deployments when you want ReplicaSets.

 ### Bare Pods

-Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicaSet even if your application requires only a single Pod. Think of it similarly to a process supervisor, only it supervises multiple Pods across multiple nodes instead of individual processes on a single node. A ReplicaSet delegates local container restarts to some agent on the node such as Kubelet.
+Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods that are deleted or
+terminated for any reason, such as in the case of node failure or disruptive node maintenance,
+such as a kernel upgrade. For this reason, we recommend that you use a ReplicaSet even if your
+application requires only a single Pod. Think of it similarly to a process supervisor, only it
+supervises multiple Pods across multiple nodes instead of individual processes on a single node. A
+ReplicaSet delegates local container restarts to some agent on the node such as Kubelet.

 ### Job

-Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet for Pods that are expected to terminate on their own
-(that is, batch jobs).
+Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet for Pods that are
+expected to terminate on their own (that is, batch jobs).

 ### DaemonSet

@@ -402,12 +416,12 @@ to a machine lifetime: the Pod needs to be running on the machine before other P
 safe to terminate when the machine is otherwise ready to be rebooted/shutdown.

 ### ReplicationController
-ReplicaSets are the successors to [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/).
+
+ReplicaSets are the successors to [ReplicationControllers](/docs/concepts/workloads/controllers/replicationcontroller/).
 The two serve the same purpose, and behave similarly, except that a ReplicationController does not support set-based
 selector requirements as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
 As such, ReplicaSets are preferred over ReplicationControllers

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

 * Learn about [Pods](/docs/concepts/workloads/pods).
@@ -419,3 +433,4 @@ As such, ReplicaSets are preferred over ReplicationControllers
  object definition to understand the API for replica sets.
 * Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
  you can use it to manage application availability during disruptions.
+
@@ -39,10 +39,18 @@ that provides a set of stateless replicas.

 ## Limitations

-* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
-* Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
-* StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
-* StatefulSets do not provide any guarantees on the termination of pods when a StatefulSet is deleted. To achieve ordered and graceful termination of the pods in the StatefulSet, it is possible to scale the StatefulSet down to 0 prior to deletion.
+* The storage for a given Pod must either be provisioned by a
+  [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)
+  based on the requested `storage class`, or pre-provisioned by an admin.
+* Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the
+  StatefulSet. This is done to ensure data safety, which is generally more valuable than an
+  automatic purge of all related StatefulSet resources.
+* StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services)
+  to be responsible for the network identity of the Pods. You are responsible for creating this
+  Service.
+* StatefulSets do not provide any guarantees on the termination of pods when a StatefulSet is
+  deleted. To achieve ordered and graceful termination of the pods in the StatefulSet, it is
+  possible to scale the StatefulSet down to 0 prior to deletion.
 * When using [Rolling Updates](#rolling-updates) with the default
  [Pod Management Policy](#pod-management-policies) (`OrderedReady`),
  it's possible to get into a broken state that requires
@@ -108,18 +116,24 @@ In the above example:

 * A Headless Service, named `nginx`, is used to control the network domain.
 * The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
-* The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
+* The `volumeClaimTemplates` will provide stable storage using
+  [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a
+  PersistentVolume Provisioner.

 The name of a StatefulSet object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

 ### Pod Selector

-You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
+You must set the `.spec.selector` field of a StatefulSet to match the labels of its
+`.spec.template.metadata.labels`. Failing to specify a matching Pod Selector will result in a
+validation error during StatefulSet creation.

 ### Volume Claim Templates

-You can set the  `.spec.volumeClaimTemplates` which can provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
+You can set the `.spec.volumeClaimTemplates` which can provide stable storage using
+[PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume
+Provisioner.


 ### Minimum ready seconds
@@ -128,9 +142,11 @@ You can set the  `.spec.volumeClaimTemplates` which can provide stable storage u

 `.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
 created Pod should be ready without any of its containers crashing, for it to be considered available.
-Please note that this feature is beta and enabled by default. Please opt out by unsetting the StatefulSetMinReadySeconds flag, if you don't
+Please note that this feature is beta and enabled by default. Please opt out by unsetting the
+StatefulSetMinReadySeconds flag, if you don't
 want this feature to be enabled. This field defaults to 0 (the Pod will be considered 
-available as soon as it is ready). To learn more about when a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
+available as soon as it is ready). To learn more about when a Pod is considered ready, see
+[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).

 ## Pod Identity

@@ -166,8 +182,8 @@ remembered and reused, even after the Pod is running, for at least a few seconds
 If you need to discover Pods promptly after they are created, you have a few options:

 - Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
-
+- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the
+  config map for CoreDNS, which currently caches for 30 seconds).

 As mentioned in the [limitations](#limitations) section, you are responsible for
 creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services)
@@ -189,7 +205,9 @@ Cluster Domain will be set to `cluster.local` unless

 ### Stable Storage

-For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one PersistentVolumeClaim. In the nginx example above, each Pod receives a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
+For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one
+PersistentVolumeClaim. In the nginx example above, each Pod receives a single PersistentVolume
+with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
 is specified, then the default StorageClass will be used. When a Pod is (re)scheduled
 onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
 PersistentVolume Claims. Note that, the PersistentVolumes associated with the
@@ -210,7 +228,9 @@ the StatefulSet.
 * Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
 * Before a Pod is terminated, all of its successors must be completely shutdown.

-The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice
+is unsafe and strongly discouraged. For further explanation, please refer to
+[force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).

 When the nginx example above is created, three Pods will be deployed in the order
 web-0, web-1, web-2. web-1 will not be deployed before web-0 is
@@ -256,7 +276,8 @@ annotations for the Pods in a StatefulSet. There are two possible values:
  create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.

 `RollingUpdate`
-: The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a StatefulSet. This is the default update strategy.
+: The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
+  StatefulSet. This is the default update strategy.

 ## Rolling Updates

@@ -299,7 +320,7 @@ unavailable Pod in the range `0` to `replicas - 1`, it will be counted towards
 {{< note >}}
 The `maxUnavailable` field is in Alpha stage and it is honored only by API servers
 that are running with the `MaxUnavailableStatefulSet`
-[feature gate](/docs/reference/commmand-line-tools-reference/feature-gates/)
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 enabled.
 {{< /note >}}

@@ -375,8 +396,8 @@ spec:
 ...
 ```

-The StatefulSet {{<glossary_tooltip text="controller" term_id="controller">}} adds [owner
-references](/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)
+The StatefulSet {{<glossary_tooltip text="controller" term_id="controller">}} adds
+[owner references](/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)
 to its PVCs, which are then deleted by the {{<glossary_tooltip text="garbage collector"
 term_id="garbage-collection">}} after the Pod is terminated. This enables the Pod to
 cleanly unmount all volumes before the PVCs are deleted (and before the backing PV and
@@ -278,7 +278,7 @@ For an example of adding a new localization, see the PR to enable

 To guide other localization contributors, add a new
 [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of
-[k/website](https://github.com/kubernetes/website/), where `**` is the two-letter language code.
+[kubernetes/website](https://github.com/kubernetes/website/), where `**` is the two-letter language code.
 For example, a German README file would be `README-de.md`.

 Provide guidance to localization contributors in the localized `README-**.md` file.
@@ -418,7 +418,7 @@ To collaborate on a localization branch:
   `dev-<source version>-<language code>.<team milestone>`

   For example, an approver on a German localization team opens the localization branch
-   `dev-1.12-de.1` directly against the k/website repository, based on the source branch for
+   `dev-1.12-de.1` directly against the `kubernetes/website` repository, based on the source branch for
   Kubernetes v1.12.

 2. Individual contributors open feature branches based on the localization branch.
@@ -216,16 +216,16 @@ Figure 2. Working from a local fork to make your changes.

 1. Decide which branch base to your work on:

-  - For improvements to existing content, use `upstream/main`.
-  - For new content about existing features, use `upstream/main`.
-  - For localized content, use the localization's conventions. For more information, see
-    [localizing Kubernetes documentation](/docs/contribute/localization/).
-  - For new features in an upcoming Kubernetes release, use the feature branch. For more
-    information, see [documenting for a release](/docs/contribute/new-content/new-features/).
-  - For long-running efforts that multiple SIG Docs contributors collaborate on,
-    like content reorganization, use a specific feature branch created for that effort.
+   - For improvements to existing content, use `upstream/main`.
+   - For new content about existing features, use `upstream/main`.
+   - For localized content, use the localization's conventions. For more information, see
+     [localizing Kubernetes documentation](/docs/contribute/localization/).
+   - For new features in an upcoming Kubernetes release, use the feature branch. For more
+     information, see [documenting for a release](/docs/contribute/new-content/new-features/).
+   - For long-running efforts that multiple SIG Docs contributors collaborate on,
+     like content reorganization, use a specific feature branch created for that effort.

-    If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
+   If you need help choosing a branch, ask in the `#sig-docs` Slack channel.

 1. Create a new branch based on the branch identified in step 1. This example assumes the base
   branch is `upstream/main`:
@@ -234,7 +234,7 @@ Figure 2. Working from a local fork to make your changes.
   git checkout -b <my_new_branch> upstream/main
   ```

-3. Make your changes using a text editor.
+1. Make your changes using a text editor.

 At any time, use the `git status` command to see what files you've changed.

@@ -396,7 +396,7 @@ Figure 3. Steps to open a PR from your fork to the K8s/website.
 1. From the **head repository** drop-down menu, select your fork.
 1. From the **compare** drop-down menu, select your branch.
 1. Select **Create Pull Request**.
-`. Add a description for your pull request:
+1. Add a description for your pull request:

    - **Title** (50 characters or less): Summarize the intent of the change.
    - **Description**: Describe the change in more detail.
@@ -484,10 +484,10 @@ conflict. You must resolve all merge conflicts in your PR.

 1. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch:

-    ```shell
-    git fetch upstream
-    git rebase upstream/main
-    ```
+   ```shell
+   git fetch upstream
+   git rebase upstream/main
+   ```

 1. Inspect the results of the rebase:

@@ -512,7 +512,7 @@ conflict. You must resolve all merge conflicts in your PR.

 1. Continue the rebase:

-   ``
+   ```shell
   git rebase --continue
   ```

@@ -10,9 +10,8 @@ weight: 10
 Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls)
 section in the Kubernetes website repository to see open pull requests.

-Reviewing documentation pull requests is a
-great way to introduce yourself to the Kubernetes community.
-It helps you learn the code base and build trust with other contributors.
+Reviewing documentation pull requests is a great way to introduce yourself to the Kubernetes
+community.  It helps you learn the code base and build trust with other contributors.

 Before reviewing, it's a good idea to:

@@ -28,7 +27,6 @@ Before reviewing, it's a good idea to:

 Before you start a review:

-
 - Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
  and ensure that you abide by it at all times.
 - Be polite, considerate, and helpful.
@@ -73,6 +71,7 @@ class third,fourth white

 Figure 1. Review process steps.

+
 1. Go to [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
   You see a list of every open pull request against the Kubernetes website and docs.

@@ -103,12 +102,20 @@ Figure 1. Review process steps.
 4. Go to the **Files changed** tab to start your review.

   1. Click on the `+` symbol  beside the line you want to comment on.
-   1. Fill in any comments you have about the line and click either **Add single comment** (if you
-      have only one comment to make) or  **Start a review** (if you have multiple comments to make).
+   1. Fill in any comments you have about the line and click either **Add single comment**
+      (if you have only one comment to make) or **Start a review** (if you have multiple comments to make).
   1. When finished, click **Review changes** at the top of the page. Here, you can add
-      a summary of your review (and leave some positive comments for the contributor!),
-      approve the PR, comment or request changes as needed. New contributors should always
-      choose **Comment**.
+      a summary of your review (and leave some positive comments for the contributor!).
+      Please always use the "Comment"
+
+     - Avoid clicking the "Request changes" button when finishing your review.
+       If you want to block a PR from being merged before some further changes are made,
+       you can leave a "/hold" comment.
+       Mention why you are setting a hold, and optionally specify the conditions under
+       which the hold can be removed by you or other reviewers.
+
+     - Avoid clicking the "Approve" button when finishing your review.
+       Leaving a "/approve" comment is recommended most of the time.

 ## Reviewing checklist

@@ -361,7 +361,7 @@ Beware.

 ### Katacoda Embedded Live Environment

-This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel).
+This button lets users run Minikube in their browser using the Katacoda Terminal.
 It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete
 Minikube and Kubectl installation process locally.

@@ -74,6 +74,10 @@ PUT       | update
 PATCH     | patch
 DELETE    | delete (for individual resources), deletecollection (for collections)

+{{< caution >}}
+The `get`, `list` and `watch` verbs can all return the full details of a resource. In terms of the returned data they are equivalent. For example, `list` on `secrets` will still reveal the `data` attributes of any returned resources.
+{{< /caution >}}
+
 Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:

 * [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/)
@@ -9,7 +9,7 @@ weight: 95

 <!-- overview -->
 The tables below enumerate the configuration parameters on
-[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) objects, whether the field mutates
+[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) objects, whether the field mutates
 and/or validates pods, and how the configuration values map to the
 [Pod Security Standards](/docs/concepts/security/pod-security-standards/).

@@ -31,9 +31,9 @@ The fields enumerated in this table are part of the `PodSecurityPolicySpec`, whi
 under the `.spec` field path.

 <table class="no-word-break">
-	<caption style="display:none">Mapping PodSecurityPolicySpec fields to Pod Security Standards</caption>
-	<tbody>
-		<tr>
+  <caption style="display:none">Mapping PodSecurityPolicySpec fields to Pod Security Standards</caption>
+  <tbody>
+    <tr>
      <th><code>PodSecurityPolicySpec</code></th>
      <th>Type</th>
      <th>Pod Security Standards Equivalent</th>
@@ -54,19 +54,19 @@ under the `.spec` field path.
      <td>
        <p><b>Baseline</b>: subset of</p>
        <ul>
-					<li><code>AUDIT_WRITE</code></li>
-					<li><code>CHOWN</code></li>
-					<li><code>DAC_OVERRIDE</code></li>
-					<li><code>FOWNER</code></li>
-					<li><code>FSETID</code></li>
-					<li><code>KILL</code></li>
-					<li><code>MKNOD</code></li>
-					<li><code>NET_BIND_SERVICE</code></li>
-					<li><code>SETFCAP</code></li>
-					<li><code>SETGID</code></li>
-					<li><code>SETPCAP</code></li>
-					<li><code>SETUID</code></li>
-					<li><code>SYS_CHROOT</code></li>
+          <li><code>AUDIT_WRITE</code></li>
+          <li><code>CHOWN</code></li>
+          <li><code>DAC_OVERRIDE</code></li>
+          <li><code>FOWNER</code></li>
+          <li><code>FSETID</code></li>
+          <li><code>KILL</code></li>
+          <li><code>MKNOD</code></li>
+          <li><code>NET_BIND_SERVICE</code></li>
+          <li><code>SETFCAP</code></li>
+          <li><code>SETGID</code></li>
+          <li><code>SETPCAP</code></li>
+          <li><code>SETUID</code></li>
+          <li><code>SYS_CHROOT</code></li>
        </ul>
        <p><b>Restricted</b>: empty / undefined / nil OR a list containing <i>only</i> <code>NET_BIND_SERVICE</code>
      </td>
@@ -236,9 +236,9 @@ The [annotations](/docs/concepts/overview/working-with-objects/annotations/) enu
 table can be specified under `.metadata.annotations` on the PodSecurityPolicy object.

 <table class="no-word-break">
-	<caption style="display:none">Mapping PodSecurityPolicy annotations to Pod Security Standards</caption>
-	<tbody>
-		<tr>
+  <caption style="display:none">Mapping PodSecurityPolicy annotations to Pod Security Standards</caption>
+  <tbody>
+    <tr>
      <th><code>PSP Annotation</code></th>
      <th>Type</th>
      <th>Pod Security Standards Equivalent</th>
@@ -54,8 +54,8 @@ it can't be both.

 ClusterRoles have several uses. You can use a ClusterRole to:

-1. define permissions on namespaced resources and be granted within individual namespace(s)
-1. define permissions on namespaced resources and be granted across all namespaces
+1. define permissions on namespaced resources and be granted access within individual namespace(s)
+1. define permissions on namespaced resources and be granted access across all namespaces
 1. define permissions on cluster-scoped resources

 If you want to define a role within a namespace, use a Role; if you want to define
@@ -178,7 +178,8 @@ different Kubernetes components.
 | `RemainingItemCount` | `true` | Beta | 1.16 | |
 | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
-| `SeccompDefault` | `false` | Alpha | 1.22 | |
+| `SeccompDefault` | `false` | Alpha | 1.22 | 1.24 |
+| `SeccompDefault` | `true` | Beta | 1.25 | |
 | `ServerSideFieldValidation` | `false` | Alpha | 1.23 | - |
 | `ServiceInternalTrafficPolicy` | `false` | Alpha | 1.21 | 1.21 |
 | `ServiceInternalTrafficPolicy` | `true` | Beta | 1.22 | |
@@ -90,7 +90,7 @@ kubelet [flags]
 </tr>

 <tr>
-<td colspan="2">--authorization-mode string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>AlwaysAllow</code></td></td>
+<td colspan="2">--authorization-mode string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>AlwaysAllow</code></td>
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
@@ -187,27 +187,6 @@ kubelet [flags]
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

-<tr>
-<td colspan="2">--cni-bin-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>/opt/cni/bin</code></td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">A comma-separated list of full paths of directories in which to search for CNI plugin binaries. This docker-specific flag only works when container-runtime is set to <code>docker</code>. (DEPRECATED: will be removed along with dockershim.)</td>
-</tr>
-
-<tr>
-<td colspan="2">--cni-cache-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>/var/lib/cni/cache</code></td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The full path of the directory in which CNI should store cache files. This docker-specific flag only works when container-runtime is set to <code>docker</code>. (DEPRECATED: will be removed along with dockershim.)</td>
-</tr>
-
-<tr>
-<td colspan="2">--cni-conf-dir string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>/etc/cni/net.d</code></td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; The full path of the directory in which to search for CNI config files. This docker-specific flag only works when container-runtime is set to <code>docker</code>. (DEPRECATED: will be removed along with dockershim.)</td>
-</tr>
-
 <tr>
 <td colspan="2">--config string</td>
 </tr>
@@ -230,20 +209,19 @@ kubelet [flags]
 </tr>

 <tr>
-<td colspan="2">--container-runtime string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>docker</code></td>
+<td colspan="2">--container-runtime string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>remote</code></td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The container runtime to use. Possible values: <code>docker</code>, <code>remote</code>.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The container runtime to use. Possible values: <code>docker</code>, <code>remote</code>. (DEPRECATED: will be removed in 1.27 as the only valid value is 'remote')</td>
 </tr>

 <tr>
-<td colspan="2">--container-runtime-endpoint string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>unix:///var/run/dockershim.sock</code></td>
+<td colspan="2">--container-runtime-endpoint string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: <code>unix:///var/run/dockershim.sock</code>, <code>npipe:////./pipe/dockershim</code>.</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">The endpoint of remote runtime service. Unix Domain SOckets are supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: <code>unix:///var/run/dockershim.sock</code>, <code>npipe:////./pipe/dockershim</code>.</td>
 </tr>

-
 <tr>
 <td colspan="2">--contention-profiling</td>
 </tr>
@@ -276,7 +254,7 @@ kubelet [flags]
 <td colspan="2">--cpu-manager-policy-options mapStringString</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of options to fine-tune the behavior of the selected CPU Manager policy. If not supplied, keep the default behaviour. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">A set of key=value CPU Manager policy options to use, to fine tune their behaviour. If not supplied, keep the default behaviour. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

 <tr>
@@ -286,20 +264,6 @@ kubelet [flags]
 <td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; CPU Manager reconciliation period. Examples: <code>10s</code>, or <code>1m</code>. If not supplied, defaults to node status update frequency. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

-<tr>
-<td colspan="2">--docker-endpoint string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>unix:///var/run/docker.sock</code></td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Use this for the <code>docker</code> endpoint to communicate with. This docker-specific flag only works when container-runtime is set to <code>docker</code>. (DEPRECATED: will be removed along with dockershim.)</td>
-</tr>
-
-<tr>
-<td colspan="2">--dynamic-config-dir string</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The <code>DynamicKubeletConfig</code> feature gate must be enabled to pass this flag. (DEPRECATED: Feature DynamicKubeletConfig is deprecated in 1.22 and will not move to GA. It is planned to be removed from Kubernetes in the version 1.24 or later. Please use alternative ways to update kubelet configuration.)</td>
-</tr>
-
 <tr>
 <td colspan="2">--enable-controller-attach-detach&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>true</code></td>
 </tr>
@@ -398,13 +362,6 @@ kubelet [flags]
 <td></td><td style="line-height: 130%; word-wrap: break-word;">When set to <code>true</code>, hard eviction thresholds will be ignored while calculating node allocatable. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/">here</a> for more details. (DEPRECATED: will be removed in 1.24 or later)</td>
 </tr>

-<tr>
-<td colspan="2">--experimental-check-node-capabilities-before-mount</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] if set to <code>true</code>, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount (DEPRECATED: will be removed in 1.24 or later, in favor of using CSI.)</td>
-</tr>
-
 <tr>
 <td colspan="2">--experimental-kernel-memcg-notification</td>
 </tr>
@@ -412,13 +369,6 @@ kubelet [flags]
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Use kernelMemcgNotification configuration, this flag will be removed in 1.24 or later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

-<tr>
-<td colspan="2">--experimental-log-sanitization bool</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] When enabled, prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)
-</tr>
-
 <tr>
 <td colspan="2">--experimental-mounter-path string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>mount</code></td>
 </tr>
@@ -445,83 +395,76 @@ APIServerIdentity=true|false (ALPHA - default=false)<br/>
 APIServerTracing=true|false (ALPHA - default=false)<br/>
 AllAlpha=true|false (ALPHA - default=false)<br/>
 AllBeta=true|false (BETA - default=false)<br/>
-AnyVolumeDataSource=true|false (ALPHA - default=false)<br/>
+AnyVolumeDataSource=true|false (BETA - default=true)<br/>
 AppArmor=true|false (BETA - default=true)<br/>
 CPUManager=true|false (BETA - default=true)<br/>
 CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)<br/>
 CPUManagerPolicyBetaOptions=true|false (BETA - default=true)<br/>
-CPUManagerPolicyOptions=true|false (ALPHA - default=false)<br/>
+CPUManagerPolicyOptions=true|false (BETA - default=true)<br/>
 CSIInlineVolume=true|false (BETA - default=true)<br/>
 CSIMigration=true|false (BETA - default=true)<br/>
-CSIMigrationAWS=true|false (BETA - default=false)<br/>
-CSIMigrationAzureDisk=true|false (BETA - default=true)<br/>
-CSIMigrationAzureFile=true|false (BETA - default=false)<br/>
+CSIMigrationAWS=true|false (BETA - default=true)<br/>
+CSIMigrationAzureFile=true|false (BETA - default=true)<br/>
 CSIMigrationGCE=true|false (BETA - default=true)<br/>
-CSIMigrationOpenStack=true|false (BETA - default=true)<br/>
 CSIMigrationPortworx=true|false (ALPHA - default=false)<br/>
+CSIMigrationRBD=true|false (ALPHA - default=false)<br/>
 CSIMigrationvSphere=true|false (BETA - default=false)<br/>
-CSIStorageCapacity=true|false (BETA - default=true)<br/>
 CSIVolumeHealth=true|false (ALPHA - default=false)<br/>
-CSRDuration=true|false (BETA - default=true)<br/>
-ControllerManagerLeaderMigration=true|false (BETA - default=true)<br/>
+ContextualLogging=true|false (ALPHA - default=false)<br/>
+CronJobTimeZone=true|false (ALPHA - default=false)<br/>
 CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)<br/>
 CustomResourceValidationExpressions=true|false (ALPHA - default=false)<br/>
 DaemonSetUpdateSurge=true|false (BETA - default=true)<br/>
-DefaultPodTopologySpread=true|false (BETA - default=true)<br/>
 DelegateFSGroupToCSIDriver=true|false (BETA - default=true)<br/>
 DevicePlugins=true|false (BETA - default=true)<br/>
 DisableAcceleratorUsageMetrics=true|false (BETA - default=true)<br/>
 DisableCloudProviders=true|false (ALPHA - default=false)<br/>
 DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)<br/>
 DownwardAPIHugePages=true|false (BETA - default=true)<br/>
-EfficientWatchResumption=true|false (BETA - default=true)<br/>
 EndpointSliceTerminatingCondition=true|false (BETA - default=true)<br/>
 EphemeralContainers=true|false (BETA - default=true)<br/>
-ExpandCSIVolumes=true|false (BETA - default=true)<br/>
-ExpandInUsePersistentVolumes=true|false (BETA - default=true)<br/>
-ExpandPersistentVolumes=true|false (BETA - default=true)<br/>
 ExpandedDNSConfig=true|false (ALPHA - default=false)<br/>
 ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)<br/>
-GRPCContainerProbe=true|false (ALPHA - default=false)<br/>
+GRPCContainerProbe=true|false (BETA - default=true)<br/>
 GracefulNodeShutdown=true|false (BETA - default=true)<br/>
-GracefulNodeShutdownBasedOnPodPriority=true|false (ALPHA - default=false)<br/>
+GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)<br/>
 HPAContainerMetrics=true|false (ALPHA - default=false)<br/>
 HPAScaleToZero=true|false (ALPHA - default=false)<br/>
 HonorPVReclaimPolicy=true|false (ALPHA - default=false)<br/>
-IdentifyPodOS=true|false (ALPHA - default=false)<br/>
+IdentifyPodOS=true|false (BETA - default=true)<br/>
 InTreePluginAWSUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginGCEUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginPortworxUnregister=true|false (ALPHA - default=false)<br/>
-InTreePluginRBDUnregister=true|false (ALPHA - default=false)<br>
+InTreePluginRBDUnregister=true|false (ALPHA - default=false)<br/>
 InTreePluginvSphereUnregister=true|false (ALPHA - default=false)<br/>
-IndexedJob=true|false (BETA - default=true)<br/>
 JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)<br/>
-JobReadyPods=true|false (ALPHA - default=false)<br/>
-JobTrackingWithFinalizers=true|false (BETA - default=true)<br/>
-KubeletCredentialProviders=true|false (ALPHA - default=false)<br/>
+JobReadyPods=true|false (BETA - default=true)<br/>
+JobTrackingWithFinalizers=true|false (BETA - default=false)<br/>
+KubeletCredentialProviders=true|false (BETA - default=true)<br/>
 KubeletInUserNamespace=true|false (ALPHA - default=false)<br/>
 KubeletPodResources=true|false (BETA - default=true)<br/>
 KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)<br/>
+LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)<br/>
 LocalStorageCapacityIsolation=true|false (BETA - default=true)<br/>
 LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)<br/>
 LogarithmicScaleDown=true|false (BETA - default=true)<br/>
+MaxUnavailableStatefulSet=true|false (ALPHA - default=false)<br/>
 MemoryManager=true|false (BETA - default=true)<br/>
 MemoryQoS=true|false (ALPHA - default=false)<br/>
-MixedProtocolLBService=true|false (ALPHA - default=false)<br/>
+MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)<br/>
+MixedProtocolLBService=true|false (BETA - default=true)<br/>
 NetworkPolicyEndPort=true|false (BETA - default=true)<br/>
+NetworkPolicyStatus=true|false (ALPHA - default=false)<br/>
+NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)<br/>
 NodeSwap=true|false (ALPHA - default=false)<br/>
-NonPreemptingPriority=true|false (BETA - default=true)<br/>
-OpenAPIEnums=true|false (ALPHA - default=false)<br/>
-OpenAPIV3=true|false (ALPHA - default=false)<br/>
-PodAffinityNamespaceSelector=true|false (BETA - default=true)<br/>
+OpenAPIEnums=true|false (BETA - default=true)<br/>
+OpenAPIV3=true|false (BETA - default=true)<br/>
 PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)<br/>
 PodDeletionCost=true|false (BETA - default=true)<br/>
-PodOverhead=true|false (BETA - default=true)<br/>
 PodSecurity=true|false (BETA - default=true)<br/>
-PreferNominatedNode=true|false (BETA - default=true)<br/>
 ProbeTerminationGracePeriod=true|false (BETA - default=false)<br/>
 ProcMountType=true|false (ALPHA - default=false)<br/>
 ProxyTerminatingEndpoints=true|false (ALPHA - default=false)<br/>
@@ -529,25 +472,22 @@ QOSReserved=true|false (ALPHA - default=false)<br/>
 ReadWriteOncePod=true|false (ALPHA - default=false)<br/>
 RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)<br/>
 RemainingItemCount=true|false (BETA - default=true)<br/>
-RemoveSelfLink=true|false (BETA - default=true)<br/>
 RotateKubeletServerCertificate=true|false (BETA - default=true)<br/>
 SeccompDefault=true|false (ALPHA - default=false)<br/>
+ServerSideFieldValidation=true|false (ALPHA - default=false)<br/>
+ServiceIPStaticSubrange=true|false (ALPHA - default=false)<br/>
 ServiceInternalTrafficPolicy=true|false (BETA - default=true)<br/>
-ServiceLBNodePortControl=true|false (BETA - default=true)<br/>
-ServiceLoadBalancerClass=true|false (BETA - default=true)<br/>
 SizeMemoryBackedVolumes=true|false (BETA - default=true)<br/>
 StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)<br/>
 StatefulSetMinReadySeconds=true|false (BETA - default=true)<br/>
 StorageVersionAPI=true|false (ALPHA - default=false)<br/>
 StorageVersionHash=true|false (BETA - default=true)<br/>
-SuspendJob=true|false (BETA - default=true)<br/>
 TopologyAwareHints=true|false (BETA - default=true)<br/>
 TopologyManager=true|false (BETA - default=true)<br/>
 VolumeCapacityPriority=true|false (ALPHA - default=false)<br/>
 WinDSR=true|false (ALPHA - default=false)<br/>
 WinOverlay=true|false (BETA - default=true)<br/>
 WindowsHostProcessContainers=true|false (BETA - default=true)<br/>
-csiMigrationRBD=true|false (ALPHA - default=false)<br/>
 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

@@ -628,18 +568,11 @@ csiMigrationRBD=true|false (ALPHA - default=false)<br/>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of <code>--image-gc-high-threshold</code>. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

-<tr>
-<td colspan="2">--image-pull-progress-deadline duration&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>1m0s</code></td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to <code>docker</code>. (DEPRECATED: will be removed along with dockershim.)</td>
-</tr>
-
 <tr>
 <td colspan="2">--image-service-endpoint string</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] The endpoint of remote image service. If not specified, it will be the same with <code>--container-runtime-endpoint</code> by default. Currently UNIX socket endpoint is supported on Linux, while npipe and TCP endpoints are supported on Windows.  Examples: <code>unix:///var/run/dockershim.sock</code>, <code>npipe:////./pipe/dockershim</code></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] The endpoint of remote image service. If not specified, it will be the same with <code>--container-runtime-endpoint</code> by default. Unix Domain Socket are supported on Linux, while npipe and TCP endpoints are supported on Windows.  Examples: <code>unix:///var/run/dockershim.sock</code>, <code>npipe:////./pipe/dockershim</code></td>
 </tr>

 <tr>
@@ -866,20 +799,6 @@ csiMigrationRBD=true|false (ALPHA - default=false)<br/>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Minimum age for an unused image before it is garbage collected. Examples: <code>'300ms'</code>, <code>'10s'</code> or <code>'2h45m'</code>. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

-<tr>
-<td colspan="2">--network-plugin string</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to <code>docker</code>. (DEPRECATED: will be removed along with dockershim.)</td>
-</tr>
-
-<tr>
-<td colspan="2">--network-plugin-mtu int32</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">The MTU to be passed to the network plugin, to override the default. Set to <code>0</code> to use the default 1460 MTU. This docker-specific flag only works when container-runtime is set to <code>docker</code>. (DEPRECATED: will be removed along with dockershim.)</td>
-</tr>
-
 <tr>
 <td colspan="2">--node-ip string</td>
 </tr>
@@ -908,13 +827,6 @@ csiMigrationRBD=true|false (ALPHA - default=false)<br/>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with <code>nodeMonitorGracePeriod</code> in Node controller. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

-<tr>
-<td colspan="2">--non-masquerade-cidr string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>10.0.0.0/8</code></td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">Traffic to IPs outside this range will use IP masquerade. Set to <code>'0.0.0.0/0'</code> to never masquerade. (DEPRECATED: will be removed in a future version)</td>
-</tr>
-
 <tr>
 <td colspan="2">--one-output</td>
 </tr>
@@ -999,13 +911,6 @@ csiMigrationRBD=true|false (ALPHA - default=false)<br/>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">The read-only port for the kubelet to serve on with no authentication/authorization (set to <code>0</code> to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's <code>--config</code> flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
 </tr>

-<tr>
-<td colspan="2">--really-crash-for-testing</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">If true, when panics occur crash. Intended for testing. (DEPRECATED: will be removed in a future version.)</td>
-</tr>
-
 <tr>
 <td colspan="2">--register-node&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>true</code></td>
 </tr>
@@ -1105,7 +1010,7 @@ csiMigrationRBD=true|false (ALPHA - default=false)<br/>
 </tr>

 <tr>
-<td colspan="2">--seccomp-default RuntimeDefault</td>
+<td colspan="2">--seccomp-default string</td>
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">&lt;Warning: Alpha feature&gt; Enable the use of <code>RuntimeDefault</code> as the default seccomp profile for all workloads. The <code>SeccompDefault</code> feature gate must be enabled to allow this flag, which is disabled by default.</td>
@@ -1187,10 +1092,10 @@ csiMigrationRBD=true|false (ALPHA - default=false)<br/>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.<br/>
 Preferred values:
-TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384<br/>
-Insecure values:
-TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.
-(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)
+`TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`, `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA`, `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA`, `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`, `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`, `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256`, `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA`, `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`, `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA`, `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`, `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305`, `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256`, `TLS_RSA_WITH_AES_128_CBC_SHA`, `TLS_RSA_WITH_AES_128_GCM_SHA256`, `TLS_RSA_WITH_AES_256_CBC_SHA`, `TLS_RSA_WITH_AES_256_GCM_SHA384`<br/>
+Insecure values:<br/>
+`TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`, `TLS_ECDHE_ECDSA_WITH_RC4_128_SHA`, `TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA`, `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`, `TLS_ECDHE_RSA_WITH_RC4_128_SHA`, `TLS_RSA_WITH_3DES_EDE_CBC_SHA`, `TLS_RSA_WITH_AES_128_CBC_SHA256`, `TLS_RSA_WITH_RC4_128_SHA`.<br/>
+(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)
 </tr>

 <tr>
@@ -1237,7 +1142,7 @@ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_E
 </tr>

 <tr>
-<td colspan="2">--vmodule &lt;A list of 'pattern=N' string&gt;</td>
+<td colspan="2">--vmodule &lt;A list of 'pattern=N' strings&gt;</td>
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of <code>pattern=N</code> settings for file-filtered logging</td>
@@ -1159,7 +1159,7 @@ This information will be annotated to the Node API object, for later re-use</p>
 <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#taint-v1-core"><code>[]core/v1.Taint</code></a>
 </td>
 <td>
-   <p><code>tains</code> specifies the taints the Node API object should be registered with.
+   <p><code>taints</code> specifies the taints the Node API object should be registered with.
 If this field is unset, i.e. nil, in the <code>kubeadm init</code> process it will be defaulted
 with a control-plane taint for control-plane nodes.
 If you don't want to taint your control-plane node, set this field to an empty list,
@@ -2,9 +2,10 @@
 title: Extensions
 id: Extensions
 date: 2019-02-01
-full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions
+full_link: /docs/concepts/extend-kubernetes/#extensions
 short_description: >
-  Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware.
+  Extensions are software components that extend and deeply integrate with Kubernetes to support
+  new types of hardware.

 aka:
 tags:
@@ -15,4 +16,6 @@ tags:

 <!--more-->

-Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters come with extensions pre-installed. As a result, most Kubernetes users will not need to install [extensions](/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and even fewer users will need to author new ones. 
+Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters
+come with extensions pre-installed. As a result, most Kubernetes users will not need to install
+[extensions](/docs/concepts/extend-kubernetes/) and even fewer users will need to author new ones. 
@@ -2,7 +2,7 @@
 title: Garbage Collection
 id: garbage-collection
 date: 2021-07-07
-full_link: /docs/concepts/workloads/controllers/garbage-collection/
+full_link: /docs/concepts/architecture/garbage-collection/
 short_description: >
  A collective term for the various mechanisms Kubernetes uses to clean up cluster
  resources.
@@ -12,13 +12,16 @@ tags:
 - fundamental
 - operation
 ---
- Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
- cluster resources. 
+
+Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
+cluster resources. 

 <!--more-->

-Kubernetes uses garbage collection to clean up resources like [unused containers and images](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
+Kubernetes uses garbage collection to clean up resources like
+[unused containers and images](/docs/concepts/architecture/garbage-collection/#containers-images),
 [failed Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
 [objects owned by the targeted resource](/docs/concepts/overview/working-with-objects/owners-dependents/),
 [completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
-that have expired or failed.
+that have expired or failed.
+
@@ -68,6 +68,11 @@ kubectl config get-contexts                          # display list of contexts
 kubectl config current-context                       # display the current-context
 kubectl config use-context my-cluster-name           # set the default context to my-cluster-name

+kubectl config set-cluster my-cluster-name           # set a cluster entry in the kubeconfig
+
+# configure the URL to a proxy server to use for requests made by this client in the kubeconfig
+kubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url
+
 # add a new user to your kubeconf that supports basic auth
 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

@@ -182,6 +187,9 @@ kubectl get pods --selector=app=cassandra -o \
 kubectl get configmap myconfig \
  -o jsonpath='{.data.ca\.crt}'

+# Retrieve a base64 encoded value with dashes instead of underscores.
+kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'
+
 # Get all worker nodes (use a selector to exclude results that have a label
 # named 'node-role.kubernetes.io/control-plane')
 kubectl get node --selector='!node-role.kubernetes.io/control-plane'
@@ -511,9 +511,9 @@ The kubelet checks D-value of the size of `/proc/sys/kernel/pid_max` and the PID

 Example: `node.kubernetes.io/out-of-service:NoExecute`

-A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach` 
+A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled on
-`kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. 
+`kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node.

 {{< caution >}}
 Refer to
@@ -645,7 +645,7 @@ This determines whether a user can modify the mode of the source volume when a
 {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} is being
 created from a VolumeSnapshot.

-Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) 
+Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode)
 and the [Kubernetes CSI Developer Documentation](https://kubernetes-csi.github.io/docs/) for more information.

 ## Annotations used for audit
@@ -713,14 +713,3 @@ Used on: Node
 Example: `node-role.kubernetes.io/control-plane:NoSchedule`

 Taint that kubeadm applies on control plane nodes to allow only critical workloads to schedule on them.
-
-### node-role.kubernetes.io/master
-
-Used on: Node
-
-Example: `node-role.kubernetes.io/master:NoSchedule`
-
-Taint that kubeadm applies on control plane nodes to allow only critical workloads to schedule on them.
-
-{{< note >}} Starting in v1.20, this taint is deprecated in favor of `node-role.kubernetes.io/control-plane`
-and will be removed in v1.25.{{< /note >}}
@@ -199,7 +199,7 @@ Static Pod manifest share a set of common properties:

 Please note that:

-1. All images will be pulled from k8s.gcr.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
+1. All images will be pulled from registry.k8s.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
 2. In case of kubeadm is executed in the `--dry-run` mode, static Pods files are written in a temporary folder
 3. Static Pod manifest generation for control plane components can be invoked individually with the [`kubeadm init phase control-plane all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) command

@@ -289,7 +289,7 @@ a local etcd instance running in a Pod with following attributes:

 Please note that:

-1. The etcd image will be pulled from `k8s.gcr.io` by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
+1. The etcd image will be pulled from `registry.k8s.io` by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository
 2. in case of kubeadm is executed in the `--dry-run` mode, the etcd static Pod manifest is written in a temporary folder
 3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) command

@@ -319,12 +319,10 @@ Please note that:
 As soon as the control plane is available, kubeadm executes following actions:

 - Labels the node as control-plane with `node-role.kubernetes.io/control-plane=""`
- Taints the node with `node-role.kubernetes.io/master:NoSchedule` and `node-role.kubernetes.io/control-plane:NoSchedule`
+- Taints the node with `node-role.kubernetes.io/control-plane:NoSchedule`

-Please note that:
-
-1. The `node-role.kubernetes.io/master` taint is deprecated and will be removed in kubeadm version 1.25
-1. Mark control-plane phase phase can be invoked individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) command
+Please note that the phase to mark the control-plane phase phase can be invoked
+individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) command.

 ### Configure TLS-Bootstrapping for node joining

@@ -6,7 +6,9 @@ title: kubeadm init
 content_type: concept
 weight: 20
 ---
+
 <!-- overview -->
+
 This command initializes a Kubernetes control-plane node.

 <!-- body -->
@@ -26,12 +28,12 @@ following steps:
 1. Generates a self-signed CA to set up identities for each component in the cluster. The user can provide their
   own CA cert and/or key by dropping it in the cert directory configured via `--cert-dir`
   (`/etc/kubernetes/pki` by default).
-   The APIServer certs will have additional SAN entries for any `--apiserver-cert-extra-sans` arguments, lowercased if necessary.
+   The APIServer certs will have additional SAN entries for any `--apiserver-cert-extra-sans`
+   arguments, lowercased if necessary.

-1. Writes kubeconfig files in `/etc/kubernetes/`  for
-   the kubelet, the controller-manager and the scheduler to use to connect to the
-   API server, each with its own identity, as well as an additional
-   kubeconfig file for administration named `admin.conf`.
+1. Writes kubeconfig files in `/etc/kubernetes/` for the kubelet, the controller-manager and the
+   scheduler to use to connect to the API server, each with its own identity, as well as an
+   additional kubeconfig file for administration named `admin.conf`.

 1. Generates static Pod manifests for the API server,
   controller-manager and scheduler. In case an external etcd is not provided,
@@ -76,10 +78,12 @@ following steps:

 Kubeadm allows you to create a control-plane node in phases using the `kubeadm init phase` command.

-To view the ordered list of phases and sub-phases you can call `kubeadm init --help`. The list will be located at the top of the help screen and each phase will have a description next to it.
+To view the ordered list of phases and sub-phases you can call `kubeadm init --help`. The list
+will be located at the top of the help screen and each phase will have a description next to it.
 Note that by calling `kubeadm init` all of the phases and sub-phases will be executed in this exact order.

-Some phases have unique flags, so if you want to have a look at the list of available options add `--help`, for example:
+Some phases have unique flags, so if you want to have a look at the list of available options add
+`--help`, for example:

 ```shell
 sudo kubeadm init phase control-plane controller-manager --help
@@ -91,7 +95,8 @@ You can also use `--help` to see the list of sub-phases for a certain parent pha
 sudo kubeadm init phase control-plane --help
 ```

-`kubeadm init` also exposes a flag called `--skip-phases` that can be used to skip certain phases. The flag accepts a list of phase names and the names can be taken from the above ordered list.
+`kubeadm init` also exposes a flag called `--skip-phases` that can be used to skip certain phases.
+The flag accepts a list of phase names and the names can be taken from the above ordered list.

 An example:

@@ -102,7 +107,10 @@ sudo kubeadm init phase etcd local --config=configfile.yaml
 sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml
 ```

-What this example would do is write the manifest files for the control plane and etcd in `/etc/kubernetes/manifests` based on the configuration in `configfile.yaml`. This allows you to modify the files and then skip these phases using `--skip-phases`. By calling the last command you will create a control plane node with the custom manifest files.
+What this example would do is write the manifest files for the control plane and etcd in
+`/etc/kubernetes/manifests` based on the configuration in `configfile.yaml`. This allows you to
+modify the files and then skip these phases using `--skip-phases`. By calling the last command you
+will create a control plane node with the custom manifest files.

 {{< feature-state for_k8s_version="v1.22" state="beta" >}}

@@ -147,15 +155,15 @@ directly to kubeadm is not supported. Instead, it is possible to pass them by
 List of feature gates:

 {{< table caption="kubeadm feature gates" >}}
-Feature | Default | Alpha | Beta
-:-------|:--------|:------|:-----
-`PublicKeysECDSA` | `false` | 1.19 | -
-`RootlessControlPlane` | `false` | 1.22 | -
-`UnversionedKubeletConfigMap` | `true` | 1.22 | 1.23
+Feature | Default | Alpha | Beta | GA
+:-------|:--------|:------|:-----|:----
+`PublicKeysECDSA` | `false` | 1.19 | - | -
+`RootlessControlPlane` | `false` | 1.22 | - | -
+`UnversionedKubeletConfigMap` | `true` | 1.22 | 1.23 | 1.25
 {{< /table >}}

 {{< note >}}
-Once a feature gate goes GA it is removed from this list as its value becomes locked to `true` by default.
+Once a feature gate goes GA its value becomes locked to `true` by default.
 {{< /note >}}

 Feature gate descriptions:
@@ -181,10 +189,6 @@ or `kubeadm upgrade apply`), kubeadm respects the value of `UnversionedKubeletCo
 (during `kubeadm join`, `kubeadm reset`, `kubeadm upgrade ...`), kubeadm attempts to use unversioned ConfigMap name first;
 if that does not succeed, kubeadm falls back to using the legacy (versioned) name for that ConfigMap.

-{{< note >}}
-Setting `UnversionedKubeletConfigMap` to `false` is supported but **deprecated**.
-{{< /note >}}
-
 ### Adding kube-proxy parameters {#kube-proxy}

 For information about kube-proxy parameters in the kubeadm configuration see:
@@ -212,11 +216,11 @@ kubeadm config images pull
 You can pass `--config` to the above commands with a [kubeadm configuration file](#config-file)
 to control the `kubernetesVersion` and `imageRepository` fields.

-All default `k8s.gcr.io` images that kubeadm requires support multiple architectures.
+All default `registry.k8s.io` images that kubeadm requires support multiple architectures.

 ### Using custom images {#custom-images}

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

@@ -225,18 +229,18 @@ Allowed customization are:

 * To provide `kubernetesVersion` which affects the version of the images.
 * To provide an alternative `imageRepository` to be used instead of
-  `k8s.gcr.io`.
+  `registry.k8s.io`.
 * To provide a specific `imageRepository` and `imageTag` for etcd or CoreDNS.

-Image paths between the default `k8s.gcr.io` and a custom repository specified using
+Image paths between the default `registry.k8s.io` and a custom repository specified using
 `imageRepository` may differ for backwards compatibility reasons. For example,
-one image might have a subpath at `k8s.gcr.io/subpath/image`, but be defaulted
+one image might have a subpath at `registry.k8s.io/subpath/image`, but be defaulted
 to `my.customrepository.io/image` when using a custom repository.

 To ensure you push the images to your custom repository in paths that kubeadm
 can consume, you must:

-* Pull images from the defaults paths at `k8s.gcr.io` using `kubeadm config images {list|pull}`.
+* Pull images from the defaults paths at `registry.k8s.io` using `kubeadm config images {list|pull}`.
 * Push images to the paths from `kubeadm config images list --config=config.yaml`,
 where `config.yaml` contains the custom `imageRepository`, and/or `imageTag`
 for etcd and CoreDNS.
@@ -249,7 +253,7 @@ To set a custom image for these you need to configure this in your
 to use the image.
 Consult the documentation for your container runtime to find out how to change this setting;
 for selected container runtimes, you can also find advice within the
-[Container Runtimes]((/docs/setup/production-environment/container-runtimes/) topic.
+[Container Runtimes](/docs/setup/production-environment/container-runtimes/) topic.

 ### Uploading control-plane certificates to the cluster

@@ -284,30 +288,35 @@ and certificate renewal.

 ### Managing the kubeadm drop-in file for the kubelet {#kubelet-drop-in}

-The `kubeadm` package ships with a configuration file for running the `kubelet` by `systemd`. Note that the kubeadm CLI never touches this drop-in file. This drop-in file is part of the kubeadm DEB/RPM package.
+The `kubeadm` package ships with a configuration file for running the `kubelet` by `systemd`.
+Note that the kubeadm CLI never touches this drop-in file. This drop-in file is part of the kubeadm
+DEB/RPM package.

-For further information, see [Managing the kubeadm drop-in file for systemd](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#the-kubelet-drop-in-file-for-systemd).
+For further information, see
+[Managing the kubeadm drop-in file for systemd](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/#the-kubelet-drop-in-file-for-systemd).

 ### Use kubeadm with CRI runtimes

-By default kubeadm attempts to detect your container runtime. For more details on this detection, see
-the [kubeadm CRI installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).
+By default kubeadm attempts to detect your container runtime. For more details on this detection,
+see the [kubeadm CRI installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime).

 ### Setting the node name

-By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name` flag.
+By default, `kubeadm` assigns a node name based on a machine's host address.
+You can override this setting with the `--node-name` flag.
 The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
 value to the kubelet.

-Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
+Be aware that overriding the hostname can
+[interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).

 ### Automating kubeadm

 Rather than copying the token you obtained from `kubeadm init` to each node, as
-in the [basic kubeadm tutorial](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), you can parallelize the
-token distribution for easier automation. To implement this automation, you must
-know the IP address that the control-plane node will have after it is started,
-or use a DNS name or an address of a load balancer.
+in the [basic kubeadm tutorial](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/),
+you can parallelize the token distribution for easier automation. To implement this automation,
+you must know the IP address that the control-plane node will have after it is started, or use a
+DNS name or an address of a load balancer.

 1. Generate a token. This token must have the form  `<6 character string>.<16
   character string>`. More formally, it must match the regex:
@@ -341,7 +350,11 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku
 ## {{% heading "whatsnext" %}}

 * [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
-`kubeadm init` phases
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
-* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
+  `kubeadm init` phases
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes
+  worker node and join it to the cluster
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes
+  cluster to a newer version
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made
+  to this host by `kubeadm init` or `kubeadm join`
+
@@ -39,7 +39,7 @@ The JSON and Protobuf serialization schemas follow the same guidelines for
 schema changes. The following descriptions cover both formats.

 The API versioning and software versioning are indirectly related.
-The [API and release versioning proposal](https://git.k8s.io/design-proposals-archive/release/versioning.md)
+The [API and release versioning proposal](https://git.k8s.io/sig-release/release-engineering/versioning.md)
 describes the relationship between API versioning and software versioning.

 Different API versions indicate different levels of stability and support. You
@@ -179,9 +179,9 @@ Follow the instructions for [getting started with containerd](https://github.com
 {{% tab name="Linux" %}}
 You can find this file under the path `/etc/containerd/config.toml`.
 {{% /tab %}}
-{{< tab name="Windows" >}}
+{{% tab name="Windows" %}}
 You can find this file under the path `C:\Program Files\containerd\config.toml`.
-{{< /tab >}}
+{{% /tab %}}
 {{< /tabs >}}

 On Linux the default CRI socket for containerd is `/run/containerd/containerd.sock`.
@@ -134,13 +134,13 @@ etcd:
      election-timeout: 1000
 ```

-## Customizing the control plane with patches {#patches}
+## Customizing with patches {#patches}

 {{< feature-state for_k8s_version="v1.22" state="beta" >}}

 Kubeadm allows you to pass a directory with patch files to `InitConfiguration` and `JoinConfiguration`
-on individual nodes. These patches can be used as the last customization step before the control
-plane component manifests are written to disk.
+on individual nodes. These patches can be used as the last customization step before component configuration
+is written to disk.

 You can pass this file to `kubeadm init` with `--config <YOUR CONFIG YAML>`:

@@ -168,7 +168,8 @@ patches:
 The directory must contain files named `target[suffix][+patchtype].extension`.
 For example, `kube-apiserver0+merge.yaml` or just `etcd.json`.

- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` and `etcd`.
+- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `etcd`
+and `kubeletconfiguration`.
 - `patchtype` can be one of `strategic`, `merge` or `json` and these must match the patching formats
 [supported by kubectl](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch).
 The default `patchtype` is `strategic`.
@@ -183,20 +184,22 @@ flag, which must point to the same directory. `kubeadm upgrade` currently does n
 API structure that can be used for the same purpose.
 {{< /note >}}

-## Customizing the kubelet
+## Customizing the kubelet {#kubelet}

-To customize the kubelet you can add a `KubeletConfiguration` next to the `ClusterConfiguration` or
-`InitConfiguration` separated by `---` within the same configuration file. This file can then be passed to `kubeadm init`.
+To customize the kubelet you can add a [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
+next to the `ClusterConfiguration` or `InitConfiguration` separated by `---` within the same configuration file.
+This file can then be passed to `kubeadm init` and kubeadm will apply the same base `KubeletConfiguration`
+to all nodes in the cluster.

-{{< note >}}
-kubeadm applies the same `KubeletConfiguration` to all nodes in the cluster. To apply node
-specific settings you can use kubelet flags as overrides by passing them in the `nodeRegistration.kubeletExtraArgs`
-field supported by both `InitConfiguration` and `JoinConfiguration`. Some kubelet flags are deprecated,
-so check their status in the [kubelet reference documentation](/docs/reference/command-line-tools-reference/kubelet)
-before using them.
-{{< /note >}}
+For applying instance-specific configuration over the base `KubeletConfiguration` you can use the
+[`kubeletconfiguration` patch target](#patches).

-For more details see [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)
+Alternatively, you can use kubelet flags as overrides by passing them in the
+`nodeRegistration.kubeletExtraArgs` field supported by both `InitConfiguration` and `JoinConfiguration`.
+Some kubelet flags are deprecated, so check their status in the
+[kubelet reference documentation](/docs/reference/command-line-tools-reference/kubelet) before using them.
+
+For additional details see [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)

 ## Customizing kube-proxy

@@ -88,7 +88,7 @@ After you initialize your control-plane, the kubelet runs normally.
 ### Preparing the required container images

 This step is optional and only applies in case you wish `kubeadm init` and `kubeadm join`
-to not download the default container images which are hosted at `k8s.gcr.io`.
+to not download the default container images which are hosted at `registry.k8s.io`.

 Kubeadm has commands that can help you pre-pull the required images
 when creating a cluster without an internet connection on its nodes.
@@ -305,7 +305,7 @@ reasons. If you want to be able to schedule Pods on the control plane nodes,
 for example for a single machine Kubernetes cluster, run:

 ```bash
-kubectl taint nodes --all node-role.kubernetes.io/control-plane- node-role.kubernetes.io/master-
+kubectl taint nodes --all node-role.kubernetes.io/control-plane-
 ```

 The output will look something like:
@@ -315,14 +315,9 @@ node "test-01" untainted
 ...
 ```

-This will remove the `node-role.kubernetes.io/control-plane` and
-`node-role.kubernetes.io/master` taints from any nodes that have them,
-including the control plane nodes, meaning that the scheduler will then be able
-to schedule Pods everywhere.
-
-{{< note >}}
-The `node-role.kubernetes.io/master` taint is deprecated and kubeadm will stop using it in version 1.25.
-{{< /note >}}
+This will remove the `node-role.kubernetes.io/control-plane:NoSchedule` taint
+from any nodes that have it, including the control plane nodes, meaning that the
+scheduler will then be able to schedule Pods everywhere.

 ### Joining your nodes {#join-nodes}

@@ -97,7 +97,7 @@ _See [External etcd topology](/docs/setup/production-environment/tools/kubeadm/h

 ### Container images

-Each host should have access read and fetch images from the Kubernetes container image registry, `k8s.gcr.io`.
+Each host should have access read and fetch images from the Kubernetes container image registry, `registry.k8s.io`.
 If you want to deploy a highly-available cluster where the hosts do not have access to pull images, this is possible. You must ensure by some other means that the correct container images are already available on the relevant hosts.

 ### Command line interface {#kubectl}
@@ -226,8 +226,8 @@ option. Your cluster requirements may need a different configuration.
   As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
   {{< /caution >}}

-1. Apply the CNI plugin of your choice:  
-   [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) 
+1. Apply the CNI plugin of your choice:
+   [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)
   to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the
   kubeadm configuration file (if applicable).

@@ -87,20 +87,21 @@ networking, or other host-specific parameters. The following list provides a few
 - To specify the container runtime you must set its endpoint with the
 `--container-runtime-endpoint=<path>` flag.

-You can specify these flags by configuring an individual kubelet's configuration in your service manager,
-such as systemd.
+The recommended way of applying such instance-specific configuration is by using
+[`KubeletConfiguration` patches](/docs/setup/production-environment/tools/kubeadm/control-plane-flags#patches).

 ## Configure kubelets using kubeadm

-It is possible to configure the kubelet that kubeadm will start if a custom `KubeletConfiguration`
+It is possible to configure the kubelet that kubeadm will start if a custom
+[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
 API object is passed with a configuration file like so `kubeadm ... --config some-config-file.yaml`.

 By calling `kubeadm config print init-defaults --component-configs KubeletConfiguration` you can
 see all the default values for this structure.

-Also have a look at the
-[reference for the KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/)
-for more information on the individual fields.
+It is also possible to apply instance-specific patches over the base `KubeletConfiguration`.
+Have a look at [Customizing the kubelet](/docs/setup/production-environment/tools/kubeadm/control-plane-flags#customizing-the-kubelet)
+for more details.

 ### Workflow when using `kubeadm init`

@@ -31,7 +31,7 @@ etcd cluster of three members that can be used by kubeadm during cluster creatio
  the kubeadm config file.
 * Each host must have systemd and a bash compatible shell installed.
 * Each host must [have a container runtime, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
-* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using
+* Each host should have access to the Kubernetes container image registry (`registry.k8s.io`) or list/pull the required etcd image using
 `kubeadm config images list/pull`. This guide will setup etcd instances as
 [static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
 * Some infrastructure to copy files between hosts. For example `ssh` and `scp`
@@ -276,7 +276,7 @@ on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/set
    ```sh
    docker run --rm -it \
    --net host \
-    -v /etc/kubernetes:/etc/kubernetes k8s.gcr.io/etcd:${ETCD_TAG} etcdctl \
+    -v /etc/kubernetes:/etc/kubernetes registry.k8s.io/etcd:${ETCD_TAG} etcdctl \
    --cert /etc/kubernetes/pki/etcd/peer.crt \
    --key /etc/kubernetes/pki/etcd/peer.key \
    --cacert /etc/kubernetes/pki/etcd/ca.crt \
@@ -351,7 +351,7 @@ A known solution is to patch the kube-proxy DaemonSet to allow scheduling it on
 nodes regardless of their conditions, keeping it off of other nodes until their initial guarding
 conditions abate:
 ```
-kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/master" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }'
+kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }'
 ```

 The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027).
@@ -13,10 +13,10 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
 * a highly available cluster
 * composable attributes
 * support for most popular Linux distributions
-  * Ubuntu 16.04, 18.04, 20.04
+  * Ubuntu 16.04, 18.04, 20.04, 22.04
  * CentOS/RHEL/Oracle Linux 7, 8
  * Debian Buster, Jessie, Stretch, Wheezy
-  * Fedora 31, 32
+  * Fedora 34, 35
  * Fedora CoreOS
  * openSUSE Leap 15
  * Flatcar Container Linux by Kinvolk
@@ -33,7 +33,7 @@ To choose a tool which best fits your use case, read [this comparison](https://g

 Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):

-* **Ansible v2.9 and python-netaddr are installed on the machine that will run Ansible commands**
+* **Ansible v2.11 and python-netaddr are installed on the machine that will run Ansible commands**
 * **Jinja 2.11 (or newer) is required to run the Ansible Playbooks**
 * The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
 * The target servers are configured to allow **IPv4 forwarding**
@@ -41,13 +41,12 @@ See [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootl

 ### minikube

-[minikube](https://minikube.sigs.k8s.io/) also supports running Kubernetes inside Rootless Docker.
+[minikube](https://minikube.sigs.k8s.io/) also supports running Kubernetes inside Rootless Docker or Rootless Podman.

-See the page about the [docker](https://minikube.sigs.k8s.io/docs/drivers/docker/) driver in the Minikube documentation.
+See the Minikube documentation:

-Rootless Podman is not supported.
-
-<!-- Supporting rootless podman is discussed in https://github.com/kubernetes/minikube/issues/8719 -->
+* [Rootless Docker](https://minikube.sigs.k8s.io/docs/drivers/docker/)
+* [Rootless Podman](https://minikube.sigs.k8s.io/docs/drivers/podman/)

 ## Running Kubernetes inside Unprivileged Containers

@@ -13,11 +13,6 @@ To avoid CNI plugin-related errors, verify that you are using or upgrading to a
 container runtime that has been tested to work correctly with your version of
 Kubernetes.

-For example, the following container runtimes are being prepared, or have already been prepared, for Kubernetes v1.24:
-
-* containerd v1.6.4 and later, v1.5.11 and later
-* The CRI-O v1.24.0 and later
-
 ## About the "Incompatible CNI versions" and "Failed to destroy network for sandbox" errors

 Service issues exist for pod CNI network setup and tear down in containerd
@@ -68,5 +68,5 @@ e.g. [conformance image](https://github.com/kubernetes/kubernetes/blob/master/te
 admission controller. To get started with `cosigned` here are a few helpful
 resources:

-* [Installation](https://github.com/sigstore/helm-charts/tree/main/charts/cosigned)
-* [Configuration Options](https://github.com/sigstore/cosign/tree/main/config)
+* [Installation](https://github.com/sigstore/cosign#installation)
+* [Configuration Options](https://github.com/sigstore/cosign/blob/main/USAGE.md#detailed-usage)
@@ -362,9 +362,9 @@ and create it:
 kubectl create --validate=false -f my-crontab.yaml -o yaml
 ```

-your output is similar to:
+Your output is similar to:

-```console
+```yaml
 apiVersion: stable.example.com/v1
 kind: CronTab
 metadata:
@@ -836,7 +836,7 @@ Validation Rules Examples:
 | `has(self.expired) && self.created + self.ttl < self.expired`                    | Validate that 'expired' date is after a 'create' date plus a 'ttl' duration       |
 | `self.health.startsWith('ok')`                                                   | Validate a 'health' string field has the prefix 'ok'                              |
 | `self.widgets.exists(w, w.key == 'x' && w.foo < 10)`                             | Validate that the 'foo' property of a listMap item with a key 'x' is less than 10 |
-| `type(self) == string ? self == '100%' : self == 1000`                           | Validate an int-or-string field for both the the int and string cases             |
+| `type(self) == string ? self == '100%' : self == 1000`                           | Validate an int-or-string field for both the int and string cases             |
 | `self.metadata.name.startsWith(self.prefix)`                                     | Validate that an object's name has the prefix of another field value              |
 | `self.set1.all(e, !(e in self.set2))`                                            | Validate that two listSets are disjoint                                           |
 | `size(self.names) == size(self.details) && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet           |
@@ -844,7 +844,6 @@ Validation Rules Examples:

 Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#evaluation)

-
 - If the Rule is scoped to the root of a resource, it may make field selection into any fields
  declared in the OpenAPIv3 schema of the CRD as well as `apiVersion`, `kind`, `metadata.name` and
  `metadata.generateName`. This includes selection of fields in both the `spec` and `status` in the
@@ -7,7 +7,7 @@ description: Configure the kubelet's image credential provider plugin
 content_type: task
 ---

-{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.24" state="beta" >}}

 <!-- overview -->

@@ -165,8 +165,8 @@ kubectl create --edit -f /tmp/srv.yaml
 ## {{% heading "whatsnext" %}}


-* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
-* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
 * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
 * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

@@ -161,7 +161,7 @@ template:


 * [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
-* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/)
 * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
 * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

@@ -6,34 +6,63 @@ weight: 10

 <!-- overview -->

-In this tutorial you will learn how and why to externalize your microservice’s configuration.  Specifically, you will learn how to use Kubernetes ConfigMaps and Secrets to set environment variables and then consume them using MicroProfile Config.
+In this tutorial you will learn how and why to externalize your microservice’s configuration.
+Specifically, you will learn how to use Kubernetes ConfigMaps and Secrets to set environment
+variables and then consume them using MicroProfile Config.


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

 ### Creating Kubernetes ConfigMaps & Secrets
-There are several ways to set environment variables for a Docker container in Kubernetes, including: Dockerfile, kubernetes.yml, Kubernetes ConfigMaps, and Kubernetes Secrets.  In the tutorial, you will learn how to use the latter two for setting your environment variables whose values will be injected into your microservices.  One of the benefits for using ConfigMaps and Secrets is that they can be re-used across multiple containers, including being assigned to different environment variables for the different containers.

-ConfigMaps are API Objects that store non-confidential key-value pairs.  In the Interactive Tutorial you will learn how to use a ConfigMap to store the application's name.  For more information regarding ConfigMaps, you can find the documentation [here](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+There are several ways to set environment variables for a Docker container in Kubernetes,
+including: Dockerfile, kubernetes.yml, Kubernetes ConfigMaps, and Kubernetes Secrets.  In the
+tutorial, you will learn how to use the latter two for setting your environment variables whose
+values will be injected into your microservices.  One of the benefits for using ConfigMaps and
+Secrets is that they can be re-used across multiple containers, including being assigned to
+different environment variables for the different containers.

-Although Secrets are also used to store key-value pairs, they differ from ConfigMaps in that they're intended for confidential/sensitive information and are stored using Base64 encoding.  This makes secrets the appropriate choice for storing such things as credentials, keys, and tokens, the former of which you'll do in the Interactive Tutorial.  For more information on Secrets, you can find the documentation [here](/docs/concepts/configuration/secret/).
+ConfigMaps are API Objects that store non-confidential key-value pairs.  In the Interactive
+Tutorial you will learn how to use a ConfigMap to store the application's name.  For more
+information regarding ConfigMaps, you can find the documentation
+[here](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+
+Although Secrets are also used to store key-value pairs, they differ from ConfigMaps in that
+they're intended for confidential/sensitive information and are stored using Base64 encoding.
+This makes secrets the appropriate choice for storing such things as credentials, keys, and
+tokens, the former of which you'll do in the Interactive Tutorial.  For more information on
+Secrets, you can find the documentation [here](/docs/concepts/configuration/secret/).


 ### Externalizing Config from Code
-Externalized application configuration is useful because configuration usually changes depending on your environment.  In order to accomplish this, we'll use Java's Contexts and Dependency Injection (CDI) and MicroProfile Config. MicroProfile Config is a feature of MicroProfile, a set of open Java technologies for developing and deploying cloud-native microservices.

-CDI provides a standard dependency injection capability enabling an application to be assembled from collaborating, loosely-coupled beans.  MicroProfile Config provides apps and microservices a standard way to obtain config properties from various sources, including the application, runtime, and environment.  Based on the source's defined priority, the properties are automatically combined into a single set of properties that the application can access via an API.  Together, CDI & MicroProfile will be used in the Interactive Tutorial to retrieve the externally provided properties from the Kubernetes ConfigMaps and Secrets and get injected into your application code.
+Externalized application configuration is useful because configuration usually changes depending
+on your environment.  In order to accomplish this, we'll use Java's Contexts and Dependency
+Injection (CDI) and MicroProfile Config. MicroProfile Config is a feature of MicroProfile, a set
+of open Java technologies for developing and deploying cloud-native microservices.

-Many open source frameworks and runtimes implement and support MicroProfile Config.  Throughout the interactive tutorial, you'll be using Open Liberty, a flexible open-source Java runtime for building and running cloud-native apps and microservices.  However, any MicroProfile compatible runtime could be used instead. 
+CDI provides a standard dependency injection capability enabling an application to be assembled
+from collaborating, loosely-coupled beans.  MicroProfile Config provides apps and microservices a
+standard way to obtain config properties from various sources, including the application, runtime,
+and environment.  Based on the source's defined priority, the properties are automatically
+combined into a single set of properties that the application can access via an API.  Together,
+CDI & MicroProfile will be used in the Interactive Tutorial to retrieve the externally provided
+properties from the Kubernetes ConfigMaps and Secrets and get injected into your application code.
+
+Many open source frameworks and runtimes implement and support MicroProfile Config.  Throughout
+the interactive tutorial, you'll be using Open Liberty, a flexible open-source Java runtime for
+building and running cloud-native apps and microservices.  However, any MicroProfile compatible
+runtime could be used instead. 


 ## {{% heading "objectives" %}}

 * Create a Kubernetes ConfigMap and Secret
 * Inject microservice configuration using MicroProfile Config
-
  
 <!-- lessoncontent -->

 ## Example: Externalizing config using MicroProfile, ConfigMaps and Secrets
-### [Start Interactive Tutorial](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) 
+
+[Start Interactive Tutorial](/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/) 
+
@@ -17,7 +17,8 @@ created. This tutorial shows you how to enforce the `baseline` Pod Security
 Standard at the cluster level which applies a standard configuration
 to all namespaces in a cluster.

-To apply Pod Security Standards to specific namespaces, refer to [Apply Pod Security Standards at the namespace level](/docs/tutorials/security/ns-level-pss).
+To apply Pod Security Standards to specific namespaces, refer to
+[Apply Pod Security Standards at the namespace level](/docs/tutorials/security/ns-level-pss).

 If you are running a version of Kubernetes other than v{{< skew currentVersion >}},
 check the documentation for that version.
@@ -17,7 +17,7 @@ one namespace at a time.

 You can also apply Pod Security Standards to multiple namespaces at once at the cluster
 level. For instructions, refer to
-[Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss).
+[Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/).

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

@@ -39,7 +39,7 @@ profiles that give only the necessary privileges to your container processes.
 In order to complete all steps in this tutorial, you must install
 [kind](/docs/tasks/tools/#kind) and [kubectl](/docs/tasks/tools/#kubectl).

-This tutorial shows some examples that are still alpha (since v1.22) and
+This tutorial shows some examples that are still beta (since v1.25) and
 others that use only generally available seccomp functionality. You should
 make sure that your cluster is
 [configured correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version)
@@ -112,7 +112,7 @@ See [Nodes](https://kind.sigs.k8s.io/docs/user/configuration/#nodes) within the
 kind documentation about configuration for more details on this.
 This tutorial assumes you are using Kubernetes {{< param "version" >}}.

-As an alpha feature, you can configure Kubernetes to use the profile that the
+As a beta feature, you can configure Kubernetes to use the profile that the
 {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
 prefers by default, rather than falling back to `Unconfined`.
 If you want to try that, see
@@ -159,11 +159,12 @@ running within kind.

 ## Enable the use of `RuntimeDefault` as the default seccomp profile for all workloads

-{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+{{< feature-state state="beta" for_k8s_version="v1.25" >}}

-`SeccompDefault` is an optional kubelet
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates) as
-well as corresponding `--seccomp-default`
+To use seccomp profile defaulting, you must run the kubelet with the `SeccompDefault`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled
+(this is the default). You must also explicitly enable the defaulting behavior for each
+node where you want to use this with the corresponding `--seccomp-default`
 [command line flag](/docs/reference/command-line-tools-reference/kubelet).
 Both have to be enabled simultaneously to use the feature.

@@ -196,12 +197,20 @@ If you were introducing this feature into production-like cluster, the Kubernete
 recommends that you enable this feature gate on a subset of your nodes and then
 test workload execution before rolling the change out cluster-wide.

-More detailed information about a possible upgrade and downgrade strategy can be
-found in the [related Kubernetes Enhancement Proposal (KEP)](https://github.com/kubernetes/enhancements/tree/a70cc18/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy).
+You can find more detailed information about a possible upgrade and downgrade strategy
+in the related Kubernetes Enhancement Proposal (KEP):
+[Enable seccomp by default](https://github.com/kubernetes/enhancements/tree/9a124fd29d1f9ddf2ff455c49a630e3181992c25/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy).

-Since the feature is in alpha state it is disabled per default. To enable it,
-pass the flags `--feature-gates=SeccompDefault=true --seccomp-default` to the
-`kubelet` CLI or enable it via the [kubelet configuration
+Kubernetes {{< skew currentVersion >}} lets you configure the seccomp profile
+that applies when the spec for a Pod doesn't define a specific seccomp profile.
+This is a beta feature and the corresponding `SeccompDefault` [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled by
+default. However, you still need to enable this defaulting for each node where
+you would like to use it.
+
+If you are running a Kubernetes {{< skew currentVersion >}} cluster and want to
+enable the feature, either run the kubelet with the `--seccomp-default` command
+line flag, or enable it through the [kubelet configuration
 file](/docs/tasks/administer-cluster/kubelet-config-file/). To enable the
 feature gate in [kind](https://kind.sigs.k8s.io), ensure that `kind` provides
 the minimum required Kubernetes version and enables the `SeccompDefault` feature
@@ -2,7 +2,7 @@ apiVersion: apiserver.k8s.io/v1beta1
 kind: EgressSelectorConfiguration
 egressSelections:
 # Since we want to control the egress traffic to the cluster, we use the
-# "cluster" as the name. Other supported values are "etcd", and "master".
+# "cluster" as the name. Other supported values are "etcd", and "controlplane".
 - name: cluster
  connection:
    # This controls the protocol between the API Server and the Konnectivity
@@ -7,7 +7,7 @@ spec:
    spec:
      containers:
      - name: pi
-        image: perl:5.34
+        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4
@@ -8,11 +8,10 @@ spec:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
-          - key: topology.kubernetes.io/zone
+          - key: kubernetes.io/os
            operator: In
            values:
-            - antarctica-east1
-            - antarctica-west1
+            - linux
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
@@ -8,10 +8,11 @@ spec:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
-          - key: kubernetes.io/os
+          - key: topology.kubernetes.io/zone
            operator: In
            values:
-            - linux
+            - antarctica-east1
+            - antarctica-west1
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
@@ -78,7 +78,6 @@ releases may also occur in between these.

 | Monthly Patch Release | Cherry Pick Deadline | Target date |
 | --------------------- | -------------------- | ----------- |
-| July 2022             | 2022-07-08           | 2022-07-13  |
 | August 2022           | 2022-08-12           | 2022-08-17  |
 | September 2022        | 2022-09-09           | 2022-09-14  |
 | October 2022          | 2022-10-07           | 2022-10-12  |
@@ -87,24 +86,28 @@ releases may also occur in between these.

 ### 1.24

-Next patch release is **1.24.1**
+Next patch release is **1.24.4**

-End of Life for **1.24** is **2023-09-29**
+End of Life for **1.24** is **2023-07-28**

 | PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
 |---------------|----------------------|-------------|------|
+| 1.24.4        | 2022-08-12           | 2022-08-17  |      |
 | 1.24.3        | 2022-07-08           | 2022-07-13  |      |
 | 1.24.2        | 2022-06-10           | 2022-06-15  |      |
 | 1.24.1        | 2022-05-20           | 2022-05-24  |      |

 ### 1.23

+Next patch release is **1.23.10**
+
 **1.23** enters maintenance mode on **2022-12-28**.

 End of Life for **1.23** is **2023-02-28**.

 | Patch Release | Cherry Pick Deadline | Target Date | Note |
 |---------------|----------------------|-------------|------|
+| 1.23.10       | 2022-08-12           | 2022-08-17  |      |
 | 1.23.9        | 2022-07-08           | 2022-07-13  |      |
 | 1.23.8        | 2022-06-10           | 2022-06-15  |      |
 | 1.23.7        | 2022-05-20           | 2022-05-24  |      |
@@ -117,12 +120,15 @@ End of Life for **1.23** is **2023-02-28**.

 ### 1.22

+Next patch release is **1.22.13**
+
 **1.22** enters maintenance mode on **2022-08-28**

 End of Life for **1.22** is **2022-10-28**

 | Patch Release | Cherry Pick Deadline | Target Date | Note |
 |---------------|----------------------|-------------|------|
+| 1.22.13       | 2022-08-12           | 2022-08-17  |      |
 | 1.22.12       | 2022-07-08           | 2022-07-13  |      |
 | 1.22.11       | 2022-06-10           | 2022-06-15  |      |
 | 1.22.10       | 2022-05-20           | 2022-05-24  |      |
@@ -4,8 +4,8 @@ type: docs
 ---

 "Release Managers" is an umbrella term that encompasses the set of Kubernetes
-contributors responsible for maintaining release branches, tagging releases,
-and building/packaging Kubernetes.
+contributors responsible for maintaining release branches and creating releases
+by using the tools SIG Release provides.

 The responsibilities of each role are described below.

@@ -133,7 +133,9 @@ referred to as Release Manager shadows. They are responsible for:
 GitHub Mentions: @kubernetes/release-engineering

 - Arnaud Meukam ([@ameukam](https://github.com/ameukam))
+- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))
 - Jim Angel ([@jimangel](https://github.com/jimangel))
+- Joseph Sandoval ([@jrsapi](https://github.com/jrsapi))
 - Joyce Kung ([@thejoycekung](https://github.com/thejoycekung))
 - Max Körbächer ([@mkorbi](https://github.com/mkorbi))
 - Seth McCombs ([@sethmccombs](https://github.com/sethmccombs))
@@ -124,7 +124,7 @@ The general labeling process should be consistent across artifact types.
  referring to a release MAJOR.MINOR `vX.Y` version.

  See also
-  [release versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md).
+  [release versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md).

 - *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone.

@@ -136,7 +136,7 @@ The general labeling process should be consistent across artifact types.

 ## The Release Cycle

-![Image of one Kubernetes release cycle](release-cycle.jpg)
+![Image of one Kubernetes release cycle](/images/releases/release-cycle.jpg)

 Kubernetes releases currently happen approximately three times per year.

@@ -204,7 +204,7 @@ back to the release branch. The release is built from the release branch.

 Each release is part of a broader Kubernetes lifecycle:

-![Image of Kubernetes release lifecycle spanning three releases](release-lifecycle.jpg)
+![Image of Kubernetes release lifecycle spanning three releases](/images/releases/release-lifecycle.jpg)

 ## Removal Of Items From The Milestone

@@ -21,7 +21,7 @@ Specific cluster deployment tools may place additional restrictions on version s
 ## Supported versions

 Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
-For more information, see [Kubernetes Release Versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md#kubernetes-release-versioning).
+For more information, see [Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning).

 The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew currentVersion >}}, {{< skew currentVersionAddMinor -1 >}}, {{< skew currentVersionAddMinor -2 >}}).  Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.

@@ -8,7 +8,7 @@ weight: 10

 <!-- overview -->

-Un nodo es una máquina de trabajo en Kubernetes, previamente conocida como `minion`. Un nodo puede ser una máquina virtual o física, dependiendo del tipo de clúster. Cada nodo está gestionado por el componente máster y contiene los servicios necesarios para ejecutar [pods](/docs/concepts/workloads/pods/pod). Los servicios en un nodo incluyen el [container runtime](/docs/concepts/overview/components/#node-components), kubelet y el kube-proxy. Accede a la sección [The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) en el documento de diseño de arquitectura para más detalle.
+Un nodo es una máquina de trabajo en Kubernetes, previamente conocida como `minion`. Un nodo puede ser una máquina virtual o física, dependiendo del tipo de clúster. Cada nodo está gestionado por el componente máster y contiene los servicios necesarios para ejecutar [pods](/docs/concepts/workloads/pods/pod). Los servicios en un nodo incluyen el [container runtime](/docs/concepts/overview/components/#node-components), kubelet y el kube-proxy. Accede a la sección [The Kubernetes Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) en el documento de diseño de arquitectura para más detalle.



@@ -676,7 +676,7 @@ La cantidad de recursos disponibles para los pods es menor que la capacidad del
 los demonios del sistema utilizan una parte de los recursos disponibles. El campo `allocatable`
 [NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
 indica la cantidad de recursos que están disponibles para los Pods. Para más información, mira 
-[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
+[Node Allocatable Resources](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md).

 La característica [resource quota](/docs/concepts/policy/resource-quotas/) se puede configurar
 para limitar la cantidad total de recursos que se pueden consumir. Si se usa en conjunto
@@ -757,7 +757,7 @@ Puedes ver que el Contenedor fué terminado a causa de `reason:OOM Killed`, dond
 * Obtén experiencia práctica [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).

 * Para más detalles sobre la diferencia entre solicitudes y límites, mira
-  [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md).
+  [Resource QoS](https://git.k8s.io/design-proposals-archive/node/resource-qos.md).

 * Lee [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) referencia de API

@@ -38,4 +38,4 @@ Para obtener más detalles vea la [documentación sobre autorización](/docs/ref
 <!-- whatsnext -->

 * [RuntimeClass](/docs/concepts/containers/runtime-class/)
-* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
+* [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
@@ -14,7 +14,7 @@ weight: 50

 Los objetos de tipo {{< glossary_tooltip text="Secret" term_id="secret" >}} en Kubernetes te permiten almacenar y administrar información confidencial, como
 contraseñas, tokens OAuth y llaves ssh.  Poniendo esta información en un Secret
-es más seguro y más flexible que ponerlo en la definición de un {{< glossary_tooltip term_id="pod" >}} o en un {{< glossary_tooltip text="container image" term_id="image" >}}. Ver [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) para más información.
+es más seguro y más flexible que ponerlo en la definición de un {{< glossary_tooltip term_id="pod" >}} o en un {{< glossary_tooltip text="container image" term_id="image" >}}. Ver [Secrets design document](https://git.k8s.io/design-proposals-archive/auth/secrets.md) para más información.

 <!-- body -->

@@ -345,7 +345,7 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
 ## Usando Secrets

 Los Secrets se pueden montar como volúmenes de datos o ser expuestos como 
-{{< glossary_tooltip text="variables de ambiente" term_id="container-env-variables" >}}
+{{< glossary_tooltip text="variables de entorno" term_id="container-env-variables" >}}
 para ser usados por un contenedor en un pod.  También pueden ser utilizados por otras partes del sistema, 
 sin estar directamente expuesto en el pod.  Por ejemplo, pueden tener credenciales que otras partes del sistema usan para interactuar con sistemas externos en su nombre.

@@ -202,4 +202,4 @@ cuentan en Kubernetes.
 - [Diseño de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
 - [Diseño de programación de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
 - Leer sobre el concepto de [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
- [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
+- [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
@@ -66,7 +66,7 @@ Para facilitar la eliminación de propiedades o reestructurar la representación

 Se versiona a nivel de la API en vez de a nivel de los recursos o propiedades para asegurarnos de que la API presenta una visión clara y consistente de los recursos y el comportamiento del sistema, y para controlar el acceso a las APIs experimentales o que estén terminando su ciclo de vida. Los esquemas de serialización JSON y Protobuf siguen los mismos lineamientos para los cambios, es decir, estas descripciones cubren ambos formatos.

-Se ha de tener en cuenta que hay una relación indirecta entre el versionado de la API y el versionado del resto del software. La propuesta de [versionado de la API y releases](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describe esta relación.
+Se ha de tener en cuenta que hay una relación indirecta entre el versionado de la API y el versionado del resto del software. La propuesta de [versionado de la API y releases](https://git.k8s.io/design-proposals-archive/release/versioning.md) describe esta relación.

 Las distintas versiones de la API implican distintos niveles de estabilidad y soporte. El criterio para cada nivel se describe en detalle en la documentación de [Cambios a la API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). A continuación se ofrece un resumen:

@@ -89,7 +89,7 @@ Las distintas versiones de la API implican distintos niveles de estabilidad y so

 ## Grupos de API

-Para que sea más fácil extender la API de Kubernetes, se han creado los [*grupos de API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md).
+Para que sea más fácil extender la API de Kubernetes, se han creado los [*grupos de API*](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md).
 Estos grupos se especifican en una ruta REST y en la propiedad `apiVersion` de un objeto serializado.

 Actualmente hay varios grupos de API en uso:
@@ -60,7 +60,7 @@ APIs](/docs/concepts/api-extension/custom-resources/)
 desde una [herramienta de línea de comandos](/docs/user-guide/kubectl-overview/).

 Este
-[diseño](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)
+[diseño](https://git.k8s.io/design-proposals-archive/architecture/architecture.md)
 ha permitido que otros sistemas sean construidos sobre Kubernetes.

 ## Lo que Kubernetes no es
@@ -10,7 +10,7 @@ Todos los objetos de la API REST de Kubernetes se identifica de forma inequívoc

 Para aquellos atributos provistos por el usuario que no son únicos, Kubernetes provee de [etiquetas](/docs/user-guide/labels) y [anotaciones](/docs/concepts/overview/working-with-objects/annotations/).

-Echa un vistazo al [documento de diseño de identificadores](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) para información precisa acerca de las reglas sintácticas de los Nombres y UIDs.
+Echa un vistazo al [documento de diseño de identificadores](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) para información precisa acerca de las reglas sintácticas de los Nombres y UIDs.



@@ -58,7 +58,7 @@ Ni la contención ni los cambios en un LimitRange afectarán a los recursos ya c

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

-Consulte el [documento de diseño del LimitRanger](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) para más información.
+Consulte el [documento de diseño del LimitRanger](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) para más información.

 Los siguientes ejemplos utilizan límites y están pendientes de su traducción:

@@ -95,7 +95,7 @@ Los Services comúnmente abstraen el acceso a los Pods de Kubernetes, pero tambi

 Por ejemplo:

- Quieres tener un clúster de base de datos externo en producción, pero en el ambiente de pruebas quieres usar tus propias bases de datos.
+- Quieres tener un clúster de base de datos externo en producción, pero en el entorno de pruebas quieres usar tus propias bases de datos.
 - Quieres apuntar tu Service a un Service en un {{< glossary_tooltip term_id="namespace" text="Namespace" >}} o en un clúster diferente.
 - Estás migrando tu carga de trabajo a Kubernetes. Mientras evalúas la aproximación, corres solo una porción de tus backends en Kubernetes.

@@ -418,7 +418,7 @@ Si quieres un número de puerto específico, puedes especificar un valor en el c
 Esto significa que necesitas prestar atención a posibles colisiones de puerto por tu cuenta.
 También tienes que usar un número de puerto válido, uno que esté dentro del rango configurado para uso del NodePort.

-Usar un NodePort te da libertad para configurar tu propia solución de balanceo de cargas, para configurar ambientes que no soportan Kubernetes del todo, o para exponer uno o más IPs del nodo directamente.
+Usar un NodePort te da libertad para configurar tu propia solución de balanceo de cargas, para configurar entornos que no soportan Kubernetes del todo, o para exponer uno o más IPs del nodo directamente.

 Ten en cuenta que este Service es visible como `<NodeIP>:spec.ports[*].nodePort` y `.spec.clusterIP:spec.ports[*].port`.
 Si la bandera `--nodeport-addresses` está configurada para el kube-proxy o para el campo equivalente en el fichero de configuración, `<NodeIP>` sería IP filtrada del nodo. Si
@@ -514,7 +514,7 @@ El valor de `spec.loadBalancerClass` debe ser un identificador de etiqueta, con

 #### Balanceador de carga interno

-En un ambiente mixto algunas veces es necesario enrutar el tráfico desde Services dentro del mismo bloque (virtual) de direcciones de red.
+En un entorno mixto algunas veces es necesario enrutar el tráfico desde Services dentro del mismo bloque (virtual) de direcciones de red.

 En un entorno de split-horizon DNS necesitarías dos Services para ser capaz de enrutar tanto el tráfico externo como el interno a tus Endpoints.

@@ -646,7 +646,7 @@ HTTP y HTTPS seleccionan un proxy de capa 7: el ELB termina la conexión con el

 TCP y SSL seleccionan un proxy de capa 4: el ELB reenvía el tráfico sin modificar los encabezados.

-En un ambiente mixto donde algunos puertos están asegurados y otros se dejan sin encriptar, puedes usar una de las siguientes anotaciones:
+En un entorno mixto donde algunos puertos están asegurados y otros se dejan sin encriptar, puedes usar una de las siguientes anotaciones:

 ```yaml
 metadata:
@@ -0,0 +1,36 @@
+---
+reviewers:
+- edithturn
+- raelga
+- electrocucaracha
+title: Supervisión del Estado del Volumen
+content_type: concept
+---
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+La supervisión del estado del volumen de {{< glossary_tooltip text="CSI" term_id="csi" >}}  permite que los controladores de CSI detecten condiciones de volumen anómalas de los sistemas de almacenamiento subyacentes y las notifiquen como eventos en {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} o {{< glossary_tooltip text="Pods" term_id="pod" >}}.
+
+
+
+<!-- body -->
+
+## Supervisión del Estado del Volumen
+
+El _monitoreo del estado del volumen_ de Kubernetes es parte de cómo Kubernetes implementa la Interfaz de Almacenamiento de Contenedores (CSI). La función de supervisión del estado del volumen se implementa en dos componentes: un controlador de supervisión del estado externo y {{< glossary_tooltip term_id="kubelet" text="Kubelet" >}}.
+
+Si un controlador CSI admite la función supervisión del estado del volumen desde el lado del controlador, se informará un evento en el {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} (PVC) relacionado cuando se detecte una condición de volumen anormal en un volumen CSI.
+
+El {{< glossary_tooltip text="controlador" term_id="controller" >}} de estado externo también observa los eventos de falla del nodo. Se puede habilitar la supervisión de fallas de nodos configurando el indicador `enable-node-watcher` en verdadero. Cuando el monitor de estado externo detecta un evento de falla de nodo, el controlador reporta que se informará un evento en el PVC para indicar que los Pods que usan este PVC están en un nodo fallido.
+
+Si un controlador CSI es compatible con la función monitoreo del estado del volumen desde el lado del nodo, se informará un evento en cada Pod que use el PVC cuando se detecte una condición de volumen anormal en un volumen CSI.
+
+{{< note >}}
+Se necesita habilitar el `CSIVolumeHealth` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para usar esta función desde el lado del nodo.
+{{< /note >}}
+
+## {{% heading "whatsnext" %}}
+
+Ver la [documentación del controlador CSI](https://kubernetes-csi.github.io/docs/drivers.html) para averiguar qué controladores CSI han implementado esta característica.
@@ -638,7 +638,7 @@ Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/master/stagi

 ### persistentVolumeClaim {#persistentvolumeclaim}

-Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del ambiente de la nube en particular.
+Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del entorno de la nube en particular.

 Mira la información spbre [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) para más detalles.

@@ -170,7 +170,7 @@ Seguimiento en [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
 ## {{% heading "whatsnext" %}}


-[Documento de Diseño 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
+[Documento de Diseño 1](https://git.k8s.io/design-proposals-archive/api-machinery/garbage-collection.md)

-[Documento de Diseño 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
+[Documento de Diseño 2](https://git.k8s.io/design-proposals-archive/api-machinery/synchronous-garbage-collection.md)

@@ -92,4 +92,4 @@ modificación del Pod Preset. En estos casos, se puede añadir una observación

 Ver [Inyectando datos en un Pod usando PodPreset](/docs/tasks/inject-data-application/podpreset/)

-Para más información sobre los detalles de los trasfondos, consulte la [propuesta de diseño de PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). 
+Para más información sobre los detalles de los trasfondos, consulte la [propuesta de diseño de PodPreset](https://git.k8s.io/design-proposals-archive/service-catalog/pod-preset.md). 
@@ -59,6 +59,6 @@ En estos momento, las librerías con soporte oficial son:

 Un archivo de los documentos de diseño para la funcionalidad de Kubernetes.

-Puedes empezar por [Arquitectura de Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) y [Vista general del diseño de Kubernetes](https://git.k8s.io/community/contributors/design-proposals).
+Puedes empezar por [Arquitectura de Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) y [Vista general del diseño de Kubernetes](https://git.k8s.io/community/contributors/design-proposals).


@@ -52,6 +52,6 @@ El servidor reune métricas de la Summary API, que es expuesta por el [Kubelet](
 El servidor de métricas se añadió a la API de Kubernetes utilizando el
 [Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/) introducido en Kubernetes 1.7.

-Puedes aprender más acerca del servidor de métricas en el [documento de diseño](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
+Puedes aprender más acerca del servidor de métricas en el [documento de diseño](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/metrics-server.md).


@@ -17,7 +17,7 @@ card:

 Este tutorial muestra como ejecutar una aplicación Node.js Hola Mundo en Kubernetes utilizando 
 [Minikube](/docs/setup/learning-environment/minikube) y Katacoda.
-Katacoda provee un ambiente de Kubernetes desde el navegador.
+Katacoda provee un entorno de Kubernetes desde el navegador.

 {{< note >}}
 También se puede  seguir este tutorial si se ha instalado [Minikube localmente](/docs/tasks/tools/install-minikube/).
@@ -63,9 +63,9 @@ Para más información sobre el comando `docker build`, lea la [documentación d
    minikube dashboard
    ```

-3. Solo en el ambiente de Katacoda: En la parte superior de la terminal, haz clic en el símbolo + y luego clic en **Select port to view on Host 1**.
+3. Solo en el entorno de Katacoda: En la parte superior de la terminal, haz clic en el símbolo + y luego clic en **Select port to view on Host 1**.

-4. Solo en el ambiente de Katacoda: Escribir `30000`, y hacer clic en **Display Port**.
+4. Solo en el entorno de Katacoda: Escribir `30000`, y hacer clic en **Display Port**.

 ## Crear un Deployment

@@ -154,15 +154,15 @@ Por defecto, el Pod es accedido por su dirección IP interna dentro del clúster
    minikube service hello-node
    ```

-4. Solo en el ambiente de Katacoda: Hacer clic sobre el símbolo +, y luego en **Select port to view on Host 1**.
+4. Solo en el entorno de Katacoda: Hacer clic sobre el símbolo +, y luego en **Select port to view on Host 1**.

-5. Solo en el ambiente de Katacoda: Anotar el puerto de 5 dígitos ubicado al lado del valor de `8080` en el resultado de servicios. Este número de puerto es generado aleatoriamente y puede ser diferente al indicado en el ejemplo. Escribir el número de puerto en el cuadro de texto y hacer clic en Display Port. Usando el ejemplo anterior, usted escribiría `30369`.
+5. Solo en el entorno de Katacoda: Anotar el puerto de 5 dígitos ubicado al lado del valor de `8080` en el resultado de servicios. Este número de puerto es generado aleatoriamente y puede ser diferente al indicado en el ejemplo. Escribir el número de puerto en el cuadro de texto y hacer clic en Display Port. Usando el ejemplo anterior, usted escribiría `30369`.

    Esto abre una ventana de navegador que contiene la aplicación y muestra el mensaje "Hello World".

 ## Habilitar Extensiones

-Minikube tiene un conjunto  de {{< glossary_tooltip text="Extensiones" term_id="addons" >}} que pueden ser habilitados y desahabilitados en el ambiente local de Kubernetes.
+Minikube tiene un conjunto  de {{< glossary_tooltip text="Extensiones" term_id="addons" >}} que pueden ser habilitados y desahabilitados en el entorno local de Kubernetes.

 1. Listar las extensiones soportadas actualmente:

@@ -7,85 +7,48 @@ cid: partners
 ---

 <section id="users">
-    <main>
-        <h5>Kubernetes trabaja con socios para crear una base de código sólida y vibrante que admita un espectro de plataformas complementarias.</h5>
-        <div class="col-container">
-          <div class="col-nav">
-            <center>
-              <h5>
-                <b>Kubernetes Certified Service Providers</b>
-              </h5>
-              <br>Proveedores de servicios con amplia experiencia ayudando a las empresas a adoptar Kubernetes con éxito.
-              <br><br><br>
-              <button id="kcsp" class="button" onClick="updateSrc(this.id)">See KCSP Partners</button>
-              <br><br>Conviértete en <a href="https://www.cncf.io/certification/kcsp/">KCSP</a>
-            </center>
-          </div>
-          <div class="col-nav">
-            <center>
-              <h5>
-                <b>Certified Kubernetes Distributions, Hosted Platforms, and Installers</b>
-              </h5>La conformidad del software garantiza que la versión de Kubernetes de cada proveedor sea compatible con las API requeridas.
-              <br><br><br>
-              <button id="conformance" class="button" onClick="updateSrc(this.id)">See Conformance Partners</button>
-              <br><br>Conviértete en <a href="https://www.cncf.io/certification/software-conformance/">Certified Kubernetes</a>
-            </center>
-          </div>
-          <div class="col-nav">
-            <center>
-              <h5><b>Kubernetes Training Partners</b></h5>
-              <br>Partners de formación que ofrecen cursos de alta calidad y con una amplia experiencia en formación de tecnologías nativas de la nube.
-              <br><br><br><br>
-              <button id="ktp" class="button" onClick="updateSrc(this.id)">See KTP Partners</button>
-              <br><br>Conviértete en <a href="https://www.cncf.io/certification/training/">KTP</a>
-            </center>
-          </div>
-        </div>
-<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
-<script type="text/javascript">
-
-			var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes";
-			var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes";
-      var secondLink = "https://landscape.cncf.io/category=kubernetes-training-partner&format=card-mode&grouping=category&embed=yes";
-
-      function updateSrc(buttonId) {
-      	if (buttonId == "kcsp") {
-        		$("#landscape").attr("src",defaultLink);
-            window.location.hash = "#kcsp";
-        }
-        if (buttonId == "conformance") {
-         		$("#landscape").attr("src",firstLink);
-            window.location.hash = "#conformance";
-        }
-        if (buttonId == "ktp") {
-        		$("#landscape").attr("src",secondLink);
-            window.location.hash = "#ktp";
-        }
-      }
-
-      // Automatically load the correct iframe based on the URL fragment
-      document.addEventListener('DOMContentLoaded', function() {
-        var showContent = "kcsp";
-        if (window.location.hash) {
-          console.log('hash is:', window.location.hash.substring(1));
-          showContent = window.location.hash.substring(1);
-        }
-        updateSrc(showContent);
-      });
-</script>
-<body>
-    <div id="frameHolder">
-      <iframe id="landscape" frameBorder="0" scrolling="no" style="width: 1px; min-width: 100%" src=""></iframe>
-      <script src="https://landscape.cncf.io/iframeResizer.js"></script>
+    <h5>Kubernetes trabaja con socios para crear una base de código sólida y vibrante que admita un espectro de plataformas complementarias.</h5>
+    <div class="col-container">
+      <div class="col-nav">
+        <center>
+          <h5>
+            <b>Kubernetes Certified Service Providers</b>
+          </h5>
+          <br>Proveedores de servicios con amplia experiencia ayudando a las empresas a adoptar Kubernetes con éxito.
+          <br><br><br>
+          <button class="button landscape-trigger landscape-default" data-landscape-types="kubernetes-certified-service-provider" id="kcsp">See KCSP Partners</button>
+          <br><br>Conviértete en 
+          <a href="https://www.cncf.io/certification/kcsp/">KCSP</a>?
+        </center>
+      </div>
+      <div class="col-nav">
+        <center>
+          <h5>
+            <b>Certified Kubernetes Distributions, Hosted Platforms, and Installers</b>
+          </h5>La conformidad del software garantiza que la versión de Kubernetes de cada proveedor sea compatible con las API requeridas.
+          <br><br><br>
+          <button class="button landscape-trigger" data-landscape-types="certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer" id="conformance">See Conformance Partners</button>
+          <br><br>Conviértete en 
+          <a href="https://www.cncf.io/certification/software-conformance/">Certified Kubernetes</a>?
+        </center>
+      </div>
+      <div class="col-nav">
+        <center>
+          <h5>
+            <b>Kubernetes Training Partners</b>
+          </h5>
+          <br>Partners de formación que ofrecen cursos de alta calidad y con una amplia experiencia en formación de tecnologías nativas de la nube.
+          <br><br><br>
+          <button class="button landscape-trigger" data-landscape-types="kubernetes-training-partner" id="ktp">See KTP Partners</button>
+          <br><br>Conviértete en 
+          <a href="https://www.cncf.io/certification/training/">KTP</a>?
+        </center>
+      </div>
    </div>
-</body>
-    </main>
+    {{< cncf-landscape helpers=true >}}
 </section>

 <style>
    {{< include "partner-style.css" >}}
 </style>

-<script>
-    {{< include "partner-script.js" >}}
-</script>
@@ -15,8 +15,8 @@ Kubespray se base sur des outils de provisioning, des [paramètres](https://gith
 * Le support des principales distributions Linux:
  * Container Linux de CoreOS
  * Debian Jessie, Stretch, Wheezy
-  * Ubuntu 16.04, 18.04
-  * CentOS/RHEL 7
+  * Ubuntu 16.04, 18.04, 20.04, 22.04
+  * CentOS/RHEL 7, 8
  * Fedora/CentOS Atomic
  * openSUSE Leap 42.3/Tumbleweed
 * des tests d'intégration continue
@@ -33,8 +33,8 @@ Afin de choisir l'outil le mieux adapté à votre besoin, veuillez lire [cette c

 Les serveurs doivent être installés en s'assurant des éléments suivants:

-* **Ansible v2.6 (ou version plus récente) et python-netaddr installés sur la machine qui exécutera les commandes Ansible**
-* **Jinja 2.9 (ou version plus récente) est nécessaire pour exécuter les playbooks Ansible**
+* **Ansible v2.11 (ou version plus récente) et python-netaddr installés sur la machine qui exécutera les commandes Ansible**
+* **Jinja 2.11 (ou version plus récente) est nécessaire pour exécuter les playbooks Ansible**
 * Les serveurs cibles doivent avoir **accès à Internet** afin de télécharger les images Docker. Autrement, une configuration supplémentaire est nécessaire, (se référer à [Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/downloads.md#offline-environment))
 * Les serveurs cibles doivent être configurés afin d'autoriser le transfert IPv4 (**IPv4 forwarding**)
 * **Votre clé ssh doit être copiée** sur tous les serveurs faisant partie de votre inventaire Ansible.
@@ -22,15 +22,15 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk

 * [ACI](https://www.github.com/noironetworks/aci-containers) menyediakan integrasi jaringan kontainer dan keamanan jaringan dengan Cisco ACI.
 * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) merupakan penyedia jaringan L3 yang aman dan *policy* jaringan.
-* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) menggabungkan Flannel dan Calico, menyediakan jaringan serta *policy* jaringan.
+* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) menggabungkan Flannel dan Calico, menyediakan jaringan serta *policy* jaringan.
 * [Cilium](https://github.com/cilium/cilium) merupakan *plugin* jaringan L3 dan *policy* jaringan yang dapat menjalankan *policy* HTTP/API/L7 secara transparan. Mendukung mode *routing* maupun *overlay/encapsulation*.
-* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam *plugin* CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus.
+* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam *plugin* CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus.
 * [Contiv](http://contiv.github.io) menyediakan jaringan yang dapat dikonfigurasi (*native* L3 menggunakan BGP, *overlay* menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta *policy framework* yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](http://github.com/contiv). Laman [instalasi](http://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk klaster dengan kubeadm maupun non-kubeadm.
 * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), yang berbasis dari [Tungsten Fabric](https://tungsten.io), merupakan sebuah proyek *open source* yang menyediakan virtualisasi jaringan *multi-cloud* serta platform manajemen *policy*. Contrail dan Tungsten Fabric terintegrasi dengan sistem orkestrasi lainnya seperti Kubernetes, OpenShift, OpenStack dan Mesos, serta menyediakan mode isolasi untuk mesin virtual (VM), kontainer/pod dan *bare metal*.
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) merupakan penyedia jaringan *overlay* yang dapat digunakan pada Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) merupakan solusi jaringan yang mendukung multipel jaringan pada Kubernetes.
-* Multus merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes.
-* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift.
+* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes.
+* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) merupakan platform SDN yang menyediakan *policy-based* jaringan antara Kubernetes Pods dan non-Kubernetes *environment* dengan *monitoring* visibilitas dan keamanan.
 * [Romana](http://romana.io) merupakan solusi jaringan  *Layer* 3 untuk jaringan pod yang juga mendukung [*NetworkPolicy* API](/id/docs/concepts/services-networking/network-policies/). Instalasi Kubeadm *add-on* ini tersedia [di sini](https://github.com/romana/romana/tree/master/containerize).
 * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) menyediakan jaringan serta *policy* jaringan, yang akan membawa kedua sisi dari partisi jaringan, serta tidak membutuhkan basis data eksternal.
@@ -22,14 +22,14 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine

 * [ACI](https://www.github.com/noironetworks/aci-containers) fornisce funzionalità integrate di networking e sicurezza di rete con Cisco ACI.
 * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) è un provider di sicurezza e rete L3 sicuro.
-* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete.
+* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) unisce Flannel e Calico, fornendo i criteri di rete e di rete.
 * [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento.
-* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave.
+* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave.
 * [Contiv](https://contivpp.io/) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm.
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes.
-* Multus è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes.
-* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift.
+* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes.
+* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1/docs/kubernetes-1-installation.rst) è una piattaforma SDN che fornisce una rete basata su policy tra i pod di Kubernetes e non Kubernetes con visibilità e monitoraggio della sicurezza.
 * [Romana](https://github.com/romana/romana) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui](https://github.com/romana/romana/tree/master/containerize).
 * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornisce i criteri di rete e di rete, continuerà a funzionare su entrambi i lati di una partizione di rete e non richiede un database esterno.
--- a/Show More
+++ b/Show More