Merge pull request #26613 from kubernetes/dev-1.20-ko.4

ko: Fourth Korean l10n work for release-1.20
2021-02-18 15:30:24 -08:00
parent 5b28c549d9 519861d265
commit fd8ee1d068
20 changed files with 614 additions and 239 deletions
@@ -5,7 +5,9 @@ date: 2020-12-02
 slug: dont-panic-kubernetes-and-docker
 ---
-**작성자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
+**저자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
 **번역:** 박재화(삼성SDS), 손석호(한국전자통신연구원)
 쿠버네티스는 v1.20 이후 컨테이너 런타임으로서
 [도커를
@@ -1,9 +1,5 @@
 ---
-title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
+title: 쿠버네티스 시스템 컴포넌트에 대한 메트릭
 content_type: concept
 weight: 60
 ---
@@ -12,7 +8,7 @@ weight: 60
 시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
-쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
+쿠버네티스 컴포넌트의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
 이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
 <!-- body -->
@@ -36,7 +32,7 @@ weight: 60
 클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다.
 예를 들면, 다음과 같다.
-```
+```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
@@ -156,5 +152,4 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
 ## {{% heading "whatsnext" %}}
 * 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
 * [안정적인 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 참고한다
 * [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다
@@ -22,6 +22,16 @@ weight: 30
 명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
 일부 시크릿을 만들 수 있다.
 {{< caution >}}
 쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
 기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에 
 액세스할 수 있는 모든 사용자가 일반 텍스트로 검색 할 수 있다. 
 시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
 2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
 {{< /caution >}}
 <!-- body -->
 ## 시크릿 개요
@@ -269,6 +279,13 @@ SSH 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다.
 API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
 검증도 한다.
 {{< caution >}}
 SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버간에 신뢰할 수있는 통신을 
 설정하지 않는다. ConfigMap에 추가된 `known_hosts` 파일과 같은 
 "중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는 
 2차 수단이 필요하다.
 {{< /caution >}}
 ### TLS 시크릿
 쿠버네티스는 보통 TLS를 위해 사용되는 인증서와 관련된 키를 저장하기 위해서
@@ -786,7 +803,6 @@ immutable: true
 수동으로 생성된 시크릿(예: GitHub 계정에 접근하기 위한 토큰이 포함된 시크릿)은
 시크릿의 서비스 어카운트를 기반한 파드에 자동으로 연결될 수 있다.
 해당 프로세스에 대한 자세한 설명은 [파드프리셋(PodPreset)을 사용하여 파드에 정보 주입하기](/docs/tasks/inject-data-application/podpreset/)를 참고한다.
 ## 상세 내용
@@ -1233,3 +1249,4 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
 - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
 - [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
 - [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
@@ -54,7 +54,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 컨테이너 라이프사이클 관리 훅이 호출되면,
 쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고,
-`exec` 와 `tcpSocket` 은 컨테이너에서 실행되고, `httpGet` 은 kubelet 프로세스에 의해 실행된다.
+`httpGet` 와 `tcpSocket` 은 kubelet 프로세스에 의해 실행되고, `exec` 은 컨테이너에서 실행된다.
 훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다.
 이것은 `PostStart` 훅에 대해서,
@@ -1,7 +1,4 @@
 ---
 title: 런타임클래스(RuntimeClass)
 content_type: concept
 weight: 20
@@ -35,10 +32,6 @@ weight: 20
 ## 셋업
 런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다.
 기능 게이트 활성화에 대한 설명은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
 참고한다. `RuntimeClass` 기능 게이트는 API 서버 _및_ kubelets에서 활성화되어야 한다.
 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서).
 2. 상응하는 런타임클래스 리소스 생성.
@@ -144,11 +137,9 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
-쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터
+RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가 
-지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는
+이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다.
-노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면,
+`scheduling`이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.
 [런타임 클래스 어드미션(admission) 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)를
 활성화(1.16 부터 기본값)해야 한다.
 파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
@@ -69,7 +69,7 @@ weight: 10
 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
 *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
 바이너리 플러그인은 kubelet(예:
-[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
+[Flex 볼륨 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
 kubectl에서
 사용한다.
@@ -157,7 +157,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 ### 스토리지 플러그인
-[Flex Volumes](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
+[Flex 볼륨](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
 빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
@@ -9,11 +9,11 @@ weight: 40
 인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.
-kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
+`kube-controller-manager` 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
 클러스터와 함께 자동으로 실행되지 않는다.
 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
-프로젝트로써 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
+프로젝트로서 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
  [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다.
@@ -26,6 +26,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
 * [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
  컨트롤러다.
 * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
 * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
@@ -42,7 +43,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
  기반 인그레스 컨트롤러다.
 * [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
  구동하는 인그레스 컨트롤러다.
-* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary)
+* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
  웹서버(프록시로 사용)와 함께 작동한다.
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
 * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
@@ -376,7 +376,7 @@ graph LR;
 트래픽을 일치 시킬 수 있다.
 예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
-`service1`로, `second.foo.com`는 `service2`로, 호스트 이름이 정의되지
+`service1`로, `second.bar.com`는 `service2`로, 호스트 이름이 정의되지
 않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
 트래픽은 `service3`로 라우팅 한다.
@@ -134,7 +134,7 @@ spec:
 * 한 서비스에서 다른
  {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
 * 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
-  쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
+  쿠버네티스에서는 백엔드의 일부만 실행한다.
 이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
 예를 들면
@@ -13,7 +13,7 @@ weight: 50
 <!-- overview -->
-잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료되도록 한다.
+잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다.
 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다.  지정된 수의
 성공 완료에 도달하면, 작업(즉, 잡)이 완료된다.  잡을 삭제하면 잡이 생성한
 파드가 정리된다.
@@ -76,4 +76,4 @@ TTL 컨트롤러는 쿠버네티스 리소스에
 * [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)
-* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
+* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
@@ -18,7 +18,8 @@ content_type: concept
 ## API 레퍼런스
-* [쿠버네티스 API 레퍼런스 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+* [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/)
 * [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
 ## API 클라이언트 라이브러리
@@ -48,13 +48,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | 기능     | 디폴트    | 단계   | 도입   | 종료   |
 |---------|---------|-------|-------|-------|
 | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
 | `APIListChunking` | `false` | 알파 | 1.8 | 1.8 |
 | `APIListChunking` | `true` | 베타 | 1.9 | |
 | `APIPriorityAndFairness` | `false` | 알파 | 1.17 | 1.19 |
 | `APIPriorityAndFairness` | `true` | 베타 | 1.20 | |
-| `APIResponseCompression` | `false` | 알파 | 1.7 | |
+| `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 |
 | `APIResponseCompression` | `false` | 베타 | 1.16 | |
 | `APIServerIdentity` | `false` | 알파 | 1.20 | |
 | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | |
 | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
 | `AppArmor` | `true` | 베타 | 1.4 | |
 | `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | |
 | `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | |
@@ -77,7 +79,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 |
 | `CSIMigrationGCE` | `false` | 베타 | 1.17 | |
 | `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | |
-| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | |
+| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 |
 | `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | |
 | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | |
 | `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
 | `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | |
@@ -89,26 +92,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
 | `CronJobControllerV2` | `false` | 알파 | 1.20 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
 | `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
 | `CustomResourceDefaulting` | `true` | 베타 | 1.16 | |
 | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
 | `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
 | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | 베타 | 1.10 | |
 | `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 |
-| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | 1.22 |
+| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | |
 | `DownwardAPIHugePages` | `false` | 알파 | 1.20 | |
 | `DryRun` | `false` | 알파 | 1.12 | 1.12 |
 | `DryRun` | `true` | 베타 | 1.13 | |
 | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | |
 | `EfficientWatchResumption` | `false` | 알파 | 1.20 | |
 | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
 | `EndpointSlice` | `false` | 베타 | 1.17 | |
 | `EndpointSlice` | `true` | 베타 | 1.18 | |
 | `EndpointSliceNodeName` | `false` | 알파 | 1.20 | |
 | `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
 | `EndpointSliceProxying` | `true` | 베타 | 1.19 | |
-| `EndpointSliceTerminating` | `false` | 알파 | 1.20 | |
+| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | |
 | `EphemeralContainers` | `false` | 알파 | 1.16 | |
 | `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | 베타 | 1.16 | |
@@ -119,19 +119,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
 | `GenericEphemeralVolume` | `false` | 알파 | 1.19 | |
 | `GracefulNodeShutdown` | `false` | 알파 | 1.20 | |
 | `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
 | `HPAScaleToZero` | `false` | 알파 | 1.16 | |
 | `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
 | `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
-| `HyperVContainer` | `false` | 알파 | 1.10 | |
+| `IPv6DualStack` | `false` | 알파 | 1.15 | |
 | `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
 | `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | |
-| `IPv6DualStack` | `false` | 알파 | 1.16 | |
+| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
-| `LegacyNodeRoleBehavior` | `true` | 알파 | 1.16 | |
+| `KubeletPodResources` | `true` | 알파 | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | 베타 | 1.15 | |
 | `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
 | `LegacyNodeRoleBehavior` | `true` | True | 1.19 |  |
 | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
 | `MixedProtocolLBService` | `false` | 알파 | 1.20 | |
 | `MountContainers` | `false` | 알파 | 1.9 | |
 | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
 | `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | |
 | `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
@@ -143,25 +146,27 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `ProcMountType` | `false` | 알파 | 1.12 | |
 | `QOSReserved` | `false` | 알파 | 1.11 | |
 | `RemainingItemCount` | `false` | 알파 | 1.15 | |
 | `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
 | `RemoveSelfLink` | `true` | 베타 | 1.20 | |
 | `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 |
 | `RootCAConfigMap` | `true` | 베타 | 1.20 | |
 | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
 | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
 | `RunAsGroup` | `true` | 베타 | 1.14 | |
 | `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
 | `RuntimeClass` | `true` | 베타 | 1.14 | |
 | `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
 | `SCTPSupport` | `true` | 베타 | 1.19 | |
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | |
-| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | |
+| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 |
-| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.20 |
+| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | |
 | `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | |
 | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
 | `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
 | `ServiceTopology` | `false` | 알파 | 1.17 | |
 | `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | |
 | `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
 | `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | |
 | `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | |
 | `StorageVersionAPI` | `false` | 알파 | 1.20 | |
 | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | 베타 | 1.15 | |
 | `Sysctls` | `true` | 베타 | 1.11 | |
@@ -170,11 +175,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `TopologyManager` | `true` | 베타 | 1.18 | |
 | `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
 | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
-| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | |
+| `WarningHeaders` | `true` | 베타 | 1.19 | |
 | `WindowsGMSA` | `false` | 알파 | 1.14 | |
 | `WindowsGMSA` | `true` | 베타 | 1.16 | |
 | `WinDSR` | `false` | 알파 | 1.14 | |
-| `WinOverlay` | `false` | 알파 | 1.14 | |
+| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
 | `WinOverlay` | `true` | 베타 | 1.20 | |
 | `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | |
 {{< /table >}}
 ### GA 또는 사용 중단된 기능을 위한 기능 게이트
@@ -228,6 +233,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 |
 | `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 |
 | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
 | `DryRun` | `false` | 알파 | 1.12 | 1.12 |
 | `DryRun` | `true` | 베타 | 1.13 | 1.18 |
 | `DryRun` | `true` | GA | 1.19 | - |
 | `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 |
 | `DynamicAuditing` | - | 사용중단 | 1.19 | - |
 | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
@@ -247,23 +255,28 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `HugePages` | `false` | 알파 | 1.8 | 1.9 |
 | `HugePages` | `true` | 베타| 1.10 | 1.13 |
 | `HugePages` | `true` | GA | 1.14 | - |
 | `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 |
 | `HyperVContainer` | `false` | 사용중단 | 1.20 | - |
 | `Initializers` | `false` | 알파 | 1.7 | 1.13 |
 | `Initializers` | - | 사용중단 | 1.14 | - |
 | `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 |
 | `KubeletConfigFile` | - | 사용중단 | 1.10 | - |
 | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | 1.20 |
 | `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 |
 | `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 |
 | `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
 | `KubeletPodResources` | `true` | 베타 | 1.15 | |
 | `KubeletPodResources` | `true` | GA | 1.20 | |
 | `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 | - |
 | `NodeLease` | `false` | 알파 | 1.12 | 1.13 |
 | `NodeLease` | `true` | 베타 | 1.14 | 1.16 |
 | `NodeLease` | `true` | GA | 1.17 | - |
 | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
 | `PVCProtection` | - | 사용중단 | 1.10 | - |
 | `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
 | `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 |
 | `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
@@ -276,8 +289,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `PodShareProcessNamespace` | `false` | 알파 | 1.10 | 1.11 |
 | `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 |
 | `PodShareProcessNamespace` | `true` | GA | 1.17 | - |
 | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
 | `PVCProtection` | - | 사용중단 | 1.10 | - |
 | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 |
 | `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 |
 | `ResourceLimitsPriorityFunction` | - | 사용중단 | 1.19 | - |
@@ -398,62 +409,131 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 각 기능 게이트는 특정 기능을 활성화/비활성화하도록 설계되었다.
 - `APIListChunking`: API 클라이언트가 API 서버에서 (`LIST` 또는 `GET`)
  리소스를 청크(chunks)로 검색할 수 있도록 한다.
 - `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을
  관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
 - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
 - `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다.
 - `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다.
 - `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다.
- `AffinityInAnnotations`(*사용 중단됨*): [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 설정을 활성화한다.
+- `AffinityInAnnotations`(*사용 중단됨*): [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
  설정을 활성화한다.
 - `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다.
 - `AllowInsecureBackendProxy`: 사용자가 파드 로그 요청에서 kubelet의
  TLS 확인을 건너뛸 수 있도록 한다.
 - `AnyVolumeDataSource`: {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}의
  `DataSource` 로 모든 사용자 정의 리소스 사용을 활성화한다.
 - `APIListChunking`: API 클라이언트가 API 서버에서 (`LIST` 또는 `GET`) 리소스를 청크(chunks)로 검색할 수 있도록 한다.
 - `APIPriorityAndFairness`: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
 - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
 - `APIServerIdentity`: 클러스터의 각 kube-apiserver에 ID를 할당한다.
 - `AppArmor`: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다.
-   자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다.
+  자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/clusters/apparmor/)을 참고한다.
 - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
  대한 제한을 보고하도록 한다.
-   자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
+  자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
 - `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를
  포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가
  더 가까운 노드가 선호된다.
 - `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다.
-   자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
+  자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
-   참고한다.
+  참고한다.
 - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
-   마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
+  마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
-   확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
+  확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
-   `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
+  `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
-   자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
+  자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
-   확인한다.
+  확인한다.
- `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다.
+- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
-`CronJobControllerV2` : {{< glossary_tooltip text="크론잡" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
+  [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
 - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
 - `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.
- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원) 문서를 참고한다.
+- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다.
- `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 모든 로직을 활성화한다.
+  자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)
  문서를 참고한다.
 - `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된
  모든 로직을 활성화한다.
 - `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다.
- `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다.
+- `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서
- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에 EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로 폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다.
+  사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다.
- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을
- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+  AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에
- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+  EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로
- `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+  폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다.
- `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리
- `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에 PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+  플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS
- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 필요하다.
+  인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
- `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+  클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고
- `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+  EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
+- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을
- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
+  Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
  노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리
  AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
  필요하다.
 - `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리
  플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을
  Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로
  라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능
  플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어
  있어야 한다.
 - `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을
  Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다.
  노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
  AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
  필요하다.
 - `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리
  플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을
  Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로
  라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능
  플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어
  있어야 한다.
 - `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을
  GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
  PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
  지원한다. CSIMigration 기능 플래그가 필요하다.
 - `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD
  인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
  인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
  CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI
  플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
 - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을
  Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에
  Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
  Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
 - `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서
  Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리
  플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다.
  클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고
  Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
 - `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을
  라우팅하는 shim 및 변환 로직을 사용한다.
  노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우
  인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
 - `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리
  플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서
  vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및
  CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
  클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
 - `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
 - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
  호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
  마운트할 수 있다.
- `CSIServiceAccountToken` : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록 CSI 드라이버를 활성화한다. [토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다.
+- `CSIServiceAccountToken` : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록
- `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
+  CSI 드라이버를 활성화한다.
  [토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다.
 - `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고
  쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다.
  [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
  자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다.
+- `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다.
- `CustomCPUCFSQuotaPeriod`: 노드가 CPUCFSQuotaPeriod를 변경하도록 한다.
+  이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과
  권한 수정을 지원하는지 여부를 제어한다.
 - `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한
  볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은
  [파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을
  참고한다.
 - `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}}
  컨트롤러의 대체 구현을 사용한다. 그렇지 않으면,
  동일한 컨트롤러의 버전 1이 선택된다.
  버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
 - `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서
  `cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다.
 - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
  자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을
  확인한다.
@@ -466,147 +546,248 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
  생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
  실행 중인 파드 문제를 해결한다.
 - `DisableAcceleratorUsageMetrics`: [kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/#액셀러레이터-메트릭-비활성화).
 - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
  기반 리소스 프로비저닝을 활성화한다.
 - `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
  [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
- `DownwardAPIHugePages`: 다운워드 API에서 hugepages 사용을 활성화한다.
+- `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
  기반 리소스 프로비저닝을 활성화한다.
 - `DisableAcceleratorUsageMetrics`:
  [kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/#액셀러레이터-메트릭-비활성화).
 - `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서
  hugepages 사용을 활성화한다.
 - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
  요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
 - `DynamicAuditing`(*사용 중단됨*): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다.
+- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다.
- `DynamicProvisioningScheduling`: 볼륨 스케줄을 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다.
+  [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다.
 - `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록
  기본 스케줄러를 확장한다.
  이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다.
- `DynamicVolumeProvisioning`(*사용 중단됨*): 파드에 퍼시스턴트 볼륨의 [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다.
+- `DynamicVolumeProvisioning`(*사용 중단됨*): 파드에 퍼시스턴트 볼륨의
- `EnableAggregatedDiscoveryTimeout` (*사용 중단됨*): 수집된 검색 호출에서 5초 시간 초과를 활성화한다.
+  [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다.
- `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의 동등성을 캐시할 수 있게 한다.
+- `EfficientWatchResumption`: 스토리지에서 생성된 북마크(진행
- `EphemeralContainers`: 파드를 실행하기 위한 {{< glossary_tooltip text="임시 컨테이너"
+  알림) 이벤트를 사용자에게 전달할 수 있다. 이것은 감시 작업에만
-  term_id="ephemeral-container" >}}를 추가할 수 있다.
+  적용된다.
- `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다.
+- `EnableAggregatedDiscoveryTimeout` (*사용 중단됨*): 수집된 검색 호출에서 5초
-`ExecProbeTimeout` : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다. 이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한 현재 수정된 결함에 의존하는 경우 존재한다. [준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다.
+  시간 초과를 활성화한다.
- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다. [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
+- `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의
- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다. [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다.
+  동등성을 캐시할 수 있게 한다.
- `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
+- `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한
  엔드포인트슬라이스(EndpointSlices)를 활성화한다. [엔드포인트슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 - `EndpointSliceNodeName` : 엔드포인트슬라이스 `nodeName` 필드를 활성화한다.
 - `EndpointSliceProxying`: 활성화되면, 리눅스에서 실행되는
  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 - `EndpointSliceTerminatingCondition`: 엔드포인트슬라이스 `terminating` 및 `serving`
  조건 필드를 활성화한다.
 - `EphemeralContainers`: 파드를 실행하기 위한
  {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를
  추가할 수 있다.
 - `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다.
  [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다.
 - `ExecProbeTimeout` : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다.
  이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한
  현재 수정된 결함에 의존하는 경우 존재한다.
  [준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다.
 - `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
 - `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
  [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
 - `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다.
  [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다.
 - `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로
  어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
  이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
 - `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로
  기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
  권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
  사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
  재 매핑이 활성화된 경우에만 활성화해야 한다.
 - `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한
  엔드포인트 슬라이스를 활성화한다. [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 -`EndpointSliceNodeName` : 엔드포인트슬라이스 `nodeName` 필드를 활성화한다.
 -`EndpointSliceTerminating` : 엔드포인트슬라이스 `terminating` 및 `serving` 조건 필드를
   활성화한다.
 - `EndpointSliceProxying`: 이 기능 게이트가 활성화되면, 리눅스에서 실행되는
  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 - `WindowsEndpointSliceProxying`: 이 기능 게이트가 활성화되면, 윈도우에서 실행되는
  kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를
  기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다.
  [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
+- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인
-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을 참조한다.
+  볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원
- `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다.
+  등에서 제공할 수 있음).
- `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다.
+  [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
- `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다.
+- `GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다.
- `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해 `minReplicas` 를 0으로 설정한다.
+  시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행 중인
- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다.
+  파드를 정상적으로 종료하려고 시도한다. 자세한 내용은
- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다.
+  [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을
-  자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다.
+  참조한다.
 - `HPAContainerMetrics`: `HorizontalPodAutoscaler`를 활성화하여 대상 파드의
  개별 컨테이너 메트릭을 기반으로 확장한다.
 - `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해
  `minReplicas` 를 0으로 설정한다.
 - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의
  할당 및 사용을 활성화한다.
 - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의
  여러 크기를 지원한다.
 - `HyperVContainer`: 윈도우 컨테이너를 위한
  [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)
  기능을 활성화한다.
 - `IPv6DualStack`: IPv6에 대한 [듀얼 스택](/ko/docs/concepts/services-networking/dual-stack/)
  지원을 활성화한다.
 - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
  변경할 수 없는(immutable) 것으로 표시할 수 있다.
 - `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
  kubelet 구성을 로드할 수 있다.
  자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
  참고한다.
 - `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
 - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
  플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
- `KubeletPodResources`: kubelet의 파드 리소스 grpc 엔드포인트를 활성화한다.
+- `KubeletPodResources`: kubelet의 파드 리소스 GPRC 엔드포인트를 활성화한다. 자세한 내용은
-   자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을 참고한다.
+  [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)을
- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다.
+  참고한다.
- `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다.
+- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
- `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 `LocalStorageCapacityIsolation` 이 활성화되고 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 파일시스템 사용보다는 프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다.
+  `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여
- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다.
+  `node-role.kubernetes.io/master` 레이블을 무시한다.
- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
+- `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와
  [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의
  `sizeLimit` 속성을 사용할 수 있게 한다.
 - `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에
  `LocalStorageCapacityIsolation` 이 활성화되고
  [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의
  백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 파일시스템 사용보다는
  프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)
  스토리지 사용을 모니터링하여 성능과 정확성을
  향상시킨다.
 - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
  사용을 활성화한다.
 - `MountContainers` (*사용 중단됨*): 호스트의 유틸리티 컨테이너를 볼륨 마운터로
  사용할 수 있다.
 - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
  자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다.
+- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
  사용을 활성화한다.
 - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 NonPreempting 옵션을 활성화한다.
+- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
 - `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
  삭제되지 않도록 한다.
 - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
  `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다.
 - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다.
+- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
- `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다.
+  기능을 활성화한다.
 - `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를
  기반으로 파드의 스케줄링 취소와 선점을 활성화한다.
 - `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해
  `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를
  참고한다.
 - `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를
  공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은
  [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다.
- `ProcMountType`: 컨테이너의 ProcMountType 제어를 활성화한다.
+- `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
+  컨테이너의 proc 타입의 마운트를 제어할 수 있다.
-  삭제되지 않도록 한다.  
+- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가
- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서
+  더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다
-  요청된 리소스로 파열되는 것을 방지한다(현재 메모리만 해당).
+  (현재 메모리만 해당).
 - `RemainingItemCount`: API 서버가
  [청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한
  응답에서 남은 항목 수를 표시하도록 허용한다.
 - `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고
  제거한다.
 - `ResourceLimitsPriorityFunction` (*사용 중단됨*): 입력 파드의 CPU 및 메모리 한도 중
  하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는
  스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진
  노드 사이의 관계를 끊는 것이다.
 - `ResourceQuotaScopeSelectors`: 리소스 쿼터 범위 셀렉터를 활성화한다.
- `RootCAConfigMap`: 모든 네임 스페이스에 `kube-root-ca.crt`라는 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 게시하도록 kube-controller-manager를 구성한다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.
+- `RootCAConfigMap`: 모든 네임스페이스에 `kube-root-ca.crt`라는
-   자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 참조한다.
+  {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 게시하도록
  `kube-controller-manager` 를 구성한다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데
  사용되는 CA 번들이 포함되어 있다. 자세한 내용은
  [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
  참조한다.
 - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
  자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
 - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
-  자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
+- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를
- `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다.
+  활성화한다.
- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다.
+- `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)
- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다.
+  기능을 활성화한다.
- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다.
+- `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다.
+  스케줄링할 수 있다.
- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다.
+- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서
  _SCTP_ `protocol` 값을 활성화한다.
 - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/)
  경로를 활성화한다.
 - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및
  JWKS URL)를 활성화한다. 자세한 내용은
  [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을
  참고한다.
 - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다.
- `ServiceLBNodePortControl`: 서비스에서`spec.allocateLoadBalancerNodePorts` 필드를 활성화한다.
+- `ServiceLBNodePortControl`: 서비스에서`spec.allocateLoadBalancerNodePorts` 필드를
  활성화한다.
 - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다.
+- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를
-  "`alpha.service-controller.kubernetes.io/exclude-balancer`" 키 또는 `node.kubernetes.io/exclude-from-external-load-balancers` 로 레이블이 지정된 경우 노드를 제외할 수 있다.
+  제외할 수 있다. "`node.kubernetes.io/exclude-from-external-load-balancers`"로
- `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다.
+  레이블이 지정된 경우 노드를 제외할 수 있다.
- `SizeMemoryBackedVolumes`: kubelet 지원을 사용하여 메모리 백업 볼륨의 크기를 조정한다. 자세한 내용은 [volumes](/ko/docs/concepts/storage/volumes)를 참조한다.
+- `ServiceTopology`: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수
- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
+  있도록 한다. 자세한 내용은
- `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다.
+  [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를
  참고한다.
 - `SizeMemoryBackedVolumes`: kubelet 지원을 사용하여 메모리 백업 볼륨의 크기를 조정한다.
  자세한 내용은 [volumes](/ko/docs/concepts/storage/volumes)를 참조한다.
 - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
  설정하는 기능을 활성화한다.
  [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다.
 - `StartupProbe`: kubelet에서
  [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
  프로브를 활성화한다.
 - `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히
  사용 중인 경우 삭제를 연기한다.
- `StorageVersionHash`: API 서버가 디스커버리에서 스토리지 버전 해시를 노출하도록 허용한다.
+- `StorageVersionAPI`: [스토리지 버전 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageversion-v1alpha1-internal-apiserver-k8s-io)를
  활성화한다.
 - `StorageVersionHash`: API 서버가 디스커버리에서 스토리지 버전 해시를 노출하도록
  허용한다.
 - `StreamingProxyRedirects`: 스트리밍 요청을 위해 백엔드(kubelet)에서 리디렉션을
  가로채서 따르도록 API 서버에 지시한다.
  스트리밍 요청의 예로는 `exec`, `attach` 및 `port-forward` 요청이 있다.
 - `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다.
  자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다.
 - `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다.
- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다.
+- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다.
- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다.
+  `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=<number>`
-  자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
+  파라미터를 지정하여 지정된 수의 프로세스 ID가
- `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다.
+  시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록
-  자세한 내용은 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 참고한다.
+  할 수 있다.
- `TaintNodesByCondition`: [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)을 기반으로 자동 테인트 노드를 활성화한다.
+- `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널
  파라미터(sysctl)를 지원한다. 자세한 내용은
  [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
 - `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
  실행이 끝난 후 리소스를 정리하도록
  허용한다.
 - `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로
  노드에서 파드를 축출할 수 있다.
  자세한 내용은 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을
  참고한다.
 - `TaintNodesByCondition`: [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)을
  기반으로 자동 테인트 노드를 활성화한다.
 - `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다.
- `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해 서비스 어카운트
+- `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해
-  토큰을 파드에 주입할 수 있다.
+  서비스 어카운트 토큰을 파드에 주입할 수 있다.
- `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스 할당을 조정하는 메커니즘을 활성화한다. [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다.
+- `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스
- `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 실행이 끝난 후 리소스를 정리하도록 허용한다.
+  할당을 조정하는 메커니즘을 활성화한다.
  [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다.
 - `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다.
 - `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고
  퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한
  `PersistentLocalVolumes` 기능 게이트와 함께 사용될 때
  [`local`](/ko/docs/concepts/storage/volumes/#local) 볼륨 유형을 사용할 수 있다.
 - `VolumeSnapshotDataSource`: 볼륨 스냅샷 데이터 소스 지원을 활성화한다.
- `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해 `subPathExpr` 필드를 활성화한다.
+- `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해
  `subPathExpr` 필드를 활성화한다.
 - `WarningHeaders`: API 응답에서 경고 헤더를 보낼 수 있다.
 - `WatchBookmark`: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다.
 - `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
 - `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 애플리케이션을 실행할 수 있도록 지원한다.
  자세한 내용은 [RunAsUserName 구성](/docs/tasks/configure-pod-container/configure-runasusername)을 참고한다.
 - `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다.
 - `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다.
 - `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
 - `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서
  애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은
  [RunAsUserName 구성](/docs/tasks/configure-pod-container/configure-runasusername)을
  참고한다.
 - `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는
  엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
  확장성과 성능을 향상시킨다.
  [엔드포인트 슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다.
 ## {{% heading "whatsnext" %}}
@@ -2,7 +2,7 @@
 title: API 그룹(API Group)
 id: api-group
 date: 2019-09-02
-full_link: /ko/docs/concepts/overview/kubernetes-api/#api-groups
+full_link: /ko/docs/concepts/overview/kubernetes-api/#api-그룹과-버전-규칙
 short_description: >
  쿠버네티스 API의 연관된 경로들의 집합.
@@ -11,9 +11,9 @@ tags:
 - fundamental
 - architecture
 ---
-쿠버네티스 API의 연관된 경로들의 집합. 
+쿠버네티스 API의 연관된 경로들의 집합.
 <!--more-->
 API 서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있다. 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있다. API 그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있다. API 그룹은 REST 경로 및 직렬화된 오브젝트의 `apiVersion` 필드에 지정된다.
-* 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-groups)을 참조한다.
+* 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-그룹과-버전-규칙)을 참조한다.
@@ -0,0 +1,33 @@
 ---
 title: 수량(Quantity)
 id: quantity
 date: 2018-08-07
 full_link:
 short_description: >
  SI 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현.
 aka: 
 tags:
 - core-object
 ---
 SI 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현.
 <!--more-->
 수량은 SI 접미사가 포함된 간결한 정수 표기법을 통해서 작거나 큰 숫자를 표현한 것이다. 
 분수는 밀리(milli) 단위로 표시되는 반면, 
 큰 숫자는 킬로(kilo), 메가(mega), 또는 기가(giga) 
 단위로 표시할 수 있다.
 예를 들어, 숫자 `1.5`는 `1500m`으로, 숫자 `1000`은 `1k`로, `1000000`은
 `1M`으로 표시할 수 있다. 또한, 이진 표기법 접미사도 명시 가능하므로,
 숫자 2048은 `2Ki`로 표기될 수 있다. 
 허용되는 10진수(10의 거듭 제곱) 단위는 `m` (밀리), `k` (킬로, 의도적인 소문자),
 `M` (메가), `G` (기가), `T` (테라), `P` (페타),
 `E` (엑사)가 있다.
 허용되는 2진수(2의 거듭 제곱) 단위는 `Ki` (키비), `Mi` (메비), `Gi` (기비),
 `Ti` (테비), `Pi` (페비), `Ei` (엑비)가 있다.
@@ -0,0 +1,18 @@
 ---
 title: 시크릿(Secret)
 id: secret
 date: 2018-04-12
 full_link: /ko/docs/concepts/configuration/secret/
 short_description: >
  비밀번호, OAuth 토큰 및 ssh 키와 같은 민감한 정보를 저장한다.
 aka: 
 tags:
 - core-object
 - security
 ---
 비밀번호, OAuth 토큰 및 ssh 키와 같은 민감한 정보를 저장한다.
 <!--more--> 
 민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 유휴 상태의 [암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)를 포함하여 우발적인 노출 위험을 줄인다. {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}}는 시크릿을 마운트된 볼륨의 파일로 참조하거나, 파드의 이미지를 풀링하는 kubelet이 시크릿을 참조한다. 시크릿은 기밀 데이터에 적합하고 [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터에 적합하다.
@@ -0,0 +1,20 @@
 ---
 title: 스토리지 클래스(Storage Class)
 id: storageclass
 date: 2018-04-12
 full_link: /ko/docs/concepts/storage/storage-classes
 short_description: >
  스토리지클래스는 관리자가 사용 가능한 다양한 스토리지 유형을 설명할 수 있는 방법을 제공한다.
 aka: 
 tags:
 - core-object
 - storage
 ---
 스토리지클래스는 관리자가 사용 가능한 다양한 스토리지 유형을 설명할 수 있는 방법을 제공한다.
 <!--more--> 
 스토리지 클래스는 서비스 품질 수준, 백업 정책 혹은 클러스터 관리자가 결정한 임의의 정책에 매핑할 수 있다. 각 스토리지클래스에는 클래스에 속한 {{< glossary_tooltip text="퍼시스턴트 볼륨(Persistent Volume)" term_id="persistent-volume" >}}을 동적으로 프로비저닝해야 할 때 사용되는 `provisioner`, `parameters` 및 `reclaimPolicy` 필드가 있다. 사용자는 스토리지클래스 객체의 이름을 사용하여 특정 클래스를 요청할 수 있다. 
@@ -122,7 +122,7 @@ sudo apt-get update && sudo apt-get install -y containerd.io
 ```shell
 # containerd 구성
 sudo mkdir -p /etc/containerd
-sudo containerd config default | sudo tee /etc/containerd/config.toml
+containerd config default | sudo tee /etc/containerd/config.toml
 ```
 ```shell
@@ -140,7 +140,7 @@ sudo apt-get update && sudo apt-get install -y containerd
 ```shell
 # containerd 구성
 sudo mkdir -p /etc/containerd
-sudo containerd config default | sudo tee /etc/containerd/config.toml
+containerd config default | sudo tee /etc/containerd/config.toml
 ```
 ```shell
@@ -210,7 +210,7 @@ sudo yum update -y && sudo yum install -y containerd.io
 ```shell
 ## containerd 구성
 sudo mkdir -p /etc/containerd
-sudo containerd config default | sudo tee /etc/containerd/config.toml
+containerd config default | sudo tee /etc/containerd/config.toml
 ```
 ```shell
@@ -1,11 +1,18 @@
 ---
 title: 쿠버네티스 버전 및 버전 차이(skew) 지원 정책
 content_type: concept
 weight: 30
 ---
 <!-- overview -->
-이 문서는 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이를 설명한다. 
+이 문서는 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이를 설명한다.
 특정 클러스터 배포 도구는 버전 차이에 대한 추가적인 제한을 설정할 수 있다.
@@ -19,14 +26,14 @@ weight: 30
 쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다.
-보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다. 
+보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(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
@@ -133,6 +140,11 @@ HA 클러스터의 `kube-apiserver` 인스턴스 간에 버전 차이가 있으
 필요에 따라서 `kubelet` 인스턴스를 **{{< skew latestVersion >}}** 으로 업그레이드할 수 있다(또는 **{{< skew prevMinorVersion >}}** 아니면 **{{< skew oldestMinorVersion >}}** 으로 유지할 수 있음).
 {{< note >}}
 `kubelet` 마이너 버전 업그레이드를 수행하기 전에, 해당 노드의 파드를 [드레인(drain)](/docs/tasks/administer-cluster/safely-drain-node/)해야 한다.
 인플레이스(In-place) 마이너 버전 `kubelet` 업그레이드는 지원되지 않는다.
 {{</ note >}}
 {{< warning >}}
 클러스터 안의 `kubelet` 인스턴스를 `kube-apiserver`의 버전보다 2단계 낮은 버전으로 실행하는 것을 권장하지 않는다:
@@ -1,4 +1,6 @@
 ---
 title: kubectl 설치 및 설정
 content_type: task
 weight: 10
@@ -30,33 +32,73 @@ kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소
 1. 다음 명령으로 최신 릴리스를 다운로드한다.
-    ```
+   ```bash
-    curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
+   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
-    ```
+   ```
-    특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
+   {{< note >}}
 특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
-    예를 들어, 리눅스에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
+예를 들어, 리눅스에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
    ```
    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
    ```
-2. kubectl 바이너리를 실행 가능하게 만든다.
+   ```bash
   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
   ```
   {{< /note >}}
-    ```
+1. 바이너리를 검증한다. (선택 사항)
    chmod +x ./kubectl
    ```
-3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다.
+   kubectl 체크섬(checksum) 파일을 다운로드한다.
-    ```
+   ```bash
-    sudo mv ./kubectl /usr/local/bin/kubectl
+   curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
-    ```
+   ```
 4. 설치한 버전이 최신 버전인지 확인한다.
-    ```
+   kubectl 바이너리를 체크섬 파일을 통해 검증한다.
-    kubectl version --client
+
-    ```
+   ```bash
   echo "$(<kubectl.sha256) kubectl" | sha256sum --check
   ```
   검증이 성공한다면, 출력은 다음과 같다.
   ```bash
   kubectl: OK
   ```
   검증이 실패한다면, `sha256` 가 0이 아닌 상태로 종료되며 다음과 유사한 결과를 출력한다.
   ```bash
   kubectl: FAILED
   sha256sum: WARNING: 1 computed checksum did NOT match
   ```
   {{< note >}}
   동일한 버전의 바이너리와 체크섬을 다운로드한다.
   {{< /note >}}
 1. kubectl 설치
   ```bash
   sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
   ```
   {{< note >}}
   대상 시스템에 root 접근 권한을 가지고 있지 않더라도, `~/.local/bin` 디렉터리에 kubectl을 설치할 수 있다.
   ```bash
   mkdir -p ~/.local/bin/kubectl
   mv ./kubectl ~/.local/bin/kubectl
   # 그리고 ~/.local/bin/kubectl을 $PATH에 추가
   ```
   {{< /note >}}
 1. 설치한 버전이 최신인지 확인한다.
   ```bash
   kubectl version --client
   ```
 ### 기본 패키지 관리 도구를 사용하여 설치
@@ -117,29 +159,65 @@ kubectl version --client
 1. 최신 릴리스를 다운로드한다.
   ```bash
-   curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
+   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
   ```
-   특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
+   {{< note >}}
   특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
   예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
   ```bash
   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
    ```
-   kubectl 바이너리를 실행 가능하게 만든다.
+   ```bash
   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
   ```
   {{< /note >}}
 1. 바이너리를 검증한다. (선택 사항)
   kubectl 체크섬 파일을 다운로드한다.
   ```bash
   curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
   ```
   kubectl 바이너리를 체크섬 파일을 통해 검증한다.
   ```bash
   echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check
   ```
   검증이 성공한다면, 출력은 다음과 같다.
   ```bash
   kubectl: OK
   ```
   검증이 실패한다면, `sha256` 가 0이 아닌 상태로 종료되며 다음과 유사한 결과를 출력한다.
   ```bash
   kubectl: FAILED
   shasum: WARNING: 1 computed checksum did NOT match
   ```
   {{< note >}}
   동일한 버전의 바이너리와 체크섬을 다운로드한다.
   {{< /note >}}
 1. kubectl 바이너리를 실행 가능하게 한다.
   ```bash
   chmod +x ./kubectl
   ```
-3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다.
+1. kubectl 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.
   ```bash
-   sudo mv ./kubectl /usr/local/bin/kubectl
+   sudo mv ./kubectl /usr/local/bin/kubectl && \
   sudo chown root: /usr/local/bin/kubectl
   ```
-4. 설치한 버전이 최신 버전인지 확인한다.
+1. 설치한 버전이 최신 버전인지 확인한다.
   ```bash
   kubectl version --client
@@ -161,7 +239,7 @@ macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경
   brew install kubernetes-cli
   ```
-2. 설치한 버전이 최신 버전인지 확인한다.
+1. 설치한 버전이 최신 버전인지 확인한다.
   ```bash
   kubectl version --client
@@ -178,7 +256,7 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하
   sudo port install kubectl
   ```
-2. 설치한 버전이 최신 버전인지 확인한다.
+1. 설치한 버전이 최신 버전인지 확인한다.
   ```bash
   kubectl version --client
@@ -188,30 +266,55 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하
 ### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치
-1. [이 링크](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)에서 최신 릴리스 {{< param "fullversion" >}}을 다운로드한다.
+1. [최신 릴리스 {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)를 다운로드한다.
   또는 `curl` 을 설치한 경우, 다음 명령을 사용한다.
-   ```bash
+   ```powershell
-   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
+   curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
   ```
-   최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다.
+   {{< note >}}
   최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt)를 참고한다.
   {{< /note >}}
-2. 바이너리를 PATH가 설정된 디렉터리에 추가한다.
+1. 바이너리를 검증한다. (선택 사항)
-3. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
+   kubectl 체크섬 파일을 다운로드한다.
-   ```bash
+   ```powershell
   curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
   ```
   kubectl 바이너리를 체크섬 파일을 통해 검증한다.
   - 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
     ```cmd
     CertUtil -hashfile kubectl.exe SHA256
     type kubectl.exe.sha256
     ```
   - `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
     ```powershell
     $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
     ```
 1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
 1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
   ```cmd
   kubectl version --client
   ```
 {{< note >}}
-[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다.
+[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 `PATH` 에 추가한다.
-도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 PATH 항목 앞에 PATH 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다.
+도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 `PATH` 항목 앞에 `PATH` 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다.
 {{< /note >}}
-### PSGallery에서 Powershell로 설치
+### PSGallery에서 PowerShell로 설치
 윈도우에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다.
@@ -223,12 +326,12 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하
   ```
   {{< note >}}
-   `DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다.
+   `DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 `temp` 디렉터리에 설치된다.
   {{< /note >}}
   설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다.
-2. 설치한 버전이 최신 버전인지 확인한다.
+1. 설치한 버전이 최신 버전인지 확인한다.
   ```powershell
   kubectl version --client
@@ -256,32 +359,32 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하
   {{< /tabs >}}
-2. 설치한 버전이 최신 버전인지 확인한다.
+1. 설치한 버전이 최신 버전인지 확인한다.
   ```powershell
   kubectl version --client
   ```
-3. 홈 디렉터리로 이동한다.
+1. 홈 디렉터리로 이동한다.
   ```powershell
   # cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE%
   cd ~
   ```
-4. `.kube` 디렉터리를 생성한다.
+1. `.kube` 디렉터리를 생성한다.
   ```powershell
   mkdir .kube
   ```
-5. 금방 생성한 `.kube` 디렉터리로 이동한다.
+1. 금방 생성한 `.kube` 디렉터리로 이동한다.
   ```powershell
   cd .kube
   ```
-6. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다.
+1. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다.
   ```powershell
   New-Item config -type file
@@ -297,13 +400,13 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다.
 1. [Google Cloud SDK](https://cloud.google.com/sdk/)를 설치한다.
-2. `kubectl` 설치 명령을 실행한다.
+1. `kubectl` 설치 명령을 실행한다.
   ```shell
   gcloud components install kubectl
   ```
-3. 설치한 버전이 최신 버전인지 확인한다.
+1. 설치한 버전이 최신 버전인지 확인한다.
   ```shell
   kubectl version --client
@@ -381,11 +484,13 @@ source /usr/share/bash-completion/bash_completion
   ```bash
   echo 'source <(kubectl completion bash)' >>~/.bashrc
   ```
 - 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다.
   ```bash
   kubectl completion bash >/etc/bash_completion.d/kubectl
   ```
 kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다.
 ```bash
@@ -466,7 +571,6 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
    ```bash
    echo 'source <(kubectl completion bash)' >>~/.bash_profile
    ```
 - 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다.
`@@ -76,4 +76,4 @@ TTL 컨트롤러는 쿠버네티스 리소스에`

	`* [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)`	`* [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)`

	`* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)`	`* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)`