Ko: 1st Korean l10n work for release-1.20

- Translate reference/glossary/persistent-volume.md in Korean (#25474) - Update outdated files in the dev-1.20-ko.1 branch (1) (#25576) - Translate blog/dont-panic-kubernetes-and-docker into Korean (#25596) - Update outdated files in the dev-1.20-ko.1 branch(3) (#25728) - Ko: enhance tutorials//cluster-intro translation (#25754) - Fix Outdated files in the dev-1.20-ko.1 branch (2) (#25765) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: jmyung <jesang.myung@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: santachopa <santachopa@naver.com> Co-authored-by: SEUNGHYUN KO <kosehy@gmail.com> Co-authored-by: June Yi <gochist@gmail.com>
2020-12-14 00:16:04 +00:00 · 2020-12-14 00:16:04 +00:00 · 0ed380d4aa
parent 8fd80c3e35
commit 0ed380d4aa
60 changed files with 1290 additions and 731 deletions
--- a/content/ko/blog/_index.md
+++ b/content/ko/blog/_index.md
@ -0,0 +1,16 @@
+---
+title: 쿠버네티스 블로그
+linkTitle: 블로그
+menu:
+  main:
+    title: "블로그"
+    weight: 40
+    post: >
+       <p>쿠버네티스와 컨테이너 전반적 영역에 대한 최신 뉴스도 읽고, 방금 나온 따끈따끈한 기술적 노하우도 알아보세요.</p>
+---
+{{< comment >}}
+
+블로그에 기여하는 방법에 대한 자세한 내용은
+https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post 를 참고하세요.
+
+{{< /comment >}}
--- a/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
+++ b/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
@ -0,0 +1,104 @@
+---
+layout: blog
+title: "당황하지 마세요. 쿠버네티스와 도커"
+date: 2020-12-02
+slug: dont-panic-kubernetes-and-docker
+---
+
+**작성자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
+
+쿠버네티스는 v1.20 이후 컨테이너 런타임으로서
+[도커를
+사용 중단(deprecating)](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)합니다.
+
+**당황할 필요는 없습니다. 말처럼 극적이진 않습니다.**
+
+요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 [컨테이너 런타임 인터페이스(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)를
+사용하는 런타임으로써는 더 이상 사용되지 않습니다(deprecated).
+도커가 생성한 이미지는 늘 그래왔듯이 모든 런타임을 통해 클러스터에서
+계속 작동될 것입니다.
+
+쿠버네티스의 엔드유저에게는 많은 변화가 없을 것입니다.
+이 내용은 도커의 끝을 의미하지 않으며, 도커를 더 이상 개발 도구로 사용할 수 없다거나,
+사용하면 안 된다는 의미도 아닙니다. 도커는 여전히 컨테이너를
+빌드하는 데 유용한 도구이며, `docker
+build` 실행 결과로 만들어진 이미지도 여전히 쿠버네티스 클러스터에서 동작합니다.
+
+GKE, EKS 또는 AKS([containerd가 기본](https://github.com/Azure/AKS/releases/tag/2020-11-16)인)와 같은 관리형 쿠버네티스 서비스를
+사용하는 경우 쿠버네티스의 향후 버전에서 도커에 대한 지원이
+없어지기 전에, 워커 노드가 지원되는 컨테이너 런타임을 사용하고 있는지 확인해야 합니다. 노드에
+사용자 정의가 적용된 경우 사용자 환경 및 런타임 요구 사항에 따라 업데이트가 필요할 수도
+있습니다. 서비스 공급자와 협업하여 적절한 업그레이드
+테스트 및 계획을 확인하세요.
+
+자체 클러스터를 운영하는 경우에도, 클러스터의 고장을 피하기 위해서
+변경을 수행해야 합니다. v1.20에서는 도커에 대한 지원 중단 경고(deprecation warning)가 표시됩니다.
+도커 런타임 지원이 쿠버네티스의 향후 릴리스(현재는 2021년 하반기의
+1.22 릴리스로 계획됨)에서 제거되면 더 이상 지원되지
+않으며, containerd 또는 CRI-O와 같은 다른 호환 컨테이너 런타임 중
+하나로 전환해야 합니다. 선택한 런타임이 현재 사용 중인
+도커 데몬 구성(예: 로깅)을 지원하는지 확인하세요.
+
+## 많은 사람들이 걱정하는 이유는 무엇이며, 왜 이런 혼란이 야기되었나요?
+
+우리는 여기서 두 가지 다른 환경에 대해 이야기하고 있는데, 이것이 혼란을 야기하고
+있습니다. 쿠버네티스 클러스터 내부에는 컨테이너 이미지를 가져오고
+실행하는 역할을 하는 컨테이너 런타임이라는 것이 있습니다. 도커를
+컨테이너 런타임(다른 일반적인 옵션에는 containerd 및 CRI-O가 있음)으로 많이
+선택하지만, 도커는 쿠버네티스 내부에 포함(embedded)되도록 설계되지 않았기에 문제를
+유발합니다.
+
+우리가 "도커"라고 부르는 것은 실제로는 하나가 아닙니다. 도커는
+전체 기술 스택이고, 그 중 한 부분은 그 자체로서 고수준(high-level)의
+컨테이너 런타임인 "containerd" 입니다. 도커는 개발을 하는 동안
+사람이 정말 쉽게 상호 작용할 수 있도록 많은 UX 개선을 포함하므로
+도커는 멋지고 유용합니다. 하지만, 쿠버네티스는 사람이 아니기 때문에
+이런 UX 개선 사항들이 필요하지 않습니다.
+
+이 인간 친화적인 추상화 계층의 결과로, 쿠버네티스 클러스터는
+containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심(Dockershim)이라는
+다른 도구를 사용해야 합니다. 이것은 좋지 않습니다. 왜냐하면, 이는 추가적인 유지 관리를
+필요로 하고 오류의 가능성도 높이기 때문입니다. 여기서 실제로 일어나는 일은
+도커심이 빠르면 v1.23 릴리스에 Kubelet에서 제거되어, 결과적으로
+도커에 대한 컨테이너 런타임으로서의 지원이 제거된다는 것입니다. 여러분
+스스로도 생각할 수 있을 것입니다. containerd가 도커 스택에 포함되어 있는 것이라면, 도커심이
+쿠버네티스에 왜 필요할까요?
+
+도커는 [컨테이너 런타임 인터페이스](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)인 CRI를 준수하지 않습니다.
+만약 이를 준수했다면, 심(shim)이 필요하지 않았을 것입니다. 그러나
+이건 세상의 종말이 아니며, 당황할 필요도 없습니다. 여러분은 단지
+컨테이너 런타임을 도커에서 지원되는 다른 컨테이너 런타임으로 변경하기만 하면 됩니다.
+
+참고할 사항 한 가지: 현재 클러스터 내 워크플로의 일부가 기본 도커 소켓
+(/var/run/docker.sock)에 의존하고 있는 경우, 다른
+런타임으로 전환하는 것은 해당 워크플로의 사용에 문제를 일으킵니다. 이 패턴은 종종
+도커 내의 도커라고 합니다. 이런 특정 유스케이스에 대해서
+[kaniko](https://github.com/GoogleContainerTools/kaniko),
+[img](https://github.com/genuinetools/img)와
+[buildah](https://github.com/containers/buildah)
+같은 것들을 포함해 많은 옵션들이 있습니다.
+
+## 그렇지만, 이 변경이 개발자에게는 어떤 의미인가요? 여전히 Dockerfile을 작성나요? 여전히 도커로 빌드하나요?
+
+이 변경 사항은 사람들(folks)이 보통 도커와 상호 작용하는 데 사용하는 것과는 다른 환경을
+제시합니다. 개발에 사용하는 도커의 설치는 쿠버네티스 클러스터 내의
+도커 런타임과 관련이 없습니다. 혼란스럽죠, 우리도 알고 있습니다. 개발자에게
+도커는 이 변경 사항이 발표되기 전과 마찬가지로 여전히
+유용합니다. 도커가 생성하는 이미지는 실제로는
+도커에만 특정된 이미지가 아니라 OCI([Open Container Initiative](https://opencontainers.org/)) 이미지입니다.
+모든 OCI 호환 이미지는 해당 이미지를 빌드하는 데 사용하는 도구에 관계없이 
+쿠버네티스에서 동일하게 보입니다. [containerd](https://containerd.io/)와
+[CRI-O](https://cri-o.io/)는 모두 해당 이미지를 가져와 실행하는 방법을 알고 있습니다. 이것이
+컨테이너가 어떤 모습이어야 하는지에 대한 표준이 있는 이유입니다.
+
+변경은 다가오고 있습니다. 이 변경이 일부 문제를 일으킬 수도 있지만, 치명적이지는
+않으며, 일반적으로는 괜찮은 일입니다. 사용자가 쿠버네티스와 상호 작용하는
+방식에 따라 이 변경은 아무런 의미가 없거나 약간의 작업만을 의미할 수 있습니다.
+장기적으로는 일이 더 쉬워질 것입니다. 이것이 여전히
+혼란스럽더라도 괜찮습니다. 이에 대해서 많은 일이 진행되고 있습니다. 쿠버네티스에는 변화되는
+부분이 많이 있고, 이에 대해 100% 전문가는 없습니다. 경험 수준이나
+복잡성에 관계없이 어떤 질문이든 하시기 바랍니다! 우리의 목표는
+모든 사람이 다가오는 변경 사항에 대해 최대한 많은 교육을 받을 수 있도록 하는 것입니다. `<3` 이 글이
+여러분이 가지는 대부분의 질문에 대한 답이 되었고, 불안을 약간은 진정시켰기를 바랍니다!
+
+더 많은 답변을 찾고 계신가요? 함께 제공되는 [도커심 사용 중단 FAQ](/blog/2020/12/02/dockershim-faq/)를 확인하세요.
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@ -327,6 +327,26 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 자세한 내용은
 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.

+## 그레이스풀(Graceful) 노드 셧다운
+
+{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
+
+`GracefulNodeShutdown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한 경우 kubelet은 노드 시스템 종료를 감지하고 노드에서 실행 중인 파드를 종료한다.
+Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다.
+
+`GracefulNodeShutdown` 기능 게이트가 활성화되면 kubelet은 [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 사용하여 주어진 기간 동안 노드 종료를 지연시킨다. 종료 중에 kubelet은 두 단계로 파드를 종료시킨다.
+
+1. 노드에서 실행 중인 일반 파드를 종료시킨다.
+2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
+
+그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
+* `ShutdownGracePeriod`:
+  * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
+* `ShutdownGracePeriodCriticalPods`:
+  * 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이는 `ShutdownGracePeriod`보다 작아야 한다.
+
+예를 들어 `ShutdownGracePeriod=30s`, `ShutdownGracePeriodCriticalPods=10s` 인 경우 kubelet은 노드 종료를 30 초까지 지연시킨다. 종료하는 동안 처음 20(30-10) 초는 일반 파드의 유예 종료에 할당되고, 마지막 10 초는 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
+

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

@ -335,3 +355,4 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
  섹션을 읽어본다.
 * [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
+
--- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
@ -17,7 +17,7 @@ weight: 70

 ## 이미지 수집

-쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의 
+쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
 라이프사이클을 관리한다.

 이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
@ -36,26 +36,26 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대

 ## 사용자 설정

-사용자는 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
+여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.

 1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
 기본값은 85% 이다.
 2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
 기본값은 80% 이다.

-또한 사용자는 다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의 할 수 있다.
+다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.

-1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집 
-되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다. 
+1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
+되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
 2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된
 인스턴스의 최대 수. 기본 값은 1 이다.
 3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
 기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.

 컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
-문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도 
-1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container` 
-값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers` 
+문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
+1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
+값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
 의 값도 상대적으로 더 큰 값을 권장한다.
 자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다.

@ -82,5 +82,3 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대


 자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다.
-
-
--- a/content/ko/docs/concepts/cluster-administration/networking.md
+++ b/content/ko/docs/concepts/cluster-administration/networking.md
@ -55,11 +55,12 @@ weight: 50
 주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
 프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.

-쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
+쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
 컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
 `localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
 `Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
-VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다.
+VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 
+한다.

 이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.

--- a/content/ko/docs/concepts/cluster-administration/system-metrics.md
+++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md
@ -128,6 +128,25 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
 cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
 ```

+### kube-scheduler 메트릭
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
+
+kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다.
+- 네임스페이스
+- 파드 이름
+- 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열
+- 우선순위
+- 해당 파드에 할당된 스케줄러
+- 리소스 이름 (예: `cpu`)
+- 알려진 경우 리소스 단위 (예: `cores`)
+
+파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다.
+
+메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
+와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.


 ## {{% heading "whatsnext" %}}
--- a/content/ko/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md
@ -600,6 +600,10 @@ spec:
        example.com/foo: 1
 ```

+## PID 제한
+
+프로세스 ID(PID) 제한은 kubelet의 구성에 대해 주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다. 자세한 내용은 [Pid 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
+
 ## 문제 해결

 ### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다
--- a/content/ko/docs/concepts/configuration/secret.md
+++ b/content/ko/docs/concepts/configuration/secret.md
@ -134,7 +134,7 @@ data:
 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면
 서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
 또한 파드에서 서비스 어카운트를 참조하는 방법을
-[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의
+[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의
 `automountServiceAccountToken` 필드와 `serviceAccountName`
 필드를 통해 확인할 수 있다.

@ -152,7 +152,7 @@ data:
 인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지
 확실히 확인해야 한다.

-`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의
+`kubernetes.io/dockerconfigjson` 타입은 `~/.dockercfg` 의
 새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을
 따르는 직렬화 된 JSON의 저장을 위해 디자인되었다.
 이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를
@ -347,22 +347,21 @@ data:
  usage-bootstrap-signing: dHJ1ZQ==
 ```

-부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다.
+부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다.

 - `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항.
 - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항.
- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
+- `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는
  문자열. 선택 사항.
 - `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를
  사용하는 절대 UTC 시간. 선택 사항.
 - `usage-bootstrap-<usage>`: 부트스트랩 토큰의 추가적인 사용처를 나타내는
  불리언(boolean) 플래그.
- `auth-extra-groups`: system:bootstrappers 그룹에 추가로 인증될
+- `auth-extra-groups`: `system:bootstrappers` 그룹에 추가로 인증될
  쉼표로 구분된 그룹 이름 목록.

 위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일
-수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿 오브젝트 결과를 만드는
-동일한 시크릿을 생성할 수 있다.
+수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿을 생성할 수 있다.

 ```yaml
 apiVersion: v1
@ -724,6 +723,11 @@ echo $SECRET_PASSWORD
 1f2d1e2e67df
 ```

+#### 시크릿 업데이트 후 환경 변수가 업데이트되지 않음
+
+컨테이너가 환경 변수에서 이미 시크릿을 사용하는 경우, 다시 시작하지 않는 한 컨테이너에서 시크릿 업데이트를 볼 수 없다.
+시크릿이 변경될 때 재시작을 트리거하는 써드파티 솔루션이 있다.
+
 ## 변경할 수 없는(immutable) 시크릿 {#secret-immutable}

 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
--- a/content/ko/docs/concepts/containers/runtime-class.md
+++ b/content/ko/docs/concepts/containers/runtime-class.md
@ -6,7 +6,7 @@ weight: 20

 <!-- overview -->

-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}

 이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.

@ -63,7 +63,7 @@ weight: 20
 (`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.

 ```yaml
-apiVersion: node.k8s.io/v1beta1  # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
+apiVersion: node.k8s.io/v1  # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
 kind: RuntimeClass
 metadata:
  name: myclass  # 런타임클래스는 해당 이름을 통해서 참조됨
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@ -203,7 +203,7 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스
 `/var/lib/kubelet/pod-resources` 를
 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다.

-"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 쿠버네티스 1.15부터 기본적으로 활성화되어 있다.
+"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.

 ## 토폴로지 관리자와 장치 플러그인 통합

@ -254,5 +254,3 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 * 노드에서의 [확장 리소스 알리기](/ko/docs/tasks/administer-cluster/extended-resource-node/)에 대해 배우기
 * 쿠버네티스에서 [TLS 수신에 하드웨어 가속](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) 사용에 대해 읽기
 * [토폴로지 관리자](/docs/tasks/administer-cluster/topology-manager/)에 대해 알아보기
-
-
--- a/content/ko/docs/concepts/overview/kubernetes-api.md
+++ b/content/ko/docs/concepts/overview/kubernetes-api.md
@ -75,19 +75,10 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
 IDL(인터페이스 정의 언어) 파일을 참고한다.

-## API 변경 사항
+## 지속성

-성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
-따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 기능을 설계했다.
-쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
-적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
-
-일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
-리소스 또는 필드를 제거하려면
-[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
-
-호환 가능한 변경 사항과 API 변경 방법은
-[API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에 자세히 설명되어 있다.
+쿠버네티스는 오브젝트의 직렬화된 상태를
+{{< glossary_tooltip term_id="etcd" >}}에 기록하여 저장한다.

 ## API 그룹과 버전 규칙

@ -105,29 +96,44 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를
 가능한 [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 구현한다.

 API 리소스는 API 그룹, 리소스 유형, 네임스페이스
-(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는
-여러 API 버전을 통해 동일한 기본 데이터를 제공하고 API 버전 간의
-변환을 투명하게 처리할 수 있다. 이 모든 다른 버전은 실제로
-같은 리소스의 표현이다. 예를 들어 동일한 리소스에 대해
-두 가지 버전 `v1`과 `v1beta1`이 있다고 가정해 보자.
-`v1beta1` 버전에서 생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서
-읽기, 업데이트 및 삭제할 수 있다.
+(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 API 버전 간의
+변환을 투명하게 처리한다. 서로 다른 모든 버전은 실제로
+동일한 지속 데이터의 표현이다. API 서버는 여러 API 버전을 통해
+동일한 기본 데이터를 제공할 수 있다.

-API 버전 수준 정의에 대한 자세한 내용은
-[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다.
+예를 들어, 동일한 리소스에 대해  `v1` 과 `v1beta1` 이라는 두 가지 API 버전이
+있다고 가정한다. 원래 API의 `v1beta1` 버전을 사용하여 오브젝트를
+만든 경우, 나중에 `v1beta1` 또는 `v1` API 버전을 사용하여 해당 오브젝트를
+읽거나, 업데이트하거나, 삭제할 수 있다.

-API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스
-(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한
-기본 데이터를 제공하고 API 버전 간의 변환을 투명하게
-처리할 수 있다. 이 모든 다른 버전은 실제로
-동일한 리소스의 표현이다. 예를 들어, 동일한 리소스에 대해 두 가지
-버전 `v1` 과 `v1beta1` 이 있다고 가정한다. 그런 다음 `v1beta1` 버전에서
-생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 읽고 업데이트하고
-삭제할 수 있다.
+## API 변경 사항
+
+성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다.
+따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 설계했다.
+쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 _않고_ 다른 프로젝트가
+적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.
+
+일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다.
+리소스 또는 필드를 제거하려면
+[API 지원 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따라야 한다.
+
+쿠버네티스는 일반적으로 API 버전 `v1` 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에
+대한 호환성 유지를 강력하게 이행한다. 또한,
+쿠버네티스는 가능한 경우 _베타_ API 버전에서도 호환성을 유지한다.
+베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와
+계속 상호 작용할 수 있다.
+
+{{< note >}}
+쿠버네티스는 또한 _알파_ API 버전에 대한 호환성을 유지하는 것을 목표로 하지만, 일부
+상황에서는 호환성이 깨진다. 알파 API 버전을 사용하는 경우, API가 변경된 경우 클러스터를
+업그레이드할 때 쿠버네티스에 대한 릴리스 정보를 확인한다.
+{{< /note >}}

 API 버전 수준 정의에 대한 자세한 내용은
 [API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다.

+
+
 ## API 확장

 쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.
@ -145,3 +151,5 @@ API 버전 수준 정의에 대한 자세한 내용은
  클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
 - [API 레퍼런스](/docs/reference/kubernetes-api/)를
  읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
+- [API 변경 사항](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)에서
+  호환 가능한 변경 사항을 구성하고, API를 변경하는 방법에 대해 알아본다.
--- a/content/ko/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md
@ -138,10 +138,11 @@ partition
 !partition
 ```

-첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
-두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
-세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
-네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
+* 첫 번째 예시에서 키가 `environment`이고 값이 `production` 또는 `qa`인 모든 리소스를 선택한다.
+* 두 번째 예시에서 키가 `tier`이고 값이 `frontend`와 `backend`를 가지는 리소스를 제외한 모든 리소스와 키로 `tier`를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
+* 세 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하는 모든 리소스를 선택한다.
+* 네 번째 예시에서 레이블의 값에 상관없이 키가 `partition`을 포함하지 않는 모든 리소스를 선택한다.
+
 마찬가지로 쉼표는 _AND_ 연산자로 작동한다. 따라서 `partition,environment notin (qa)`와 같이 사용하면 값과 상관없이 키가 `partition`인 것과 키가 `environment`이고 값이 `qa`와 다른 리소스를 필터링할 수 있다.
 _집합성 기준_ 레이블 셀렉터는 일반적으로 `environment=production`과 `environment in (production)`을 같은 것으로 본다. 유사하게는 `!=`과 `notin`을 같은 것으로 본다.

--- a/content/ko/docs/concepts/policy/pod-security-policy.md
+++ b/content/ko/docs/concepts/policy/pod-security-policy.md
@ -1,7 +1,7 @@
 ---
 title: 파드 시큐리티 폴리시
 content_type: concept
-weight: 20
+weight: 30
 ---

 <!-- overview -->
--- a/content/ko/docs/concepts/policy/resource-quotas.md
+++ b/content/ko/docs/concepts/policy/resource-quotas.md
@ -1,7 +1,7 @@
 ---
 title: 리소스 쿼터
 content_type: concept
-weight: 10
+weight: 20
 ---

 <!-- overview -->
--- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
@ -154,6 +154,49 @@ spec:

 `preferredDuringSchedulingIgnoredDuringExecution` 의 `weight` 필드의 범위는 1-100이다. 모든 스케줄링 요구 사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)"를 추가한다. 이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다.

+#### 스케줄링 프로파일당 노드 어피니티
+
+{{< feature-state for_k8s_version="v1.20" state="beta" >}}
+
+여러 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)을 구성할 때 
+노드 어피니티가 있는 프로파일을 연결할 수 있는데, 이는 프로파일이 특정 노드 집합에만 적용되는 경우 유용하다.
+이렇게 하려면 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는 
+[`NodeAffinity` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인-1)의 인수에 `addedAffinity`를 추가한다. 예를 들면
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - schedulerName: default-scheduler
+  - schedulerName: foo-scheduler
+    pluginConfig:
+      - name: NodeAffinity
+        args:
+          addedAffinity:
+            requiredDuringSchedulingIgnoredDuringExecution:
+              nodeSelectorTerms:
+              - matchExpressions:
+                - key: scheduler-profile
+                  operator: In
+                  values:
+                  - foo
+```
+
+`addedAffinity`는 `.spec.schedulerName`을 `foo-scheduler`로 설정하는 모든 파드에 적용되며 
+PodSpec에 지정된 NodeAffinity도 적용된다.
+즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 파드의 `.spec.NodeAffinity`를 충족해야 한다.
+
+`addedAffinity`는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 프로파일의 
+스케줄러 이름과 명확한 상관 관계가 있는 노드 레이블을 사용하는 것이 좋다.
+
+{{< note >}}
+[데몬셋용 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는 
+스케줄링 프로파일을 인식하지 못한다.
+따라서 `addedAffinity`없이 `default-scheduler`와 같은 스케줄러 프로파일을 유지하는 것이 좋다. 그런 다음 데몬셋의 파드 템플릿이 스케줄러 이름을 사용해야 한다.
+그렇지 않으면, 데몬셋 컨트롤러에 의해 생성된 일부 파드가 스케줄되지 않은 상태로 유지될 수 있다.
+{{< /note >}}
+
 ### 파드간 어피니티와 안티-어피니티

 파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, *노드에서 이미 실행 중인 파드 레이블을 기반으로*
@ -386,3 +429,5 @@ spec:
 파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다.
 [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는
 노드 수준의 리소스 할당 결정에 참여할 수 있다.
+
+
--- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
+++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
@ -44,7 +44,7 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
 ```yaml
 ---
 kind: RuntimeClass
-apiVersion: node.k8s.io/v1beta1
+apiVersion: node.k8s.io/v1
 metadata:
    name: kata-fc
 handler: kata-fc
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@ -165,11 +165,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac

 ### 파드의 setHostnameAsFQDN 필드 {# pod-sethostnameasfqdn-field}

-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
-
-**전제 조건**: `SetHostnameAsFQDN` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}에
-대해 활성화해야 한다.
+{{< feature-state for_k8s_version="v1.20" state="beta" >}}

 파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.

--- a/content/ko/docs/concepts/services-networking/dual-stack.md
+++ b/content/ko/docs/concepts/services-networking/dual-stack.md
@ -26,14 +26,17 @@ weight: 70
 쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택을 활성화하면 다음의 기능을 제공한다.

   * 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
-   * IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.)
+   * IPv4와 IPv6 지원 서비스
   * IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷)

 ## 필수 구성 요소

 IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다.

-   * 쿠버네티스 1.16 또는 이후 버전
+   * 쿠버네티스 1.20 이상
+     이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보
+     쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 
+     문서 참조
   * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
   * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인

@ -64,45 +67,173 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만,

 ## 서비스

-만약 클러스터 IPv4/IPv6 이중 스택 네트워킹을 활성화한 경우, IPv4 또는 IPv6 주소로 {{< glossary_tooltip text="서비스" term_id="service" >}} 를 만들 수 있다. 해당 서비스에서 `.spec.ipFamily` 필드를 설정하면, 서비스 클러스터 IP의 주소 패밀리를 선택할 수 있다.
-새 서비스를 생성할 때만 이 필드를 설정할 수 있다. `.spec.ipFamily` 필드는 선택 사항이며 클러스터에서 {{< glossary_tooltip text="서비스" term_id="service" >}} 와 {{< glossary_tooltip text="인그레스" term_id="ingress" >}} 를 IPv4와 IPv6로 사용하도록 설정할 경우에만 사용해야 한다. 이 필드의 구성은 [이그레스](#이그레스-트래픽)에 대한 요구사항이 아니다.
+클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다.
+
+서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-controller-manager에 구성)
+
+서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 
+다음 값 중 하나로 설정한다.
+
+* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다.
+* `PreferDualStack`:
+  * 클러스터에 이중 스택이 활성화된 경우에만 사용된다. 서비스에 대해 IPv4 및 IPv6 클러스터 IP를 할당한다.
+  * 클러스터에 이중 스택이 활성화되지 않은 경우, 이 설정은 `SingleStack`과 동일한 동작을 따른다.
+* `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다.
+  * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다.
+  * 클러스터에는 이중 스택 네트워킹이 구성되어 있어야 한다.
+
+단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다.

 {{< note >}}
-클러스터의 기본 주소 패밀리는 `--service-cluster-ip-range` 플래그로 kube-controller-manager에 구성된 첫 번째 서비스 클러스터 IP 범위의 주소 패밀리이다.
+`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를 재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면 서비스를 삭제하고 다시 생성한다.
 {{< /note >}}

-`.spec.ipFamily` 를 다음 중 하나로 설정할 수 있다.
+`.spec.ipFamilies`를 다음 배열 값 중 하나로 설정할 수 있다.

-   * `IPv4`: API 서버는 `ipv4` 인 `service-cluster-ip-range` 의 IP를 할당 한다.
-   * `IPv6`: API 서버는 `ipv6` 인 `service-cluster-ip-range` 의 IP를 할당 한다.
+- `["IPv4"]`
+- `["IPv6"]`
+- `["IPv4","IPv6"]` (이중 스택)
+- `["IPv6","IPv4"]` (이중 스택)

-다음 서비스 사양에는 `ipFamily` 필드가 포함되어 있지 않다. 쿠버네티스는 처음 구성된 `service-cluster-ip-range` 의 IP 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당 한다.
+나열한 첫 번째 군은 레거시`.spec.ClusterIP` 필드에 사용된다.
+
+### 이중 스택 서비스 구성 시나리오
+
+이 예제는 다양한 이중 스택 서비스 구성 시나리오의 동작을 보여준다.
+
+#### 새로운 서비스에 대한 이중 스택 옵션
+
+1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를 `SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와 같은 방식으로 동작한다.)

 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}

-다음 서비스 명세에는 `ipFamily` 필드가 포함되어 있다. 쿠버네티스는 구성된 `service-cluster-ip-range` 의 IPv6 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당 한다.
+1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 `.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는 기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이 `.spec.ClusterIPs`에서 계산된 보조 필드이다.

-{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
+      * `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다.
+      * 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는 모두 하나의 주소만 나열한다.
+      * 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을 지정하면 `PreferDualStack`과 동일하게 작동한다.

-비교를 위해, 다음 서비스 명세에는 구성된 `service-cluster-ip-range` 의 IPv4 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당한다.
+{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}

-{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
+1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에 IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다.

-### 로드밸런서 유형
+{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}}

-IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급자들은 `type` 필드를 `LoadBalancer` 로 설정하고, 추가적으로 `ipFamily` 필드를 `IPv6` 로 설정하면 서비스에 대한 클라우드 로드 밸런서가 구축된다.
+#### 기존 서비스의 이중 스택 기본값

-## 이그레스 트래픽
+이 예제는 서비스가 이미있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다.

-근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent를 사용할 수 있다.
+1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다.

-## 알려진 이슈들
+{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}

-   * Kubenet은 IP의 IPv4,IPv6의 위치 보고를 강제로 수행한다. (--cluster-cidr)
+   kubectl을 사용하여 기존 서비스를 검사하여 이 동작을 검증할 수 있다.

+```shell
+kubectl get svc my-service -o yaml
+```

+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: MyApp
+  name: my-service
+spec:
+  clusterIP: 10.0.197.123
+  clusterIPs:
+  - 10.0.197.123
+  ipFamilies:
+  - IPv4
+  ipFamilyPolicy: SingleStack
+  ports:
+  - port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:
+    app: MyApp
+  type: ClusterIP
+status:
+  loadBalancer: {}
+```
+
+1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-controller-manager에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다.
+
+{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+
+   kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다.
+
+```shell
+kubectl get svc my-service -o yaml
+```
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: MyApp
+  name: my-service
+spec:
+  clusterIP: None
+  clusterIPs:
+  - None
+  ipFamilies:
+  - IPv4
+  ipFamilyPolicy: SingleStack
+  ports:
+  - port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:
+    app: MyApp
+```
+
+#### 단일 스택과 이중 스택 간 서비스 전환
+
+서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다.
+
+1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다.
+
+   `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack`으로 업데이트하는 서비스 사양을 편집한다.
+
+이전:
+```yaml
+spec:
+  ipFamilyPolicy: SingleStack
+```
+이후:
+```yaml
+spec:
+  ipFamilyPolicy: PreferDualStack
+```
+
+1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다.
+
+### 셀렉터가 없는 헤드리스 서비스
+
+[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가 명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은 `RequireDualStack` 이다.
+
+### 로드밸런서 서비스 유형
+
+서비스에 이중 스택 로드밸런서를 프로비저닝하려면
+   * `.spec.type` 필드를 `LoadBalancer`로 설정
+   * `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정
+
+{{< note >}}
+이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다.
+{{< /note >}}
+
+## 이그레스(Egress) 트래픽
+
+비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다.
+
+{{< note >}}
+{{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 IPv6를 지원하는지 확인한다.
+{{< /note >}}

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


-* [IPv4/IPv6 이중 스택 확인](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
+* [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹
--- a/content/ko/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md
@ -73,7 +73,8 @@ endpoints:
 ```

 기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를
-갖도록 엔드포인트슬라이스를 생성하고 관리한다. `--max-endpoints-per-slice`
+갖도록 엔드포인트슬라이스를 
+생성하고 관리한다. `--max-endpoints-per-slice`
 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
 플래그를 사용하여, 최대 1000개까지 구성할 수 있다.

@ -90,8 +91,58 @@ endpoints:
 * IPv6
 * FQDN (전체 주소 도메인 이름)

+### 조건
+
+엔드포인트슬라이스 API는 컨슈머에게 유용한 엔드포인트에 대한 조건을 저장한다.
+조건은 `준비`, `제공` 및 `종료` 세 가지가 있다.
+
+#### 준비
+
+`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는 
+이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의 
+이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여 
+파드 종료 준비 상태(readiness)를 검사해야 한다.
+이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다.
+이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다.
+
+#### 제공(Serving)
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+`serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다.
+엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면 
+이 조건을 확인해야 한다.
+
+{{< note >}}
+
+`serving`은 `ready`와 거의 동일하지만 `ready`의 기존 의미가 깨지는 것을 방지하기 위해 추가되었다.
+엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다. 
+역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다.
+이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며, 
+클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를 
+추적 할 수 있도록 v1.20에 새로운 조건 `serving`이 추가되었다.
+
+{{< /note >}}
+
+#### 종료(Terminating)
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+`종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다.
+파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다.
+
 ### 토폴로지 정보 {#토폴로지}

+{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
+
+{{< note >}}
+엔드포인트슬라이스의 토폴로지 필드는 사용 중단되었으며 향후 릴리스에서 제거된다.
+토폴로지에서 `kubernetes.io/hostname`을 설정하는 대신 새로운 `nodeName` 필드가 
+사용된다. 영역 및 리전을 커버하는 다른 토폴로지 필드는 
+엔드포인트슬라이스 내의 모든 엔드포인트에 적용되는 
+엔드포인트슬라이스 레이블을 이용해 더 잘 표현될 수 있다.
+{{< /note >}}
+
 엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다.
 이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된
 엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면,
--- a/content/ko/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md
@ -13,8 +13,8 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
 클러스터와 함께 자동으로 실행되지 않는다.
 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.

-프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와
-  [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다.
+프로젝트로써 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
+  [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다.



@ -24,31 +24,31 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의

 {{% thirdparty-content %}}

-* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
-* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
-  [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
-  [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
-* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
-* [AWS 로드 밸런서 컨트롤러](https://github.com/kubernetes-sigs/aws-load-balancer-controller)(이전의 AWS ALB 인그레스 컨트롤러)는 [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)을 사용하여 인그레스를 활성화한다.
-* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
-  VMware에서 제공하고 지원한다.
-* Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다.
-* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨테이너 인그레스 서비스](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한
-  [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다.
-* [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다.
-* [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.
-* [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다.
-* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로
-  [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/).
-* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한
-  [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는
-  [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다.
-* [NGINX, Inc.](https://www.nginx.com/)는
-  [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다.
-* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.
-* [Traefik](https://github.com/traefik/traefik)은
-  모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로,
-  [Traefik Labs](https://traefik.io)에서 상업적인 지원을 제공한다.
+* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
+* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
+  컨트롤러다.
+* [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
+  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
+* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
+* 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) 기반의
+  오픈소스 인그레스 컨트롤러다.
+* [HAProxy 인그레스](https://haproxy-ingress.github.io/)는 [HAProxy](http://www.haproxy.org/#desc)의
+  인그레스 컨트롤러다.
+* [쿠버네티스 용 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress#readme)는 [HAProxy](http://www.haproxy.org/#desc) 용
+  인그레스 컨트롤러이기도 하다.
+* [Istio 인그레스](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)는 [Istio](https://istio.io/)
+  기반 인그레스 컨트롤러다.
+* [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
+  구동하는 인그레스 컨트롤러다.
+* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary)
+  웹서버(프록시로 사용)와 함께 작동한다.
+* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
+* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
+  [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.
+* [Voyager](https://appscode.com/products/voyager)는
+  [HAProxy](http://www.haproxy.org/#desc)의 인그레스 컨트롤러다.

 ## 여러 인그레스 컨트롤러 사용

@ -73,3 +73,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의

 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
 * [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
+
--- a/content/ko/docs/concepts/services-networking/service.md
+++ b/content/ko/docs/concepts/services-networking/service.md
@ -201,10 +201,15 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만,

 ### 애플리케이션 프로토콜

-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}

-`AppProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
-이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스 리소스에 의해 미러링된다.
+`appProtocol` 필드는 각 서비스 포트에 대한 애플리케이션 프로토콜을 지정하는 방법을 제공한다.
+이 필드의 값은 해당 엔드포인트와 엔드포인트슬라이스 
+오브젝트에 의해 미러링된다.
+
+이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은 
+[IANA 표준 서비스 이름](http://www.iana.org/assignments/service-names) 또는
+`mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다.

 ## 가상 IP와 서비스 프록시

@ -576,21 +581,12 @@ status:

 외부 로드 밸런서의 트래픽은 백엔드 파드로 전달된다. 클라우드 공급자는 로드 밸런싱 방식을 결정한다.

-로드 밸런서 서비스 유형의 경우 두 개 이상의 포트가 정의된 경우,
-모든 포트의 프로토콜이 동일해야 하고, 프로토콜은 `TCP`, `UDP` 그리고
-`SCTP` 중 하나여야 한다.
-
 일부 클라우드 공급자는 `loadBalancerIP`를 지정할 수 있도록 허용한다. 이 경우, 로드 밸런서는
 사용자 지정 `loadBalancerIP`로 생성된다. `loadBalancerIP` 필드가 지정되지 않으면,
 임시 IP 주소로 loadBalancer가 설정된다. `loadBalancerIP`를 지정했지만
 클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 `loadbalancerIP` 필드는
 무시된다.

-{{< note >}}
-SCTP를 사용하는 경우, `LoadBalancer` 서비스 유형에 대한 아래의 [경고](#caveat-sctp-loadbalancer-service-type)를
-참고한다.
-{{< /note >}}
-
 {{< note >}}

 **Azure** 에서 사용자 지정 공개(public) 유형 `loadBalancerIP`를 사용하려면, 먼저
@ -602,7 +598,35 @@ SCTP를 사용하는 경우, `LoadBalancer` 서비스 유형에 대한 아래의

 {{< /note >}}

-#### 내부 로드 밸런서 {#internal-load-balancer}
+#### 프로토콜 유형이 혼합된 로드밸런서
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든 
+포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가 
+지원하는 프로토콜이어야 한다.
+
+kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
+
+{{< note >}}
+
+로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다.
+
+{{< /note >}}
+
+#### 로드밸런서 NodePort 할당 비활성화
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+v1.20부터는 `spec.allocateLoadBalancerNodePorts`필드를 `false`로 설정하여 서비스 Type=LoadBalancer에 
+대한 노드 포트 할당을 선택적으로 비활성화 할 수 있다.
+노드 포트를 사용하는 대신 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
+기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당한다.
+노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 않는다.
+이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
+이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다.
+
+#### 내부 로드 밸런서

 혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로
 라우팅해야 하는 경우가 있다.
@ -1182,6 +1206,36 @@ IPVS는 로드 밸런싱을 위해 설계되었고 커널-내부 해시 테이
 대부분의 서비스에 UDP를 사용할 수 있다. type=LoadBalancer 서비스의 경우, UDP 지원은
 이 기능을 제공하는 클라우드 공급자에 따라 다르다.

+### SCTP
+
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
+
+SCTP 트래픽을 지원하는 네트워크 플러그인을 사용하는 경우 대부분의 서비스에 SCTP를 사용할 수 있다. 
+type=LoadBalancer 서비스의 경우 SCTP 지원은 이 기능을 제공하는 
+클라우드 공급자에 따라 다르다. (대부분 그렇지 않음)
+
+#### 경고 {#caveat-sctp-overview}
+
+##### 멀티홈드(multihomed) SCTP 연결을 위한 지원 {#caveat-sctp-multihomed}
+
+{{< warning >}}
+멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
+
+멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다.
+{{< /warning >}}
+
+##### 윈도우 {#caveat-sctp-windows-os}
+
+{{< warning >}}
+SCTP는 윈도우 기반 노드를 지원하지 않는다.
+{{< /warning >}}
+
+##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace}
+
+{{< warning >}}
+kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
+{{< /warning >}}
+
 ### HTTP

 클라우드 공급자가 이를 지원하는 경우, LoadBalancer 모드의
@ -1209,42 +1263,6 @@ PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n

 클라이언트 데이터가 뒤따라온다.

-### SCTP
-
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
-쿠버네티스는 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 및 파드 정의에서 SCTP를 `protocol` 값으로 지원한다. 이 기능은 베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에서 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
-
-기능 게이트가 활성화되면, 서비스, 엔드포인트, 엔드포인트슬라이스, 네트워크폴리시 또는 파드의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. 쿠버네티스는 TCP 연결과 마찬가지로, SCTP 연결에 맞게 네트워크를 설정한다.
-
-#### 경고 {#caveat-sctp-overview}
-
-##### 멀티홈드(multihomed) SCTP 연결을 위한 지원 {#caveat-sctp-multihomed}
-
-{{< warning >}}
-멀티홈 SCTP 연결을 위해서는 먼저 CNI 플러그인이 파드에 대해 멀티 인터페이스 및 IP 주소 할당이 지원되어야 한다.
-
-멀티홈 SCTP 연결을 위한 NAT는 해당 커널 모듈 내에 특수한 로직을 필요로 한다.
-{{< /warning >}}
-
-##### type=LoadBalancer 서비스 {#caveat-sctp-loadbalancer-service-type}
-
-{{< warning >}}
-클라우드 공급자의 로드 밸런서 구현이 프로토콜로서 SCTP를 지원하는 경우에만 LoadBalancer `유형`과 SCTP `프로토콜`을 사용하여 서비스를 생성할 수 있다. 그렇지 않으면, 서비스 생성 요청이 거부된다. 현재 클라우드 로드 밸런서 공급자 세트 (Azure, AWS, CloudStack, GCE, OpenStack)는 모두 SCTP에 대한 지원이 없다.
-{{< /warning >}}
-
-##### 윈도우 {#caveat-sctp-windows-os}
-
-{{< warning >}}
-SCTP는 윈도우 기반 노드를 지원하지 않는다.
-{{< /warning >}}
-
-##### 유저스페이스 kube-proxy {#caveat-sctp-kube-proxy-userspace}
-
-{{< warning >}}
-kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지원하지 않는다.
-{{< /warning >}}
-
 ## {{% heading "whatsnext" %}}

 * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기
--- a/content/ko/docs/concepts/storage/persistent-volumes.md
+++ b/content/ko/docs/concepts/storage/persistent-volumes.md
@ -304,26 +304,35 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마

 퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다.

-* GCEPersistentDisk
-* AWSElasticBlockStore
-* AzureFile
-* AzureDisk
-* CSI
-* FC (파이버 채널)
-* FlexVolume
-* Flocker
-* NFS
-* iSCSI
-* RBD (Ceph Block Device)
-* CephFS
-* Cinder (OpenStack 블록 스토리지)
-* Glusterfs
-* VsphereVolume
-* Quobyte Volumes
-* HostPath (단일 노드 테스트 전용 – 로컬 스토리지는 어떤 방식으로도 지원되지 않으며 다중-노드 클러스터에서 작동하지 않음)
-* Portworx Volumes
-* ScaleIO Volumes
-* StorageOS
+* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS)
+* [`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 볼륨
+  (단일 노드 테스트 전용. 다중-노드 클러스터에서 작동하지 않음. 
+  대신 `로컬` 볼륨 사용 고려)
+* [`iscsi`](/ko/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 스토리지
+* [`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 볼륨

 ## 퍼시스턴트 볼륨

@ -717,12 +726,10 @@ spec:

 ## 볼륨 스냅샷 및 스냅샷 지원에서 볼륨 복원

-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}

-CSI 볼륨 플러그인만 지원하도록 볼륨 스냅샷 기능이 추가되었다. 자세한 내용은 [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)을 참고한다.
-
-볼륨 스냅샷 데이터 소스에서 볼륨 복원을 지원하려면 apiserver와 controller-manager에서
-`VolumeSnapshotDataSource` 기능 게이트를 활성화한다.
+볼륨 스냅 샷은 아웃-오브-트리 CSI 볼륨 플러그인만 지원한다. 자세한 내용은 [볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)을 참조한다.
+인-트리 볼륨 플러그인은 사용 중단 되었다. [볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)에서 사용 중단된 볼륨 플러그인에 대해 확인할 수 있다.

 ### 볼륨 스냅샷에서 퍼시스턴트볼륨클레임 생성 {#create-persistent-volume-claim-from-volume-snapshot}

--- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md
+++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md
@ -33,7 +33,7 @@ weight: 30
 생성된 이후에는 업데이트할 수 없다.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotClass
 metadata:
  name: csi-hostpath-snapclass
@ -47,7 +47,7 @@ parameters:
 기본 볼륨스냅샷클래스를 지정할 수 있다.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotClass
 metadata:
  name: csi-hostpath-snapclass
--- a/content/ko/docs/concepts/storage/volume-snapshots.md
+++ b/content/ko/docs/concepts/storage/volume-snapshots.md
@ -6,7 +6,6 @@ weight: 20

 <!-- overview -->

-{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다.


@ -30,7 +29,8 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및

 * API 오브젝트인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
 * `VolumeSnapshot` 은 CSI 드라이버에서만 사용할 수 있다.
-* 쿠버네티스 팀은 `VolumeSnapshot` 베타 버젼의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다.
+* 쿠버네티스 팀은 `VolumeSnapshot` 의 배포 프로세스 일부로써, 컨트롤 플레인에 배포할 스냅샷 컨트롤러와 CSI 드라이버와 함께 배포할 csi-snapshotter라는 사이드카 헬퍼(helper) 컨테이너를 제공한다. 스냅샷 컨트롤러는 `VolumeSnapshot` 및 `VolumeSnapshotContent` 오브젝트를 관찰하고 동적 프로비저닝에서 `VolumeSnapshotContent` 오브젝트의 생성 및 삭제를 할 수 있다.사이드카 csi-snapshotter는 `VolumeSnapshotContent` 오브젝트를 관찰하고 CSI 엔드포인트에 대해 `CreateSnapshot` 및 `DeleteSnapshot` 을 트리거(trigger)한다.
+* 스냅샷 오브젝트에 대한 강화된 검증을 제공하는 검증 웹훅 서버도 있다. 이는 CSI 드라이버가 아닌 스냅샷 컨트롤러 및 CRD와 함께 쿠버네티스 배포판에 의해 설치되어야 한다. 스냅샷 기능이 활성화된 모든 쿠버네티스 클러스터에 설치해야 한다.
 * CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다.
 * CRDs 및 스냅샷 컨트롤러는 쿠버네티스 배포 시 설치된다.

@ -71,7 +71,7 @@ API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이
 각각의 볼륨 스냅샷은 스펙과 상태를 포함한다.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshot
 metadata:
  name: new-snapshot-test
@ -90,7 +90,7 @@ spec:
 사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshot
 metadata:
  name: test-snapshot
@ -125,7 +125,7 @@ spec:
 사전 프로비저닝된 스냅샷의 경우, (클러스터 관리자로서) 다음과 같이 `VolumeSnapshotContent` 오브젝트를 작성해야 한다.

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1beta1
+apiVersion: snapshot.storage.k8s.io/v1
 kind: VolumeSnapshotContent
 metadata:
  name: new-snapshot-content-test
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@ -296,6 +296,12 @@ tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs
 작성하는 모든 파일이 컨테이너 메모리
 제한에 포함된다.

+{{< note >}}
+`SizeMemoryBackedVolumes` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우,
+메모리 기반 볼륨의 크기를 지정할 수 있다. 크기를 지정하지 않으면, 메모리
+기반 볼륨의 크기는 리눅스 호스트 메모리의 50%로 조정된다.
+{{< /note >}}
+
 #### emptyDir 구성 예시

 ```yaml
--- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
@ -28,8 +28,6 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 11자를 자동으로 추가하고, 작업 이름의 최대 길이는
 63자라는 제약 조건이 있기 때문이다.

-
-
 <!-- body -->

 ## 크론잡
@ -78,6 +76,14 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
 크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고,
 잡은 그 잡이 대표하는 파드 관리에 책임이 있다.

+## 새 컨트롤러
+
+쿠버네티스 1.20부터 알파 기능으로 사용할 수 있는 크론잡 컨트롤러의 대체 구현이 있다. 크론잡 컨트롤러의 버전 2를 선택하려면, 다음의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달한다.
+
+```
+--feature-gates="CronJobControllerV2=true"
+```
+

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

--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@ -81,12 +81,6 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.

-또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로
-레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋
-{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을
-막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을
-수동으로 생성하는 것이다.
-
 ### 오직 일부 노드에서만 파드 실행

 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@ -95,7 +95,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

  `.spec.replicas` 필드에 따라 의도한 레플리카의 수가 3개인지 알 수 있다.

-3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다.
+3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment/nginx-deployment` 를 실행한다.

   다음과 유사하게 출력된다.
   ```
@ -194,7 +194,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 2. 롤아웃 상태를 보려면 다음을 실행한다.

    ```shell
-    kubectl rollout status deployment.v1.apps/nginx-deployment
+    kubectl rollout status deployment/nginx-deployment
    ```

    이와 유사하게 출력된다.
@ -373,7 +373,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성


    ```shell
-    kubectl rollout status deployment.v1.apps/nginx-deployment
+    kubectl rollout status deployment/nginx-deployment
    ```

    이와 유사하게 출력된다.
@ -850,7 +850,7 @@ nginx-deployment-618515232    11        11        11        7m
 만약 롤아웃이 성공적으로 완료되면 `kubectl rollout status` 는 종료 코드로 0이 반환된다.

 ```shell
-kubectl rollout status deployment.v1.apps/nginx-deployment
+kubectl rollout status deployment/nginx-deployment
 ```
 이와 유사하게 출력된다.
 ```
--- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
@ -59,11 +59,22 @@ metadata:
 ```

 {{< note >}}
-교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다. 이는 다음을 의미한다.
-1) 네임스페이스 범위의 종속 항목은 동일한 네임스페이스의 소유자와
-클러스터 범위의 소유자만 지정할 수 있다.
-2) 클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있으며,
-네임스페이스 범위의 소유자는 불가하다.
+교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다.
+
+네임스페이스 종속 항목은 클러스터 범위 또는 네임스페이스 소유자를 지정할 수 있다.
+네임스페이스 소유자는 **반드시** 종속 항목과 동일한 네임스페이스에 있어야 한다.
+그렇지 않은 경우, 소유자 참조는 없는 것으로 처리되며, 소유자가 없는 것으로 확인되면
+종속 항목이 삭제될 수 있다.
+
+클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있다.
+v1.20 이상에서 클러스터 범위의 종속 항목이 네임스페이스 종류를 소유자로 지정하면,
+확인할 수 없는 소유자 참조가 있는 것으로 처리되고 가비지 수집이 될 수 없다.
+
+v1.20 이상에서 가비지 수집기가 잘못된 교차 네임스페이스 `ownerReference`
+또는 네임스페이스 종류를 참조하는 `ownerReference` 가 있는 클러스터 범위의 종속 항목을 감지하면,
+`OwnerRefInvalidNamespace` 의 원인이 있는 경고 이벤트와 유효하지 않은 종속 항목의 `involvedObject` 가 보고된다.
+`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` 를 실행하여
+이러한 종류의 이벤트를 확인할 수 있다.
 {{< /note >}}

 ## 가비지 수집기의 종속 항목 삭제 방식 제어
--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@ -255,7 +255,6 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
 ## {{% heading "whatsnext" %}}

 * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
-* [PodPresets](/ko/docs/concepts/workloads/pods/podpreset/)에 대해 알아본다.
 * [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
  다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
--- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
@ -87,7 +87,7 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
 {{< /note >}}

 이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
-보여준다. 일반적으로 `kubectl alpha debug` 또는
+보여준다. 일반적으로 `kubectl debug` 또는
 다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
 사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.

--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@ -316,7 +316,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지

 ### 언제 스타트업 프로브를 사용해야 하는가?

-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}

 스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
 파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@ -310,6 +310,7 @@ profiles:
            - maxSkew: 1
              topologyKey: topology.kubernetes.io/zone
              whenUnsatisfiable: ScheduleAnyway
+          defaultingType: List
 ```

 {{< note >}}
@ -322,9 +323,9 @@ profiles:

 #### 내부 기본 제약

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

-`DefaultPodTopologySpread` 기능 게이트를 활성화하면, 기존
+기본적으로 활성화된 `DefaultPodTopologySpread` 기능 게이트를 사용하면, 기존
 `SelectorSpread` 플러그인이 비활성화된다.
 kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
 기본 토폴로지 제약 조건을 사용한다.
@ -351,6 +352,22 @@ defaultConstraints:
 없는 노드에 점수를 매기지 않는다.
 {{< /note >}}

+클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,
+`PodTopologySpread` 플러그인 구성에서 `defaultingType` 을 `List` 로 설정하고
+`defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.
+
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+
+profiles:
+  - pluginConfig:
+      - name: PodTopologySpread
+        args:
+          defaultConstraints: []
+          defaultingType: List
+```
+
 ## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교

 쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가
--- a/content/ko/docs/concepts/workloads/pods/podpreset.md
+++ b/content/ko/docs/concepts/workloads/pods/podpreset.md
@ -1,89 +0,0 @@
---
-title: 파드 프리셋
-content_type: concept
-weight: 50
---
-
-<!-- overview -->
-{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-
-이 페이지는 파드프리셋(PodPreset)에 대한 개요를 제공한다. 파드프리셋은 파드 생성 시간에 파드에
-특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는
-시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다.
-
-
-
-<!-- body -->
-## 파드 프리셋 이해하기
-
-파드프리셋은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
-주입하기 위한 API 리소스이다.
-주어진 파드프리셋이 적용되도록 파드에 명시하기 위해서는
-[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다.
-
-파드프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
-제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드
-템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다.
-
-
-## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset}
-
-클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.
-
-1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
-   예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
-   minikube에서는 클러스터가 시작할 때
-   `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
-   플래그를 추가한다.
-1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
-   API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
-   minikube에서는 클러스터가 시작할 때
-
-   ```shell
-   --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
-   ```
-
-   플래그를 추가한다.
-
-## 어떻게 동작하는가
-
-쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면,
-파드 프리셋을 파드 생성 요청에 적용한다.
-파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다.
-
-1. 사용 가능한 모든 `PodPresets`을 검색한다.
-1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는
-   것이 있는지 확인한다.
-1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에
-   병합되도록 시도한다.
-1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로
-   부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다.
-1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서
-   수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다.
-    `podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`.
-
-각 파드는 0개 이상의 파드프리셋에 일치될 수 있고, 각 파드프리셋은 0개 이상의
-파드에 적용될 수 있다. 하나의 파드프리셋이 한 개 이상의 파드에 적용되었을
-때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `env`, `envFrom`, `volumeMounts`의
-변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
-수정한다. `volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.
-
-{{< note >}}
-파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다.
- `.spec.containers` 필드
- `.spec.initContainers` 필드
-{{< /note >}}
-
-### 특정 파드의 파드 프리셋 비활성화하기
-
-어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
-있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드의 `.spec` 에
-추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.
-
-
-
-## {{% heading "whatsnext" %}}
-
-[파드프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)를 본다.
-
-배경에 대한 자세한 정보를 위해서는, [파드프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 본다.
--- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
@ -48,6 +48,20 @@ weight: 50
 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.

+ 1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다.
+ 1. 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다.
+ 1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다.
+ 1. 파드에 API 접근을 위한 토큰이 포함된 `volume` 을 추가한다.
+ 1. `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
+
+#### 바인딩된 서비스 어카운트 토큰 볼륨
+{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+
+`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
+시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참고한다.
+
+이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 `RootCAConfigMap` 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.
+
 1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를
   `default`로 설정한다.
 1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면
--- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
@ -51,8 +51,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
 | `APIListChunking` | `false` | 알파 | 1.8 | 1.8 |
 | `APIListChunking` | `true` | 베타 | 1.9 | |
-| `APIPriorityAndFairness` | `false` | 알파 | 1.17 | |
+| `APIPriorityAndFairness` | `false` | 알파 | 1.17 | 1.19 |
+| `APIPriorityAndFairness` | `true` | 베타 | 1.20 | |
 | `APIResponseCompression` | `false` | 알파 | 1.7 | |
+| `APIServerIdentity` | `false` | 알파 | 1.20 | |
 | `AppArmor` | `true` | 베타 | 1.4 | |
 | `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | |
 | `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | |
@ -79,14 +81,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | |
 | `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
 | `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | |
+| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | |
 | `CSIStorageCapacity` | `false` | 알파 | 1.19 | |
-| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | |
-| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | |
+| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
+| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | |
+| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
+| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
+| `CronJobControllerV2` | `false` | 알파 | 1.20 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
-| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | |
+| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
+| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | |
+| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
+| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
 | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | 베타 | 1.10 | |
-| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.20 |
+| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 |
+| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | 1.22 |
+| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | |
 | `DryRun` | `false` | 알파 | 1.12 | 1.12 |
 | `DryRun` | `true` | 베타 | 1.13 | |
 | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
@ -94,7 +105,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | 베타 | 1.17 | |
 | `EndpointSlice` | `true` | 베타 | 1.18 | |
-| `EndpointSliceProxying` | `false` | 알파 | 1.18 | |
+| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | |
+| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
+| `EndpointSliceProxying` | `true` | 베타 | 1.19 | |
+| `EndpointSliceTerminating` | `false` | 알파 | 1.20 | |
 | `EphemeralContainers` | `false` | 알파 | 1.16 | |
 | `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | 베타 | 1.16 | |
@ -104,6 +118,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
 | `GenericEphemeralVolume` | `false` | 알파 | 1.19 | |
+| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | |
 | `HPAScaleToZero` | `false` | 알파 | 1.16 | |
 | `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
 | `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
@ -111,12 +126,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
 | `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | |
 | `IPv6DualStack` | `false` | 알파 | 1.16 | |
-| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
-| `KubeletPodResources` | `true` | 베타 | 1.15 | |
 | `LegacyNodeRoleBehavior` | `true` | 알파 | 1.16 | |
 | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
+| `MixedProtocolLBService` | `false` | 알파 | 1.20 | |
 | `MountContainers` | `false` | 알파 | 1.9 | |
 | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
 | `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | |
@ -124,10 +138,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
 | `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
 | `PodDisruptionBudget` | `true` | 베타 | 1.5 | |
-| `PodOverhead` | `false` | 알파 | 1.16 | - |
+| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
+| `PodOverhead` | `true` | 베타 | 1.18 |  |
 | `ProcMountType` | `false` | 알파 | 1.12 | |
 | `QOSReserved` | `false` | 알파 | 1.11 | |
 | `RemainingItemCount` | `false` | 알파 | 1.15 | |
+| `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 |
+| `RootCAConfigMap` | `true` | 베타 | 1.20 | |
 | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
 | `RunAsGroup` | `true` | 베타 | 1.14 | |
@ -137,32 +154,21 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `SCTPSupport` | `true` | 베타 | 1.19 | |
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | |
-| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
-| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
-| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
+| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | |
+| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.20 |
 | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
 | `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
 | `ServiceTopology` | `false` | 알파 | 1.17 | |
-| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | |
-| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
-| `StartupProbe` | `true` | 베타 | 1.18 | |
+| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | |
+| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
+| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | |
 | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | 베타 | 1.15 | |
-| `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 |
-| `SupportNodePidsLimit` | `true` | 베타 | 1.15 | |
-| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 |
-| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | |
 | `Sysctls` | `true` | 베타 | 1.11 | |
-| `TokenRequest` | `false` | 알파 | 1.10 | 1.11 |
-| `TokenRequest` | `true` | 베타 | 1.12 | |
-| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 |
-| `TokenRequestProjection` | `true` | 베타 | 1.12 | |
 | `TTLAfterFinished` | `false` | 알파 | 1.12 | |
 | `TopologyManager` | `false` | 알파 | 1.16 | |
 | `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
 | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
-| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 |
-| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | - |
 | `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | |
 | `WindowsGMSA` | `false` | 알파 | 1.14 | |
 | `WindowsGMSA` | `true` | 베타 | 1.16 | |
@ -177,12 +183,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | 기능     | 디폴트    | 단계   | 도입   | 종료   |
 |---------|---------|-------|-------|-------|
 | `Accelerators` | `false` | 알파 | 1.6 | 1.10 |
-| `Accelerators` | - | 사용 중단 | 1.11 | - |
+| `Accelerators` | - | 사용중단 | 1.11 | - |
 | `AdvancedAuditing` | `false` | 알파 | 1.7 | 1.7 |
 | `AdvancedAuditing` | `true` | 베타 | 1.8 | 1.11 |
 | `AdvancedAuditing` | `true` | GA | 1.12 | - |
 | `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 |
-| `AffinityInAnnotations` | - | 사용 중단 | 1.8 | - |
+| `AffinityInAnnotations` | - | 사용중단 | 1.8 | - |
 | `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 |
 | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
 | `BlockVolume` | `false` | 알파 | 1.9 | 1.12 |
@ -206,7 +212,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
 | `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
 | `CustomPodDNS` | `true` | GA | 1.14 | - |
-| `CustomResourceDefaulting` | `false` | 알파 | 1.15 | 1.15 |
+| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | 베타 | 1.16 | 1.16 |
 | `CustomResourceDefaulting` | `true` | GA | 1.17 | - |
 | `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 |
@ -222,30 +228,35 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 |
 | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
 | `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 |
-| `DynamicAuditing` | - | 사용 중단 | 1.19 | - |
+| `DynamicAuditing` | - | 사용중단 | 1.19 | - |
 | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
-| `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - |
+| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
 | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
 | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
 | `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 |
-| `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - |
+| `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - |
 | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
-| `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - |
+| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
 | `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
 | `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 |
 | `EvenPodsSpread` | `true` | GA | 1.19 | - |
+| `ExecProbeTimeout` | `true` | GA | 1.20 | - |
 | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | 알파 | 1.8 | 1.9 |
 | `HugePages` | `true` | 베타| 1.10 | 1.13 |
 | `HugePages` | `true` | GA | 1.14 | - |
 | `Initializers` | `false` | 알파 | 1.7 | 1.13 |
-| `Initializers` | - | 사용 중단 | 1.14 | - |
+| `Initializers` | - | 사용중단 | 1.14 | - |
 | `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 |
-| `KubeletConfigFile` | - | 사용 중단 | 1.10 | - |
+| `KubeletConfigFile` | - | 사용중단 | 1.10 | - |
+| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | 1.20 |
 | `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 |
 | `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 |
 | `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
+| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
+| `KubeletPodResources` | `true` | 베타 | 1.15 | |
+| `KubeletPodResources` | `true` | GA | 1.20 | |
 | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 |
 | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 |
 | `MountPropagation` | `true` | GA | 1.12 | - |
@ -265,36 +276,63 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 |
 | `PodShareProcessNamespace` | `true` | GA | 1.17 | - |
 | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
-| `PVCProtection` | - | 사용 중단 | 1.10 | - |
+| `PVCProtection` | - | 사용중단 | 1.10 | - |
 | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 |
 | `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 |
-| `ResourceLimitsPriorityFunction` | - | 사용 중단 | 1.19 | - |
+| `ResourceLimitsPriorityFunction` | - | 사용중단 | 1.19 | - |
 | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 |
 | `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 |
 | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
 | `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 |
 | `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
+| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
+| `RuntimeClass` | `true` | 베타 | 1.14 | 1.19 |
+| `RuntimeClass` | `true` | GA | 1.20 | - |
 | `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 |
 | `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16  |
 | `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
+| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
+| `SCTPSupport` | `true` | 베타 | 1.19 | 1.19 |
+| `SCTPSupport` | `true` | GA | 1.20 | - |
+| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
+| `ServiceAppProtocol` | `true` | GA | 1.20 | - |
 | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 |
 | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 |
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
+| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
+| `StartupProbe` | `true` | 베타 | 1.18 | 1.19 |
+| `StartupProbe` | `true` | GA | 1.20 | - |
 | `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 |
 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
 | `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
 | `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 |
-| `StreamingProxyRedirects` | - | 사용 중단| 1.19 | - |
+| `StreamingProxyRedirects` | - | 사용중단| 1.19 | - |
 | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 |
 | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 |
 | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 |
 | `SupportIPVSProxyMode` | `true` | GA | 1.11 | - |
+| `SupportNodePidsLimit` | `false` | 알파 | 1.14 | 1.14 |
+| `SupportNodePidsLimit` | `true` | 베타 | 1.15 | 1.19 |
+| `SupportNodePidsLimit` | `true` | GA | 1.20 | - |
+| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 |
+| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | 1.19 |
+| `SupportPodPidsLimit` | `true` | GA | 1.20 | - |
 | `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 |
 | `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 |
 | `TaintBasedEvictions` | `true` | GA | 1.18 | - |
 | `TaintNodesByCondition` | `false` | 알파 | 1.8 | 1.11 |
 | `TaintNodesByCondition` | `true` | 베타 | 1.12 | 1.16 |
 | `TaintNodesByCondition` | `true` | GA | 1.17 | - |
+| `TokenRequest` | `false` | 알파 | 1.10 | 1.11 |
+| `TokenRequest` | `true` | 베타 | 1.12 | 1.19 |
+| `TokenRequest` | `true` | GA | 1.20 | - |
+| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 |
+| `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 |
+| `TokenRequestProjection` | `true` | GA | 1.20 | - |
+| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 |
+| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 |
+| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - |
 | `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 |
 | `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 |
 | `VolumePVCDataSource` | `true` | GA | 1.18 | - |
@ -368,6 +406,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `APIListChunking`: API 클라이언트가 API 서버에서 (`LIST` 또는 `GET`) 리소스를 청크(chunks)로 검색할 수 있도록 한다.
 - `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
 - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
+- `APIServerIdentity`: 클러스터의 각 kube-apiserver에 ID를 할당한다.
 - `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다.
   자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다.
 - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
@ -380,10 +419,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
   자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
   참고한다.
 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
-   마이그레이션한다.
-   자세한 내용은 [서비스 어카운트 토큰 볼륨](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)을
+   마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 
+   확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 
+   `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
+   자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 
   확인한다.
 - `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다.
+-`CronJobControllerV2` : {{< glossary_tooltip text="크론잡" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
 - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
 - `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.
 - `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원) 문서를 참고한다.
@ -406,7 +448,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
  호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
  마운트할 수 있다.
-  자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
+- `CSIServiceAccountToken` : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록 CSI 드라이버를 활성화한다. [토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다.
 - `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
  자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
 - `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다.
@ -423,14 +465,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
  생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
  실행 중인 파드 문제를 해결한다.
- `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/).
+- `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/#액셀러레이터-메트릭-비활성화).
 - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
  기반 리소스 프로비저닝을 활성화한다.
 - `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
  [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
+- `DownwardAPIHugePages`: 다운워드 API에서 hugepages 사용을 활성화한다.
 - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
  요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
- `DynamicAuditing`: [동적 감사](/docs/tasks/debug-application-cluster/audit/#dynamic-backend) 기능을 활성화한다.
 - `DynamicAuditing`(*사용 중단됨*): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
 - `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다.
 - `DynamicProvisioningScheduling`: 볼륨 스케줄을 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다.
@ -441,6 +483,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `EphemeralContainers`: 파드를 실행하기 위한 {{< glossary_tooltip text="임시 컨테이너"
  term_id="ephemeral-container" >}}를 추가할 수 있다.
 - `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다.
+-`ExecProbeTimeout` : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다. 이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한 현재 수정된 결함에 의존하는 경우 존재한다. [준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다.
 - `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다. [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
 - `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다. [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다.
 - `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
@ -452,6 +495,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  재 매핑이 활성화된 경우에만 활성화해야 한다.
 - `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한
  엔드포인트 슬라이스를 활성화한다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
+-`EndpointSliceNodeName` : 엔드포인트슬라이스 `nodeName` 필드를 활성화한다.
+-`EndpointSliceTerminating` : 엔드포인트슬라이스 `terminating` 및 `serving` 조건 필드를
+   활성화한다.
 - `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, 리눅스에서 실행되는
  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
@ -462,6 +508,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
 - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
+-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown)을 참조한다.
 - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다.
 - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다.
 - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다.
@ -469,6 +516,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다.
 - `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다.
  자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다.
+- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
 - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
  플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
 - `KubeletPodResources`: kubelet의 파드 리소스 grpc 엔드포인트를 활성화한다.
@ -476,6 +524,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다.
 - `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다.
 - `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 `LocalStorageCapacityIsolation` 이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 파일시스템 사용보다는 프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다.
+- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다.
 - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
 - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
  자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
@ -503,6 +552,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진
  노드 사이의 관계를 끊는 것이다.
 - `ResourceQuotaScopeSelectors`: 리소스 쿼터 범위 셀렉터를 활성화한다.
+- `RootCAConfigMap`: 모든 네임 스페이스에 `kube-root-ca.crt`라는 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 게시하도록 kube-controller-manager를 구성한다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.
+   자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 참조한다.
 - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
  자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
 - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
@ -514,10 +565,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다.
 - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다.
 - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
+- `ServiceLBNodePortControl`: 서비스에서`spec.allocateLoadBalancerNodePorts` 필드를 활성화한다.
 - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
 - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다.
  "`alpha.service-controller.kubernetes.io/exclude-balancer`" 키 또는 `node.kubernetes.io/exclude-from-external-load-balancers` 로 레이블이 지정된 경우 노드를 제외할 수 있다.
 - `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다.
+- `SizeMemoryBackedVolumes`: kubelet 지원을 사용하여 메모리 백업 볼륨의 크기를 조정한다. 자세한 내용은 [volumes](/ko/docs/concepts/storage/volumes)를 참조한다.
 - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
 - `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다.
 - `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히
@ -529,6 +582,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다.
  자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다.
 - `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다.
+- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. 
 - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다.
  자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
 - `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다.
--- a/content/ko/docs/reference/glossary/kube-proxy.md
+++ b/content/ko/docs/reference/glossary/kube-proxy.md
@ -23,4 +23,5 @@ tags:
 세션이나 클러스터 바깥에서 파드로 네트워크 통신을
 할 수 있도록 해준다.

-kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
+kube-proxy는 운영 체제에 가용한 패킷 
+필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
--- a/content/ko/docs/reference/glossary/persistent-volume.md
+++ b/content/ko/docs/reference/glossary/persistent-volume.md
@ -0,0 +1,21 @@
+---
+title: 퍼시스턴트 볼륨(Persistent Volume)
+id: persistent-volume
+date: 2018-04-12
+full_link: /ko/docs/concepts/storage/persistent-volumes/
+short_description: >
+  클러스터의 스토리지를 구성하는 API 오브젝트이다. 보통은 개별 파드보다 수명이 긴 플러그 가능한 형태의 리소스로 제공한다.
+
+aka: 
+tags:
+- core-object
+- storage
+---
+ 클러스터의 스토리지를 나타내는 API 오브젝트이다. 보통은 개별 {{< glossary_tooltip text="파드" term_id="pod" >}}보다 수명이 긴 플러그 가능한 형태의 리소스로 제공한다.
+
+<!--more-->
+
+퍼시스턴트볼륨(PV)은 스토리지를 어떻게 제공하고 사용하는지를 추상화하는 API를 제공한다.
+PV는 스토리지를 미리 생성할 수 있는 경우에 사용한다(정적 프로비저닝). 
+온-디맨드 스토리지(동적 프로비저닝)가 필요한 경우에는 퍼시스턴트볼륨클레임(PVC)을 대신 사용한다.
+
--- a/content/ko/docs/reference/kubectl/cheatsheet.md
+++ b/content/ko/docs/reference/kubectl/cheatsheet.md
@ -305,9 +305,10 @@ mynamespace                                         # 특정 네임스페이스
 kubectl run nginx --image=nginx                     # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
 --dry-run=client -o yaml > pod.yaml

-kubectl attach my-pod -i                            # 실행중인 컨테이너에 연결
+kubectl attach my-pod -i                            # 실행 중인 컨테이너에 연결
 kubectl port-forward my-pod 5000:6000               # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달
 kubectl exec my-pod -- ls /                         # 기존 파드에서 명령 실행(한 개 컨테이너 경우)
+kubectl exec --stdin --tty my-pod -- /bin/sh        # 실행 중인 파드로 대화형 셸 액세스(1 컨테이너 경우)
 kubectl exec my-pod -c my-container -- ls /         # 기존 파드에서 명령 실행(멀티-컨테이너 경우)
 kubectl top pod POD_NAME --containers               # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
 ```
--- a/content/ko/docs/reference/kubectl/conventions.md
+++ b/content/ko/docs/reference/kubectl/conventions.md
@ -32,7 +32,7 @@ content_type: concept
 `--dry-run` 플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.

 {{< note >}}
-모든 `kubectl`의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 [목록](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
+모든 `kubectl run`의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 [목록](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators) 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
 {{< /note >}}

 #### 생성기
@ -58,5 +58,3 @@ content_type: concept
 ### `kubectl apply`

 * `kubectl apply`를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 [Kubectl 책](https://kubectl.docs.kubernetes.io)을 참고한다.
-
-
--- a/content/ko/docs/reference/kubectl/kubectl.md
+++ b/content/ko/docs/reference/kubectl/kubectl.md
@ -206,6 +206,13 @@ kubectl [flags]
 <td></td><td style="line-height: 130%; word-wrap: break-word;">지정된 경우, 해당 네임스페이스가 CLI 요청의 범위가 됨</td>
 </tr>

+<tr>
+<td colspan="2">--one-output</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">true이면, 로그를 기본 심각도 수준으로만 기록한다(그렇지 않으면 각각의 더 낮은 심각도 수준에도 기록함).</td>
+</tr>
+
 <tr>
 <td colspan="2">--password string</td>
 </tr>
@ -325,7 +332,6 @@ kubectl [flags]

 ## {{% heading "seealso" %}}

-* [kubectl alpha](/docs/reference/generated/kubectl/kubectl-commands#alpha)	 - 알파 기능에 대한 커맨드
 * [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate)	 - 리소스에 대한 어노테이션 업데이트
 * [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources)	 - 서버에서 지원되는 API 리소스 출력
 * [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions)	 - "그룹/버전" 형식으로 서버에서 지원되는 API 버전을 출력
@ -337,10 +343,10 @@ kubectl [flags]
 * [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info)	 - 클러스터 정보 표시
 * [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion)	 - 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드 출력
 * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)	 - kubeconfig 파일 수정
-* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert)	 - 다른 API 버전 간에 구성 파일 변환
 * [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon)	 - 노드를 unschedulable로 표시
 * [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp)	 - 컨테이너 간에 파일과 디렉터리 복사
 * [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create)	 - 파일 또는 표준 입력에서 리소스를 생성
+* [kubectl debug](/docs/reference/generated/kubectl/kubectl-commands#debug)	 - 워크로드와 노드의 문제 해결을 위한 디버깅 세션 생성
 * [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete)	 - 파일명, 표준 입력, 리소스 및 이름, 또는 리소스 및 레이블 셀렉터로 리소스 삭제
 * [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe)	 - 특정 리소스 또는 리소스 그룹의 세부 정보를 표시
 * [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff)	 - 적용 예정 버전과 라이브 버전 비교
@ -354,7 +360,7 @@ kubectl [flags]
 * [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label)	 - 리소스의 레이블 업데이트
 * [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs)	 - 파드의 컨테이너에 대한 로그 출력
 * [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options)	 - 모든 커맨드에서 상속된 플래그 목록을 출력
-* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch)	 - 전략적 병합 패치를 사용하여 리소스 필드를 업데이트
+* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch)	 - 리소스 필드를 업데이트
 * [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin)	 - 플러그인과 상호 작용하기 위한 유틸리티를 제공
 * [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward)	 - 하나 이상의 로컬 포트를 파드로 전달
 * [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy)	 - 쿠버네티스 API 서버에 대한 프록시 실행
--- a/content/ko/docs/setup/production-environment/container-runtimes.md
+++ b/content/ko/docs/setup/production-environment/container-runtimes.md
@ -119,7 +119,7 @@ sudo apt-get update && sudo apt-get install -y containerd.io
 ```shell
 # containerd 구성
 sudo mkdir -p /etc/containerd
-sudo containerd config default > /etc/containerd/config.toml
+sudo containerd config default | sudo tee /etc/containerd/config.toml
 ```

 ```shell
@ -161,10 +161,10 @@ sudo systemctl restart containerd
 {{% /tab %}}
 {{% tab name="Windows (PowerShell)" %}}
 ```powershell
-# (Install containerd)
-# download containerd
-cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.0-beta.2/containerd-1.4.0-beta.2-windows-amd64.tar.gz
-cmd /c tar xvf .\containerd-1.4.0-beta.2-windows-amd64.tar.gz
+# (containerd 설치)
+# containerd 다운로드
+cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.1/containerd-1.4.1-windows-amd64.tar.gz
+cmd /c tar xvf .\containerd-1.4.1-windows-amd64.tar.gz
 ```

 ```shell
--- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@ -8,8 +8,6 @@ weight: 65

 윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다. [윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) 사례를 더욱 쉽게 사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. 쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, 쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로, 운영 체제와 관계없이 배포 전반에 걸쳐 운영 효율성이 향상된다.

-
-
 <!-- body -->

 ## 쿠버네티스의 윈도우 컨테이너
@ -36,12 +34,10 @@ weight: 65

 | 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
 | --- | --- | --- | --- |
-| *Kubernetes v1.14* | Windows Server 2019 | Windows Server ver 1809 |
-| *Kubernetes v1.15* | Windows Server 2019 | Windows Server ver 1809 |
-| *Kubernetes v1.16* | Windows Server 2019 | Windows Server ver 1809 |
 | *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 |
 | *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 |
 | *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
+| *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |

 {{< note >}}
 지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 [윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다.
@ -56,6 +52,10 @@ weight: 65
 프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, [여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/version-compatibility). 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, 제한 및 호환성 규칙이 변경될 것이다.
 {{< /note >}}

+#### 퍼즈(Pause) 이미지
+
+Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 윈도우 퍼즈 인프라 컨테이너를 유지한다.
+
 #### 컴퓨트

 API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 [제한 섹션](#제한)에 요약된 주요 기능에는 몇 가지 눈에 띄는 차이점이 있다.
@ -114,23 +114,22 @@ Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장

 ##### CRI-ContainerD

-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}

-{{< caution >}}
-커널 패치가 필요한 윈도우 네트워크 공유에 접근하기 위해 ContainerD와 함께 GMSA를 사용할 때 [알려진 제한](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)이 있다. [Microsoft 윈도우 컨테이너 이슈 트래커](https://github.com/microsoft/Windows-Containers/issues/44)에서 업데이트를 확인한다.
-{{< /caution >}}
-
-{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0-beta.2+는 윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다.
-
-쿠버네티스 v1.18은 윈도우에서 ContainerD에 대한 초기 지원을 추가한다. 윈도우에서 ContainerD의 진행 상황은 [enhancements#1001](https://github.com/kubernetes/enhancements/issues/1001)에서 확인할 수 있다.
+{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+는 윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다.

 [윈도우에 ContainerD 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치) 방법을 확인한다.

+{{< caution >}}
+ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 네트워크 공유에 액세스 할 때 [알려진 제한](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)이 있다. 이 제한을 해결하기위한 업데이트는 현재 Windows Server, 버전 2004에서 사용할 수 있으며 2021년 초에 Windows Server 2019에서 사용할 수 있다. [Microsoft 윈도우 컨테이너 이슈 트래커](https://github.com/microsoft/Windows-Containers/issues/44)에서 업데이트를 확인한다.
+{{< /caution >}}
+
 #### 퍼시스턴트 스토리지(Persistent Storage)

 쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/)을 사용하면 데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 프로토콜에 대해 이러한 볼륨 관리 작업을 구현하는 코드는 쿠버네티스 볼륨 [플러그인](/ko/docs/concepts/storage/volumes/#볼륨-유형들)의 형태로 제공된다. 다음과 같은 광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다.

 ##### 인-트리(In-tree) 볼륨 플러그인
+
 인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 배포할 필요가 없다. 이러한 플러그인들은 볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다.

 * [awsElasticBlockStore](/ko/docs/concepts/storage/volumes/#awselasticblockstore)
@ -140,6 +139,7 @@ Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장
 * [vsphereVolume](/ko/docs/concepts/storage/volumes/#vspherevolume)

 ##### FlexVolume 플러그인
+
 [FlexVolume](/ko/docs/concepts/storage/volumes/#flexVolume) 플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 프로비저너를 통해 처리될 수 있다. 호스트에서 powershell 스크립트로 배포된 다음의 FlexVolume [플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 윈도우 노드를 지원한다.

 * [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
@ -147,7 +147,7 @@ Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장

 ##### CSI 플러그인

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

 {{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) 및 스테이트풀셋(StatefulSets)과 같은 표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 플러그인으로 구성된다.

@ -170,6 +170,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 * ExternalName

 ##### 네트워크 모드
+
 윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 각 CNI 사용 시 권장 사항이 있다.

 | 네트워크 드라이버 | 설명 | 컨테이너 패킷 수정 | 네트워크 플러그인 | 네트워크 플러그인 특성 |
@ -180,7 +181,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 | Transparent([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)의 특수한 유스케이스) | 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 연결된다. | 패킷은 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 또는 [STT](https://datatracker.ietf.org/doc/draft-davie-stt)를 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다. <br/> 패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다. <br/> NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [ansible을 통해 배포](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)한다. 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 iptables/netsh를 사용하지 않고 수행된다. |
 | NAT(*쿠버네티스에서 사용되지 않음*) | 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/)라는 내부 컴포넌트를 사용하여 제공된다. | MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 완전성을 위해 여기에 포함되었다. |

-위에서 설명한대로 [플라넬(Flannel)](https://github.com/coreos/flannel) CNI [메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 [VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**alpha 지원**, win-overlay에 위임) 및 [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (안정적인 지원, win-bridge에 위임)를 통해 [윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다.
+위에서 설명한대로 [플란넬(Flannel)](https://github.com/coreos/flannel) CNI [메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 [VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**alpha 지원**, win-overlay에 위임) 및 [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (안정적인 지원, win-bridge에 위임)를 통해 [윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다.

 노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다.

@ -194,7 +195,8 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 * 노드 -> 파드
 * 파드 -> 노드

-##### IP 주소 관리(IPAM) {#ipam}
+##### IP 주소 관리(IPAM)
+
 윈도우에서는 다음 IPAM 옵션이 지원된다.

 * [호스트-로컬](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
@ -215,10 +217,11 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 {{< /table >}}

 #### IPv4/IPv6 이중 스택
+
 `IPv6DualStack` [기능 게이트](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)을 참조한다.

 {{< note >}}
-윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 vNext Insider Preview Build 19603 이상이 필요하다.
+윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다.
 {{< /note >}}

 {{< note >}}
@ -243,7 +246,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템

 ##### 기능 제한

-* TerminationGracePeriod: 구현되지 않음
+* TerminationGracePeriod: CRI-containerD 필요
 * 단일 파일 매핑: CRI-ContainerD로 구현 예정
 * 종료 메시지: CRI-ContainerD로 구현 예정
 * 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음
@ -267,12 +270,13 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 * MemoryPressure 조건은 구현되지 않았다.
 * kubelet이 취한 OOM 축출 조치가 없다.
 * 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. `--kubelet-reserve`와 `--system-reserve`는 호스트에서 실행되는 kubelet 또는 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 의미한다.
+* kubelet 프로세스의 우선 순위를 설정하는 추가 플래그는 `--windows-priorityclass`라는 윈도우 노드에서 사용할 수 있다. 이 플래그를 사용하면 kubelet 프로세스가 윈도우 호스트에서 실행중인 다른 프로세스와 비교할 때 더 많은 CPU 시간 슬라이스을 얻을 수 있다. 허용되는 값과 그 의미에 대한 자세한 내용은 [윈도우 우선순위 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 확인할 수 있다. kubelet이 항상 충분한 CPU주기를 갖도록 하려면 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정하는 것이 좋다.

 #### 스토리지

 윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 해당 컨테이너의 컨텍스트 내에서만 확인된다.

-* 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉터리만 대상으로 할 수 있다.
+* 도커 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉토리 만 대상으로 할 수 있다. 이 제한은 CRI-containerD에는 존재하지 않는다.
 * 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 투영할 수 없다.
 * 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 볼륨은 지원된다.
 * 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 권한은 컨테이너 컨텍스트 내에서 해결된다.
@ -329,10 +333,11 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 * 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 `Resolve-DNSName` 유틸리티를 사용하는 것이 좋다.

 ##### IPv6
+
 윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. 그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 지원된다. 자세한 내용은 [IPv4/IPv6 이중 스택 네트워킹](#ipv4ipv6-이중-스택)을 참고한다.

-
 ##### 세션 어피니티(affinity)
+
 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 사용하는 윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다.

 ##### 보안
@ -342,7 +347,7 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템
 1. 파일 ACL을 사용하여 시크릿 파일 위치를 보호한다.
 2. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용한 볼륨-레벨 암호화를 사용한다.

-[RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)는 현재 윈도우에서 지원되지 않는다. 해결 방법(workaround)은 컨테이너를 패키징하기 전에 로컬 계정을 만드는 것이다. RunAsUsername 기능은 향후 릴리스에 추가될 수 있다.
+[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername)은 컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는 컨테이너에 지정할 수 있다. 이것은 [RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)와 거의 동일하다.

 SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다.

@ -464,9 +469,9 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
        nssm start flanneld

        # kubelet.exe 등록
-        # Microsoft는 mcr.microsoft.com/k8s/core/pause:1.2.0에서 pause 인프라 컨테이너를 릴리스했다.
+        # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다.
        nssm install kubelet C:\k\kubelet.exe
-        nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/k8s/core/pause:1.2.0 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
+        nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
        nssm set kubelet AppDirectory C:\k
        nssm start kubelet

@ -528,7 +533,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
    C:\k\kube-proxy.exe --hostname-override=$(hostname)
    ```

-1. 플라넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다.
+1. 플란넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다.

    이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 이전 파드 서브넷 구성 파일을 제거해야 한다.

@ -548,7 +553,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를

 1. `/run/flannel/subnet.env` 누락으로 인해 윈도우 파드를 시작할 수 없다.

-    이것은 플라넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 `/run/flannel/subnet.env`에서 윈도우 워커 노드의 `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다.
+    이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 `/run/flannel/subnet.env`에서 윈도우 워커 노드의 `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다.

    ```env
    FLANNEL_NETWORK=10.244.0.0/16
@ -576,15 +581,13 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를

    pause 이미지가 OS 버전과 호환되는지 확인한다. [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다.

-    쿠버네티스 v1.14부터 Microsoft는 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 pause 인프라 컨테이너를 릴리스한다.
-
 1. DNS 확인(resolution)이 제대로 작동하지 않는다.

    이 [섹션](#dns-limitations)에서 윈도우에 대한 DNS 제한을 확인한다.

 1. `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.

-    이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/k8s/core/pause:1.2.0`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다.
+    이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다.
    자체 pause 인프라 컨테이너를 빌드하려면 [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다.

 1. 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 설치가 실패한다.
@ -600,7 +603,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를

    쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다.

-    "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다.
+    "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다.

 ### 추가 조사

@ -622,11 +625,8 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
 * [관련 로그](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
 * SIG-Windows 회원의 주의를 끌 수 있도록 `/sig windows`로 이슈에 대해 어노테이션을 달아 이슈에 sig/windows 태그를 지정한다.

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

-
 로드맵에는 많은 기능이 있다. 요약된 높은 수준의 목록이 아래에 포함되어 있지만, [로드맵 프로젝트](https://github.com/orgs/kubernetes/projects/8)를 보고 [기여](https://github.com/kubernetes/community/blob/master/sig-windows/)하여 윈도우 지원을 개선하는데 도움이 주는 것이 좋다.

 ### Hyper-V 격리(isolation)
@ -638,31 +638,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
 * 파드에 대한 특정 CPU/NUMA 설정
 * 메모리 격리 및 예약

-v1.10의 실험적(experimental) 기능인 기존 Hyper-V 격리 지원은 위에서 언급한 CRI-ContainerD와 런타임클래스(RuntimeClass) 기능을 위해 향후 사용 중단(deprecated)된다. 현재 기능을 사용하고 Hyper-V 격리된 컨테이너를 만들려면, kubelet을 기능 게이트(feature gates) `HyperVContainer=true`로 시작해야 하고 파드에 `experimental.windows.kubernetes.io/isolation-type=hyperv` 어노테이션을 포함해야 한다. 실험 릴리스에서 이 기능은 파드 당 컨테이너 1개로 제한된다.
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: iis
-spec:
-  selector:
-    matchLabels:
-      app: iis
-  replicas: 3
-  template:
-    metadata:
-      labels:
-        app: iis
-      annotations:
-        experimental.windows.kubernetes.io/isolation-type: hyperv
-    spec:
-      containers:
-      - name: iis
-        image: microsoft/iis
-        ports:
-        - containerPort: 80
-```
+Hyper-V 격리 지원은 이후 릴리스에 추가되며 CRI-Containerd가 필요하다.

 ### kubeadm 및 클러스터 API를 사용한 배포

@ -671,8 +647,3 @@ Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사
 [여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다.
 또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에
 투자하고 있다.
-
-### 몇 가지 기타 주요 기능
-* 그룹 관리 서비스 어카운트(Service Accounts)에 대한 베타 지원
-* 더 많은 CNI
-* 더 많은 스토리지 플러그인
--- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
@ -177,7 +177,7 @@ tolerations:
 1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS, 아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되었다.

 ```yaml
-apiVersion: node.k8s.io/v1beta1
+apiVersion: node.k8s.io/v1
 kind: RuntimeClass
 metadata:
  name: windows-2019
--- a/content/ko/docs/tasks/administer-cluster/highly-available-master.md
+++ b/content/ko/docs/tasks/administer-cluster/highly-available-master.md
@ -169,8 +169,39 @@ Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있
 etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용).
 이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다.

+### API 서버 신원
+
+{{< feature-state state="alpha"  for_k8s_version="v1.20" >}}
+
+API 서버 식별 기능은
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
+의해 제어되며 기본적으로 활성화되지 않는다.
+{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
+시작 시 `APIServerIdentity` 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다.
+
+```shell
+kube-apiserver \
+--feature-gates=APIServerIdentity=true \
+ # …다른 플래그는 평소와 같다.
+```
+
+부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는
+`kube-apiserver-{UUID}` 형식이다. 각 kube-apiserver는
+_kube-system_ {{< glossary_tooltip text="네임스페이스" term_id="namespace">}}에
+[임대](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)를 생성한다.
+임대 이름은 kube-apiserver의 고유 ID이다. 임대에는
+`k8s.io/component=kube-apiserver` 라는 레이블이 있다. 각 kube-apiserver는
+`IdentityLeaseRenewIntervalSeconds` (기본값은 10초)마다 임대를 새로 갱신한다. 각
+kube-apiserver는 `IdentityLeaseDurationSeconds` (기본값은 3600초)마다
+모든 kube-apiserver 식별 ID 임대를 확인하고,
+`IdentityLeaseDurationSeconds` 이상 갱신되지 않은 임대를 삭제한다.
+`IdentityLeaseRenewIntervalSeconds` 및 `IdentityLeaseDurationSeconds`는
+kube-apiserver 플래그 `identity-lease-renew-interval-seconds`
+및 `identity-lease-duration-seconds`로 구성된다.
+
+이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을
+사용하기 위한 전제조건이다(예: `StorageVersionAPI` 기능 게이트).
+
 ## 추가 자료

 [자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
-
-
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@ -135,31 +135,91 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow


 ### 윈도우 워커 노드 조인(joining)
-{{< note >}}
-`Containers` 기능을 설치하고 도커를 설치해야 한다.
-[윈도우 서버에 Docker Engine - Enterprise 설치](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 설치에 대한 내용을 참고할 수 있다.
-{{< /note >}}

 {{< note >}}
 윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의
 높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다.
 {{< /note >}}

-1. wins, kubelet 및 kubeadm 설치
+{{< tabs name="tab-windows-kubeadm-runtime-installation" >}}
+{{% tab name="Docker EE" %}}
+
+#### Docker EE 설치
+
+`컨테이너` 기능 설치
+
+```powershell
+Install-WindowsFeature -Name containers
+```
+
+도커 설치
+자세한 내용은 [도커 엔진 설치 - 윈도우 서버 엔터프라이즈](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 확인할 수 있다.
+
+#### wins, kubelet 및 kubeadm 설치

   ```PowerShell
   curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
   .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
   ```

-1. 노드에 조인하기 위해 `kubeadm` 실행
+#### `kubeadm` 실행하여 노드에 조인
+
+컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
+이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
+(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.
+
+{{% /tab %}}
+{{% tab name="CRI-containerD" %}}
+
+#### containerD 설치
+
+```powershell
+curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1
+.\Install-Containerd.ps1
+```
+
+{{< note >}}
+특정 버전의 containerD를 설치하려면 -ContainerDVersion를 사용하여 버전을 지정한다.
+
+```powershell
+# 예
+.\Install-Containerd.ps1 -ContainerDVersion v1.4.1
+```
+
+{{< /note >}}
+
+{{< note >}}
+윈도우 노드에서 이더넷(예: "Ethernet0 2")이 아닌 다른 인터페이스를 사용하는 경우, `-netAdapterName` 으로 이름을 지정한다.
+
+```powershell
+# 예
+.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2"
+```
+
+{{< /note >}}
+
+#### wins, kubelet 및 kubeadm 설치
+
+```PowerShell
+curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
+```
+
+#### `kubeadm` 실행하여 노드에 조인

    컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다.
    이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command`
    (컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다.

+{{< note >}}
+**CRI-containerD** 를 사용하는 경우 kubeadm 호출에 `--cri-socket "npipe:////./pipe/containerd-containerd"` 를 추가한다
+{{< /note >}}
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### 설치 확인

-#### 설치 확인
 이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다.

 ```bash
@ -175,9 +235,6 @@ kubectl -n kube-system get pods -l app=flannel

 flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드를 처리할 수 있어야 한다.

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

-
 - [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
@ -50,7 +50,7 @@ CA 키없이 진행한다.
 `check-expiration` 하위 명령을 사용하여 인증서가 만료되는 시기를 확인할 수 있다.

 ```
-kubeadm alpha certs check-expiration
+kubeadm certs check-expiration
 ```

 출력 결과는 다음과 비슷하다.
@ -118,7 +118,7 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서

 ## 수동 인증서 갱신

-`kubeadm alpha certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
+`kubeadm certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.

 이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.

@ -127,10 +127,10 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
 {{< /warning >}}

 {{< note >}}
-`alpha certs renew` 는 기존 인증서를 kubeadm-config 컨피그맵(ConfigMap) 대신 속성(공통 이름, 조직, SAN 등)의 신뢰할 수 있는 소스로 사용한다. 둘 다 동기화 상태를 유지하는 것을 강력히 권장한다.
+`certs renew` 는 기존 인증서를 kubeadm-config 컨피그맵(ConfigMap) 대신 속성(공통 이름, 조직, SAN 등)의 신뢰할 수 있는 소스로 사용한다. 둘 다 동기화 상태를 유지하는 것을 강력히 권장한다.
 {{< /note >}}

-`kubeadm alpha certs renew` 는 다음의 옵션을 제공한다.
+`kubeadm certs renew` 는 다음의 옵션을 제공한다.

 쿠버네티스 인증서는 일반적으로 1년 후 만료일에 도달한다.

@ -168,14 +168,14 @@ controllerManager:

 ### 인증서 서명 요청(CSR) 생성

-`kubeadm alpha certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.
+`kubeadm certs renew --use-api` 로 쿠버네티스 인증서 API에 대한 인증서 서명 요청을 만들 수 있다.

 [cert-manager](https://github.com/jetstack/cert-manager)와 같은 외부 서명자를 설정하면, 인증서 서명 요청(CSR)이 자동으로 승인된다.
 그렇지 않으면, [`kubectl certificate`](/ko/docs/setup/best-practices/certificates/) 명령을 사용하여 인증서를 수동으로 승인해야 한다.
 다음의 kubeadm 명령은 승인할 인증서 이름을 출력한 다음, 승인이 발생하기를 차단하고 기다린다.

 ```shell
-sudo kubeadm alpha certs renew apiserver --use-api &
+sudo kubeadm certs renew apiserver --use-api &
 ```
 출력 결과는 다음과 비슷하다.
 ```
@ -209,13 +209,13 @@ kubeadm 관점에서, 일반적으로 온-디스크(on-disk) CA에 의해 서명

 ### 인증서 서명 요청(CSR) 생성

-`kubeadm alpha certs renew --csr-only` 로 인증서 서명 요청을 만들 수 있다.
+`kubeadm certs renew --csr-only` 로 인증서 서명 요청을 만들 수 있다.

 CSR과 함께 제공되는 개인 키가 모두 출력된다.
 `--csr-dir` 로 사용할 디텍터리를 전달하여 지정된 위치로 CSR을 출력할 수 있다.
 `--csr-dir` 을 지정하지 않으면, 기본 인증서 디렉터리(`/etc/kubernetes/pki`)가 사용된다.

-`kubeadm alpha certs renew --csr-only` 로 인증서를 갱신할 수 있다.
+`kubeadm certs renew --csr-only` 로 인증서를 갱신할 수 있다.
 `kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다.

 CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다.
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
@ -2,22 +2,22 @@
 title: kubeadm 클러스터 업그레이드
 content_type: task
 weight: 20
-min-kubernetes-server-version: 1.19
 ---

 <!-- overview -->

 이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를
-1.18.x 버전에서 1.19.x 버전으로, 1.19.x 버전에서 1.19.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.
+{{< skew latestVersionAddMinor -1 >}}.x 버전에서 {{< skew latestVersion >}}.x 버전으로,
+{{< skew latestVersion >}}.x 버전에서 {{< skew latestVersion >}}.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다.  업그레이드가 지원되지 않는 경우
+마이너 버전을 건너뛴다.

 이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면,
 이 페이지 대신 다음의 페이지들을 참고한다.

- [kubeadm 클러스터를 1.17에서 1.18로 업그레이드](https://v1-18.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
- [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/)
- [kubeadm 클러스터를 1.13에서 1.14로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/)
+- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -2 >}}에서 {{< skew latestVersionAddMinor -1 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -3 >}}에서 {{< skew latestVersionAddMinor -2 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -4 >}}에서 {{< skew latestVersionAddMinor -3 >}}로 업그레이드](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
+- [kubeadm 클러스터를 {{< skew latestVersionAddMinor -5 >}}에서 {{< skew latestVersionAddMinor -4 >}}으로 업그레이드](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)

 추상적인 업그레이드 작업 절차는 다음과 같다.

@ -27,60 +27,63 @@ min-kubernetes-server-version: 1.19

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

- 1.18.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다.
- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다.
 - [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다.
+- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다.
 - 데이터베이스에 저장된 앱-레벨 상태와 같은 중요한 컴포넌트를 반드시 백업한다.
  `kubeadm upgrade` 는 워크로드에 영향을 미치지 않고, 쿠버네티스 내부의 컴포넌트만 다루지만, 백업은 항상 모범 사례일 정도로 중요하다.
+- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).

 ### 추가 정보

+- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)이
+  필요하다. 컨트롤 플레인 노드의 경우 CoreNDS 파드 또는 기타 중요한 워크로드를 실행할 수 있다.
 - 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다.
- 하나의 MINOR 버전에서 다음 MINOR 버전으로,
-  또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다.
-  예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다.

 <!-- steps -->

 ## 업그레이드할 버전 결정

-최신의 안정 버전인 1.19를 찾는다.
+OS 패키지 관리자를 사용하여 최신의 안정 버전({{< skew latestVersion >}})을 찾는다.

 {{< tabs name="k8s_install_versions" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
    apt update
    apt-cache madison kubeadm
-    # 목록에서 최신 버전 1.19를 찾는다
-    # 1.19.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
+    # 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
+    # {{< skew latestVersion >}}.x-00과 같아야 한다. 여기서 x는 최신 패치이다.
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
    yum list --showduplicates kubeadm --disableexcludes=kubernetes
-    # 목록에서 최신 버전 1.19를 찾는다
-    # 1.19.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
+    # 목록에서 최신 버전({{< skew latestVersion >}})을 찾는다
+    # {{< skew latestVersion >}}.x-0과 같아야 한다. 여기서 x는 최신 패치이다.
 {{% /tab %}}
 {{< /tabs >}}

 ## 컨트롤 플레인 노드 업그레이드

-### 첫 번째 컨트롤 플레인 노드 업그레이드
+컨트롤 플레인 노드의 업그레이드 절차는 한 번에 한 노드씩 실행해야 한다.
+먼저 업그레이드할 컨트롤 플레인 노드를 선택한다. `/etc/kubernetes/admin.conf` 파일이 있어야 한다.

-  첫 번째 컨트롤 플레인 노드에서 kubeadm을 업그레이드한다.
+### "kubeadm upgrade" 호출
+
+**첫 번째 컨트롤 플레인 노드의 경우**
+
+-  kubeadm 업그레이드

 {{< tabs name="k8s_install_kubeadm_first_cp" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.19.x-00에서 x를 최신 패치 버전으로 바꾼다.
+    # {{< skew latestVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다.
    apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
+    apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
    apt-mark hold kubeadm
    -
    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
+    apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다.
-    yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
+    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다.
+    yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}

@ -90,63 +93,10 @@ min-kubernetes-server-version: 1.19
    kubeadm version
    ```

-  컨트롤 플레인 노드를 드레인(drain)한다.
+-  업그레이드 계획을 확인한다.

    ```shell
-    # <cp-node-name>을 컨트롤 플레인 노드 이름으로 바꾼다.
-    kubectl drain <cp-node-name> --ignore-daemonsets
-    ```
-
-  컨트롤 플레인 노드에서 다음을 실행한다.
-
-    ```shell
-    sudo kubeadm upgrade plan
-    ```
-
-    다음과 비슷한 출력이 표시되어야 한다.
-
-    ```
-    [upgrade/config] Making sure the configuration is correct:
-    [upgrade/config] Reading configuration from the cluster...
-    [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
-    [preflight] Running pre-flight checks.
-    [upgrade] Running cluster health checks
-    [upgrade] Fetching available versions to upgrade to
-    [upgrade/versions] Cluster version: v1.18.4
-    [upgrade/versions] kubeadm version: v1.19.0
-    [upgrade/versions] Latest stable version: v1.19.0
-    [upgrade/versions] Latest version in the v1.18 series: v1.19.0
-
-    Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
-    COMPONENT   CURRENT             AVAILABLE
-    Kubelet     1 x v1.18.4         v1.19.0
-
-    Upgrade to the latest version in the v1.18 series:
-
-    COMPONENT            CURRENT   AVAILABLE
-    API Server           v1.18.4   v1.19.0
-    Controller Manager   v1.18.4   v1.19.0
-    Scheduler            v1.18.4   v1.19.0
-    Kube Proxy           v1.18.4   v1.19.0
-    CoreDNS              1.6.7     1.7.0
-    Etcd                 3.4.3-0   3.4.7-0
-
-    You can now apply the upgrade by executing the following command:
-
-        kubeadm upgrade apply v1.19.0
-
-    _____________________________________________________________________
-
-    아래 표는 이 버전의 kubeadm에서 이해하는 컴포넌트 구성의 현재 상태를 보여준다.
-    "MANUAL UPGRADE REQUIRED" 열에 "yes" 표시가 있는 구성은 성공적인 업그레이드를
-    수행하기 전에 수동 구성 업그레이드 또는 kubeadm 기본값으로 재설정이 필요하다. 수동으로
-    업그레이드할 버전은 "PREFERRED VERSION" 열에 표시된다.
-
-    API GROUP                 CURRENT VERSION   PREFERRED VERSION   MANUAL UPGRADE REQUIRED
-    kubeproxy.config.k8s.io   v1alpha1          v1alpha1            no
-    kubelet.config.k8s.io     v1beta1           v1beta1             no
-    _____________________________________________________________________
-
+    kubeadm upgrade plan
    ```

    이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다.
@ -168,90 +118,13 @@ min-kubernetes-server-version: 1.19

    ```shell
    # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다.
-    sudo kubeadm upgrade apply v1.19.x
+    sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x
    ```

-
-    다음과 비슷한 출력이 표시되어야 한다.
+    명령이 완료되면 다음을 확인해야 한다.

    ```
-    [upgrade/config] Making sure the configuration is correct:
-    [upgrade/config] Reading configuration from the cluster...
-    [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
-    [preflight] Running pre-flight checks.
-    [upgrade] Running cluster health checks
-    [upgrade/version] You have chosen to change the cluster version to "v1.19.0"
-    [upgrade/versions] Cluster version: v1.18.4
-    [upgrade/versions] kubeadm version: v1.19.0
-    [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y
-    [upgrade/prepull] Pulling images required for setting up a Kubernetes cluster
-    [upgrade/prepull] This might take a minute or two, depending on the speed of your internet connection
-    [upgrade/prepull] You can also perform this action in beforehand using 'kubeadm config images pull'
-    [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.19.0"...
-    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
-    Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
-    Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
-    [upgrade/etcd] Upgrading to TLS for etcd
-    Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
-    [upgrade/staticpods] Preparing for "etcd" upgrade
-    [upgrade/staticpods] Renewing etcd-server certificate
-    [upgrade/staticpods] Renewing etcd-peer certificate
-    [upgrade/staticpods] Renewing etcd-healthcheck-client certificate
-    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/etcd.yaml"
-    [upgrade/staticpods] Waiting for the kubelet to restart the component
-    [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-    Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
-    Static pod: etcd-kind-control-plane hash: 171c56cd0e81c0db85e65d70361ceddf
-    Static pod: etcd-kind-control-plane hash: 59e40b2aab1cd7055e64450b5ee438f0
-    [apiclient] Found 1 Pods for label selector component=etcd
-    [upgrade/staticpods] Component "etcd" upgraded successfully!
-    [upgrade/etcd] Waiting for etcd to become available
-    [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests999800980"
-    [upgrade/staticpods] Preparing for "kube-apiserver" upgrade
-    [upgrade/staticpods] Renewing apiserver certificate
-    [upgrade/staticpods] Renewing apiserver-kubelet-client certificate
-    [upgrade/staticpods] Renewing front-proxy-client certificate
-    [upgrade/staticpods] Renewing apiserver-etcd-client certificate
-    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-apiserver.yaml"
-    [upgrade/staticpods] Waiting for the kubelet to restart the component
-    [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
-    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
-    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
-    Static pod: kube-apiserver-kind-control-plane hash: b4c8effe84b4a70031f9a49a20c8b003
-    Static pod: kube-apiserver-kind-control-plane hash: f717874150ba572f020dcd89db8480fc
-    [apiclient] Found 1 Pods for label selector component=kube-apiserver
-    [upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
-    [upgrade/staticpods] Preparing for "kube-controller-manager" upgrade
-    [upgrade/staticpods] Renewing controller-manager.conf certificate
-    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-controller-manager.yaml"
-    [upgrade/staticpods] Waiting for the kubelet to restart the component
-    [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-    Static pod: kube-controller-manager-kind-control-plane hash: 9ac092f0ca813f648c61c4d5fcbf39f2
-    Static pod: kube-controller-manager-kind-control-plane hash: b155b63c70e798b806e64a866e297dd0
-    [apiclient] Found 1 Pods for label selector component=kube-controller-manager
-    [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
-    [upgrade/staticpods] Preparing for "kube-scheduler" upgrade
-    [upgrade/staticpods] Renewing scheduler.conf certificate
-    [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-07-13-16-24-16/kube-scheduler.yaml"
-    [upgrade/staticpods] Waiting for the kubelet to restart the component
-    [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s)
-    Static pod: kube-scheduler-kind-control-plane hash: 7da02f2c78da17af7c2bf1533ecf8c9a
-    Static pod: kube-scheduler-kind-control-plane hash: 260018ac854dbf1c9fe82493e88aec31
-    [apiclient] Found 1 Pods for label selector component=kube-scheduler
-    [upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
-    [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
-    [kubelet] Creating a ConfigMap "kubelet-config-1.19" in namespace kube-system with the configuration for the kubelets in the cluster
-    [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
-    [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
-    [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
-    [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
-    [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
-    W0713 16:26:14.074656    2986 dns.go:282] the CoreDNS Configuration will not be migrated due to unsupported version of CoreDNS. The existing CoreDNS Corefile configuration and deployment has been retained.
-    [addons] Applied essential addon: CoreDNS
-    [addons] Applied essential addon: kube-proxy
-
-    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.19.0". Enjoy!
+    [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy!

    [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
    ```
@ -264,14 +137,7 @@ min-kubernetes-server-version: 1.19

    CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다.

-  컨트롤 플레인 노드에 적용된 cordon을 해제한다.
-
-    ```shell
-    # <cp-node-name>을 컨트롤 플레인 노드 이름으로 바꾼다.
-    kubectl uncordon <cp-node-name>
-    ```
-
-### 추가 컨트롤 플레인 노드 업그레이드
+**다른 컨트롤 플레인 노드의 경우**

 첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다.

@ -285,36 +151,58 @@ sudo kubeadm upgrade node
 sudo kubeadm upgrade apply
 ```

-또한 `sudo kubeadm upgrade plan` 은 필요하지 않다.
+`kubeadm upgrade plan` 을 호출하고 CNI 공급자 플러그인을 업그레이드할 필요가 없다.
+
+### 노드 드레인
+
+-  Prepare the node for maintenance by marking it unschedulable and evicting the workloads:
+
+    ```shell
+    # <node-to-drain>을 드레인하는 노드의 이름으로 바꾼다.
+    kubectl drain <node-to-drain> --ignore-daemonsets
+    ```

 ### kubelet과 kubectl 업그레이드

-모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다.
+-  모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다.

 {{< tabs name="k8s_install_kubelet" >}}
-{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
+{{< tab name="Ubuntu, Debian 또는 HypriotOS" >}}
+    <pre>>
+    # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
    apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
    apt-mark hold kubelet kubectl
    -
    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
-{{% /tab %}}
-{{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
-{{% /tab %}}
+    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
+    </pre>
+{{< /tab >}}
+{{< tab name="CentOS, RHEL 또는 Fedora" >}}
+    <pre>
+    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
+    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
+    </pre>
+{{< /tab >}}
 {{< /tabs >}}

-kubelet을 다시 시작한다.
+-  kubelet을 다시 시작한다.

 ```shell
 sudo systemctl daemon-reload
 sudo systemctl restart kubelet
 ```

+### 노드 uncordon
+
+-   노드를 스케줄 가능으로 표시하여 노드를 다시 온라인 상태로 전환한다.
+
+    ```shell
+    # <node-to-drain>을 드레인하는 노드의 이름으로 바꾼다.
+    kubectl uncordon <node-to-drain>
+    ```
+
 ## 워커 노드 업그레이드

 워커 노드의 업그레이드 절차는 워크로드를 실행하는 데 필요한 최소 용량을 보장하면서,
@ -326,18 +214,18 @@ sudo systemctl restart kubelet

 {{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
+    # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
    apt-mark unhold kubeadm && \
-    apt-get update && apt-get install -y kubeadm=1.19.x-00 && \
+    apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \
    apt-mark hold kubeadm
    -
    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubeadm=1.19.x-00
+    apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubeadm-1.19.x-0 --disableexcludes=kubernetes
+    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
+    yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}

@ -350,17 +238,9 @@ sudo systemctl restart kubelet
    kubectl drain <node-to-drain> --ignore-daemonsets
    ```

-    다음과 비슷한 출력이 표시되어야 한다.
+### kubeadm 업그레이드 호출

-    ```
-    node/ip-172-31-85-18 cordoned
-    WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx
-    node/ip-172-31-85-18 drained
-    ```
-
-### kubelet 구성 업그레이드
-
-1.  다음의 명령을 호출한다.
+-  워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다.

    ```shell
    sudo kubeadm upgrade node
@ -368,22 +248,22 @@ sudo systemctl restart kubelet

 ### kubelet과 kubectl 업그레이드

-  모든 워커 노드에서 kubelet 및 kubectl을 업그레이드한다.
+-  kubelet 및 kubectl을 업그레이드한다.

 {{< tabs name="k8s_kubelet_and_kubectl" >}}
 {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}}
-    # 1.19.x-00의 x를 최신 패치 버전으로 바꾼다
+    # {{< skew latestVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다
    apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet=1.19.x-00 kubectl=1.19.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
    apt-mark hold kubelet kubectl
    -
    # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다
    apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet=1.19.x-00 kubectl=1.19.x-00
+    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
 {{% /tab %}}
 {{% tab name="CentOS, RHEL 또는 Fedora" %}}
-    # 1.19.x-0에서 x를 최신 패치 버전으로 바꾼다
-    yum install -y kubelet-1.19.x-0 kubectl-1.19.x-0 --disableexcludes=kubernetes
+    # {{< skew latestVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다
+    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
 {{% /tab %}}
 {{< /tabs >}}

@ -405,7 +285,8 @@ sudo systemctl restart kubelet

 ## 클러스터 상태 확인

-모든 노드에서 kubelet을 업그레이드 한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여 모든 노드를 다시 사용할 수 있는지 확인한다.
+모든 노드에서 kubelet을 업그레이드한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여
+모든 노드를 다시 사용할 수 있는지 확인한다.

 ```shell
 kubectl get nodes
@ -413,8 +294,6 @@ kubectl get nodes

 모든 노드에 대해 `STATUS` 열에 `Ready` 가 표시되어야 하고, 버전 번호가 업데이트되어 있어야 한다.

-
-
 ## 장애 상태에서의 복구

 예를 들어 `kubeadm upgrade` 를 실행하는 중에 예기치 못한 종료로 인해 업그레이드가 실패하고 롤백하지 않는다면, `kubeadm upgrade` 를 다시 실행할 수 있다.
@ -423,7 +302,6 @@ kubectl get nodes
 잘못된 상태에서 복구하기 위해, 클러스터가 실행 중인 버전을 변경하지 않고 `kubeadm upgrade apply --force` 를 실행할 수도 있다.

 업그레이드하는 동안 kubeadm은 `/etc/kubernetes/tmp` 아래에 다음과 같은 백업 폴더를 작성한다.
-
 - `kubeadm-backup-etcd-<date>-<time>`
 - `kubeadm-backup-manifests-<date>-<time>`

--- a/content/ko/docs/tasks/network/validate-dual-stack.md
+++ b/content/ko/docs/tasks/network/validate-dual-stack.md
@ -1,5 +1,5 @@
 ---
-min-kubernetes-server-version: v1.16
+min-kubernetes-server-version: v1.20
 title: IPv4/IPv6 이중 스택 검증
 content_type: task
 ---
@ -94,31 +94,31 @@ a00:100::4    pod01

 ## 서비스 검증

-`ipFamily` 필드 세트 없이 다음 서비스를 생성한다. 필드가 구성되지 않았으면 서비스는 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 설정된 범위 내 첫 IP를 할당받는다.
+`.spec.ipFamilyPolicy` 를 명시적으로 정의하지 않은 다음의 서비스를 생성한다. 쿠버네티스는 처음 구성된 `service-cluster-ip-range` 에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정한다.

 {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}

-해당 서비스의 YAML을 보면, 서비스의 `ipFamily` 필드가 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 첫 번째 설정된 범위의 주소 패밀리를 반영하도록 설정되어 있음을 확인할 수 있다.
+`kubectl` 을 사용하여 서비스의 YAML을 확인한다.

 ```shell
 kubectl get svc my-service -o yaml
 ```

+이 서비스에서 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정하고 `.spec.clusterIP` 를 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 설정된 첫 번째 구성 범위에서 IPv4 주소로 설정한다.
+
 ```yaml
 apiVersion: v1
 kind: Service
 metadata:
-  creationTimestamp: "2019-09-03T20:45:13Z"
-  labels:
-    app: MyApp
  name: my-service
  namespace: default
-  resourceVersion: "485836"
-  selfLink: /api/v1/namespaces/default/services/my-service
-  uid: b6fa83ef-fe7e-47a3-96a1-ac212fa5b030
 spec:
-  clusterIP: 10.0.29.179
-  ipFamily: IPv4
+  clusterIP: 10.0.217.164
+  clusterIPs:
+  - 10.0.217.164
+  ipFamilies:
+  - IPv4
+  ipFamilyPolicy: SingleStack
  ports:
  - port: 80
    protocol: TCP
@ -131,26 +131,97 @@ status:
  loadBalancer: {}
 ```

-`ipFamily` 필드를 `IPv6`로 설정하여 다음의 서비스를 생성한다.
+`.spec.ipFamilies` 의 첫 번째 배열 요소로 `IPv6` 을 명시적으로 정의하는 다음 서비스를 생성한다. Kubernetes는 `service-cluster-ip-range`로 구성된 IPv6 범위에서 서비스용 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정한다.

-{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
+{{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}}

-서비스가 IPv6 주소 블록에서 클러스터 IP 주소를 할당받는 것을 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
+`kubectl` 를 사용하여 서비스의 YAML을 확인한다.
+
+```shell
+kubectl get svc my-service -o yaml
 ```
+
+이 서비스에서 `.spec.ipFamilyPolicy` 를 `SingleStack` 으로 설정하고 `.spec.clusterIP` 를 kube-controller-manager의 `--service-cluster-ip-range` 플래그를 통해 설정된 IPv6 범위에서 IPv6 주소로 설정한다.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: MyApp
+  name: my-service
+spec:
+  clusterIP: fd00::5118
+  clusterIPs:
+  - fd00::5118
+  ipFamilies:
+  - IPv6
+  ipFamilyPolicy: SingleStack
+  ports:
+  - port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:
+    app: MyApp
+  sessionAffinity: None
+  type: ClusterIP
+status:
+  loadBalancer: {}
+```
+
+`PreferDualStack` 에 `.spec.ipFamilyPolicy` 을 명시적으로 정의하는 다음 서비스를 생성한다. 쿠버네티스는 IPv4 및 IPv6 주소를 모두 할당하고 (이 클러스터에는 이중 스택을 사용하도록 설정되었으므로) `.spec.ipFamilies` 배열에 있는 첫 번째 요소의 주소 계열을 기반으로`.spec.ClusterIP` 목록에서 `.spec.ClusterIPs` 를 선택한다.
+
+{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}}
+
+{{< note >}}
+`kubectl get svc` 명령어는 오직 `CLUSTER-IP` 필드에 주요 IP만 표시한다.
+
+```shell
 kubectl get svc -l app=MyApp
-NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
-my-service   ClusterIP   fe80:20d::d06b   <none>        80/TCP    9s
+
+NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
+my-service   ClusterIP   10.0.216.242   <none>        80/TCP    5s
+```
+{{< /note >}}
+
+서비스가 `kubectl describe` 를 사용하여 IPv4 및 IPv6 주소 블록에서 클러스터 IP를 가져오는지 확인한다. 그런 다음 IP 및 포트를 통해 서비스에 대한 접속을 확인할 수 있다.
+
+```shell
+kubectl describe svc -l app=MyApp
+```
+
+```
+Name:              my-service
+Namespace:         default
+Labels:            app=MyApp
+Annotations:       <none>
+Selector:          app=MyApp
+Type:              ClusterIP
+IP Family Policy:  PreferDualStack
+IP Families:       IPv4,IPv6
+IP:                10.0.216.242
+IPs:               10.0.216.242,fd00::af55
+Port:              <unset>  80/TCP
+TargetPort:        9376/TCP
+Endpoints:         <none>
+Session Affinity:  None
+Events:            <none>
 ```

 ### 이중 스택 로드 밸런싱 서비스 생성

-만약 클라우드 제공자가 IPv6 기반 외부 로드 밸런서 구성을 지원한다면 `ipFamily` 필드를 `IPv6`로, `type` 필드를 `LoadBalancer` 로 설정하여 다음의 서비스를 생성한다.
+만약 클라우드 제공자가 IPv6 기반 외부 로드 밸런서 구성을 지원한다면 `.spec.ipFamilyPolicy` 의 `PreferDualStack` 과 `.spec.ipFamilies` 배열의 첫 번째 요소로 `IPv6` 및 `LoadBalancer` 로 설정된 `type` 필드를 사용하여 다음 서비스를 생성한다.

-{{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}
+{{< codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" >}}
+
+Check the Service:
+
+```shell
+kubectl get svc -l app=MyApp
+```

 서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다.
-```
- kubectl get svc -l app=MyApp
-NAME         TYPE        CLUSTER-IP       EXTERNAL-IP                     PORT(S)        AGE
-my-service   ClusterIP   fe80:20d::d06b   2001:db8:f100:4002::9d37:c0d7   80:31868/TCP   30s
-```
+
+```shell
+NAME         TYPE           CLUSTER-IP   EXTERNAL-IP        PORT(S)        AGE
+my-service   LoadBalancer   fd00::7ebc   2603:1030:805::5   80:30790/TCP   35s
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
@ -233,6 +233,75 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
 있다.
 {{< /note >}}

+## 리소스 메트릭 지원
+
+모든 HPA 대상은 스케일링 대상에서 파드의 리소스 사용량을 기준으로 스케일링할 수 있다.
+파드의 명세를 정의할 때는 `cpu` 및 `memory` 와 같은 리소스 요청을
+지정해야 한다. 이것은 리소스 사용률을 결정하는 데 사용되며 HPA 컨트롤러에서 대상을
+스케일링하거나 축소하는 데 사용한다. 리소스 사용률 기반 스케일링을 사용하려면 다음과 같은 메트릭 소스를
+지정해야 한다.
+
+```yaml
+type: Resource
+resource:
+  name: cpu
+  target:
+    type: Utilization
+    averageUtilization: 60
+```
+이 메트릭을 사용하면 HPA 컨트롤러는 스케일링 대상에서 파드의 평균 사용률을
+60%로 유지한다. 사용률은 파드의 요청된 리소스에 대한 현재 리소스 사용량 간의
+비율이다. 사용률 계산 및 평균 산출 방법에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을
+참조한다.
+
+{{< note >}}
+모든 컨테이너의 리소스 사용량이 합산되므로 총 파드 사용량이 개별 컨테이너 리소스 사용량을
+정확하게 나타내지 못할 수 있다. 이로 인해 단일 컨테이너가
+높은 사용량으로 실행될 수 있고 전체 파드 사용량이 여전히 허용 가능한 한도 내에 있기 때문에 HPA가 스케일링되지 않는
+상황이 발생할 수 있다.
+{{< /note >}}
+
+### 컨테이너 리소스 메트릭
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+`HorizontalPodAutoscaler` 는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
+리소스 사용량을 추적할 수 있는 컨테이너 메트릭 소스도 지원한다.
+이를 통해 특정 파드에서 가장 중요한 컨테이너의 스케일링 임계값을 구성할 수 있다.
+예를 들어 웹 애플리케이션 프로그램과 로깅 사이드카가 있는 경우 사이드카 컨테이너와 해당 리소스 사용을 무시하고
+웹 애플리케이션의 리소스 사용을 기준으로 스케일링할 수 있다.
+
+대상 리소스를 다른 컨테이너 세트를 사용하여 새 파드 명세를 갖도록 수정하는 경우
+새로 추가된 컨테이너도 스케일링에 사용해야 한다면 HPA 사양을 수정해야 한다.
+메트릭 소스에 지정된 컨테이너가 없거나 파드의 하위 집합에만 있는 경우
+해당 파드는 무시되고 권장 사항이 다시 계산된다. 계산에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을
+을 참조한다. 컨테이너 리소스를 오토스케일링에 사용하려면 다음과 같이
+메트릭 소스를 정의한다.
+```yaml
+type: ContainerResource
+containerResource:
+  name: cpu
+  container: application
+  target:
+    type: Utilization
+    averageUtilization: 60
+```
+
+위의 예에서 HPA 컨트롤러는 모든 파드의 `application` 컨테이너에 있는 CPU의 평균 사용률이
+60%가 되도록 대상을 조정한다.
+
+{{< note >}}
+HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는 경우
+특정 순서로 변경을 수행하여 변경 사항이 적용되는 동안 스케일링을 계속 사용할 수 있고
+효율적으로 유지할 수 있다. 컨테이너를 정의하는 리소스(예: 배포)를
+업데이트하기 전에 연결된 HPA를 업데이트하여 새 컨테이너 이름과 이전 컨테이너 이름을
+모두 추적해야 한다. 이러한 방식으로 HPA는 업데이트 프로세스 전반에 걸쳐 스케일링 권장 사항을
+계산할 수 있다.
+
+컨테이너 이름 변경을 워크로드 리소스로 롤아웃한 후에는 HPA 사양에서
+이전 컨테이너 이름을 제거하여 정리한다.
+{{< /note >}}
+
 ## 멀티 메트릭을 위한 지원

 Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
--- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
@ -29,19 +29,12 @@ weight: 10
            <div class="col-md-8">
                <h3>쿠버네티스 클러스터</h3>
                <p>
-                    <b>쿠버네티스는 서로 연결되어서 단일 유닛처럼 동작하는 고가용성의 컴퓨터 클러스터를 상호조정한다.</b>
-                    쿠버네티스의 추상화된 개념을 통해 개별 머신에 얽매이지 않고 컨테이너화된 애플리케이션을 클러스터에
-                    배포할 수 있다. 이렇게 새로운 배포 모델을 활용하려면, 애플리케이션을 개별 호스트에 결합되지 않는
-                    방식으로 패키지할 필요가 있다. 즉, 컨테이너화 해야 한다. 컨테이너화된 애플리케이션은 호스트에
-                    매우 깊이 통합된 패키지로써, 특정 머신에 직접 설치되는 예전의 배포 모델보다 유연하고 가용성이 높다.
-                    <b>쿠버네티스는 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 보다 효율적으로
-                        자동화한다.</b>
-                    쿠버네티스는 오픈소스 플랫폼이고 운영 수준의 안정성을 가졌다.
+                <b>쿠버네티스는 컴퓨터들을 연결하여 단일 형상으로 동작하도록 컴퓨팅 클러스터를 구성하고 높은 가용성을 제공하도록 조율한다.</b> 사용자는 쿠버네티스의 추상화 개념을 통해 개별 머신에 얽매이지 않고 컨테이너화된 애플리케이션을 클러스터에 배포할 수 있다. 이렇게 새로운 배포 모델을 활용하려면, 애플리케이션을 개별 호스트에 독립적인 방식으로 패키징할 필요가 있다. 즉, 컨테이너화가 필요하다. 예전 배치 모델인 설치형 애플리케이션이 특정 머신의 호스트와 밀접하게 통합되는 패키지인 것에 비해, 컨테이너화된 애플리케이션은 유연성(flexible)과 가용성(available)이 훨씬 높다. <b>쿠버네티스는 이러한 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 더욱 효율적으로 자동화한다.</b> 쿠버네티스는 오픈소스 플랫폼이며 운영 수준의 안정성(production-ready)을 제공한다.
                </p>
                <p>쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.
                <ul>
-                    <li><b>마스터</b>는 클러스터를 상호조정한다</li>
-                    <li><b>노드</b>는 애플리케이션을 구동하는 작업자다</li>
+                    <li><b>마스터</b>는 클러스터를 조율한다.</li>
+                    <li><b>노드</b>는 애플리케이션을 구동하는 작업자(worker)이다.</li>
                </ul>
                </p>
            </div>
@ -56,8 +49,7 @@ weight: 10
                </div>
                <div class="content__box content__box_fill">
                    <p><i>
-                        쿠버네티스는 컴퓨터 클러스터에 걸쳐서 애플리케이션 컨테이너의 위치(스케줄링)와 실행을
-                        오케스트레이션하는 운영 수준의 오픈소스 플랫폼이다.
+                        쿠버네티스는 컴퓨터 클러스터에 애플리케이션 컨테이너의 배치(스케줄링) 및 실행을 오케스트레이션하는 운영 수준의 오픈소스 플랫폼이다.
                    </i></p>
                </div>
            </div>
@ -79,38 +71,24 @@ weight: 10

        <div class="row">
            <div class="col-md-8">
-                <p><b>마스터는 클러스터 관리를 담당한다.</b> 마스터는 애플리케이션을 스케줄링하거나, 애플리케이션의
-                    항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영하는 일과 같은
-                    클러스터 내 모든 활동을 조율한다.</p>
-                <p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로써 동작하는 VM 또는 물리적인 컴퓨터다.</b>
-                    각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는
-                    컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스
-                    클러스터는 최소 세 대의 노드를 가져야한다.</p>
+                <p><b>마스터는 클러스터 관리를 담당한다.</b> 마스터는 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
+                <p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>

            </div>
            <div class="col-md-4">
                <div class="content__box content__box_fill">
-                    <p><i>마스터는 실행 중인 애플리케이션을 호스팅하는 데 사용되는 클러스터와 노드를 관리한다. </i></p>
+                    <p><i>마스터는 실행 중인 애플리케이션을 호스팅하기 위해 사용되는 노드와 클러스터를 관리한다. </i></p>
                </div>
            </div>
        </div>

        <div class="row">
            <div class="col-md-8">
-                <p>애플리케이션을 쿠버네티스에 배포한다는 것은, 마스터에 애플리케이션 컨테이너를 구동하라고 지시하는
-                    것이다. 마스터는 컨테이너를 클러스터의 어느 노드에 구동시킬지를 스케줄한다. <b>노드는 마스터가
-                        제공하는 <a href="/docs/concepts/overview/kubernetes-api/">쿠버네티스 API</a>를 통해서 마스터와 통신한다.</b> 최종 사용자도 쿠버네티스 API를 직접
-                    사용해서 클러스터와 상호작용할 수 있다.</p>
+                <p>애플리케이션을 쿠버네티스에 배포하기 위해서는, 마스터에 애플리케이션 컨테이너의 구동을 지시하면 된다. 그러면 마스터는 컨테이너를 클러스터의 어느 노드에 구동시킬지 스케줄한다. <b>노드는 마스터가 제공하는 <a href="/ko/docs/concepts/overview/kubernetes-api/">쿠버네티스 API</a>를 통해서 마스터와 통신한다.</b> 최종 사용자도 쿠버네티스 API를 사용해서 클러스터와 직접 상호작용(interact)할 수 있다.</p>

-                <p>쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면
-                    Minikube를 사용할 수 있다. Minikube는 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한
-                    클러스터를 배포하는 가벼운 쿠버네티스 구현체다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서
-                    구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인
-                    부트스트래핑 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는
-                    온라인 터미널을 사용할 것이다.</p>
+                <p>쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면 Minikube를 사용할 수 있다. Minikube는 가벼운 쿠버네티스 구현체이며, 로컬 머신에 VM을 만들고 하나의 노드로 구성된 간단한 클러스터를 생성한다. Minikube는 리눅스, 맥, 그리고 윈도우 시스템에서 구동이 가능하다. Minikube CLI는 클러스터에 대해 시작, 중지, 상태 조회 및 삭제 등의 기본적인 부트스트래핑(bootstrapping) 기능을 제공한다. 하지만, 본 튜토리얼에서는 Minikube가 미리 설치된 채로 제공되는 온라인 터미널을 사용할 것이다.</p>

-                <p>이제 쿠버네티스가 무엇인지 알아봤으니, 온라인 튜토리얼로 이동해서 우리의 첫 번째 클러스터를
-                    시작해보자!</p>
+                <p>쿠버네티스가 무엇인지 알아봤으니, 이제 온라인 튜토리얼로 이동해서 우리의 첫 번째 클러스터를 시작해보자!</p>

            </div>
        </div>
@ -118,8 +96,7 @@ weight: 10

        <div class="row">
            <div class="col-md-12">
-                <a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/"
-                   role="button">대화형 튜토리얼 시작하기 <span class="btn__next">›</span></a>
+                <a class="btn btn-lg btn-success" href="/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/" role="button">대화형 튜토리얼 시작하기 <span class="btn__next">›</span></a>
            </div>
        </div>

--- a/content/ko/examples/application/job/cronjob.yaml
+++ b/content/ko/examples/application/job/cronjob.yaml
@ -11,6 +11,7 @@ spec:
          containers:
          - name: hello
            image: busybox
+            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
--- a/content/ko/examples/application/mysql/mysql-configmap.yaml
+++ b/content/ko/examples/application/mysql/mysql-configmap.yaml
@ -5,12 +5,12 @@ metadata:
  labels:
    app: mysql
 data:
-  master.cnf: |
-    # Apply this config only on the master.
+  primary.cnf: |
+    # Primary에만 이 구성을 적용한다.
    [mysqld]
    log-bin
-  slave.cnf: |
-    # Apply this config only on slaves.
+  replica.cnf: |
+    # 레플리카에만 이 구성을 적용한다.
    [mysqld]
    super-read-only

--- a/content/ko/examples/application/mysql/mysql-services.yaml
+++ b/content/ko/examples/application/mysql/mysql-services.yaml
@ -1,4 +1,4 @@
-# Headless service for stable DNS entries of StatefulSet members.
+# 스테이트풀셋 멤버의 안정적인 DNS 엔트리를 위한 헤드리스 서비스.
 apiVersion: v1
 kind: Service
 metadata:
@ -13,8 +13,8 @@ spec:
  selector:
    app: mysql
 ---
-# Client service for connecting to any MySQL instance for reads.
-# For writes, you must instead connect to the master: mysql-0.mysql.
+# 읽기용 MySQL 인스턴스에 연결하기 위한 클라이언트 서비스.
+# 쓰기용은 Primary인 mysql-0.mysql에 대신 연결해야 한다.
 apiVersion: v1
 kind: Service
 metadata:
--- a/content/ko/examples/application/mysql/mysql-statefulset.yaml
+++ b/content/ko/examples/application/mysql/mysql-statefulset.yaml
@ -21,17 +21,17 @@ spec:
        - "-c"
        - |
          set -ex
-          # Generate mysql server-id from pod ordinal index.
+          # 파드의 원래 인덱스에서 mysql server-id를 생성.
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          echo [mysqld] > /mnt/conf.d/server-id.cnf
-          # Add an offset to avoid reserved server-id=0 value.
+          # 예약된 server-id=0 값을 피하기 위해 오프셋 추가.
          echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
-          # Copy appropriate conf.d files from config-map to emptyDir.
+          # config-map에서 emptyDir로 적당한 conf.d 파일들을 복사.
          if [[ $ordinal -eq 0 ]]; then
-            cp /mnt/config-map/master.cnf /mnt/conf.d/
+            cp /mnt/config-map/primary.cnf /mnt/conf.d/
          else
-            cp /mnt/config-map/slave.cnf /mnt/conf.d/
+            cp /mnt/config-map/replica.cnf /mnt/conf.d/
          fi
        volumeMounts:
        - name: conf
@ -45,15 +45,15 @@ spec:
        - "-c"
        - |
          set -ex
-          # Skip the clone if data already exists.
+          # 데이터가 이미 존재하면 복제 생략. 
          [[ -d /var/lib/mysql/mysql ]] && exit 0
-          # Skip the clone on master (ordinal index 0).
+          # Primary에 복제 생략(ordinal index 0).
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          [[ $ordinal -eq 0 ]] && exit 0
-          # Clone data from previous peer.
+          # 이전 피어(peer)에서 데이터 복제.
          ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
-          # Prepare the backup.
+          # 백업 준비.
          xtrabackup --prepare --target-dir=/var/lib/mysql
        volumeMounts:
        - name: data
@ -88,7 +88,7 @@ spec:
          timeoutSeconds: 5
        readinessProbe:
          exec:
-            # Check we can execute queries over TCP (skip-networking is off).
+            # TCP 상에서 쿼리를 실행할 수 있는지 확인(skip-networking은 off).
            command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
@ -105,22 +105,22 @@ spec:
          set -ex
          cd /var/lib/mysql

-          # Determine binlog position of cloned data, if any.
+          # 복제된 데이터의 binlog 위치를 확인.
          if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
-            # XtraBackup already generated a partial "CHANGE MASTER TO" query
-            # because we're cloning from an existing slave. (Need to remove the tailing semicolon!)
+            # XtraBackup은 기존 레플리카에서 복제하기 때문에
+            # 일부 "CHANGE MASTER TO" 쿼리는 이미 생성했음. (테일링 세미콜론을 제거해야 한다!)
            cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
-            # Ignore xtrabackup_binlog_info in this case (it's useless).
+            # 이 경우에는 xtrabackup_binlog_info는 무시(필요없음).
            rm -f xtrabackup_slave_info xtrabackup_binlog_info
          elif [[ -f xtrabackup_binlog_info ]]; then
-            # We're cloning directly from master. Parse binlog position.
+            # Primary로부터 직접 복제함. binlog 위치를 파싱.
            [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
            rm -f xtrabackup_binlog_info xtrabackup_slave_info
            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
          fi

-          # Check if we need to complete a clone by starting replication.
+          # Replication을 시작하여 복제를 완료해야 하는지 확인.
          if [[ -f change_master_to.sql.in ]]; then
            echo "Waiting for mysqld to be ready (accepting connections)"
            until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done
@ -133,11 +133,11 @@ spec:
                          MASTER_PASSWORD='', \
                          MASTER_CONNECT_RETRY=10; \
                        START SLAVE;" || exit 1
-            # In case of container restart, attempt this at-most-once.
+            # 컨테이너가 다시 시작하는 경우, 이 작업을 한번만 시도한다.
            mv change_master_to.sql.in change_master_to.sql.orig
          fi

-          # Start a server to send backups when requested by peers.
+          # 피어가 요청할 때 서버를 시작하여 백업을 보냄.
          exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
            "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
        volumeMounts:
--- a/content/ko/examples/service/networking/dual-stack-default-svc.yaml
+++ b/content/ko/examples/service/networking/dual-stack-default-svc.yaml
@ -2,10 +2,11 @@ apiVersion: v1
 kind: Service
 metadata:
  name: my-service
+  labels:
+    app: MyApp
 spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
-      targetPort: 9376
--- a/content/ko/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml
+++ b/content/ko/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml
@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  ipFamily: IPv4
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
--- a/content/ko/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml
+++ b/content/ko/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml
--- a/content/ko/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml
+++ b/content/ko/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml
@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+  labels:
+    app: MyApp
+spec:
+  ipFamilyPolicy: PreferDualStack
+  ipFamilies:
+  - IPv6
+  - IPv4
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
--- a/content/ko/examples/service/networking/dual-stack-preferred-svc.yaml
+++ b/content/ko/examples/service/networking/dual-stack-preferred-svc.yaml
@ -0,0 +1,13 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+  labels:
+    app: MyApp
+spec:
+  ipFamilyPolicy: PreferDualStack
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80