[ko] Update outdated files in dev-1.24-ko.1 M34-M48

content/ko/docs/concepts/scheduling-eviction/pod-overhead.md

@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 파드 오버헤드
 content_type: concept
 weight: 30
@@ -6,17 +10,12 @@ weight: 30
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
-
+노드 상에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
-노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다.
-_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해
+쿠버네티스에서, _파드 오버헤드_ 는 리소스 요청 및 상한 외에도 
-소비되는 리소스를 계산하는 기능이다.
+파드의 인프라에 의해 소비되는 리소스를 계산하는 방법 중 하나이다.
-
-
-
-
 
 <!-- body -->
 
@@ -25,26 +24,23 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
 [어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
 이 수행될 때 지정된다.
 
-파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에
+파드를 노드에 스케줄링할 때, 컨테이너 리소스 요청의 합 뿐만 아니라 파드의 오버헤드도 함께 고려된다. 
-파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나
+마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나 파드의 축출 등급을 부여할 때에도 
-파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다.
+파드의 오버헤드를 포함하여 고려한다.
 
-## 파드 오버헤드 활성화하기 {#set-up}
+## 파드 오버헤드 환경 설정하기 {#set-up}
 
-기능 활성화를 위해 클러스터에서
-`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화),
 `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다.
 
 ## 사용 예제
 
-파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다.
+파드 오버헤드를 활용하려면, `overhead` 필드를 정의하는 런타임클래스가 필요하다.
 예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는
 가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다.
 
 ```yaml
----
-kind: RuntimeClass
 apiVersion: node.k8s.io/v1
+kind: RuntimeClass
 metadata:
   name: kata-fc
 handler: kata-fc
@@ -68,7 +64,7 @@ spec:
   runtimeClassName: kata-fc
   containers:
   - name: busybox-ctr
-    image: busybox
+    image: busybox:1.28
     stdin: true
     tty: true
     resources:
@@ -88,13 +84,15 @@ spec:
 파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가
 `overhead` 를 포함하도록 변경한다.
 
-런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다.
+런타임클래스 어드미션 컨트롤러가 변경을 완료하면, 
+다음의 명령어로 업데이트된 파드 오버헤드 값을 확인할 수 있다.
 
 ```bash
 kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
 ```
 
 명령 실행 결과는 다음과 같다.
+
 ```
 map[cpu:250m memory:120Mi]
 ```
@@ -106,23 +104,26 @@ kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할
 해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는
 리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다.
 
-일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다.
+일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 
+파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다.
 기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다.
 
-만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면,
+만약 각 컨테이너에 대하여 리소스 상한 제한이 걸려있으면 
-kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의
+(제한이 걸려있는 보장된(Guaranteed) Qos 또는 향상 가능한(Burstable) QoS), 
-cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에
+kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 cgroup 의 상한선을 설정한다. 
-정의된 `overhead` 의 합에 기반한다.
+이 상한선은 컨테이너 리소스 상한과 PodSpec에 정의된 `overhead` 의 합에 기반한다.
 
-CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의
+CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, 
-리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다.
+kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다.
 
 다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자.
+
 ```bash
 kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
 ```
 
 컨테이너 리소스 요청의 합은 각각 CPU 2000m 와 메모리 200MiB 이다.
+
 ```
 map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
 ```
@@ -133,7 +134,8 @@ map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
 kubectl describe node | grep test-pod -B2
 ```
 
-CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다.
+결과를 보면 2250 m의 CPU와 320 MiB의 메모리가 리소스로 요청되었다. 여기에는 파드 오버헤드가 포함되어 있다.
+
 ```
   Namespace    Name       CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE
   ---------    ----       ------------  ----------   ---------------  -------------  ---
@@ -142,10 +144,11 @@ CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는
 
 ## 파드 cgroup 상한 확인하기
 
-워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며,
+워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인해 보자. 
+다음의 예제에서, 
+[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, 
 CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. 
-파드의 오버헤드 동작을 보여주는 좋은 예이며,
+파드 오버헤드 동작을 보여주는 좋은 예이며, 사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
-사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
 
 먼저 특정 노드에서 파드의 식별자를 확인해 보자.
 
@@ -155,39 +158,41 @@ POD_ID="$(sudo crictl pods --name test-pod -q)"
 ```
 
 여기에서, 파드의 cgroup 경로를 확인할 수 있다.
+
 ```bash
 # 파드가 스케줄 된 노드에서 이것을 실행
 sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
 ```
 
 명령의 결과로 나온 cgroup 경로는 파드의 `pause` 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다.
+
 ```
   "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
 ```
 
-아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자.
+아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 
+메모리의 파드 레벨 cgroup 설정을 확인하자.
+
 ```bash
 # 파드가 스케줄 된 노드에서 이것을 실행.
 # 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정.
  cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
 ```
 
-예상대로 320 MiB 이다.
+예상한 것과 같이 320 MiB 이다.
+
 ```
 335544320
 ```
 
 ### 관찰성
-`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
-에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고,
-정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
-이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다.
-그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다.
-
 
+몇몇 `kube_pod_overhead` 메트릭은 
+[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 에서 사용할 수 있어, 
+파드 오버헤드가 사용되는 시기를 식별하고, 정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
 
 ## {{% heading "whatsnext" %}}
 
-
+* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)에 대해 알아본다.
-* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)
+* 더 자세한 문맥은 
-* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
+  [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 향상 제안을 확인한다.

content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md

@@ -104,7 +104,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
 
 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class}
 
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
 `preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
 앞쪽에 배치되지만,
@@ -203,9 +203,11 @@ spec:
 정보를 제공한다.
 
 파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다.
+The scheduler always tries the "nominated Node" before iterating over any other nodes.
+스케줄러는 다른 노드에 스케줄링을 시도하기 전에 항상 "지정된 노드"부터 시도한다.
 피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다.
 스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수
-있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과,
+있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용할 수 있다. 그 결과,
 파드 스펙의 `nominatedNodeName` 과 `nodeName` 은 항상 동일하지 않다. 또한,
 스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가
 도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한

content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md

@@ -21,25 +21,24 @@ kube-scheduler를 미세 조정할 수 있다.
 
 ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
 
-쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
+쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 
-용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를
+용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 
-통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
+이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 
 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. 
-`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
+`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 
-동작은 `RequestedToCapacityRatioArgs`라는
+`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다. 
-구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
+이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. 
-두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
+`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로 
-`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
+최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. 
-조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할
+`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과 
-리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로
+각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
-구성된다.
 
 다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
 설정하는 구성의 예시이다.
 
 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
 # ...

content/ko/docs/concepts/security/controlling-access.md

@@ -1,7 +1,9 @@
 ---
+
+
+
 title: 쿠버네티스 API 접근 제어하기
 content_type: concept
-weight: 5
 ---
 
 <!-- overview -->
@@ -29,13 +31,16 @@ API 서버의 인증서에 대한 루트 인증서를 포함하며,
 이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
 클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
 
+클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다.
+
 ## 인증
 
 TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
 이는 다이어그램에 **1**단계로 표시되어 있다.
 클러스터 생성 스크립트 또는 클러스터 관리자는
 API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
-인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
+인증기에 대해서는 
+[인증](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
 
 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
 일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.
@@ -46,8 +51,6 @@ JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
 여러 개의 인증 모듈을 지정할 수 있으며,
 이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
 
-GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
-
 요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
 이 외에는 사용자가 특정 `username`으로 인증되며,
 이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
@@ -126,6 +129,12 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
 요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
 오브젝트 저장소에 기록(**4**단계)된다.
 
+## 감사(Auditing)
+
+쿠버네티스 감사는 클러스터에서 발생하는 일들의 순서를 문서로 기록하여, 보안과 관련되어 있고 시간 순서로 정리된 기록을 제공한다.
+클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자신이 생성한 활동을 감사한다.
+
+더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다.
 
 ## API 서버 포트와 IP
 

content/ko/docs/concepts/services-networking/dns-pod-service.md

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

content/ko/docs/concepts/services-networking/dual-stack.md

@@ -43,7 +43,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
      쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
      문서 참조
    * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
-   * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
+   * 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 
 ## IPv4/IPv6 이중 스택 구성
 

content/ko/docs/concepts/services-networking/endpoint-slices.md

@@ -1,4 +1,6 @@
 ---
+
+
 title: 엔드포인트슬라이스
 content_type: concept
 weight: 45
@@ -144,12 +146,12 @@ endpoints:
 v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별
 `topology` 가 효과적으로 제거되었다.
 
-`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를
+`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 설정하는 것은 
-설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신,
+더 이상 사용되지 않으며 v1 API에서 지원되지 않는다. 
-v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한
+대신, v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 
-필드는 API 버전 간에 자동으로 번역된다. 예를 들어,
+이러한 필드는 API 버전 간에 자동으로 번역된다. 
-v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
+예를 들어, v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` 키 값은 
-키 값은 v1 API의 `zone` 필드로 접근할 수 있다.
+v1 API의 `zone` 필드로 접근할 수 있다.
 {{< /note >}}
 
 ### 관리

content/ko/docs/concepts/services-networking/ingress-controllers.md

@@ -23,7 +23,7 @@ weight: 40
 
 {{% thirdparty-content %}}
 
-* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
+* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com/azure/application-gateway/overview)를 구성하는 인그레스 컨트롤러다.
 * [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) 기반의 인그레스 컨트롤러이다.
@@ -48,6 +48,7 @@ weight: 40
   구동하는 인그레스 컨트롤러다.
 * [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
   웹서버(프록시로 사용)와 함께 작동한다.
+* [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다.
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
 * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
   [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.

content/ko/docs/concepts/services-networking/ingress.md

@@ -74,7 +74,7 @@ graph LR;
 
 {{< codenew file="service/networking/minimal-ingress.yaml" >}}
 
-다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
+인그레스에는 `apiVersion`, `kind`, `metadata` 및 `spec` 필드가 명시되어야 한다.
 인그레스 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
@@ -118,8 +118,14 @@ graph LR;
 
 ### DefaultBackend {#default-backend}
 
-규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로
+규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송하며, 
-[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
+`.spec.defaultBackend`는 이와 같은 경우에 요청을 처리할 백엔드를 지정한다. 
+`defaultBackend` 는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 
+인그레스 리소스에 지정되어 있지 않다. 
+`.spec.rules` 가 명시되어 있지 않으면, 
+`.spec.defaultBackend` 는 반드시 명시되어 있어야 한다. 
+`defaultBackend` 가 설정되어 있지 않으면, 어느 규칙에도 해당되지 않는 요청의 처리는 인그레스 컨트롤러의 구현을 따른다(이러한 
+경우를 어떻게 처리하는지 알아보려면 해당 인그레스 컨트롤러 문서를 참고한다).
 
 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
 기본 백엔드로 라우팅 된다.
@@ -309,7 +315,7 @@ spec:
   controller: example.com/ingress-controller
   parameters:
     # 이 인그레스클래스에 대한 파라미터는 
-    # "external-configuration" 환경 설정 네임스페이스에 있는
+    # "external-configuration" 네임스페이스에 있는
     # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.
     scope: Namespace
     apiGroup: k8s.example.com

content/ko/docs/concepts/services-networking/network-policies.md

@@ -45,42 +45,7 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
 
 네트워크폴리시 의 예시는 다음과 같다.
 
-```yaml
+{{< codenew file="service/networking/networkpolicy.yaml" >}}
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: test-network-policy
-  namespace: default
-spec:
-  podSelector:
-    matchLabels:
-      role: db
-  policyTypes:
-  - Ingress
-  - Egress
-  ingress:
-  - from:
-    - ipBlock:
-        cidr: 172.17.0.0/16
-        except:
-        - 172.17.1.0/24
-    - namespaceSelector:
-        matchLabels:
-          project: myproject
-    - podSelector:
-        matchLabels:
-          role: frontend
-    ports:
-    - protocol: TCP
-      port: 6379
-  egress:
-  - to:
-    - ipBlock:
-        cidr: 10.0.0.0/24
-    ports:
-    - protocol: TCP
-      port: 5978
-```
 
 {{< note >}}
 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
@@ -281,7 +246,7 @@ API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을
 
 ## 이름으로 네임스페이스 지정
 
-{{< feature-state state="beta" for_k8s_version="1.21" >}}
+{{< feature-state for_k8s_version="1.22" state="stable" >}}
 
 쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName`
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우

content/ko/docs/concepts/services-networking/service.md

@@ -24,7 +24,7 @@ weight: 10
 
 ## 동기
 
-쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와
+쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 목표 상태(desired state)와
 일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
 만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면,
 동적으로 파드를 생성하고 제거할 수 있다.
@@ -108,13 +108,46 @@ spec:
 필드와 같은 값으로 설정된다.
 {{< /note >}}
 
-파드의 포트 정의에는 이름이 있고, 서비스의 `targetPort` 속성에서 이 이름을
+파드의 포트 정의에 이름이 있으므로, 
-참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고,
+서비스의 `targetPort` 속성에서 이 이름을 참조할 수 있다. 
-단일 구성 이름을 사용하는 서비스 내에
+예를 들어, 다음과 같은 방법으로 서비스의 `targetPort`를 파드 포트에 바인딩할 수 있다.
-혼합된 파드가 존재해도 가능하다.
+
-이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다.
+```yaml
-예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음
+apiVersion: v1
-버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
+kind: Pod
+metadata:
+  name: nginx
+  labels:
+    app.kubernetes.io/name: proxy
+spec:
+  containers:
+  - name: nginx
+    image: nginx:11.14.2
+    ports:
+      - containerPort: 80
+        name: http-web-svc
+        
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx-service
+spec:
+  selector:
+    app.kubernetes.io/name: proxy
+  ports:
+  - name: name-of-service-port
+    protocol: TCP
+    port: 80
+    targetPort: http-web-svc
+```
+
+
+이것은 서로 다른 포트 번호를 통해 가용한 동일 네트워크 프로토콜이 있고, 
+단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다. 
+이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다. 
+예를 들어, 클라이언트를 망가뜨리지 않고, 
+백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
 
 서비스의 기본 프로토콜은 TCP이다. 다른
 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
@@ -125,9 +158,9 @@ spec:
 
 ### 셀렉터가 없는 서비스
 
-서비스는 일반적으로 쿠버네티스 파드에 대한 접근을 추상화하지만,
+서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만, 
-다른 종류의 백엔드를 추상화할 수도 있다.
+셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며, 
-예를 들면
+여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다.
 
 * 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
   테스트 환경에서는 자체 데이터베이스를 사용한다.
@@ -668,44 +701,38 @@ status:
 
 #### 프로토콜 유형이 혼합된 로드밸런서
 
-{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.24" state="beta" >}}
 
 기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
 포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
 지원하는 프로토콜이어야 한다.
 
-kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
+`MixedProtocolLBService` 기능 게이트(v1.24에서 kube-apiserver에 대해 기본적으로 활성화되어 있음)는 
+둘 이상의 포트가 정의되어 있는 경우에 로드밸런서 타입의 서비스에 대해 서로 다른 프로토콜을 사용할 수 있도록 해 준다.
 
 {{< note >}}
 
 로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다.
+클라우드 제공자가 혼합 프로토콜을 지원하지 않는다면 이는 단일 프로토콜만을 제공한다는 것을 의미한다.
 
 {{< /note >}}
 
 #### 로드밸런서 NodePort 할당 비활성화
 
-{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
 `type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며, 
 이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다. 
 노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
 기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다.
-노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 
+노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
-해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
 이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
-이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl` 
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
-쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로, 
-`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다. 
-다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
 
 #### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
 
-{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
 `spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 
-이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. 
-쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
 기본적으로, `spec.loadBalancerClass` 는 `nil` 이고, 
 클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면 
 `LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
@@ -1211,7 +1238,7 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
 충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는
 많은 일이 있다.
 
-### 충돌 방지
+### 충돌 방지 {#avoiding-collisions}
 
 쿠버네티스의 주요 철학 중 하나는 잘못한 것이
 없는 경우 실패할 수 있는 상황에 노출되어서는
@@ -1219,9 +1246,10 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
 충돌할 경우에 대비해 자신의 포트 번호를 선택하지
 않아도 된다. 그것은 격리 실패이다.
 
-서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의
+서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 
-서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
+두 개의 서비스가 충돌하지 않도록 해야 한다. 
-할당하여 이를 수행한다.
+쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서 
+각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다.
 
 각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는
 각 서비스를 만들기 전에 {{< glossary_tooltip term_id="etcd" >}}에서
@@ -1235,6 +1263,25 @@ IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다.
 할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된
 IP 주소를 정리한다.
 
+#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range}
+
+{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
+그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데, 
+그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address).
+이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면 
+충돌이 발생할 수 있다.
+
+`ServiceIPStaticSubrange` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, 
+할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 
+`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며, 
+여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다. 
+동적 IP 할당은 상위 대역에서 우선적으로 선택하며, 
+이를 통해 하위 대역에서 할당된 IP와의 충돌 위험을 줄인다. 
+이렇게 함으로써 사용자가 서비스의 고정 IP를 
+`service-cluster-ip-range`의 하위 대역에서 할당하면서도 
+충돌 위험을 줄일 수 있다.
+
 ### 서비스 IP 주소 {#ips-and-vips}
 
 실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,

content/ko/docs/concepts/services-networking/topology-aware-hints.md

@@ -19,6 +19,12 @@ _토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드
 예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해, 
 인접성을 고려하여 트래픽을 라우트할 수 있다.
 
+{{< note >}}
+"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**. 
+이 기능을 사용해 보려면, 
+`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+{{< /note >}}
+
 <!-- body -->
 
 ## 동기(motivation)

content/ko/docs/concepts/storage/ephemeral-volumes.md

@@ -107,7 +107,7 @@ metadata:
 spec:
   containers:
     - name: my-frontend
-      image: busybox
+      image: busybox:1.28
       volumeMounts:
       - mountPath: "/data"
         name: my-csi-inline-vol
@@ -125,8 +125,19 @@ spec:
 더 자세한 사항은 각 CSI 드라이버 문서를 
 참고한다.
 
-클러스터 관리자는, [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 사용하여 파드 내에서 어떤 CSI 드라이버가 사용될 수 있는지를 제어할 수 있으며, 
+### CSI 드라이버 제한 사항
-[`allowedCSIDrivers` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)에 기재하면 된다.
+
+CSI 임시 볼륨은 사용자로 하여금 `volumeAttributes`를 
+파드 스펙의 일부로서 CSI 드라이버에 직접 제공할 수 있도록 한다. 
+보통은 관리자만 사용할 수 있는 `volumeAttributes`를 허용하는 CSI 드라이버는 
+내장(inline) 임시 볼륨 내에서 사용하는 것이 적합하지 않다. 
+예를 들어, 일반적으로 스토리지클래스 내에 정의되어 있는 파라미터들은 
+내장 임시 볼륨 사용을 통해 사용자에게 노출되어서는 안 된다.
+
+클러스터 관리자가 이처럼 파드 스펙 내장 임시 볼륨 사용이 가능한 CSI 드라이버를 제한하려면 
+다음을 수행할 수 있다.
+- CSIDriver 스펙의 `volumeLifecycleModes`에서 `Ephemeral`을 제거하여, 해당 드라이버가 내장 임시 볼륨으로 사용되는 것을 막는다.
+- [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 드라이버를 활용하는 방법을 제한한다.
 
 ### 일반 임시 볼륨 {#generic-ephemeral-volumes}
 
@@ -158,7 +169,7 @@ metadata:
 spec:
   containers:
     - name: my-frontend
-      image: busybox
+      image: busybox:1.28
       volumeMounts:
       - mountPath: "/scratch"
         name: scratch-volume
@@ -239,16 +250,9 @@ PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할
 
 GenericEphemeralVolume 기능을 활성화하면 
 사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며, 
-심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. 
+심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. 클러스터 관리자는 이를 명심해야 한다. 
-클러스터 관리자는 이를 명심해야 한다. 
+이것이 보안 모델에 부합하지 않는다면, [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 
-이것이 보안 모델에 부합하지 않는다면, 다음의 두 가지 선택지가 있다.
+일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부해야 한다.
-- `volumes`의 목록 중에 `ephemeral` 볼륨 타입이 없는 경우, 
-  [파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/)를 
-  사용한다(쿠버네티스 
-  1.21에서 사용 중단됨).
-- 일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부하는 
-  [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 
-  사용한다.
 
 일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로, 
 사용자가 이 새로운 메카니즘을 사용할 수 있도록 허용되었어도, 

content/ko/docs/concepts/storage/persistent-volumes.md

@@ -175,6 +175,74 @@ spec:
 
 그러나 `volumes` 부분의 사용자 정의 재활용 파드 템플릿에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 바뀐다.
 
+### 퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer) {#persistentvolume-deletion-protection-finalizer}
+{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
+
+퍼시스턴트볼륨에 파이널라이저를 추가하여, `Delete` 반환 정책을 갖는 퍼시스턴트볼륨이 
+기반 스토리지(backing storage)가 삭제된 이후에만 삭제되도록 할 수 있다.
+
+새롭게 도입된 `kubernetes.io/pv-controller` 및 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 
+동적으로 프로비전된 볼륨에만 추가된다.
+
+`kubernetes.io/pv-controller` 파이널라이저는 인-트리 플러그인 볼륨에 추가된다. 다음은 이에 대한 예시이다.
+
+```shell
+kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
+Name:            pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
+Labels:          <none>
+Annotations:     kubernetes.io/createdby: vsphere-volume-dynamic-provisioner
+                 pv.kubernetes.io/bound-by-controller: yes
+                 pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume
+Finalizers:      [kubernetes.io/pv-protection kubernetes.io/pv-controller]
+StorageClass:    vcp-sc
+Status:          Bound
+Claim:           default/vcp-pvc-1
+Reclaim Policy:  Delete
+Access Modes:    RWO
+VolumeMode:      Filesystem
+Capacity:        1Gi
+Node Affinity:   <none>
+Message:         
+Source:
+    Type:               vSphereVolume (a Persistent Disk resource in vSphere)
+    VolumePath:         [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk
+    FSType:             ext4
+    StoragePolicyName:  vSAN Default Storage Policy
+Events:                 <none>
+```
+
+`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 CSI 볼륨에 추가된다.
+다음은 이에 대한 예시이다.
+```shell
+Name:            pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d
+Labels:          <none>
+Annotations:     pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
+Finalizers:      [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer]
+StorageClass:    fast
+Status:          Bound
+Claim:           demo-app/nginx-logs
+Reclaim Policy:  Delete
+Access Modes:    RWO
+VolumeMode:      Filesystem
+Capacity:        200Mi
+Node Affinity:   <none>
+Message:         
+Source:
+    Type:              CSI (a Container Storage Interface (CSI) volume source)
+    Driver:            csi.vsphere.vmware.com
+    FSType:            ext4
+    VolumeHandle:      44830fa8-79b4-406b-8b58-621ba25353fd
+    ReadOnly:          false
+    VolumeAttributes:      storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com
+                           type=vSphere CNS Block Volume
+Events:                <none>
+```
+
+특정 인-트리 볼륨 플러그인에 대해 `CSIMigration` 기능을 활성화하면 `kubernetes.io/pv-controller` 파이널라이저는 제거되고, 
+`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저가 추가된다. 
+이와 비슷하게, `CSIMigration` 기능을 비활성화하면 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 제거되고, 
+`kubernetes.io/pv-controller` 파이널라이저가 추가된다.
+
 ### 퍼시스턴트볼륨 예약
 
 컨트롤 플레인은 클러스터에서 [퍼시스턴트볼륨클레임을 일치하는 퍼시스턴트볼륨에 바인딩](#바인딩)할
@@ -284,18 +352,13 @@ FlexVolume은 파드 재시작 시 크기를 조정할 수 있다.
 
 #### 사용 중인 퍼시스턴트볼륨클레임 크기 조정
 
-{{< feature-state for_k8s_version="v1.15" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}
-
-{{< note >}}
-사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다.
-{{< /note >}}
 
 이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다.
 파일시스템이 확장되자마자 사용 중인 PVC가 파드에서 자동으로 사용 가능하다.
 이 기능은 파드나 디플로이먼트에서 사용하지 않는 PVC에는 영향을 미치지 않는다. 확장을 완료하기 전에
 PVC를 사용하는 파드를 만들어야 한다.
 
-
 다른 볼륨 유형과 비슷하게 FlexVolume 볼륨도 파드에서 사용 중인 경우 확장할 수 있다.
 
 {{< note >}}
@@ -329,7 +392,7 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
 PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다.
 {{< /note >}}
 
-클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure` 
+클러스터에 `RecoverVolumeExpansionFailure` 
 기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면 
 이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다. 
 더 작은 크기를 지정하여 확장 시도를 요청하려면, 
@@ -849,17 +912,12 @@ spec:
 
 ## 볼륨 파퓰레이터(Volume populator)와 데이터 소스
 
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.24" state="beta" >}}
 
-{{< note >}}
 쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다. 
-이 알파 기능은 쿠버네티스 1.18에서 도입되었으며 
+커스텀 볼륨 파퓰레이터를 사용하려면, 
-1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다.
+kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource` 
-현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
-확인한다. {{% version-check %}}
-커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해 
-`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
-{{< /note >}}
 
 볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다. 
 다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는 
@@ -877,6 +935,7 @@ spec:
 
 `dataSourceRef` 필드와 `dataSource` 필드 사이에는 
 사용자가 알고 있어야 할 두 가지 차이점이 있다.
+
 * `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만, 
   `dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다. 
   유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다.

content/ko/examples/service/networking/networkpolicy.yaml

@@ -0,0 +1,35 @@
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: test-network-policy
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  policyTypes:
+    - Ingress
+    - Egress
+  ingress:
+    - from:
+        - ipBlock:
+            cidr: 172.17.0.0/16
+            except:
+              - 172.17.1.0/24
+        - namespaceSelector:
+            matchLabels:
+              project: myproject
+        - podSelector:
+            matchLabels:
+              role: frontend
+      ports:
+        - protocol: TCP
+          port: 6379
+  egress:
+    - to:
+        - ipBlock:
+            cidr: 10.0.0.0/24
+      ports:
+        - protocol: TCP
+          port: 5978
+