From 5f6f123db7adca12df802636cad07d103d8b9aa7 Mon Sep 17 00:00:00 2001
From: Jihoon Seo <jihoon.seo@etri.re.kr>
Date: Fri, 2 Jul 2021 11:24:48 +0900
Subject: [PATCH 1/6] [ko] Fix nits

---
 content/ko/docs/concepts/workloads/pods/_index.md      | 8 ++++----
 content/ko/docs/setup/_index.md                        | 2 +-
 content/ko/docs/setup/best-practices/multiple-zones.md | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md
index 8645053bef..22b98b705c 100644
--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@@ -32,10 +32,10 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)
 ## 파드란 무엇인가?
 
 {{< note >}}
-[도커](https://www.docker.com/)가 가장 일반적으로
-잘 알려진 런타임이지만, 쿠버네티스는 도커보다
-{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을
-더 많이 지원하며, 도커의 일부 용어를 사용하면 파드를 설명하는 데 도움이 된다.
+[도커](https://www.docker.com/)가 가장 일반적으로 잘 알려진 
+{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이지만, 
+쿠버네티스는 도커 외에도 다양한 컨테이너 런타임을 지원하며, 
+파드를 설명할 때 도커 관련 용어를 사용하면 더 쉽게 설명할 수 있다.
 {{< /note >}}
 
 파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md
index d6e1ea5a21..3c6013c590 100644
--- a/content/ko/docs/setup/_index.md
+++ b/content/ko/docs/setup/_index.md
@@ -58,6 +58,6 @@ card:
 - 클러스터 구성의 [모범 사례](/ko/docs/setup/best-practices/)를 확인한다.
 
 쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은 
-리눅스에서 실행되어야 한다. 클러스터 내에서는 리눅스 또는 
+리눅스에서 실행되도록 설계되었다. 클러스터 내에서는 리눅스 또는 
 다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다.
 - [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다.
diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md
index 3d825ebd08..93ab353d37 100644
--- a/content/ko/docs/setup/best-practices/multiple-zones.md
+++ b/content/ko/docs/setup/best-practices/multiple-zones.md
@@ -55,7 +55,7 @@ content_type: concept
 특정 kubelet을 나타내는 노드 오브젝트에
 {{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다.
 이러한 레이블에는
-[영역 정보](/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
+[영역 정보](/ko/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
 
 클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
 [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과

From d9f11f3b19af9f02208b5d688554cca5d1c031f8 Mon Sep 17 00:00:00 2001
From: Jihoon Seo <jihoon.seo@etri.re.kr>
Date: Fri, 2 Jul 2021 11:48:07 +0900
Subject: [PATCH 2/6] [ko] Update links (http -> https)

---
 content/ko/_index.html                                       | 2 +-
 content/ko/case-studies/box/index.html                       | 4 ++--
 content/ko/docs/concepts/policy/pod-security-policy.md       | 2 +-
 content/ko/docs/contribute/participate/_index.md             | 2 +-
 content/ko/docs/tutorials/stateless-application/guestbook.md | 2 +-
 content/ko/includes/task-tutorial-prereqs.md                 | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/content/ko/_index.html b/content/ko/_index.html
index 9db1ac0982..2b3d62cb44 100644
--- a/content/ko/_index.html
+++ b/content/ko/_index.html
@@ -10,7 +10,7 @@ sitemap:
 {{% blocks/feature image="flower" %}}
 K8s라고도 알려진 [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
 
-애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
+애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](https://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="scalable" %}}
diff --git a/content/ko/case-studies/box/index.html b/content/ko/case-studies/box/index.html
index 058ff7f9a2..392e3d66bb 100644
--- a/content/ko/case-studies/box/index.html
+++ b/content/ko/case-studies/box/index.html
@@ -23,7 +23,7 @@ case_study_details:
 
 <h2>Solution</h2>
 
-<p>Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <a href="http://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box's developers to "target a universal set of concepts that are portable across all clouds."</p>
+<p>Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <a href="https://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box's developers to "target a universal set of concepts that are portable across all clouds."</p>
 
 <h2>Impact</h2>
 
@@ -37,7 +37,7 @@ case_study_details:
 In the summer of 2014, Box was feeling the pain of a decade's worth of hardware and software infrastructure that wasn't keeping up with the company's needs.
 {{< /case-studies/lead >}}
 
-<p>A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It's been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."</p>
+<p>A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="https://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It's been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."</p>
 
 <p>Box's cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.</p>
 
diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md
index eae69022e6..5941a0e13a 100644
--- a/content/ko/docs/concepts/policy/pod-security-policy.md
+++ b/content/ko/docs/concepts/policy/pod-security-policy.md
@@ -567,7 +567,7 @@ spec:
 리눅스 기능은 전통적으로 슈퍼유저와 관련된 권한을 보다 세밀하게 분류한다.
 이러한 기능 중 일부는 권한 에스컬레이션 또는 컨테이너 분류에 사용될 수 있으며
 파드시큐리티폴리시에 의해 제한될 수 있다. 리눅스 기능에 대한 자세한 내용은
-[기능(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)을
+[기능(7)](https://man7.org/linux/man-pages/man7/capabilities.7.html)을
 참고하길 바란다.
 
 다음 필드는 대문자로 표기된 기능 이름 목록을
diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md
index ef271ca31c..46ae4e0d9c 100644
--- a/content/ko/docs/contribute/participate/_index.md
+++ b/content/ko/docs/contribute/participate/_index.md
@@ -94,7 +94,7 @@ PR 소유자에게 조언하는데 활용된다.
 ## 병합 작업 방식
 
 풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는
-브랜치에 병합되면, 해당 콘텐츠는 http://kubernetes.io 에 공개된다. 게시된 콘텐츠의
+브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. 게시된 콘텐츠의
 품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
 작동 방식은 다음과 같다.
 
diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md
index 4a475563ba..0aea000cd7 100644
--- a/content/ko/docs/tutorials/stateless-application/guestbook.md
+++ b/content/ko/docs/tutorials/stateless-application/guestbook.md
@@ -269,7 +269,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
       Forwarding from [::1]:8080 -> 80
       ```
 
-1. 방명록을 보기위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다.
+1. 방명록을 보기 위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다.
 
 ### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기
 
diff --git a/content/ko/includes/task-tutorial-prereqs.md b/content/ko/includes/task-tutorial-prereqs.md
index 65651286bd..e27f4b99e4 100644
--- a/content/ko/includes/task-tutorial-prereqs.md
+++ b/content/ko/includes/task-tutorial-prereqs.md
@@ -5,4 +5,4 @@
 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
 
 * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
-* [Play with Kubernetes](http://labs.play-with-k8s.com/)
+* [Play with Kubernetes](https://labs.play-with-k8s.com/)

From 85adb64d7288cd90026245f64260619404fbda3a Mon Sep 17 00:00:00 2001
From: Nitesh Seram <niteshseram@gmail.com>
Date: Mon, 5 Jul 2021 08:56:43 +0530
Subject: [PATCH 3/6] fix link issue

---
 content/ko/_index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/ko/_index.html b/content/ko/_index.html
index 2b3d62cb44..c6350f1559 100644
--- a/content/ko/_index.html
+++ b/content/ko/_index.html
@@ -48,7 +48,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Revisit KubeCon EU 2021</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Attend KubeCon Europe on May 17-20, 2022</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

From 15b64da3ddc9880d446d9c62bb1ddfd6728e340d Mon Sep 17 00:00:00 2001
From: Jihoon Seo <jihoon.seo@etri.re.kr>
Date: Mon, 5 Jul 2021 16:27:39 +0900
Subject: [PATCH 4/6] [ko] Update outdated files in dev-1.21-ko.6 (p2)

---
 .../ko/docs/concepts/architecture/nodes.md    | 36 ++++++++++++++-----
 content/ko/docs/concepts/storage/volumes.md   | 31 ++++++++++++----
 .../pods/pod-topology-spread-constraints.md   | 14 ++++----
 .../generate-ref-docs/quickstart.md           |  4 +--
 .../docs/contribute/new-content/open-a-pr.md  | 18 +++++-----
 .../docs/contribute/new-content/overview.md   |  4 +--
 .../ko/docs/contribute/participate/_index.md  |  4 +--
 .../contribute/participate/pr-wranglers.md    |  4 +--
 .../participate/roles-and-responsibilities.md |  4 +--
 .../feature-gates.md                          |  3 +-
 10 files changed, 81 insertions(+), 41 deletions(-)

diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
index 5bba08100e..3ab89472d8 100644
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 노드
 content_type: concept
 weight: 10
@@ -8,7 +11,8 @@ weight: 10
 
 쿠버네티스는 컨테이너를 파드내에 배치하고 _노드_ 에서 실행함으로 워크로드를 구동한다.
 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는
-{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 의해 관리되며
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 
+의해 관리되며
 {{< glossary_tooltip text="파드" term_id="pod" >}}를
 실행하는 데 필요한 서비스를 포함한다.
 
@@ -272,17 +276,18 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 #### 안정성
 
  대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
-축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여
+축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여
 파드 축출을 하지 않는다는 의미가 된다.
 
 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
 체크한다(NodeReady 컨디션은 ConditionUnknown 또는
-ConditionFalse 다.).
-- 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold`
-  (기본값 0.55)가 되면 축출 비율은 감소한다.
+ConditionFalse 다).
+- 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold`
+  (기본값 0.55)가 되면 축출 속도가 감소한다.
 - 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
-  노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당
+  노드 이하면 - 기본값 50) 축출이 중지된다.
+- 이외의 경우, 축출 속도는 초당
   `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
 
 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
@@ -293,7 +298,7 @@ ConditionFalse 다.).
 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이
 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다.
 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
-`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이
+`--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이
 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다.
 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이
 복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
@@ -347,7 +352,8 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
 사용하여 주어진 기간 동안 노드 종료를 지연시키므로 systemd에 의존한다.
 
 그레이스풀 노드 셧다운은 1.21에서 기본적으로 활성화된 `GracefulNodeShutdown`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 제어된다.
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 
+제어된다.
 
 기본적으로, 아래 설명된 두 구성 옵션,
 `ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
@@ -371,6 +377,20 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
 유예 종료에 할당되고, 마지막 10초는
 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
 
+{{< note >}}
+그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다.
+`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다.
+그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다.
+
+```
+Status:         Failed
+Reason:         Shutdown
+Message:        Node is shutting, evicting pods
+```
+
+실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다.
+이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md
index 3bdfead48d..29f4755172 100644
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 볼륨
 content_type: concept
 weight: 10
@@ -13,7 +18,6 @@ weight: 10
 파일을 공유할 때 발생한다.
 쿠버네티스 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 추상화는
 이러한 문제를 모두 해결한다.
-
 [파드](/ko/docs/concepts/workloads/pods/)에 대해 익숙해지는 것을 추천한다.
 
 <!-- body -->
@@ -40,7 +44,6 @@ weight: 10
 
 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고
 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다.
-
 컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템
 뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는
 파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에
@@ -117,6 +120,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
 베타 기능을 활성화해야 한다.
 
 #### AWS EBS CSI 마이그레이션 완료
+
 {{< feature-state for_k8s_version="v1.17" state="alpha" >}}
 
 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지
@@ -257,6 +261,9 @@ spec:
 `path` 에서 파생된다.
 
 {{< note >}}
+* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 사용하기 위해서는
+  먼저 컨피그맵을 생성해야 한다.
+
 * 컨피그맵을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵
 업데이트를 수신하지 않는다.
 
@@ -522,6 +529,15 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 
 ### hostPath {#hostpath}
 
+{{< warning >}}
+HostPath 볼륨에는 많은 보안 위험이 있으며, 가능하면 HostPath를 사용하지 않는 
+것이 좋다. HostPath 볼륨을 사용해야 하는 경우, 필요한 파일 또는 디렉터리로만 
+범위를 지정하고 ReadOnly로 마운트해야 한다.
+
+AdmissionPolicy를 사용하여 특정 디렉터리로의 HostPath 액세스를 제한하는 경우,
+`readOnly` 마운트를 사용하는 정책이 유효하려면 `volumeMounts` 가 반드시 지정되어야 한다.
+{{< /warning >}}
+
 `hostPath` 볼륨은 호스트 노드의 파일시스템에 있는 파일이나 디렉터리를
 파드에 마운트 한다. 이것은 대부분의 파드들이 필요한 것은 아니지만, 일부
 애플리케이션에 강력한 탈출구를 제공한다.
@@ -538,7 +554,6 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 
 필드가 `type` 에 지원되는 값은 다음과 같다.
 
-
 | 값 | 행동 |
 |:------|:---------|
 | | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. |
@@ -552,6 +567,9 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 
 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다.
 
+* HostPath는 권한있는 시스템 자격 증명 (예 : Kubelet 용) 또는 권한있는 API 
+  (예 : 컨테이너 런타임 소켓)를 노출 할 수 있으며, 이는 컨테이너 이스케이프 또는 
+  클러스터의 다른 부분을 공격하는 데 사용될 수 있다.
 * 동일한 구성(파드템플릿으로 생성한 것과 같은)을
   가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다.
 * 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다.
@@ -909,7 +927,8 @@ API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정
 상대 경로를 지정한다.
 
 {{< note >}}
-projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다.
+projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 
+해당 볼륨 소스의 업데이트를 수신하지 않는다.
 {{< /note >}}
 
 ### quobyte
@@ -1103,7 +1122,6 @@ vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
 
 {{< /tabs >}}
 
-
 #### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration}
 
 ```yaml
@@ -1133,8 +1151,7 @@ spec:
 {{< feature-state for_k8s_version="v1.19" state="beta" >}}
 
 `vsphereVolume` 용 `CSIMigration` 기능이 활성화되면, 기존 인-트리 플러그인에서
-`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다.
-이 기능을 사용하려면,
+`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면,
 [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가
 클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere`
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 3c30e895b6..304471bb28 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -82,12 +82,11 @@ spec:
 사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다.
 
 - **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
-  이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는
-  파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야
-  한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
+  이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
   - `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
-    대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 사이에
-    허용되는 최대 차이이다.
+    대상 토폴로지에서 일치하는 파드 수와 전역 최솟값
+    (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 전역 최솟값은 0) 
+    사이에 허용되는 최대 차이이다.
   - `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
     왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
 - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
@@ -96,6 +95,8 @@ spec:
   - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
 - **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
 
+파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
+
 사용자는 `kubectl explain Pod.spec.topologySpreadConstraints` 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다.
 
 ### 예시: 단수 토폴로지 분배 제약 조건
@@ -387,7 +388,8 @@ profiles:
 
 ## 알려진 제한사항
 
-- 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다.
+- 파드가 제거된 이후에도 제약 조건이 계속 충족된다는 보장은 없다. 예를 들어 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형해질 수 있다.
+[Descheduler](https://github.com/kubernetes-sigs/descheduler)를 사용하여 파드 분포를 다시 균형있게 만들 수 있다.
 - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다.
 
 ## {{% heading "whatsnext" %}}
diff --git a/content/ko/docs/contribute/generate-ref-docs/quickstart.md b/content/ko/docs/contribute/generate-ref-docs/quickstart.md
index 6e3fbb5263..6855696b9d 100644
--- a/content/ko/docs/contribute/generate-ref-docs/quickstart.md
+++ b/content/ko/docs/contribute/generate-ref-docs/quickstart.md
@@ -18,7 +18,7 @@ weight: 40
 
 ## `website` 저장소 클론하기 {#Getting-the-docs-repository}
 
-개인 계정에 있는 포크 버전의 `website` 저장소가 `kubernetes/website` 저장소의 master 브랜치만큼 최신인지 확인한 뒤,
+개인 계정에 있는 포크 버전의 `website` 저장소가 GitHub에 있는 `kubernetes/website` 저장소(`main` 브랜치)의 최신 상태와 일치하는지 확인한 뒤,
 개인 계정에 있는 포크 버전의 `website` 저장소를 로컬 개발 환경으로 클론한다.
 
 ```shell
@@ -171,7 +171,7 @@ cd <web-base>/update-imported-docs
 `release.yml` 환경설정 파일은 상대경로 링크를 수정하는 방법을 포함하고 있다.
 임포트하는 파일 안에 있는 상대경로 링크를 수정하려면, `gen-absolute-links` 필드를 
 `true` 로 명시한다. 이에 대한 예시는 
-[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml) 에서 볼 수 있다.
+[`release.yml`](https://github.com/kubernetes/website/blob/main/update-imported-docs/release.yml) 에서 볼 수 있다.
 
 ## `kubernetes/website` 의 변경사항을 커밋하기 {#Adding-and-committing-changes-in-kubernetes-website}
 
diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md
index 552a6e1a0c..a1f0178b3c 100644
--- a/content/ko/docs/contribute/new-content/open-a-pr.md
+++ b/content/ko/docs/contribute/new-content/open-a-pr.md
@@ -127,7 +127,7 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
     upstream	https://github.com/kubernetes/website.git (push)
     ```
 
-6. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다.
+6. 포크의 `origin/main` 와 `kubernetes/website` 의 `upstream/main` 에서 커밋을 가져온다.
 
     ```bash
     git fetch origin
@@ -137,15 +137,15 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
     이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다.
 
     {{< note >}}
-    이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `master` 복사본을 `upstream/master` 와 병합할 필요가 없다.
+    이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다.
     {{< /note >}}
 
 ### 브랜치 만들기
 
 1. 작업할 브랜치 기반을 결정한다.
 
-  - 기존 콘텐츠를 개선하려면, `upstream/master` 를 사용한다.
-  - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/master` 를 사용한다.
+  - 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다.
+  - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다.
   - 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
   - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
   - 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
@@ -154,10 +154,10 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
 
     브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다.
 
-2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/master` 라고 가정한다.
+2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다.
 
     ```bash
-    git checkout -b <my_new_branch> upstream/master
+    git checkout -b <my_new_branch> upstream/main
     ```
 
 3.  텍스트 편집기를 사용하여 변경한다.
@@ -264,7 +264,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
 
 또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다.
 
-1.  [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
+1.  [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
 
 2.  website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다.
 테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
@@ -372,11 +372,11 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
     git push --force-with-lease origin <your-branch-name>
     ```
 
-2. `kubernetes/website` 의 `upstream/master` 에 대한 변경 사항을 가져오고 브랜치를 리베이스한다.
+2. `kubernetes/website` 의 `upstream/main` 에 대한 변경 사항을 가져오고 브랜치를 리베이스한다.
 
     ```bash
     git fetch upstream
-    git rebase upstream/master
+    git rebase upstream/main
     ```
 
 3. 리베이스의 결과를 검사한다.
diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md
index 5c8f6569da..540f1e6c12 100644
--- a/content/ko/docs/contribute/new-content/overview.md
+++ b/content/ko/docs/contribute/new-content/overview.md
@@ -42,7 +42,7 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동
 
 시나리오   | 브랜치
 :---------|:------------
-현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `master`
+현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `main`
 기능 변경 릴리스의 콘텐츠 | `dev-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다.
 다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
 
@@ -60,6 +60,6 @@ PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 
 
 ## 기여자를 위한 도구들
 
-`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다.
+`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다.
 
 
diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md
index 46ae4e0d9c..c2d9aed771 100644
--- a/content/ko/docs/contribute/participate/_index.md
+++ b/content/ko/docs/contribute/participate/_index.md
@@ -73,8 +73,8 @@ GitHub의 SIG Docs [팀]에는 두 분류가 있다.
 - approve
 
 이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는
-[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와
-[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
+[OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS)와
+[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
 파일을 사용해서
 해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
 
diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md
index f3333890d2..674696ee90 100644
--- a/content/ko/docs/contribute/participate/pr-wranglers.md
+++ b/content/ko/docs/contribute/participate/pr-wranglers.md
@@ -45,8 +45,8 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
   지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
 - [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
   병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다.
-- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
-- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
+- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
+- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amain): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
 
 ### 랭글러를 위한 유용한 Prow 명령어
 
diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md
index 897d638435..c8e32e2a77 100644
--- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md
+++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md
@@ -144,7 +144,7 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로
 지원하려면, 다음을 수행한다.
 
 1. `kubernetes/website` 리포지터리 내
-   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) 파일의 섹션에
    여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다.
 
   {{< note >}}
@@ -216,7 +216,7 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리
 지원하려면 다음을 수행한다.
 
 1. `kubernetes/website` 리포지터리 내
-   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS)
    파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다.
 
     {{< note >}}
diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
index aef90d8db5..e5e6f1570d 100644
--- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
@@ -152,7 +152,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | |
 | `ProcMountType` | `false` | 알파 | 1.12 | |
 | `QOSReserved` | `false` | 알파 | 1.11 | |
-| `RemainingItemCount` | `false` | 알파 | 1.15 | |
+| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 |
+| `RemainingItemCount` | `true` | 베타 | 1.16 | |
 | `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
 | `RemoveSelfLink` | `true` | 베타 | 1.20 | |
 | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |

From 9fedbf68ea4bc52cdcfb39fd3f81d03b6651f658 Mon Sep 17 00:00:00 2001
From: Jihoon Seo <jihoon.seo@etri.re.kr>
Date: Mon, 5 Jul 2021 18:21:22 +0900
Subject: [PATCH 5/6] [ko] Update outdated files in dev-1.21-ko.6 (p3)

---
 .../manage-deployment.md                      |  2 +-
 .../organize-cluster-access-kubeconfig.md     |  6 +-
 content/ko/docs/concepts/containers/images.md | 14 ++++
 .../concepts/extend-kubernetes/operator.md    |  3 +-
 .../concepts/policy/pod-security-policy.md    | 65 +++++++++++++---
 .../taint-and-toleration.md                   | 29 ++++++--
 .../services-networking/dns-pod-service.md    |  2 +-
 content/ko/examples/policy/baseline-psp.yaml  | 74 +++++++++++++++++++
 8 files changed, 174 insertions(+), 21 deletions(-)
 create mode 100644 content/ko/examples/policy/baseline-psp.yaml

diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md
index abcc4c2cd5..7e3093d51e 100644
--- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md
@@ -50,7 +50,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/
 URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다.
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/nginx/nginx-deployment.yaml
 ```
 
 ```shell
diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
index a002414b67..aa739b381c 100644
--- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -17,6 +17,11 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스
 `kubeconfig`라는 이름의 파일이 있다는 의미는 아니다.
 {{< /note >}}
 
+{{< warning >}}
+신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다. 
+신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다.
+{{< /warning>}}
+
 기본적으로 `kubectl`은 `$HOME/.kube` 디렉터리에서 `config`라는 이름의 파일을 찾는다.
 `KUBECONFIG` 환경 변수를 설정하거나
 [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) 플래그를 지정해서
@@ -154,4 +159,3 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
 
 
 
-
diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md
index 9dd72e335f..886f8247a3 100644
--- a/content/ko/docs/concepts/containers/images.md
+++ b/content/ko/docs/concepts/containers/images.md
@@ -77,6 +77,20 @@ weight: 10
 
 `imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다.
 
+### 이미지풀백오프(ImagePullBackOff)
+
+kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, 
+`ImagePullBackOff`로 인해 컨테이너가 
+[Waiting](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) 상태에 있을 수 있다.
+
+`ImagePullBackOff`라는 상태는 (이미지 이름이 잘못됨, 또는 `imagePullSecret` 없이 
+비공개 레지스트리에서 풀링 시도 등의 이유로) 쿠버네티스가 컨테이너 이미지를 
+가져올 수 없기 때문에 컨테이너를 실행할 수 없음을 의미한다. `BackOff`라는 단어는 
+쿠버네티스가 백오프 딜레이를 증가시키면서 이미지 풀링을 계속 시도할 것임을 나타낸다.
+
+쿠버네티스는 시간 간격을 늘려가면서 시도를 계속하며, 시간 간격의 상한은 쿠버네티스 코드에 
+300초(5분)로 정해져 있다.
+
 ## 이미지 인덱스가 있는 다중 아키텍처 이미지
 
 바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.
diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md
index a0959f83dc..aba13a59c2 100644
--- a/content/ko/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ko/docs/concepts/extend-kubernetes/operator.md
@@ -116,7 +116,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
 * [Charmed Operator Framework](https://juju.is/)
 * [kubebuilder](https://book.kubebuilder.io/) 사용하기
 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
-* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
+* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)를
   사용하여 직접 구현하기
 * [오퍼레이터 프레임워크](https://operatorframework.io)
 * [shell-operator](https://github.com/flant/shell-operator)
@@ -124,6 +124,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
 ## {{% heading "whatsnext" %}}
 
 
+* {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [오퍼레이터 백서](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md) 읽어보기
 * [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
 * [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기
 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md
index 5941a0e13a..ff98e134eb 100644
--- a/content/ko/docs/concepts/policy/pod-security-policy.md
+++ b/content/ko/docs/concepts/policy/pod-security-policy.md
@@ -11,7 +11,8 @@ weight: 30
 
 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
 
-파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다.
+파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 사용 중단에 대한 상세 사항은
+[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
 
 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
 부여할 수 있다.
@@ -48,10 +49,9 @@ _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는
 
 ## 파드 시큐리티 폴리시 활성화
 
-파드 시큐리티 폴리시 제어는 선택 사항(하지만 권장함)인
-[어드미션
-컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로
-구현된다. [어드미션 컨트롤러 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면
+파드 시큐리티 폴리시 제어는 선택 사항인 [어드미션
+컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로 구현된다. 
+[어드미션 컨트롤러를 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면
 파드시큐리티폴리시가 적용되지만,
 정책을 승인하지 않고 활성화하면 클러스터에
 **파드가 생성되지 않는다.**
@@ -110,11 +110,15 @@ roleRef:
   name: <role name>
   apiGroup: rbac.authorization.k8s.io
 subjects:
-# Authorize specific service accounts:
+# 네임스페이스의 모든 서비스 어카운트 승인(권장):
+- kind: Group
+  apiGroup: rbac.authorization.k8s.io
+  name: system:serviceaccounts:<authorized namespace>
+# 특정 서비스 어카운트 승인(권장하지 않음):
 - kind: ServiceAccount
   name: <authorized service account name>
   namespace: <authorized pod namespace>
-# Authorize specific users (not recommended):
+# 특정 사용자 승인(권장하지 않음):
 - kind: User
   apiGroup: rbac.authorization.k8s.io
   name: <authorized user name>
@@ -124,21 +128,55 @@ subjects:
 실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을
 부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다.
 ```yaml
-# Authorize all service accounts in a namespace:
+# 네임스페이스의 모든 서비스 어카운트 승인:
 - kind: Group
   apiGroup: rbac.authorization.k8s.io
   name: system:serviceaccounts
-# Or equivalently, all authenticated users in a namespace:
+# 또는 동일하게, 네임스페이스의 모든 승인된 사용자에게 사용 권한 부여
 - kind: Group
   apiGroup: rbac.authorization.k8s.io
   name: system:authenticated
 ```
 
 RBAC 바인딩에 대한 자세한 예는,
-[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고하길 바란다.
+[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고한다.
 파드시큐리티폴리시 인증에 대한 전체 예제는
-[아래](#예제)를 참고하길 바란다.
+[아래](#예제)를 참고한다.
 
+### 추천 예제
+
+파드시큐리티폴리시는 새롭고 간결해진 `PodSecurity` {{< glossary_tooltip
+text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되고 있다.
+이 변경에 대한 상세사항은 
+[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
+다음 가이드라인을 참조하여 파드시큐리티폴리시를 새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.
+
+1. 파드시큐리티폴리시를 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
+    - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
+    - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
+    - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
+
+2. `system:serviceaccounts:<namespace>` (여기서 `<namespace>`는 타겟 네임스페이스) 그룹을 사용하여 
+  파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다.
+
+    ```yaml
+    apiVersion: rbac.authorization.k8s.io/v1
+    # 이 클러스터롤바인딩(ClusterRoleBinding)을 통해 "development" 네임스페이스의 모든 파드가 기준 파드시큐리티폴리시(PSP)를 사용할 수 있다.
+    kind: ClusterRoleBinding
+    metadata:
+      name: psp-baseline-namespaces
+    roleRef:
+      kind: ClusterRole
+      name: psp-baseline
+      apiGroup: rbac.authorization.k8s.io
+    subjects:
+    - kind: Group
+      name: system:serviceaccounts:development
+      apiGroup: rbac.authorization.k8s.io
+    - kind: Group
+      name: system:serviceaccounts:canary
+      apiGroup: rbac.authorization.k8s.io
+    ```
 
 ### 문제 해결
 
@@ -661,5 +699,10 @@ spec:
 
 ## {{% heading "whatsnext" %}}
 
+- [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 
+미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)에서 
+파드시큐리티폴리시의 미래에 대해 알아본다.
+
 - 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
+
 - API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
index 4465b8a149..c47f5f995b 100644
--- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 테인트(Taints)와 톨러레이션(Tolerations)
 content_type: concept
 weight: 40
@@ -260,13 +264,27 @@ tolerations:
 
 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
 
-## 컨디션별 노드 테인트하기
+## 컨디션을 기준으로 노드 테인트하기
 
-노드 라이프사이클 컨트롤러는 `NoSchedule` 이펙트가 있는 노드 컨디션에 해당하는
-테인트를 자동으로 생성한다.
-마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다.
+컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여 
+[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
 
-쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을
+스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. 
+이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
+예를 들어 `DiskPressure` 노드 조건이 활성화된 경우 
+컨트롤 플레인은 `node.kubernetes.io/disk-pressure` 테인트를 추가하고 영향을 받는 노드에 새 파드를 할당하지 않는다. 
+`MemoryPressure` 노드 조건이 활성화되면 
+컨트롤 플레인이 `node.kubernetes.io/memory-pressure` 테인트를 추가한다.
+
+새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 조건을 무시하도록 할 수 있다. 
+또한 컨트롤 플레인은 `BestEffort` 이외의 
+{{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}를 가지는 파드에 
+`node.kubernetes.io/memory-pressure` 톨러레이션을 추가한다. 
+이는 쿠버네티스가 `Guaranteed` 또는 `Burstable` QoS 클래스를 갖는 파드(메모리 요청이 설정되지 않은 파드 포함)를 
+마치 그 파드들이 메모리 압박에 대처 가능한 것처럼 다루는 반면, 
+새로운 `BestEffort` 파드는 영향을 받는 노드에 할당하지 않기 때문이다.
+
+데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을
 모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다.
 
   * `node.kubernetes.io/memory-pressure`
@@ -278,7 +296,6 @@ tolerations:
 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에
 임의의 톨러레이션을 추가할 수도 있다.
 
-
 ## {{% heading "whatsnext" %}}
 
 * [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md
index 8a35c2c6a3..b405617118 100644
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@@ -50,7 +50,7 @@ options ndots:5
 ```
 
 요약하면, _test_ 네임스페이스에 있는 파드는 `data.prod` 또는
-`data.prod.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다.
+`data.prod.svc.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다.
 
 ### DNS 레코드
 
diff --git a/content/ko/examples/policy/baseline-psp.yaml b/content/ko/examples/policy/baseline-psp.yaml
new file mode 100644
index 0000000000..679b780096
--- /dev/null
+++ b/content/ko/examples/policy/baseline-psp.yaml
@@ -0,0 +1,74 @@
+apiVersion: policy/v1beta1
+kind: PodSecurityPolicy
+metadata:
+  name: baseline
+  annotations:
+    # 선택 사항: 기본 AppArmor 프로파일을 활성화한다. 이 경우 기본값을 설정해야 한다.
+    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
+    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
+    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
+spec:
+  privileged: false
+  # Moby의 기본 캐퍼빌리티 집합(NET_RAW는 제외되었음)
+  allowedCapabilities:
+    - 'CHOWN'
+    - 'DAC_OVERRIDE'
+    - 'FSETID'
+    - 'FOWNER'
+    - 'MKNOD'
+    - 'SETGID'
+    - 'SETUID'
+    - 'SETFCAP'
+    - 'SETPCAP'
+    - 'NET_BIND_SERVICE'
+    - 'SYS_CHROOT'
+    - 'KILL'
+    - 'AUDIT_WRITE'
+  # hostpath를 제외한 모든 볼륨 타입을 허용
+  volumes:
+    # '코어' 볼륨 타입
+    - 'configMap'
+    - 'emptyDir'
+    - 'projected'
+    - 'secret'
+    - 'downwardAPI'
+    # 클러스터 관리자에 의해 구성된 휘발성 CSI 드라이버와 퍼시스턴트볼륨(PersistentVolume)은 사용하기에 안전하다고 가정한다.
+    - 'csi'
+    - 'persistentVolumeClaim'
+    - 'ephemeral'
+    # hostpath 타입이 아닌 다른 모든 볼륨 타입을 허용
+    - 'awsElasticBlockStore'
+    - 'azureDisk'
+    - 'azureFile'
+    - 'cephFS'
+    - 'cinder'
+    - 'fc'
+    - 'flexVolume'
+    - 'flocker'
+    - 'gcePersistentDisk'
+    - 'gitRepo'
+    - 'glusterfs'
+    - 'iscsi'
+    - 'nfs'
+    - 'photonPersistentDisk'
+    - 'portworxVolume'
+    - 'quobyte'
+    - 'rbd'
+    - 'scaleIO'
+    - 'storageos'
+    - 'vsphereVolume'
+  hostNetwork: false
+  hostIPC: false
+  hostPID: false
+  readOnlyRootFilesystem: false
+  runAsUser:
+    rule: 'RunAsAny'
+  seLinux:
+    # 이 파드시큐리티폴리시는 노드가 SELinux가 아닌 AppArmor를 사용하고 있다고 가정한다.
+    # 파드시큐리티폴리시 SELinux API는 SELinux 파드 보안 표준을 표현할 수 없으므로,
+    # SELinux를 사용하는 경우 더 제한적인 기본값을 선택해야 한다.
+    rule: 'RunAsAny'
+  supplementalGroups:
+    rule: 'RunAsAny'
+  fsGroup:
+    rule: 'RunAsAny'

From 30c6cec1ba2a60dd731550e11843c27d7febd460 Mon Sep 17 00:00:00 2001
From: seokho-son <shsongist@gmail.com>
Date: Mon, 12 Jul 2021 16:08:07 +0900
Subject: [PATCH 6/6] Update outdated files in dev-1.21-ko.6 (p1)

---
 .../configure-access-multiple-clusters.md     |  7 ++++
 .../tasks/administer-cluster/certificates.md  |  5 ++-
 .../highly-available-control-plane.md         | 38 ++++++++++---------
 .../ko/docs/tasks/tls/certificate-rotation.md |  4 +-
 .../configure-redis-using-configmap.md        |  4 +-
 .../ko/examples/policy/restricted-psp.yaml    |  9 ++---
 6 files changed, 40 insertions(+), 27 deletions(-)

diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index 8d25bb7ca6..b3997580f2 100644
--- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -20,6 +20,13 @@ card:
 반드시 존재해야 한다는 것을 의미하는 것은 아니다.
 {{< /note >}}
 
+
+{{< warning >}}
+신뢰할 수 있는 소스의 kubeconfig 파일만 사용해야 한다. 특수 제작된 kubeconfig 파일은 악성코드를 실행하거나 파일을 노출시킬 수 있다.
+신뢰할 수 없는 kubeconfig 파일을 꼭 사용해야 한다면, 셸 스크립트를 사용하는 경우처럼 신중한 검사가 선행되어야 한다.
+{{< /warning>}}
+
+
 ## {{% heading "prerequisites" %}}
 
 {{< include "task-tutorial-prereqs.md" >}}
diff --git a/content/ko/docs/tasks/administer-cluster/certificates.md b/content/ko/docs/tasks/administer-cluster/certificates.md
index 44159fb22e..076f09faf4 100644
--- a/content/ko/docs/tasks/administer-cluster/certificates.md
+++ b/content/ko/docs/tasks/administer-cluster/certificates.md
@@ -116,7 +116,10 @@ weight: 20
         openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
         -CAcreateserial -out server.crt -days 10000 \
         -extensions v3_ext -extfile csr.conf
-1.  인증서를 본다.
+1.  인증서 서명 요청을 확인한다.
+
+        openssl req  -noout -text -in ./server.csr
+1.  인증서를 확인한다.
 
         openssl x509  -noout -text -in ./server.crt
 
diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md
index ae6f79d690..56cc5b3d9a 100644
--- a/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md
+++ b/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md
@@ -1,7 +1,9 @@
 ---
-reviewers:
+
+
 title: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기
 content_type: task
+
 ---
 
 <!-- overview -->
@@ -62,7 +64,7 @@ HA 호환 클러스터를 생성했다면, 여기에 컨트롤 플레인 노드
 HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로
 설정할 필요는 없다.
 
-다음 샘플 커맨드는 기존 HA 호환 클러스터에서 
+다음 샘플 커맨드는 기존 HA 호환 클러스터에서
 컨트롤 플레인 노드를 복제한다.
 
 ```shell
@@ -89,39 +91,41 @@ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
 ## 동작에 실패한 컨트롤 플레인 노드 처리
 
 HA 클러스터의 컨트롤 플레인 노드 중 하나가 동작에 실패하면,
-클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인 노드를 추가하는 것이 가장 좋다.
+클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인
+노드를 추가하는 것이 가장 좋다.
 다음 샘플 커맨드로 이 과정을 시연한다.
 
 1. 손상된 복제본을 제거한다.
 
-    ```shell
-    KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
-    ```
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+```
 
-1. 기존 복제본 대신 새 노드를 추가한다.
+<ol start="2"><li>기존 복제본을 대신할 새 노드를 추가한다.</li></ol>
 
-    ```shell
-    KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
-    ```
+```shell
+KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
 
 ## HA 클러스터에서 컨트롤 플레인 노드 복제에 관한 모범 사례
 
-* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안, 
+* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안,
 해당 영역에 있는 컨트롤 플레인 노드도 모두 동작에 실패할 것이다.
 영역 장애를 극복하기 위해 노드를 여러 영역에 배치한다
 (더 자세한 내용은 [멀티 영역](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다).
 
-* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된 
+* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된
 컨트롤 플레인에서의 합의를 위해서는 지속적 상태(persistent state) 변경 시 두 컨트롤 플레인 노드가 모두 정상적으로 동작 중이어야 한다.
-결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도 
+결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도
 클러스터의 심각한 장애 상태를 초래한다.
-따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은 
+따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은
 단일 노드로 구성된 컨트롤 플레인보다도 못하다.
 
 * 컨트롤 플레인 노드를 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
 클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
 이 작업은 [etcd 관리 가이드](https://etcd.io/docs/v2.3/admin_guide/#member-migration)에 기술한 대로
-Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다).
+Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다.
+(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다)
 
 
 
@@ -152,14 +156,14 @@ Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있
 해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
 로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
 
-### 마스터 서비스와 Kubelet
+### 컨트롤 플레인 서비스와 Kubelet
 
 쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
 시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
 
 * 단일 노드 컨트롤 플레인의 경우, IP 주소는 단일 컨트롤 플레인 노드를 가리킨다.
 
-* 고가용성 컨트롤 플레인의 경우, IP 주소는 마스터 앞의 로드밸런서를 가리킨다.
+* 고가용성 컨트롤 플레인의 경우, IP 주소는 컨트롤 플레인 노드 앞의 로드밸런서를 가리킨다.
 
 마찬가지로 Kubelet은 외부 IP 주소를 사용하여 컨트롤 플레인과 통신한다.
 
diff --git a/content/ko/docs/tasks/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md
index 037f99d87a..eadec87b4f 100644
--- a/content/ko/docs/tasks/tls/certificate-rotation.md
+++ b/content/ko/docs/tasks/tls/certificate-rotation.md
@@ -27,10 +27,10 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다.
 기본적으로 이러한 인증서는 1년 만기로 발급되므로
 너무 자주 갱신할 필요는 없다.
 
-쿠버네티스 1.8은 [kubelet 인증서
+쿠버네티스는 [kubelet 인증서
 갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며,
 이 기능은 현재 인증서의 만료 시한이 임박한 경우,
-새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다.
+새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 기능이다.
 새로운 인증서를 사용할 수 있게 되면
 쿠버네티스 API에 대한 연결을 인증하는데 사용된다.
 
diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
index c1b21d1404..fb1ac922fc 100644
--- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
@@ -55,7 +55,7 @@ EOF
 
 ```shell
 kubectl apply -f example-redis-config.yaml
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml
 ```
 
 Redis 파드 매니페스트의 내용을 검토하고 다음의 사항을 염두에 둔다.
@@ -206,7 +206,7 @@ kubectl exec -it redis -- redis-cli
 
 ```shell
 kubectl delete pod redis
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml
 ```
 
 이제 마지막으로 설정값을 다시 확인해 본다.
diff --git a/content/ko/examples/policy/restricted-psp.yaml b/content/ko/examples/policy/restricted-psp.yaml
index cbaf2758c0..4cdc12639a 100644
--- a/content/ko/examples/policy/restricted-psp.yaml
+++ b/content/ko/examples/policy/restricted-psp.yaml
@@ -5,14 +5,11 @@ metadata:
   annotations:
     seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
     apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
-    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'runtime/default'
     apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
 spec:
   privileged: false
-  # 루트로의 에스컬레이션을 방지하는데 필요하다.
+  # 루트로의 에스컬레이션을 방지하는 데 필요하다.
   allowPrivilegeEscalation: false
-  # 이것은 루트가 아닌 사용자 + 권한 에스컬레이션을 허용하지 않는 것으로 중복이지만,
-  # 심층 방어를 위해 이를 제공한다.
   requiredDropCapabilities:
     - ALL
   # 기본 볼륨 유형을 허용한다.
@@ -22,8 +19,10 @@ spec:
     - 'projected'
     - 'secret'
     - 'downwardAPI'
-    # 클러스터 관리자가 설정한 퍼시스턴트볼륨을 사용하는 것이 안전하다고 가정한다.
+    # 클러스터 관리자에 의해 구성된 휘발성 CSI 드라이버와 퍼시스턴트볼륨(PersistentVolume)의 사용은 안전하다고 가정한다.
+    - 'csi'
     - 'persistentVolumeClaim'
+    - 'ephemeral'
   hostNetwork: false
   hostIPC: false
   hostPID: false