[ko] Update outdated files in dev-1.21-ko.3 (p2)

2021-05-28 22:16:18 +09:00 · 2021-05-28 22:16:18 +09:00 · a9fb2d35d0
parent 4e6a6b8965
commit a9fb2d35d0
19 changed files with 118 additions and 28 deletions
--- a/content/ko/community/_index.html
+++ b/content/ko/community/_index.html
@ -24,7 +24,8 @@ cid: community
 <a href="#videos">비디오</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#discuss">토론</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 <a href="#events">이벤트와 모임들</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="#news">새소식</a>
+<a href="#news">새소식</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+<a href="/releases">릴리즈</a>

 </div>
 <br class="mobile"><br class="mobile">
--- a/content/ko/docs/concepts/cluster-administration/addons.md
+++ b/content/ko/docs/concepts/cluster-administration/addons.md
@ -23,7 +23,7 @@ content_type: concept
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
 * [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
-* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
+* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
 * [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 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
--- a/content/ko/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ko/docs/concepts/extend-kubernetes/operator.md
@ -113,11 +113,13 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하

 {{% thirdparty-content %}}

+* [Charmed Operator Framework](https://juju.is/)
 * [kubebuilder](https://book.kubebuilder.io/) 사용하기
 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
 * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를
  사용하여 직접 구현하기
 * [오퍼레이터 프레임워크](https://operatorframework.io)
+* [shell-operator](https://github.com/flant/shell-operator)

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

--- a/content/ko/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md
@ -21,7 +21,7 @@ sitemap:
 <!-- body -->
 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

-쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.
+쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.

 ## 여정 돌아보기

--- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md
@ -32,14 +32,15 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝
 레이블을 최대한 활용하려면 모든 리소스 오브젝트에
 적용해야 한다.

-| Key                                 | Description           | Example  | Type |
+| 키                                  | 설명                  | 예시     | 타입 |
 | ----------------------------------- | --------------------- | -------- | ---- |
 | `app.kubernetes.io/name`            | 애플리케이션 이름 | `mysql` | 문자열 |
 | `app.kubernetes.io/instance`        | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `mysql-abcxzy` | 문자열 |
 | `app.kubernetes.io/version`         | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 |
 | `app.kubernetes.io/component`       | 아키텍처 내 구성요소 | `database` | 문자열 |
 | `app.kubernetes.io/part-of`         | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 |
-| `app.kubernetes.io/managed-by`  | 애플리케이션의 작동을 관리하는데 사용되는 도구 | `helm` | 문자열 |
+| `app.kubernetes.io/managed-by`      | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 |
+| `app.kubernetes.io/created-by`      | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 |

 위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다.

@ -54,6 +55,7 @@ metadata:
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/created-by: controller-manager
 ```

 ## 애플리케이션과 애플리케이션 인스턴스
@ -76,7 +78,7 @@ WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비

 `Deployment` 와 `Service` 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다.

-`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는데 사용한다.
+`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는 데 사용한다.
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@ -102,9 +104,9 @@ metadata:

 Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을
 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다.
-다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다.
+다음 식별자는 이 애플리케이션을 배포하는 데 사용하는 오브젝트의 시작을 보여준다.

-WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다.
+WordPress를 배포하는 데 다음과 같이 `Deployment` 로 시작한다.

 ```yaml
 apiVersion: apps/v1
@ -152,7 +154,7 @@ metadata:
 ...
 ```

-`Service` 는 WordPress의 일부로 MySQL을 노출하는데 이용한다.
+`Service` 는 WordPress의 일부로 MySQL을 노출하는 데 이용한다.

 ```yaml
 apiVersion: v1
--- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
@ -35,7 +35,7 @@ weight: 30
 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다.

 {{< note >}}
-    쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다.
+    `kube-` 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다.
 {{< /note >}}

 ### 네임스페이스 조회
--- a/content/ko/docs/concepts/scheduling-eviction/_index.md
+++ b/content/ko/docs/concepts/scheduling-eviction/_index.md
@ -1,7 +1,37 @@
 ---
-title: "스케줄링과 축출(eviction)"
+title: "스케줄링, 선점(Preemption), 축출(Eviction)"
 weight: 90
+content_type: concept
 description: >
-  쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다.
-  축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다.
+  쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 
+  파드를 노드에 할당하는 것을 말한다.
+  선점은 우선순위가 높은 파드가 노드에 스케줄될 수 있도록 
+  우선순위가 낮은 파드를 종료시키는 과정을 말한다.
+  축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다.
+no_list: true
 ---
+
+쿠버네티스에서, 스케줄링은 {{<glossary_tooltip text="kubelet" term_id="kubelet">}}이 파드를 실행할 수 있도록 
+{{<glossary_tooltip text="파드" term_id="pod">}}를 
+{{<glossary_tooltip text="노드" term_id="node">}}에 할당하는 것을 말한다.
+선점은 {{<glossary_tooltip text="우선순위" term_id="pod-priority">}}가 높은 파드가 노드에 스케줄될 수 있도록 
+우선순위가 낮은 파드를 종료시키는 과정을 말한다.
+축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다.
+
+## 스케줄링
+
+* [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)
+* [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)
+* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
+* [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)
+* [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)
+* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
+* [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/)
+
+## 파드 중단(disruption)
+
+{{<glossary_definition term_id="pod-disruption" length="all">}}
+
+* [파드 우선순위와 선점](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
+* [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)
--- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
@ -80,7 +80,6 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 1. [스케줄링 정책](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다.
 1. [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.

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

 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
--- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
+++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
@ -1,7 +1,7 @@
 ---
 title: 파드 오버헤드
 content_type: concept
-weight: 20
+weight: 30
 ---

 <!-- overview -->
--- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
--- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
@ -5,7 +5,7 @@

 title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
 content_type: concept
-weight: 30
+weight: 80
 ---

 <!-- overview -->
--- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@ -3,7 +3,7 @@

 title: 스케줄러 성능 튜닝
 content_type: concept
-weight: 80
+weight: 100
 ---

 <!-- overview -->
--- a/content/ko/docs/concepts/storage/persistent-volumes.md
+++ b/content/ko/docs/concepts/storage/persistent-volumes.md
@ -540,11 +540,11 @@ spec:

 ### 접근 모드

-클레임은 특정 접근 모드로 저장소를 요청할 때 볼륨과 동일한 규칙을 사용한다.
+클레임은 특정 접근 모드로 저장소를 요청할 때 [볼륨과 동일한 규칙](#접근-모드)을 사용한다.

 ### 볼륨 모드

-클레임은 볼륨과 동일한 규칙을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다.
+클레임은 [볼륨과 동일한 규칙](#볼륨-모드)을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다.

 ### 리소스

--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@ -149,9 +149,9 @@ CSI | 1.14 (alpha), 1.16 (beta)
 ### 볼륨 바인딩 모드

 `volumeBindingMode` 필드는 [볼륨 바인딩과 동적
-프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다.
+프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다. 설정되어 있지 않으면, `Immediate` 모드가 기본으로 사용된다.

-기본적으로, `Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨
+`Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨
 바인딩과 동적 프로비저닝이 즉시 발생하는 것을 나타낸다. 토폴로지 제약이
 있고 클러스터의 모든 노드에서 전역적으로 접근할 수 없는 스토리지
 백엔드의 경우, 파드의 스케줄링 요구 사항에 대한 지식 없이 퍼시스턴트볼륨이
@ -183,6 +183,36 @@ CSI | 1.14 (alpha), 1.16 (beta)
 사전에 생성된 PV에서도 지원되지만, 지원되는 토폴로지 키와 예시를 보려면 해당
 CSI 드라이버에 대한 문서를 본다.

+{{< note >}}
+   `waitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다.
+   만약 `nodeName`을 사용한다면, 스케줄러가 바이패스되고 PVC가 `pending` 상태로 있을 것이다.
+
+   대신, 아래와 같이 호스트네임을 이용하는 노드셀렉터를 사용할 수 있다.
+{{< /note >}}
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: task-pv-pod
+spec:
+  nodeSelector:
+    kubernetes.io/hostname: kube-01
+  volumes:
+    - name: task-pv-storage
+      persistentVolumeClaim:
+        claimName: task-pv-claim
+  containers:
+    - name: task-pv-container
+      image: nginx
+      ports:
+        - containerPort: 80
+          name: "http-server"
+      volumeMounts:
+        - mountPath: "/usr/share/nginx/html"
+          name: task-pv-storage
+```
+
 ### 허용된 토폴로지

 클러스터 운영자가 `WaitForFirstConsumer` 볼륨 바인딩 모드를 지정하면, 대부분의 상황에서
--- a/content/ko/docs/concepts/workloads/pods/disruptions.md
+++ b/content/ko/docs/concepts/workloads/pods/disruptions.md
@ -79,13 +79,15 @@ weight: 60
  ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에
  애플리케이션을 분산해야 한다.

-자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
+자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자동화된 자발적 중단은 발생하지 않는다(사용자가 지시한 자발적 중단만 발생한다).
 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다.
 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다.
 또한 클러스터(노드) 오토스케일링의 일부 구현에서는
 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
 클러스터 관리자 또는 호스팅 공급자는
 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
+파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션
+또한 자발적(+ 비자발적) 중단을 유발할 수 있다.

 ## 파드 disruption budgets

--- a/content/ko/docs/concepts/workloads/pods/init-containers.md
+++ b/content/ko/docs/concepts/workloads/pods/init-containers.md
@ -326,6 +326,5 @@ myapp-pod   1/1       Running   0          9m

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

-
 * [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)
 * [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@ -13,7 +13,7 @@ obsolete -->
 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.

 {{< note >}}
-v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
+v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
 [API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
 [스케줄러](/docs/reference/generated/kube-scheduler/)에서
 `EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
--- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
@ -132,7 +132,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `IPv6DualStack` | `true` | 베타 | 1.21 | |
 | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
 | `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
-| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 |  |
+| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
 | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
@ -142,7 +142,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | |
 | `NetworkPolicyEndPort` | `false` | 알파 | 1.21 |  |
 | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
-| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | |
+| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 |
 | `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
 | `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
 | `PodDeletionCost` | `false` | 알파 | 1.21 | |
@ -164,7 +164,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | |
 | `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | |
 | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
-| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
+| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 |
 | `ServiceTopology` | `false` | 알파 | 1.17 | |
 | `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
 | `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | |
@ -173,7 +173,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | 베타 | 1.15 | |
 | `SuspendJob` | `false` | 알파 | 1.21 | |
-| `TTLAfterFinished` | `false` | 알파 | 1.12 | |
+| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 |
+| `TTLAfterFinished` | `true` | 베타 | 1.21 | |
 | `TopologyAwareHints` | `false` | 알파 | 1.21 | |
 | `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
 | `TopologyManager` | `true` | 베타 | 1.18 | |
@ -266,6 +267,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 |
 | `EvenPodsSpread` | `true` | GA | 1.19 | - |
 | `ExecProbeTimeout` | `true` | GA | 1.20 | - |
+| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
 | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `HugePages` | `false` | 알파 | 1.8 | 1.9 |
@ -286,11 +288,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | 베타 | 1.15 | |
 | `KubeletPodResources` | `true` | GA | 1.20 | |
+| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - |
 | `MountContainers` | `false` | 알파 | 1.9 | 1.16 |
 | `MountContainers` | `false` | 사용중단 | 1.17 | - |
 | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 |
 | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 |
 | `MountPropagation` | `true` | GA | 1.12 | - |
+| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - |
 | `NodeLease` | `false` | 알파 | 1.12 | 1.13 |
 | `NodeLease` | `true` | 베타 | 1.14 | 1.16 |
 | `NodeLease` | `true` | GA | 1.17 | - |
@ -341,6 +345,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 |
 | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 |
 | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
+| `ServiceNodeExclusion` | `true` | GA | 1.21 | - |
 | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
 | `StartupProbe` | `true` | 베타 | 1.18 | 1.19 |
 | `StartupProbe` | `true` | GA | 1.20 | - |
@ -636,6 +641,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
  사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
  재 매핑이 활성화된 경우에만 활성화해야 한다.
+- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다.
 - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
 - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인
  볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원
--- a/content/ko/docs/reference/glossary/pod-disruption.md
+++ b/content/ko/docs/reference/glossary/pod-disruption.md
@ -0,0 +1,19 @@
+---
+id: pod-disruption
+title: 파드 중단(Disruption)
+full_link: /ko/docs/concepts/workloads/pods/disruptions/
+date: 2021-05-12
+short_description: >
+  노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차
+
+aka:
+related:
+ - pod
+ - container
+tags:
+ - operation
+---
+
+[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다.
+
+자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다.