Merge branch 'main' into fix-link

config.toml

@@ -123,6 +123,7 @@ id = "UA-00000000-0"
 [params]
 copyright_k8s = "The Kubernetes Authors"
 copyright_linux =  "Copyright © 2020 The Linux Foundation ®."
+
 # privacy_policy = "https://policies.google.com/privacy"
 
 # First one is picked as the Twitter card image if not set on page.

content/de/_index.html

@@ -42,12 +42,12 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Video ansehen</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Besuche die KubeCon - 13-16 August 2020 in Amsterdam</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Besuche die KubeCon North America vom 11. bis 15. Oktober 2021</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Besuche die KubeCon - 17-20 November 2020 in Boston</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Besuche die KubeCon Europe vom 17. bis 20. Mai 2022</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/en/blog/_posts/2021-10-18-kpng-specialized-proxiers.md

@@ -0,0 +1,241 @@
+---
+layout: blog
+title: "Use KPNG to Write Specialized kube-proxiers"
+date: 2021-10-18
+slug: use-kpng-to-write-specialized-kube-proxiers
+---
+
+**Author**: Lars Ekman (Ericsson)
+
+The post will show you how to create a specialized service kube-proxy
+style network proxier using Kubernetes Proxy NG
+[kpng](https://github.com/kubernetes-sigs/kpng) without interfering
+with the existing kube-proxy. The kpng project aims at renewing the
+the default Kubernetes Service implementation, the "kube-proxy". An
+important feature of kpng is that it can be used as a library to
+create proxiers outside K8s. While this is useful for CNI-plugins that
+replaces the kube-proxy it also opens the possibility for anyone to
+create a proxier for a special purpose.
+
+
+## Define a service that uses a specialized proxier
+
+```
+apiVersion: v1
+kind: Service
+metadata:
+  name: kpng-example
+  labels:
+    service.kubernetes.io/service-proxy-name: kpng-example
+spec:
+  clusterIP: None
+  ipFamilyPolicy: RequireDualStack
+  externalIPs:
+  - 10.0.0.55
+  - 1000::55
+  selector:
+    app: kpng-alpine
+  ports:
+  - port: 6000
+```
+
+If the `service.kubernetes.io/service-proxy-name` label is defined the
+`kube-proxy` will ignore the service. A custom controller can watch
+services with the label set to it's own name, "kpng-example" in
+this example, and setup specialized load-balancing.
+
+The `service.kubernetes.io/service-proxy-name` label is [not
+new](https://kubernetes.io/docs/reference/labels-annotations-taints/#servicekubernetesioservice-proxy-name),
+but so far is has been quite hard to write a specialized proxier.
+
+The common use for a specialized proxier is assumed to be handling
+external traffic for some use-case not supported by K8s. In that
+case `ClusterIP` is not needed, so we use a "headless" service in this
+example.
+
+
+## Specialized proxier using kpng
+
+A [kpng](https://github.com/kubernetes-sigs/kpng) based proxier
+consists of the `kpng` controller handling all the K8s api related
+functions, and a "backend" implementing the load-balancing. The
+backend can be linked with the `kpng` controller binary or be a
+separate program communicating with the controller using gRPC.
+
+```
+kpng kube --service-proxy-name=kpng-example to-api
+```
+
+This starts the `kpng` controller and tell it to watch only services
+with the "kpng-example" service proxy name. The "to-api" parameter
+will open a gRPC server for backends.
+
+You can test this yourself outside your cluster. Please see the example
+below.
+
+Now we start a backend that simply prints the updates from the
+controller.
+
+```
+$ kubectl apply -f kpng-example.yaml
+$ kpng-json | jq     # (this is the backend)
+{
+  "Service": {
+    "Namespace": "default",
+    "Name": "kpng-example",
+    "Type": "ClusterIP",
+    "IPs": {
+      "ClusterIPs": {},
+      "ExternalIPs": {
+        "V4": [
+          "10.0.0.55"
+        ],
+        "V6": [
+          "1000::55"
+        ]
+      },
+      "Headless": true
+    },
+    "Ports": [
+      {
+        "Protocol": 1,
+        "Port": 6000,
+        "TargetPort": 6000
+      }
+    ]
+  },
+  "Endpoints": [
+    {
+      "IPs": {
+        "V6": [
+          "1100::202"
+        ]
+      },
+      "Local": true
+    },
+    {
+      "IPs": {
+        "V4": [
+          "11.0.2.2"
+        ]
+      },
+      "Local": true
+    },
+    {
+      "IPs": {
+        "V4": [
+          "11.0.1.2"
+        ]
+      }
+    },
+    {
+      "IPs": {
+        "V6": [
+          "1100::102"
+        ]
+      }
+    }
+  ]
+}
+```
+
+A real backend would use some mechanism to load-balance traffic from
+the external IPs to the endpoints.
+
+
+
+## Writing a backend
+
+The `kpng-json` backend looks like this:
+
+```go
+package main
+import (
+        "os"
+        "encoding/json"
+        "sigs.k8s.io/kpng/client"
+)
+func main() {
+        client.Run(jsonPrint)
+}
+func jsonPrint(items []*client.ServiceEndpoints) {
+        enc := json.NewEncoder(os.Stdout)
+        for _, item := range items {
+                _ = enc.Encode(item)
+        }
+}
+```
+
+(yes, that is the entire program)
+
+A real backend would of course be much more complex, but this
+illustrates how `kpng` let you focus on load-balancing.
+
+You can have several backends connected to a `kpng` controller, so
+during development or debug it can be useful to let something like the
+`kpng-json` backend run in parallel with your real backend.
+
+
+## Example
+
+
+The complete example can be found [here](https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec).
+
+As an example we implement an "all-ip" backend. It direct all traffic
+for the externalIPs to a local endpoint, regardless of ports and upper
+layer protocols. There is a
+[KEP](https://github.com/kubernetes/enhancements/pull/2611) for this
+function and this example is a much simplified version.
+
+To direct all traffic from an external address to a local POD [only
+one iptables rule is
+needed](https://github.com/kubernetes/enhancements/pull/2611#issuecomment-895061013),
+for instance;
+
+```
+ip6tables -t nat -A PREROUTING -d 1000::55/128 -j DNAT --to-destination 1100::202
+```
+
+As you can see the addresses are in the call to the backend and all it
+have to do is:
+
+* Extract the addresses with `Local: true`
+* Setup iptables rules for the `ExternalIPs`
+
+A script doing that may look like:
+
+```
+xip=$(cat /tmp/out | jq -r .Service.IPs.ExternalIPs.V6[0])
+podip=$(cat /tmp/out | jq -r '.Endpoints[]|select(.Local == true)|select(.IPs.V6 != null)|.IPs.V6[0]')
+ip6tables -t nat -A PREROUTING -d $xip/128 -j DNAT --to-destination $podip
+```
+
+Assuming the JSON output above is stored in `/tmp/out` ([jq](https://stedolan.github.io/jq/) is an *awesome* program!).
+
+
+As this is an example we make it really simple for ourselves by using
+a minor variation of the `kpng-json` backend above. Instead of just
+printing, a program is called and the JSON output is passed as `stdin`
+to that program. The backend can be tested stand-alone:
+
+```
+CALLOUT=jq kpng-callout
+```
+
+Where `jq` can be replaced with your own program or script. A script
+may look like the example above.  For more info and the complete
+example please see [https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec](https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec).
+
+
+## Summary
+
+While [kpng](https://github.com/kubernetes-sigs/kpng) is in early
+stage of development this post wants to show how you may build your
+own specialized K8s proxiers in the future. The only thing your
+applications need to do is to add the
+`service.kubernetes.io/service-proxy-name` label in the Service
+manifest.
+
+It is a tedious process to get new features into the `kube-proxy` and
+it is not unlikely that they will be rejected, so to write a
+specialized proxier may be the only option.

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

@@ -145,7 +145,7 @@ Coil operates with a low overhead compared to bare metal, and allows you to defi
 
 ### Contiv
 
-[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.
+[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan,  classic l2, or Cisco-SDN/ACI) for various use cases.
 
 ### Contrail / Tungsten Fabric
 
@@ -260,12 +260,6 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p
 
 [NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
 
-### Nuage Networks VCS (Virtualized Cloud Services)
-
-[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
-
-The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
-
 ### OpenVSwitch
 
 [OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also

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

@@ -10,8 +10,7 @@ weight: 30
 
 <!-- overview -->
 
-Kubernetes supports multiple virtual clusters backed by the same physical cluster.
+In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
-These virtual clusters are called namespaces.
 
 <!-- body -->
 

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

@@ -1072,6 +1072,9 @@ in those modified security groups.
 
 {{< /note >}}
 
+Further documentation on annotations for Elastic IPs and other common use-cases may be found
+in the [AWS Load Balancer Controller documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/).
+
 #### Other CLB annotations on Tencent Kubernetes Engine (TKE)
 
 There are other annotations for managing Cloud Load Balancers on TKE as shown below.

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

@@ -146,7 +146,7 @@ features:
   parameters.
 - Typical operations on volumes are supported assuming that the driver
   supports them, including
-  ([snapshotting](/docs/concepts/storage/volume-snapshots/),
+  [snapshotting](/docs/concepts/storage/volume-snapshots/),
   [cloning](/docs/concepts/storage/volume-pvc-datasource/),
   [resizing](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims),
   and [storage capacity tracking](/docs/concepts/storage/storage-capacity/).

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

@@ -48,6 +48,21 @@ with shared namespaces and shared filesystem volumes.
 
 ## Using Pods
 
+The following is an example of a Pod which consists of a container running the image `nginx:1.14.2`.
+
+{{< codenew file="pods/simple-pod.yaml" >}}
+
+To create the Pod shown above, run the following command:
+```shell
+kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
+```
+
+Pods are generally not created directly and are created using workload resources.
+See [Working with Pods](#working-with-pods) for more information on how Pods are used
+with workload resources.
+
+### Workload resources for managing pods
+
 Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
 term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
 If your Pods need to track state, consider the

content/en/docs/contribute/_index.md

@@ -29,6 +29,8 @@ Kubernetes documentation contributors:
 - Translate the documentation
 - Manage and publish the documentation parts of the Kubernetes release cycle
 
+
+
 <!-- body -->
 
 ## Getting started
@@ -44,18 +46,98 @@ to work effectively in the Kubernetes community.
 To get involved with documentation:
 
 1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
-1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
+2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
    and the website's [static site generator](https://gohugo.io).
-1. Make sure you understand the basic processes for
+3. Make sure you understand the basic processes for
    [opening a pull request](/docs/contribute/new-content/open-a-pr/) and
    [reviewing changes](/docs/contribute/review/reviewing-prs/).
 
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
+
+{{< mermaid >}}
+flowchart TB
+subgraph third[Open PR]
+direction TB
+U[ ] -.-
+Q[Improve content] --- N[Create content]
+N --- O[Translate docs]
+O --- P[Manage/publish docs parts<br>of K8s release cycle]
+
+end
+
+subgraph second[Review]
+direction TB
+   T[ ] -.-
+   D[Look over the<br>K8s/website<br>repository] --- E[Check out the<br>Hugo static site<br>generator]
+   E --- F[Understand basic<br>GitHub commands]
+   F --- G[Review open PR<br>and change review <br>processes]
+end
+
+subgraph first[Sign up]
+    direction TB
+    S[ ] -.-
+    B[Sign the CNCF<br>Contributor<br>License Agreement] --- C[Join sig-docs<br>Slack channel] 
+    C --- V[Join kubernetes-sig-docs<br>mailing list]
+    V --- M[Attend weekly<br>sig-docs calls<br>or slack meetings]
+end
+
+A([fa:fa-user New<br>Contributor]) --> first
+A --> second
+A --> third
+A --> H[Ask Questions!!!]
+
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
+class S,T,U spacewhite
+class first,second,third white
+{{</ mermaid >}}
+***Figure - Getting started for a new contributor***
+
+The figure above outlines a roadmap for new contributors. You can follow some or all of the steps for `Sign up` and `Review`. Now you are ready to open PRs that achieve your contribution objectives with some listed under `Open PR`. Again, questions are always welcome!
+
 Some tasks require more trust and more access in the Kubernetes organization.
 See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
 roles and permissions.
 
 ## Your first contribution
 
+You can prepare for your first contribution by reviewing several steps beforehand. The figure below outlines the steps and the details follow. 
+
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
+
+{{< mermaid >}}
+flowchart LR
+    subgraph second[First Contribution]
+    direction TB
+    S[ ] -.-
+    G[Review PRs from other<br>K8s members] -->
+    A[Check K8s/website<br>issues list for<br>good first PRs] --> B[Open a PR!!]
+    end
+    subgraph first[Suggested Prep]
+    direction TB
+       T[ ] -.-
+       D[Read contribution overview] -->E[Read K8s content<br>and style guides]
+       E --> F[Learn about Hugo page<br>content types<br>and shortcodes]
+    end
+    
+
+    first ----> second
+     
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,D,E,F,G grey
+class S,T spacewhite
+class first,second white
+{{</ mermaid >}}
+***Figure - Preparation for your first contribution***
+
 - Read the [Contribution overview](/docs/contribute/new-content/overview/) to
   learn about the different ways you can contribute.
 - Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/)
@@ -92,10 +174,12 @@ SIG Docs communicates with different methods:
   introduce yourself!
 - [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
   where broader discussions take place and official decisions are recorded.
-- Join the [weekly SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs). Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
+- Join the [SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs) held every two weeks. Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
+- Join the SIG Docs async Slack standup meeting on those weeks when the in-person Zoom video meeting does not take place. Meetings are always announced on `#sig-docs`. You can contribute to any one of the threads up to 24 hours after meeting announcement. 
 
 ## Other ways to contribute
 
 - Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more.
 - Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
 - Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
+

content/en/docs/contribute/new-content/_index.md

@@ -5,10 +5,48 @@ main_menu: true
 weight: 20
 ---
 
+
+
 <!-- overview -->
 
-This section contains information you should know before contributing new content.
+This section contains information you should know before contributing new
+content. 
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 
+{{< mermaid >}}
+flowchart LR 
+    subgraph second[Before you begin]
+    direction TB
+    S[ ] -.-
+    A[Sign the CNCF CLA] --> B[Choose Git branch]
+    B --> C[One language per PR]
+    C --> F[Check out<br>contributor tools]
+    end
+    subgraph first[Contributing Basics]
+    direction TB
+       T[ ] -.-
+       D[Write docs in markdown<br>and build site with Hugo] --- E[source in GitHub]
+       E --- G[_'/content/../docs'_ folder contains docs<br>for multiple languages]
+       G --- H[Review Hugo page content<br>types and shortcodes]
+    end
+    
+
+    first ----> second
+     
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,C,D,E,F,G,H grey
+class S,T spacewhite
+class first,second white
+{{</ mermaid >}}
+
+***Figure - Contributing new content preparation***
+
+The figure above depicts the information you should know
+prior to submitting new content. The information details follow.
 
 
 
@@ -16,28 +54,43 @@ This section contains information you should know before contributing new conten
 
 ## Contributing basics
 
-- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
+- Write Kubernetes documentation in Markdown and build the Kubernetes site
-- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
+  using [Hugo](https://gohugo.io/).
-- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
+- The source is in [GitHub](https://github.com/kubernetes/website). You can find
+  Kubernetes documentation at `/content/en/docs/`. Some of the reference
+  documentation is automatically generated from scripts in
+  the `update-imported-docs/` directory.
+- [Page content types](/docs/contribute/style/page-content-types/) describe the
+  presentation of documentation content in Hugo.
 - In addition to the standard Hugo shortcodes, we use a number of
-  [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
+  [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our
+  documentation to control the presentation of content.
 - Documentation source is available in multiple languages in `/content/`. Each
   language has its own folder with a two-letter code determined by the
-  [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For
+  [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php)
-  example, English documentation source is stored in `/content/en/docs/`.
+  . For example, English documentation source is stored in `/content/en/docs/`.
-- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
+- For more information about contributing to documentation in multiple languages
+  or starting a new translation,
+  see [localization](/docs/contribute/localization).
 
 ## Before you begin {#before-you-begin}
 
 ### Sign the CNCF CLA {#sign-the-cla}
 
-All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
+All Kubernetes contributors **must** read
+the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)
+and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md)
+.
 
-Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
+Pull requests from contributors who haven't signed the CLA fail the automated
+tests. The name and email you provide must match those found in
+your `git config`, and your git name and email must match those used for the
+CNCF CLA.
 
 ### Choose which Git branch to use
 
-When opening a pull request, you need to know in advance which branch to base your work on.
+When opening a pull request, you need to know in advance which branch to base
+your work on.
 
 Scenario | Branch
 :---------|:------------
@@ -45,20 +98,21 @@ Existing or new English language content for the current release | `main`
 Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
 Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
 
-
 If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
 
-{{< note >}}
+{{< note >}} If you already submitted your pull request and you know that the
-If you already submitted your pull request and you know that the base branch
+base branch was wrong, you (and only you, the submitter) can change it. {{<
-was wrong, you (and only you, the submitter) can change it.
+/note >}}
-{{< /note >}}
 
 ### Languages per PR
 
-Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
+Limit pull requests to one language per PR. If you need to make an identical
+change to the same code sample in multiple languages, open a separate PR for
+each language.
 
 ## Tools for contributors
 
-The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
+The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools)
-
+directory in the `kubernetes/website` repository contains tools to help your
+contribution journey go more smoothly.
 

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

@@ -28,7 +28,40 @@ If your changes are large, read [Work from a local fork](#fork-the-repo) to lear
 ## Changes using GitHub
 
 If you're less experienced with git workflows, here's an easier method of
-opening a pull request.
+opening a pull request. The figure below outlines the steps and the details follow.
+
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
+
+{{< mermaid >}}
+flowchart LR
+A([fa:fa-user New<br>Contributor]) --- id1[(K8s/Website<br>GitHub)]
+subgraph tasks[Changes using GitHub]
+direction TB
+    0[ ] -.-
+    1[1. Edit this page] --> 2[2. Use GitHub markdown<br>editor to make changes]
+    2 --> 3[3. fill in Propose file change]
+
+end
+subgraph tasks2[ ]
+direction TB
+4[4. select Propose file change] --> 5[5. select Create pull request] --> 6[6. fill in Open a pull request]
+6 --> 7[7. select Create pull request] 
+end
+
+id1 --> tasks --> tasks2
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,1,2,3,4,5,6,7 grey
+class 0 spacewhite
+class tasks,tasks2 white
+class id1 k8s
+{{</ mermaid >}}
+
+***Figure - Steps for opening a PR using GitHub***
 
 1.  On the page where you see the issue, select the pencil icon at the top right.
     You can also scroll to the bottom of the page and select **Edit this page**.
@@ -89,6 +122,37 @@ work from a local fork.
 
 Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
 
+The figure below shows the steps to follow when you work from a local fork. The details for each step follow.
+
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
+
+{{< mermaid >}}
+flowchart LR
+1[Fork the K8s/website<br>repository] --> 2[Create local clone<br>and set upstream]
+subgraph changes[Your changes]
+direction TB
+S[ ] -.-
+3[Create a branch<br>example: my_new_branch] --> 3a[Make changes using<br>text editor] --> 4["Preview your changes<br>locally using Hugo<br>(localhost:1313)<br>or build container image"]
+end
+subgraph changes2[Commit / Push]
+direction TB
+T[ ] -.-
+5[Commit your changes] --> 6[Push commit to<br>origin/my_new_branch]
+end
+
+2 --> changes --> changes2
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class 1,2,3,3a,4,5,6 grey
+class S,T spacewhite
+class changes,changes2 white
+{{</ mermaid >}}
+***Figure - Working from a local fork to make your changes***
+
 ### Fork the kubernetes/website repository
 
 1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
@@ -289,6 +353,34 @@ Alternately, install and use the `hugo` command on your computer:
 
 ### Open a pull request from your fork to kubernetes/website {#open-a-pr}
 
+The figure below shows the steps to open a PR from your fork to the K8s/website. The details follow.
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
+
+{{< mermaid >}}
+flowchart LR
+subgraph first[ ]
+direction TB
+1[1. Go to K8s/website repository] --> 2[2. Select New Pull Request]
+2 --> 3[3. Select compare across forks]
+3 --> 4[4. Select your fork from<br>head repository drop-down menu]
+end
+subgraph second [ ]
+direction TB
+5[5. Select your branch from<br>the compare drop-down menu] --> 6[6. Select Create Pull Request]
+6 --> 7[7. Add a description<br>to your PR]
+7 --> 8[8. Select Create pull request]
+end
+
+first --> second
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+class 1,2,3,4,5,6,7,8 grey
+class first,second white
+{{</ mermaid >}}
+***Figure - Steps to open a PR from your fork to the K8s/website***
+
 1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
 2. Select **New Pull Request**.
 3. Select **compare across forks**.
@@ -303,7 +395,7 @@ Alternately, install and use the `hugo` command on your computer:
 
 8. Select the **Create pull request** button.
 
-  Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
+Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
 
 
 After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
@@ -414,7 +506,6 @@ If another contributor commits changes to the same file in another PR, it can cr
 
     The pull request no longer shows any conflicts.
 
-
 ### Squashing commits
 
 {{< note >}}
@@ -500,11 +591,8 @@ Most repositories use issue and PR templates. Have a look through some open
 issues and PRs to get a feel for that team's processes. Make sure to fill out
 the templates with as much detail as possible when you file issues or PRs.
 
-
-
 ## {{% heading "whatsnext" %}}
 
 
 - Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process.
 
-

content/en/docs/contribute/review/reviewing-prs.md

@@ -36,7 +36,38 @@ Before you start a review:
 
 ## Review process
 
-In general, review pull requests for content and style in English.
+In general, review pull requests for content and style in English. The figure below outlines the steps for the review process. The details for each step follow.
+
+<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
+<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
+
+{{< mermaid >}}
+flowchart LR
+    subgraph fourth[Start review]
+    direction TB
+    S[ ] -.-
+    M[add comments] --> N[review changes]
+    N --> O[new contributors should<br>choose Comment]
+    end
+    subgraph third[Select PR]
+    direction TB
+    T[ ] -.-
+    J[read description<br>and comments]--> K[preview changes in<br>Netlify preview build]
+    end
+ 
+  A[Review open PR list]--> B[Filter open PRs<br>by label]
+  B --> third --> fourth
+     
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,J,K,M,N,O grey
+class S,T spacewhite
+class third,fourth white
+{{</ mermaid >}}
+
+***Figure - Review process steps***
 
 1.  Go to
     [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).

content/en/docs/reference/access-authn-authz/authorization.md

@@ -134,6 +134,21 @@ The output is similar to this:
 no
 ```
 
+Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
+can list Pods in the Namespace `target`:
+
+```bash
+kubectl auth can-i list pods \
+	--namespace target \
+	--as system:serviceaccount:dev:dev-sa
+```
+
+The output is similar to this:
+
+```
+yes
+```
+
 `SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
 exposes the API server authorization to external services. Other resources in
 this group include:

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

@@ -125,7 +125,6 @@ different Kubernetes components.
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
 | `IndexedJob` | `false` | Alpha | 1.21 | 1.21 |
 | `IndexedJob` | `true` | Beta | 1.22 | |
-| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
 | `IngressClassNamespacedParams` | `false` | Alpha | 1.21 | 1.21 |
 | `IngressClassNamespacedParams` | `true` | Beta | 1.22 | |
 | `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | |
@@ -138,13 +137,13 @@ different Kubernetes components.
 | `IPv6DualStack` | `true` | Beta | 1.21 | |
 | `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
 | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | |
+| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
+| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
 | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
 | `LogarithmicScaleDown` | `false` | Alpha | 1.21 | 1.21 |
 | `LogarithmicScaleDown` | `true` | Beta | 1.22 | |
-| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
-| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
 | `MemoryManager` | `false` | Alpha | 1.21 | 1.21 |
 | `MemoryManager` | `true` | Beta | 1.22 | |
 | `MemoryQoS` | `false` | Alpha | 1.22 | |
@@ -289,9 +288,6 @@ different Kubernetes components.
 | `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
 | `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
 | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
-| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
-| `DynamicKubeletConfig` | `true` | Beta | 1.11 | 1.21 |
-| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
 | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
 | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
 | `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |

content/en/docs/reference/glossary/namespace.md

@@ -10,9 +10,9 @@ aka:
 tags:
 - fundamental
 ---
- An abstraction used by Kubernetes to support multiple virtual clusters on the same physical {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
+ An abstraction used by Kubernetes to support isolation of groups of resources within a single {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
 
 <!--more--> 
 
-Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces.
+Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
 

content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md

@@ -127,7 +127,7 @@ If your configuration is not using the latest version it is **recommended** that
 the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
 
 For more information on the fields and usage of the configuration you can navigate to our
-[API reference page](/docs/reference/config-api/kubeadm-config.v1beta2/).
+[API reference page](/docs/reference/config-api/kubeadm-config.v1beta3/).
 
 ### Adding kube-proxy parameters {#kube-proxy}
 

content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md

@@ -287,7 +287,7 @@ If your configuration is not using the latest version it is **recommended** that
 the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
 
 For more information on the fields and usage of the configuration you can navigate to our
-[API reference](/docs/reference/config-api/kubeadm-config.v1beta2/).
+[API reference](/docs/reference/config-api/kubeadm-config.v1beta3/).
 
 ## {{% heading "whatsnext" %}}
 

content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md

@@ -15,7 +15,7 @@ behind one command, with support for both planning an upgrade and actually perfo
 
 ## kubeadm upgrade guidance
 
-The steps for performing a upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
+The steps for performing an upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
 For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website.
 
 You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests.

content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md

@@ -93,6 +93,10 @@ kind: JoinConfiguration
 discovery:
   bootstrapToken:
     apiServerEndpoint: 10.100.0.1:6443
+    token: "clvldh.vjjwg16ucnhp94qr"
+    caCertHashes:
+    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
+    # change auth info above to match the actual token and CA certificate hash for your cluster
 nodeRegistration:
   kubeletExtraArgs:
     node-ip: 10.100.0.3,fd00:1:2:3::3
@@ -109,6 +113,10 @@ controlPlane:
 discovery:
   bootstrapToken:
     apiServerEndpoint: 10.100.0.1:6443
+    token: "clvldh.vjjwg16ucnhp94qr"
+    caCertHashes:
+    - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
+    # change auth info above to match the actual token and CA certificate hash for your cluster
 nodeRegistration:
   kubeletExtraArgs:
     node-ip: 10.100.0.4,fd00:1:2:3::4
@@ -118,7 +126,7 @@ nodeRegistration:
 `advertiseAddress` in JoinConfiguration.controlPlane specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm join`.
 
 ```shell
-kubeadm join --config=kubeadm-config.yaml ...
+kubeadm join --config=kubeadm-config.yaml
 ```
 
 ### Create a single-stack cluster
@@ -150,4 +158,4 @@ networking:
 
 * [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
 * Read about [Dual-stack](/docs/concepts/services-networking/dual-stack/) cluster networking
-* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta2/)
+* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta3/)

content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md

@@ -262,7 +262,7 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
   When using DigitalOcean, it can be the public one (assigned to `eth0`) or
   the private one (assigned to `eth1`) should you want to use the optional
   private network. The `kubeletExtraArgs` section of the kubeadm
-  [`NodeRegistrationOptions` structure](/docs/reference/config-api/kubeadm-config.v1beta2/#kubeadm-k8s-io-v1beta2-NodeRegistrationOptions)
+  [`NodeRegistrationOptions` structure](/docs/reference/config-api/kubeadm-config.v1beta3/#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions)
   can be used for this.
 
   Then restart `kubelet`:
@@ -336,7 +336,7 @@ Alternatively, you can try separating the `key=value` pairs like so:
 `--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
 but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
 
-A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta2/).
+A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/).
 
 ## kube-proxy scheduled before node is initialized by cloud-controller-manager
 

content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md

@@ -325,6 +325,10 @@ Here is an example:
 ```shell
 ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb
 ```
+Another example for restoring using etcdutl options:
+```shell
+ETCDCTL_API=3 etcdutl --data-dir <data-dir-location> snapshot restore snapshotdb
+```
 
 For more information and examples on restoring a cluster from a snapshot file, see
 [etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster).

content/en/docs/tasks/administer-cluster/kubelet-in-userns.md

@@ -27,8 +27,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo
 * [Enable systemd with user session](https://rootlesscontaine.rs/getting-started/common/login/)
 * [Configure several sysctl values, depending on host Linux distribution](https://rootlesscontaine.rs/getting-started/common/sysctl/)
 * [Ensure that your unprivileged user is listed in `/etc/subuid` and `/etc/subgid`](https://rootlesscontaine.rs/getting-started/common/subuid/)
-
+* Enable the `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-* `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 
 <!-- steps -->
 
@@ -86,9 +85,10 @@ Rootless Docker/Podman or LXC/LXD, you are all set, and you can go to the next s
 Otherwise you have to create a user namespace by yourself, by calling `unshare(2)` with `CLONE_NEWUSER`.
 
 A user namespace can be also unshared by using command line tools such as:
+
+- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
 - [RootlessKit](https://github.com/rootless-containers/rootlesskit)
 - [become-root](https://github.com/giuseppe/become-root)
-- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
 
 After unsharing the user namespace, you will also have to unshare other namespaces such as mount namespace.
 
@@ -123,29 +123,37 @@ On your node, systemd must already be configured to allow delegation; for more d
 Containers documentation.
 
 ### Configuring network
+
 {{% thirdparty-content %}}
 
 The network namespace of the Node components has to have a non-loopback interface, which can be for example configured with
-slirp4netns, VPNKit, or lxc-user-nic.
+[slirp4netns](https://github.com/rootless-containers/slirp4netns),
+[VPNKit](https://github.com/moby/vpnkit), or
+[lxc-user-nic(1)](https://www.man7.org/linux/man-pages/man1/lxc-user-nic.1.html).
 
 The network namespaces of the Pods can be configured with regular CNI plugins.
 For multi-node networking, Flannel (VXLAN, 8472/UDP) is known to work.
 
 Ports such as the kubelet port (10250/TCP) and `NodePort` service ports have to be exposed from the Node network namespace to
-the host with an external port forwarder, such as RootlessKit, slirp4netns, or socat.
+the host with an external port forwarder, such as RootlessKit, slirp4netns, or
+[socat(1)](https://linux.die.net/man/1/socat).
 
-You can use the port forwarder from K3s; see https://github.com/k3s-io/k3s/blob/v1.21.2+k3s1/pkg/rootlessports/controller.go
+You can use the port forwarder from K3s.
+See [Running K3s in Rootless Mode](https://rancher.com/docs/k3s/latest/en/advanced/#known-issues-with-rootless-mode)
+for more details.
 
 ### Configuring CRI
 
-The kubelet relies on a container runtime. You should deploy a container runtime such as containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
+The kubelet relies on a container runtime. You should deploy a container runtime such as
+containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
 
 {{< tabs name="cri" >}}
 {{% tab name="containerd" %}}
 
 Running CRI plugin of containerd in a user namespace is supported since containerd 1.4.
 
-Running containerd within a user namespace requires the following configuration:
+Running containerd within a user namespace requires the following configurations
+in `/etc/containerd/containerd-config.toml`.
 
 ```toml
 version = 2
@@ -175,7 +183,7 @@ Running CRI-O in a user namespace is supported since CRI-O 1.22.
 
 CRI-O requires an environment variable `_CRIO_ROOTLESS=1` to be set.
 
-The following configuration is also recommended:
+The following configurations (in `/etc/crio/crio.conf`) are also recommended:
 
 ```toml
 [crio]
@@ -197,8 +205,8 @@ The following configuration is also recommended:
 Running kubelet in a user namespace requires the following configuration:
 
 ```yaml
-kind: KubeletConfiguration
 apiVersion: kubelet.config.k8s.io/v1beta1
+kind: KubeletConfiguration
 featureGates:
   KubeletInUserNamespace: true
 # We use cgroupfs that is delegated by systemd, so we do not use "systemd" driver
@@ -206,22 +214,23 @@ featureGates:
 cgroupDriver: "cgroupfs"
 ```
 
-When the `KubeletInUserNamespace` feature gate is enabled, kubelet ignores errors that may happen during setting the following sysctl values:
+When the `KubeletInUserNamespace` feature gate is enabled, the kubelet ignores errors
+that may happen during setting the following sysctl values on the node.
+
 - `vm.overcommit_memory`
 - `vm.panic_on_oom`
 - `kernel.panic`
 - `kernel.panic_on_oops`
 - `kernel.keys.root_maxkeys`
 - `kernel.keys.root_maxbytes`.
-   (these are sysctl values for the host, not for the containers).
 
 Within a user namespace, the kubelet also ignores any error raised from trying to open `/dev/kmsg`.
 This feature gate also allows kube-proxy to ignore an error during setting `RLIMIT_NOFILE`.
 
 The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status.
 
-Running kubelet in a user namespace without using this feature gate is also possible by mounting a specially crafted proc filesystem,
+Running kubelet in a user namespace without using this feature gate is also possible
-but not officially supported.
+by mounting a specially crafted proc filesystem, but not officially supported.
 
 ### Configuring kube-proxy
 
@@ -251,9 +260,11 @@ For more on this, see the [Caveats and Future work](https://rootlesscontaine.rs/
 on the rootlesscontaine.rs website.
 
 ## {{% heading "seealso" %}}
+
 - [rootlesscontaine.rs](https://rootlesscontaine.rs/)
 - [Rootless Containers 2020 (KubeCon NA 2020)](https://www.slideshare.net/AkihiroSuda/kubecon-na-2020-containerd-rootless-containers-2020)
 - [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootless/)
 - [Usernetes](https://github.com/rootless-containers/usernetes)
 - [Running K3s with rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
 - [KEP-2033: Kubelet-in-UserNS (aka Rootless mode)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless)
+

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

@@ -258,7 +258,7 @@ In the example below the Pod did not get the credspec correctly:
 ```PowerShell
 kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
 ```
-nltest.exe /parentdomain` results in the following error:
+`nltest.exe /parentdomain` results in the following error:
 ```
 Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
 ```

content/en/training/_index.html

@@ -14,6 +14,9 @@ class: training
         <h2>Build your cloud native career</h2>
         <p>Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.</p>
       </div>
+      <div class="logo-certification cta-image" id="logo-kcnf">
+        <img src="/images/training/kubernetes-kcnf-white.svg" />
+      </div>
       <div class="logo-certification cta-image" id="logo-cka">
         <img src="/images/training/kubernetes-cka-white.svg"/>
       </div>
@@ -81,6 +84,15 @@ class: training
   <div class="main-section padded">
     <h2>Get Kubernetes Certified</h2>
     <div class="col-container">
+      <div class="col-nav">
+        <h5>
+          <b>Kubernetes and Cloud Native Associate (KCNA)</b>
+        </h5>
+        <p>The Kubernetes and Cloud Native Associate (KCNA) exam demonstrates a user’s foundational knowledge and skills in Kubernetes and the wider cloud native ecosystem.</p>
+        <p>A certified KCNA will confirm conceptual knowledge of the entire cloud native ecosystem, particularly focusing on Kubernetes.</p>
+        <br>
+        <a href="https://training.linuxfoundation.org/certification/kubernetes-cloud-native-associate/" target="_blank" class="button">Go to Certification</a>
+      </div>
       <div class="col-nav">
           <h5>
             <b>Certified Kubernetes Application Developer (CKAD)</b>

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

@@ -329,6 +329,9 @@ spec:
         ephemeral-storage: "2Gi"
       limits:
         ephemeral-storage: "4Gi"
+    volumeMounts:
+      - name: ephemeral
+        mountPath: "/tmp"
   - name: log-aggregator
     image: images.my-company.example/log-aggregator:v6
     resources:
@@ -336,6 +339,12 @@ spec:
         ephemeral-storage: "2Gi"
       limits:
         ephemeral-storage: "4Gi"
+    volumeMounts:
+      - name: ephemeral
+        mountPath: "/tmp"
+  volumes:
+    - name: ephemeral
+      emptyDir: {}
 ```
 
 ### Como son programados los Pods con solicitudes de almacenamiento efímero

content/es/docs/reference/glossary/wg.md

@@ -0,0 +1,19 @@
+---
+title: WG (working group)
+id: wg
+date: 2018-04-12
+full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list
+short_description: >
+  Facilita la discusión y/o la implementación de un proyecto que sea efímero, corto o desacoplado para un comité, {{< glossary_tooltip text="SIG" term_id="sig" >}}, o esfuerzo SIG cruzado.
+
+aka: 
+tags:
+- community
+---
+ Facilita la discusión y/o la implementación de un proyecto que sea efímero, corto o desacoplado para un comité, {{< glossary_tooltip text="SIG" term_id="sig" >}}, o un esfuerzo entre varios SIGs.
+
+<!--more-->
+
+Los grupos de trabajo son una forma de organizar personas para completar una tarea discreta.
+
+Para más información, consulta el repositorio [kubernetes/community](https://github.com/kubernetes/community) y la lista de los [SIGs y Grupos de Trabajo (WGs).](https://github.com/kubernetes/community/blob/master/sig-list.md).

content/es/docs/reference/glossary/workload.md

@@ -0,0 +1,22 @@
+---
+title: Workload
+id: workloads
+date: 2019-02-13
+full_link: /docs/concepts/workloads/
+short_description: >
+   Un Workload es una aplicación que se ejecuta en Kubernetes.
+
+aka: 
+tags:
+- fundamental
+---
+   Un Workload es una aplicación que se ejecuta en Kubernetes.
+
+<!--more--> 
+
+Varios objetos clave que representan diferentes tipos o partes de un Workload
+incluyen los objetos: DaemonSet, Deployment, Job, ReplicaSet y StatefulSet.
+
+Por ejemplo, un Workload que tiene un servidor web y una base de datos podría ejecutar
+la base de datos en un {{< glossary_tooltip term_id="StatefulSet" >}} y el servidor
+web en un {{< glossary_tooltip term_id="Deployment" >}}.

content/ja/docs/concepts/services-networking/ingress.md

@@ -18,7 +18,7 @@ weight: 40
 * ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
 * クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードの集合です。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはインターネットに公開されていません。
 * エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。クラウドプロバイダーが管理するゲートウェイや、物理的なハードウェアの一部である場合もあります。
-* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
+* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
 * Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodの集合を特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に指定がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つものとして扱われます。
 
 ## Ingressとは何か
@@ -66,7 +66,7 @@ Ingressリソースの最小構成の例は以下のとおりです。
 
 {{< codenew file="service/networking/minimal-ingress.yaml" >}}
 
-他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
+他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
 
 Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
 
@@ -346,7 +346,7 @@ IngressでこのSecretを参照すると、クライアントとロードバラ
 
 Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
 
-Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
+Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
 
 ## Ingressの更新
 
@@ -451,4 +451,4 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
 ## {{% heading "whatsnext" %}}
 * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
 * [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
-* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube/)
+* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/ja/docs/tasks/access-application-cluster/ingress-minikube/)

content/ja/docs/reference/access-authn-authz/authentication.md

@@ -63,7 +63,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app
 
 これにより、"app1"と"app2"の2つのグループに属するユーザー名"jbeda"の証明書署名要求が作成されます。
 
-クライアント証明書の生成方法については、[証明書の管理](/docs/concepts/cluster-administration/certificates/)を参照してください。
+クライアント証明書の生成方法については、[証明書の管理](/ja/docs/concepts/cluster-administration/certificates/)を参照してください。
 
 ### 静的なトークンファイル
 
@@ -314,7 +314,7 @@ Webhook認証は、Bearerトークンを検証するためのフックです。
 * `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです
 * `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です
 
-設定ファイルは、[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。
+設定ファイルは、[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。
 ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。
 
 ```yaml
@@ -347,7 +347,7 @@ contexts:
 
 クライアントが[上記](#putting-a-bearer-token-in-a-request)のようにBearerトークンを使用してAPIサーバーとの認証を試みた場合、認証Webhookはトークンを含むJSONでシリアライズされた`authentication.k8s.io/v1beta1` `TokenReview`オブジェクトをリモートサービスにPOSTします。Kubernetesはそのようなヘッダーが不足しているリクエストを作成しようとはしません。
 
-Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。
+Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/ja/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。
 
 POSTボディは、以下の形式になります。
 
@@ -600,7 +600,7 @@ rules:
 
 ### 設定
 
-クレデンシャルプラグインの設定は、userフィールドの一部として[kubectlの設定ファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)で行います。
+クレデンシャルプラグインの設定は、userフィールドの一部として[kubectlの設定ファイル](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)で行います。
 
 ```yaml
 apiVersion: v1

content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md

@@ -146,7 +146,7 @@ Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実
 1. wins、kubelet、kubeadmをインストールします。
 
    ```PowerShell
-   curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+   curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
    .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
    ```
 

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

@@ -73,7 +73,7 @@ NodeLocal DNSキャッシュは、クラスターノード上でDNSキャッシ
   * kube-proxyがIPVSモードで稼働中のとき:
 
     ``` 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
     ```
      このモードでは、node-local-dns Podは`<node-local-address>`上のみで待ち受けます。node-local-dnsのインターフェースはkube-dnsのクラスターIPをバインドしません。なぜならばIPVSロードバランシング用に使われているインターフェースは既にこのアドレスを使用しているためです。
      `__PILLAR__UPSTREAM__SERVERS__` はnode-local-dns Podにより生成されます。

content/ja/docs/tutorials/stateless-application/guestbook.md

@@ -79,7 +79,7 @@ POD-NAMEの部分を実際のPodの名前に書き換えてください。
 
 ### RedisのマスターのServiceを作成する
 
-ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
+ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/ja/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
 
 {{< codenew file="application/guestbook/redis-master-service.yaml" >}}
 
@@ -199,7 +199,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
 
 ### フロントエンドのServiceを作成する
 
-適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
+適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/ja/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
 
 もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。
 
@@ -363,8 +363,8 @@ DeploymentとServiceを削除すると、実行中のPodも削除されます。
 
 ## {{% heading "whatsnext" %}}
 
-* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
+* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
 * [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる
-* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
+* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
 * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む
-* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
+* [リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む

content/ko/community/_index.html

@@ -12,8 +12,8 @@ cid: community
 
 <div class="intro">
 <br class="mobile">
-<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화로 구성된 쿠버네티스 커뮤니티는 이 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장 하고 변화함에 따라 우리의 문화와 가치관이 계속 성장하고 변화하고 있습니다. 우리 모두는 프로젝트의 지속적인 개선과 작업 방식을 위해 함께 노력합니다.
+<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는 본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장하고 변화함에 따라 우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다. 우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다.
-<br><br>우리는 이슈를 제기하고 풀 리퀘스트하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고 채택과 혁신을 옹호하며, <code>kubectl get pods</code> 을 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 여러분이 어떻게 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
+<br><br>우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고, 도입(adoption)과 혁신(innovation)을 지지하며, <code>kubectl get pods</code> 를 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
 <br class="mobile">
 </div>
 

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

@@ -392,6 +392,49 @@ Message:        Node is shutting, evicting pods
 이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
 {{< /note >}}
 
+## 스왑(swap) 메모리 관리 {#swap-memory}
+
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+
+쿠버네티스 1.22 이전에는 노드가 스왑 메모리를 지원하지 않았다. 그리고 
+kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 실패하도록 되어 있었다.
+1.22부터는 스왑 메모리 지원을 노드 단위로 활성화할 수 있다.
+
+노드에서 스왑을 활성화하려면, `NodeSwap` 기능 게이트가 kubelet에서
+활성화되어야 하며, 명령줄 플래그 `--fail-swap-on` 또는
+[구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가
+false로 지정되어야 한다.
+
+사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 
+이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,
+
+```yaml
+memorySwap:
+  swapBehavior: LimitedSwap
+```
+
+`swapBehavior`에 가용한 구성 옵션은 다음과 같다.
+
+- `LimitedSwap`: 쿠버네티스 워크로드는 스왑을 사용할 수 있는 만큼으로
+  제한된다. 쿠버네티스에 의해 관리되지 않는 노드의 워크로드는 여전히 스왑될 수 있다.
+- `UnlimitedSwap`: 쿠버네티스 워크로드는 요청한 만큼 스왑 메모리를 사용할 수 있으며,
+  시스템의 최대치까지 사용 가능하다.
+
+만약 `memorySwap` 구성이 명시되지 않았고 기능 게이트가 활성화되어 있다면, 
+kubelet은 `LimitedSwap` 설정과 같은 행동을
+기본적으로 적용한다.
+
+`LimitedSwap` 설정에 대한 행동은 노드가 ("cgroups"으로 알려진)
+제어 그룹이 v1 또는 v2 중에서 무엇으로 동작하는가에 따라서 결정된다. 
+
+- **cgroupsv1:** 쿠버네티스 워크로드는 메모리와 스왑의 조합을 사용할 수 있다.
+  파드의 메모리 제한이 설정되어 있다면 가용 상한이 된다.
+- **cgroupsv2:** 쿠버네티스 워크로드는 스왑 메모리를 사용할 수 없다.
+
+테스트를 지원하고 피드벡을 제공하기 위한 정보는
+[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 및
+[디자인 제안](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)에서 찾을 수 있다.
+
 ## {{% heading "whatsnext" %}}
 
 * 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.

content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -6,6 +6,18 @@ weight: 70
 
 <!-- overview -->
 
+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
 가비지 수집은 사용되지 않는 
 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 
 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 

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

@@ -80,7 +80,7 @@ kubectl logs counter
 로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
 
 예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
-[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
+[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해
 자세히 알 수 있다.
 
 **CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.

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

@@ -160,7 +160,7 @@ persistentvolumeclaim/my-pvc created
 
 지금까지 사용한 예는 모든 리소스에 최대 한 개의 레이블만 적용하는 것이었다. 세트를 서로 구별하기 위해 여러 레이블을 사용해야 하는 많은 시나리오가 있다.
 
-예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
+예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
 
 ```yaml
      labels:

content/ko/docs/concepts/configuration/overview.md

@@ -21,7 +21,7 @@ weight: 10
 
 - JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
 
-- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
+- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
 
 - 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
 
@@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
 
 ## 레이블 사용하기
 
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
 
 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
 

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

@@ -12,26 +12,33 @@ weight: 30
 
 <!-- overview -->
 
-쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
-민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이
-{{< glossary_tooltip term_id="pod" >}} 정의나
-{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
-내에 그대로 두는 것보다 안전하고 유연하다.
-자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
-
 시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
-포함하는 오브젝트이다. 그렇지 않으면  이러한 정보가 파드
+포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}}
-명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
+명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
-일부 시크릿을 만들 수 있다.
+포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를
+애플리케이션 코드에 넣을 필요가
+없음을 뜻한다.
+
+시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에,
+파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이
+노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스
+및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성
+저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.
+
+시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만
+특별히 기밀 데이터를 보관하기 위한 것이다.
 
 {{< caution >}}
-쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
+쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
-기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
+또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. 
-액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
+
-시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
+시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
 
 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
-2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
+2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
+   활성화 또는 구성.
+3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
+
 {{< /caution >}}
 
 <!-- body -->
@@ -47,6 +54,10 @@ weight: 30
 - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
 
+쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어,
+[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은
+노드 등록을 자동화하는 데 도움을 주는 메커니즘이다.
+
 시크릿 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
@@ -1236,7 +1247,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
    API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
    시크릿을 노출하는 파드를 실행할 수 있다.
 
-
 ## {{% heading "whatsnext" %}}
 
 - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기

content/ko/docs/concepts/containers/container-environment.md

@@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
 FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
 ```
 
-서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
+서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
 
 
 

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 이미지
 content_type: concept
 weight: 10
@@ -16,9 +19,6 @@ weight: 10
 
 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
 
-
-
-
 <!-- body -->
 
 ## 이미지 이름
@@ -210,10 +210,6 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
 
 ### 미리 내려받은 이미지
 
-{{< note >}}
-Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
-{{< /note >}}
-
 {{< note >}}
 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
 클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
@@ -334,4 +330,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
 
 ## {{% heading "whatsnext" %}}
 
-* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기
+* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
+* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 런타임클래스(RuntimeClass)
 content_type: concept
 weight: 20
@@ -115,7 +118,7 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
 유효한 핸들러는 runtimes 단락 아래에서 설정한다.
 
 ```
-[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
 ```
 
 더 자세한 containerd의 구성 문서를 살펴본다.

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

@@ -197,31 +197,39 @@ service PodResourcesLister {
 }
 ```
 
-`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
+`List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
-이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께
+독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
-실행 중인 파드의 리소스에 대한 정보를 제공한다.
+이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
 
 ```gRPC
-// ListPodResourcesResponse는 List 함수가 반환하는 응답이다
+// ListPodResourcesResponse는 List 함수가 반환하는 응답이다.
 message ListPodResourcesResponse {
     repeated PodResources pod_resources = 1;
 }
 
-// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다
+// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다.
 message PodResources {
     string name = 1;
     string namespace = 2;
     repeated ContainerResources containers = 3;
 }
 
-// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다
+// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다.
 message ContainerResources {
     string name = 1;
     repeated ContainerDevices devices = 2;
     repeated int64 cpu_ids = 3;
+    repeated ContainerMemory memory = 4;
 }
 
-// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다
+// ContainerMemory는 컨테이너에 할당된 메모리와 hugepage에 대한 정보를 포함한다.
+message ContainerMemory {
+    string memory_type = 1;
+    uint64 size = 2;
+    TopologyInfo topology = 3;
+}
+
+// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다.
 message TopologyInfo {
         repeated NUMANode nodes = 1;
 }
@@ -231,7 +239,7 @@ message NUMANode {
         int64 ID = 1;
 }
 
-// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다
+// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다.
 message ContainerDevices {
     string resource_name = 1;
     repeated string device_ids = 2;
@@ -247,6 +255,7 @@ kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다
 message AllocatableResourcesResponse {
     repeated ContainerDevices devices = 1;
     repeated int64 cpu_ids = 2;
+    repeated ContainerMemory memory = 3;
 }
 
 ```

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

@@ -45,7 +45,7 @@ sitemap:
 * 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
 * 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
 * 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
-* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
+* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
 * 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
 * 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
 * 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.

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

@@ -30,6 +30,11 @@ weight: 50
 }
 ```
 
+{{<note>}}
+맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자,
+불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다.
+{{</note>}}
+
 다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
 
 * 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은

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

@@ -42,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
    * `"partition" : "customerA"`, `"partition" : "customerB"`
    * `"track" : "daily"`, `"track" : "weekly"`
 
-이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
+이 예시는 [일반적으로 사용하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
 
 ## 구문과 캐릭터 셋
 
@@ -50,15 +50,13 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
 
 접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
 
-`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
+`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
 
 유효한 레이블 값은 다음과 같다.
 * 63 자 이하여야 하고 (공백일 수도 있음),
 * (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
 * 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.
 
-유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
-
 다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
 
 ```yaml

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 오브젝트 이름과 ID
 content_type: concept
 weight: 20
@@ -25,7 +28,7 @@ weight: 20
 물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
 {{< /note >}}
 
-다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
+다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.
 
 ### DNS 서브도메인 이름
 
@@ -38,7 +41,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 - 영숫자로 시작한다.
 - 영숫자로 끝난다.
 
-### DNS 레이블 이름
+### RFC 1123 레이블 이름 {#dns-label-names}
 
 일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에
 정의된 대로 DNS 레이블 표준을 따라야 한다.
@@ -49,6 +52,17 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 - 영숫자로 시작한다.
 - 영숫자로 끝난다.
 
+### RFC 1035 레이블 이름
+
+몇몇 리소스 타입은 자신의 이름을 [RFC 1035](https://tools.ietf.org/html/rfc1035)에
+정의된 DNS 레이블 표준을 따르도록 요구한다.
+이것은 이름이 다음을 만족해야 한다는 의미이다.
+
+- 최대 63개 문자를 포함
+- 소문자 영숫자 또는 '-'만 포함
+- 알파벳 문자로 시작
+- 영숫자로 끝남
+
 ### 경로 세그먼트 이름
 
 일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수

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

@@ -442,7 +442,7 @@ pods        0     10
 
 ### 네임스페이스 간 파드 어피니티 쿼터
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
 제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
@@ -493,9 +493,9 @@ plugins:
 해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
 파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
 
-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
 
 ## 요청과 제한의 비교 {#requests-vs-limits}
 

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

@@ -271,16 +271,16 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
 연관된 `matchExpressions` 가 모두 충족되어야 한다.
 
 #### 네임스페이스 셀렉터
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
 어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다.
 빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과
 null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다.
 
-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
 
 #### 더 실용적인 유스케이스
 

content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
-* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
+* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기

content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 파드 우선순위(priority)와 선점(preemption)
 content_type: concept
 weight: 70
@@ -350,21 +353,25 @@ spec:
 `PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를
 축출 대상으로 고려한다.
 
-QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
+kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/) 순서를 결정한다.
-[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
+사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
-kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
+예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
-파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
+
-먼저 축출 대상 파드의 순위를 매긴다.
+  1. 부족한 리소스 사용량이 요청을 초과하는지 여부
-더 자세한 내용은
+  1. 파드 우선순위
-[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
+  1. 요청 대비 리소스 사용량
+
+더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
 참조한다.
 
-kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
+kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
 파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을
 초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가
 더 높은 다른 파드가 축출될 수 있다.
 
-
 ## {{% heading "whatsnext" %}}
 
-* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
+* 프라이어리티클래스와 함께 리소스쿼터 사용에 대해 읽기: [기본으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)
+* [파드 중단(disruption)](/ko/docs/concepts/workloads/pods/disruptions/)에 대해 학습한다.
+* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)에 대해 학습한다.
+* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 학습한다.

content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 마치 100을 설정한 것처럼 작동한다.
 
 값을 변경하려면,
-[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
+[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을
 편집한 다음 스케줄러를 재시작한다.
 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
 
@@ -161,4 +161,4 @@ percentageOfNodesToScore: 50
 
 ## {{% heading "whatsnext" %}}
 
-* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인
+* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인

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

@@ -264,10 +264,10 @@ tolerations:
 
 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
 
-## 컨디션을 기준으로 노드 테인트하기
+## 조건(condition)을 기준으로 노드 테인트하기
 
 컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여 
-[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
+[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
 
 스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. 
 이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
@@ -298,5 +298,5 @@ tolerations:
 
 ## {{% heading "whatsnext" %}}
 
-* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
+* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기
 * [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기

content/ko/docs/concepts/security/overview.md

@@ -1,17 +1,21 @@
 ---
+
+
 title: 클라우드 네이티브 보안 개요
+description: >
+  클라우드 네이티브 보안 관점에서 쿠버네티스 보안을 생각해보기 위한 모델
 content_type: concept
-weight: 10
+weight: 1
 ---
 
 <!-- overview -->
+
 이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다.
 
 {{< warning >}}
 이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다.
 {{< /warning >}}
 
-
 <!-- body -->
 
 ## 클라우드 네이티브 보안의 4C
@@ -83,7 +87,6 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
 * 설정 가능한 클러스터 컴포넌트의 보안
 * 클러스터에서 실행되는 애플리케이션의 보안
 
-
 ### 클러스터의 컴포넌트 {#cluster-components}
 
 우발적이거나 악의적인 접근으로부터 클러스터를 보호하고,

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

@@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외
 
 쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
 지원한다. 전자는 기본적으로 작동하지만 후자는
-[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
+[CoreDNS 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다.
 {{< note >}}
 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
 처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서
@@ -227,7 +227,7 @@ Address 1: 10.0.162.149
 * 인증서를 사용하도록 구성된 nginx 서버
 * 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/ko/docs/concepts/configuration/secret/)
 
-[nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
+[nginx https 예제](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
 
 ```shell
 make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
@@ -299,7 +299,7 @@ nginxsecret           kubernetes.io/tls                     2         1m
 nginx-secure-app의 매니페스트에 대한 주목할만한 점:
 
 - 이것은 동일한 파일에 디플로이먼트와 서비스의 사양을 모두 포함하고 있다.
-- [nginx 서버](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
+- [nginx 서버](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)
   는 포트 80에서 HTTP 트래픽을 443에서 HTTPS 트래픽 서비스를 제공하고, nginx 서비스는
   두 포트를 모두 노출한다.
 - 각 컨테이너는 `/etc/nginx/ssl` 에 마운트된 볼륨을 통해 키에 접근할 수 있다.

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

@@ -197,7 +197,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
 
 ### 파드의 setHostnameAsFQDN 필드 {#pod-sethostnameasfqdn-field}
 
-{{< feature-state for_k8s_version="v1.20" state="beta" >}}
+{{< feature-state for_k8s_version="v1.22" state="stable" >}}
 
 파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.
 
@@ -313,6 +313,28 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
 options ndots:5
 ```
 
+#### 확장된 DNS 환경 설정
+
+{{< feature-state for_k8s_version="1.22" state="alpha" >}}
+
+쿠버네티스는 파드의 DNS 환경 설정을 위해 기본적으로 최대 6개의 탐색 도메인과 
+최대 256자의 탐색 도메인 목록을 허용한다.
+
+kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화되어 있으면, 
+쿠버네티스는 최대 32개의 탐색 도메인과 
+최대 2048자의 탐색 도메인 목록을 허용한다.
+
+### 기능 가용성
+
+파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
+
+| 쿠버네티스 버전 | 기능 지원 |
+| :---------: |:-----------:|
+| 1.14 | 안정 |
+| 1.10 | 베타 (기본값으로 켜져 있음)|
+| 1.9 | 알파 |
+
+
 ## {{% heading "whatsnext" %}}
 
 

content/ko/docs/concepts/services-networking/ingress-controllers.md

@@ -32,6 +32,7 @@ weight: 40
   Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
 * [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
+* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
 * F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
   이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
 * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의

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

@@ -1,4 +1,6 @@
 ---
+
+
 title: 인그레스(Ingress)
 content_type: concept
 weight: 40
@@ -222,7 +224,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
 
 #### 네임스페이스 범위의 파라미터
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 `Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
 사용할 수 있는 `scope` 및 `namespace` 필드가 있다.

content/ko/docs/concepts/services-networking/network-policies.md

@@ -223,7 +223,7 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex
 
 ## 포트 범위 지정
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.
 
@@ -251,17 +251,25 @@ spec:
       endPort: 32768
 ```
 
-위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
+위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 
+네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 
+TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
 
 이 필드를 사용할 때 다음의 제한 사항이 적용된다.
-* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+* 베타 기능으로, 기본적으로 활성화되어 있다. 
+클러스터 수준에서 `endPort` 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가 
+API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 이용하여 
+`NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
 * `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
 * `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
 * 두 포트 모두 숫자여야 한다.
 
 {{< note >}}
-클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
+클러스터가 네트워크폴리시 명세의 `endPort` 필드를 지원하는
-네트워크폴리시 명세에서 `endPort` 필드를 지원한다.
+{{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
+만약 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)이 
+`endPort` 필드를 지원하지 않는데 네트워크폴리시의 해당 필드에 명시를 하면, 
+그 정책은 `port` 필드에만 적용될 것이다.
 {{< /note >}}
 
 ## 이름으로 네임스페이스 지정

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

@@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
 마찬가지로, 서비스 정의를 API 서버에 `POST`하여
 새 인스턴스를 생성할 수 있다.
 서비스 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names)이어야 한다.
 
 예를 들어, 각각 TCP 포트 9376에서 수신하고
 `app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
@@ -188,9 +188,10 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
 
 ### 초과 용량 엔드포인트
-엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
+엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상)
-클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
+클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: truncated` 어노테이션을 추가한다.
-이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
+이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며
+엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
 
 ### 엔드포인트슬라이스
 
@@ -384,6 +385,40 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
 유효하지 않은 clusterIP 주소 값으로 서비스를 생성하려고 하면, API 서버는
 422 HTTP 상태 코드를 리턴하여 문제점이 있음을 알린다.
 
+## 트래픽 정책
+
+### 외부 트래픽 정책
+
+`spec.externalTrafficPolicy` 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
+이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, 
+`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 
+엔드포인트가 하나도 없는 경우, kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다.
+
+{{< note >}}
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+kube-proxy에 대해 `ProxyTerminatingEndpoints` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 
+활성화하면, kube-proxy는 노드에 로컬 엔드포인트가 있는지, 
+그리고 모든 로컬 엔드포인트가 "종료 중(terminating)"으로 표시되어 있는지 여부를 확인한다.
+만약 로컬 엔드포인트가 존재하는데 **모두**가 종료 중이면, kube-proxy는 `Local`로 설정된 모든 외부 트래픽 정책을 무시한다. 
+대신, 모든 노드-로컬 엔드포인트가 "종료 중" 상태를 유지하는 동안, 
+kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 것처럼 
+그 서비스에 대한 트래픽을 정상 상태의 다른 엔드포인트로 포워드한다.
+이러한 종료 중인 엔드포인트에 대한 포워딩 정책은 `NodePort` 서비스로 트래픽을 로드밸런싱하던 외부 로드밸런서가 
+헬스 체크 노드 포트가 작동하지 않을 때에도 연결들을 비돌발적으로(gracefully) 종료시킬 수 있도록 하기 위해 존재한다.
+이러한 정책이 없다면, 노드가 여전히 로드밸런서 노드 풀에 있지만 
+파드 종료 과정에서 트래픽이 제거(drop)되는 상황에서 트래픽이 유실될 수 있다.
+{{< /note >}}
+
+### 내부 트래픽 정책
+
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+
+`spec.internalTrafficPolicy` 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
+이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, 
+`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 
+엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 포워드하지 않는다.
+
 ## 서비스 디스커버리하기
 
 쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
@@ -394,7 +429,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
 파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
 환경 변수 세트를 추가한다. [도커 링크
 호환](https://docs.docker.com/userguide/dockerlinks/) 변수
-([makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와
+([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와
 보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
 
@@ -523,6 +558,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 [kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
 동등한 `nodePortAddresses` 필드를
 특정 IP 블록으로 설정할 수 있다.
+
 이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
 
 예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
@@ -641,12 +677,12 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정
 
 #### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
-v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에
+`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
-대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다.
+기본적으로, `spec.loadBalancerClass` 는 `nil` 이고, 
-기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는
+클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면 
-클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
+`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
 `spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
 구현이 서비스를 감시하고 있다고 가정한다.
 모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
@@ -656,7 +692,6 @@ v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer`
 `spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는
 "`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
 접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
-이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다.
 
 #### 내부 로드 밸런서
 

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

@@ -314,12 +314,9 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
 * [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
 * [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
 * [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
-* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
-  (**사용 중단**)
 * [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI)
 * [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지
 * [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
-* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
 * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
 * [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
 * [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
@@ -329,17 +326,28 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
 * [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
   로컬 스토리지 디바이스
 * [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지
-* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
-  (이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
-  작동하지 않는다.)
 * [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
-* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
 * [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 볼륨
-* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
-  (**사용 중단**)
-* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
 * [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨
 
+아래의 PersistentVolume 타입은 사용 중단되었다. 이 말인 즉슨, 지원은 여전히 제공되지만 추후 쿠버네티스 릴리스에서는 삭제될 예정이라는 것이다.
+
+* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
+  (v1.18에서 **사용 중단**)
+* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
+  (v1.22에서 **사용 중단**)
+* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
+  (v1.22에서 **사용 중단**)
+* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
+  (v1.22에서 **사용 중단**)
+
+이전 쿠버네티스 버전은 아래의 인-트리 PersistentVolume 타입도 지원했었다.
+
+* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
+  (v1.15 이후 **사용 불가**)
+* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
+  (v1.21 이후 **사용 불가**)
+
 ## 퍼시스턴트 볼륨
 
 각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다.
@@ -407,38 +415,40 @@ spec:
 * ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
 * ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다
 * ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
+* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다.
+  쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다.
 
 CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
 
 * RWO - ReadWriteOnce
 * ROX - ReadOnlyMany
 * RWX - ReadWriteMany
+* RWOP - ReadWriteOncePod
 
 > __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다.
 
 
-| Volume Plugin        | ReadWriteOnce          | ReadOnlyMany          | ReadWriteMany|
+| Volume Plugin        | ReadWriteOnce          | ReadOnlyMany          | ReadWriteMany | ReadWriteOncePod       |
-| :---                 | :---:                  | :---:                 | :---:        |
+| :---                 | :---:                  | :---:                 | :---:         | -                      |
-| AWSElasticBlockStore | ✓               | -                     | -            |
+| AWSElasticBlockStore | ✓               | -                     | -             | -                      |
-| AzureFile            | ✓               | ✓              | ✓     |
+| AzureFile            | ✓               | ✓              | ✓      | -                      |
-| AzureDisk            | ✓               | -                     | -            |
+| AzureDisk            | ✓               | -                     | -             | -                      |
-| CephFS               | ✓               | ✓              | ✓     |
+| CephFS               | ✓               | ✓              | ✓      | -                      |
-| Cinder               | ✓               | -                     | -            |
+| Cinder               | ✓               | -                     | -             | -                      |
-| CSI                  | 드라이버에 따라 다름    | 드라이버에 따라 다름    | 드라이버에 따라 다름 |
+| CSI                  | depends on the driver  | depends on the driver | depends on the driver | depends on the driver |
-| FC                   | ✓               | ✓              | -            |
+| FC                   | ✓               | ✓              | -             | -                      |
-| FlexVolume           | ✓               | ✓              | 드라이버에 따라 다름 |
+| FlexVolume           | ✓               | ✓              | depends on the driver | -              |
-| Flocker              | ✓               | -                     | -            |
+| Flocker              | ✓               | -                     | -             | -                      |
-| GCEPersistentDisk    | ✓               | ✓              | -            |
+| GCEPersistentDisk    | ✓               | ✓              | -             | -                      |
-| Glusterfs            | ✓               | ✓              | ✓     |
+| Glusterfs            | ✓               | ✓              | ✓      | -                      |
-| HostPath             | ✓               | -                     | -            |
+| HostPath             | ✓               | -                     | -             | -                      |
-| iSCSI                | ✓               | ✓              | -            |
+| iSCSI                | ✓               | ✓              | -             | -                      |
-| Quobyte              | ✓               | ✓              | ✓     |
+| Quobyte              | ✓               | ✓              | ✓      | -                      |
-| NFS                  | ✓               | ✓              | ✓     |
+| NFS                  | ✓               | ✓              | ✓      | -                      |
-| RBD                  | ✓               | ✓              | -            |
+| RBD                  | ✓               | ✓              | -             | -                      |
-| VsphereVolume        | ✓               | -                     | - (파드가 병치될(collocated) 때 작동)  |
+| VsphereVolume        | ✓               | -                     | - (works when Pods are collocated) | - |
-| PortworxVolume       | ✓               | -                     | ✓     |
+| PortworxVolume       | ✓               | -                     | ✓      | -                  | - |
-| ScaleIO              | ✓               | ✓              | -            |
+| StorageOS            | ✓               | -                     | -             | -                      |
-| StorageOS            | ✓               | -                     | -            |
 
 ### 클래스
 
@@ -785,6 +795,82 @@ spec:
       storage: 10Gi
 ```
 
+## 볼륨 파퓰레이터(Volume populator)와 데이터 소스
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다. 
+이 알파 기능은 쿠버네티스 1.18에서 도입되었으며 
+1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다.
+현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번 
+확인한다. {{% version-check %}}
+커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해 
+`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+{{< /note >}}
+
+볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다. 
+다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는 
+`dataSource` 필드와는 다르게, `dataSourceRef` 필드는 동일 네임스페이스에 있는 
+어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외). 
+기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다.
+
+## 데이터 소스 참조
+
+`dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다. 
+둘 중 하나만 명시되어 있으면, API 서버는 두 필드에 같은 값을 할당할 것이다. 
+두 필드 모두 생성 이후에는 변경될 수 없으며, 
+두 필드에 다른 값을 넣으려고 시도하면 검증 에러가 발생할 것이다. 
+따라서 두 필드는 항상 같은 값을 갖게 된다.
+
+`dataSourceRef` 필드와 `dataSource` 필드 사이에는 
+사용자가 알고 있어야 할 두 가지 차이점이 있다.
+* `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만, 
+  `dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다. 
+  유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다.
+* `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는 
+  PVC와 VolumeSnapshot만 포함할 수 있다.
+
+기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은 
+클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야 
+할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만 
+존재하는 것이다. 상세히 설명하면, 이전 버전과 새로운 버전의 컨트롤러가 함께 동작할 
+수 있는데, 이는 두 필드가 동일하기 때문이다.
+
+### 볼륨 파퓰레이터 사용하기
+
+볼륨 파퓰레이터는 비어 있지 않은 볼륨(non-empty volume)을 생성할 수 있는 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}이며, 
+이 볼륨의 내용물은 커스텀 리소스(Custom Resource)에 의해 결정된다.
+파퓰레이티드 볼륨(populated volume)을 생성하려면 `dataSourceRef` 필드에 커스텀 리소스를 기재한다.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: populated-pvc
+spec:
+  dataSourceRef:
+    name: example-name
+    kind: ExampleDataSource
+    apiGroup: example.storage.k8s.io
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
+```
+
+볼륨 파퓰레이터는 외부 컴포넌트이기 때문에, 
+만약 적합한 컴포넌트가 설치되어 있지 않다면 볼륨 파퓰레이터를 사용하는 PVC에 대한 생성 요청이 실패할 수 있다.
+외부 컨트롤러는 '컴포넌트가 없어서 PVC를 생성할 수 없음' 경고와 같은 
+PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이벤트를 생성해야 한다.
+
+알파 버전의 [볼륨 데이터 소스 검증기](https://github.com/kubernetes-csi/volume-data-source-validator)를 
+클러스터에 설치할 수 있다. 
+해당 데이터 소스를 다루는 파퓰레이터가 등록되어 있지 않다면 이 컨트롤러가 PVC에 경고 이벤트를 생성한다.
+PVC를 위한 적절한 파퓰레이터가 설치되어 있다면, 
+볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다.
+
 ## 포터블 구성 작성
 
 광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한

content/ko/docs/concepts/storage/storage-capacity.md

@@ -0,0 +1,117 @@
+---
+
+
+
+
+
+
+title: 스토리지 용량
+content_type: concept
+weight: 45
+---
+
+<!-- overview -->
+
+스토리지 용량은 제한이 있으며, 파드가 실행되는 노드의 상황에 따라 달라질 수 있다.
+예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
+또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+
+이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
+스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에
+파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다.
+스토리지 용량을 추적하지 않으면, 스케줄러는
+볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며,
+스케줄링을 여러 번 다시 시도해야 한다.
+
+스토리지 용량 추적은 {{< glossary_tooltip
+text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며,
+CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다.
+
+<!-- body -->
+
+## API
+
+ 이 기능에는 다음 두 가지 API 확장이 있다.
+- CSIStorageCapacity 오브젝트:
+  CSI 드라이버가 설치된 네임스페이스에
+  CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는
+  하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며,
+  어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다.
+- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io):
+  `true`로 설정하면, 쿠버네티스 스케줄러가
+  CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다.
+
+## 스케줄링
+
+다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다.
+- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고,
+- 파드가 아직 생성되지 않은 볼륨을 사용하고,
+- 해당 볼륨은 CSI 드라이버를 참조하고
+  `WaitForFirstConsumer`
+  [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 사용하는
+  {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 사용하고,
+- 드라이버의 `CSIDriver` 오브젝트에 `StorageCapacity` 속성이
+  true로 설정되어 있다.
+
+이 경우 스케줄러는 파드에 제공할
+충분한 스토리지가 있는 노드만 고려한다.
+이 검사는 아주 간단한데,
+볼륨의 크기를 노드를 포함하는 토폴로지를 가진 `CSIStorageCapacity` 오브젝트에
+나열된 용량과 비교한다.
+
+볼륨 바인딩 모드가 `Immediate` 인 볼륨의 경우에는 스토리지 드라이버는
+볼륨을 사용하는 파드와 관계없이 볼륨을 생성할 위치를 정한다.
+볼륨을 생성한 후에, 스케줄러는
+볼륨을 사용할 수 있는 노드에 파드를 스케줄링한다.
+
+[CSI 임시 볼륨](/ko/docs/concepts/storage/volumes/#csi)의 경우에는
+볼륨 유형이 로컬 볼륨이고
+큰 자원이 필요하지 않은 특정 CSI 드라이버에서만 사용된다는 가정하에,
+항상 스토리지 용량을 고려하지 않고
+스케줄링한다.
+
+## 리스케줄링
+
+`WaitForFirstConsumer` 볼륨을 가진 파드에 대해
+노드가 선정되었더라도 아직은 잠정적인 결정이다. 다음 단계에서
+선정한 노드에서 볼륨을 사용할 수 있어야 한다는 힌트를 주고
+CSI 스토리지 드라이버에 볼륨 생성을 요청한다
+
+쿠버네티스는 시간이 지난 스토리지 용량 정보를 기반으로
+노드를 선정할 수도 있으므로, 볼륨을 실제로 생성하지 않을 수도 있다.
+그런 다음 노드 선정이 재설정되고 쿠버네티스 스케줄러가
+파드를 위한 노드를 찾는 것을 재시도한다.
+
+## 제한사항
+
+스토리지 용량 추적은 첫 시도에 스케줄링이 성공할 가능성을 높이지만,
+스케줄러가 시간이 지난 정보를 기반으로
+결정해야 할 수도 있기 때문에 이를 보장하지는 않는다.
+일반적으로 스토리지 용량 정보가 없는 스케줄링과
+동일한 재시도 메커니즘으로 스케줄링 실패를 처리한다.
+
+스케줄링이 영구적으로 실패할 수 있는 한 가지 상황은
+파드가 여러 볼륨을 사용하는 경우이다.
+토폴로지 세그먼트에 하나의 볼륨이 이미 생성되어
+다른 볼륨에 충분한 용량이 남아 있지 않을 수 있다.
+이러한 상황을 복구하려면
+용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하며,
+자동으로 처리하려면
+[추가 작업](https://github.com/kubernetes/enhancements/pull/1703)이 필요하다.
+
+## 스토리지 용량 추적 활성화
+
+스토리지 용량 추적은 베타 기능이며,
+쿠버네티스 1.21 이후 버전부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있다.
+클러스터에서 스토리지 용량 추적 기능을 활성화하는 것뿐만 아니라, CSI 드라이버에서도 이 기능을 지원해야 한다.
+자세한 내용은 드라이버 문서를 참조한다.
+
+## {{% heading "whatsnext" %}}
+
+- 설계에 대한 자세한 내용은
+ [파드 스케줄링 스토리지 용량 제약 조건](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)을 참조한다.
+- 이 기능의 추가 개발에 대한 자세한 내용은 [개선 추적 이슈 #1472](https://github.com/kubernetes/enhancements/issues/1472)를 참조한다.
+- [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 살펴본다.

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

@@ -76,7 +76,7 @@ volumeBindingMode: Immediate
 | Glusterfs            | ✓            | [Glusterfs](#glusterfs)              |
 | iSCSI                | -                   | -                                    |
 | Quobyte              | ✓            | [Quobyte](#quobyte)                  |
-| NFS                  | -                   | -                                    |
+| NFS                  | -                   | [NFS](#nfs)       |
 | RBD                  | ✓            | [Ceph RBD](#ceph-rbd)                |
 | VsphereVolume        | ✓            | [vSphere](#vsphere)                  |
 | PortworxVolume       | ✓            | [Portworx 볼륨](#portworx-볼륨)  |
@@ -423,6 +423,29 @@ parameters:
     헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
     삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.
 
+### NFS
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: example-nfs
+provisioner: example.com/external-nfs
+parameters:
+  server: nfs-server.example.com
+  path: /share
+  readOnly: false
+```
+
+* `server`: NFS 서버의 호스트네임 또는 IP 주소.
+* `path`: NFS 서버가 익스포트(export)한 경로.
+* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false).
+
+쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다.
+예시는 다음과 같다.
+* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
+* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
+
 ### OpenStack Cinder
 
 ```yaml
@@ -578,6 +601,12 @@ parameters:
 
 ### Quobyte
 
+{{< feature-state for_k8s_version="v1.22" state="deprecated" >}}
+
+Quobyte 인-트리 스토리지 플러그인은 사용 중단되었으며, 
+아웃-오브-트리 Quobyte 플러그인에 대한 [예제](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml) 
+`StorageClass`는 Quobyte CSI 저장소에서 찾을 수 있다.
+
 ```yaml
 apiVersion: storage.k8s.io/v1
 kind: StorageClass

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

@@ -124,13 +124,13 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
 {{< feature-state for_k8s_version="v1.17" state="alpha" >}}
 
 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지
-플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `true` 로 설정한다. 이 기능은 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다.
+플러그인을 끄려면, `InTreePluginAWSUnregister` 플래그를 `true` 로 설정한다.
 
 ### azureDisk {#azuredisk}
 
 `azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다.
 
-더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)을 참고한다.
+더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md)을 참고한다.
 
 #### azureDisk CSI 마이그레이션
 
@@ -148,7 +148,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
 `azureFile` 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에
 마운트한다.
 
-더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)을 참고한다.
+더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md)을 참고한다.
 
 #### azureFile CSI 마이그레이션
 
@@ -176,7 +176,7 @@ Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용
 CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다.
 {{< /note >}}
 
-더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다.
+더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)를 참조한다.
 
 ### cinder
 
@@ -347,7 +347,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
 쿠버네티스 호스트가 해당 LUN에 접근할 수 있다.
 {{< /note >}}
 
-더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)를 참고한다.
+더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)를 참고한다.
 
 ### flocker (사용 중단됨(deprecated)){#flocker}
 
@@ -365,7 +365,7 @@ Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이
 `flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다.
 {{< /note >}}
 
-더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다.
+더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다.
 
 ### gcePersistentDisk
 
@@ -462,7 +462,8 @@ spec:
     required:
       nodeSelectorTerms:
       - matchExpressions:
-        - key: failure-domain.beta.kubernetes.io/zone
+        # 1.21 이전 버전에서는 failure-domain.beta.kubernetes.io/zone 키를 사용해야 한다.
+        - key: topology.kubernetes.io/zone
           operator: In
           values:
           - us-central1-a
@@ -480,6 +481,13 @@ GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러
 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE`
 베타 기능을 활성화해야 한다.
 
+#### GCE CSI 마이그레이션 완료
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+컨트롤러 매니저와 kubelet이 `gcePersistentDisk` 스토리지 플러그인을 로드하는 것을 방지하려면, 
+`InTreePluginGCEUnregister` 플래그를 `true`로 설정한다.
+
 ### gitRepo (사용 중단됨) {#gitrepo}
 
 {{< warning >}}
@@ -525,7 +533,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다.
 {{< /note >}}
 
-더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다.
+더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다.
 
 ### hostPath {#hostpath}
 
@@ -653,7 +661,7 @@ iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수
 iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있다.
 동시 쓰기는 허용되지 않는다.
 
-더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다.
+더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/master/volumes/iscsi)를 본다.
 
 ### local
 
@@ -741,7 +749,7 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla
 사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다.
 {{< /note >}}
 
-더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다.
+더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다.
 
 ### persistentVolumeClaim {#persistentvolumeclaim}
 
@@ -789,7 +797,7 @@ spec:
 있는지 확인한다.
 {{< /note >}}
 
-자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) 예제를 참고한다.
+자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) 예제를 참고한다.
 
 ### projected
 
@@ -803,7 +811,7 @@ spec:
 * `serviceAccountToken`
 
 모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은
-[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
+[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
 
 #### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap}
 
@@ -931,7 +939,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마
 해당 볼륨 소스의 업데이트를 수신하지 않는다.
 {{< /note >}}
 
-### quobyte
+### quobyte (사용 중단됨) {#quobyte}
 
 `quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을
 파드에 마운트할 수 있다.
@@ -964,52 +972,9 @@ RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수
 RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
 동시 쓰기는 허용되지 않는다.
 
-더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를
+더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를
 참고한다.
 
-### scaleIO (사용 중단됨) {#scaleio}
-
-ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를
-생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨
-플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수
-있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는
-방법에 대한 자세한 내용은
-[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다.
-
-{{< note >}}
-사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고
-생성한 볼륨과 함께 실행해야 한다.
-{{< /note >}}
-
-다음의 예시는 ScaleIO를 사용하는 파드 구성이다.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: pod-0
-spec:
-  containers:
-  - image: k8s.gcr.io/test-webserver
-    name: pod-0
-    volumeMounts:
-    - mountPath: /test-pd
-      name: vol-0
-  volumes:
-  - name: vol-0
-    scaleIO:
-      gateway: https://localhost:443/api
-      system: scaleio
-      protectionDomain: sd0
-      storagePool: sp1
-      volumeName: vol-0
-      secretRef:
-        name: sio-secret
-      fsType: xfs
-```
-
-더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) 예제를 참고한다.
-
 ### secret
 
 `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데
@@ -1029,7 +994,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
 
 더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다.
 
-### storageOS {#storageos}
+### storageOS (사용 중단됨) {#storageos}
 
 `storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com)
 볼륨을 파드에 마운트할 수 있다.
@@ -1177,7 +1142,7 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를
 
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
-`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다.
+`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다.
 
 ## subPath 사용하기 {#using-subpath}
 

content/ko/docs/concepts/workloads/controllers/cron-jobs.md

@@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 
 ## 크론잡
 
-크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인
+크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다. 
-작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
+각 작업은 무기한 반복되도록 구성해야 한다(예: 
-스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
+1일/1주/1달마다 1회). 
+작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다.
 
 ### 예시
 

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

@@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
 
 파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
-디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
+디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면, 
-다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
+파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
+
+예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.

content/ko/docs/concepts/workloads/controllers/garbage-collection.md

@@ -6,6 +6,18 @@ weight: 60
 
 <!-- overview -->
 
+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
 쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
 소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
 

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

@@ -187,14 +187,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 
 ### 완료 모드
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
-
-{{< note >}}
-인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
-`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
-{{< /note >}}
 
 완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
 `.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
@@ -203,8 +196,14 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
   완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드
   완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는
   잡은 암시적으로 `NonIndexed` 이다.
-- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index`
+- `Indexed`: 잡의 파드는 연결된 완료 인덱스를 0에서 `.spec.completions-1` 까지 
-  어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다.
+  가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다.
+  - 파드 어노테이션 `batch.kubernetes.io/job-completion-index`.
+  - 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). 인덱스된(Indexed) 잡과 
+    {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 
+    있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 
+    호스트네임을 사용할 수 있다.
+  - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
   각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
   간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
   [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@@ -255,7 +254,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 
 ## 잡의 종료와 정리
 
-잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다.  이를 유지하면
+잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다.  
+이를 유지하면
 완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
 잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
 `kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.
@@ -402,14 +402,12 @@ spec:
 
 ### 잡 일시 중지
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 {{< note >}}
-잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을
+이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며, 
-사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
+이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다. 
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
+[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
-`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
 {{< /note >}}
 
 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
@@ -568,6 +566,46 @@ spec:
 `manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
 불일치를 허용한다.
 
+### 종료자(finalizers)를 이용한 잡 추적
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+이 기능을 이용하기 위해서는 
+[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와 
+[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해 
+`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 
+기본적으로는 비활성화되어 있다.
+
+이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. 
+기존에 존재하던 잡은 영향을 받지 않는다. 
+사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
+{{< /note >}}
+
+이 기능이 활성화되지 않으면, 잡 
+{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 
+`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다. 
+그런데, 파드는 다음과 같은 이유로 제거될 수 있다.
+- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거
+- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를 
+  일정 임계값 이후에 제거
+- 잡에 속한 파드를 사용자가 임의로 제거
+- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나 
+  교체
+
+클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면, 
+컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고 
+API 서버에서 파드가 제거되면 이를 알아챈다. 
+이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다. 
+컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로, 
+이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다.
+
+잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다. 
+이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다. 
+잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여, 
+잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다. 
+이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**.
+
 ## 대안
 
 ### 베어(Bare) 파드
@@ -594,7 +632,7 @@ spec:
 시작하기에는 다소 복잡할 수 있으며 쿠버네티스와의 통합성이 낮아진다.
 
 이 패턴의 한 예시는 파드를 시작하는 잡이다. 파드는 스크립트를 실행해서
-스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)를 본다)를 시작하고,
+스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)를 본다)를 시작하고,
 스파크 드라이버를 실행한 다음, 정리한다.
 
 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,

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

@@ -323,9 +323,9 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.
 
 ### 파드 삭제 비용
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
-[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
+[`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
 레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다.
 
 이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다.
@@ -335,9 +335,9 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다.
 유효하지 않은 값은 API 서버가 거부한다.
 
-이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다. 
+이 기능은 베타 상태이며 기본적으로 활성화되어 있다. 
-kube-apiserver와 kube-controller-manager에서 `PodDeletionCost` 
+kube-apiserver와 kube-controller-manager에 대해 `PodDeletionCost` 
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다.
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.
 
 {{< note >}}
 - 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.

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

@@ -32,7 +32,7 @@ weight: 30
 
 ## 제한사항
 
-* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
+* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
 * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
 * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
 * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
@@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 ## 업데이트 전략
 
-쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
+스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
 파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
-구성하거나 비활성화 할 수 있다.
+구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다.
 
-### 삭제 시(On Delete)
+`OnDelete`(삭제시)
-
+: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 
-`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
+스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 
-`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는
+사용자는 컨트롤러가 스테이트풀셋의
-스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
 
-### 롤링 업데이트
+`RollingUpdate`(롤링 업데이트)
+: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
+구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
 
-`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
+## 롤링 업데이트
-구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
-스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
-순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
-각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
-때까지 기다린다.
 
-#### 파티션(Partition)
+스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
+스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이
+순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로),
+각 파드의 업데이트는 한 번에 하나씩 한다.
+
+쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
+`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
+
+### 파티션 롤링 업데이트 {#partitions}
 
 `롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition`
 를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가
@@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
 
-#### 강제 롤백
+### 강제 롤백
 
 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
 함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우
@@ -273,8 +277,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로
 실행하려고 시도한 모든 파드를 삭제해야 한다.
-그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
+그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.
 
+### 최소 준비 시간 초 {#minimum-ready-seconds}
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 
+컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
+기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
+파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
+[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
+
+이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
 
 ## {{% heading "whatsnext" %}}
 

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

@@ -257,8 +257,12 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여
 
 ## 컨테이너에 대한 특권 모드
 
-파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
+리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
-특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다.
+클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다.
+
+파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다.
+
+HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
 
 {{< note >}}
 이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
@@ -282,6 +286,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
 여기에서 제어할 수는 없다는 의미이다.
 
+## 컨테이너 프로브
+
+_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
+
+- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
+- `TCPSocketAction` (kubelet에 의해 직접 검사)
+- `HTTPGetAction` (kubelet에 의해 직접 검사)
+
+[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
+파드 라이프사이클 문서를 참고한다.
+
 ## {{% heading "whatsnext" %}}
 
 * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.

content/ko/docs/concepts/workloads/pods/ephemeral-containers.md

@@ -6,15 +6,15 @@ weight: 80
 
 <!-- overview -->
 
-{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
 
-이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
+이 페이지는 임시 컨테이너에 대한 개요를 제공한다. 
-트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서
+이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 
-임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
+기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다. 
-컨테이너를 사용한다.
+임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다.
 
 {{< warning >}}
-임시 컨테이너는 초기 알파 상태이며,
+임시 컨테이너 기능은 알파 상태이며,
 프로덕션 클러스터에는 적합하지 않다.
 [쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
@@ -72,119 +72,8 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
 
 임시 컨테이너 사용 시 [프로세스 네임스페이스
 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
-활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다.
+활성화하면 다른 컨테이너 안의 프로세스를 보는 데 도움이 된다.
 
-임시 컨테이너를 사용해서 문제를 해결하는 예시는
+## {{% heading "whatsnext" %}}
-[임시 디버깅 컨테이너로 디버깅하기]
-(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다.
 
-## 임시 컨테이너 API
+* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
-
-{{< note >}}
-이 섹션의 예시는 `EphemeralContainers` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
-활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
-{{< /note >}}
-
-이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
-보여준다. 일반적으로 `kubectl debug` 또는
-다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
-사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
-
-임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
-사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
-`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다.
-
-```json
-{
-    "apiVersion": "v1",
-    "kind": "EphemeralContainers",
-    "metadata": {
-        "name": "example-pod"
-    },
-    "ephemeralContainers": [{
-        "command": [
-            "sh"
-        ],
-        "image": "busybox",
-        "imagePullPolicy": "IfNotPresent",
-        "name": "debugger",
-        "stdin": true,
-        "tty": true,
-        "terminationMessagePolicy": "File"
-    }]
-}
-```
-
-이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다.
-
-```shell
-kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers  -f ec.json
-```
-
-그러면 새로운 임시 컨테이너 목록이 반환된다.
-
-```json
-{
-   "kind":"EphemeralContainers",
-   "apiVersion":"v1",
-   "metadata":{
-      "name":"example-pod",
-      "namespace":"default",
-      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
-      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
-      "resourceVersion":"15886",
-      "creationTimestamp":"2019-08-29T06:41:42Z"
-   },
-   "ephemeralContainers":[
-      {
-         "name":"debugger",
-         "image":"busybox",
-         "command":[
-            "sh"
-         ],
-         "resources":{
-
-         },
-         "terminationMessagePolicy":"File",
-         "imagePullPolicy":"IfNotPresent",
-         "stdin":true,
-         "tty":true
-      }
-   ]
-}
-```
-
-사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다.
-
-```shell
-kubectl describe pod example-pod
-```
-
-```
-...
-Ephemeral Containers:
-  debugger:
-    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
-    Image:         busybox
-    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
-    Port:          <none>
-    Host Port:     <none>
-    Command:
-      sh
-    State:          Running
-      Started:      Thu, 29 Aug 2019 06:42:21 +0000
-    Ready:          False
-    Restart Count:  0
-    Environment:    <none>
-    Mounts:         <none>
-...
-```
-
-예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서
-다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와
-상호작용할 수 있다.
-
-```shell
-kubectl attach -it example-pod -c debugger
-```

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

@@ -290,8 +290,9 @@ myapp-pod   1/1       Running   0          9m
 초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
 다음의 규칙이 적용된다.
 
-* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
+* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 
-  높은 것은 *유효한 초기화 요청량/상한* 이다.
+  가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는 
+  이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
 * 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
   * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
   * 리소스에 대한 유효한 초기화 요청량/상한