Merge pull request #25415 from kubernetes/dev-1.19-ko.6

Sixth Korean l10n work for release-1.19
2020-12-06 16:03:26 -08:00 · 2020-12-06 16:03:26 -08:00 · 4e90fc3812
parent 7ad4627328 dd950df8bd
commit 4e90fc3812
55 changed files with 760 additions and 545 deletions
--- a/content/ko/_index.html
+++ b/content/ko/_index.html
@ -8,7 +8,7 @@ sitemap:

 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-[쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
+K8s라고도 알려진 [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.

 애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
 {{% /blocks/feature %}}
@ -28,7 +28,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
 {{% /blocks/feature %}}

 {{% blocks/feature image="suitcase" %}}
-#### 어디서나 동작
+#### K8s를 어디서나 실행

 쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다.

@ -44,6 +44,11 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
        <br>
        <br>
        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon NA virtually on November 17-20, 2020</a>
+        <br>
+        <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">Attend KubeCon EU virtually on May 4 – 7, 2021</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
--- a/content/ko/case-studies/newyorktimes/index.html
+++ b/content/ko/case-studies/newyorktimes/index.html
@ -26,9 +26,9 @@ case_study_details:

 <p>Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.</p>

-{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times">}}
-<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/DqS_IPw-c6o" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-<iframe style="padding:1%:" width="380" height="215" src="https://www.youtube.com/embed/Tm4VfJtOHt8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
+{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times" >}}
+{{< youtube DqS_IPw-c6o youtube-quote-sm >}}
+{{< youtube Tm4VfJtOHt8 youtube-quote-sm >}}
 <br>
 "I think once you get over the initial hump, things get a lot easier and actually a lot faster."
 {{< /case-studies/quote >}}
--- a/content/ko/docs/concepts/architecture/controller.md
+++ b/content/ko/docs/concepts/architecture/controller.md
@ -93,8 +93,7 @@ weight: 30
 현재 상태를 보다 가깝게 만든다.

 (실제로 클러스터의 노드를 수평으로 확장하는
-컨트롤러가 있다.
-[클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 본다.)
+[컨트롤러](https://github.com/kubernetes/autoscaler/)가 있다.)

 여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고,
 현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다.
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@ -335,4 +335,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
  섹션을 읽어본다.
 * [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
-* [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.
--- a/content/ko/docs/concepts/cluster-administration/_index.md
+++ b/content/ko/docs/concepts/cluster-administration/_index.md
@ -35,8 +35,6 @@ no_list: true

 ## 클러스터 관리

-* [클러스터 관리](/ko/docs/tasks/administer-cluster/cluster-management/)는 클러스터 라이프사이클과 관련된 몇 가지 주제를 설명한다. 새로운 클러스터 생성, 클러스터의 마스터 및 워커 노드 업그레이드, 노드 유지 관리 수행(예: 커널 업그레이드) 및 실행 중인 클러스터의 쿠버네티스 API 버전 업그레이드
-
 * [노드 관리](/ko/docs/concepts/architecture/nodes/) 방법을 배운다.

 * 공유 클러스터에 대한 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 설정하고 관리하는 방법을 배운다.
--- a/content/ko/docs/concepts/cluster-administration/addons.md
+++ b/content/ko/docs/concepts/cluster-administration/addons.md
@ -25,6 +25,7 @@ content_type: concept
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
 * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
 * [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
+* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
--- a/content/ko/docs/concepts/cluster-administration/networking.md
+++ b/content/ko/docs/concepts/cluster-administration/networking.md
@ -156,6 +156,11 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브
 수 있다. 즉, cni-ipvlan-vpc-k8s는 AWS 내에서 쿠버네티스를
 대규모로 배포하는 데 필요한 네트워크 복잡성을 크게 줄인다.

+### Coil
+
+[Coil](https://github.com/cybozu-go/coil)은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다.
+Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다.
+
 ### 콘티브(Contiv)

 [콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다.
--- a/content/ko/docs/concepts/configuration/configmap.md
+++ b/content/ko/docs/concepts/configuration/configmap.md
@ -88,7 +88,7 @@ data:
 컨피그맵을 사용하여 파드 내부에 컨테이너를 구성할 수 있는
 네 가지 방법이 있다.

-1. 컨테이너의 엔트리포인트에 대한 커맨드 라인 인수
+1. 컨테이너 커맨드와 인수 내에서
 1. 컨테이너에 대한 환경 변수
 1. 애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일 추가
 1. 쿠버네티스 API를 사용하여 컨피그맵을 읽는 파드 내에서 실행할 코드 작성
--- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md
@ -318,9 +318,7 @@ spec:
 선점자 대신 우선순위가 높은 파드를 스케줄링한다.

 이것은 예상된 동작이다. 우선순위가 높은 파드는 우선순위가 낮은 파드를
-대체해야 한다. [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)과
-같은 다른 컨트롤러 작업은,
-결국 보류 중인 파드를 스케줄링할 수 있는 용량을 제공할 수 있다.
+대체해야 한다.

 ### 우선순위가 높은 파드는 우선순위가 낮은 파드보다 우선함

--- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@ -14,7 +14,7 @@ card:
 <!-- body -->
 ## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects}

-*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다.
+*쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.

 * 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
 * 그 애플리케이션이 이용할 수 있는 리소스
--- a/content/ko/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md
@ -189,7 +189,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'

 #### 서비스와 레플리케이션 컨트롤러

-`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
+`services`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `replicationcontrollers`가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다.

 서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.

--- a/content/ko/docs/concepts/policy/resource-quotas.md
+++ b/content/ko/docs/concepts/policy/resource-quotas.md
@ -74,8 +74,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
 | `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음. |
 | `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음. |
 | `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음. |
-| `hugepages-<size>` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의
-휴즈 페이지 요청은 이 값을 초과하지 못함. |
+| `hugepages-<size>` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의 휴즈 페이지 요청은 이 값을 초과하지 못함. |
 | `cpu` | `requests.cpu` 와 같음. |
 | `memory` | `requests.memory` 와 같음. |

--- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
@ -8,125 +8,146 @@ weight: 50

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

-kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 kube-scheduler를 미세 조정할 수 있다.
-
-
+kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능을 사용해서
+확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라
+kube-scheduler를 미세 조정할 수 있다.

 <!-- body -->

 ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기

-쿠버네티스 1.15 이전에는 Kube-scheduler가 CPU 및 메모리와 같은 리소스의 용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용했다. 쿠버네티스 1.16은 우선 순위 기능에 새로운 파라미터를 추가해서 사용자가 용량 대비 요청 비율을 기반으로 노드에 점수를 매기도록 각 리소스의 가중치와 함께 리소스를 지정할 수 있다. 이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들수 있어 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 `requestedToCapacityRatioArguments`라는 구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. 셰이프(shape)는 사용자가 `utilization`과 `score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. 리소스는
-점수를 매길 때 고려할 리소스를 지정하는 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
+쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
+용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를
+통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
+대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
+`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
+동작은 `requestedToCapacityRatioArguments`라는
+구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
+두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
+`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
+조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할
+리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로
+구성된다.

-다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 설정하는 구성의 예시이다.
+다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
+`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
+설정하는 구성의 예시이다.

-```json
-{
-    "kind" : "Policy",
-    "apiVersion" : "v1",
-
-    ...
-
-    "priorities" : [
-
-       ...
-
-      {
-        "name": "RequestedToCapacityRatioPriority",
-        "weight": 2,
-        "argument": {
-          "requestedToCapacityRatioArguments": {
-            "shape": [
-              {"utilization": 0, "score": 0},
-              {"utilization": 100, "score": 10}
-            ],
-            "resources": [
-              {"name": "intel.com/foo", "weight": 3},
-              {"name": "intel.com/bar", "weight": 5}
-            ]
-          }
-        }
-      }
-    ],
-  }
+```yaml
+apiVersion: v1
+kind: Policy
+# ...
+priorities:
+  # ...
+  - name: RequestedToCapacityRatioPriority
+    weight: 2
+    argument:
+      requestedToCapacityRatioArguments:
+        shape:
+          - utilization: 0
+            score: 0
+          - utilization: 100
+            score: 10
+        resources:
+          - name: intel.com/foo
+            weight: 3
+          - name: intel.com/bar
+            weight: 5
 ```

 **이 기능은 기본적으로 비활성화되어 있다.**

-### RequestedToCapacityRatioResourceAllocation 우선 순위 기능 튜닝하기
+### 우선 순위 기능 튜닝하기

-`shape` 는 `RequestedToCapacityRatioPriority` 기능의 동작을 지정하는 데 사용된다.
+`shape` 는 `RequestedToCapacityRatioPriority` 기능의
+동작을 지정하는 데 사용된다.

 ```yaml
- {"utilization": 0, "score": 0},
- {"utilization": 100, "score": 10}
+shape:
+ - utilization: 0
+   score: 0
+ - utilization: 100
+   score: 10
 ```

-위의 인수는 사용률이 0%인 경우 점수는 0, 사용률이 100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을 활성화하려면 점수 값을 다음과 같이 변경해야 한다.
+위의 인수는 `utilization` 이 0%인 경우 `score` 는 0, `utilization` 이
+100%인 경우 10으로 하여, 빈 패킹 동작을 활성화한다. 최소 요청을
+활성화하려면 점수 값을 다음과 같이 변경해야 한다.

 ```yaml
- {"utilization": 0, "score": 100},
- {"utilization": 100, "score": 0}
+shape:
+  - utilization: 0
+    score: 100
+  - utilization: 100
+    score: 0
 ```

 `resources` 는 기본적으로 다음과 같이 설정되는 선택적인 파라미터이다.

 ``` yaml
-"resources": [
-              {"name": "CPU", "weight": 1},
-              {"name": "Memory", "weight": 1}
-            ]
+resources:
+  - name: CPU
+    weight: 1
+  - name: Memory
+    weight: 1
 ```

 다음과 같이 확장된 리소스를 추가하는 데 사용할 수 있다.

 ```yaml
-"resources": [
-              {"name": "intel.com/foo", "weight": 5},
-              {"name": "CPU", "weight": 3},
-              {"name": "Memory", "weight": 1}
-            ]
+resources:
+  - name: intel.com/foo
+    weight: 5
+  - name: CPU
+    weight: 3
+  - name: Memory
+    weight: 1
 ```

-가중치 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한, 가중치는 음수로 설정할 수 없다.
+`weight` 파라미터는 선택 사항이며 지정되지 않은 경우 1로 설정 된다. 또한,
+`weight` 는 음수로 설정할 수 없다.

-### RequestedToCapacityRatioResourceAllocation 우선 순위 기능이 노드에 점수를 매기는 방법
+### 용량 할당을 위해 노드에 점수 매기기

 이 섹션은 이 기능 내부의 세부적인 사항을 이해하려는 사람들을
 위한 것이다.
 아래는 주어진 값의 집합에 대해 노드 점수가 계산되는 방법의 예시이다.

-```
-Requested Resources
+요청된 리소스는 다음과 같다.

+```
 intel.com/foo : 2
 Memory: 256MB
 CPU: 2
+```

-Resource Weights
+리소스의 가중치는 다음과 같다.

+```
 intel.com/foo : 5
 Memory: 1
 CPU: 3
+```

 FunctionShapePoint {{0, 0}, {100, 10}}

-Node 1 Spec
+노드 1의 사양은 다음과 같다.

+```
 Available:
-intel.com/foo : 4
-Memory : 1 GB
-CPU: 8
+  intel.com/foo: 4
+  Memory: 1 GB
+  CPU: 8

 Used:
-intel.com/foo: 1
-Memory: 256MB
-CPU: 1
+  intel.com/foo: 1
+  Memory: 256MB
+  CPU: 1
+```

+노드 점수는 다음과 같다.

-Node Score:
-
+```
 intel.com/foo  = resourceScoringFunction((2+1),4)
               = (100 - ((4-3)*100/4)
               = (100 - 25)
@ -148,24 +169,24 @@ CPU            = resourceScoringFunction((2+1),8)

 NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
            =  5
+```

+노드 2의 사양은 다음과 같다.

-Node 2 Spec
-
+```
 Available:
-intel.com/foo: 8
-Memory: 1GB
-CPU: 8
-
+  intel.com/foo: 8
+  Memory: 1GB
+  CPU: 8
 Used:
+  intel.com/foo: 2
+  Memory: 512MB
+  CPU: 6
+```

-intel.com/foo: 2
-Memory: 512MB
-CPU: 6
-
-
-Node Score:
+노드 점수는 다음과 같다.

+```
 intel.com/foo  = resourceScoringFunction((2+2),8)
               =  (100 - ((8-4)*100/8)
               =  (100 - 50)
@ -189,3 +210,8 @@ NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
            =  7

 ```
+
+## {{% heading "whatsnext" %}}
+
+- [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다.
+- [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다.
--- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
@ -28,15 +28,15 @@ _톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트
 예를 들면 다음과 같다.

 ```shell
-kubectl taint nodes node1 key=value:NoSchedule
+kubectl taint nodes node1 key1=value1:NoSchedule
 ```

-`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key`, 값 `value` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
+`node1` 노드에 테인트을 배치한다. 테인트에는 키 `key1`, 값 `value1` 및 테인트 이펙트(effect) `NoSchedule` 이 있다.
 이는 일치하는 톨러레이션이 없으면 파드를 `node1` 에 스케줄할 수 없음을 의미한다.

 위의 명령으로 추가한 테인트를 제거하려면, 다음을 실행한다.
 ```shell
-kubectl taint nodes node1 key:NoSchedule-
+kubectl taint nodes node1 key1=value1:NoSchedule-
 ```

 PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러레이션은
@ -45,15 +45,15 @@ PodSpec에서 파드에 대한 톨러레이션를 지정한다. 다음의 톨러

 ```yaml
 tolerations:
- key: "key"
+- key: "key1"
  operator: "Equal"
-  value: "value"
+  value: "value1"
  effect: "NoSchedule"
 ```

 ```yaml
 tolerations:
- key: "key"
+- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"
 ```
@ -76,7 +76,7 @@ tolerations:
 operator `Exists` 가 있는 비어있는 `key` 는 모든 키, 값 및 이펙트와 일치하므로
 모든 것이 톨러레이션 된다.

-비어있는 `effect` 는 모든 이펙트를 키 `key` 와 일치시킨다.
+비어있는 `effect` 는 모든 이펙트를 키 `key1` 와 일치시킨다.

 {{< /note >}}

--- a/content/ko/docs/concepts/security/controlling-access.md
+++ b/content/ko/docs/concepts/security/controlling-access.md
@ -110,7 +110,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
 어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.

 어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
-어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
+어드미션 컨트롤러는 단순히 오브젝트를 읽는 요청에는 작동하지 않는다.
 여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.

 이는 다이어그램에 **3**단계로 표시되어 있다.
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@ -152,7 +152,7 @@ spec:
 DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다.
 "`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다.

-엔드포인트 객체는 `hostname` 필드를
+엔드포인트 오브젝트는 `hostname` 필드를
 임의의 엔드포인트 IP 주소로 지정할 수 있다.

 {{< note >}}
@ -253,7 +253,7 @@ spec:
   값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다.
   병합 시 중복되는 도메인은 제거되며,
   쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다.
- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다.
+- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 오브젝트들의 선택적 목록이다.
   이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다.
   이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며,
   병합 시 중복되는 항목은 제거된다.
--- a/content/ko/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md
@ -22,12 +22,14 @@ 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 ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다.
+* [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)를 제공한다.
--- a/content/ko/docs/concepts/services-networking/network-policies.md
+++ b/content/ko/docs/concepts/services-networking/network-policies.md
@ -214,7 +214,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C
 SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다.
 {{< /note >}}

-# 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)
+## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는)

 쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다.

--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@ -89,7 +89,7 @@ volumeBindingMode: Immediate
 등에 대한 완전한 재량권을 가진다. [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 리포지터리에는 대량의 사양을 구현하는 외부 프로비저너를 작성하기
 위한 라이브러리가 있다. 일부 외부 프로비저너의 목록은
-[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns) 리포지터리에 있다.
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 리포지터리에 있다.

 예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부
 프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부
--- a/content/ko/docs/concepts/storage/volume-snapshots.md
+++ b/content/ko/docs/concepts/storage/volume-snapshots.md
@ -28,7 +28,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및

 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다.

-* API 객체인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다.
+* 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)한다.
 * CSI 드라이버에서의 볼륨 스냅샷 기능 유무는 확실하지 않다. 볼륨 스냅샷 서포트를 제공하는 CSI 드라이버는 csi-snapshotter를 사용할 가능성이 높다. 자세한 사항은 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/)를 확인하면 된다.
@ -60,7 +60,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및
 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}
 API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에).

-퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 객체를 삭제한다면, 퍼시스턴트볼륨클레임 객체는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 객체 삭제는 스냅샷이 준비(readyTouse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.
+퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용 중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트를 삭제한다면, 퍼시스턴트볼륨클레임 오브젝트는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 오브젝트 삭제는 스냅샷이 준비(readyToUse) 혹은 중단(aborted) 상태가 될 때까지 연기된다.

 ### 삭제

--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@ -171,13 +171,17 @@ spec:
 ```

 파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는
-파드에는 영향을 주지 않는다. 파드는 템플릿 업데이트를 직접 받지 않는다. 대신,
-수정된 파드 템플릿과 일치하는 새로운 파드가 생성된다.
+파드에는 직접적인 영향을 주지 않는다. 워크로드 리소스의 파드 템플릿을
+변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 한다.

-예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 각 디플로이먼트 오브젝트에 대한 현재
-파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트된 경우, 디플로이먼트는
-기존 파드를 제거하고 업데이트된 템플릿을 기반으로 새로운 파드를 생성해야 한다. 각 워크로드
-리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
+예를 들어, 스테이트풀셋 컨트롤러는 실행 중인 파드가 각 스테이트풀셋 오브젝트에 대한 현재
+파드 템플릿과 일치하는지 확인한다. 스테이트풀셋을 수정하여 파드 템플릿을
+변경하면, 스테이트풀셋이 업데이트된 템플릿을 기반으로 새로운 파드를 생성하기 시작한다.
+결국, 모든 이전의 파드가 새로운 파드로 교체되고, 업데이트가 완료된다.
+
+각 워크로드 리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
+스테이트풀셋에 대해 자세히 알아 보려면,
+스테이트풀셋 기본 튜토리얼에서 [업데이트 전략](/ko/docs/tutorials/stateful-application/basic-stateful-set/#스테이트풀셋-업데이트하기)을 읽어본다.

 노드에서 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}은
 파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@ -284,8 +284,6 @@ graph BT

 ### 클러스터 수준의 기본 제약 조건

-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
 클러스터에 대한 기본 토폴로지 분배 제약 조건을 설정할 수 있다. 기본
 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다.

--- a/content/ko/docs/contribute/_index.md
+++ b/content/ko/docs/contribute/_index.md
@ -1,6 +1,6 @@
 ---
 content_type: concept
-title: 쿠버네티스 문서에 기여하기
+title: K8s 문서에 기여하기
 linktitle: 기여
 main_menu: true
 no_list: true
@ -8,7 +8,7 @@ weight: 80
 card:
  name: contribute
  weight: 10
-  title: 기여 시작하기
+  title: K8s에 기여 시작하기
 ---

 <!-- overview -->
--- a/content/ko/docs/home/_index.md
+++ b/content/ko/docs/home/_index.md
@ -30,7 +30,7 @@ cards:
  button: "튜토리얼 보기"
  button_path: "/ko/docs/tutorials"
 - name: setup
-  title: "클러스터 구축하기"
+  title: "K8s 클러스터 구축하기"
  description: "보유한 자원과 요구에 맞게 동작하는 쿠버네티스를 구축한다."
  button: "쿠버네티스 구축하기"
  button_path: "/ko/docs/setup"
@ -55,7 +55,7 @@ cards:
  button: 문서에 기여하기
  button_path: "/ko/docs/contribute"
 - name: release-notes
-  title: 릴리스 노트
+  title: K8s 릴리스 노트
  description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다.
  button: "쿠버네티스 다운로드"
  button_path: "/docs/setup/release/notes"
--- a/content/ko/docs/reference/access-authn-authz/authorization.md
+++ b/content/ko/docs/reference/access-authn-authz/authorization.md
@ -128,7 +128,7 @@ API 서버 인가를 외부 서비스에 노출시킨다.
 * `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다.
 * `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.

-이러한 API는 반환된 객체의 응답 "status" 필드가 쿼리의 결과인
+이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인
 일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.

 ```bash
--- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
@ -18,95 +18,105 @@ weight: 50
 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
 구분한다.

-  - 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
-    위한 것이다.
-  - 사용자 어카운트는 전역을 대상으로 고려된다.
-    클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 하며, 향후 사용자 리소스는 네임스페이스에 할당되지 않는다.
-    서비스 어카운트는 네임스페이스에 할당된다.
-  - 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
-    여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
-    서비스 어카운트 생성은
-    클러스터 사용자가 특정 작업(즉, 최소 권한 원칙)을 위한 서비스 어카운트를 만들 수 있도록
-    보다 가볍게 만들어졌다.
-  - 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
-  - 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
-    서비스 어카운트는 임시(ad-hoc)로 만들 수도 있고 네임스페이스에 할당된 이름을 가질 수도 있기 때문에
-    이러한 설정은 이식성이 좋다.
+- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
+  위한 것이다.
+- 사용자 어카운트는 전역을 대상으로 고려된다.
+  클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다.
+- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
+  여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
+  서비스 어카운트 생성은
+  클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록
+  보다 가볍게 만들어졌다.
+- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
+- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
+  서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에
+  이러한 설정은 이식성이 좋다.

 ## 서비스 어카운트 자동화

 서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.

-  - 서비스 어카운트 어드미션 컨트롤러
-  - 토큰 컨트롤러
-  - 서비스 어카운트 컨트롤러
+- `ServiceAccount` 어드미션 컨트롤러
+- 토큰 컨트롤러
+- `ServiceAccount` 컨트롤러

-### 서비스 어카운트 어드미션 컨트롤러
+### 서비스어카운트(ServiceAccount) 어드미션 컨트롤러

-파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
-라는 플러그인을 통해 구현된다. 이것은 apiserver의 일부이다.
+파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는
+플러그인을 통해 구현된다.
+이것은 API 서버의 일부이다.
 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.

-  1. 파드에 `ServiceAccount`가 없다면 `ServiceAccount`를 `default`로 설정한다.
-  1. 파드에 참조되는 `ServiceAccount`가 있도록 하고, 그렇지 않으면 이를 거부한다.
-  1. 파드에 `ImagePullSecrets`이 없는 경우 `ServiceAccount`의 `ImagePullSecrets`이 파드에 추가된다.
-  1. 파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
-  1. `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 파드의 각 컨테이너에 `volumeSource`를 추가한다.
+1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를
+   `default`로 설정한다.
+1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면
+   이를 거부한다.
+1. 파드에 `imagePullSecrets`이 없는 경우, 서비스어카운트의
+   `imagePullSecrets`이 파드에 추가된다.
+1. 서비스어카운트 `automountServiceAccountToken` 또는 파드의
+   `automountServiceAccountToken` 이 `false` 로 설정되지 않은 경우
+   파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
+1. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우,
+   `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된
+   파드의 각 컨테이너에 `volumeSource`를 추가한다.

-v1.13부터 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
+`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
 서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
-[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참조한다.
+[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한
+자세한 내용을 참조한다.

 ### 토큰 컨트롤러

-토큰컨트롤러는 컨트롤러 매니저의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
+토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,

- 서비스 어카운트 생성을 지켜보고 API에 접근할 수 있는 시크릿을 생성한다.
- 서비스 어카운트 삭제를 지켜보고 해당하는 모든 서비스 어카운트 토큰 시크릿을 삭제한다.
- 시크릿 추가를 지켜보고 참조된 서비스 어카운트가 존재하는지 확인하고 필요한 경우 시크릿에 토큰을 추가한다.
- 시크릿 삭제를 지켜보고 필요한 경우 해당 서비스 어카운트에서 참조를 제거한다.
+- 서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당
+  서비스어카운트 토큰 시크릿을 생성한다.
+- 서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트
+  토큰 시크릿을 삭제한다.
+- 서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가
+  존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다.
+- 시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서
+  참조를 제거한다.

-서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 옵션을 사용하여 컨트롤러 매니저의 토큰 컨트롤러에 전달해야 한다.
-개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
-마찬가지로 `--service-account-key-file` 옵션을 사용하여 해당 공개키를 쿠버네티스 API 서버에 전달해야 한다.
-공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.
+서비스 어카운트 개인키 파일은 `--service-account-private-key-file`
+플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야
+한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
+마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를
+`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을
+검증하는 데 사용될 것이다.

 #### 추가적인 API 토큰 생성

-컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스 어카운트에 존재하도록 보장한다.
-서비스 어카운트에 대한 추가적인 API 토큰을 생성하기 위해
-서비스 어카운트를 참조하는 어노테이션과 함께 `ServiceAccountToken` 유형의 시크릿을 생성하면
+컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다.
+서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해
+서비스어카운트를 참조하는 어노테이션과 함께 `kubernetes.io/service-account-token` 유형의 시크릿을 생성하면
 컨트롤러가 새로 생성된 토큰으로 갱신한다.

-secret.json:
+다음은 시크릿에 대한 샘플 구성이다.

-```json
-{
-    "kind": "Secret",
-    "apiVersion": "v1",
-    "metadata": {
-        "name": "mysecretname",
-        "annotations": {
-            "kubernetes.io/service-account.name": "myserviceaccount"
-        }
-    },
-    "type": "kubernetes.io/service-account-token"
-}
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecretname
+  annotations:
+    kubernetes.io/service-account.name: myserviceaccount
+type: kubernetes.io/service-account-token
 ```

 ```shell
-kubectl create -f ./secret.json
+kubectl create -f ./secret.yaml
 kubectl describe secret mysecretname
 ```

-#### 서비스 어카운트 토큰 삭제/무효화
+#### 서비스 어카운트 토큰 시크릿 삭제/무효화

 ```shell
 kubectl delete secret mysecretname
 ```

-### 서비스 어카운트 컨트롤러
+### 서비스어카운트 컨트롤러

-서비스 어카운트 컨트롤러는 네임스페이스에 있는 서비스 어카운트를 관리하고
-"default"라는 이름의 서비스 어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
+서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고
+"default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
--- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
@ -83,8 +83,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | |
 | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
-| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
-| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | |
 | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | |
 | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | 베타 | 1.10 | |
@ -137,12 +135,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `RuntimeClass` | `true` | 베타 | 1.14 | |
 | `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
 | `SCTPSupport` | `true` | 베타 | 1.19 | |
-| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
-| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | |
 | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
-| `ServiceAppProtocol` | `false` | 알파 | 1.18 | |
+| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
 | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
 | `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
 | `ServiceTopology` | `false` | 알파 | 1.17 | |
@ -209,6 +206,9 @@ 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` | `true` | 베타 | 1.16 | 1.16 |
+| `CustomResourceDefaulting` | `true` | GA | 1.17 | - |
 | `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 |
 | `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 |
 | `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - |
--- a/content/ko/docs/reference/glossary/api-group.md
+++ b/content/ko/docs/reference/glossary/api-group.md
@ -0,0 +1,19 @@
+---
+title: API 그룹(API Group)
+id: api-group
+date: 2019-09-02
+full_link: /ko/docs/concepts/overview/kubernetes-api/#api-groups
+short_description: >
+  쿠버네티스 API의 연관된 경로들의 집합.
+
+aka:
+tags:
+- fundamental
+- architecture
+---
+쿠버네티스 API의 연관된 경로들의 집합. 
+
+<!--more-->
+API 서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있다. 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있다. API 그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있다. API 그룹은 REST 경로 및 직렬화된 오브젝트의 `apiVersion` 필드에 지정된다.
+
+* 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-groups)을 참조한다.
--- a/content/ko/docs/reference/glossary/mirror-pod.md
+++ b/content/ko/docs/reference/glossary/mirror-pod.md
@ -3,18 +3,18 @@ title: 미러 파드(Mirror Pod)
 id: mirror-pod
 date: 2019-08-06
 short_description: >
-  Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 객체.
+  Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 오브젝트.

 aka:
 tags:
 - fundamental
 ---
  Kubelet이 {{< glossary_tooltip text="스태틱 파드" term_id="static-pod" >}}를
-  표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 객체
+  표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 오브젝트

 <!--more-->
 Kubelet이 설정에서 스태틱 파드를 찾으면, 자동으로 쿠버네티스
-API 서버에 파드 객체 생성을 시도한다. 이렇게 생성된 파드를
+API 서버에 파드 오브젝트 생성을 시도한다. 이렇게 생성된 파드를
 API 서버에서 확인할 수는 있지만, API 서버를 통해 제어할 수는 없다.

 (예를 들어, 미러 파드를 제거하더라도 kubelet 데몬이 해당 파드를 멈추지 않는다.)
--- a/content/ko/docs/reference/glossary/object.md
+++ b/content/ko/docs/reference/glossary/object.md
@ -0,0 +1,19 @@
+---
+title: 오브젝트(Object)
+id: object
+date: 2020-12-1
+full_link: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
+short_description: >
+   클러스터 상태의 일부를 나타내는 쿠버네티스 시스템의 엔티티이다.
+aka:
+tags:
+- fundamental
+---
+쿠버네티스 시스템의 엔티티이다. 쿠버네티스 API가 클러스터의 상태를 나타내기 위해
+사용하는 엔티티이다.
+<!--more-->
+쿠버네티스 오브젝트는 일반적으로 "의도를 담은 레코드"이다. 당신이 오브젝트를 생성하게 되면, 쿠버네티스
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 그 아이템이 실제 존재함을 보장하기 위해
+지속적으로 작동한다.
+객체를 생성함으로써 당신의 클러스터의 워크로드 해당 부분이 어떻게 보이길 원하는지 쿠버네티스 시스템에 효과적으로 알리는 것이다.
+이것은 당신의 클러스터의 의도한 상태이다.
--- a/content/ko/docs/reference/glossary/uid.md
+++ b/content/ko/docs/reference/glossary/uid.md
@ -14,5 +14,5 @@ tags:

 <!--more--> 

-쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록 상 유사한 개체의 출현을 서로 구분하기 위함이다.
+쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다.

--- a/content/ko/docs/reference/kubectl/cheatsheet.md
+++ b/content/ko/docs/reference/kubectl/cheatsheet.md
@ -86,6 +86,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml      # 여러 파일로 부터 생성
 kubectl apply -f ./dir                         # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
 kubectl apply -f https://git.io/vPieo          # url로부터 리소스(들) 생성
 kubectl create deployment nginx --image=nginx  # nginx 단일 인스턴스를 시작
+
+# "Hello World"를 출력하는 잡(Job) 생성
+kubectl create job hello --image=busybox -- echo "Hello World"
+
+# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
+kubectl create cronjob hello --image=busybox   --schedule="*/1 * * * *" -- echo "Hello World"    
+
 kubectl explain pods                           # 파드 매니페스트 문서를 조회

 # stdin으로 다수의 YAML 오브젝트 생성
--- a/content/ko/docs/reference/kubectl/overview.md
+++ b/content/ko/docs/reference/kubectl/overview.md
@ -59,7 +59,7 @@ kubectl [command] [TYPE] [NAME] [flags]
   * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`

      * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
-     예: `kubectl get pod -f ./pod.yaml`
+     예: `kubectl get -f ./pod.yaml`

 * `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>

--- a/content/ko/docs/reference/using-api/health-checks.md
+++ b/content/ko/docs/reference/using-api/health-checks.md
@ -0,0 +1,101 @@
+---
+title: 쿠버네티스 API 헬스(health) 엔드포인트
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+쿠버네티스 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}는 현재 상태를 나타내는 API 엔드포인트를 제공한다.
+이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다.
+
+<!-- body -->
+
+## 헬스를 위한 API 엔드포인트
+
+쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(`healthz`, `livez` 와 `readyz`)를 제공한다.
+`healthz` 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스  v1.16 버전 이후), 대신 보다 구체적인 `livez` 와 `readyz` 엔드포인트를 사용해야 한다.
+`livez` 엔드포인트는 `--livez-grace-period` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 시작 대기 시간을 지정할 수 있다.
+`/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다.
+API 서버의 `health`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
+상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다.
+아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.
+
+다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.
+
+모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
+이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.
+
+```shell
+curl -k https://localhost:6443/livez?verbose
+```
+
+인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다.
+
+```shell
+kubectl get --raw='/readyz?verbose'
+```
+
+출력은 다음과 같다.
+
+    [+]ping ok
+    [+]log ok
+    [+]etcd ok
+    [+]poststarthook/start-kube-apiserver-admission-initializer ok
+    [+]poststarthook/generic-apiserver-start-informers ok
+    [+]poststarthook/start-apiextensions-informers ok
+    [+]poststarthook/start-apiextensions-controllers ok
+    [+]poststarthook/crd-informer-synced ok
+    [+]poststarthook/bootstrap-controller ok
+    [+]poststarthook/rbac/bootstrap-roles ok
+    [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+    [+]poststarthook/start-cluster-authentication-info-controller ok
+    [+]poststarthook/start-kube-aggregator-informers ok
+    [+]poststarthook/apiservice-registration-controller ok
+    [+]poststarthook/apiservice-status-available-controller ok
+    [+]poststarthook/kube-apiserver-autoregistration ok
+    [+]autoregister-completion ok
+    [+]poststarthook/apiservice-openapi-controller ok
+    healthz check passed
+
+또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다.
+쿼리 파라미터는 다음 예와 같이 조합될 수 있다.
+
+```shell
+curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+```
+
+출력에서 etcd 체크가 제외된 것을 보여준다.
+
+    [+]ping ok
+    [+]log ok
+    [+]etcd excluded: ok
+    [+]poststarthook/start-kube-apiserver-admission-initializer ok
+    [+]poststarthook/generic-apiserver-start-informers ok
+    [+]poststarthook/start-apiextensions-informers ok
+    [+]poststarthook/start-apiextensions-controllers ok
+    [+]poststarthook/crd-informer-synced ok
+    [+]poststarthook/bootstrap-controller ok
+    [+]poststarthook/rbac/bootstrap-roles ok
+    [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+    [+]poststarthook/start-cluster-authentication-info-controller ok
+    [+]poststarthook/start-kube-aggregator-informers ok
+    [+]poststarthook/apiservice-registration-controller ok
+    [+]poststarthook/apiservice-status-available-controller ok
+    [+]poststarthook/kube-apiserver-autoregistration ok
+    [+]autoregister-completion ok
+    [+]poststarthook/apiservice-openapi-controller ok
+    [+]shutdown ok
+    healthz check passed
+
+## 개별 헬스 체크
+
+{{< feature-state state="alpha" >}}
+
+각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
+개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
+`<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
+이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
+
+```shell
+curl -k https://localhost:6443/livez/etcd
+```
--- a/content/ko/docs/setup/best-practices/cluster-large.md
+++ b/content/ko/docs/setup/best-practices/cluster-large.md
@ -1,122 +1,120 @@
 ---
-title: 대형 클러스터 구축
+title: 대형 클러스터에 대한 고려 사항
 weight: 20
 ---

-## 지원
-
-{{< param "version" >}} 버전에서, 쿠버네티스는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는, 다음 기준을 *모두* 만족하는 설정을 지원한다.
+클러스터는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서 관리하는
+쿠버네티스 에이전트를 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}(물리
+또는 가상 머신)의 집합이다.
+쿠버네티스 {{<param "version">}}는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는,
+쿠버네티스는 다음 기준을 *모두* 만족하는 설정을 수용하도록 설계되었다.

+* 노드 당 파드 100 개 이하
 * 노드 5000개 이하
 * 전체 파드 150000개 이하
 * 전체 컨테이너 300000개 이하
-* 노드 당 파드 100개 이하

+노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은
+클러스터 배포 방법에 따라 다르다.

-## 설치
+## 클라우드 프로바이더 리소스 쿼터 {#quota-issues}

-클러스터는 쿠버네티스 에이전트가 구동하는 노드(물리 또는 가상 머신)의 집합이며, "마스터"(클러스터-수준 컨트롤 플레인)에 의해 관리된다.
+여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해
+고려할 점은 다음과 같다.

-보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다.
-
-하지만 단순히 값만 매우 크게 바꾼다면, 클라우드 프로바이더에 따라 셋업 스크립트가 실패할 수도 있다. 예를 들어, GCE에 배포할 때 쿼터 이슈가 발생하여 클러스터 구축이 실패할 수 있다.
-
-큰 쿠버네티스 클러스터를 설정할 때는 다음 이슈들을 고려해야 한다.
-
-### 쿼터 문제
-
-여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해 고려할 점:
-
-* CPU, IP 등의 쿼터를 늘린다.
-  * 예를 들어, [GCE의 경우](https://cloud.google.com/compute/docs/resource-quotas) 다음에 관한 쿼터를 늘릴 수 있다.
+* 다음과 같은 클라우드 리소스에 대한 쿼터 증가를 요청한다.
+    * 컴퓨터 인스턴스
    * CPU
-    * VM 인스턴스
-    * 전체 영구 디스크 예약
+    * 스토리지 볼륨
    * 사용 중인 IP 주소
-    * 방화벽 규칙
-    * 포워딩 규칙
-    * 라우트
-    * 대상 풀
-* 일부 클라우드 프로바이더는 VM 생성 속도에 상한이 있어, 셋업 스크립트 수행 간 새로운 노드 VM을 생성하는 사이사이에 대기시간이 추가되는 작은 배치가 걸릴 수 있다.
+    * 패킷 필터링 규칙 세트
+    * 로드밸런서 개수
+    * 로그 스트림
+* 일부 클라우드 프로바이더는 새로운 인스턴스 생성 속도에 상한이 있어, 클러스터 확장 작업 간 새로운 노드를 일괄적으로 배치하고, 배치 간에 일시 중지한다.
+
+## 컨트롤 플레인 컴포넌트
+
+대규모 클러스터의 경우, 충분한 컴퓨트 및 기타 리소스가 있는 컨트롤 플레인이
+필요하다.
+
+일반적으로 장애 영역 당 하나 또는 두 개의 컨트롤 플레인 인스턴스를
+실행하고, 해당 인스턴스를 수직으로(vertically) 먼저 확장한 다음 (수직) 규모로 하락하는
+지점에 도달한 후 수평으로(horizontally) 확장한다.
+
+내결함성을 제공하려면 장애 영역 당 하나 이상의 인스턴스를 실행해야 한다. 쿠버네티스
+노드는 동일한 장애 영역에 있는 컨트롤 플레인 엔드포인트로 트래픽을
+자동으로 조정하지 않는다. 그러나, 클라우드 프로바이더는 이를 수행하기 위한 자체 메커니즘을 가지고 있을 수 있다.
+
+예를 들어, 관리형 로드 밸런서를 사용하여 장애 영역 _A_ 의
+kubelet 및 파드에서 시작되는 트래픽을 전송하도록 로드 밸런서를 구성하고, 해당 트래픽을
+_A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 컨트롤 플레인 호스트 또는
+엔드포인트 장애 영역 _A_ 이 오프라인이 되면, 영역 _A_ 의 노드에 대한
+모든 컨트롤 플레인 트래픽이 이제 영역간에 전송되고 있음을 의미한다. 각 영역에서 여러 컨트롤 플레인 호스트를
+실행하면 가용성이 낮아진다.

 ### etcd 저장소

-큰 클러스터의 성능 향상을 위해, 우리는 이벤트를 각각의 전용 etcd 인스턴스에 저장한다.
+큰 클러스터의 성능 향상을 위해, 사용자는 이벤트 오브젝트를 각각의
+전용 etcd 인스턴스에 저장한다.

 클러스터 생성시의 부가 스트립트이다.
+클러스터 생성 시에 (사용자 도구를 사용하여) 다음을 수행할 수 있다.

 * 추가 ectd 인스턴스 시작 및 설정
-* 이벤트를 저장하기 위한 api-server 설정
+* 이벤트를 저장하기 위한 {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} 설정

-### 마스터 크기와 마스터 구성 요소
+## 애드온 리소스

-GCE/구글 쿠버네티스 엔진 및 AWS에서, `kube-up`은 클러스터 내 노드의 수에 따라 마스터용으로 적합한 VM 크기를 자동으로 설정한다.
-기타 다른 프로바이더의 경우, 수동으로 설정해야 한다. 참고로 GCE에 적용하는 크기는 다음과 같다.
+쿠버네티스 [리소스 제한](/ko/docs/concepts/configuration/manage-resources-containers/)은
+파드와 컨테이너가 다른 컴포넌트에 영향을 줄 수 있는 메모리 누수 및 기타 방식의 영향을
+최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용되는 것과 마찬가지로
+{{< glossary_tooltip text="애드온" term_id="addons" >}}에도 적용될 수 있으며
+적용되어야 한다.

-* 1-5 노드: n1-standard-1
-* 6-10 노드: n1-standard-2
-* 11-100 노드: n1-standard-4
-* 101-250 노드: n1-standard-8
-* 251-500 노드: n1-standard-16
-* 500 노드 이상: n1-standard-32
-
-AWS에 적용하는 크기는 다음과 같다.
-
-* 1-5 노드: m3.medium
-* 6-10 노드: m3.large
-* 11-100 노드: m3.xlarge
-* 101-250 노드: m3.2xlarge
-* 251-500 노드: c4.4xlarge
-* 500 노드 이상: c4.8xlarge
-
-{{< note >}}
-구글 쿠버네티스 엔진에서, 마스터 노드 크기는 클러스터의 크기에 따라 자동적으로 조절된다. 자세한 사항은 [이 블로그 글](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html)을 참고하라.
-
-AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 그대로이며 변경되지 않는다. 이후에 클러스터를 스케일 업/다운하거나 수동으로 노드를 추가/제거하거나 클러스터 오토스케일러를 사용하더라도 그렇다.
-{{< /note >}}
-
-### 애드온 자원
-
-[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](https://pr.k8s.io/10653/files)과 [#10778](https://pr.k8s.io/10778/files) 참고).
-
-예시:
+예를 들어, 로깅 컴포넌트에 대한 CPU 및 메모리 제한을 설정할 수 있다.

 ```yaml
+  ...
  containers:
  - name: fluentd-cloud-logging
-    image: k8s.gcr.io/fluentd-gcp:1.16
+    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi
 ```

-힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](https://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](https://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다.
+애드온의 기본 제한은 일반적으로 중소형 쿠버네티스 클러스터에서
+각 애드온을 실행한 경험에서 수집된 데이터를 기반으로 한다. 대규모 클러스터에서
+실행할 때, 애드온은 종종 기본 제한보다 많은 리소스를 소비한다.
+이러한 값을 조정하지 않고 대규모 클러스터를 배포하면, 애드온이
+메모리 제한에 계속 도달하기 때문에 지속적으로 종료될 수 있다.
+또는, 애드온이 실행될 수 있지만 CPU 시간 슬라이스 제한으로 인해
+성능이 저하된다.

-많은 노드를 가진 클러스터를 생성할 때는 애드온 리소스 이슈를 피하기 위해 다음을 고려하라.
+클러스터 애드온 리소스 문제가 발생하지 않도록, 노드가 많은 클러스터를
+만들 때, 다음 사항을 고려한다.

-* 다음 애드온을 사용한다면, 클러스터의 크기를 확장할 때 그에 맞게 메모리와 CPU 상한을 규모를 조정하라 (전체 클러스터를 담당하는 각 레플리카는, 메모리와 CPU 사용량이 대체로 클러스터의 크기/부하에 따라 비율적으로 증가할 것이다).
-  * [InfluxDB와 Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns, dnsmasq, 사이드카](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
-  * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
-* 다음 애드온들을 쓴다면 클러스터 크기에 따라 레플리카 수를 조절해준다(각각 레플리카가 여러 개 두면 늘어나는 부하를 처리하는 데 도움이 되지만, 레플리카 당 부하도 약간 늘어나게 되므로 CPU/메모리 상한을 높이는 것을 고려해보자):
-  * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
-* 다음의 애드온들을 쓴다면, 클러스터 크기에 따라 각각 메모리와 CPU 상한을 조금 더 높이자(노드 당 레플리카 1개만 있어도 클러스터 부하량/크기에 따라 CPU/메모리 사용율은 조금씩 증가한다).
-  * [ElasticSearch 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [GCP 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+* 일부 애드온은 수직으로 확장된다. 클러스터 또는 전체 장애 영역을
+  제공하는 애드온 레플리카가 하나 있다. 이러한 애드온의 경우, 클러스터를 확장할 때
+  요청과 제한을 늘린다.
+* 많은 애드온은 수평으로 확장된다. 더 많은 파드를 실행하여 용량을 추가하지만,
+  매우 큰 클러스터에서는 CPU 또는 메모리 제한을 약간 높여야 할 수도 있다.
+  VerticalPodAutoscaler는 _recommender_ 모드에서 실행되어 요청 및 제한에 대한
+  제안 수치를 제공할 수 있다.
+* 일부 애드온은 {{< glossary_tooltip text="데몬셋(DaemonSet)"
+  term_id="daemonset" >}}에 의해 제어되는 노드 당 하나의 복사본으로 실행된다(예: 노드 수준 로그 수집기). 수평
+  확장 애드온의 경우와 유사하게, CPU 또는 메모리 제한을 약간 높여야
+  할 수도 있다.

-힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](https://issue.k8s.io/16185)과
-[#22940](https://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면,
- 힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자.
+## {{% heading "whatsnext" %}}

-애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는
-[컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라.
+`VerticalPodAutoscaler` 는 리소스 요청 및 파드 제한을 관리하는 데 도움이 되도록
+클러스터에 배포할 수 있는 사용자 정의 리소스이다.
+클러스터에 중요한 애드온을 포함하여 클러스터 컴포넌트를 확장하는 방법에 대한
+자세한 내용은 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)를
+방문하여 배워본다.

-### 시작 시 사소한 노드 오류 허용
-
-다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고
-`kube-up.sh`을 실행하면 제대로 기동되지 않은 극소수의 노드들 때문에 실패할 수 있다.
-현재로서는 두 가지 선택지가 있다. 클러스터를 재시작하거나(`kube-down.sh` 한 후 다시 `kube-up.sh` ),
-`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다.
-이렇게 하면 `NUM_NODES`에 못 미치는 경우에도 `kube-up.sh`이 성공할 수 있다.
-실패 원인에 따라 일부 노드들이 늦게 결합되거나, 클러스터가 `NUM_NODES - ALLOWED_NOTREADY_NODES`의 크기로 남을 수 있다.
+[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
+여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
+노드 수를 실행할 수 있도록 도와준다.
--- a/content/ko/docs/setup/best-practices/node-conformance.md
+++ b/content/ko/docs/setup/best-practices/node-conformance.md
@ -22,7 +22,11 @@ weight: 30

 노드 적합성 테스트는 다음 순서로 진행된다.

-1. 테스트 프레임워크는 Kublet을 테스트하기 위해 로컬 마스터를 시작하기 때문에, Kublet이 localhost를 가르키도록 `--api-servers="http://localhost:8080"`를 사용한다. 고려해야 할 다른 Kubelet 플래그들은 다음과 같다.
+1. kubelet에 대한 `--kubeconfig` 옵션의 값을 계산한다. 예를 들면, 다음과 같다.
+   `--kubeconfig = / var / lib / kubelet / config.yaml`.
+   테스트 프레임워크는 kubelet을 테스트하기 위해 로컬 컨트롤 플레인을 시작하기 때문에,
+   `http://localhost:8080` 을 API 서버의 URL로 사용한다.
+   사용할 수 있는 kubelet 커맨드 라인 파라미터가 몇 개 있다.
  * `--pod-cidr`: `kubenet`을 사용 중이라면, 임의의 CIDR을 Kubelet에 지정해주어야 한다. 예) `--pod-cidr=10.180.0.0/24`.
  * `--cloud-provider`: `--cloud-provider=gce`를 사용 중이라면, 테스트 실행 시에는 제거해야 한다.

--- a/content/ko/docs/setup/production-environment/container-runtimes.md
+++ b/content/ko/docs/setup/production-environment/container-runtimes.md
@ -1,7 +1,7 @@
 ---
 title: 컨테이너 런타임
 content_type: concept
-weight: 10
+weight: 20
 ---
 <!-- overview -->

--- a/content/ko/docs/setup/production-environment/turnkey/_index.md
+++ b/content/ko/docs/setup/production-environment/turnkey/_index.md
@ -1,4 +0,0 @@
---
-title: 턴키 클라우드 솔루션
-weight: 30
---
--- a/content/ko/docs/setup/release/version-skew-policy.md
+++ b/content/ko/docs/setup/release/version-skew-policy.md
@ -0,0 +1,154 @@
+---
+title: 쿠버네티스 버전 및 버전 차이(skew) 지원 정책
+content_type: concept
+weight: 30
+---
+
+<!-- overview -->
+이 문서는 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이를 설명한다. 
+특정 클러스터 배포 도구는 버전 차이에 대한 추가적인 제한을 설정할 수 있다.
+
+
+<!-- body -->
+
+## 지원되는 버전
+
+쿠버네티스 버전은 **x.y.z**로 표현되는데,
+여기서 **x**는 메이저 버전, **y**는 마이너 버전, **z**는 [시맨틱 버전](https://semver.org/) 용어에 따른 패치 버전이다.
+자세한 내용은 [쿠버네티스 릴리스 버전](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)을 참조한다.
+
+쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
+
+보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다. 
+패치 릴리스는 각 브랜치별로 [정기적인 주기](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다.
+
+[릴리스 관리자](https://git.k8s.io/sig-release/release-managers.md) 그룹이 이러한 결정 권한을 가진다.
+
+자세한 내용은 쿠버네티스 [패치 릴리스](https://git.k8s.io/sig-release/releases/patch-releases.md) 페이지를 참조한다.
+
+## 지원되는 버전 차이 
+
+### kube-apiserver
+
+[고가용성(HA) 클러스터](/docs/setup/production-environment/tools/kubeadm/high-availability/)에서 최신 및 가장 오래된 `kube-apiserver` 인스턴스가 각각 한 단계 마이너 버전 내에 있어야 한다.
+
+예:
+
+* 최신 `kube-apiserver`는 **{{< skew latestVersion >}}** 이다.
+* 다른 `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 을 지원한다.
+
+### kubelet
+
+`kubelet`은 `kube-apiserver`보다 최신일 수 없으며, 2단계의 낮은 마이너 버전까지 지원한다.
+
+예:
+
+* `kube-apiserver`가 **{{< skew latestVersion >}}** 이다.
+* `kubelet`은 **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}** 및 **{{< skew oldestMinorVersion >}}** 을 지원한다.
+
+{{< note >}}
+HA 클러스터의 `kube-apiserver` 인스턴스 사이에 버전 차이가 있으면 허용되는 `kubelet` 버전의 범위도 줄어든다.
+{{</ note >}}
+
+예:
+
+* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다.
+* `kubelet`은 **{{< skew prevMinorVersion >}}** 및 **{{< skew oldestMinorVersion >}}** 을 지원한다(**{{< skew latestVersion >}}** 는  `kube-apiserver`의 **{{< skew prevMinorVersion >}}** 인스턴스보다 최신 버전이기 때문에 지원하지 않는다).
+
+### kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager
+
+`kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 그들과 통신하는 `kube-apiserver` 인스턴스보다 최신 버전이면 안 된다. `kube-apiserver` 마이너 버전과 일치할 것으로 예상하지만, 최대 한 단계 낮은 마이너 버전까지는 허용한다(실시간 업그레이드를 지원하기 위해서).
+
+예:
+
+* `kube-apiserver`은 **{{< skew latestVersion >}}** 이다.
+* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 **{{< skew latestVersion >}}** 과 **{{< skew prevMinorVersion >}}** 을 지원한다.
+
+{{< note >}}
+HA 클러스터의 `kube-apiserver` 인스턴스 간에 버전 차이가 존재하고 이러한 구성 요소가 클러스터의 모든 `kube-apiserver` 인스턴스와 통신할 수 있는 경우(예를 들어, 로드 밸런서를 통해서)에는 구성 요소의 허용하는 버전의 범위도 줄어든다.
+{{< /note >}}
+
+예:
+
+* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다.
+* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 모든 `kube-apiserver` 인스턴스로 라우팅하는 로드 밸런서와 통신한다.
+* `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`는 **{{< skew prevMinorVersion >}}** 에서 지원한다(**{{< skew latestVersion >}}** 는 `kube-apiserver` 인스턴스의 **{{< skew prevMinorVersion >}}** 버전보다 최신이기 때문에 지원하지 않는다).
+
+### kubectl
+
+`kubectl`은 `kube-apiserver`의 한 단계 마이너 버전(이전 또는 최신) 내에서 지원한다.
+
+예:
+
+* `kube-apiserver`은 **{{< skew latestVersion >}}** 이다.
+* `kubectl`은 **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 을 지원한다.
+
+{{< note >}}
+HA 클러스터의 `kube-apiserver` 인스턴스 간에 버전 차이가 있으면 지원되는 `kubectl` 버전의 범위도 줄어든다.
+{{< /note >}}
+
+예:
+
+* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 이다.
+* `kubectl`은 **{{< skew latestVersion >}}** 및 **{{< skew prevMinorVersion >}}** 에서 지원한다(다른 버전은 `kube-apiserver` 인스턴스 중에 한 단계 이상의 마이너 버전 차이가 난다).
+
+## 지원되는 구성 요소 업그레이드 순서
+
+구성요소 간 지원되는 버전 차이는 구성요소를 업그레이드하는 순서에 영향을 준다.
+이 섹션에서는 기존 클러스터를 버전 **{{< skew prevMinorVersion >}}** 에서 버전 **{{< skew latestVersion >}}** 로 전환하기 위해 구성 요소를 업그레이드하는 순서를 설명한다.
+
+### kube-apiserver
+
+사전 요구 사항:
+
+* 단일 인스턴스 클러스터에서 기존 `kube-apiserver` 인스턴스는 **{{< skew prevMinorVersion >}}** 이어야 한다.
+* HA 클러스터에서 모든 `kube-apiserver` 인스턴스는 **{{< skew prevMinorVersion >}}** 또는 **{{< skew latestVersion >}}** 이어야 한다(이것은 `kube-apiserver` 인스턴스 간의 가장 최신과 오래된 버전의 차이를 최대 1개의 마이너 버전의 차이로 보장한다).
+* 이 서버와 통신하는 `kube-controller-manager`, `kube-scheduler` 그리고 `cloud-controller-manager`의 버전은 **{{< skew prevMinorVersion >}}** 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니고 새로운 API서버 버전의 마이너 1개의 버전 내에 있음을 보장한다).
+* 모든 `kubelet` 인스턴스는 버전  **{{< skew prevMinorVersion >}}** 또는 **{{< skew oldestMinorVersion >}}** 이어야 한다(이것은 기존 API서버 버전보다 최신 버전이 아니며, 새로운 API서버 버전의 2개의 마이너 버전 내에 있음을 보장한다).
+* 등록된 어드미션 웹훅은 새로운 `kube-apiserver` 인스턴스가 전송하는 데이터를 처리할 수 있다:
+  * `ValidatingWebhookConfiguration` 그리고 `MutatingWebhookConfiguration` 오브젝트는 **{{< skew latestVersion >}}** 에 추가된 REST 리소스의 새 버전을 포함하도록 업데이트한다(또는 v1.15 이상에서 사용 가능한 [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) 설정을 사용).
+  * 웹훅은 자신에게 전송될 REST리소스의 새버전과 **{{< skew latestVersion >}}** 에서 기존 버전에 추가된 새로운 필드를 처리할 수 있다.
+
+`kube-apiserver`를 **{{< skew latestVersion >}}** 으로 업그레이드
+
+{{< note >}}
+[API 지원 중단](/docs/reference/using-api/deprecation-policy/) 및
+[API 변경 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
+에 대한 프로젝트 정책에서는 단일 클러스터일지라도 업그레이드할 때 `kube-apiserver`의 마이너 버전을 건너뛰지 않도록 요구한다.
+{{< /note >}}
+
+### kube-controller-manager, kube-scheduler 그리고 cloud-controller-manager
+
+사전 요구 사항:
+
+* `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 이여야 한다(HA 클러스터에서 `kube-apiserver` 인스턴스와 통신할 수 있는 구성 요소를 업그레이드 전에 모든 `kube-apiserver` 인스턴스는 업그레이드되어야 한다).
+
+`kube-controller-manager`, `kube-scheduler` 및 `cloud-controller-manager` 를 **{{< skew latestVersion >}}** 으로 업그레이드한다.
+
+### kubelet
+
+사전 요구 사항:
+
+*  `kubelet`과 통신하는 `kube-apiserver` 인스턴스는 **{{< skew latestVersion >}}** 이어야 한다.
+
+필요에 따라서 `kubelet` 인스턴스를 **{{< skew latestVersion >}}** 으로 업그레이드할 수 있다(또는 **{{< skew prevMinorVersion >}}** 아니면 **{{< skew oldestMinorVersion >}}** 으로 유지할 수 있음).
+
+{{< warning >}}
+클러스터 안의 `kubelet` 인스턴스를 `kube-apiserver`의 버전보다 2단계 낮은 버전으로 실행하는 것을 권장하지 않는다:
+
+* `kube-apiserver`를 업그레이드한다면 한 단계 낮은 버전으로 업그레이드해야 한다.
+* 이것은 관리되고 있는 3단계의 마이너 버전보다 낮은 `kubelet`을 실행할 가능성을 높인다.
+{{</ warning >}}
+
+### kube-proxy
+
+* `kube-proxy`는 반드시 `kubelet`과 동일한 마이너 버전이어야 한다.
+* `kube-proxy`는 반드시 `kube-apiserver` 보다 최신 버전이면 안 된다.
+* `kube-proxy`는 `kube-apiserver` 보다 2단계 낮은 마이너 버전 이내여야 한다.
+
+예:
+
+`kube-proxy` 버전이 **{{< skew oldestMinorVersion >}}** 인 경우:
+
+* `kubelet` 버전도 반드시 **{{< skew oldestMinorVersion >}}** 와 동일한 마이너 버전이어야 한다.
+* `kube-apiserver` 버전은 반드시 **{{< skew oldestMinorVersion >}}** 에서 **{{< skew latestVersion >}}** 사이 이어야 한다.
--- a/content/ko/docs/tasks/administer-cluster/cluster-management.md
+++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md
@ -1,217 +0,0 @@
---
-title: 클러스터 관리
-content_type: concept
---
-
-<!-- overview -->
-
-이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
-클러스터의 마스터와 워커 노드들의 업그레이드,
-노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
-쿠버네티스 API 버전 업그레이드.
-
-<!-- body -->
-
-## 클러스터 생성과 설정
-
-일련의 머신들에 쿠버네티스를 설치하려면, 환경에 맞게 기존의 [시작하기](/ko/docs/setup/) 안내서들 중에 하나를 선택하여 참조한다.
-
-## 클러스터 업그레이드
-
-클러스터 업그레이드 상태의 현황은 제공자에 따라 달라지며, 몇몇 릴리스들은 업그레이드에 각별한 주의를 요하기도 한다. 관리자들에게는 클러스터 업그레이드에 앞서 [릴리스 노트](https://git.k8s.io/kubernetes/CHANGELOG/README.md)와 버전에 맞는 업그레이드 노트 모두를 검토하도록 권장하고 있다.
-
-### Azure Kubernetes Service (AKS) 클러스터 업그레이드
-
-Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
-현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다.
-
-### Google Compute Engine 클러스터 업그레이드
-
-Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
-재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
-동일한 Persistent Disk(PD)를 유지한다.
-
-GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
-순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
-레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다.
-
-open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다.
-
-`cluster/gce/upgrade.sh -h`를 실행하여 사용법을 알아볼 수 있다.
-
-예를 들어, 마스터만 특정 버전(v1.0.2)로 업그레이드하려고 한다면 다음과 같이 커맨드를 사용한다.
-
-```shell
-cluster/gce/upgrade.sh -M v1.0.2
-```
-
-이 대신에, 전체 클러스터를 최신 안정 릴리스로 업그레이드하려고 한다면 다음과 같이 커맨드를 사용한다.
-
-```shell
-cluster/gce/upgrade.sh release/stable
-```
-
-### Google Kubernetes Engine 클러스터 업그레이드
-
-Google Kubernetes Engine은 자동으로 마스터 구성요소들(예. `kube-apiserver`, `kube-scheduler`)을 최신 버전으로 업데이트한다. 이는 운영체제와 마스터 상에서 동작하는 다른 구성요소들의 업그레이드를 처리하기도 한다.
-
-노드 업그레이드 프로세스는 사용자가 직접 시작하는 방식이며 [Google Kubernetes Engine 문서](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade)에 설명되어 있다.
-
-### Amazon EKS 클러스터 업그레이드
-Amazon EKS 클러스터는 eksctl, AWS 관리 콘솔, AWS CLI를 사용해서 마스터 구성요소를 업그레이드할 수 있다. 프로세스는 사용자가 시작하며 [Amazon EKS 문서](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)에 설명되어 있다.
-
-### Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) 클러스터 업그레이드
-
-Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레인을 가질 수 있도록 사용자를 대신하여 Oracle 컨트롤 플레인 내에 마스터 노드들의 세트를 (그리고 etcd 노드들과 같은 관련 쿠버네티스 인프라스트럭처를) 생성하고 관리한다. 또한 이 마스터 노드들을 다운타임 없이 쿠버네티스 신규 버전으로 유연하게 업그레이드할 수도 있다. 이 기능들은 [OKE 문서](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm)에 설명되어 있다.
-
-### 다른 플랫폼들의 클러스터 업그레이드
-
-다른 제공자들과 도구들은 업그레이드를 다른 방식으로 관리한다. 이들의 업그레이드를 위해서는 이들의 주요 문서를 참조하기를 권장한다.
-
-* [kops](https://github.com/kubernetes/kops)
-* [kubespray](https://github.com/kubernetes-sigs/kubespray)
-* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
-* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
-* ...
-
-위 리스트에서 언급되지 않은 플랫폼의 클러스터 업그레이드는 [버전 차이 지원(skew)](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order)
-페이지 상의 구성요소 업그레이드 순서 부분을 확인해보는 것이 좋다.
-
-## 클러스터 크기 재조정
-
-[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인
-클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다.
-GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
-[Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면
-`Compute > Compute Engine > Instance groups > your group > Edit group`에서
-인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
-
-```shell
-gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE
-```
-
-인스턴스 그룹은 신규 머신들에 적절한 이미지를 넣고 시작하는 것을 관리하는 반면에
-Kubelet은 자신의 노드를 API 서버에 등록하여 스케줄링할 수 있도록 해준다.
-사용자가 인스턴스 그룹을 스케일 다운하면 시스템은 임의로 노드들을 선택하여 죽일 것이다.
-
-다른 환경에서는 사용자가 직접 머신을 구성하고 어떤 머신에서 API 서버가 동작하는지를 Kubelet에 알려줘야 할 수도 있다.
-
-### Azure Kubernetes Service (AKS) 클러스터 크기 재조정
-
-Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터의 크기를 재조정할 수 있게 해주며
-[Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/scale-cluster)에서
-이를 설명하고 있다.
-
-
-### 클러스터 오토스케일링
-
-GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
-재조정하도록 클러스터를 구성할 수 있다.
-
-[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼
-사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다.
-이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
-여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
-다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.
-
-Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
-추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다.
-
-Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
-더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다.
-
-Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다.
-
-GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
-cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다.
-
-* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다.
-* `KUBE_AUTOSCALER_MIN_NODES` - 클러스터 노드들의 최소 개수.
-* `KUBE_AUTOSCALER_MAX_NODES` - 클러스터 노드들의 최대 개수.
-
-예제:
-
-```shell
-KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
-```
-
-Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
-생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
-전달하여 cluster autoscaler를 구성할 수 있다.
-
-예제:
-
-```shell
-gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
-```
-
-```shell
-gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
-```
-
-**Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.**
-
-cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
-autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
-문서를 참조하기를 바란다.
-
-## 노드 유지보수
-
-(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
-Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
-(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
-노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
-레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
-복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다.
-
-만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다.
-
-노드에 스케줄할 수 없도록 표시하면서 해당 노드 상의 모든 파드들을 자연스럽게 종료하기 위해 `kubectl drain`을 사용한다.
-
-```shell
-kubectl drain $NODENAME
-```
-
-이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다.
-
-레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
-
-레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
-
-해당 노드에 유지보수 작업을 수행한다.
-
-해당 노드가 다시 스케줄될 수 있도록 한다.
-
-```shell
-kubectl uncordon $NODENAME
-```
-
-해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
-자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
-이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.)
-상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
-
-## 고급 주제들
-
-### 클러스터에서 API 버전을 ON/OFF 하기
-
-특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
-전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
-예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
-이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`)
-
-### 클러스터에서 스토리지 API 버전을 변경
-
-클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다.
-지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
-쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다.
-
-### 구성 파일을 신규 API 버전으로 변경
-
-다른 API 버전들 간에 구성 파일을 전환하는데 `kubectl convert` 커맨드를 사용할 수 있다.
-
-```shell
-kubectl convert -f pod.yaml --output-version v1
-```
-
-옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다.
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@ -137,7 +137,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
 ### 윈도우 워커 노드 조인(joining)
 {{< note >}}
 `Containers` 기능을 설치하고 도커를 설치해야 한다.
-[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)에서 설치에 대한 내용을 참고할 수 있다.
+[윈도우 서버에 Docker Engine - Enterprise 설치](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 설치에 대한 내용을 참고할 수 있다.
 {{< /note >}}

 {{< note >}}
--- a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
@ -45,8 +45,8 @@ kubectl create namespace qos-example

 파드에 Guaranteed QoS 클래스 할당을 위한 전제 조건은 다음과 같다.

-* 파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
-* 파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
+* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다.
+* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다.

 이것은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과
 메모리 요청량을 갖고 있고, 200MiB로 동일하다. 해당 컨테이너는 CPU 상한과 CPU 요청량을 가지며, 700 milliCPU로 동일하다.
--- a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@ -45,7 +45,7 @@ kubectl describe pods ${POD_NAME}
 사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우
 몇 가지 방법을 시도할 수 있다.

-* 클러스터에 [노드를 더 추가하기](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-크기-재조정).
+* 클러스터에 노드를 더 추가하기.

 * pending 상태인 파드를 위한 공간을 확보하기 위해
  [불필요한 파드 종료하기](/ko/docs/concepts/workloads/pods/#pod-termination)
--- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md
@ -29,7 +29,7 @@ kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네
 플러그인 관리자이다.

 {{< caution >}}
-Krew [플러그인 인덱스](https://index.krew.dev/)를 통해 사용할 수 있는 kubectl 플러그인은
+Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사용할 수 있는 kubectl 플러그인은
 보안 감사를 받지 않는다. 써드파티 플러그인은 시스템에서 실행되는 임의의
 프로그램이므로, 사용자는 이를 인지한 상태에서 설치하고 실행해야 한다.
 {{< /caution >}}
@ -42,7 +42,7 @@ Krew [플러그인 인덱스](https://index.krew.dev/)를 통해 사용할 수
 서로의 이름과 겹치는 유효한 플러그인 파일에 대한 경고도 포함된다.

 [Krew](https://krew.dev/)를 사용하여 커뮤니티가 관리하는
-[플러그인 인덱스](https://index.krew.dev/)에서 `kubectl`
+[플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)에서 `kubectl`
 플러그인을 검색하고 설치할 수 있다.

 #### 제한 사항
@ -351,7 +351,7 @@ CLI 런타임 리포지터리에 제공된 도구 사용법의 예제는
 방식을 제공한다. 이렇게 하면, 모든 대상 플랫폼(리눅스, 윈도우, macOS 등)에
 단일 패키징 형식을 사용하고 사용자에게 업데이트를 제공한다.
 Krew는 또한 다른 사람들이 여러분의 플러그인을 검색하고 설치할 수 있도록
-[플러그인 인덱스](https://index.krew.dev/)를
+[플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를
 유지 관리한다.


@ -384,5 +384,3 @@ kubectl 플러그인의 배포 패키지를
  궁금한 사항이 있으면,
  [SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다.
 * kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다.
-
-
--- a/content/ko/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md
@ -44,7 +44,7 @@ kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아
 kubectl delete -f <file.yaml> --cascade=false
 ```

-`kubectl delete` 에 `--cascade=false` 를 사용함으로써, 스테이트풀셋 객체가 삭제 된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.
+`kubectl delete` 에 `--cascade=false` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다.

 ```shell
 kubectl delete pods -l app=myapp
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@ -16,29 +16,27 @@ Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는

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

-
 이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다.
-[메트릭-서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다.
-Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다.
-메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다.
+[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여
+[메트릭 API](https://github.com/kubernetes/metrics)를 통해 메트릭을 제공해야 한다.
+Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면,
+[메트릭-서버 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다.

 Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우,
-버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다.
-또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
+버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가
+사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
 마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우,
-버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다.
+버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부
+메트릭 API와 통신이 가능해야 한다.
 자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다.

-
-
 <!-- steps -->

 ## php-apache 서버 구동 및 노출

-Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다.
-Dockerfile은 다음과 같다.
+Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다.

-```
+```dockerfile
 FROM php:5-apache
 COPY index.php /var/www/html/index.php
 RUN chmod a+rx index.php
@ -46,7 +44,7 @@ RUN chmod a+rx index.php

 index.php는 CPU 과부하 연산을 수행한다.

-```
+```php
 <?php
  $x = 0.0001;
  for ($i = 0; $i <= 1000000; $i++) {
@ -61,11 +59,12 @@ index.php는 CPU 과부하 연산을 수행한다.

 {{< codenew file="application/php-apache.yaml" >}}

-
 다음의 명령어를 실행한다.
+
 ```shell
 kubectl apply -f https://k8s.io/examples/application/php-apache.yaml
 ```
+
 ```
 deployment.apps/php-apache created
 service/php-apache created
@ -85,6 +84,7 @@ service/php-apache created
 ```shell
 kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
 ```
+
 ```
 horizontalpodautoscaler.autoscaling/php-apache autoscaled
 ```
@ -94,10 +94,10 @@ horizontalpodautoscaler.autoscaling/php-apache autoscaled
 ```shell
 kubectl get hpa
 ```
+
 ```
 NAME         REFERENCE                     TARGET    MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   0% / 50%  1         10        1          18s
-
 ```

 아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다 (``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다).
@ -116,10 +116,10 @@ kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin
 ```shell
 kubectl get hpa
 ```
+
 ```
 NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   305% / 50%  1         10        1          3m
-
 ```

 CPU 소비가 305%까지 증가하였다.
@ -128,6 +128,7 @@ CPU 소비가 305%까지 증가하였다.
 ```shell
 kubectl get deployment php-apache
 ```
+
 ```
 NAME         READY   UP-TO-DATE   AVAILABLE   AGE
 php-apache   7/7      7           7           19m
@ -151,6 +152,7 @@ php-apache   7/7      7           7           19m
 ```shell
 kubectl get hpa
 ```
+
 ```
 NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m
@ -159,6 +161,7 @@ php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1
 ```shell
 kubectl get deployment php-apache
 ```
+
 ```
 NAME         READY   UP-TO-DATE   AVAILABLE   AGE
 php-apache   1/1     1            1           27m
@ -170,8 +173,6 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
 레플리카 오토스케일링은 몇 분 정도 소요된다.
 {{< /note >}}

-
-
 <!-- discussion -->

 ## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링
@ -417,7 +418,8 @@ HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl des
 ```shell
 kubectl describe hpa cm-test
 ```
-```shell
+
+```
 Name:                           cm-test
 Namespace:                      prom
 Labels:                         <none>
@ -472,6 +474,7 @@ HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를
 ```shell
 kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
 ```
+
 ```
 horizontalpodautoscaler.autoscaling/php-apache created
 ```
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
@ -434,7 +434,14 @@ behavior:
    selectPolicy: Disabled
 ```

+## 암시적 유지 관리 모드 비활성화

+HPA 구성 자체를 변경할 필요없이 대상에 대한
+HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한
+레플리카 수가 0으로 설정되고, HPA의 최소 레플리카 수가 0 보다 크면, 대상의
+의도한 레플리카 수 또는 HPA의 최소 레플리카 수를 수동으로 조정하여
+다시 활성화할 때까지 HPA는 대상 조정을
+중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정).

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

--- a/content/ko/docs/tutorials/configuration/configure-java-microservice/_index.md
+++ b/content/ko/docs/tutorials/configuration/configure-java-microservice/_index.md
@ -0,0 +1,4 @@
+---
+title: "예제: Java 마이크로서비스 구성하기"
+weight: 10
+---
--- a/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html
+++ b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html
@ -0,0 +1,30 @@
+---
+title: "대화형 튜토리얼 - Java 마이크로서비스 구성하기"
+weight: 20
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                터미널 화면을 조작하려면, 데스크톱/태블릿 버전을 사용하기 바란다.
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/9" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+        </div>
+    </main>
+
+</div>
+
+</body>
+</html>
--- a/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md
+++ b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice.md
@ -0,0 +1,39 @@
+---
+title: "MicroProfile, 컨피그맵(ConfigMaps) 및 시크릿(Secrets)을 사용하여 구성 외부화(externalizing)"
+content_type: tutorial
+weight: 10
+---
+
+<!-- overview -->
+
+이 튜토리얼에서는 마이크로서비스의 구성을 외부화하는 방법과 이유를 알아본다. 특히, 쿠버네티스 컨피그맵과 시크릿을 사용하여 환경 변수를 설정한 다음 MicroProfile Config를 이용한 사용 방법을 배운다.
+
+
+## {{% heading "prerequisites" %}}
+
+### 쿠버네티스 컨피그맵 및 시크릿 생성하기
+쿠버네티스에서 도커 컨테이너에 대한 환경 변수를 설정하는 방법에는 Dockerfile, kubernetes.yml, 쿠버네티스 컨피그맵 및 쿠버네티스 시크릿이 있다. 이 튜토리얼에서는 사용자의 마이크로서비스에 값을 주입하기 위한 환경 변수를 설정하기 위해 후자의 두 가지를 사용하는 방법에 대해 배운다. 컨피그맵 및 시크릿을 사용할 때의 이점 중 하나는 여러 다른 컨테이너에 대해 서로 다른 환경 변수에 할당되는 것을 포함하여, 여러 컨테이너에서 다시 사용할 수 있다는 것이다.
+
+컨피그맵은 기밀이 아닌 키-값 쌍을 저장하는 API 오브젝트이다. 대화형 튜토리얼에서는 컨피그맵을 사용하여 애플리케이션의 이름을 저장하는 방법을 배운다. 컨피그맵에 대한 자세한 정보는 [여기](/docs/tasks/configure-pod-container/configure-pod-configmap/)에서 문서를 찾을 수 있다.
+
+시크릿은 키-값 쌍을 저장하는 데도 사용되지만, 기밀/민감한 정보를 위한 것이며 Base64 인코딩을 사용하여 저장된다는 점에서 컨피그맵과 다르다. 따라서 시크릿은 자격 증명, 키 및 토큰과 같은 항목을 저장하는 데 적합한 선택이 된다. 이 내용은 대화형 튜토리얼에서 수행할 것이다. 시크릿에 대한 자세한 내용은 [여기](/ko/docs/concepts/configuration/secret/)에서 문서를 찾을 수 있다.
+
+
+### 코드로부터 구성 외부화
+구성은 일반적으로 환경에 따라 변경되기 때문에, 외부화된 애플리케이션 구성(externalized application configuration)은 유용하다. 이를 이루기 위해, Java의 CDI(콘텍스트와 의존성 주입) 및 MicroProfile Config를 사용한다. MicroProfile Config는 클라우드 네이티브 마이크로서비스를 개발하고 배포하기 위한 개방형 Java 기술 세트인 MicroProfile의 기능이다.
+
+CDI는 느슨하게 결합된 협업 빈(beans)을 통해 애플리케이션을 어셈블할 수 있는 표준 종속성 주입(standard dependency injection) 기능을 제공한다. MicroProfile Config는 애플리케이션, 런타임 및 환경을 포함한 다양한 소스에서 구성 속성을 가져오는 표준 방법을 앱과 마이크로서비스에 제공한다. 소스의 정의된 우선순위에 따라 속성은 애플리케이션이 API를 통해 접근할 수 있는 단일 속성 집합으로 자동 결합된다. 대화형 튜토리얼에서는 CDI와 MicroProfile을 함께 사용하여 쿠버네티스 컨피그맵 및 시크릿을 통한 외부 제공 속성을 검색하고 애플리케이션 코드에 삽입한다.
+
+많은 오픈 소스 프레임워크와 런타임이 MicroProfile Config를 구현하고 지원한다. 대화형 튜토리얼을 통해 클라우드 네이티브 앱과 마이크로서비스를 빌드하고 실행하기 위한 유연한 오픈 소스 Java 런타임인 Open Liberty를 사용하게 될 것이다. 그러나, 모든 MicroProfile 호환 런타임을 대신 사용할 수 있다.
+
+
+## {{% heading "objectives" %}}
+
+* 쿠버네티스 컨피그맵 및 시크릿 생성
+* MicroProfile Config를 사용하여 마이크로서비스 구성 주입
+
+
+<!-- lessoncontent -->
+
+## 예제: MicroProfile, 컨피그맵 및 시크릿를 사용하여 구성 외부화
+### [대화형 튜토리얼 시작](/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/)
--- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
@ -65,7 +65,7 @@ resources:
 EOF
 ```

-컨피그 맵과 파드 개체를 생성하도록 kustomization 디렉터리를 적용한다.
+컨피그 맵과 파드 오브젝트를 생성하도록 kustomization 디렉터리를 적용한다.

 ```shell
 kubectl apply -k .
--- a/content/ko/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html
@ -1,6 +1,7 @@
 ---
 title: 쿠버네티스 기초 학습
 linkTitle: 쿠버네티스 기초 학습
+no_list: true
 weight: 10
 card:
  name: tutorials
--- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@ -76,7 +76,7 @@ MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필
 ## kustomization.yaml 생성하기

 ### 시크릿 생성자 추가
-[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다.
+[시크릿](/ko/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 오브젝트이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 오브젝트를 관리한다. `kustomization.yaml`의 제너레이터로 시크릿을 생성할 수 있다.

 다음 명령어로 `kustomization.yaml` 내에 시크릿 제네레이터를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다.

@ -131,7 +131,7 @@ EOF
 kubectl apply -k ./
 ```

-이제 모든 개체가 존재하는지 확인할 수 있다.
+이제 모든 오브젝트가 존재하는지 확인할 수 있다.

 1. 시크릿이 존재하는지 다음 명령어를 실행하여 확인한다.

--- a/content/ko/docs/tutorials/stateful-application/zookeeper.md
+++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md
@ -18,7 +18,7 @@ weight: 40
 -   [파드](/ko/docs/concepts/workloads/pods/)
 -   [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
 -   [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
-   [퍼시스턴트볼륨](/ko/docs/concepts/storage/volumes/)
+-   [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
 -   [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
 -   [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
 -   [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
@ -38,7 +38,7 @@ weight: 40
 이 튜토리얼을 마치면 다음에 대해 알게 된다.

 -   어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
-   어떻게 지속적해서 컨피그맵을 이용해서 앙상블을 설정하는가.
+-   어떻게 앙상블을 일관되게 설정하는가.
 -   어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
 -   어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.

@ -761,7 +761,7 @@ fi
 kubectl get pod -w -l app=zk
 ```

-다른 창에서 `zk-0` 파드의 파일시스템에서 `zkOk.sh` 스크립트를 삭제하기 위해 다음 명령어를 이용하자.
+다른 창에서 `zk-0` 파드의 파일시스템에서 `zookeeper-ready` 스크립트를 삭제하기 위해 다음 명령어를 이용하자.

 ```shell
 kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
--- a/content/ko/training/_index.html
+++ b/content/ko/training/_index.html
@ -10,16 +10,19 @@ class: training
 <section class="call-to-action">
  <div class="main-section">
    <div class="call-to-action" id="cta-certification">
-      <div class="logo-certification cta-image cta-image-before" id="logo-cka">
-        <img src="/images/training/kubernetes-cka-white.svg"/>
-      </div>
-      <div class="logo-certification cta-image cta-image-after" id="logo-ckad">
-        <img src="/images/training/kubernetes-ckad-white.svg"/>
-      </div>
      <div class="cta-text">
        <h2>클라우드 네이티브 커리어를 구축하세요</h2>
        <p>쿠버네티스는 클라우드 네이티브 무브먼트의 핵심입니다. 리눅스 재단이 제공하는 교육과 인증 프로그램을 통해 커리어에 투자하고, 쿠버네티스를 배우며, 클라우드 네이티브 프로젝트를 성공적으로 수행하세요.</p>
      </div>
+      <div class="logo-certification cta-image" id="logo-cka">
+        <img src="/images/training/kubernetes-cka-white.svg"/>
+      </div>
+      <div class="logo-certification cta-image" id="logo-ckad">
+        <img src="/images/training/kubernetes-ckad-white.svg"/>
+      </div>
+      <div class="logo-certification cta-image" id="logo-cks">
+        <img src="/images/training/kubernetes-cks-white.svg"/>
+      </div>
    </div>
  </div>
 </section>
@ -74,31 +77,36 @@ class: training
  </div>
 </div>

-<section>
+<section id="get-certified">
  <div class="main-section padded">
-    <center>
-        <h2>쿠버네티스 공인 자격 획득하기</h2>
-    </center>
+    <h2>쿠버네티스 공인 자격 획득하기</h2>
    <div class="col-container">
      <div class="col-nav">
-        <center>
          <h5>
            <b>공인 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer, CKAD)</b>
          </h5>
          <p>공인 쿠버네티스 애플리케이션 개발자 시험은 사용자가 쿠버네티스의 클라우드 네이티브 애플리케이션을 디자인, 구축, 구성과 노출을 할 수 있음을 인증합니다.</p>
+          <p>CKAD는 애플리케이션 리소스를 정의하고 핵심 기본 요소를 사용하여 쿠버네티스에서 확장 가능한 애플리케이션 및 도구를 빌드, 모니터링하고 문제를 해결합니다.</p>
          <br>
          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">인증으로 이동하기</a>
-        </center>
      </div>
      <div class="col-nav">
-        <center>
          <h5>
            <b>공인 쿠버네티스 관리자(Certified Kubernetes Administrator, CKA)</b>
          </h5>
          <p>공인 쿠버네티스 관리자(CKA) 프로그램은 CKA가 쿠버네티스 관리자 직무을 수행할 수 있는 기술, 지식과 역량을 갖추고 있음을 보장합니다.</p>
+          <p>공인 쿠버네티스 관리자는 기본 설치를 수행하고 프로덕션 등급의 쿠버네티스 클러스터를 구성하고 관리하는 능력을 보여줍니다.</p>
          <br>
          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">인증으로 이동하기</a>
-        </center>
+      </div>
+      <div class="col-nav">
+          <h5>
+            <b>공인 쿠버네티스 보안 전문가(Certified Kubernetes Security Specialist, CKS)</b>
+          </h5>
+          <p>공인 쿠버네티스 보안 전문가(CKS) 프로그램은 CKS가 다양한 모범 사례에 대해 능숙하고 자신감을 가지도록 보장합니다. CKS 인증은 빌드, 배포 및 런타임 중에 컨테이너 기반 애플리케이션과 쿠버네티스 플랫폼을 보호하는 기술을 다룹니다.</p>
+          <p><em>CKS 지원자는 CKS에 참여하기 전에 충분한 쿠버네티스 전문 지식을 보유하고 있음을 입증하기 위해 현재 버전의 공인 쿠버네티스 관리자(CKA) 인증을 보유해야 합니다.</em></p>
+          <br>
+          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/" target="_blank" class="button">인증으로 이동하기</a>
      </div>
    </div>
  </div>