Merge master into dev-1.22 to keep in sync

.gitignore

@@ -33,4 +33,8 @@ resources/
 # Netlify Functions build output
 package-lock.json
 functions/
-node_modules/
+node_modules/
+
+# Generated files when building with make container-build
+.config/
+.npm/

OWNERS_ALIASES

@@ -27,6 +27,7 @@ aliases:
     - kbarnard10
     - kbhawkey
     - onlydole
+    - pi-victor
     - reylejano
     - savitharaghunathan
     - sftim
@@ -232,3 +233,27 @@ aliases:
     - mrbobbytables
     - nikhita
     - parispittman
+  # authoritative source: https://git.k8s.io/sig-release/OWNERS_ALIASES
+  sig-release-leads:
+    - hasheddan # SIG Technical Lead
+    - jeremyrickard # SIG Technical Lead
+    - justaugustus # SIG Chair
+    - LappleApple # SIG Program Manager
+    - saschagrunert # SIG Chair
+  release-engineering-approvers:
+    - cpanato # Release Manager
+    - hasheddan # subproject owner / Release Manager
+    - puerco # Release Manager
+    - saschagrunert # subproject owner / Release Manager
+    - justaugustus # subproject owner / Release Manager
+    - xmudrii # Release Manager
+  release-engineering-reviewers:
+    - ameukam # Release Manager Associate
+    - jimangel # Release Manager Associate
+    - mkorbi # Release Manager Associate
+    - palnabarun # Release Manager Associate
+    - onlydole # Release Manager Associate
+    - sethmccombs # Release Manager Associate
+    - thejoycekung # Release Manager Associate
+    - verolop # Release Manager Associate
+    - wilsonehusin # Release Manager Associate

assets/scss/_custom.scss

@@ -444,7 +444,7 @@ body.cid-community > #deprecation-warning > .deprecation-warning > * {
 .td-sidebar__inner {
   form.td-sidebar__search {
 
-    button.td-sidebar__toggle {
+    .td-sidebar__toggle {
       &:hover {
         color: #000000;
       }
@@ -482,10 +482,6 @@ main.content {
 
 .td-blog {
 
-  .td-sidebar-nav {
-    max-height: calc(100vh - 8rem);
-  }
-
   .widget-link {
     margin-bottom: 1rem;
 

assets/scss/_tablet.scss

@@ -77,7 +77,6 @@ $feature-box-div-width: 45%;
       position: relative;
       clear: both;
       display: table;
-      height: 160px;
 
       .content {
         display: table-cell;
@@ -124,6 +123,7 @@ $feature-box-div-width: 45%;
           position: relative;
           display: block;
           float: none;
+          text-align: center;
           max-width: 100%;
           transform: none;
         }

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

@@ -47,6 +47,15 @@ and other ecosystem groups to ensure a smooth transition and will evaluate thing
 as the situation evolves.
 
 
+### Can I still use dockershim after it is removed from Kubernetes?
+
+Update:
+Mirantis and Docker have [committed][mirantis] to maintaining the dockershim after
+it is removed from Kubernetes.
+
+[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
+
+
 ### Will my existing Docker images still work?
 
 Yes, the images produced from `docker build` will work with all CRI implementations.
@@ -178,4 +187,3 @@ discussion of the changes.
 
 Always and whenever you want!  🤗🤗
 
-

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

@@ -0,0 +1,268 @@
+---
+layout: blog
+title: 'Using Finalizers to Control Deletion'
+date: 2021-05-14
+slug: using-finalizers-to-control-deletion
+---
+
+**Authors:** Aaron Alpar (Kasten)
+
+Deleting objects in Kubernetes can be challenging. You may think you’ve deleted something, only to find it still persists. While issuing a `kubectl delete` command and hoping for the best might work for day-to-day operations, understanding how Kubernetes `delete` commands operate will help you understand why some objects linger after deletion. 
+
+In this post, I’ll look at:
+
+- What properties of a resource govern deletion
+- How finalizers and owner references impact object deletion
+- How the propagation policy can be used to change the order of deletions
+- How deletion works, with examples
+
+For simplicity, all examples will use ConfigMaps and basic shell commands to demonstrate the process. We’ll explore how the commands work and discuss repercussions and results from using them in practice.
+
+## The basic `delete`
+
+Kubernetes has several different commands you can use that allow you to create, read, update, and delete objects. For the purpose of this blog post, we’ll focus on four `kubectl` commands: `create`, `get`, `patch`, and `delete`. 
+
+Here are examples of the basic `kubectl delete` command:
+
+```
+kubectl create configmap mymap
+configmap/mymap created
+```
+
+```
+kubectl get configmap/mymap
+NAME    DATA   AGE
+mymap   0      12s
+```
+
+```
+kubectl delete configmap/mymap
+configmap "mymap" deleted
+```
+
+```
+kubectl get configmap/mymap
+Error from server (NotFound): configmaps "mymap" not found
+```
+
+Shell commands preceded by `$` are followed by their output. You can see that we begin with a `kubectl create configmap mymap`, which will create the empty configmap `mymap`. Next, we need to `get` the configmap to prove it exists. We can then delete that configmap. Attempting to `get` it again produces an HTTP 404 error, which means the configmap is not found.
+
+The state diagram for the basic `delete` command is very simple:
+
+
+{{<figure width="495" src="/images/blog/2021-05-14-using-finalizers-to-control-deletion/state-diagram-delete.png" caption="State diagram for delete">}}
+
+Although this operation is straightforward, other factors may interfere with the deletion, including finalizers and owner references.
+
+## Understanding Finalizers
+
+When it comes to understanding resource deletion in Kubernetes, knowledge of how finalizers work is helpful and can help you understand why some objects don’t get deleted. 
+
+Finalizers are keys on resources that signal pre-delete operations. They control the garbage collection on resources, and are designed to alert controllers what cleanup operations to perform prior to removing a resource. However, they don’t necessarily name code that should be executed; finalizers on resources are basically just lists of keys much like annotations. Like annotations, they can be manipulated.
+
+Some common finalizers you’ve likely encountered are:
+
+- `kubernetes.io/pv-protection`
+- `kubernetes.io/pvc-protection`
+
+The finalizers above are used on volumes to prevent accidental deletion. Similarly, some finalizers can be used to prevent deletion of any resource but are not managed by any controller.
+
+Below with a custom configmap, which has no properties but contains a finalizer:
+
+```
+cat <<EOF | kubectl create -f -
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: mymap
+  finalizers:
+  - kubernetes
+EOF
+```
+
+The configmap resource controller doesn't understand what to do with the `kubernetes` finalizer key. I term these “dead” finalizers for configmaps as it is normally used on namespaces. Here’s what happen upon attempting to delete the configmap:
+
+```
+kubectl delete configmap/mymap &
+configmap "mymap" deleted
+jobs
+[1]+  Running kubectl delete configmap/mymap
+```
+
+Kubernetes will report back that the object has been deleted, however, it hasn’t been deleted in a traditional sense. Rather, it’s in the process of deletion. When we attempt to `get` that object again, we discover the object has been modified to include the deletion timestamp. 
+
+```
+kubectl get configmap/mymap -o yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  creationTimestamp: "2020-10-22T21:30:18Z"
+  deletionGracePeriodSeconds: 0
+  deletionTimestamp: "2020-10-22T21:30:34Z"
+  finalizers:
+  - kubernetes
+  name: mymap
+  namespace: default
+  resourceVersion: "311456"
+  selfLink: /api/v1/namespaces/default/configmaps/mymap
+  uid: 93a37fed-23e3-45e8-b6ee-b2521db81638
+```
+
+In short, what’s happened is that the object was updated, not deleted. That’s because Kubernetes saw that the object contained finalizers and put it into a read-only state. The deletion timestamp signals that the object can only be read, with the exception of removing the finalizer key updates. In other words, the deletion will not be complete until we edit the object and remove the finalizer.
+
+Here's a demonstration of using the `patch` command to remove finalizers. If we want to delete an object, we can simply patch it on the command line to remove the finalizers. In this way, the deletion that was running in the background will complete and the object will be deleted. When we attempt to `get` that configmap, it will be gone. 
+
+```
+kubectl patch configmap/mymap \
+    --type json \
+    --patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'
+configmap/mymap patched
+[1]+  Done  kubectl delete configmap/mymap
+
+kubectl get configmap/mymap -o yaml
+Error from server (NotFound): configmaps "mymap" not found
+```
+
+Here's a state diagram for finalization: 
+
+{{<figure width="617" src="/images/blog/2021-05-14-using-finalizers-to-control-deletion/state-diagram-finalize.png" caption="State diagram for finalize">}}
+
+So, if you attempt to delete an object that has a finalizer on it, it will remain in finalization until the controller has removed the finalizer keys or the finalizers are removed using Kubectl. Once that finalizer list is empty, the object can actually be reclaimed by Kubernetes and put into a queue to be deleted from the registry.
+
+## Owner References
+
+Owner references describe how groups of objects are related. They are properties on resources that specify the relationship to one another, so entire trees of resources can be deleted.
+
+Finalizer rules are processed when there are owner references. An owner reference consists of a name and a UID. Owner references link resources within the same namespace, and it also needs a UID for that reference to work. Pods typically have owner references to the owning replica set. So, when deployments or stateful sets are deleted, then the child replica sets and pods are deleted in the process. 
+
+Here are some examples of owner references and how they work. In the first example, we create a parent object first, then the child. The result is a very simple configmap that contains an owner reference to its parent:
+
+```
+cat <<EOF | kubectl create -f -
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: mymap-parent
+EOF
+CM_UID=$(kubectl get configmap mymap-parent -o jsonpath="{.metadata.uid}")
+
+cat <<EOF | kubectl create -f -
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: mymap-child
+  ownerReferences:
+  - apiVersion: v1
+    kind: ConfigMap
+    name: mymap-parent
+    uid: $CM_UID
+EOF
+```
+
+Deleting the child object when an owner reference is involved does not delete the parent:
+
+```
+kubectl get configmap
+NAME           DATA   AGE
+mymap-child    0      12m4s
+mymap-parent   0      12m4s
+
+kubectl delete configmap/mymap-child
+configmap "mymap-child" deleted
+
+kubectl get configmap
+NAME           DATA   AGE
+mymap-parent   0      12m10s
+```
+
+In this example, we re-created the parent-child configmaps from above. Now, when deleting from the parent (instead of the child) with an owner reference from the child to the parent, when we `get` the configmaps, none are in the namespace:
+
+```
+kubectl get configmap
+NAME           DATA   AGE
+mymap-child    0      10m2s
+mymap-parent   0      10m2s
+
+kubectl delete configmap/mymap-parent
+configmap "mymap-parent" deleted
+
+kubectl get configmap
+No resources found in default namespace.
+```
+
+To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=false option for `kubectl delete` to delete an object and orphan its children. 
+
+In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=false, the parent is deleted but the child still exists:
+
+```
+kubectl get configmap
+NAME           DATA   AGE
+mymap-child    0      13m8s
+mymap-parent   0      13m8s
+
+kubectl delete --cascade=false configmap/mymap-parent
+configmap "mymap-parent" deleted
+
+kubectl get configmap
+NAME          DATA   AGE
+mymap-child   0      13m21s
+```
+
+The --cascade option links to the propagation policy in the API, which allows you to change the order in which objects are deleted within a tree. In the following example uses API access to craft a custom delete API call with the background propagation policy:
+
+```
+kubectl proxy --port=8080 &
+Starting to serve on 127.0.0.1:8080
+
+curl -X DELETE \
+  localhost:8080/api/v1/namespaces/default/configmaps/mymap-parent \
+  -d '{ "kind":"DeleteOptions", "apiVersion":"v1", "propagationPolicy":"Background" }' \
+  -H "Content-Type: application/json"
+{
+  "kind": "Status",
+  "apiVersion": "v1",
+  "metadata": {},
+  "status": "Success",
+  "details": { ... }
+}
+```
+
+Note that the propagation policy cannot be specified on the command line using kubectl. You have to specify it using a custom API call. Simply create a proxy, so you have access to the API server from the client, and execute a `curl` command with just a URL to execute that `delete` command. 
+
+There are three different options for the propagation policy:
+
+- `Foreground`: Children are deleted before the parent (post-order)
+- `Background`: Parent is deleted before the children (pre-order)
+- `Orphan`: Owner references are ignored
+
+Keep in mind that when you delete an object and owner references have been specified, finalizers will be honored in the process. This can result in trees of objects persisting, and you end up with a partial deletion. At that point, you have to look at any existing owner references on your objects, as well as any finalizers, to understand what’s happening. 
+
+## Forcing a Deletion of a Namespace
+
+There's one situation that may require forcing finalization for a namespace. If you've deleted a namespace and you've cleaned out all of the objects under it, but the namespace still exists, deletion can be forced by updating the namespace subresource, `finalize`. This informs the namespace controller that it needs to remove the finalizer from the namespace and perform any cleanup:
+
+```
+cat <<EOF | curl -X PUT \
+  localhost:8080/api/v1/namespaces/test/finalize \
+  -H "Content-Type: application/json" \
+  --data-binary @-
+{
+  "kind": "Namespace",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "test"
+  },
+  "spec": {
+    "finalizers": null
+  }
+}
+EOF
+```
+
+This should be done with caution as it may delete the namespace only and leave orphan objects within the, now non-exiting, namespace - a confusing state for Kubernetes. If this happens, the namespace can be re-created manually and sometimes the orphaned objects will re-appear under the just-created namespace which will allow manual cleanup and recovery.
+
+## Key Takeaways
+
+As these examples demonstrate, finalizers can get in the way of deleting resources in Kubernetes, especially when there are parent-child relationships between objects. Often, there is a reason for adding a finalizer into the code, so you should always investigate before manually deleting it. Owner references allow you to specify and remove trees of resources, although finalizers will be honored in the process. Finally, the propagation policy can be used to specify the order of deletion via a custom API call, giving you control over how objects are deleted. Now that you know a little more about how deletions work in Kubernetes, we recommend you try it out on your own, using a test cluster. 
+
+{{< youtube class="youtube-quote-sm" id="F7-ZxWwf4sY" title="Clean Up Your Room! What Does It Mean to Delete Something in K8s">}}

content/en/community/_index.html

@@ -24,7 +24,8 @@ cid: community
 <a href="#videos">Videos</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#discuss">Discussions</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#events">Events and meetups</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="#news">News</a>
+<a href="#news">News</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+<a href="/releases">Releases</a>
 
 </div>
 <br class="mobile"><br class="mobile">

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

@@ -23,7 +23,7 @@ This page lists some of the available add-ons and links to their respective inst
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
 * [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
-* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
+* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
 * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.

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

@@ -328,13 +328,13 @@ kubectl create secret tls my-tls-secret \
   --key=path/to/key/file
 ```
 
-The public/private key pair must exist before hand. The public key certificate
+The public/private key pair must exist beforehand. The public key certificate
 for `--cert` must be .PEM encoded (Base64-encoded DER format), and match the
 given private key for `--key`.
 The private key must be in what is commonly called PEM private key format,
 unencrypted. In both cases, the initial and the last lines from PEM (for
 example, `--------BEGIN CERTIFICATE-----` and `-------END CERTIFICATE----` for
-a cetificate) are *not* included.
+a certificate) are *not* included.
 
 ### Bootstrap token Secrets
 

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

@@ -25,7 +25,7 @@ This page provides an outline of the container image concept.
 
 Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`.
 Images can also include a registry hostname; for example: `fictional.registry.example/imagename`,
-and possible a port number as well; for example: `fictional.registry.example:10443/imagename`.
+and possibly a port number as well; for example: `fictional.registry.example:10443/imagename`.
 
 If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
 

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

@@ -113,11 +113,13 @@ Operator.
 
 {{% thirdparty-content %}}
 
+* [Charmed Operator Framework](https://juju.is/)
 * [kubebuilder](https://book.kubebuilder.io/)
 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
 * [Metacontroller](https://metacontroller.app/) along with WebHooks that
   you implement yourself
 * [Operator Framework](https://operatorframework.io)
+* [shell-operator](https://github.com/flant/shell-operator)
 
 ## {{% heading "whatsnext" %}}
 

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

@@ -21,7 +21,7 @@ This page is an overview of Kubernetes.
 <!-- body -->
 Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
 
-The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community.
+The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the "K" and the "s". Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community.
 
 ## Going back in time
 

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

@@ -39,7 +39,8 @@ on every resource object.
 | `app.kubernetes.io/version`         | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
 | `app.kubernetes.io/component`       | The component within the architecture | `database` | string |
 | `app.kubernetes.io/part-of`         | The name of a higher level application this one is part of | `wordpress` | string |
-| `app.kubernetes.io/managed-by`  | The tool being used to manage the operation of an application | `helm` | string |
+| `app.kubernetes.io/managed-by`      | The tool being used to manage the operation of an application | `helm` | string |
+| `app.kubernetes.io/created-by`      | The controller/user who created this resource | `controller-manager` | string |
 
 To illustrate these labels in action, consider the following StatefulSet object:
 
@@ -54,6 +55,7 @@ metadata:
     app.kubernetes.io/component: database
     app.kubernetes.io/part-of: wordpress
     app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/created-by: controller-manager
 ```
 
 ## Applications And Instances Of Applications
@@ -170,4 +172,3 @@ metadata:
 
 With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and WordPress, the broader application, are included.
 
-

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

@@ -39,7 +39,7 @@ Creation and deletion of namespaces are described in the
 [Admin Guide documentation for namespaces](/docs/tasks/administer-cluster/namespaces).
 
 {{< note >}}
-    Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
+    Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
 {{< /note >}}
 
 ### Viewing namespaces

content/en/docs/concepts/scheduling-eviction/_index.md

@@ -1,8 +1,11 @@
 ---
-title: "Scheduling and Eviction"
+title: "Scheduling, Preemption and Eviction"
 weight: 90
 description: >
-  In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them.
+  In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes
-  Eviction is the process of proactively failing one or more Pods on resource-starved Nodes.
+  so that the kubelet can run them. Preemption is the process of terminating 
+  Pods with lower Priority so that Pods with higher Priority can schedule on 
+  Nodes. Eviction is the process of proactively terminating one or more Pods on
+  resource-starved Nodes.
 ---
 

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

@@ -113,7 +113,7 @@ enforced/disallowed:
 			</td>
 		</tr>
 		<tr>
-			<td>AppArmor <em>(optional)</em></td>
+			<td>AppArmor</td>
 			<td>
 				On supported hosts, the 'runtime/default' AppArmor profile is applied by default.
 				The baseline policy should prevent overriding or disabling the default AppArmor
@@ -124,14 +124,26 @@ enforced/disallowed:
 			</td>
 		</tr>
 		<tr>
-			<td>SELinux <em>(optional)</em></td>
+			<td>SELinux</td>
 			<td>
-				Setting custom SELinux options should be disallowed.<br>
+				Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.<br>
 				<br><b>Restricted Fields:</b><br>
-				spec.securityContext.seLinuxOptions<br>
+				spec.securityContext.seLinuxOptions.type<br>
-				spec.containers[*].securityContext.seLinuxOptions<br>
+				spec.containers[*].securityContext.seLinuxOptions.type<br>
-				spec.initContainers[*].securityContext.seLinuxOptions<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.type<br>
-				<br><b>Allowed Values:</b> undefined/nil<br>
+				<br><b>Allowed Values:</b><br>
+				undefined/empty<br>
+				container_t<br>
+				container_init_t<br>
+				container_kvm_t<br>
+				<br><b>Restricted Fields:</b><br>
+				spec.securityContext.seLinuxOptions.user<br>
+				spec.containers[*].securityContext.seLinuxOptions.user<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.user<br>
+				spec.securityContext.seLinuxOptions.role<br>
+				spec.containers[*].securityContext.seLinuxOptions.role<br>
+				spec.initContainers[*].securityContext.seLinuxOptions.role<br>
+				<br><b>Allowed Values:</b> undefined/empty<br>
 			</td>
 		</tr>
 		<tr>

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

@@ -540,11 +540,11 @@ spec:
 
 ### Access Modes
 
-Claims use the same conventions as volumes when requesting storage with specific access modes.
+Claims use [the same conventions as volumes](#access-modes) when requesting storage with specific access modes.
 
 ### Volume Modes
 
-Claims use the same convention as volumes to indicate the consumption of the volume as either a filesystem or block device.
+Claims use [the same convention as volumes](#volume-mode) to indicate the consumption of the volume as either a filesystem or block device.
 
 ### Resources
 

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

@@ -154,9 +154,9 @@ the class or PV. If a mount option is invalid, the PV mount fails.
 ### Volume Binding Mode
 
 The `volumeBindingMode` field controls when [volume binding and dynamic
-provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
+provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur. When unset, "Immediate" mode is used by default.
 
-By default, the `Immediate` mode indicates that volume binding and dynamic
+The `Immediate` mode indicates that volume binding and dynamic
 provisioning occurs once the PersistentVolumeClaim is created. For storage
 backends that are topology-constrained and not globally accessible from all Nodes
 in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling
@@ -188,6 +188,36 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
 and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
 to see its supported topology keys and examples.
 
+{{< note >}}
+   If you choose to use `waitForFirstConsumer`, do not use `nodeName` in the Pod spec
+   to specify node affinity. If `nodeName` is used in this case, the scheduler will be bypassed and PVC will remain in `pending` state.
+
+   Instead, you can use node selector for hostname in this case as shown below.
+{{< /note >}}
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: task-pv-pod
+spec:
+  nodeSelector:
+    kubernetes.io/hostname: kube-01
+  volumes:
+    - name: task-pv-storage
+      persistentVolumeClaim:
+        claimName: task-pv-claim
+  containers:
+    - name: task-pv-container
+      image: nginx
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: task-pv-storage
+```
+
 ### Allowed Topologies
 
 When a cluster operator specifies the `WaitForFirstConsumer` volume binding mode, it is no longer necessary

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

@@ -80,12 +80,14 @@ Here are some ways to mitigate involuntary disruptions:
   [multi-zone cluster](/docs/setup/multiple-zones).)
 
 The frequency of voluntary disruptions varies.  On a basic Kubernetes cluster, there are
-no voluntary disruptions at all.  However, your cluster administrator or hosting provider
+no automated voluntary disruptions (only user-triggered ones).  However, your cluster administrator or hosting provider
 may run some additional services which cause voluntary disruptions. For example,
 rolling out node software updates can cause voluntary disruptions. Also, some implementations
 of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes.
 Your cluster administrator or hosting provider should have documented what level of voluntary
-disruptions, if any, to expect.
+disruptions, if any, to expect. Certain configuration options, such as
+[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
+in your pod spec can also cause voluntary (and involuntary) disruptions.
 
 
 ## Pod disruption budgets

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

@@ -246,7 +246,7 @@ myapp-pod   1/1       Running   0          9m
 ```
 
 This simple example should provide some inspiration for you to create your own
-init containers. [What's next](#whats-next) contains a link to a more detailed example.
+init containers. [What's next](#what-s-next) contains a link to a more detailed example.
 
 ## Detailed behavior
 
@@ -326,7 +326,6 @@ Kubernetes, consult the documentation for the version you are using.
 
 ## {{% heading "whatsnext" %}}
 
-
 * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
 * Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
 

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

@@ -13,7 +13,7 @@ obsolete -->
 You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
 
 {{< note >}}
-In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread`
+In versions of Kubernetes before v1.18, you must enable the `EvenPodsSpread`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on
 the [API server](/docs/concepts/overview/components/#kube-apiserver) and the
 [scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod

content/en/docs/contribute/generate-ref-docs/kubernetes-api.md

@@ -90,8 +90,8 @@ This section shows how to generate the
 For example:
 
 ```shell
-export K8S_WEBROOT=$(GOPATH)/src/github.com/<your-username>/website
+export K8S_WEBROOT=${GOPATH}/src/github.com/<your-username>/website
-export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes
+export K8S_ROOT=${GOPATH}/src/k8s.io/kubernetes
 export K8S_RELEASE=1.17.0
 ```
 

content/en/docs/contribute/localization.md

@@ -16,18 +16,21 @@ card:
 This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a different language.
 
 
-
 <!-- body -->
 
-## Getting started
+## Contribute to an existing localization
 
-Because contributors can't approve their own pull requests, you need at least two contributors to begin a localization.
+You can help add or improve content to an existing localization. In [Kubernetes Slack](https://slack.k8s.io/) you'll find a channel for each localization. There is also a general [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations) where you can say hello.
 
-All localization teams must be self-sustaining with their own resources. The Kubernetes website is happy to host your work, but it's up to you to translate it.
+{{< note >}}
+If you want to work on a localization that already exists, check
+this page in that localization (if it exists), rather than the
+English original. You might see extra details there.
+{{< /note >}}
 
 ### Find your two-letter language code
 
-First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) to find your localization's two-letter country code. For example, the two-letter code for Korean is `ko`.
+First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) to find your localization's two-letter language code. For example, the two-letter code for Korean is `ko`.
 
 ### Fork and clone the repo
 
@@ -40,13 +43,54 @@ git clone https://github.com/<username>/website
 cd website
 ```
 
-### Open a pull request
+The website content directory includes sub-directories for each language. The localization you want to help out with is inside `content/<two-letter-code>`.
 
-Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a localization to the `kubernetes/website` repository.
+### Suggest changes
 
-The PR must include all of the [minimum required content](#minimum-required-content) before it can be approved.
+Create or update your chosen localized page based on the English original. See
+[translating content](#translating-content) for more details.
 
-For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548).
+If you notice a technical inaccuracy or other problem with the upstream (English)
+documentation, you should fix the upstream documentation first and then repeat the
+equivalent fix by updating the localization you're working on.
+
+Please limit pull requests to a single localization, since pull requests that change
+content in multiple localizations could be difficult to review.
+
+Follow [Suggesting Content Improvements](/docs/contribute/suggest-improvements/) to propose changes to
+that localization. The process is very similar to proposing changes to the upstream (English) content.
+
+## Start a new localization
+
+If you want the Kubernetes documentation localized into a new language, here's what
+you need to do.
+
+Because contributors can't approve their own pull requests, you need _at least two contributors_
+to begin a localization.
+
+All localization teams must be self-sustaining. The Kubernetes website is happy to host your work, but
+it's up to you to translate it and keep existing localized content current.
+
+You'll need to know the two-letter language code for your language. Consult the
+[ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) to find your
+localization's two-letter language code. For example, the two-letter code for Korean is
+`ko`.
+
+When you start a new localization, you must localize all the
+[minimum required content](#minimum-required-content) before
+the Kubernetes project can publish your changes to the live
+website.
+
+SIG Docs can help you work on a separate branch so that you
+can incrementally work towards that goal.
+
+### Find community
+
+Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). Other localization teams are happy to help you get started and answer any questions you have.
+
+Please also consider participating in the [SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs).  The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization teams to collaborate on defining and documenting the processes for creating localized contribution guides. In addition, the SIG Docs localization subgroup will look for opportunities for the creation and sharing of common tools across localization teams and also serve to identify new requirements to the SIG Docs Leadership team.  If you have questions about this meeting, please inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations).
+
+You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding a channel for Persian](https://github.com/kubernetes/community/pull/4980).
 
 ### Join the Kubernetes GitHub organization
 
@@ -70,15 +114,6 @@ Next, add a GitHub label for your localization in the `kubernetes/test-infra` re
 
 For an example of adding a label, see the PR for adding the [Italian language label](https://github.com/kubernetes/test-infra/pull/11316).
 
-### Find community
-
-Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). Other localization teams are happy to help you get started and answer any questions you have.
-
-Please also consider participating in the [SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs).  The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization teams to collaborate on defining and documenting the processes for creating localized contribution guides. In addition, the SIG Docs localization subgroup will look for opportunities for the creation and sharing of common tools across localization teams and also serve to identify new requirements to the SIG Docs Leadership team.  If you have questions about this meeting, please inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations).
-
-You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding a channel for Persian](https://github.com/kubernetes/community/pull/4980).
-
-## Minimum required content
 
 ### Modify the site configuration
 
@@ -107,20 +142,20 @@ Add a language-specific subdirectory to the [`content`](https://github.com/kuber
 mkdir content/de
 ```
 
+You also need to create a directory inside `data/i18n` for
+[localized strings](#site-strings-in-i18n); look at existing localizations
+for an example. To use these new strings, you must also create a symbolic link
+from `i18n/<localization>.toml` to the actual string configuration in
+`data/i18n/<localization>/<localization>.toml` (remember to commit the symbolic
+link).
+
+For example, for German the strings live in `data/i18n/de/de.toml`, and
+`i18n/de.toml` is a symbolic link to `data/i18n/de/de.toml`.
+
 ### Localize the community code of conduct
 
 Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) repository to add the code of conduct in your language.
 
-### Add a localized README file
-
-To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/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. Include the same information contained in `README.md` as well as:
-
-- A point of contact for the localization project
-- Any information specific to the localization
-
-After you create the localized README, add a link to the file from the main English `README.md`, and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your localized Community Code of Conduct.
 
 ### Setting up the OWNERS files
 
@@ -174,10 +209,38 @@ For each team, add the list of GitHub users requested in [Add your localization
      - remyleone
 ```
 
+### Open a pull request
+
+Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a localization to the `kubernetes/website` repository.
+
+The PR must include all of the [minimum required content](#minimum-required-content) before it can be approved.
+
+For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548).
+
+### Add a localized README file
+
+To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/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. Include the same information contained in `README.md` as well as:
+
+- A point of contact for the localization project
+- Any information specific to the localization
+
+After you create the localized README, add a link to the file from the main English `README.md`, and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your localized Community Code of Conduct.
+
+### Launching your new localization
+
+Once a localization meets requirements for workflow and minimum output, SIG Docs will:
+
+- Enable language selection on the website
+- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).
+
 ## Translating content
 
 Localizing *all* of the Kubernetes documentation is an enormous task. It's okay to start small and expand over time.
 
+### Minimum required content
+
 At a minimum, all localizations must include:
 
 Description | URLs
@@ -185,7 +248,7 @@ Description | URLs
 Home | [All heading and subheading URLs](/docs/home/)
 Setup | [All heading and subheading URLs](/docs/setup/)
 Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/)
-Site strings | [All site strings in a new localized TOML file](https://github.com/kubernetes/website/tree/master/i18n)
+Site strings | [All site strings](#Site-strings-in-i18n) in a new localized TOML file
 
 Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
 
@@ -213,27 +276,30 @@ To find source files for your target version:
 2. Select a branch for your target version from the following table:
     Target version | Branch
     -----|-----
-    Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}})
     Latest version | [`master`](https://github.com/kubernetes/website/tree/master)
-    Previous version | `release-*.**`
+    Previous version | [`release-{{< skew prevMinorVersion >}}`](https://github.com/kubernetes/website/tree/release-{{< skew prevMinorVersion >}})
+    Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}})
 
-The `master` branch holds content for the current release `{{< latest-version >}}`. The release team will create `{{< release-branch >}}` branch shortly before the next release: v{{< skew nextMinorVersion >}}.
+The `master` branch holds content for the current release `{{< latest-version >}}`. The release team will create a `{{< release-branch >}}` branch before the next release: v{{< skew nextMinorVersion >}}.
 
 ### Site strings in i18n
 
-Localizations must include the contents of [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in a new language-specific file. Using German as an example: `i18n/de.toml`.
+Localizations must include the contents of [`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/master/data/i18n/en/en.toml) in a new language-specific file. Using German as an example: `data/i18n/de/de.toml`.
 
-Add a new localization file to `i18n/`. For example, with German (`de`):
+Add a new localization directory and file to `data/i18n/`. For example, with German (`de`):
 
-```shell
+```bash
-cp i18n/en.toml i18n/de.toml
+mkdir -p data/i18n/de
+cp data/i18n/en/en.toml data/i18n/de/de.toml
 ```
 
-Then translate the value of each string:
+Revise the comments at the top of the file to suit your localization,
+then translate the value of each string. For example, this is the German-language
+placeholder text for the search form:
 
-```TOML
+```toml
-[docs_label_i_am]
+[ui_search_placeholder]
-other = "ICH BIN..."
+other = "Suchen"
 ```
 
 Localizing site strings lets you customize site-wide text and features: for example, the legal copyright text in the footer on each page.
@@ -244,7 +310,9 @@ Some language teams have their own language-specific style guide and glossary. F
 
 ## Branching strategy
 
-Because localization projects are highly collaborative efforts, we encourage teams to work in shared localization branches.
+Because localization projects are highly collaborative efforts, we
+encourage teams to work in shared localization branches - especially
+when starting out and the localization is not yet live.
 
 To collaborate on a localization branch:
 
@@ -288,16 +356,4 @@ For more information about working from forks or directly from the repository, s
 
 SIG Docs welcomes upstream contributions and corrections to the English source.
 
-## Help an existing localization
 
-You can also help add or improve content to an existing localization. Join the [Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/) for the localization, and start opening PRs to help. Please limit pull requests to a single localization since pull requests that change content in multiple localizations could be difficult to review.
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-Once a localization meets requirements for workflow and minimum output, SIG docs will:
-
-- Enable language selection on the website
-- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/).

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

@@ -132,7 +132,7 @@ different Kubernetes components.
 | `IPv6DualStack` | `true` | Beta | 1.21 | |
 | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | |
 | `LegacyNodeRoleBehavior` | `false` | Alpha | 1.16 | 1.18 |
-| `LegacyNodeRoleBehavior` | `true` | Beta | 1.19 |  |
+| `LegacyNodeRoleBehavior` | `true` | Beta | 1.19 | 1.20 |
 | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
@@ -142,7 +142,7 @@ different Kubernetes components.
 | `NamespaceDefaultLabelName` | `true` | Beta | 1.21 | |
 | `NetworkPolicyEndPort` | `false` | Alpha | 1.21 |  |
 | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | 1.18 |
-| `NodeDisruptionExclusion` | `true` | Beta | 1.19 | |
+| `NodeDisruptionExclusion` | `true` | Beta | 1.19 | 1.20 |
 | `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 |
 | `NonPreemptingPriority` | `true` | Beta | 1.19 | |
 | `PodDeletionCost` | `false` | Alpha | 1.21 | |
@@ -162,7 +162,7 @@ different Kubernetes components.
 | `ServiceLBNodePortControl` | `false` | Alpha | 1.20 | |
 | `ServiceLoadBalancerClass` | `false` | Alpha | 1.21 | |
 | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 |
-| `ServiceNodeExclusion` | `true` | Beta | 1.19 | |
+| `ServiceNodeExclusion` | `true` | Beta | 1.19 | 1.20 |
 | `ServiceTopology` | `false` | Alpha | 1.17 | |
 | `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | 1.19 |
 | `SetHostnameAsFQDN` | `true` | Beta | 1.20 | |
@@ -171,7 +171,8 @@ different Kubernetes components.
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
 | `SuspendJob` | `false` | Alpha | 1.21 | |
-| `TTLAfterFinished` | `false` | Alpha | 1.12 | |
+| `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 |
+| `TTLAfterFinished` | `true` | Beta | 1.21 | |
 | `TopologyAwareHints` | `false` | Alpha | 1.21 | |
 | `TopologyManager` | `false` | Alpha | 1.16 | 1.17 |
 | `TopologyManager` | `true` | Beta | 1.18 | |
@@ -264,6 +265,7 @@ different Kubernetes components.
 | `EvenPodsSpread` | `true` | Beta | 1.18 | 1.18 |
 | `EvenPodsSpread` | `true` | GA | 1.19 | - |
 | `ExecProbeTimeout` | `true` | GA | 1.20 | - |
+| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
 | `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | Alpha | 1.8 | 1.9 |
@@ -284,11 +286,13 @@ different Kubernetes components.
 | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | Beta | 1.15 | |
 | `KubeletPodResources` | `true` | GA | 1.20 | |
+| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - |
 | `MountContainers` | `false` | Alpha | 1.9 | 1.16 |
 | `MountContainers` | `false` | Deprecated | 1.17 | - |
 | `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
 | `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
 | `MountPropagation` | `true` | GA | 1.12 | - |
+| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - |
 | `NodeLease` | `false` | Alpha | 1.12 | 1.13 |
 | `NodeLease` | `true` | Beta | 1.14 | 1.16 |
 | `NodeLease` | `true` | GA | 1.17 | - |
@@ -342,6 +346,7 @@ different Kubernetes components.
 | `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | 1.15 |
 | `ServiceLoadBalancerFinalizer` | `true` | Beta | 1.16 | 1.16 |
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
+| `ServiceNodeExclusion` | `true` | GA | 1.21 | - |
 | `StartupProbe` | `false` | Alpha | 1.16 | 1.17 |
 | `StartupProbe` | `true` | Beta | 1.18 | 1.19 |
 | `StartupProbe` | `true` | GA | 1.20 | - |
@@ -636,6 +641,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
   host mounts, or containers that are privileged or using specific non-namespaced
   capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled
   if user namespace remapping is enabled in the Docker daemon.
+- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not applied to Service ExternalIPs.
 - `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE.
 - `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features
   of normal volumes (can be provided by third-party storage vendors, storage capacity tracking,

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

@@ -216,6 +216,10 @@ kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
 
 # Produce a period-delimited tree of all keys returned for pods, etc
 kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
+
+# Produce ENV for all pods, assuming you have a default container for the pods, default namespace and the `env` command is supported.
+# Helpful when running any supported command across all pods, not just `env`
+for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done
 ```
 
 ## Updating resources

content/en/docs/reference/kubectl/docker-cli-to-kubectl.md

@@ -265,7 +265,7 @@ nginx-app    1/1     1            1           2m
 ```
 
 ```shell
-kubectl get po -l run=nginx-app
+kubectl get po -l app=nginx-app
 ```
 ```
 NAME                         READY     STATUS    RESTARTS   AGE
@@ -279,7 +279,7 @@ deployment "nginx-app" deleted
 ```
 
 ```shell
-kubectl get po -l run=nginx-app
+kubectl get po -l app=nginx-app
 # Return nothing
 ```
 

content/en/docs/reference/kubernetes-api/service-resources/service-v1.md

@@ -96,7 +96,7 @@ ServiceSpec describes the attributes that a user creates on a service.
 
   - **ports.nodePort** (int32)
 
-    The port on each node on which this service is exposed when type is NodePort or LoadBalancer.  Usually assigned by the system. If a value is specified, in-range, and not in use it will be used, otherwise the operation will fail.  If not specified, a port will be allocated if this Service requires one.  If this field is specified when creating a Service which does not need it, creation will fail. This field will be wiped when updating a Service to no longer need it (e.g. changing type from NodePort to ClusterIP). More info: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
+    The port on each node on which this service is exposed when type is NodePort or LoadBalancer.  Usually assigned by the system. If a value is specified, in-range, and not in use it will be used, otherwise the operation will fail.  If not specified, a port will be allocated if this Service requires one.  If this field is specified when creating a Service which does not need it, creation will fail. This field will be wiped when updating a Service to no longer need it (e.g. changing type from NodePort to ClusterIP). More info: https://kubernetes.io/docs/concepts/services-networking/service/#nodeport
 
   - **ports.appProtocol** (string)
 

content/en/docs/reference/scheduling/policies.md

@@ -43,21 +43,6 @@ The following *predicates* implement filtering:
 - `MaxCSIVolumeCount`: Decides how many {{< glossary_tooltip text="CSI" term_id="csi" >}}
   volumes should be attached, and whether that's over a configured limit.
 
-- `CheckNodeMemoryPressure`: If a Node is reporting memory pressure, and there's no
-  configured exception, the Pod won't be scheduled there.
-
-- `CheckNodePIDPressure`: If a Node is reporting that process IDs are scarce, and
-  there's no configured exception, the Pod won't be scheduled there.
-
-- `CheckNodeDiskPressure`: If a Node is reporting storage pressure (a filesystem that
-   is full or nearly full), and there's no configured exception, the Pod won't be
-   scheduled there.
-
-- `CheckNodeCondition`: Nodes can report that they have a completely full filesystem,
-  that networking isn't available or that kubelet is otherwise not ready to run Pods.
-  If such a condition is set for a Node, and there's no configured exception, the Pod
-  won't be scheduled there.
-
 - `PodToleratesNodeTaints`: checks if a Pod's {{< glossary_tooltip text="tolerations" term_id="toleration" >}}
   can tolerate the Node's {{< glossary_tooltip text="taints" term_id="taint" >}}.
 

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

@@ -59,7 +59,7 @@ kubeadm init phase control-plane all [flags]
 <td colspan="2">--apiserver-extra-args &lt;comma-separated 'key=value' pairs&gt;</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the API Server or override default ones in form of <!-- raw HTML omitted -->=<!-- raw HTML omitted --></p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the API Server or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</p></td>
 </tr>
 
 <tr>
@@ -87,7 +87,7 @@ kubeadm init phase control-plane all [flags]
 <td colspan="2">--controller-manager-extra-args &lt;comma-separated 'key=value' pairs&gt;</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Controller Manager or override default ones in form of <!-- raw HTML omitted -->=<!-- raw HTML omitted --></p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Controller Manager or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</p></td>
 </tr>
 
 <tr>
@@ -136,7 +136,7 @@ kubeadm init phase control-plane all [flags]
 <td colspan="2">--scheduler-extra-args &lt;comma-separated 'key=value' pairs&gt;</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Scheduler or override default ones in form of <!-- raw HTML omitted -->=<!-- raw HTML omitted --></p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Scheduler or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</p></td>
 </tr>
 
 <tr>

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

@@ -48,7 +48,7 @@ kubeadm init phase control-plane apiserver [flags]
 <td colspan="2">--apiserver-extra-args &lt;comma-separated 'key=value' pairs&gt;</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the API Server or override default ones in form of <!-- raw HTML omitted -->=<!-- raw HTML omitted --></p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the API Server or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md

@@ -48,7 +48,7 @@ kubeadm init phase control-plane controller-manager [flags]
 <td colspan="2">--controller-manager-extra-args &lt;comma-separated 'key=value' pairs&gt;</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Controller Manager or override default ones in form of <!-- raw HTML omitted -->=<!-- raw HTML omitted --></p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Controller Manager or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</p></td>
 </tr>
 
 <tr>

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

@@ -76,7 +76,7 @@ kubeadm init phase control-plane scheduler [flags]
 <td colspan="2">--scheduler-extra-args &lt;comma-separated 'key=value' pairs&gt;</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Scheduler or override default ones in form of <!-- raw HTML omitted -->=<!-- raw HTML omitted --></p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>A set of extra flags to pass to the Scheduler or override default ones in form of &lt;flagname&gt;=&lt;value&gt;</p></td>
 </tr>
 
 </tbody>

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

@@ -147,7 +147,7 @@ kubeadm join [api-server-endpoint] [flags]
 <td colspan="2">--discovery-token-ca-cert-hash strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;<!-- raw HTML omitted -->:<!-- raw HTML omitted -->&quot;).</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;&lt;type&gt;:&lt;value&gt;&quot;).</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md

@@ -83,7 +83,7 @@ kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]
 <td colspan="2">--discovery-token-ca-cert-hash strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;<!-- raw HTML omitted -->:<!-- raw HTML omitted -->&quot;).</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;&lt;type&gt;:&lt;value&gt;&quot;).</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md

@@ -69,7 +69,7 @@ kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]
 <td colspan="2">--discovery-token-ca-cert-hash strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;<!-- raw HTML omitted -->:<!-- raw HTML omitted -->&quot;).</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;&lt;type&gt;:&lt;value&gt;&quot;).</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_download-certs.md

@@ -69,7 +69,7 @@ kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [f
 <td colspan="2">--discovery-token-ca-cert-hash strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;<!-- raw HTML omitted -->:<!-- raw HTML omitted -->&quot;).</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;&lt;type&gt;:&lt;value&gt;&quot;).</p></td>
 </tr>
 
 <tr>

content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md

@@ -69,7 +69,7 @@ kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags
 <td colspan="2">--discovery-token-ca-cert-hash strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;<!-- raw HTML omitted -->:<!-- raw HTML omitted -->&quot;).</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;&lt;type&gt;:&lt;value&gt;&quot;).</p></td>
 </tr>
 
 <tr>

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

@@ -62,7 +62,7 @@ kubeadm join phase kubelet-start [api-server-endpoint] [flags]
 <td colspan="2">--discovery-token-ca-cert-hash strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;<!-- raw HTML omitted -->:<!-- raw HTML omitted -->&quot;).</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;&lt;type&gt;:&lt;value&gt;&quot;).</p></td>
 </tr>
 
 <tr>

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

@@ -97,7 +97,7 @@ kubeadm join phase preflight [api-server-endpoint] [flags]
 <td colspan="2">--discovery-token-ca-cert-hash strings</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;<!-- raw HTML omitted -->:<!-- raw HTML omitted -->&quot;).</p></td>
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>For token-based discovery, validate that the root CA public key matches this hash (format: &quot;&lt;type&gt;:&lt;value&gt;&quot;).</p></td>
 </tr>
 
 <tr>

content/en/docs/setup/best-practices/cluster-large.md

@@ -24,7 +24,7 @@ on how your cluster is deployed.
 
 To avoid running into cloud provider quota issues, when creating a cluster with many nodes,
 consider:
-* Request a quota increase for cloud resources such as:
+* Requesting a quota increase for cloud resources such as:
     * Computer instances
     * CPUs
     * Storage volumes
@@ -33,7 +33,7 @@ consider:
     * Number of load balancers
     * Network subnets
     * Log streams
-* Gate the cluster scaling actions to brings up new nodes in batches, with a pause
+* Gating the cluster scaling actions to bring up new nodes in batches, with a pause
   between batches, because some cloud providers rate limit the creation of new instances.
 
 ## Control plane components
@@ -66,6 +66,10 @@ When creating a cluster, you can (using custom tooling):
 * start and configure additional etcd instance
 * configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events
 
+See [Operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/) and
+[Set up a High Availability etcd cluster with kubeadm](docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
+for details on configuring and managing etcd for a large cluster.
+
 ## Addon resources
 
 Kubernetes [resource limits](/docs/concepts/configuration/manage-resources-containers/)

content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md

@@ -78,9 +78,13 @@ kind: ClusterConfiguration
 kubernetesVersion: v1.16.0
 scheduler:
   extraArgs:
-    bind-address: 0.0.0.0
+    config: /etc/kubernetes/scheduler-config.yaml
-    config: /home/johndoe/schedconfig.yaml
+  extraVolumes:
-    kubeconfig: /home/johndoe/kubeconfig.yaml
+    - name: schedulerconfig
+      hostPath: /home/johndoe/schedconfig.yaml
+      mountPath: /etc/kubernetes/scheduler-config.yaml
+      readOnly: true
+      pathType: "File"
 ```
 
 

content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md

@@ -246,8 +246,8 @@ this example.
 
     ```sh
     root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
+    root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml
+    root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml
     ```
 
 1. Optional: Check the cluster health

content/en/docs/setup/release/_index.md

@@ -1,4 +0,0 @@
----
-title: "Release notes and version skew"
-weight: 10
----

content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md

@@ -196,13 +196,6 @@ the slightly simpler syntax:
 kubectl port-forward deployment/mongo :27017
 ```
 
-The output is similar to this:
-
-```
-Forwarding from 127.0.0.1:63753 -> 27017
-Forwarding from [::1]:63753 -> 27017
-```
-
 The `kubectl` tool finds a local port number that is not in use (avoiding low ports numbers,
 because these might be used by other applications). The output is similar to:
 

content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -34,7 +34,7 @@ Dashboard also provides information on the state of Kubernetes resources in your
 The Dashboard UI is not deployed by default. To deploy it, run the following command:
 
 ```
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
 ```
 
 ## Accessing the Dashboard UI

content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -229,7 +229,7 @@ serverTLSBootstrap: true
 
 If you have already created the cluster you must adapt it by doing the following:
  - Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace.
-In that ConfigMap, the `config` key has a
+In that ConfigMap, the `kubelet` key has a
 [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
 document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`.
 - On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml`

content/en/docs/tasks/administer-cluster/nodelocaldns.md

@@ -79,7 +79,7 @@ If you are using the sample manifest from the previous point, this will require
   * If kube-proxy is running in IPVS mode:
 
     ``` bash
-     sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
+     sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
     ```
      In this mode, node-local-dns pods listen only on `<node-local-address>`. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address.
      `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods.

content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md

@@ -131,6 +131,8 @@ The output is similar to:
 
 ```yaml
 apiVersion: v1
+data:
+  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
 kind: Secret
 metadata:
   creationTimestamp: 2018-11-15T20:40:59Z
@@ -139,8 +141,6 @@ metadata:
   resourceVersion: "7225"
   uid: c280ad2e-e916-11e8-98f2-025000000001
 type: Opaque
-data:
-  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
 ```
 
 The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by
@@ -168,6 +168,8 @@ Results in the following Secret:
 
 ```yaml
 apiVersion: v1
+data:
+  username: YWRtaW5pc3RyYXRvcg==
 kind: Secret
 metadata:
   creationTimestamp: 2018-11-15T20:46:46Z
@@ -176,8 +178,6 @@ metadata:
   resourceVersion: "7579"
   uid: 91460ecb-e917-11e8-98f2-025000000001
 type: Opaque
-data:
-  username: YWRtaW5pc3RyYXRvcg==
 ```
 
 Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.

content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md

@@ -1,5 +1,5 @@
 ---
-title: Managing Secret using kubectl
+title: Managing Secrets using kubectl
 content_type: task
 weight: 10
 description: Creating Secret objects using kubectl command line.
@@ -15,7 +15,7 @@ description: Creating Secret objects using kubectl command line.
 
 ## Create a Secret
 
-A `Secret` can contain user credentials required by Pods to access a database.
+A `Secret` can contain user credentials required by pods to access a database.
 For example, a database connection string consists of a username and password.
 You can store the username in a file `./username.txt` and the password in a
 file `./password.txt` on your local machine.
@@ -24,11 +24,10 @@ file `./password.txt` on your local machine.
 echo -n 'admin' > ./username.txt
 echo -n '1f2d1e2e67df' > ./password.txt
 ```
-
+In these commands, the `-n` flag ensures that the generated files do not have
-The `-n` flag in the above two commands ensures that the generated files will
+an extra newline character at the end of the text. This is important because
-not contain an extra newline character at the end of the text. This is
+when `kubectl` reads a file and encodes the content into a base64 string, the
-important because when `kubectl` reads a file and encode the content into
+extra newline character gets encoded too.
-base64 string, the extra newline character gets encoded too.
 
 The `kubectl create secret` command packages these files into a Secret and creates
 the object on the API server.
@@ -45,7 +44,7 @@ The output is similar to:
 secret/db-user-pass created
 ```
 
-Default key name is the filename. You may optionally set the key name using
+The default key name is the filename. You can optionally set the key name using
 `--from-file=[key=]source`. For example:
 
 ```shell
@@ -54,17 +53,18 @@ kubectl create secret generic db-user-pass \
   --from-file=password=./password.txt
 ```
 
-You do not need to escape special characters in passwords from files
+You do not need to escape special characters in password strings that you 
-(`--from-file`).
+include in a file.
 
 You can also provide Secret data using the `--from-literal=<key>=<value>` tag.
 This tag can be specified more than once to provide multiple key-value pairs.
 Note that special characters such as `$`, `\`, `*`, `=`, and `!` will be
 interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing))
 and require escaping.
+
 In most shells, the easiest way to escape the password is to surround it with
-single quotes (`'`).  For example, if your actual password is `S!B\*d$zDsb=`,
+single quotes (`'`). For example, if your password is `S!B\*d$zDsb=`,
-you should execute the command this way:
+run the following command:
 
 ```shell
 kubectl create secret generic dev-db-secret \
@@ -74,7 +74,7 @@ kubectl create secret generic dev-db-secret \
 
 ## Verify the Secret
 
-You can check that the secret was created:
+Check that the Secret was created:
 
 ```shell
 kubectl get secrets
@@ -111,7 +111,7 @@ username:    5 bytes
 
 The commands `kubectl get` and `kubectl describe` avoid showing the contents
 of a `Secret` by default. This is to protect the `Secret` from being exposed
-accidentally to an onlooker, or from being stored in a terminal log.
+accidentally, or from being stored in a terminal log.
 
 ## Decoding the Secret  {#decoding-secret}
 
@@ -141,7 +141,7 @@ The output is similar to:
 
 ## Clean Up
 
-To delete the Secret you have created:
+Delete the Secret you created:
 
 ```shell
 kubectl delete secret db-user-pass
@@ -152,5 +152,5 @@ kubectl delete secret db-user-pass
 ## {{% heading "whatsnext" %}}
 
 - Read more about the [Secret concept](/docs/concepts/configuration/secret/)
-- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- Learn how to [manage Secrets using config files](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
-- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)

content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md

@@ -48,7 +48,19 @@ secretGenerator:
   - password=1f2d1e2e67df
 ```
 
-Note that in both cases, you don't need to base64 encode the values.
+You can also define the `secretGenerator` in the `kustomization.yaml`
+file by providing `.env` files.
+For example, the following `kustomization.yaml` file pulls in data from
+`.env.secret` file:
+
+```yaml
+secretGenerator:
+- name: db-user-pass
+  envs:
+  - .env.secret
+```
+
+Note that in all cases, you don't need to base64 encode the values.
 
 ## Create the Secret
 

content/en/docs/tasks/configure-pod-container/configure-gmsa.md

@@ -197,21 +197,70 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl
 
 1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity.
 
+## Containerd 
+
+On Windows Server 2019, in order to use GMSA with containerd, you must be running OS Build 17763.1817 (or later) which can be installed using the patch [KB5000822](https://support.microsoft.com/en-us/topic/march-9-2021-kb5000822-os-build-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564). 
+
+There is also a known issue with containerd that occurs when trying to connect to SMB shares from Pods. Once you have configured GMSA, the pod will be unable to connect to the share using the hostname or FQDN, but connecting to the share using an IP address works as expected. 
+
+```PowerShell
+ping adserver.ad.local
+```
+and correctly resolves the hostname to an IPv4 address. The output is similar to:
+
+```
+Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
+Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
+Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
+Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
+Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
+```
+
+However, when attempting to browse the directory using the hostname
+
+```PowerShell
+cd \\adserver.ad.local\test
+```
+
+you see an error that implies the target share doesn't exist:
+
+```
+cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
+At line:1 char:1
++ cd \\adserver.ad.local\test
++ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    + CategoryInfo          : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
+    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
+```
+
+but you notice that the error disappears if you browse to the share using its IPv4 address instead; for example:
+
+```PowerShell
+cd \\192.168.111.18\test
+```
+
+After you change into a directory within the share, you see a prompt similar to:
+
+```
+Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
+```
+
+To correct the behaviour you must run the following on the node `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1` to add the required registry key. This node change will only take effect in newly created pods, meaning you must now recreate any running pods which require access to SMB shares.
+
 ## Troubleshooting
 
 If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take.
 
-First, make sure the credspec has been passed to the Pod.  To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.  In the example below the Pod did not get the credspec correctly:
+First, make sure the credspec has been passed to the Pod.  To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.  
 
-```shell
+In the example below the Pod did not get the credspec correctly:
+
+```PowerShell
 kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
-
+```
-Windows PowerShell
+nltest.exe /parentdomain` results in the following error:
-Copyright (C) Microsoft Corporation. All rights reserved.
+```
-
-PS C:\> nltest.exe /parentdomain
 Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
-PS C:\>
 ```
 
 If your Pod did get the credspec correctly, then next check communication with the domain.  First, from inside of your Pod, quickly do an nslookup to find the root of your domain.
@@ -224,23 +273,30 @@ This will tell us 3 things:
 
 If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain.  To do this, again, `exec` into your Pod and run the `nltest.exe /query` command.
 
-```shell
+```PowerShell
-PS C:\> nltest.exe /query
+nltest.exe /query
+```
+
+Results in the following output:
+```
 I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
 ```
 
-This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec.  You can try to repair the secure channel by running the `nltest.exe /sc_reset:domain.example` command.
+This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec.  You can try to repair the secure channel by running the following:
 
-```shell
+```PowerShell
-PS C:\> nltest /sc_reset:domain.example
+nltest /sc_reset:domain.example
+```
+
+If the command is successful you will see and output similar to this:
+```
 Flags: 30 HAS_IP  HAS_TIMESERV
 Trusted DC Name \\dc10.domain.example
 Trusted DC Connection Status Status = 0 0x0 NERR_Success
 The command completed successfully
-PS C:\>
 ```
 
-If the above command corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec.  If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete.
+If the above corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec.  If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete.
 
 ```yaml
         image: registry.domain.example/iis-auth:1809v1
@@ -252,6 +308,3 @@ If the above command corrects the error, you can automate the step by adding the
 ```
 
 If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error.
-
-## GMSA limitations
-When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will receive the identity of and calls from `nltest.exe /query` will work.  It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required.  The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44).

content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md

@@ -624,9 +624,20 @@ Like before, all previous files in the `/etc/config/` directory will be deleted.
 You can project keys to specific paths and specific permissions on a per-file
 basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax.
 
+### Optional References
+
+A ConfigMap reference may be marked "optional".  If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced
+key is non-existent the path will be absent beneath the mount point.
+
 ### Mounted ConfigMaps are updated automatically
 
-When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of the pod's annotations.
+When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into
+existence after a pod has started.
+
+Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the
+ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as
+kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of
+the pod's annotations.
 
 {{< note >}}
 A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.

content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md

@@ -146,7 +146,7 @@ All modifications to a cron job, especially its `.spec`, are applied only to the
 The `.spec.schedule` is a required field of the `.spec`.
 It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed.
 
-The format also includes extended `vixie cron` step values. As explained in the
+The format also includes extended "Vixie cron" step values. As explained in the
 [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
 
 > Step values can be	used in	conjunction with ranges.  Following a range

content/en/docs/tasks/manage-kubernetes-objects/kustomization.md

@@ -86,6 +86,43 @@ metadata:
   name: example-configmap-1-8mbdf7882g
 ```
 
+To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.env` file:
+
+```shell
+# Create a .env file
+cat <<EOF >.env
+FOO=Bar
+EOF
+
+cat <<EOF >./kustomization.yaml
+configMapGenerator:
+- name: example-configmap-1
+  envs:
+  - .env
+EOF
+```
+
+The generated ConfigMap can be examined with the following command:
+
+```shell
+kubectl kustomize ./
+```
+
+The generated ConfigMap is:
+
+```yaml
+apiVersion: v1
+data:
+    FOO=Bar
+kind: ConfigMap
+metadata:
+  name: example-configmap-1-8mbdf7882g
+```
+
+{{< note >}}
+Each variable in the `.env` file becomes a separate key in the ConfigMap that you generate. This is different from the previous example which embeds a file named `.properties` (and all its entries) as the value for a single key.
+{{< /note >}}
+
 ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair:
 
 ```shell
@@ -975,4 +1012,3 @@ deployment.apps "dev-my-nginx" deleted
 * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
 * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
-

content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md

@@ -310,10 +310,10 @@ Patch your Deployment:
 
 {{< tabs name="kubectl_retainkeys_example" >}}
 {{{< tab name="Bash" codelang="bash" >}}
-kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)"
+kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)"
 {{< /tab >}}
 {{< tab name="PowerShell" codelang="posh" >}}
-kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw)
+kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw)
 {{< /tab >}}}
 {{< /tabs >}}
 
@@ -341,10 +341,10 @@ Patch your Deployment again with this new patch:
 
 {{< tabs name="kubectl_retainkeys2_example" >}}
 {{{< tab name="Bash" codelang="bash" >}}
-kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)"
+kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)"
 {{< /tab >}}
 {{< tab name="PowerShell" codelang="posh" >}}
-kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw)
+kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw)
 {{< /tab >}}}
 {{< /tabs >}}
 

content/en/docs/tasks/run-application/delete-stateful-set.md

@@ -43,14 +43,14 @@ You may need to delete the associated headless service separately after the Stat
 kubectl delete service <service-name>
 ```
 
-When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=false`.
+When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=orphan`.
 For example:
 
 ```shell
-kubectl delete -f <file.yaml> --cascade=false
+kubectl delete -f <file.yaml> --cascade=orphan
 ```
 
-By passing `--cascade=false` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
+By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
 
 ```shell
 kubectl delete pods -l app=myapp

content/en/examples/admin/konnectivity/konnectivity-agent.yaml

@@ -22,7 +22,7 @@ spec:
         - key: "CriticalAddonsOnly"
           operator: "Exists"
       containers:
-        - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.12
+        - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.16
           name: konnectivity-agent
           command: ["/proxy-agent"]
           args: [

content/en/examples/admin/konnectivity/konnectivity-server.yaml

@@ -8,7 +8,7 @@ spec:
   hostNetwork: true
   containers:
   - name: konnectivity-server-container
-    image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.12
+    image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.16
     command: ["/proxy-server"]
     args: [
             "--logtostderr=true",

content/en/examples/application/job/redis/worker.py

@@ -8,7 +8,7 @@ host="redis"
 # import os
 # host = os.getenv("REDIS_SERVICE_HOST")
 
-q = rediswq.RedisWQ(name="job2", host="redis")
+q = rediswq.RedisWQ(name="job2", host=host)
 print("Worker with sessionID: " +  q.sessionID())
 print("Initial queue state: empty=" + str(q.empty()))
 while not q.empty():

content/en/examples/controllers/daemonset.yaml

@@ -18,6 +18,7 @@ spec:
       # this toleration is to have the daemonset runnable on master nodes
       # remove it if your masters can't run pods
       - key: node-role.kubernetes.io/master
+        operator: Exists
         effect: NoSchedule
       containers:
       - name: fluentd-elasticsearch

content/en/releases/OWNERS

@@ -0,0 +1,17 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+# This is the directory for English source content.
+# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
+
+reviewers:
+  - sig-docs-en-reviews
+  - release-engineering-reviewers
+
+approvers:
+  - sig-docs-en-owners
+  - sig-release-leads
+  - release-engineering-approvers
+
+labels:
+- sig/release
+- area/release-eng

content/en/releases/_index.md

@@ -0,0 +1,27 @@
+---
+linktitle: Release History
+title: Releases
+type: docs
+---
+
+
+<!-- overview -->
+
+The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).  Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
+
+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.
+
+More information in the [version skew policy](/releases/version-skew-policy/) document.
+
+<!-- body -->
+
+## Release History
+
+{{< release-data >}}
+
+## Upcoming Release
+
+Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release!
+
+## Helpful Resources

content/en/releases/download.md

@@ -0,0 +1,26 @@
+---
+title: Download Kubernetes
+type: docs
+---
+## Core Kubernetes components
+
+Find links to download Kubernetes components (and their checksums) in the [CHANGELOG](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) files.
+
+Alternately, use [downloadkubernetes.com](https://www.downloadkubernetes.com/) to filter by version and architecture.
+
+## kubectl
+
+<!-- overview -->
+The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows
+you to run commands against Kubernetes clusters.
+
+You can use kubectl to deploy applications, inspect and manage cluster resources,
+and view logs. For more information including a complete list of kubectl operations, see the
+[`kubectl` reference documentation](/docs/reference/kubectl/).
+
+kubectl is installable on a variety of Linux platforms, macOS and Windows. 
+Find your preferred operating system below.
+
+- [Install kubectl on Linux](/docs/tasks/tools/install-kubectl-linux)
+- [Install kubectl on macOS](/docs/tasks/tools/install-kubectl-macos)
+- [Install kubectl on Windows](/docs/tasks/tools/install-kubectl-windows)

content/en/releases/notes.md

@@ -0,0 +1,13 @@
+---
+linktitle: Release Notes
+title: Notes
+type: docs
+description: >
+  Kubernetes release notes.
+sitemap:
+  priority: 0.5
+---
+
+Release notes can be found by reading the [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) that matches your Kubernetes version. View the changelog for {{< skew latestVersion >}} on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew latestVersion >}}.md).
+
+Alternately, release notes can be searched and filtered online at: [relnotes.k8s.io](https://relnotes.k8s.io). View filtered release notes for {{< skew latestVersion >}} on [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew latestVersion >}}.0).

content/en/releases/patch-releases.md

@@ -0,0 +1,164 @@
+---
+title: Patch Releases
+type: docs
+---
+
+Schedule and team contact information for Kubernetes patch releases.
+
+For general information about Kubernetes release cycle, see the
+[release process description].
+
+## Cadence
+
+Our typical patch release cadence is monthly.  It is
+commonly a bit faster (1 to 2 weeks) for the earliest patch releases
+after a 1.X minor release.  Critical bug fixes may cause a more
+immediate release outside of the normal cadence.  We also aim to not make
+releases during major holiday periods.
+
+## Contact
+
+See the [Release Managers page][release-managers] for full contact details on the Patch Release Team.
+
+Please give us a business day to respond - we may be in a different timezone!
+
+In between releases the team is looking at incoming cherry pick
+requests on a weekly basis.  The team will get in touch with
+submitters via GitHub PR, SIG channels in Slack, and direct messages
+in Slack and [email](mailto:release-managers-private@kubernetes.io)
+if there are questions on the PR.
+
+## Cherry picks
+
+Please follow the [cherry pick process][cherry-picks].
+
+Cherry picks must be merge-ready in GitHub with proper labels (e.g.,
+`approved`, `lgtm`, `release-note`) and passing CI tests ahead of the
+cherry pick deadline.  This is typically two days before the target
+release, but may be more.  Earlier PR readiness is better, as we
+need time to get CI signal after merging your cherry picks ahead
+of the actual release.
+
+Cherry pick PRs which miss merge criteria will be carried over and tracked
+for the next patch release.
+
+## Support Period
+
+In accordance with the [yearly support KEP][yearly-support], the Kubernetes
+Community will support active patch release series for a period of roughly
+fourteen (14) months.
+
+The first twelve months of this timeframe will be considered the standard
+period.
+
+Towards the end of the twelve month, the following will happen:
+
+- [Release Managers][release-managers] will cut a release
+- The patch release series will enter maintenance mode
+
+During the two-month maintenance mode period, Release Managers may cut
+additional maintenance releases to resolve:
+
+- CVEs (under the advisement of the Product Security Committee)
+- dependency issues (including base image updates)
+- critical core component issues
+
+At the end of the two-month maintenance mode period, the patch release series
+will be considered EOL (end of life) and cherry picks to the associated branch
+are to be closed soon afterwards.
+
+Note that the 28th of the month was chosen for maintenance mode and EOL target
+dates for simplicity (every month has it).
+
+## Upcoming Monthly Releases
+
+Timelines may vary with the severity of bug fixes, but for easier planning we
+will target the following monthly release points.  Unplanned, critical
+releases may also occur in between these.
+
+| Monthly Patch Release | Target date |
+| --- | --- |
+| June 2021 | 2021-06-16 |
+| July 2021 | 2021-07-14 |
+| August 2021 | 2021-08-11 |
+| September 2021 | 2021-09-15 |
+
+## Detailed Release History for Active Branches
+
+### 1.21
+
+**1.21** enters maintenance mode on **2022-04-28**
+
+End of Life for **1.21** is **2022-06-28**
+
+| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
+|--- |--- |--- |
+| 1.21.2        | 2021-06-12           | 2021-06-16  |
+| 1.21.1        | 2021-05-07           | 2021-05-12  |
+
+### 1.20
+
+**1.20** enters maintenance mode on **2021-12-28**
+
+End of Life for **1.20** is **2022-02-28**
+
+| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
+|--- |--- |--- |
+| 1.20.8        | 2021-06-12           | 2021-06-16  |
+| 1.20.7        | 2021-05-07           | 2021-05-12  |
+| 1.20.6        | 2021-04-09           | 2021-04-14  |
+| 1.20.5        | 2021-03-12           | 2021-03-17  |
+| 1.20.4        | 2021-02-12           | 2021-02-18  |
+| 1.20.3        | [Conformance Tests Issue](https://groups.google.com/g/kubernetes-dev/c/oUpY9vWgzJo) | 2021-02-17  |
+| 1.20.2        | 2021-01-08           | 2021-01-13  |
+| 1.20.1        | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18  |
+
+### 1.19
+
+**1.19** enters maintenance mode on **2021-08-28**
+
+End of Life for **1.19** is **2021-10-28**
+
+| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE |
+|--- |--- |--- |
+| 1.19.12       | 2021-06-12           | 2021-06-16  |
+| 1.19.11       | 2021-05-07           | 2021-05-12  |
+| 1.19.10       | 2021-04-09           | 2021-04-14  |
+| 1.19.9        | 2021-03-12           | 2021-03-17  |
+| 1.19.8        | 2021-02-12           | 2021-02-17  |
+| 1.19.7        | 2021-01-08           | 2021-01-13  |
+| 1.19.6        | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | 2020-12-18  |
+| 1.19.5        | 2020-12-04           | 2020-12-09  |
+| 1.19.4        | 2020-11-06           | 2020-11-11  |
+| 1.19.3        | 2020-10-09           | 2020-10-14  |
+| 1.19.2        | 2020-09-11           | 2020-09-16  |
+| 1.19.1        | 2020-09-04           | 2020-09-09  |
+
+## Non-Active Branch History
+
+These releases are no longer supported.
+
+| Minor Version | Final Patch Release | EOL date |
+| --- | --- | --- |
+| 1.18 | 1.18.19 | 2021-05-12 |
+| 1.17 | 1.17.17 | 2021-01-13 |
+| 1.16 | 1.16.15 | 2020-09-02 |
+| 1.15 | 1.15.12 | 2020-05-06 |
+| 1.14 | 1.14.10 | 2019-12-11 |
+| 1.13 | 1.13.12 | 2019-10-15 |
+| 1.12 | 1.12.10 | 2019-07-08 |
+| 1.11 | 1.11.10 | 2019-05-01 |
+| 1.10 | 1.10.13 | 2019-02-13 |
+| 1.9  | 1.9.11  | 2018-09-29 |
+| 1.8  | 1.8.15  | 2018-07-12 |
+| 1.7  | 1.7.16  | 2018-04-04 |
+| 1.6  | 1.6.13  | 2017-11-23 |
+| 1.5  | 1.5.8   | 2017-10-01 |
+| 1.4  | 1.4.12  | 2017-04-21 |
+| 1.3  | 1.3.10  | 2016-11-01 |
+| 1.2  | 1.2.7   | 2016-10-23 |
+
+[cherry-picks]: https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md
+[release-managers]: /release-managers.md
+[release process description]: /release.md
+[yearly-support]: https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md

content/en/releases/release-managers.md

@@ -0,0 +1,213 @@
+---
+title: Release Managers
+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.
+
+The responsibilities of each role are described below.
+
+- [Contact](#contact)
+- [Handbooks](#handbooks)
+- [Release Managers](#release-managers)
+  - [Becoming a Release Manager](#becoming-a-release-manager)
+- [Release Manager Associates](#release-manager-associates)
+  - [Becoming a Release Manager Associate](#becoming-a-release-manager-associate)
+- [Build Admins](#build-admins)
+- [SIG Release Leads](#sig-release-leads)
+  - [Chairs](#chairs)
+  - [Technical Leads](#technical-leads)
+
+## Contact
+
+| Mailing List | Slack | Visibility | Usage | Membership |
+| --- | --- | --- | --- | --- |
+| [release-managers@kubernetes.io](mailto:release-managers@kubernetes.io) | [#release-management](https://kubernetes.slack.com/messages/CJH2GBF7Y) (channel) / @release-managers (user group) | Public | Public discussion for Release Managers | All Release Managers (including Associates, Build Admins, and SIG Chairs) |
+| [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership |
+| [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Product Security Committee | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) |
+
+## Handbooks
+
+**NOTE: The Patch Release Team and Branch Manager handbooks will be de-duplicated at a later date.**
+
+- [Patch Release Team][handbook-patch-release]
+- [Branch Managers][handbook-branch-mgmt]
+- [Build Admins][handbook-packaging]
+
+## Release Managers
+
+**Note:** The documentation might refer to the Patch Release Team and the
+Branch Management role. Those two roles were consolidated into the
+Release Managers role.
+
+Minimum requirements for Release Managers and Release Manager Associates are:
+
+- Familiarity with basic Unix commands and able to debug shell scripts.
+- Familiarity with branched source code workflows via `git` and associated
+  `git` command line invocations.
+- General knowledge of Google Cloud (Cloud Build and Cloud Storage).
+- Open to seeking help and communicating clearly.
+- Kubernetes Community [membership][community-membership]
+
+Release Managers are responsible for:
+
+- Coordinating and cutting Kubernetes releases:
+  - Patch releases (`x.y.z`, where `z` > 0)
+  - Minor releases (`x.y.z`, where `z` = 0)
+  - Pre-releases (alpha, beta, and release candidates)
+  - Working with the [Release Team][release-team] through each
+  release cycle
+  - Setting the [schedule and cadence for patch releases][patches]
+- Maintaining the release branches:
+  - Reviewing cherry picks
+  - Ensuring the release branch stays healthy and that no unintended patch
+    gets merged
+- Mentoring the [Release Manager Associates](#associates) group
+- Actively developing features and maintaining the code in k/release
+- Supporting Release Manager Associates and contributors through actively
+  participating in the Buddy program
+  - Check in monthly with Associates and delegate tasks, empower them to cut
+    releases, and mentor
+  - Being available to support Associates in onboarding new contributors e.g.,
+    answering questions and suggesting appropriate work for them to do
+
+This team at times works in close conjunction with the
+[Product Security Committee][psc] and therefore should abide by the guidelines
+set forth in the [Security Release Process][security-release-process].
+
+GitHub Access Controls: [@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers)
+
+GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering)
+
+- Adolfo García Veytia ([@puerco](https://github.com/puerco))
+- Carlos Panato ([@cpanato](https://github.com/cpanato))
+- Daniel Mangum ([@hasheddan](https://github.com/hasheddan))
+- Marko Mudrinić ([@xmudrii](https://github.com/xmudrii))
+- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert))
+- Stephen Augustus ([@justaugustus](https://github.com/justaugustus))
+
+### Becoming a Release Manager
+
+To become a Release Manager, one must first serve as a Release Manager
+Associate. Associates graduate to Release Manager by actively working on
+releases over several cycles and:
+
+- demonstrating the willingness to lead
+- tag-teaming with Release Managers on patches, to eventually cut a release
+  independently
+  - because releases have a limiting function, we also consider substantial
+    contributions to image promotion and other core Release Engineering tasks
+- questioning how Associates work, suggesting improvements, gathering feedback,
+  and driving change
+- being reliable and responsive
+- leaning into advanced work that requires Release Manager-level access and
+  privileges to complete
+
+## Release Manager Associates
+
+Release Manager Associates are apprentices to the Release Managers, formerly
+referred to as Release Manager shadows. They are responsible for:
+
+- Patch release work, cherry pick review
+- Contributing to k/release: updating dependencies and getting used to the
+  source codebase
+- Contributing to the documentation: maintaining the handbooks, ensuring that
+  release processes are documented
+- With help from a release manager: working with the Release Team during the
+  release cycle and cutting Kubernetes releases
+- Seeking opportunities to help with prioritization and communication
+  - Sending out pre-announcements and updates about patch releases
+  - Updating the calendar, helping with the release dates and milestones from
+    the [release cycle timeline][k-sig-release-releases]
+- Through the Buddy program, onboarding new contributors and pairing up with
+  them on tasks
+
+GitHub Mentions: @kubernetes/release-engineering
+
+- Arnaud Meukam ([@ameukam](https://github.com/ameukam))
+- Jim Angel ([@jimangel](https://github.com/jimangel))
+- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung))
+- Max Körbächer ([@mkorbi](https://github.com/mkorbi))
+- Nabarun Pal ([@palnabarun](https://github.com/palnabarun))
+- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs))
+- Taylor Dolezal ([@onlydole](https://github.com/onlydole))
+- Verónica López ([@verolop](https://github.com/verolop))
+- Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin))
+
+### Becoming a Release Manager Associate
+
+Contributors can become Associates by demonstrating the following:
+
+- consistent participation, including 6-12 months of active release
+  engineering-related work
+- experience fulfilling a technical lead role on the Release Team during a
+  release cycle
+  - this experience provides a solid baseline for understanding how SIG Release
+    works overall—including our expectations regarding technical skills,
+    communications/responsiveness, and reliability
+- working on k/release items that improve our interactions with Testgrid,
+  cleaning up libraries, etc.
+  - these efforts require interacting and pairing with Release Managers and
+    Associates
+
+## Build Admins
+
+Build Admins are (currently) Google employees with the requisite access to
+Google build systems/tooling to publish deb/rpm packages on behalf of the
+Kubernetes project. They are responsible for:
+
+- Building, signing, and publishing the deb/rpm packages
+- Being the interlock with Release Managers (and Associates) on the final steps
+of each minor (1.Y) and patch (1.Y.Z) release
+
+GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins)
+
+- Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp))
+- Amit Watve ([@amwat](https://github.com/amwat))
+- Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder))
+- Grant McCloskey ([@MushuEE](https://github.com/MushuEE))
+
+## SIG Release Leads
+
+SIG Release Chairs and Technical Leads are responsible for:
+
+- The governance of SIG Release
+- Leading knowledge exchange sessions for Release Managers and Associates
+- Coaching on leadership and prioritization
+
+They are mentioned explicitly here as they are owners of the various
+communications channels and permissions groups (GitHub teams, GCP access) for
+each role. As such, they are highly privileged community members and privy to
+some private communications, which can at times relate to Kubernetes security
+disclosures.
+
+GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads)
+
+### Chairs
+
+- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert))
+- Stephen Augustus ([@justaugustus](https://github.com/justaugustus))
+
+### Technical Leads
+
+- Daniel Mangum ([@hasheddan](https://github.com/hasheddan))
+- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard))
+
+---
+
+Past Branch Managers, can be found in the [releases directory][k-sig-release-releases]
+of the kubernetes/sig-release repository within `release-x.y/release_team.md`.
+
+Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md)
+
+[community-membership]: https://git.k8s.io/community/community-membership.md#member
+[handbook-branch-mgmt]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/branch-manager.md
+[handbook-packaging]: https://git.k8s.io/sig-release/release-engineering/packaging.md
+[handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md
+[k-sig-release-releases]: https://git.k8s.io/sig-release/releases
+[patches]: /patch-releases.md
+[psc]: https://git.k8s.io/community/committee-product-security/README.md
+[release-team]: https://git.k8s.io/sig-release/release-team/README.md
+[security-release-process]: https://git.k8s.io/security/security-release-process.md

content/en/releases/release.md

@@ -0,0 +1,364 @@
+---
+title: Kubernetes Release Cycle
+type: docs
+auto_generated: true
+---
+<!-- THIS CONTENT IS AUTO-GENERATED via ./scripts/releng/update-release-info.sh in k/website -->
+
+{{< warning >}}
+This content is auto-generated and links may not function. The source of the document is located [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md).
+{{< /warning >}}
+
+# Targeting enhancements, Issues and PRs to Release Milestones
+
+This document is focused on Kubernetes developers and contributors who need to
+create an enhancement, issue, or pull request which targets a specific release
+milestone.
+
+- [TL;DR](#tldr)
+  - [Normal Dev (Weeks 1-8)](#normal-dev-weeks-1-8)
+  - [Code Freeze (Weeks 9-11)](#code-freeze-weeks-9-11)
+  - [Post-Release (Weeks 11+)](#post-release-weeks-11)
+- [Definitions](#definitions)
+- [The Release Cycle](#the-release-cycle)
+- [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
+- [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
+  - [Milestone Maintainers](#milestone-maintainers)
+  - [Feature additions](#feature-additions)
+  - [Issue additions](#issue-additions)
+  - [PR Additions](#pr-additions)
+- [Other Required Labels](#other-required-labels)
+  - [SIG Owner Label](#sig-owner-label)
+  - [Priority Label](#priority-label)
+  - [Issue/PR Kind Label](#issuepr-kind-label)
+
+The process for shepherding enhancements, issues, and pull requests into a
+Kubernetes release spans multiple stakeholders:
+
+- the enhancement, issue, and pull request owner(s)
+- SIG leadership
+- the [Release Team][release-team]
+
+Information on workflows and interactions are described below.
+
+As the owner of an enhancement, issue, or pull request (PR), it is your
+responsibility to ensure release milestone requirements are met. Automation and
+the Release Team will be in contact with you if updates are required, but
+inaction can result in your work being removed from the milestone. Additional
+requirements exist when the target milestone is a prior release (see
+[cherry pick process][cherry-picks] for more information).
+
+## TL;DR
+
+If you want your PR to get merged, it needs the following required labels and
+milestones, represented here by the Prow /commands it would take to add them:
+
+### Normal Dev (Weeks 1-8)
+
+- /sig {name}
+- /kind {type}
+- /lgtm
+- /approved
+
+### [Code Freeze][code-freeze] (Weeks 9-11)
+
+- /milestone {v1.y}
+- /sig {name}
+- /kind {bug, failing-test}
+- /lgtm
+- /approved
+
+### Post-Release (Weeks 11+)
+
+Return to 'Normal Dev' phase requirements:
+
+- /sig {name}
+- /kind {type}
+- /lgtm
+- /approved
+
+Merges into the 1.y branch are now [via cherry picks][cherry-picks], approved
+by [Release Managers][release-managers].
+
+In the past, there was a requirement for a milestone-targeted pull requests to
+have an associated GitHub issue opened, but this is no longer the case.
+Features or enhancements are effectively GitHub issues or [KEPs][keps] which
+lead to subsequent PRs.
+
+The general labeling process should be consistent across artifact types.
+
+## Definitions
+
+- *issue owners*: Creator, assignees, and user who moved the issue into a
+  release milestone
+
+- *Release Team*: Each Kubernetes release has a team doing project management
+  tasks described [here][release-team].
+
+  The contact info for the team associated with any given release can be found
+  [here](https://git.k8s.io/sig-release/releases/).
+
+- *Y days*: Refers to business days
+
+- *enhancement*: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)"
+
+- *[Enhancements Freeze][enhancements-freeze]*:
+  the deadline by which [KEPs][keps] have to be completed in order for
+  enhancements to be part of the current release
+
+- *[Exception Request][exceptions]*:
+  The process of requesting an extension on the deadline for a particular
+  Enhancement
+
+- *[Code Freeze][code-freeze]*:
+  The period of ~4 weeks before the final release date, during which only
+  critical bug fixes are merged into the release.
+
+- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*:
+  The process of removing an Enhancement from a release milestone if it is not
+  fully implemented or is otherwise considered not stable.
+
+- *release milestone*: semantic version string or
+  [GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests)
+  referring to a release MAJOR.MINOR `vX.Y` version.
+
+  See also
+  [release versioning](/contributors/design-proposals/release/versioning.md).
+
+- *release branch*: Git branch `release-X.Y` created for the `vX.Y` milestone.
+
+  Created at the time of the `vX.Y-rc.0` release and maintained after the
+  release for approximately 12 months with `vX.Y.Z` patch releases.
+
+  Note: releases 1.19 and newer receive 1 year of patch release support, and
+  releases 1.18 and earlier received 9 months of patch release support.
+
+## The Release Cycle
+
+![Image of one Kubernetes release cycle](release-cycle.png)
+
+Kubernetes releases currently happen approximately four times per year.
+
+The release process can be thought of as having three main phases:
+
+- Enhancement Definition
+- Implementation
+- Stabilization
+
+But in reality, this is an open source and agile project, with feature planning
+and implementation happening at all times. Given the project scale and globally
+distributed developer base, it is critical to project velocity to not rely on a
+trailing stabilization phase and rather have continuous integration testing
+which ensures the project is always stable so that individual commits can be
+flagged as having broken something.
+
+With ongoing feature definition through the year, some set of items will bubble
+up as targeting a given release. **[Enhancements Freeze][enhancements-freeze]**
+starts ~4 weeks into release cycle. By this point all intended feature work for
+the given release has been defined in suitable planning artifacts in
+conjunction with the Release Team's [Enhancements Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md).
+
+After Enhancements Freeze, tracking milestones on PRs and issues is important.
+Items within the milestone are used as a punchdown list to complete the
+release. *On issues*, milestones must be applied correctly, via triage by the
+SIG, so that [Release Team][release-team] can track bugs and enhancements (any
+enhancement-related issue needs a milestone).
+
+There is some automation in place to help automatically assign milestones to
+PRs.
+
+This automation currently applies to the following repos:
+
+- `kubernetes/enhancements`
+- `kubernetes/kubernetes`
+- `kubernetes/release`
+- `kubernetes/sig-release`
+- `kubernetes/test-infra`
+
+At creation time, PRs against the `master` branch need humans to hint at which
+milestone they might want the PR to target. Once merged, PRs against the
+`master` branch have milestones auto-applied so from that time onward human
+management of that PR's milestone is less necessary. On PRs against release
+branches, milestones are auto-applied when the PR is created so no human
+management of the milestone is ever necessary.
+
+Any other effort that should be tracked by the Release Team that doesn't fall
+under that automation umbrella should be have a milestone applied.
+
+Implementation and bug fixing is ongoing across the cycle, but culminates in a
+code freeze period.
+
+**[Code Freeze][code-freeze]** starts in week ~10 and continues for ~2 weeks.
+Only critical bug fixes are accepted into the release codebase during this
+time.
+
+There are approximately two weeks following Code Freeze, and preceding release,
+during which all remaining critical issues must be resolved before release.
+This also gives time for documentation finalization.
+
+When the code base is sufficiently stable, the master branch re-opens for
+general development and work begins there for the next release milestone. Any
+remaining modifications for the current release are cherry picked from master
+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.png)
+
+## Removal Of Items From The Milestone
+
+Before getting too far into the process for adding an item to the milestone,
+please note:
+
+Members of the [Release Team][release-team] may remove issues from the
+milestone if they or the responsible SIG determine that the issue is not
+actually blocking the release and is unlikely to be resolved in a timely
+fashion.
+
+Members of the Release Team may remove PRs from the milestone for any of the
+following, or similar, reasons:
+
+- PR is potentially de-stabilizing and is not needed to resolve a blocking
+  issue
+- PR is a new, late feature PR and has not gone through the enhancements
+  process or the [exception process][exceptions]
+- There is no responsible SIG willing to take ownership of the PR and resolve
+  any follow-up issues with it
+- PR is not correctly labelled
+- Work has visibly halted on the PR and delivery dates are uncertain or late
+
+While members of the Release Team will help with labelling and contacting
+SIG(s), it is the responsibility of the submitter to categorize PRs, and to
+secure support from the relevant SIG to guarantee that any breakage caused by
+the PR will be rapidly resolved.
+
+Where additional action is required, an attempt at human to human escalation
+will be made by the Release Team through the following channels:
+
+- Comment in GitHub mentioning the SIG team and SIG members as appropriate for
+  the issue type
+- Emailing the SIG mailing list
+  - bootstrapped with group email addresses from the
+    [community sig list][sig-list]
+  - optionally also directly addressing SIG leadership or other SIG members
+- Messaging the SIG's Slack channel
+  - bootstrapped with the slackchannel and SIG leadership from the
+    [community sig list][sig-list]
+  - optionally directly "@" mentioning SIG leadership or others by handle
+
+## Adding An Item To The Milestone
+
+### Milestone Maintainers
+
+The members of the [`milestone-maintainers`](https://github.com/orgs/kubernetes/teams/milestone-maintainers/members)
+GitHub team are entrusted with the responsibility of specifying the release
+milestone on GitHub artifacts.
+
+This group is [maintained](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
+by SIG Release and has representation from the various SIGs' leadership.
+
+### Feature additions
+
+Feature planning and definition takes many forms today, but a typical example
+might be a large piece of work described in a [KEP][keps], with associated task
+issues in GitHub. When the plan has reached an implementable state and work is
+underway, the enhancement or parts thereof are targeted for an upcoming milestone
+by creating GitHub issues and marking them with the Prow "/milestone" command.
+
+For the first ~4 weeks into the release cycle, the Release Team's Enhancements
+Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG
+meetings to capture all required planning artifacts.
+
+If you have an enhancement to target for an upcoming release milestone, begin a
+conversation with your SIG leadership and with that release's Enhancements
+Lead.
+
+### Issue additions
+
+Issues are marked as targeting a milestone via the Prow "/milestone" command.
+
+The Release Team's [Bug Triage Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md)
+and overall community watch incoming issues and triage them, as described in
+the contributor guide section on
+[issue triage](/contributors/guide/issue-triage.md).
+
+Marking issues with the milestone provides the community better visibility
+regarding when an issue was observed and by when the community feels it must be
+resolved. During [Code Freeze][code-freeze], a milestone must be set to merge
+a PR.
+
+An open issue is no longer required for a PR, but open issues and associated
+PRs should have synchronized labels. For example a high priority bug issue
+might not have its associated PR merged if the PR is only marked as lower
+priority.
+
+### PR Additions
+
+PRs are marked as targeting a milestone via the Prow "/milestone" command.
+
+This is a blocking requirement during Code Freeze as described above.
+
+## Other Required Labels
+
+[Here is the list of labels and their use and purpose.](https://git.k8s.io/test-infra/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs)
+
+### SIG Owner Label
+
+The SIG owner label defines the SIG to which we escalate if a milestone issue
+is languishing or needs additional attention. If there are no updates after
+escalation, the issue may be automatically removed from the milestone.
+
+These are added with the Prow "/sig" command. For example to add the label
+indicating SIG Storage is responsible, comment with `/sig storage`.
+
+### Priority Label
+
+Priority labels are used to determine an escalation path before moving issues
+out of the release milestone. They are also used to determine whether or not a
+release should be blocked on the resolution of the issue.
+
+- `priority/critical-urgent`: Never automatically move out of a release
+  milestone; continually escalate to contributor and SIG through all available
+  channels.
+  - considered a release blocking issue
+  - requires daily updates from issue owners during [Code Freeze][code-freeze]
+  - would require a patch release if left undiscovered until after the minor
+    release
+- `priority/important-soon`: Escalate to the issue owners and SIG owner; move
+  out of milestone after several unsuccessful escalation attempts.
+  - not considered a release blocking issue
+  - would not require a patch release
+  - will automatically be moved out of the release milestone at Code Freeze
+    after a 4 day grace period
+- `priority/important-longterm`: Escalate to the issue owners; move out of the
+  milestone after 1 attempt.
+  - even less urgent / critical than `priority/important-soon`
+  - moved out of milestone more aggressively than `priority/important-soon`
+
+### Issue/PR Kind Label
+
+The issue kind is used to help identify the types of changes going into the
+release over time. This may allow the Release Team to develop a better
+understanding of what sorts of issues we would miss with a faster release
+cadence.
+
+For release targeted issues, including pull requests, one of the following
+issue kind labels must be set:
+
+- `kind/api-change`: Adds, removes, or changes an API
+- `kind/bug`: Fixes a newly discovered bug.
+- `kind/cleanup`: Adding tests, refactoring, fixing old bugs.
+- `kind/design`: Related to design
+- `kind/documentation`: Adds documentation
+- `kind/failing-test`: CI test case is failing consistently.
+- `kind/feature`: New functionality.
+- `kind/flake`: CI test case is showing intermittent failures.
+
+[cherry-picks]: /contributors/devel/sig-release/cherry-picks.md
+[code-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze
+[enhancements-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze
+[exceptions]: https://git.k8s.io/sig-release/releases/release_phases.md#exceptions
+[keps]: https://git.k8s.io/enhancements/keps
+[release-managers]: https://git.k8s.io/sig-release/release-managers.md
+[release-team]: https://git.k8s.io/sig-release/release-team
+[sig-list]: /sig-list.md

content/en/releases/version-skew-policy.md

@@ -6,22 +6,21 @@ reviewers:
 - sig-cluster-lifecycle
 - sig-node
 - sig-release
-title: Kubernetes version and version skew support policy
+title: Version Skew Policy
-content_type: concept
+type: docs
-weight: 30
+description: >
+  The maximum version skew supported between various Kubernetes components.
 ---
 
 <!-- overview -->
 This document describes the maximum version skew supported between various Kubernetes components.
 Specific cluster deployment tools may place additional restrictions on version skew.
 
-
 <!-- body -->
 
 ## Supported versions
 
-Kubernetes versions are expressed as **x.y.z**,
+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.
-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://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
 
 The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}).  Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.

content/es/docs/concepts/_index.md

@@ -31,18 +31,18 @@ Kubernetes tiene diferentes abstracciones que representan el estado de tu sistem
 
 Los objetos básicos de Kubernetes incluyen:
 
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
+* [Pod](/es/docs/concepts/workloads/pods/pod/)
 * [Service](/docs/concepts/services-networking/service/)
 * [Volume](/docs/concepts/storage/volumes/)
-* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
+* [Namespace](/es/docs/concepts/overview/working-with-objects/namespaces/)
 
 Además, Kubernetes contiene abstracciónes de nivel superior llamadas Controladores. Los Controladores se basan en los objetos básicos y proporcionan funcionalidades adicionales sobre ellos. Incluyen:
 
-* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
+* [ReplicaSet](/es/docs/concepts/workloads/controllers/replicaset/)
-* [Deployment](/docs/concepts/workloads/controllers/deployment/)
+* [Deployment](/es/docs/concepts/workloads/controllers/deployment/)
-* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
+* [StatefulSet](/es/docs/concepts/workloads/controllers/statefulset/)
-* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
+* [DaemonSet](/es/docs/concepts/workloads/controllers/daemonset/)
-* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [Job](/es/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 
 
 ## Plano de Control de Kubernetes
@@ -64,15 +64,13 @@ En un clúster de Kubernetes, los nodos son las máquinas (máquinas virtuales,
 #### Metadatos de los Objectos
 
 
-* [Annotations](/docs/concepts/overview/working-with-objects/annotations/)
+* [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/)
 
 
 
 ## {{% heading "whatsnext" %}}
 
 
-Si estás interesado en escribir una página sobre conceptos,
+Si quieres empezar a contribuir a la documentación de Kubernetes accede a la página [Empieza a contribuir](/es/docs/contribute/start/).
-revisa [Usando Templates de Páginas](/docs/home/contribute/page-templates/)
-para obtener información sobre el tipo de página conceptos y la plantilla conceptos.
 
 

content/ko/case-studies/ibm/ibm_featured_logo.svg

@@ -1 +1 @@
-<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:#f9f9f9;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:transparent;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>

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

@@ -304,13 +304,6 @@ ConditionFalse 다.).
 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
 
-
-{{< caution >}}
-`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
-서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
-사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다.
-{{< /caution >}}
-
 ### 노드 용량
 
 노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의

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

@@ -45,7 +45,7 @@ no_list: true
 
 ## 클러스터 보안
 
-* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
+* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)은 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
 
 * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
 

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

@@ -170,4 +170,5 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
 ## {{% heading "whatsnext" %}}
 
 * 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
+* [안정 버전의 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 살펴본다
 * [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다

content/ko/docs/concepts/containers/container-lifecycle-hooks.md

@@ -50,11 +50,10 @@ terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실
 ### 훅 핸들러 구현
 
 컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
-구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.
+구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
 
 * Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
 커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
-* TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
 * HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
 
 ### 훅 핸들러 실행

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

@@ -11,7 +11,7 @@ weight: 20
 이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
 
 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
-구성은 파드의 컨테이너를 실행하는데 사용된다.
+구성은 파드의 컨테이너를 실행하는 데 사용된다.
 
 
 
@@ -21,7 +21,7 @@ weight: 20
 ## 동기
 
 서로 다른 파드간에 런타임클래스를 설정하여
-성능대 보안의 균형을 유지할 수 있다.
+성능과 보안의 균형을 유지할 수 있다.
 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
 그러면 몇가지 추가적인 오버헤드는 있지만
@@ -106,7 +106,8 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
 
 #### dockershim
 
-쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.
+dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
+dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
 
 #### {{< glossary_tooltip term_id="containerd" >}}
 

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

@@ -2,6 +2,10 @@
 title: 쿠버네티스 확장
 weight: 110
 description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
+feature:
+  title: 확장성을 고려하여 설계됨
+  description: >
+    쿠버네티스 업스트림 소스 코드 수정 없이 쿠버네티스 클러스터에 기능을 추가할 수 있다.
 content_type: concept
 no_list: true
 ---
@@ -76,19 +80,18 @@ kubectl에서
 아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
 보여주는 다이어그램이다.
 
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
-
 <!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
 
+![익스텐션 포인트와 컨트롤 플레인](/ko/docs/concepts/extend-kubernetes/control-plane.png)
 
 ## 익스텐션 포인트
 
 이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
 
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
-
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
 
+![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png)
+
 1.   사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
 2.   apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
 3.   apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
@@ -99,11 +102,10 @@ kubectl에서
 
 어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
 
-
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
-
 <!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
 
+![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
+
 ## API 익스텐션
 ### 사용자 정의 유형
 

content/ko/docs/concepts/extend-kubernetes/extend-cluster.md

@@ -1,201 +0,0 @@
----
-title: 쿠버네티스 클러스터 확장
-content_type: concept
-weight: 10
----
-
-<!-- overview -->
-
-쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
-쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
-거의 없다.
-
-이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
-쿠버네티스 클러스터를 업무 환경의 요구에 맞게
-조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를
-대상으로 한다.
-잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는
-쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
-어떤 익스텐션 포인트와 패턴이 있는지,
-그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
-
-
-<!-- body -->
-
-## 개요
-
-사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
-
-## 구성
-
-*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
-
-* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
-* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
-* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
-* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
-
-호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
-
-[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다.
-
-## 익스텐션(Extension) {#익스텐션}
-
-익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
-이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
-
-대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
-결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
-새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
-
-## 익스텐션 패턴
-
-쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다.
-쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다.
-*자동화* 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라
-고가용성과 강력한 자동화를 작성할 수 있다.
-자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든
-쿠버네티스 클러스터에서 작동한다.
-
-쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다.
-컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음
-오브젝트의 `.status`를 업데이트 한다.
-
-컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
-원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를
-*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
-추가한다.
-
-웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
-*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
-바이너리 플러그인은 kubelet(예:
-[Flex 볼륨 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
-[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
-kubectl에서
-사용한다.
-
-아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
-보여주는 다이어그램이다.
-
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
-
-<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
-
-
-## 익스텐션 포인트
-
-이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
-
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
-
-<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
-
-1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
-2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
-3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
-4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/#스케줄러-익스텐션) 섹션에 설명되어 있다.
-5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
-6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
-7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다.
-
-어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
-
-
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
-
-<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
-
-## API 익스텐션
-### 사용자 정의 유형
-
-새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl`과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
-
-애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
-
-커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
-
-
-### 새로운 API와 자동화의 결합
-
-사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
-
-### 빌트인 리소스 변경
-
-사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
-API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
-
-
-### API 접근 익스텐션
-
-요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다.
-
-이러한 각 단계는 익스텐션 포인트를 제공한다.
-
-쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
-
-### 인증
-
-[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다.
-
-쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
-
-
-### 승인
-
-[승인](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인증 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
-
-
-### 동적 어드미션 컨트롤
-
-요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
-
-*   [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다.
-*   임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
-
-## 인프라스트럭처 익스텐션
-
-
-### 스토리지 플러그인
-
-[Flex 볼륨](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
-Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
-빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
-
-
-### 장치 플러그인
-
-장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
-통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
-발견할 수 있게 해준다.
-
-### 네트워크 플러그인
-
-노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해
-다양한 네트워킹 패브릭을 지원할 수 있다.
-
-### 스케줄러 익스텐션
-
-스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
-컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
-기본 스케줄러를 완전히 교체하거나,
-[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
-동시에 실행할 수 있다.
-
-이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할
-필요가 없다는 것을 알게 된다.
-
-스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가
-파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는
-[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을
-지원한다.
-
-
-## {{% heading "whatsnext" %}}
-
-* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
-* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기
-* 인프라스트럭처 익스텐션에 대해 더 알아보기
-  * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
-  * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
-* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기
-* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기

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

@@ -53,9 +53,9 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
 `kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
 
 유효한 레이블 값은 다음과 같다.
-* 63 자 이하 여야 하고(공백이면 안 됨),
+* 63 자 이하여야 하고 (공백일 수도 있음),
-* 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
+* (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
-* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)를 중간에 포함할 수 있다.
+* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.
 
 유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
 

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

@@ -72,7 +72,7 @@ spec:
 ## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}
 
 [붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
-표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)를 참고한다.
+표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/labels-annotations-taints/)를 참고한다.
 
 {{< note >}}
 이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.

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

@@ -206,9 +206,9 @@ tolerations:
    `Ready` 가 "`False`"로 됨에 해당한다.
  * `node.kubernetes.io/unreachable`: 노드가 노드 컨트롤러에서 도달할 수 없다. 이는
    NodeCondition `Ready` 가 "`Unknown`"로 됨에 해당한다.
- * `node.kubernetes.io/out-of-disk`: 노드에 디스크가 부족하다.
  * `node.kubernetes.io/memory-pressure`: 노드에 메모리 할당 압박이 있다.
  * `node.kubernetes.io/disk-pressure`: 노드에 디스크 할당 압박이 있다.
+ * `node.kubernetes.io/pid-pressure`: 노드에 PID 할당 압박이 있다.
  * `node.kubernetes.io/network-unavailable`: 노드의 네트워크를 사용할 수 없다.
  * `node.kubernetes.io/unschedulable`: 노드를 스케줄할 수 없다.
  * `node.cloudprovider.kubernetes.io/uninitialized`: "외부" 클라우드 공급자로
@@ -271,7 +271,7 @@ tolerations:
 
   * `node.kubernetes.io/memory-pressure`
   * `node.kubernetes.io/disk-pressure`
-  * `node.kubernetes.io/out-of-disk` (*중요한 파드에만 해당*)
+  * `node.kubernetes.io/pid-pressure` (1.14 이상)
   * `node.kubernetes.io/unschedulable` (1.10 이상)
   * `node.kubernetes.io/network-unavailable` (*호스트 네트워크만 해당*)
 

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

@@ -194,7 +194,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
 또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다.
 {{< /note >}}
 
-### 파드의 setHostnameAsFQDN 필드 {# pod-sethostnameasfqdn-field}
+### 파드의 setHostnameAsFQDN 필드 {#pod-sethostnameasfqdn-field}
 
 {{< feature-state for_k8s_version="v1.20" state="beta" >}}
 

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

@@ -935,11 +935,18 @@ Classic ELB의 연결 드레이닝은
         # 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.
 
         service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
-        # 생성된 ELB에 추가할 기존 보안 그룹 목록.
+        # 생성된 ELB에 설정할 기존 보안 그룹(security group) 목록.
-        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다.
+        # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체하며,
+        # '해당 ELB를 위한 고유 보안 그룹 생성'을 오버라이드한다.
+        # 목록의 첫 번째 보안 그룹 ID는 인바운드 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향하도록 하는 규칙으로 사용된다.
+        # 여러 ELB가 하나의 보안 그룹 ID와 연결되면, 1줄의 허가 규칙만이 워커 노드 보안 그룹에 추가된다.
+        # 즉, 만약 여러 ELB 중 하나를 지우면, 1줄의 허가 규칙이 삭제되어, 같은 보안 그룹 ID와 연결된 모든 ELB에 대한 접속이 막힌다.
+        # 적절하게 사용되지 않으면 이는 다수의 서비스가 중단되는 상황을 유발할 수 있다.
 
         service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
-        # ELB에 추가될 추가 보안 그룹(security group) 목록
+        # 생성된 ELB에 추가할 추가 보안 그룹 목록
+        # 이 방법을 사용하면 이전에 생성된 고유 보안 그룹이 그대로 유지되므로, 각 ELB가 고유 보안 그룹 ID와 그에 매칭되는 허가 규칙 라인을 소유하여
+        # 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향할 수 있도록 한다. 여기에 기재되는 보안 그룹은 여러 서비스 간 공유될 수 있다.
 
         service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
         # 로드 밸런서의 대상 노드를 선택하는 데
@@ -988,7 +995,6 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
 | 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 |
 |------|----------|---------|------------|---------------------|
 | 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
-
 | 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
 | MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
 

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

@@ -29,10 +29,9 @@ weight: 10
 쿠버네티스는 다양한 유형의 볼륨을 지원한다. {{< glossary_tooltip term_id="pod" text="파드" >}}는
 여러 볼륨 유형을 동시에 사용할 수 있다.
 임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은
-파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서
+파드의 수명을 넘어 존재한다. 파드가 더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
-실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가
-더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
 퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
+볼륨의 종류와 상관없이, 파드 내의 컨테이너가 재시작되어도 데이터는 보존된다.
 
 기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
 내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는

content/ko/docs/concepts/workloads/controllers/job.md

@@ -99,7 +99,7 @@ echo $pods
 pi-5rwd7
 ```
 
-여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output = jsonpath` 옵션은 반환된
+여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output=jsonpath` 옵션은 반환된
 목록에 있는 각 파드의 이름으로 표현식을 지정한다.
 
 파드 중 하나를 표준 출력으로 본다.

content/ko/docs/concepts/workloads/pods/disruptions.md

@@ -135,7 +135,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
 
 Eviction API를 사용하여 파드를 축출하면,
 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의
-`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다.)
+`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다.
 
 ## PodDisruptionBudget 예시 {#pdb-example}
 

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

@@ -58,7 +58,7 @@ graph TB
     class zoneA,zoneB cluster;
 {{< /mermaid >}}
 
-레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/kubernetes-api/labels-annotations-taints/)을 재사용할 수 있다.
+레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
 
 ## 파드의 분배 제약 조건
 

content/ko/docs/contribute/new-content/open-a-pr.md

@@ -123,8 +123,8 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
     ```bash
     origin	git@github.com:<github_username>/website.git (fetch)
     origin	git@github.com:<github_username>/website.git (push)
-    upstream	https://github.com/kubernetes/website (fetch)
+    upstream	https://github.com/kubernetes/website.git (fetch)
-    upstream	https://github.com/kubernetes/website (push)
+    upstream	https://github.com/kubernetes/website.git (push)
     ```
 
 6. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다.

content/ko/docs/reference/_index.md

@@ -25,7 +25,7 @@ no_list: true
 * [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
 * [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
-* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)
+* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/labels-annotations-taints/)
 
 ## 공식적으로 지원되는 클라이언트 라이브러리
 

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

@@ -5,14 +5,15 @@ weight: 50
 ---
 
 <!-- overview -->
+
 이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다.
 독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다.
 
 인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
-가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다.
+서비스 어카운트를 더 잘 설명하기 위해, 때때로 미완성 기능이 언급될 수 있다.
-
 
 <!-- body -->
+
 ## 사용자 어카운트와 서비스 어카운트 비교
 
 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
@@ -48,37 +49,51 @@ weight: 50
 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
 
- 1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다.
+1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다.
- 1. 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다.
+1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다.
- 1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다.
+1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 어느 것도 `false` 로 설정되어 있지 않다면, API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다.
- 1. 파드에 API 접근을 위한 토큰이 포함된 `volume` 을 추가한다.
+1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
- 1. `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
+1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다.
 
 #### 바인딩된 서비스 어카운트 토큰 볼륨
+
 {{< feature-state for_k8s_version="v1.21" state="beta" >}}
 
-`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
+`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, 
-시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참고한다.
+토큰 컨트롤러에 의해 생성된 무기한 서비스 어카운트 토큰을 위해, 서비스 어카운트 어드미션 컨트롤러가 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
 
-이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 `RootCAConfigMap` 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.
+```yaml
+- name: kube-api-access-<random-suffix>
+  projected:
+    defaultMode: 420 # 0644
+    sources:
+      - serviceAccountToken:
+          expirationSeconds: 3600
+          path: token
+      - configMap:
+          items:
+            - key: ca.crt
+              path: ca.crt
+          name: kube-root-ca.crt
+      - downwardAPI:
+          items:
+            - fieldRef:
+                apiVersion: v1
+                fieldPath: metadata.namespace
+              path: namespace
+```
 
-1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를
+프로젝티드 볼륨은 세 가지로 구성된다.
-   `default`로 설정한다.
-1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면
-   이를 거부한다.
-1. 파드에 `imagePullSecrets`이 없는 경우, 서비스어카운트의
-   `imagePullSecrets`이 파드에 추가된다.
-1. 서비스어카운트 `automountServiceAccountToken` 또는 파드의
-   `automountServiceAccountToken` 이 `false` 로 설정되지 않은 경우
-   파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
-1. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우,
-   `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된
-   파드의 각 컨테이너에 `volumeSource`를 추가한다.
 
-`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
+1. kube-apiserver로부터 TokenRequest API를 통해 얻은 서비스어카운트토큰(ServiceAccountToken). 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다.
-서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
+1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`이 활성화되어 있어야 동작한다. `RootCAConfigMap`은 1.20에서 기본적으로 활성화되어 있으며, 1.21 이상에서는 항상 활성화된 상태이다.
-[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한
+1. 파드의 네임스페이스를 참조하는 DownwardAPI.
-자세한 내용을 참조한다.
+
+상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다.
+
+`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우, 
+위의 프로젝티드 볼륨을 파드 스펙에 추가하여 시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.
+그러나, `RootCAConfigMap`은 활성화되어 있어야 한다.
 
 ### 토큰 컨트롤러
 

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

@@ -53,7 +53,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `APIPriorityAndFairness` | `false` | 알파 | 1.17 | 1.19 |
 | `APIPriorityAndFairness` | `true` | 베타 | 1.20 | |
 | `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 |
-| `APIResponseCompression` | `false` | 베타 | 1.16 | |
+| `APIResponseCompression` | `true` | 베타 | 1.16 | |
 | `APIServerIdentity` | `false` | 알파 | 1.20 | |
 | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | |
 | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
@@ -90,6 +90,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
 | `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
 | `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | |
+| `CSIVolumeHealth` | `false` | 알파 | 1.21 | |
 | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
 | `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
 | `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
@@ -125,14 +126,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `HPAScaleToZero` | `false` | 알파 | 1.16 | |
 | `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
 | `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
+| `IndexedJob` | `false` | 알파 | 1.21 | |
 | `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | |
 | `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
 | `IPv6DualStack` | `true` | 베타 | 1.21 | |
 | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
-| `KubeletPodResources` | `true` | 알파 | 1.13 | 1.14 |
-| `KubeletPodResources` | `true` | 베타 | 1.15 | |
 | `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
-| `LegacyNodeRoleBehavior` | `true` | True | 1.19 |  |
+| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 |  |
 | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
@@ -158,8 +158,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
 | `RunAsGroup` | `true` | 베타 | 1.14 | |
-| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
-| `SCTPSupport` | `true` | 베타 | 1.19 | |
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | |
 | `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | |
@@ -181,12 +179,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `TopologyManager` | `true` | 베타 | 1.18 | |
 | `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
 | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
+| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
 | `WarningHeaders` | `true` | 베타 | 1.19 | |
 | `WinDSR` | `false` | 알파 | 1.14 | |
 | `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
 | `WinOverlay` | `true` | 베타 | 1.20 | |
 | `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 |
-| `WindowsEndpointSliceProxying` | `true` | beta | 1.21 | |
+| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | |
 {{< /table >}}
 
 ### GA 또는 사용 중단된 기능을 위한 기능 게이트
@@ -225,7 +224,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 |
 | `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 |
 | `CSIPersistentVolume` | `true` | GA | 1.13 | - |
-| `CSIVolumeHealth` | `false` | 알파 | 1.21 | - |
 | `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
 | `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
 | `CustomPodDNS` | `true` | GA | 1.14 | - |
@@ -258,9 +256,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - |
 | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 |
-| `EndpointSlice` | `true` | 베타 | 1.18 | 1.21 |
+| `EndpointSlice` | `true` | 베타 | 1.18 | 1.20 |
 | `EndpointSlice` | `true` | GA | 1.21 | -  |
-| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.21 |
+| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 |
 | `EndpointSliceNodeName` | `true` | GA | 1.21 | - |
 | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
 | `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
@@ -278,7 +276,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
 | `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 |
 | `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | |
-| `IndexedJob` | `false` | 알파 | 1.21 | |
 | `Initializers` | `false` | 알파 | 1.7 | 1.13 |
 | `Initializers` | - | 사용중단 | 1.14 | - |
 | `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 |
@@ -315,6 +312,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 |
 | `PodShareProcessNamespace` | `true` | GA | 1.17 | - |
 | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 |
+| `RequestManagement` | - | 사용중단 | 1.17 | - |
 | `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 |
 | `ResourceLimitsPriorityFunction` | - | 사용중단 | 1.19 | - |
 | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 |
@@ -338,7 +336,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 |
 | `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - |
 | `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
-| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
+| `ServiceAppProtocol` | `true` | 베타 | 1.19 | 1.19 |
 | `ServiceAppProtocol` | `true` | GA | 1.20 | - |
 | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 |
 | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 |
@@ -350,7 +348,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
 | `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
 | `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 |
-| `StreamingProxyRedirects` | - | 사용중단| 1.19 | - |
+| `StreamingProxyRedirects` | - | GA | 1.19 | - |
 | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 |
 | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 |
@@ -376,15 +374,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 |
 | `TokenRequestProjection` | `true` | GA | 1.20 | - |
 | `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
-| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 |
-| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 |
-| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - |
 | `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 |
 | `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 |
 | `VolumePVCDataSource` | `true` | GA | 1.18 | - |
 | `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
+| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 |
+| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 |
+| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - |
 | `VolumeSubpath` | `true` | GA | 1.10 | - |
 | `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 |
 | `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 |
@@ -451,7 +449,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다.
 - `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다.
 - `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다.
-- `AffinityInAnnotations`(*사용 중단됨*): [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
+- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
   설정을 활성화한다.
 - `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다.
 - `AllowInsecureBackendProxy`: 사용자가 파드 로그 요청에서 kubelet의
@@ -477,8 +475,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   확인한다.
 - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
   [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
-- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며, 
+- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
-컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다. 
+컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
 더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
 - `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다.
   자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)
@@ -592,18 +590,18 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   hugepages 사용을 활성화한다.
 - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
   요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
-- `DynamicAuditing`(*사용 중단됨*): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
+- `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
 - `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다.
   [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다.
 - `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록
   기본 스케줄러를 확장한다.
   이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다.
-- `DynamicVolumeProvisioning`(*사용 중단됨*): 파드에 퍼시스턴트 볼륨의
+- `DynamicVolumeProvisioning`: 파드에 퍼시스턴트 볼륨의
   [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다.
 - `EfficientWatchResumption`: 스토리지에서 생성된 북마크(진행
   알림) 이벤트를 사용자에게 전달할 수 있다. 이것은 감시 작업에만
   적용된다.
-- `EnableAggregatedDiscoveryTimeout` (*사용 중단됨*): 수집된 검색 호출에서 5초
+- `EnableAggregatedDiscoveryTimeout`: 수집된 검색 호출에서 5초
   시간 초과를 활성화한다.
 - `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의
   동등성을 캐시할 수 있게 한다.
@@ -661,11 +659,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   기능을 활성화한다.
 - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
   변경할 수 없는(immutable) 것으로 표시할 수 있다.
-- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 
+- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
   완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
-- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로 
+- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
-  한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에 
+  한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
   `Scope` 와 `Namespace` 2개의 필드를 추가한다.
+- `Initializers`: Initializers 어드미션 플러그인을 사용하여 오브젝트 생성의
+  비동기 조정을 허용한다.
 - `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
   기능을 활성화한다.
 - `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
@@ -679,12 +679,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을
   참고한다.
 - `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다.
-  이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를 
+  이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를
   [자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다.
 - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
   `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여
   `node-role.kubernetes.io/master` 레이블을 무시한다.
-- `LocalStorageCapacityIsolation`: 
+- `LocalStorageCapacityIsolation`:
   [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와
   [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의
   `sizeLimit` 속성을 사용할 수 있게 한다.
@@ -695,15 +695,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)
   스토리지 사용을 모니터링하여 성능과 정확성을
   향상시킨다.
-- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여 
+- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여
   축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다.
 - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
   사용을 활성화한다.
-- `MountContainers` (*사용 중단됨*): 호스트의 유틸리티 컨테이너를 볼륨 마운터로
+- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
-  사용할 수 있다.
 - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
   자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
-- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable) 
+- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable)
   {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가)
 - `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy)	오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다.
 - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
@@ -712,12 +711,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
 - `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
   삭제되지 않도록 한다.
-- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록, 
+- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록,
    [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다.
 - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
   `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다.
 - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
-- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과 
+- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과
   [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다.
 - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
   기능을 활성화한다.
@@ -729,8 +728,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를
   공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은
   [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다.
-- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준 
+- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준
-  `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다. 
+  `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다.
   더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다.
 - `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
   컨테이너의 proc 타입의 마운트를 제어할 수 있다.
@@ -742,7 +741,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   응답에서 남은 항목 수를 표시하도록 허용한다.
 - `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고
   제거한다.
-- `ResourceLimitsPriorityFunction` (*사용 중단됨*): 입력 파드의 CPU 및 메모리 한도 중
+- `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을
+  관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다.
+- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중
   하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는
   스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진
   노드 사이의 관계를 끊는 것이다.
@@ -770,11 +771,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   JWKS URL)를 활성화한다. 자세한 내용은
   [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을
   참고한다.
-- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
+- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다.
-- `ServiceInternalTrafficPolicy`: 서비스에서 `InternalTrafficPolicy` 필드를 활성화한다.
+- `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다.
-- `ServiceLBNodePortControl`: 서비스에서`spec.allocateLoadBalancerNodePorts` 필드를
+- `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다.
-  활성화한다.
+- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은
-- `ServiceLoadBalancerClass`: 서비스에서 `LoadBalancerClass` 필드를 활성화한다. 자세한 내용은 [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다.
+  [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다.
 - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
 - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를
   제외할 수 있다. "`node.kubernetes.io/exclude-from-external-load-balancers`"로
@@ -785,7 +786,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   참고한다.
 - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
   설정하는 기능을 활성화한다.
-  [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
+  [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다.
 - `StartupProbe`: kubelet에서
   [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
   프로브를 활성화한다.
@@ -800,14 +801,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   스트리밍 요청의 예로는 `exec`, `attach` 및 `port-forward` 요청이 있다.
 - `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다.
   자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다.
-- `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다.
 - `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다.
   `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>`
   파라미터를 지정하여 지정된 수의 프로세스 ID가
   시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록
   할 수 있다.
-- `SuspendJob`: 잡 중지/재시작 기능을 활성화한다. 
+- `SupportPodPidsLimit`: 파드의 PID 제한에 대한 지원을 활성화한다.
-  자세한 내용은 [잡 문서](/ko/docs/concepts/workloads/controllers/job/)를 
+- `SuspendJob`: 잡 중지/재시작 기능을 활성화한다.
+  자세한 내용은 [잡 문서](/ko/docs/concepts/workloads/controllers/job/)를
   참고한다.
 - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널
   파라미터(sysctl)를 지원한다. 자세한 내용은
@@ -824,14 +825,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다.
 - `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해
   서비스 어카운트 토큰을 파드에 주입할 수 있다.
-- `TopologyAwareHints`: 엔드포인트슬라이스(EndpointSlices)에서 토폴로지 힌트 기반 
+- `TopologyAwareHints`: 엔드포인트슬라이스(EndpointSlices)에서 토폴로지 힌트 기반
-  토폴로지-어웨어 라우팅을 활성화한다. 자세한 내용은 
+  토폴로지-어웨어 라우팅을 활성화한다. 자세한 내용은
   [토폴로지 어웨어 힌트](/docs/concepts/services-networking/topology-aware-hints/)
   를 참고한다.
 - `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스
   할당을 조정하는 메커니즘을 활성화한다.
   [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다.
-- `VolumeCapacityPriority`: 가용 PV 용량을 기반으로 
+- `ValidateProxyRedirects`: 이 플래그는 API 서버가 동일한 호스트로만 리디렉션되는가를
+  확인해야 하는지 여부를 제어한다. `StreamingProxyRedirects`
+  플래그가 활성화된 경우에만 사용된다.
+- `VolumeCapacityPriority`: 가용 PV 용량을 기반으로
   여러 토폴로지에 있는 노드들의 우선순위를 정하는 기능을 활성화한다.
 - `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다.
 - `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고
@@ -839,6 +843,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   `PersistentLocalVolumes` 기능 게이트와 함께 사용될 때
   [`local`](/ko/docs/concepts/storage/volumes/#local) 볼륨 유형을 사용할 수 있다.
 - `VolumeSnapshotDataSource`: 볼륨 스냅샷 데이터 소스 지원을 활성화한다.
+- `VolumeSubpath`: 컨테이너에 볼륨의 하위 경로(subpath)를 마운트할 수 있다.
 - `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해
   `subPathExpr` 필드를 활성화한다.
 - `WarningHeaders`: API 응답에서 경고 헤더를 보낼 수 있다.

content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md

@@ -265,7 +265,7 @@ nginx-app    1/1     1            1           2m
 ```
 
 ```shell
-kubectl get po -l run=nginx-app
+kubectl get po -l app=nginx-app
 ```
 ```
 NAME                         READY     STATUS    RESTARTS   AGE
@@ -279,7 +279,7 @@ deployment "nginx-app" deleted
 ```
 
 ```shell
-kubectl get po -l run=nginx-app
+kubectl get po -l app=nginx-app
 # 아무것도 반환하지 않는다
 ```
 

content/ko/docs/reference/using-api/client-libraries.md

@@ -28,12 +28,12 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 
 | 언어      | 클라이언트 라이브러리 | 예제 프로그램 |
 |----------|----------------|-----------------|
-| Go       | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples)
-| Python       | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples)
-| Java     | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation)
 | dotnet   | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple)
-| JavaScript   | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples)
+| Go       | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples)
 | Haskell  | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example)
+| Java     | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation)
+| JavaScript   | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples)
+| Python   | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples)
 
 
 ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리
@@ -46,6 +46,10 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 | 언어                  | 클라이언트 라이브러리                          |
 | -------------------- | ---------------------------------------- |
 | Clojure              | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) |
+| DotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
+| DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
+| Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
+| Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |
 | Go                   | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) |
 | Java (OSGi)          | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) |
 | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) |
@@ -68,13 +72,10 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
 | Python               | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) |
 | Ruby                 | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
 | Ruby                 | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
+| Ruby                 | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) |
 | Ruby                 | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
 | Rust                 | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) |
 | Rust                 | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) |
 | Scala                | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) |
 | Scala                | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) |
-| DotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
 | Swift                | [github.com/swiftkube/client](https://github.com/swiftkube/client) |
-| DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
-| Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
-| Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) |

content/ko/docs/setup/production-environment/tools/kops.md

@@ -57,10 +57,10 @@ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://
 $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
 ```
 
-예를 들어 kops 버전을 v1.15.0을 다운로드 하려면 다음을 입력한다.
+예를 들어 kops 버전을 v1.20.0을 다운로드 하려면 다음을 입력한다.
 
 ```shell
-curl -LO  https://github.com/kubernetes/kops/releases/download/1.15.0/kops-darwin-amd64
+curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64
 ```
 
 kops 바이너리를 실행 가능하게 만든다.
@@ -94,10 +94,10 @@ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://
 ```shell
 $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
 ```
-예를 들어 kops 버전을 v1.15.0을 다운로드 하려면 다음을 입력한다.
+예를 들어 kops 버전을 v1.20.0을 다운로드 하려면 다음을 입력한다.
 
 ```shell
-curl -LO  https://github.com/kubernetes/kops/releases/download/1.15.0/kops-linux-amd64
+curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64
 ```
 
 kops 바이너리를 실행 가능하게 만든다.

content/ko/docs/setup/production-environment/tools/kubespray.md

@@ -50,7 +50,7 @@ Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은
 
 ### (2/5) 인벤토리 파일 구성하기
 
-서버들을 프로비저닝 한 후, [Ansible의 인벤토리 파일](https://docs.ansible.com/ansible/intro_inventory.html)을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " [나만의 인벤토리 만들기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)" 글을 확인하자.
+서버들을 프로비저닝 한 후, [Ansible의 인벤토리 파일](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html)을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " [나만의 인벤토리 만들기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)" 글을 확인하자.
 
 ### (3/5) 클러스터 디플로이먼트 계획하기