[ko] Update outdated files in dev-1.24-ko.1 M49-M72

2022-05-27 11:23:37 +09:00 · 2022-05-27 11:23:37 +09:00 · 360335002d
parent e6d993feb3
commit 360335002d
21 changed files with 283 additions and 192 deletions
--- a/content/ko/docs/concepts/storage/storage-capacity.md
+++ b/content/ko/docs/concepts/storage/storage-capacity.md
@ -16,37 +16,41 @@ weight: 70
 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.

-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}

 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
 스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에
-파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다.
+[파드를 스케줄링](/ko/docs/concepts/scheduling-eviction/)하기 위해 이 정보를 어떻게 사용하는지 설명한다.
 스토리지 용량을 추적하지 않으면, 스케줄러는
 볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며,
 스케줄링을 여러 번 다시 시도해야 한다.

-스토리지 용량 추적은 {{< glossary_tooltip
-text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며,
-CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다.
+## {{% heading "prerequisites" %}}
+
+쿠버네티스 v{{< skew currentVersion >}} 버전은 스토리지 용량 추적을 위한 클러스터-수준 API를 지원한다. 
+이를 사용하려면, 스토리지 용량 추적을 지원하는 CSI 드라이버를 사용하고 있어야 한다. 
+사용 중인 CSI 드라이버가 이를 지원하는지, 지원한다면 어떻게 사용하는지를 알아보려면 
+해당 CSI 드라이버의 문서를 참고한다. 
+쿠버네티스 v{{< skew currentVersion >}} 버전을 사용하고 있지 않다면, 
+해당 버전 쿠버네티스 문서를 참고한다.

 <!-- body -->

 ## API

 이 기능에는 다음 두 가지 API 확장이 있다.
- CSIStorageCapacity 오브젝트:
+- [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) 오브젝트:
  CSI 드라이버가 설치된 네임스페이스에
  CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는
  하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며,
  어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다.
- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io):
+- [`CSIDriverSpec.StorageCapacity` 필드](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec):
  `true`로 설정하면, 쿠버네티스 스케줄러가
  CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다.

 ## 스케줄링

 다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다.
- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고,
 - 파드가 아직 생성되지 않은 볼륨을 사용하고,
 - 해당 볼륨은 CSI 드라이버를 참조하고
  `WaitForFirstConsumer`
@ -97,20 +101,9 @@ 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/)에 대해 살펴본다.
--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@ -87,7 +87,7 @@ volumeBindingMode: Immediate
 여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이
 이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와
 함께 제공된다). 또한, 쿠버네티스에서 정의한
-[사양](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)을
+[사양](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)을
 따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다.
 외부 프로비저너의 작성자는 코드의 수명, 프로비저너의
 배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인
@ -241,8 +241,8 @@ allowedTopologies:
 - matchLabelExpressions:
  - key: failure-domain.beta.kubernetes.io/zone
    values:
-    - us-central1-a
-    - us-central1-b
+    - us-central-1a
+    - us-central-1b
 ```

 ## 파라미터
--- a/content/ko/docs/concepts/storage/volume-health-monitoring.md
+++ b/content/ko/docs/concepts/storage/volume-health-monitoring.md
@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 볼륨 헬스 모니터링
 content_type: concept
 ---
@ -19,7 +24,7 @@ CSI 드라이버가 컨트롤러 측의 볼륨 헬스 모니터링 기능을 지

 외부 헬스 모니터 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 노드 장애 이벤트도 감시한다. `enable-node-watcher` 플래그를 true로 설정하여 노드 장애 모니터링을 활성화할 수 있다. 외부 헬스 모니터가 노드 장애 이벤트를 감지하면, 컨트롤러는 이 PVC를 사용하는 파드가 장애 상태인 노드에 있음을 나타내는 이벤트가 PVC에 보고된다고 알린다.

-CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다.
+CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다. 그리고, 볼륨 헬스 정보는 kubelet VolumeStats 메트릭 형태로 노출된다. 새로운 kubelet_volume_stats_health_status_abnormal 메트릭이 추가되었다. 이 메트릭은 `namespace` 및 `persistentvolumeclaim` 2개의 레이블을 포함한다. 카운터는 1 또는 0이다. 카운터가 1이면 볼륨이 정상적이지 않음을, 0이면 정상적임을 의미한다. 더 많은 정보는 [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)를 참고한다.

 {{< note >}}
 노드 측에서 이 기능을 사용하려면 `CSIVolumeHealth` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
--- a/content/ko/docs/concepts/storage/volume-snapshots.md
+++ b/content/ko/docs/concepts/storage/volume-snapshots.md
@ -120,6 +120,7 @@ spec:
  driver: hostpath.csi.k8s.io
  source:
    volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
+  sourceVolumeMode: Filesystem
  volumeSnapshotClassName: csi-hostpath-snapclass
  volumeSnapshotRef:
    name: new-snapshot-test
@ -141,6 +142,7 @@ spec:
  driver: hostpath.csi.k8s.io
  source:
    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
+  sourceVolumeMode: Filesystem
  volumeSnapshotRef:
    name: new-snapshot-test
    namespace: default
@ -148,6 +150,51 @@ spec:

 `snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. `VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 지정한다.

+`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다. 
+`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다. 
+소스 볼륨 모드가 명시되어 있지 않으면, 
+쿠버네티스는 해당 스냅샷의 소스 볼륨 모드를 알려지지 않은 상태(unknown)로 간주하여 스냅샷을 처리한다.
+
+## 스냅샷의 볼륨 모드 변환하기 {#convert-volume-mode}
+
+클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면, 
+인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이 
+API에 있는 것이다.
+
+클러스터가 이 기능을 지원하는지 확인하려면, 다음 명령어를 실행한다.
+
+```yaml
+$ kubectl get crd volumesnapshotcontent -o yaml
+```
+
+사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때 
+기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면, 
+`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에 
+`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"` 어노테이션을 추가해야 한다.
+
+이전에 프로비전된 스냅샷의 경우에는, 
+클러스터 관리자가 `Spec.SourceVolumeMode`를 추가해야 한다.
+
+이 기능이 활성화된 예시 `VolumeSnapshotContent` 리소스는 다음과 같을 것이다.
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1
+kind: VolumeSnapshotContent
+metadata:
+  name: new-snapshot-content-test
+  annotations:
+    - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"
+spec:
+  deletionPolicy: Delete
+  driver: hostpath.csi.k8s.io
+  source:
+    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
+  sourceVolumeMode: Filesystem
+  volumeSnapshotRef:
+    name: new-snapshot-test
+    namespace: default
+```
+
 ## 스냅샷을 위한 프로비저닝 볼륨

 `PersistentVolumeClaim` 오브젝트의 *dataSource* 필드를 사용하여
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@ -143,14 +143,20 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n

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

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

-`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
-`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
-드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI
-드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver)
-를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk`
-기능을 활성화해야 한다.
+`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 
+기존 인-트리 플러그인의 모든 플러그인 작업을 
+`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다. 
+이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 를 설치하고 
+`CSIMigration` 기능을 활성화해야 한다.
+
+#### azureDisk CSI 마이그레이션 완료
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+컨트롤러 매니저 및 kubelet이 `azureDisk` 스토리지 플러그인을 로드하지 않도록 하려면, 
+`InTreePluginAzureDiskUnregister` 플래그를 `true`로 설정한다.

 ### azureFile {#azurefile}

@ -170,7 +176,15 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile`
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.

-Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.
+Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. 
+Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.
+
+#### azureFile CSI 마이그레이션 완료
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+컨트롤러 매니저 및 kubelet이 `azureFile` 스토리지 플러그인을 로드하지 않도록 하려면, 
+`InTreePluginAzureFileUnregister` 플래그를 `true`로 설정한다.

 ### cephfs

@ -219,17 +233,17 @@ spec:

 #### 오픈스택 CSI 마이그레이션

-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}

-Cinder의`CSIMigration` 기능은 Kubernetes 1.21에서 기본적으로 활성화됩니다.
+Cinder의`CSIMigration` 기능은 Kubernetes 1.21부터 기본적으로 활성화되어 있다.
 기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
 드라이버로 모든 플러그인 작업을 수행한다.
 [오픈스택 Cinder CSI 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)가
 클러스터에 설치되어 있어야 한다.
-`CSIMigrationOpenStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-`false` 로 설정하여 클러스터에 대한 Cinder CSI 마이그레이션을 비활성화할 수 있다.
-`CSIMigrationOpenStack` 기능을 비활성화하면, 트리 내 Cinder 볼륨 플러그인이
-Cinder 볼륨 스토리지 관리의 모든 측면을 담당한다.
+
+컨트롤러 매니저 및 kubelet이 인-트리 Cinder 플러그인을 로드하지 않도록 하려면, 
+`InTreePluginOpenStackUnregister` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다.

 ### 컨피그맵(configMap) {#configmap}

@ -251,7 +265,7 @@ metadata:
 spec:
  containers:
    - name: test
-      image: busybox
+      image: busybox:1.28
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
@ -879,9 +893,7 @@ RBD CSI 드라이버로의 마이그레이션을 시도하기 전에
 * 또한, 트리 내(in-tree) 스토리지클래스의 
  `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 
  `adminSecretName` 값이 `adminId` 파라미터 값의 
-  base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다.
-
-{{< /note >}}
+  base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. {{< /note >}}

 ### secret

@ -957,66 +969,15 @@ spec:
 StorageOS, 동적 프로비저닝과 퍼시스턴트 볼륨 클래임에 대한 더 자세한 정보는
 [StorageOS 예제](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 참고한다.

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

 {{< note >}}
-쿠버네티스 vSphere 클라우드 공급자를 구성해야 한다. 클라우드공급자
-구성에 대해선 [vSphere 시작 가이드](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)를 참조한다.
+이 드라이버 대신 외부(out-of-tree) vSphere CSI 드라이버를 사용하는 것을 권장한다.
 {{< /note >}}

 `vsphereVolume` 은 vSphere VMDK 볼륨을 파드에 마운트하는데 사용된다.  볼륨을
 마운트 해제해도 볼륨의 내용이 유지된다. VMFS와 VSAM 데이터스토어를 모두 지원한다.

-{{< note >}}
-파드와 함께 사용하기 위해선 먼저 다음 방법 중 하나를 사용하여 vSphere VMDK 볼륨을 생성해야 한다.
-{{< /note >}}
-
-#### VMDK 볼륨 생성하기 {#creating-vmdk-volume}
-
-다음 중 하나를 선택해서 VMDK를 생성한다.
-
-{{< tabs name="tabs_volumes" >}}
-{{% tab name="vmkfstools를 사용해서 생성" %}}
-먼저 ESX에 ssh로 들어간 다음, 다음 명령을 사용해서 VMDK를 생성한다.
-
-```shell
-vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
-```
-
-{{% /tab %}}
-{{% tab name="vmware-vdiskmanager를 사용해서 생성" %}}
-다음 명령을 사용해서 VMDK를 생성한다.
-
-```shell
-vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
-```
-
-{{% /tab %}}
-
-{{< /tabs >}}
-
-#### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration}
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: test-vmdk
-spec:
-  containers:
-  - image: k8s.gcr.io/test-webserver
-    name: test-container
-    volumeMounts:
-    - mountPath: /test-vmdk
-      name: test-volume
-  volumes:
-  - name: test-volume
-    # 이 VMDK 볼륨은 이미 있어야 한다.
-    vsphereVolume:
-      volumePath: "[DatastoreName] volumes/myDisk"
-      fsType: ext4
-```
-
 더 자세한 내용은 [vSphere 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) 예제를 참고한다.

 #### vSphere CSI 마이그레이션 {#vsphere-csi-migration}
@ -1028,8 +989,15 @@ spec:
 [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가
 클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere`
 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
+마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 
+[인-트리 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션하기](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html)를 참고한다.

-또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다.
+쿠버네티스 v{{< skew currentVersion >}} 버전에서 외부(out-of-tree) CSI 드라이버로 마이그레이션하려면 
+vSphere 7.0u2 이상을 사용하고 있어야 한다. 
+v{{< skew currentVersion >}} 외의 쿠버네티스 버전을 사용 중인 경우, 
+해당 쿠버네티스 버전의 문서를 참고한다. 
+쿠버네티스 v{{< skew currentVersion >}} 버전과 vSphere 이전 버전을 사용 중이라면, 
+vSphere 버전을 7.0u2 이상으로 업그레이드하는 것을 추천한다.

 {{< note >}}
 빌트인 `vsphereVolume` 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다.
@ -1130,7 +1098,7 @@ spec:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
-    image: busybox
+    image: busybox:1.28
    command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
    volumeMounts:
    - name: workdir1
@ -1199,7 +1167,6 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면

 * [퍼시스턴트볼륨클레임](#persistentvolumeclaim)에 대한 참조를 통해서
 * [일반 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)과 함께
-  (알파 기능)
 * 드라이버가 지원하는 경우
  [CSI 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)과 함께 (베타 기능)

--- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
@ -69,7 +69,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 # │ │ │ ┌───────────── 월 (1 - 12)
 # │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
 # │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
-# │ │ │ │ │
+# │ │ │ │ │                                   또는 sun, mon, tue, wed, thu, fri, sat
 # │ │ │ │ │
 # * * * * *
 ```
@ -91,6 +91,21 @@ kube-controller-manager 컨테이너에 설정된 시간대는

 크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.

+## 타임 존
+크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다.
+
+{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
+
+`CronJobTimeZone` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, 
+크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나, 
+타임 존에 대한 실험적 지원을 제공하지 않는 쿠버네티스 버전을 사용 중인 경우, 
+클러스터의 모든 크론잡은 타임 존이 명시되지 않은 것으로 동작한다).
+
+이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 이름으로 지정할 수 있다. 
+예를 들어, `spec.timeZone: "Etc/UTC"`와 같이 설정하면 쿠버네티스는 협정 세계시를 기준으로 스케줄을 해석한다.
+
+Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 인클루드되며, 시스템에서 외부 데이터베이스를 사용할 수 없을 때 폴백(fallback)으로 사용된다.
+
 ## 크론잡의 한계 {#cron-job-limitations}

 크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는
--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@ -76,11 +76,11 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 `.spec.selector` 필드는 파드 셀렉터이다. 이것은
 [잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다.

-쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
-파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
-셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다.
-또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다.
-파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다.
+`.spec.template`의 레이블과 매치되는 
+파드 셀렉터를 명시해야 한다.
+또한, 한 번 데몬셋이 만들어지면 
+`.spec.selector` 는 바꿀 수 없다.
+파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.

 `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.

@ -91,8 +91,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.

-만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 
-일치하지 않는 구성은 API에 의해 거부된다.
+`.spec.selector` 는 `.spec.template.metadata.labels` 와 일치해야 한다. 
+이 둘이 서로 일치하지 않는 구성은 API에 의해 거부된다.

 ### 오직 일부 노드에서만 파드 실행

@ -107,7 +107,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

 ### 기본 스케줄러로 스케줄

-{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
+{{< feature-state for_k8s_version="1.17" state="stable" >}}

 데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
 쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@ -255,10 +255,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
    또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
    기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).

-    예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음
-    이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며,
-    충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다.
-    이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다.
+    예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음, 
+    이전 파드를 삭제하고, 또 다른 새로운 파드를 만든 것을 볼 수 있다. 
+    충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. 
+    이것은 최소 3개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. 
+    디플로이먼트의 레플리카 크기가 4인 경우, 파드 숫자는 3개에서 5개 사이이다.

 * 디플로이먼트의 세부 정보 가져오기
  ```shell
@ -303,13 +304,20 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
      Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
      Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0
    ```
-    처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서
-    3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다.
-    디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로   스케일 업한 다음
-    이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다.
-    이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다.
+    처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성하고 
+    3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. 
+    디플로이먼트를 업데이트하자, 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 모두 실행될 때까지 대기하였다. 
+    그 뒤 이전 레플리카셋을 2개로 스케일 다운하고 새 레플리카셋을 2개로 스케일 업하여 모든 시점에 대해 최소 3개 / 최대 3개의 파드가 존재하도록 하였다. 
+    이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. 
    마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다.

+{{< note >}}
+쿠버네티스가 `availableReplicas` 수를 계산할 때 종료 중인(terminating) 파드는 포함하지 않으며, 
+이 수는 `replicas - maxUnavailable` 와 `replicas + maxSurge` 사이에 존재한다. 
+그 결과, 롤아웃 중에는 파드의 수가 예상보다 많을 수 있으며, 
+종료 중인 파드의 `terminationGracePeriodSeconds`가 만료될 때까지는 디플로이먼트가 소비하는 총 리소스가 `replicas + maxSurge` 이상일 수 있다.
+{{< /note >}}
+
 ### 롤오버(일명 인-플라이트 다중 업데이트)

 디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
--- a/content/ko/docs/concepts/workloads/controllers/job.md
+++ b/content/ko/docs/concepts/workloads/controllers/job.md
@ -42,7 +42,9 @@ weight: 50
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 job.batch/pi created
 ```
@ -52,7 +54,9 @@ job.batch/pi created
 ```shell
 kubectl describe jobs/pi
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 Name:           pi
 Namespace:      default
@ -97,7 +101,9 @@ Events:
 pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
 echo $pods
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 pi-5rwd7
 ```
@ -110,7 +116,9 @@ pi-5rwd7
 ```shell
 kubectl logs $pods
 ```
+
 출력 결과는 다음과 같다.
+
 ```shell
 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
 ```
@ -190,7 +198,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고

 ### 완료 모드

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

 완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
 `.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
@ -308,7 +316,7 @@ spec:

 ### 완료된 잡을 위한 TTL 메커니즘

-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}

 완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은
 잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해
@ -425,13 +433,7 @@ spec:

 ### 잡 일시 중지

-{{< feature-state for_k8s_version="v1.22" state="beta" >}}
-
-{{< note >}}
-이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며, 
-이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다. 
-[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
-{{< /note >}}
+{{< feature-state for_k8s_version="v1.24" state="stable" >}}

 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
 즉시 파드 생성을 시작하고 잡이 완료될 때까지
@ -482,7 +484,7 @@ spec:
 kubectl get jobs/myjob -o yaml
 ```

-```json
+```yaml
 apiVersion: batch/v1
 kind: Job
 # .metadata and .spec omitted
@ -581,7 +583,9 @@ Events:
 ```shell
 kubectl get job old -o yaml
 ```
+
 출력 결과는 다음과 같다.
+
 ```yaml
 kind: Job
 metadata:
@ -631,7 +635,8 @@ spec:

 이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. 
 이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다. 
-사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
+사용자가 느낄 수 있는 유일한 차이점은 
+컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
 {{< /note >}}

 이 기능이 활성화되지 않으면, 잡 
--- a/content/ko/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md
@ -223,8 +223,6 @@ pod2             1/1     Running   0          36s

 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
 레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
-쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
-API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.

 레플리카셋 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
--- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
@ -185,8 +185,8 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용
 Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를
 삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다.

-REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
-레플리케이션 컨트롤러를 삭제).
+REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 
+명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, 레플리케이션 컨트롤러를 삭제).

 ### 레플리케이션 컨트롤러만 삭제

@ -194,7 +194,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적

 kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라.

-REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
+REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.

 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@ -115,7 +115,7 @@ spec:

 ### 파드 셀렉터

-스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
+스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.

 ### 볼륨 클레임 템플릿

@ -226,8 +226,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 되기 전까지 종료되지 않는다.

 ### 파드 관리 정책
-쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를
-통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
+스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해 
+고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.

 #### OrderedReady 파드 관리

@ -266,7 +266,9 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 각 파드의 업데이트는 한 번에 하나씩 한다.

 쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
-`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
+`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 
+설정한 경우, 
+컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.

 ### 파티션 롤링 업데이트 {#partitions}

@ -280,6 +282,27 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.

+### 최대 사용 불가능(unavailable) 파드 수
+
+{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
+
+`.spec.updateStrategy.rollingUpdate.maxUnavailable` 필드를 명시하여, 
+업데이트 과정에서 사용 불가능(unavailable) 파드를 최대 몇 개까지 허용할 것인지를 조절할 수 있다. 
+값은 절대값(예: `5`) 또는 목표 파드 퍼센티지(예: `10%`)로 명시할 수 있다. 
+절대값은 퍼센티지 값으로 계산한 뒤 올림하여 얻는다. 
+이 필드는 0일 수 없다. 기본값은 1이다.
+
+이 필드는 `0` 에서 `replicas - 1` 사이 범위에 있는 모든 파드에 적용된다. 
+이 범위 내에 사용 불가능한 파드가 있으면, 
+`maxUnavailable`로 집계된다.
+
+{{< note >}}
+`maxUnavailable` 필드는 현재 알파 단계이며 
+`MaxUnavailableStatefulSet` 
+[기능 게이트](/ko/docs/reference/commmand-line-tools-reference/feature-gates/)가 활성화된 API 서버에서만 
+동작한다.
+{{< /note >}}
+
 ### 강제 롤백

 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@ -180,7 +180,7 @@ spec:
    spec:
      containers:
      - name: hello
-        image: busybox
+        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # 여기까지 파드 템플릿이다
@ -251,20 +251,19 @@ spec:

 ### 파드 네트워킹

-각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의
-모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를
-공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한
-컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가
-*파드 외부의* 엔티티와 통신할 때,
-공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
-파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
-`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는
-POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로
-통신할 수도 있다. 다른 파드의 컨테이너는
-고유한 IP 주소를 가지며
-[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다.
-다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을
-사용하여 통신할 수 있다.
+각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 
+파드의 모든 컨테이너는 네트워크 네임스페이스를 공유하며, 
+여기에는 IP 주소와 네트워크 포트가 포함된다. 
+파드 내부(이 경우에 **만** 해당)에서, 파드에 속한 컨테이너는 
+`localhost` 를 사용하여 서로 통신할 수 있다. 
+파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때, 
+공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. 
+파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, 
+`localhost` 를 통해 서로를 찾을 수 있다. 
+파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은 
+표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다. 
+다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 OS 수준의 IPC로 통신할 수 없다. 
+다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다.

 파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된
 `name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한
--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@ -136,8 +136,8 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
 쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과
 종료 시간이 표시된다.

-컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에
-실행된다.
+컨테이너에 구성된 `preStop` 훅이 있는 경우, 
+이 혹은 컨테이너가 `Terminated` 상태에 들어가기 전에 실행된다.

 ## 컨테이너 재시작 정책 {#restart-policy}

--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@ -4,21 +4,11 @@ content_type: concept
 weight: 40
 ---

-{{< feature-state for_k8s_version="v1.19" state="stable" >}}
-<!-- leave this shortcode in place until the note about EvenPodsSpread is
-obsolete -->

 <!-- overview -->

 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.

-{{< note >}}
-v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
-[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
-[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
-`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다
-{{< /note >}}

 <!-- body -->

@ -83,16 +73,42 @@ spec:

 - **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
  이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
+
  - `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
    대상 토폴로지에서 일치하는 파드 수와 전역 최솟값
-    (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 전역 최솟값은 0) 
+    (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 
+    예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 
+    전역 최솟값은 0) 
    사이에 허용되는 최대 차이이다.
  - `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
    왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
+
+- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다. 
+  도메인은 토폴로지의 특정 인스턴스 중 하나이다. 
+  도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다.
+
+  - `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
+  - 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면, 
+    파드 토폴로지 스프레드는 "글로벌 미니멈"을 0으로 간주한 뒤, `skew` 계산이 수행된다. 
+    "글로벌 미니멈"은 적합한 도메인 내에 매치되는 파드의 최소 수 이며, 
+    적합한 도메인 수가 `minDomains`보다 적은 경우에는 0이다.
+  - 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면, 
+    이 값은 스케줄링에 영향을 미치지 않는다.
+  - `minDomains`가 nil이면, 이 제약은 `minDomains`가 1인 것처럼 동작한다.
+  - `minDomains`가 nil이 아니면, `whenUnsatisfiable`의 값은 "`DoNotSchedule`"이어야 한다.
+
+  {{< note >}}
+  `minDomains` 필드는 1.24에서 추가된 알파 필드이다. 
+  이를 사용하려면 `MinDomainsInPodToplogySpread` 
+  [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+  {{< /note >}}
+
 - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
+
 - **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
  - `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
  - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
+
 - **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.

 파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
@ -306,11 +322,12 @@ class zoneC cluster;
 예시 구성은 다음과 같다.

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration

 profiles:
-  - pluginConfig:
+  - schedulerName: default-scheduler
+    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
@ -321,21 +338,17 @@ profiles:
 ```

 {{< note >}}
-기본 스케줄링 제약 조건에 의해 생성된 점수는
-[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에
-의해 생성된 점수와 충돌 할 수 있다.
-`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
-이 플러그인을 비활성화 하는 것을 권장한다.
+[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은 
+기본적으로 비활성화되어 있다. 
+비슷한 효과를 얻기 위해 `PodTopologySpread`를 사용하는 것을 추천한다.
 {{< /note >}}

-#### 내부 기본 제약
+#### 내장 기본 제약 {#internal-default-constraints}

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

-기본적으로 활성화된 `DefaultPodTopologySpread` 기능 게이트를 사용하면, 기존
-`SelectorSpread` 플러그인이 비활성화된다.
-kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
-기본 토폴로지 제약 조건을 사용한다.
+파드 토폴로지 스프레딩에 대해 클러스터 수준의 기본 제약을 설정하지 않으면, 
+kube-scheduler는 다음과 같은 기본 토폴로지 제약을 설정한 것처럼 동작한다.

 ```yaml
 defaultConstraints:
@ -347,8 +360,8 @@ defaultConstraints:
    whenUnsatisfiable: ScheduleAnyway
 ```

-또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인이
-비활성화된다.
+또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인은
+기본적으로 비활성화되어 있다.

 {{< note >}}
 `PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
@ -366,11 +379,12 @@ defaultConstraints:
 `defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration

 profiles:
-  - pluginConfig:
+  - schedulerName: default-scheduler
+    pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints: []
--- a/content/ko/docs/contribute/_index.md
+++ b/content/ko/docs/contribute/_index.md
@ -95,9 +95,9 @@ class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
 class S,T,U spacewhite
 class first,second,third white
 {{</ mermaid >}}
-***그림 - 신규 기여자를 위한 시작 가이드***
+그림 1. 신규 기여자를 위한 시작 가이드.

-위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!
+그림 1은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!

 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
 역할과 권한에 대한 자세한 내용은
@ -105,7 +105,7 @@ class first,second,third white

 ## 첫 번째 기여

-몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.
+몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 그림 2는 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.

 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
@ -136,7 +136,7 @@ class A,B,D,E,F,G grey
 class S,T spacewhite
 class first,second white
 {{</ mermaid >}}
-***그림 - 첫 기여를 위한 준비***
+그림 2. 첫 기여를 위한 준비.

 - [기여 개요](/ko/docs/contribute/new-content/)를 읽고
  기여할 수 있는 다양한 방법에 대해 알아봅니다.
--- a/content/ko/docs/contribute/advanced.md
+++ b/content/ko/docs/contribute/advanced.md
@ -86,6 +86,7 @@ SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/
 - 문서 리포지터리에 대한 처음 몇 번의 PR을 통해 새로운 기여자를 멘토링한다.
 - 새로운 기여자가 쿠버네티스 멤버가 되기 위해 필요한 보다 복잡한 PR을 작성하도록 지원한다.
 - 쿠버네티스 멤버 가입을 위해 [기여자를 후원](/ko/docs/contribute/advanced/#새로운-기여자-후원)한다.
+- 월간 미팅을 개최하여 새로운 기여자에게 도움을 주고 조언을 해 준다.

 현재 새로운 기여자 홍보대사는 각 SIG-Docs 회의와 [쿠버네티스 #sig-docs 채널](https://kubernetes.slack.com)에서 발표된다.

--- a/content/ko/docs/contribute/participate/pr-wranglers.md
+++ b/content/ko/docs/contribute/participate/pr-wranglers.md
@ -48,8 +48,7 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
  CLA에 서명한 후 PR을 열 수 있음을 알린다.
  **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
 - [LGTM 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
-  멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을
-  지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
+  멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
 - [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
  병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다.
 - [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
@ -88,3 +87,17 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
 [`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.

 {{< /note >}}
+
+## PR 랭글러 섀도우 프로그램
+
+2021년 말에, SIG Docs는 PR 랭글러 섀도우 프로그램을 도입했다. 이 프로그램은 새로운 기여자가 PR 랭글링 과정을 이해하는 데 도움을 주기 위해 도입되었다.
+
+### 섀도우 되기
+
+- PR 랭글러 섀도우 활동에 관심이 있다면, [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)에서 올해의 PR 랭글링 스케줄을 확인하고 지원한다.
+
+- 쿠버네티스 org 멤버는 [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수정하여 기존 PR 랭글러를 1주일 간 섀도잉할 수 있다.
+
+- 쿠버네티스 org 비 멤버는 [#sig-docs 슬랙 채널](https://kubernetes.slack.com/messages/sig-docs)에서 특정 주간에 대해 기존 PR 랭글러에 대한 섀도잉을 요청할 수 있다. Brad Topol (`@bradtopol`) 또는 [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) 중 한 명에게 연락하면 된다.
+
+- PR 랭글러 섀도워로 지원했다면, [쿠버네티스 슬랙](https://slack.k8s.io)에서 PR 랭글러에게 자신을 소개한다.
--- a/content/ko/docs/contribute/review/reviewing-prs.md
+++ b/content/ko/docs/contribute/review/reviewing-prs.md
@ -36,7 +36,7 @@ weight: 10

 ## 리뷰 과정

-일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.
+일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.

 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
@ -67,7 +67,7 @@ class S,T spacewhite
 class third,fourth white
 {{</ mermaid >}}

-***그림 - 리뷰 과정 절차***
+그림 1. 리뷰 과정 절차.

 1.  [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로
    이동한다.
--- a/content/ko/docs/home/_index.md
+++ b/content/ko/docs/home/_index.md
@ -60,7 +60,7 @@ cards:
  title: K8s 릴리스 노트
  description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다.
  button: "쿠버네티스 다운로드"
-  button_path: "/docs/setup/release/notes"
+  button_path: "/releases/download"
 - name: about
  title: 문서에 대하여
  description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다.
--- a/content/ko/docs/reference/_index.md
+++ b/content/ko/docs/reference/_index.md
@ -43,7 +43,7 @@ no_list: true

 ## CLI

-* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
+* [kubectl](/ko/docs/reference/kubectl/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
    * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
 * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.

@ -66,6 +66,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로

 * 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는
  [포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트
+
 ## API 설정

 이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
@ -73,10 +74,12 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
 제공하지 않는다.

-
+* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
 * [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/)
+* [kube-apiserver 암호화 (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
 * [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및
  [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
+* [kubelet 크리덴셜 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)
 * [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및
  [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)