Merge pull request #29998 from kubernetes/dev-1.22-ko.1

[ko] 1st Korean localization work for v1.22
2021-10-09 06:54:36 -07:00
parent 1cd35c2a42 14e5fe697f
commit 38be851062
105 changed files with 3053 additions and 648 deletions
@@ -392,6 +392,49 @@ Message:        Node is shutting, evicting pods
 이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
 {{< /note >}}

+## 스왑(swap) 메모리 관리 {#swap-memory}
+
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+
+쿠버네티스 1.22 이전에는 노드가 스왑 메모리를 지원하지 않았다. 그리고 
+kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 실패하도록 되어 있었다.
+1.22부터는 스왑 메모리 지원을 노드 단위로 활성화할 수 있다.
+
+노드에서 스왑을 활성화하려면, `NodeSwap` 기능 게이트가 kubelet에서
+활성화되어야 하며, 명령줄 플래그 `--fail-swap-on` 또는
+[구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가
+false로 지정되어야 한다.
+
+사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 
+이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,
+
+```yaml
+memorySwap:
+  swapBehavior: LimitedSwap
+```
+
+`swapBehavior`에 가용한 구성 옵션은 다음과 같다.
+
+- `LimitedSwap`: 쿠버네티스 워크로드는 스왑을 사용할 수 있는 만큼으로
+  제한된다. 쿠버네티스에 의해 관리되지 않는 노드의 워크로드는 여전히 스왑될 수 있다.
+- `UnlimitedSwap`: 쿠버네티스 워크로드는 요청한 만큼 스왑 메모리를 사용할 수 있으며,
+  시스템의 최대치까지 사용 가능하다.
+
+만약 `memorySwap` 구성이 명시되지 않았고 기능 게이트가 활성화되어 있다면, 
+kubelet은 `LimitedSwap` 설정과 같은 행동을
+기본적으로 적용한다.
+
+`LimitedSwap` 설정에 대한 행동은 노드가 ("cgroups"으로 알려진)
+제어 그룹이 v1 또는 v2 중에서 무엇으로 동작하는가에 따라서 결정된다. 
+
+- **cgroupsv1:** 쿠버네티스 워크로드는 메모리와 스왑의 조합을 사용할 수 있다.
+  파드의 메모리 제한이 설정되어 있다면 가용 상한이 된다.
+- **cgroupsv2:** 쿠버네티스 워크로드는 스왑 메모리를 사용할 수 없다.
+
+테스트를 지원하고 피드벡을 제공하기 위한 정보는
+[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 및
+[디자인 제안](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)에서 찾을 수 있다.
+
 ## {{% heading "whatsnext" %}}

 * 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.
@@ -6,6 +6,18 @@ weight: 70

 <!-- overview -->

+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
 가비지 수집은 사용되지 않는 
 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 
 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 
@@ -80,7 +80,7 @@ kubectl logs counter
 로테이션하도록 컨테이너 런타임을 설정할 수도 있다.

 예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
-[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
+[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해
 자세히 알 수 있다.

 **CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.
@@ -160,7 +160,7 @@ persistentvolumeclaim/my-pvc created

 지금까지 사용한 예는 모든 리소스에 최대 한 개의 레이블만 적용하는 것이었다. 세트를 서로 구별하기 위해 여러 레이블을 사용해야 하는 많은 시나리오가 있다.

-예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
+예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.

 ```yaml
     labels:
@@ -21,7 +21,7 @@ weight: 10

 - JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.

- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
+- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.

 - 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.

@@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며

 ## 레이블 사용하기

- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.

 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.

@@ -12,26 +12,33 @@ weight: 30

 <!-- overview -->

-쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
-민감한 정보를 저장하고 관리할 수 있다. 기밀 정보를 시크릿에 저장하는 것이
-{{< glossary_tooltip term_id="pod" >}} 정의나
-{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
-내에 그대로 두는 것보다 안전하고 유연하다.
-자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
-
 시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
-포함하는 오브젝트이다. 그렇지 않으면  이러한 정보가 파드
-명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
-일부 시크릿을 만들 수 있다.
+포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}}
+명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
+포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를
+애플리케이션 코드에 넣을 필요가
+없음을 뜻한다.
+
+시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에,
+파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이
+노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스
+및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성
+저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.
+
+시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만
+특별히 기밀 데이터를 보관하기 위한 것이다.

 {{< caution >}}
-쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
-기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
-액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
-시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
+쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
+또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. 
+
+시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.

 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
-2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
+2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
+   활성화 또는 구성.
+3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
+
 {{< /caution >}}

 <!-- body -->
@@ -47,6 +54,10 @@ weight: 30
 - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.

+쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어,
+[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은
+노드 등록을 자동화하는 데 도움을 주는 메커니즘이다.
+
 시크릿 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
@@ -1236,7 +1247,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
   API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
   시크릿을 노출하는 파드를 실행할 수 있다.

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

 - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
@@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
 FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
 ```

-서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
+서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.



@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 이미지
 content_type: concept
 weight: 10
@@ -16,9 +19,6 @@ weight: 10

 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.

-
-
-
 <!-- body -->

 ## 이미지 이름
@@ -210,10 +210,6 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'

 ### 미리 내려받은 이미지

-{{< note >}}
-Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
-{{< /note >}}
-
 {{< note >}}
 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
 클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
@@ -334,4 +330,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.

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

-* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기
+* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
+* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 런타임클래스(RuntimeClass)
 content_type: concept
 weight: 20
@@ -115,7 +118,7 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
 유효한 핸들러는 runtimes 단락 아래에서 설정한다.

 ```
-[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
 ```

 더 자세한 containerd의 구성 문서를 살펴본다.
@@ -197,31 +197,39 @@ service PodResourcesLister {
 }
 ```

-`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
-이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께
-실행 중인 파드의 리소스에 대한 정보를 제공한다.
+`List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
+독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
+이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.

 ```gRPC
-// ListPodResourcesResponse는 List 함수가 반환하는 응답이다
+// ListPodResourcesResponse는 List 함수가 반환하는 응답이다.
 message ListPodResourcesResponse {
    repeated PodResources pod_resources = 1;
 }

-// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다
+// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다.
 message PodResources {
    string name = 1;
    string namespace = 2;
    repeated ContainerResources containers = 3;
 }

-// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다
+// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다.
 message ContainerResources {
    string name = 1;
    repeated ContainerDevices devices = 2;
    repeated int64 cpu_ids = 3;
+    repeated ContainerMemory memory = 4;
 }

-// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다
+// ContainerMemory는 컨테이너에 할당된 메모리와 hugepage에 대한 정보를 포함한다.
+message ContainerMemory {
+    string memory_type = 1;
+    uint64 size = 2;
+    TopologyInfo topology = 3;
+}
+
+// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다.
 message TopologyInfo {
        repeated NUMANode nodes = 1;
 }
@@ -231,7 +239,7 @@ message NUMANode {
        int64 ID = 1;
 }

-// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다
+// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다.
 message ContainerDevices {
    string resource_name = 1;
    repeated string device_ids = 2;
@@ -247,6 +255,7 @@ kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다
 message AllocatableResourcesResponse {
    repeated ContainerDevices devices = 1;
    repeated int64 cpu_ids = 2;
+    repeated ContainerMemory memory = 3;
 }

 ```
@@ -45,7 +45,7 @@ sitemap:
 * 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
 * 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
 * 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
-* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
+* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
 * 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
 * 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
 * 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
@@ -30,6 +30,11 @@ weight: 50
 }
 ```

+{{<note>}}
+맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자,
+불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다.
+{{</note>}}
+
 다음은 어노테이션에 기록할 수 있는 정보의 예제이다.

 * 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은
@@ -42,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
   * `"partition" : "customerA"`, `"partition" : "customerB"`
   * `"track" : "daily"`, `"track" : "weekly"`

-이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
+이 예시는 [일반적으로 사용하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.

 ## 구문과 캐릭터 셋

@@ -50,15 +50,13 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시

 접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

-`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
+`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.

 유효한 레이블 값은 다음과 같다.
 * 63 자 이하여야 하고 (공백일 수도 있음),
 * (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
 * 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.

-유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
-
 다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.

 ```yaml
@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 오브젝트 이름과 ID
 content_type: concept
 weight: 20
@@ -25,7 +28,7 @@ weight: 20
 물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
 {{< /note >}}

-다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
+다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.

 ### DNS 서브도메인 이름

@@ -38,7 +41,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 - 영숫자로 시작한다.
 - 영숫자로 끝난다.

-### DNS 레이블 이름
+### RFC 1123 레이블 이름 {#dns-label-names}

 일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에
 정의된 대로 DNS 레이블 표준을 따라야 한다.
@@ -49,6 +52,17 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
 - 영숫자로 시작한다.
 - 영숫자로 끝난다.

+### RFC 1035 레이블 이름
+
+몇몇 리소스 타입은 자신의 이름을 [RFC 1035](https://tools.ietf.org/html/rfc1035)에
+정의된 DNS 레이블 표준을 따르도록 요구한다.
+이것은 이름이 다음을 만족해야 한다는 의미이다.
+
+- 최대 63개 문자를 포함
+- 소문자 영숫자 또는 '-'만 포함
+- 알파벳 문자로 시작
+- 영숫자로 끝남
+
 ### 경로 세그먼트 이름

 일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수
@@ -442,7 +442,7 @@ pods        0     10

 ### 네임스페이스 간 파드 어피니티 쿼터

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
 제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
@@ -493,9 +493,9 @@ plugins:
 해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
 파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.

-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.

 ## 요청과 제한의 비교 {#requests-vs-limits}

@@ -271,16 +271,16 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
 연관된 `matchExpressions` 가 모두 충족되어야 한다.

 #### 네임스페이스 셀렉터
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
 어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다.
 빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과
 null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다.

-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.

 #### 더 실용적인 유스케이스

@@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
-* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
+* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기
 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 파드 우선순위(priority)와 선점(preemption)
 content_type: concept
 weight: 70
@@ -350,21 +353,25 @@ spec:
 `PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를
 축출 대상으로 고려한다.

-QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
-[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
-kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
-파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
-먼저 축출 대상 파드의 순위를 매긴다.
-더 자세한 내용은
-[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
+kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/) 순서를 결정한다.
+사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
+예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
+
+  1. 부족한 리소스 사용량이 요청을 초과하는지 여부
+  1. 파드 우선순위
+  1. 요청 대비 리소스 사용량
+
+더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
 참조한다.

-kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
+kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
 파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을
 초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가
 더 높은 다른 파드가 축출될 수 있다.

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

-* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
+* 프라이어리티클래스와 함께 리소스쿼터 사용에 대해 읽기: [기본으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)
+* [파드 중단(disruption)](/ko/docs/concepts/workloads/pods/disruptions/)에 대해 학습한다.
+* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)에 대해 학습한다.
+* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 학습한다.
@@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
 마치 100을 설정한 것처럼 작동한다.

 값을 변경하려면,
-[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
+[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을
 편집한 다음 스케줄러를 재시작한다.
 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.

@@ -161,4 +161,4 @@ percentageOfNodesToScore: 50

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

-* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인
+* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인
@@ -264,10 +264,10 @@ tolerations:

 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.

-## 컨디션을 기준으로 노드 테인트하기
+## 조건(condition)을 기준으로 노드 테인트하기

 컨트롤 플레인은 노드 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}를 이용하여 
-[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
+[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.

 스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. 
 이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
@@ -298,5 +298,5 @@ tolerations:

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

-* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
+* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기
 * [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기
@@ -1,17 +1,21 @@
 ---
+
+
 title: 클라우드 네이티브 보안 개요
+description: >
+  클라우드 네이티브 보안 관점에서 쿠버네티스 보안을 생각해보기 위한 모델
 content_type: concept
-weight: 10
+weight: 1
 ---

 <!-- overview -->
+
 이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다.

 {{< warning >}}
 이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다.
 {{< /warning >}}

-
 <!-- body -->

 ## 클라우드 네이티브 보안의 4C
@@ -83,7 +87,6 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
 * 설정 가능한 클러스터 컴포넌트의 보안
 * 클러스터에서 실행되는 애플리케이션의 보안

-
 ### 클러스터의 컴포넌트 {#cluster-components}

 우발적이거나 악의적인 접근으로부터 클러스터를 보호하고,
@@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외

 쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
 지원한다. 전자는 기본적으로 작동하지만 후자는
-[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
+[CoreDNS 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다.
 {{< note >}}
 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
 처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서
@@ -227,7 +227,7 @@ Address 1: 10.0.162.149
 * 인증서를 사용하도록 구성된 nginx 서버
 * 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/ko/docs/concepts/configuration/secret/)

-[nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
+[nginx https 예제](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:

 ```shell
 make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
@@ -299,7 +299,7 @@ nginxsecret           kubernetes.io/tls                     2         1m
 nginx-secure-app의 매니페스트에 대한 주목할만한 점:

 - 이것은 동일한 파일에 디플로이먼트와 서비스의 사양을 모두 포함하고 있다.
- [nginx 서버](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
+- [nginx 서버](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)
  는 포트 80에서 HTTP 트래픽을 443에서 HTTPS 트래픽 서비스를 제공하고, nginx 서비스는
  두 포트를 모두 노출한다.
 - 각 컨테이너는 `/etc/nginx/ssl` 에 마운트된 볼륨을 통해 키에 접근할 수 있다.
@@ -197,7 +197,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac

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

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

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

@@ -313,6 +313,28 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
 options ndots:5
 ```

+#### 확장된 DNS 환경 설정
+
+{{< feature-state for_k8s_version="1.22" state="alpha" >}}
+
+쿠버네티스는 파드의 DNS 환경 설정을 위해 기본적으로 최대 6개의 탐색 도메인과 
+최대 256자의 탐색 도메인 목록을 허용한다.
+
+kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화되어 있으면, 
+쿠버네티스는 최대 32개의 탐색 도메인과 
+최대 2048자의 탐색 도메인 목록을 허용한다.
+
+### 기능 가용성
+
+파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
+
+| 쿠버네티스 버전 | 기능 지원 |
+| :---------: |:-----------:|
+| 1.14 | 안정 |
+| 1.10 | 베타 (기본값으로 켜져 있음)|
+| 1.9 | 알파 |
+
+
 ## {{% heading "whatsnext" %}}


@@ -32,6 +32,7 @@ weight: 40
  Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
 * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
 * [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
+* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
 * F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
  이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
 * [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
@@ -1,4 +1,6 @@
 ---
+
+
 title: 인그레스(Ingress)
 content_type: concept
 weight: 40
@@ -222,7 +224,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클

 #### 네임스페이스 범위의 파라미터

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 `Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
 사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
@@ -223,7 +223,7 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex

 ## 포트 범위 지정

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.

@@ -251,17 +251,25 @@ spec:
      endPort: 32768
 ```

-위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
+위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 
+네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 
+TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.

 이 필드를 사용할 때 다음의 제한 사항이 적용된다.
-* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+* 베타 기능으로, 기본적으로 활성화되어 있다. 
+클러스터 수준에서 `endPort` 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가 
+API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 이용하여 
+`NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
 * `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
 * `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
 * 두 포트 모두 숫자여야 한다.

 {{< note >}}
-클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
-네트워크폴리시 명세에서 `endPort` 필드를 지원한다.
+클러스터가 네트워크폴리시 명세의 `endPort` 필드를 지원하는
+{{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
+만약 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)이 
+`endPort` 필드를 지원하지 않는데 네트워크폴리시의 해당 필드에 명시를 하면, 
+그 정책은 `port` 필드에만 적용될 것이다.
 {{< /note >}}

 ## 이름으로 네임스페이스 지정
@@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
 마찬가지로, 서비스 정의를 API 서버에 `POST`하여
 새 인스턴스를 생성할 수 있다.
 서비스 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names)이어야 한다.

 예를 들어, 각각 TCP 포트 9376에서 수신하고
 `app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
@@ -188,9 +188,10 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.

 ### 초과 용량 엔드포인트
-엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
-클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
-이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
+엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상)
+클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: truncated` 어노테이션을 추가한다.
+이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며
+엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.

 ### 엔드포인트슬라이스

@@ -384,6 +385,40 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
 유효하지 않은 clusterIP 주소 값으로 서비스를 생성하려고 하면, API 서버는
 422 HTTP 상태 코드를 리턴하여 문제점이 있음을 알린다.

+## 트래픽 정책
+
+### 외부 트래픽 정책
+
+`spec.externalTrafficPolicy` 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
+이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, 
+`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 
+엔드포인트가 하나도 없는 경우, kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다.
+
+{{< note >}}
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+kube-proxy에 대해 `ProxyTerminatingEndpoints` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 
+활성화하면, kube-proxy는 노드에 로컬 엔드포인트가 있는지, 
+그리고 모든 로컬 엔드포인트가 "종료 중(terminating)"으로 표시되어 있는지 여부를 확인한다.
+만약 로컬 엔드포인트가 존재하는데 **모두**가 종료 중이면, kube-proxy는 `Local`로 설정된 모든 외부 트래픽 정책을 무시한다. 
+대신, 모든 노드-로컬 엔드포인트가 "종료 중" 상태를 유지하는 동안, 
+kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 것처럼 
+그 서비스에 대한 트래픽을 정상 상태의 다른 엔드포인트로 포워드한다.
+이러한 종료 중인 엔드포인트에 대한 포워딩 정책은 `NodePort` 서비스로 트래픽을 로드밸런싱하던 외부 로드밸런서가 
+헬스 체크 노드 포트가 작동하지 않을 때에도 연결들을 비돌발적으로(gracefully) 종료시킬 수 있도록 하기 위해 존재한다.
+이러한 정책이 없다면, 노드가 여전히 로드밸런서 노드 풀에 있지만 
+파드 종료 과정에서 트래픽이 제거(drop)되는 상황에서 트래픽이 유실될 수 있다.
+{{< /note >}}
+
+### 내부 트래픽 정책
+
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+
+`spec.internalTrafficPolicy` 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
+이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며, 
+`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬 
+엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 포워드하지 않는다.
+
 ## 서비스 디스커버리하기

 쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
@@ -394,7 +429,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
 파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
 환경 변수 세트를 추가한다. [도커 링크
 호환](https://docs.docker.com/userguide/dockerlinks/) 변수
-([makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와
+([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와
 보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.

@@ -523,6 +558,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
 [kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
 동등한 `nodePortAddresses` 필드를
 특정 IP 블록으로 설정할 수 있다.
+
 이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.

 예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
@@ -641,12 +677,12 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정

 #### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

-v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에
-대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다.
-기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는
-클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
+`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
+기본적으로, `spec.loadBalancerClass` 는 `nil` 이고, 
+클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면 
+`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
 `spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
 구현이 서비스를 감시하고 있다고 가정한다.
 모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
@@ -656,7 +692,6 @@ v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer`
 `spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는
 "`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
 접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
-이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다.

 #### 내부 로드 밸런서

@@ -314,12 +314,9 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
 * [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
 * [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
 * [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
-* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
-  (**사용 중단**)
 * [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI)
 * [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지
 * [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
-* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
 * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
 * [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
 * [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
@@ -329,17 +326,28 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
 * [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
  로컬 스토리지 디바이스
 * [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지
-* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
-  (이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
-  작동하지 않는다.)
 * [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
-* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
 * [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 볼륨
-* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
-  (**사용 중단**)
-* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
 * [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨

+아래의 PersistentVolume 타입은 사용 중단되었다. 이 말인 즉슨, 지원은 여전히 제공되지만 추후 쿠버네티스 릴리스에서는 삭제될 예정이라는 것이다.
+
+* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
+  (v1.18에서 **사용 중단**)
+* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
+  (v1.22에서 **사용 중단**)
+* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
+  (v1.22에서 **사용 중단**)
+* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
+  (v1.22에서 **사용 중단**)
+
+이전 쿠버네티스 버전은 아래의 인-트리 PersistentVolume 타입도 지원했었다.
+
+* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
+  (v1.15 이후 **사용 불가**)
+* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
+  (v1.21 이후 **사용 불가**)
+
 ## 퍼시스턴트 볼륨

 각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다.
@@ -407,38 +415,40 @@ spec:
 * ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
 * ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다
 * ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
+* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다.
+  쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다.

 CLI에서 접근 모드는 다음과 같이 약어로 표시된다.

 * RWO - ReadWriteOnce
 * ROX - ReadOnlyMany
 * RWX - ReadWriteMany
+* RWOP - ReadWriteOncePod

 > __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다.


-| Volume Plugin        | ReadWriteOnce          | ReadOnlyMany          | ReadWriteMany|
-| :---                 | :---:                  | :---:                 | :---:        |
-| AWSElasticBlockStore | &#x2713;               | -                     | -            |
-| AzureFile            | &#x2713;               | &#x2713;              | &#x2713;     |
-| AzureDisk            | &#x2713;               | -                     | -            |
-| CephFS               | &#x2713;               | &#x2713;              | &#x2713;     |
-| Cinder               | &#x2713;               | -                     | -            |
-| CSI                  | 드라이버에 따라 다름    | 드라이버에 따라 다름    | 드라이버에 따라 다름 |
-| FC                   | &#x2713;               | &#x2713;              | -            |
-| FlexVolume           | &#x2713;               | &#x2713;              | 드라이버에 따라 다름 |
-| Flocker              | &#x2713;               | -                     | -            |
-| GCEPersistentDisk    | &#x2713;               | &#x2713;              | -            |
-| Glusterfs            | &#x2713;               | &#x2713;              | &#x2713;     |
-| HostPath             | &#x2713;               | -                     | -            |
-| iSCSI                | &#x2713;               | &#x2713;              | -            |
-| Quobyte              | &#x2713;               | &#x2713;              | &#x2713;     |
-| NFS                  | &#x2713;               | &#x2713;              | &#x2713;     |
-| RBD                  | &#x2713;               | &#x2713;              | -            |
-| VsphereVolume        | &#x2713;               | -                     | - (파드가 병치될(collocated) 때 작동)  |
-| PortworxVolume       | &#x2713;               | -                     | &#x2713;     |
-| ScaleIO              | &#x2713;               | &#x2713;              | -            |
-| StorageOS            | &#x2713;               | -                     | -            |
+| Volume Plugin        | ReadWriteOnce          | ReadOnlyMany          | ReadWriteMany | ReadWriteOncePod       |
+| :---                 | :---:                  | :---:                 | :---:         | -                      |
+| AWSElasticBlockStore | &#x2713;               | -                     | -             | -                      |
+| AzureFile            | &#x2713;               | &#x2713;              | &#x2713;      | -                      |
+| AzureDisk            | &#x2713;               | -                     | -             | -                      |
+| CephFS               | &#x2713;               | &#x2713;              | &#x2713;      | -                      |
+| Cinder               | &#x2713;               | -                     | -             | -                      |
+| CSI                  | depends on the driver  | depends on the driver | depends on the driver | depends on the driver |
+| FC                   | &#x2713;               | &#x2713;              | -             | -                      |
+| FlexVolume           | &#x2713;               | &#x2713;              | depends on the driver | -              |
+| Flocker              | &#x2713;               | -                     | -             | -                      |
+| GCEPersistentDisk    | &#x2713;               | &#x2713;              | -             | -                      |
+| Glusterfs            | &#x2713;               | &#x2713;              | &#x2713;      | -                      |
+| HostPath             | &#x2713;               | -                     | -             | -                      |
+| iSCSI                | &#x2713;               | &#x2713;              | -             | -                      |
+| Quobyte              | &#x2713;               | &#x2713;              | &#x2713;      | -                      |
+| NFS                  | &#x2713;               | &#x2713;              | &#x2713;      | -                      |
+| RBD                  | &#x2713;               | &#x2713;              | -             | -                      |
+| VsphereVolume        | &#x2713;               | -                     | - (works when Pods are collocated) | - |
+| PortworxVolume       | &#x2713;               | -                     | &#x2713;      | -                  | - |
+| StorageOS            | &#x2713;               | -                     | -             | -                      |

 ### 클래스

@@ -785,6 +795,82 @@ spec:
      storage: 10Gi
 ```

+## 볼륨 파퓰레이터(Volume populator)와 데이터 소스
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다. 
+이 알파 기능은 쿠버네티스 1.18에서 도입되었으며 
+1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다.
+현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번 
+확인한다. {{% version-check %}}
+커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해 
+`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+{{< /note >}}
+
+볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다. 
+다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는 
+`dataSource` 필드와는 다르게, `dataSourceRef` 필드는 동일 네임스페이스에 있는 
+어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외). 
+기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다.
+
+## 데이터 소스 참조
+
+`dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다. 
+둘 중 하나만 명시되어 있으면, API 서버는 두 필드에 같은 값을 할당할 것이다. 
+두 필드 모두 생성 이후에는 변경될 수 없으며, 
+두 필드에 다른 값을 넣으려고 시도하면 검증 에러가 발생할 것이다. 
+따라서 두 필드는 항상 같은 값을 갖게 된다.
+
+`dataSourceRef` 필드와 `dataSource` 필드 사이에는 
+사용자가 알고 있어야 할 두 가지 차이점이 있다.
+* `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만, 
+  `dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다. 
+  유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다.
+* `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는 
+  PVC와 VolumeSnapshot만 포함할 수 있다.
+
+기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은 
+클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야 
+할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만 
+존재하는 것이다. 상세히 설명하면, 이전 버전과 새로운 버전의 컨트롤러가 함께 동작할 
+수 있는데, 이는 두 필드가 동일하기 때문이다.
+
+### 볼륨 파퓰레이터 사용하기
+
+볼륨 파퓰레이터는 비어 있지 않은 볼륨(non-empty volume)을 생성할 수 있는 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}이며, 
+이 볼륨의 내용물은 커스텀 리소스(Custom Resource)에 의해 결정된다.
+파퓰레이티드 볼륨(populated volume)을 생성하려면 `dataSourceRef` 필드에 커스텀 리소스를 기재한다.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: populated-pvc
+spec:
+  dataSourceRef:
+    name: example-name
+    kind: ExampleDataSource
+    apiGroup: example.storage.k8s.io
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
+```
+
+볼륨 파퓰레이터는 외부 컴포넌트이기 때문에, 
+만약 적합한 컴포넌트가 설치되어 있지 않다면 볼륨 파퓰레이터를 사용하는 PVC에 대한 생성 요청이 실패할 수 있다.
+외부 컨트롤러는 '컴포넌트가 없어서 PVC를 생성할 수 없음' 경고와 같은 
+PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이벤트를 생성해야 한다.
+
+알파 버전의 [볼륨 데이터 소스 검증기](https://github.com/kubernetes-csi/volume-data-source-validator)를 
+클러스터에 설치할 수 있다. 
+해당 데이터 소스를 다루는 파퓰레이터가 등록되어 있지 않다면 이 컨트롤러가 PVC에 경고 이벤트를 생성한다.
+PVC를 위한 적절한 파퓰레이터가 설치되어 있다면, 
+볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다.
+
 ## 포터블 구성 작성

 광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한
@@ -0,0 +1,117 @@
+---
+
+
+
+
+
+
+title: 스토리지 용량
+content_type: concept
+weight: 45
+---
+
+<!-- overview -->
+
+스토리지 용량은 제한이 있으며, 파드가 실행되는 노드의 상황에 따라 달라질 수 있다.
+예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
+또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+
+이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
+스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에
+파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다.
+스토리지 용량을 추적하지 않으면, 스케줄러는
+볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며,
+스케줄링을 여러 번 다시 시도해야 한다.
+
+스토리지 용량 추적은 {{< glossary_tooltip
+text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며,
+CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다.
+
+<!-- body -->
+
+## API
+
+ 이 기능에는 다음 두 가지 API 확장이 있다.
+- CSIStorageCapacity 오브젝트:
+  CSI 드라이버가 설치된 네임스페이스에
+  CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는
+  하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며,
+  어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다.
+- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io):
+  `true`로 설정하면, 쿠버네티스 스케줄러가
+  CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다.
+
+## 스케줄링
+
+다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다.
+- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고,
+- 파드가 아직 생성되지 않은 볼륨을 사용하고,
+- 해당 볼륨은 CSI 드라이버를 참조하고
+  `WaitForFirstConsumer`
+  [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 사용하는
+  {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 사용하고,
+- 드라이버의 `CSIDriver` 오브젝트에 `StorageCapacity` 속성이
+  true로 설정되어 있다.
+
+이 경우 스케줄러는 파드에 제공할
+충분한 스토리지가 있는 노드만 고려한다.
+이 검사는 아주 간단한데,
+볼륨의 크기를 노드를 포함하는 토폴로지를 가진 `CSIStorageCapacity` 오브젝트에
+나열된 용량과 비교한다.
+
+볼륨 바인딩 모드가 `Immediate` 인 볼륨의 경우에는 스토리지 드라이버는
+볼륨을 사용하는 파드와 관계없이 볼륨을 생성할 위치를 정한다.
+볼륨을 생성한 후에, 스케줄러는
+볼륨을 사용할 수 있는 노드에 파드를 스케줄링한다.
+
+[CSI 임시 볼륨](/ko/docs/concepts/storage/volumes/#csi)의 경우에는
+볼륨 유형이 로컬 볼륨이고
+큰 자원이 필요하지 않은 특정 CSI 드라이버에서만 사용된다는 가정하에,
+항상 스토리지 용량을 고려하지 않고
+스케줄링한다.
+
+## 리스케줄링
+
+`WaitForFirstConsumer` 볼륨을 가진 파드에 대해
+노드가 선정되었더라도 아직은 잠정적인 결정이다. 다음 단계에서
+선정한 노드에서 볼륨을 사용할 수 있어야 한다는 힌트를 주고
+CSI 스토리지 드라이버에 볼륨 생성을 요청한다
+
+쿠버네티스는 시간이 지난 스토리지 용량 정보를 기반으로
+노드를 선정할 수도 있으므로, 볼륨을 실제로 생성하지 않을 수도 있다.
+그런 다음 노드 선정이 재설정되고 쿠버네티스 스케줄러가
+파드를 위한 노드를 찾는 것을 재시도한다.
+
+## 제한사항
+
+스토리지 용량 추적은 첫 시도에 스케줄링이 성공할 가능성을 높이지만,
+스케줄러가 시간이 지난 정보를 기반으로
+결정해야 할 수도 있기 때문에 이를 보장하지는 않는다.
+일반적으로 스토리지 용량 정보가 없는 스케줄링과
+동일한 재시도 메커니즘으로 스케줄링 실패를 처리한다.
+
+스케줄링이 영구적으로 실패할 수 있는 한 가지 상황은
+파드가 여러 볼륨을 사용하는 경우이다.
+토폴로지 세그먼트에 하나의 볼륨이 이미 생성되어
+다른 볼륨에 충분한 용량이 남아 있지 않을 수 있다.
+이러한 상황을 복구하려면
+용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하며,
+자동으로 처리하려면
+[추가 작업](https://github.com/kubernetes/enhancements/pull/1703)이 필요하다.
+
+## 스토리지 용량 추적 활성화
+
+스토리지 용량 추적은 베타 기능이며,
+쿠버네티스 1.21 이후 버전부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있다.
+클러스터에서 스토리지 용량 추적 기능을 활성화하는 것뿐만 아니라, CSI 드라이버에서도 이 기능을 지원해야 한다.
+자세한 내용은 드라이버 문서를 참조한다.
+
+## {{% heading "whatsnext" %}}
+
+- 설계에 대한 자세한 내용은
+ [파드 스케줄링 스토리지 용량 제약 조건](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)을 참조한다.
+- 이 기능의 추가 개발에 대한 자세한 내용은 [개선 추적 이슈 #1472](https://github.com/kubernetes/enhancements/issues/1472)를 참조한다.
+- [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 살펴본다.
@@ -76,7 +76,7 @@ volumeBindingMode: Immediate
 | Glusterfs            | &#x2713;            | [Glusterfs](#glusterfs)              |
 | iSCSI                | -                   | -                                    |
 | Quobyte              | &#x2713;            | [Quobyte](#quobyte)                  |
-| NFS                  | -                   | -                                    |
+| NFS                  | -                   | [NFS](#nfs)       |
 | RBD                  | &#x2713;            | [Ceph RBD](#ceph-rbd)                |
 | VsphereVolume        | &#x2713;            | [vSphere](#vsphere)                  |
 | PortworxVolume       | &#x2713;            | [Portworx 볼륨](#portworx-볼륨)  |
@@ -423,6 +423,29 @@ parameters:
    헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
    삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.

+### NFS
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: example-nfs
+provisioner: example.com/external-nfs
+parameters:
+  server: nfs-server.example.com
+  path: /share
+  readOnly: false
+```
+
+* `server`: NFS 서버의 호스트네임 또는 IP 주소.
+* `path`: NFS 서버가 익스포트(export)한 경로.
+* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false).
+
+쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다.
+예시는 다음과 같다.
+* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
+* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
+
 ### OpenStack Cinder

 ```yaml
@@ -578,6 +601,12 @@ parameters:

 ### Quobyte

+{{< feature-state for_k8s_version="v1.22" state="deprecated" >}}
+
+Quobyte 인-트리 스토리지 플러그인은 사용 중단되었으며, 
+아웃-오브-트리 Quobyte 플러그인에 대한 [예제](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml) 
+`StorageClass`는 Quobyte CSI 저장소에서 찾을 수 있다.
+
 ```yaml
 apiVersion: storage.k8s.io/v1
 kind: StorageClass
@@ -124,13 +124,13 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
 {{< feature-state for_k8s_version="v1.17" state="alpha" >}}

 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지
-플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `true` 로 설정한다. 이 기능은 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다.
+플러그인을 끄려면, `InTreePluginAWSUnregister` 플래그를 `true` 로 설정한다.

 ### azureDisk {#azuredisk}

 `azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다.

-더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)을 참고한다.
+더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md)을 참고한다.

 #### azureDisk CSI 마이그레이션

@@ -148,7 +148,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
 `azureFile` 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에
 마운트한다.

-더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)을 참고한다.
+더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md)을 참고한다.

 #### azureFile CSI 마이그레이션

@@ -176,7 +176,7 @@ Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용
 CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다.
 {{< /note >}}

-더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다.
+더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)를 참조한다.

 ### cinder

@@ -347,7 +347,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
 쿠버네티스 호스트가 해당 LUN에 접근할 수 있다.
 {{< /note >}}

-더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)를 참고한다.
+더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)를 참고한다.

 ### flocker (사용 중단됨(deprecated)){#flocker}

@@ -365,7 +365,7 @@ Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이
 `flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다.
 {{< /note >}}

-더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다.
+더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다.

 ### gcePersistentDisk

@@ -462,7 +462,8 @@ spec:
    required:
      nodeSelectorTerms:
      - matchExpressions:
-        - key: failure-domain.beta.kubernetes.io/zone
+        # 1.21 이전 버전에서는 failure-domain.beta.kubernetes.io/zone 키를 사용해야 한다.
+        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - us-central1-a
@@ -480,6 +481,13 @@ GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러
 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE`
 베타 기능을 활성화해야 한다.

+#### GCE CSI 마이그레이션 완료
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+컨트롤러 매니저와 kubelet이 `gcePersistentDisk` 스토리지 플러그인을 로드하는 것을 방지하려면, 
+`InTreePluginGCEUnregister` 플래그를 `true`로 설정한다.
+
 ### gitRepo (사용 중단됨) {#gitrepo}

 {{< warning >}}
@@ -525,7 +533,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
 사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다.
 {{< /note >}}

-더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다.
+더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다.

 ### hostPath {#hostpath}

@@ -653,7 +661,7 @@ iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수
 iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있다.
 동시 쓰기는 허용되지 않는다.

-더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다.
+더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/master/volumes/iscsi)를 본다.

 ### local

@@ -741,7 +749,7 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla
 사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다.
 {{< /note >}}

-더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다.
+더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다.

 ### persistentVolumeClaim {#persistentvolumeclaim}

@@ -789,7 +797,7 @@ spec:
 있는지 확인한다.
 {{< /note >}}

-자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) 예제를 참고한다.
+자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) 예제를 참고한다.

 ### projected

@@ -803,7 +811,7 @@ spec:
 * `serviceAccountToken`

 모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은
-[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
+[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다.

 #### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap}

@@ -931,7 +939,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마
 해당 볼륨 소스의 업데이트를 수신하지 않는다.
 {{< /note >}}

-### quobyte
+### quobyte (사용 중단됨) {#quobyte}

 `quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을
 파드에 마운트할 수 있다.
@@ -964,52 +972,9 @@ RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수
 RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
 동시 쓰기는 허용되지 않는다.

-더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를
+더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를
 참고한다.

-### scaleIO (사용 중단됨) {#scaleio}
-
-ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를
-생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨
-플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수
-있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는
-방법에 대한 자세한 내용은
-[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다.
-
-{{< note >}}
-사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고
-생성한 볼륨과 함께 실행해야 한다.
-{{< /note >}}
-
-다음의 예시는 ScaleIO를 사용하는 파드 구성이다.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: pod-0
-spec:
-  containers:
-  - image: k8s.gcr.io/test-webserver
-    name: pod-0
-    volumeMounts:
-    - mountPath: /test-pd
-      name: vol-0
-  volumes:
-  - name: vol-0
-    scaleIO:
-      gateway: https://localhost:443/api
-      system: scaleio
-      protectionDomain: sd0
-      storagePool: sp1
-      volumeName: vol-0
-      secretRef:
-        name: sio-secret
-      fsType: xfs
-```
-
-더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) 예제를 참고한다.
-
 ### secret

 `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데
@@ -1029,7 +994,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토

 더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다.

-### storageOS {#storageos}
+### storageOS (사용 중단됨) {#storageos}

 `storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com)
 볼륨을 파드에 마운트할 수 있다.
@@ -1177,7 +1142,7 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를

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

-`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다.
+`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다.

 ## subPath 사용하기 {#using-subpath}

@@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는

 ## 크론잡

-크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인
-작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
-스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
+크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다. 
+각 작업은 무기한 반복되도록 구성해야 한다(예: 
+1일/1주/1달마다 1회). 
+작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다.

 ### 예시

@@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를

 파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
-디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
-다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
+디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면, 
+파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
+
+예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
@@ -6,6 +6,18 @@ weight: 60

 <!-- overview -->

+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
 쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
 소유자가 없는 오브젝트들을 삭제하는 역할을 한다.

@@ -187,14 +187,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고

 ### 완료 모드

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
-
-{{< note >}}
-인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
-`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
-{{< /note >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
 `.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
@@ -203,8 +196,14 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
  완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드
  완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는
  잡은 암시적으로 `NonIndexed` 이다.
- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index`
-  어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다.
+- `Indexed`: 잡의 파드는 연결된 완료 인덱스를 0에서 `.spec.completions-1` 까지 
+  가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다.
+  - 파드 어노테이션 `batch.kubernetes.io/job-completion-index`.
+  - 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). 인덱스된(Indexed) 잡과 
+    {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 
+    있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 
+    호스트네임을 사용할 수 있다.
+  - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
  각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
  간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
  [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@@ -255,7 +254,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고

 ## 잡의 종료와 정리

-잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다.  이를 유지하면
+잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다.  
+이를 유지하면
 완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
 잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
 `kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.
@@ -402,14 +402,12 @@ spec:

 ### 잡 일시 중지

-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

 {{< note >}}
-잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을
-사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
-`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
+이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며, 
+이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다. 
+[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
 {{< /note >}}

 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
@@ -568,6 +566,46 @@ spec:
 `manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
 불일치를 허용한다.

+### 종료자(finalizers)를 이용한 잡 추적
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+이 기능을 이용하기 위해서는 
+[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와 
+[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해 
+`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 
+기본적으로는 비활성화되어 있다.
+
+이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. 
+기존에 존재하던 잡은 영향을 받지 않는다. 
+사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
+{{< /note >}}
+
+이 기능이 활성화되지 않으면, 잡 
+{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 
+`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다. 
+그런데, 파드는 다음과 같은 이유로 제거될 수 있다.
+- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거
+- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를 
+  일정 임계값 이후에 제거
+- 잡에 속한 파드를 사용자가 임의로 제거
+- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나 
+  교체
+
+클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면, 
+컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고 
+API 서버에서 파드가 제거되면 이를 알아챈다. 
+이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다. 
+컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로, 
+이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다.
+
+잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다. 
+이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다. 
+잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여, 
+잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다. 
+이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**.
+
 ## 대안

 ### 베어(Bare) 파드
@@ -594,7 +632,7 @@ spec:
 시작하기에는 다소 복잡할 수 있으며 쿠버네티스와의 통합성이 낮아진다.

 이 패턴의 한 예시는 파드를 시작하는 잡이다. 파드는 스크립트를 실행해서
-스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)를 본다)를 시작하고,
+스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)를 본다)를 시작하고,
 스파크 드라이버를 실행한 다음, 정리한다.

 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
@@ -323,9 +323,9 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.

 ### 파드 삭제 비용
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}

-[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
+[`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
 레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다.

 이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다.
@@ -335,9 +335,9 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다.
 유효하지 않은 값은 API 서버가 거부한다.

-이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다. 
-kube-apiserver와 kube-controller-manager에서 `PodDeletionCost` 
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다.
+이 기능은 베타 상태이며 기본적으로 활성화되어 있다. 
+kube-apiserver와 kube-controller-manager에 대해 `PodDeletionCost` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.

 {{< note >}}
 - 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.
@@ -32,7 +32,7 @@ weight: 30

 ## 제한사항

-* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
+* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
 * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
 * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
 * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
@@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가

 ## 업데이트 전략

-쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
+스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
 파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
-구성하거나 비활성화 할 수 있다.
+구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다.

-### 삭제 시(On Delete)
-
-`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
-`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는
-스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
+`OnDelete`(삭제시)
+: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 
+스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 
+사용자는 컨트롤러가 스테이트풀셋의
 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.

-### 롤링 업데이트
+`RollingUpdate`(롤링 업데이트)
+: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
+구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.

-`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
-구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
-스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
-순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
-각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
-때까지 기다린다.
+## 롤링 업데이트

-#### 파티션(Partition)
+스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
+스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이
+순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로),
+각 파드의 업데이트는 한 번에 하나씩 한다.
+
+쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
+`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
+
+### 파티션 롤링 업데이트 {#partitions}

 `롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition`
 를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가
@@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.

-#### 강제 롤백
+### 강제 롤백

 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
 함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우
@@ -273,8 +277,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가

 템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로
 실행하려고 시도한 모든 파드를 삭제해야 한다.
-그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
+그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.

+### 최소 준비 시간 초 {#minimum-ready-seconds}
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 
+컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
+기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
+파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
+[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
+
+이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.

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

@@ -257,8 +257,12 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여

 ## 컨테이너에 대한 특권 모드

-파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
-특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다.
+리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
+클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다.
+
+파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다.
+
+HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.

 {{< note >}}
 이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
@@ -282,6 +286,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
 여기에서 제어할 수는 없다는 의미이다.

+## 컨테이너 프로브
+
+_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
+
+- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
+- `TCPSocketAction` (kubelet에 의해 직접 검사)
+- `HTTPGetAction` (kubelet에 의해 직접 검사)
+
+[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
+파드 라이프사이클 문서를 참고한다.
+
 ## {{% heading "whatsnext" %}}

 * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
@@ -6,15 +6,15 @@ weight: 80

 <!-- overview -->

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

-이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
-트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서
-임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
-컨테이너를 사용한다.
+이 페이지는 임시 컨테이너에 대한 개요를 제공한다. 
+이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 
+기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다. 
+임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다.

 {{< warning >}}
-임시 컨테이너는 초기 알파 상태이며,
+임시 컨테이너 기능은 알파 상태이며,
 프로덕션 클러스터에는 적합하지 않다.
 [쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
@@ -72,119 +72,8 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지

 임시 컨테이너 사용 시 [프로세스 네임스페이스
 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
-활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다.
+활성화하면 다른 컨테이너 안의 프로세스를 보는 데 도움이 된다.

-임시 컨테이너를 사용해서 문제를 해결하는 예시는
-[임시 디버깅 컨테이너로 디버깅하기]
-(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다.
+## {{% heading "whatsnext" %}}

-## 임시 컨테이너 API
-
-{{< note >}}
-이 섹션의 예시는 `EphemeralContainers` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
-활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
-{{< /note >}}
-
-이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
-보여준다. 일반적으로 `kubectl debug` 또는
-다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
-사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
-
-임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
-사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
-`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다.
-
-```json
-{
-    "apiVersion": "v1",
-    "kind": "EphemeralContainers",
-    "metadata": {
-        "name": "example-pod"
-    },
-    "ephemeralContainers": [{
-        "command": [
-            "sh"
-        ],
-        "image": "busybox",
-        "imagePullPolicy": "IfNotPresent",
-        "name": "debugger",
-        "stdin": true,
-        "tty": true,
-        "terminationMessagePolicy": "File"
-    }]
-}
-```
-
-이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다.
-
-```shell
-kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers  -f ec.json
-```
-
-그러면 새로운 임시 컨테이너 목록이 반환된다.
-
-```json
-{
-   "kind":"EphemeralContainers",
-   "apiVersion":"v1",
-   "metadata":{
-      "name":"example-pod",
-      "namespace":"default",
-      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
-      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
-      "resourceVersion":"15886",
-      "creationTimestamp":"2019-08-29T06:41:42Z"
-   },
-   "ephemeralContainers":[
-      {
-         "name":"debugger",
-         "image":"busybox",
-         "command":[
-            "sh"
-         ],
-         "resources":{
-
-         },
-         "terminationMessagePolicy":"File",
-         "imagePullPolicy":"IfNotPresent",
-         "stdin":true,
-         "tty":true
-      }
-   ]
-}
-```
-
-사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다.
-
-```shell
-kubectl describe pod example-pod
-```
-
-```
-...
-Ephemeral Containers:
-  debugger:
-    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
-    Image:         busybox
-    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
-    Port:          <none>
-    Host Port:     <none>
-    Command:
-      sh
-    State:          Running
-      Started:      Thu, 29 Aug 2019 06:42:21 +0000
-    Ready:          False
-    Restart Count:  0
-    Environment:    <none>
-    Mounts:         <none>
-...
-```
-
-예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서
-다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와
-상호작용할 수 있다.
-
-```shell
-kubectl attach -it example-pod -c debugger
-```
+* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
@@ -290,8 +290,9 @@ myapp-pod   1/1       Running   0          9m
 초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
 다음의 규칙이 적용된다.

-* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
-  높은 것은 *유효한 초기화 요청량/상한* 이다.
+* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 
+  가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는 
+  이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
 * 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
  * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
  * 리소스에 대한 유효한 초기화 요청량/상한
@@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다.
   확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
   프로세스를 시작한다.
   1. 파드의 컨테이너 중 하나가 `preStop`
-      [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
+      [훅](/ko/docs/concepts/containers/container-lifecycle-hooks)을 정의한 경우, kubelet은
      컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
      계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
      요청한다.