From b928e5c8de3f3fc3b668373577edc469737b8d64 Mon Sep 17 00:00:00 2001
From: Jihoon Seo <jihoon.seo@etri.re.kr>
Date: Thu, 16 Dec 2021 08:47:02 +0900
Subject: [PATCH] [ko] Update outdated files in dev-1.23-ko.1 M34-37

---
 .../workloads/controllers/cron-jobs.md        |  37 +++--
 .../workloads/controllers/deployment.md       |  39 +++--
 .../concepts/workloads/controllers/job.md     |  64 +++++++-
 .../workloads/controllers/statefulset.md      | 144 +++++++++++++++---
 4 files changed, 228 insertions(+), 56 deletions(-)

diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
index 3ae5659806..34ac547b73 100644
--- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
@@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="
 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다.
 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.
 
-추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=<time zone>"을 추가해서 타임존을 명기할 수 있으며, 항상 `CRON_TZ`를 설정하는 것을 권장한다.
-
 {{< caution >}}
 모든 **크론잡** `일정:` 시간은
 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다.
@@ -28,6 +26,16 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 크론잡 컨트롤러가 사용하는 시간대로 결정한다.
 {{< /caution >}}
 
+{{< caution >}}
+[v1 CronJob API](/docs/reference/kubernetes-api/workload-resources/cron-job-v1/)은 
+위에서 설명한 타임존 설정을 공식적으로 지원하지는 않는다.
+
+`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은 쿠버네티스 프로젝트에서 공식적으로 지원하지는 않는다.
+`CRON_TZ` 또는 `TZ` 와 같은 변수를 설정하는 것은 
+크론탭을 파싱하고 다음 잡 생성 시간을 계산하는 내부 라이브러리의 구현 상세사항이다.
+프로덕션 클러스터에서는 사용을 권장하지 않는다.
+{{< /caution >}}
+
 크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이
 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
@@ -55,16 +63,15 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 ### 크론 스케줄 문법
 
 ```
-#      ┌────────────────── 타임존 (옵션)
-#      |      ┌───────────── 분 (0 - 59)
-#      |      │ ┌───────────── 시 (0 - 23)
-#      |      │ │ ┌───────────── 일 (1 - 31)
-#      |      │ │ │ ┌───────────── 월 (1 - 12)
-#      |      │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
-#      |      │ │ │ │ │                           특정 시스템에서는 7도 일요일)
-#      |      │ │ │ │ │
-#      |      │ │ │ │ │
-# CRON_TZ=UTC * * * * *
+# ┌───────────── 분 (0 - 59)
+# │ ┌───────────── 시 (0 - 23)
+# │ │ ┌───────────── 일 (1 - 31)
+# │ │ │ ┌───────────── 월 (1 - 12)
+# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
+# │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
+# │ │ │ │ │
+# │ │ │ │ │
+# * * * * *
 ```
 
 
@@ -78,9 +85,9 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 
 
 
-예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
+예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
 
-`CRON_TZ=UTC 0 0 13 * 5`
+`0 0 13 * 5`
 
 크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
 
@@ -144,6 +151,8 @@ Cannot determine if job needs to be started. Too many missed start time (> 100).
 * 크론잡을 생성하고 다루기 위한 지침 및
   크론잡 매니페스트의 예제로
   [크론잡으로 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)를 읽는다.
+* 실패했거나 완료된 잡을 자동으로 정리하도록 하려면, 
+  [완료된 잡을 자동으로 정리](/ko/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)를 확인한다.
 * `CronJob`은 쿠버네티스 REST API의 일부이다.
   {{< api-reference page="workload-resources/cron-job-v1" >}}
   오브젝트 정의를 읽고 쿠버네티스 크론잡 API에 대해 이해한다.
diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md
index ed9eaa8cbb..e9725d2eea 100644
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@@ -32,7 +32,7 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
 * 디플로이먼트의 PodTemplateSpec을 업데이트해서 [파드의 새로운 상태를 선언한다](#디플로이먼트-업데이트). 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로운 레플리카셋으로 속도를 제어하며 이동하는 것을 관리한다. 각각의 새로운 레플리카셋은 디플로이먼트의 수정 버전에 따라 업데이트한다.
 * 만약 디플로이먼트의 현재 상태가 안정적이지 않은 경우 [디플로이먼트의 이전 버전으로 롤백](#디플로이먼트-롤백)한다. 각 롤백은 디플로이먼트의 수정 버전에 따라 업데이트한다.
 * [더 많은 로드를 위해 디플로이먼트의 스케일 업](#디플로이먼트-스케일링).
-* [디플로이먼트 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 새로운 롤아웃의 시작을 재개한다.
+* [디플로이먼트 롤아웃 일시 중지](#디플로이먼트의-일시-중지와-재개)로 PodTemplateSpec에 여러 수정 사항을 적용하고, 재개하여 새로운 롤아웃을 시작한다.
 * 롤아웃이 막혀있는지를 나타내는 [디플로이먼트 상태를 이용](#디플로이먼트-상태).
 * 더 이상 필요 없는 [이전 레플리카셋 정리](#정책-초기화).
 
@@ -697,12 +697,16 @@ nginx-deployment-1989198191   7         7         0         7m
 nginx-deployment-618515232    11        11        11        7m
 ```
 
-## 디플로이먼트의 일시 중지와 재개
+## 디플로이먼트 롤아웃 일시 중지와 재개 {#pausing-and-resuming-a-deployment}
 
-하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다.
-이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
+디플로이먼트를 업데이트할 때 (또는 계획할 때), 
+하나 이상의 업데이트를 트리거하기 전에 해당 디플로이먼트에 대한 롤아웃을 일시 중지할 수 있다. 
+변경 사항을 적용할 준비가 되면, 디플로이먼트 롤아웃을 재개한다. 
+이러한 방법으로, 불필요한 롤아웃을 트리거하지 않고 
+롤아웃 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
 
 * 예를 들어, 생성된 디플로이먼트의 경우
+
   디플로이먼트 상세 정보를 가져온다.
   ```shell
   kubectl get deploy
@@ -753,7 +757,7 @@ nginx-deployment-618515232    11        11        11        7m
     REVISION  CHANGE-CAUSE
     1   <none>
     ```
-* 롤아웃 상태를 가져와서 디플로이먼트 업데이트가 성공적인지 확인한다.
+* 기존 레플리카셋이 변경되지 않았는지 확인하기 위해 롤아웃 상태를 출력한다.
     ```shell
     kubectl get rs
     ```
@@ -774,10 +778,10 @@ nginx-deployment-618515232    11        11        11        7m
     deployment.apps/nginx-deployment resource requirements updated
     ```
 
-    디플로이먼트를 일시 중지하기 전의 초기 상태는 해당 기능을 지속한다.
-    그러나 디플로이먼트가 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.
+    디플로이먼트 롤아웃을 일시 중지하기 전 디플로이먼트의 초기 상태는 해당 기능을 지속한다.
+    그러나 디플로이먼트 롤아웃이 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다.
 
-* 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
+* 결국, 디플로이먼트 롤아웃을 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
     ```shell
     kubectl rollout resume deployment/nginx-deployment
     ```
@@ -911,8 +915,8 @@ deployment.apps/nginx-deployment patched
 {{< /note >}}
 
 {{< note >}}
-만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
-롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
+만약 디플로이먼트 롤아웃을 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다.
+롤아웃 중에 디플로이먼트 롤아웃을 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고
 재개할 수 있다.
 {{< /note >}}
 
@@ -1052,8 +1056,7 @@ echo $?
 
 `.spec.template` 과 `.spec.selector` 은 `.spec` 에서 유일한 필수 필드이다.
 
-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
-이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
 
 파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다.
 레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야 한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
@@ -1065,6 +1068,18 @@ echo $?
 
 `.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 이것의 기본값은 1이다.
 
+예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로 
+디플로이먼트의 크기를 수동으로 조정한 뒤, 
+매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행), 
+수동으로 설정했던 디플로이먼트의 크기가 오버라이드된다.
+
+[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가 
+디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
+
+대신, 쿠버네티스 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 
+`.spec.replicas` 필드를 자동으로 관리한다.
+
 ### 셀렉터
 
 `.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를
diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md
index 5f52096b3f..b71a4b5934 100644
--- a/content/ko/docs/concepts/workloads/controllers/job.md
+++ b/content/ko/docs/concepts/workloads/controllers/job.md
@@ -25,7 +25,8 @@ weight: 50
 
 잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
 
-잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
+잡을 스케줄에 따라 구동하고 싶은 경우(단일 작업이든, 여러 작업의 병렬 수행이든), 
+[크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다.
 
 <!-- body -->
 
@@ -206,6 +207,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
     있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 
     호스트네임을 사용할 수 있다.
   - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
+
   각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
   간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
   [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@@ -249,7 +251,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
 
 {{< note >}}
 만약 잡에 `restartPolicy = "OnFailure"` 가 있는 경우 잡 백오프 한계에
-도달하면 잡을 실행 중인 컨테이너가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
+도달하면 잡을 실행 중인 파드가 종료된다. 이로 인해 잡 실행 파일의 디버깅이
 더 어려워질 수 있다. 디버깅하거나 로깅 시스템을 사용해서 실패한 작업의 결과를 실수로 손실되지 않도록
 하려면 `restartPolicy = "Never"` 로 설정하는 것을 권장한다.
 {{< /note >}}
@@ -344,6 +346,25 @@ spec:
 삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
 후에 TTL 컨트롤러에 의해 정리되지 않는다.
 
+{{< note >}}
+`ttlSecondsAfterFinished` 필드를 설정하는 것을 권장하는데, 
+이는 관리되지 않는 잡(직접 생성한, 
+크론잡 등 다른 워크로드 API를 통해 간접적으로 생성하지 않은 잡)의 
+기본 삭제 정책이 `orphanDependents`(관리되지 않는 잡이 완전히 삭제되어도 
+해당 잡에 의해 생성된 파드를 남겨둠)이기 때문이다.
+삭제된 잡의 파드가 실패하거나 완료된 뒤 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 언젠가 
+[가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)을 한다고 해도, 
+이렇게 남아 있는 파드는 클러스터의 성능을 저하시키거나 
+최악의 경우에는 이 성능 저하로 인해 클러스터가 중단될 수도 있다.
+
+[리밋 레인지(Limit Range)](/ko/docs/concepts/policy/limit-range/)와 
+[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용하여 
+특정 네임스페이스가 사용할 수 있는 자원량을 제한할 수 
+있다.
+{{< /note >}}
+
+
 ## 잡 패턴
 
 잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다.  잡 오브젝트는 과학
@@ -415,8 +436,11 @@ spec:
 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
 즉시 파드 생성을 시작하고 잡이 완료될 때까지
 계속한다. 그러나, 잡의 실행을 일시적으로 중단하고 나중에
-다시 시작할 수도 있다. 잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
-업데이트할 수 있다. 나중에, 다시 재개하려면, false로 업데이트한다.
+재개하거나, 잡을 중단 상태로 생성하고 언제 시작할지를 
+커스텀 컨트롤러가 나중에 결정하도록 하고 싶을 수도 있다. 
+
+잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로
+업데이트할 수 있다. 이후에, 다시 재개하려면, false로 업데이트한다.
 `.spec.suspend` 로 설정된 잡을 생성하면 일시 중지된 상태로
 생성된다.
 
@@ -501,6 +525,32 @@ Events:
 파드가 생성되지 않았지만, 잡이 재개되자마자 파드 생성이 다시
 시작되었음을 알 수 있다.
 
+### 가변적 스케줄링 지시
+
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
+
+{{< note >}}
+이 기능을 사용하려면, 
+[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)에 
+`JobMutableNodeSchedulingDirectives` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+이 기능은 기본적으로 활성화되어 있다.
+{{< /note >}}
+
+병렬 잡에서 대부분의 경우 파드를 특정 제약 조건 하에서 실행하고 싶을 것이다. 
+(예를 들면 동일 존에서 실행하거나, 또는 GPU 모델 x 또는 y를 사용하지만 둘을 혼합하지는 않는 등)
+
+[suspend](#suspending-a-job) 필드는 이러한 목적을 달성하기 위한 첫 번째 단계이다. 
+이 필드를 사용하면 커스텀 큐(queue) 컨트롤러가 잡이 언제 시작될지를 결정할 수 있다. 
+그러나, 잡이 재개된 이후에는, 커스텀 큐 컨트롤러는 잡의 파드가 실제로 어디에 할당되는지에 대해서는 영향을 주지 않는다.
+
+이 기능을 이용하여 잡이 실행되기 전에 잡의 스케줄링 지시를 업데이트할 수 있으며, 
+이를 통해 커스텀 큐 컨트롤러가 파드 배치에 영향을 줌과 동시에 
+노드로의 파드 실제 할당 작업을 kube-scheduler로부터 경감시켜 줄 수 있도록 한다. 
+이는 이전에 재개된 적이 없는 중지된 잡에 대해서만 허용된다.
+
+잡의 파드 템플릿 필드 중, 노드 어피니티(node affinity), 노드 셀렉터(node selector), 
+톨러레이션(toleration), 레이블(label), 어노테이션(annotation)은 업데이트가 가능하다.
+
 ### 자신의 파드 셀렉터를 지정하기
 
 일반적으로 잡 오브젝트를 생성할 때 `.spec.selector` 를 지정하지 않는다.
@@ -570,17 +620,17 @@ spec:
 
 ### 종료자(finalizers)를 이용한 잡 추적
 
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 
 {{< 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 >}}
 
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
index e09a08ab47..96fec58a48 100644
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -1,4 +1,11 @@
 ---
+
+
+
+
+
+
+
 title: 스테이트풀셋
 content_type: concept
 weight: 30
@@ -67,13 +74,14 @@ metadata:
 spec:
   selector:
     matchLabels:
-      app: nginx # has to match .spec.template.metadata.labels
+      app: nginx # .spec.template.metadata.labels 와 일치해야 한다
   serviceName: "nginx"
-  replicas: 3 # by default is 1
+  replicas: 3 # 기본값은 1
+  minReadySeconds: 10 # 기본값은 0
   template:
     metadata:
       labels:
-        app: nginx # has to match .spec.selector.matchLabels
+        app: nginx # .spec.selector.matchLabels 와 일치해야 한다
     spec:
       terminationGracePeriodSeconds: 10
       containers:
@@ -105,9 +113,24 @@ spec:
 스테이트풀셋 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
-## 파드 셀렉터
+### 파드 셀렉터
 
-스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
+스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
+
+### 볼륨 클레임 템플릿
+
+`.spec.volumeClaimTemplates` 를 설정하여, 퍼시스턴트볼륨 프로비저너에 의해 프로비전된 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 이용하는 안정적인 스토리지를 제공할 수 있다.
+
+
+### 최소 준비 시간 초 {#minimum-ready-seconds}
+
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
+
+`.spec.minReadySeconds` 는 파드가 '사용 가능(available)'이라고 간주될 수 있도록 파드의 모든 컨테이너가 
+문제 없이 실행되어야 하는 최소 시간(초)을 나타내는 선택적인 필드이다. 이 기능은 베타이며 기본적으로 활성화되어 
+있음에 유의한다. 이 기능을 사용하지 않으려면 StatefulSetMinReadySeconds 플래그를 설정 해제한다. 
+이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.) 
+파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
 
 ## 파드 신원
 
@@ -166,9 +189,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 
 ### 안정된 스토리지
 
-쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을
-생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
-1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
+쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
 명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
 참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
@@ -279,25 +300,103 @@ 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)를 참고한다.
+{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
 
-이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
+선택적 필드인 `.spec.persistentVolumeClaimRetentionPolicy` 는 
+스테이트풀셋의 생애주기동안 PVC를 삭제할 것인지, 
+삭제한다면 어떻게 삭제하는지를 관리한다. 
+이 필드를 사용하려면 `StatefulSetAutoDeletePVC` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 
+활성화 시, 각 스테이트풀셋에 대해 두 가지 정책을 설정할 수 있다.
+
+`whenDeleted`
+: 스테이트풀셋이 삭제될 때 적용될 볼륨 유보 동작을 설정한다.
+
+`whenScaled`
+: 스테이트풀셋의 레플리카 수가 줄어들 때, 예를 들면 스테이트풀셋을 스케일 다운할 때 
+  적용될 볼륨 유보 동작을 설정한다.
+
+설정 가능한 각 정책에 대해, 그 값을 `Delete` 또는 `Retain` 으로 설정할 수 있다.
+
+`Delete`
+: `volumeClaimTemplate` 스테이트풀셋으로부터 생성된 PVC는 정책에 영향을 받는 각 파드에 대해 삭제된다. 
+`whenDeleted` 가 이 값으로 설정되어 있으면 
+`volumeClaimTemplate` 으로부터 생성된 모든 PVC는 파드가 삭제된 뒤에 삭제된다. 
+`whenScaled` 가 이 값으로 설정되어 있으면 
+스케일 다운된 파드 레플리카가 삭제된 뒤, 삭제된 파드에 해당되는 PVC만 삭제된다.
+
+`Retain` (기본값)
+: 파드가 삭제되어도 `volumeClaimTemplate` 으로부터 생성된 PVC는 영향을 받지 않는다. 
+  이는 이 신기능이 도입되기 전의 기본 동작이다.
+
+이러한 정책은 파드의 삭제가 스테이트풀셋 삭제 또는 스케일 다운으로 인한 것일 때**에만** 적용됨에 유의한다. 
+예를 들어, 스테이트풀셋의 파드가 노드 실패로 인해 실패했고, 
+컨트롤 플레인이 대체 파드를 생성했다면, 스테이트풀셋은 기존 PVC를 유지한다. 
+기존 볼륨은 영향을 받지 않으며, 
+새 파드가 실행될 노드에 클러스터가 볼륨을 연결(attach)한다.
+  
+정책의 기본값은 `Retain` 이며, 이는 이 신기능이 도입되기 전의 스테이트풀셋 기본 동작이다.
+
+다음은 정책 예시이다.
+
+```yaml
+apiVersion: apps/v1
+kind: StatefulSet
+...
+spec:
+  persistentVolumeClaimRetentionPolicy:
+    whenDeleted: Retain
+    whenScaled: Delete
+...
+```
+
+스테이트풀셋 {{<glossary_tooltip text="컨트롤러" term_id="controller">}}는 자신이 소유한 PVC에 
+[소유자 정보(reference)](/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)를 
+추가하며, 파드가 종료된 이후에는 {{<glossary_tooltip text="가비지 콜렉터" term_id="garbage-collection">}}가 이 정보를 삭제한다. 
+이로 인해 PVC가 삭제되기 전에 
+(그리고 유보 정책에 따라, 매칭되는 기반 PV와 볼륨이 삭제되기 전에) 
+파드가 모든 볼륨을 깨끗하게 언마운트할 수 있다. 
+`whenDeleted` 정책을 `Delete` 로 설정하면, 
+해당 스테이트풀셋에 연결된 모든 PVC에 스테이트풀셋 인스턴스의 소유자 정보가 기록된다.
+
+`whenScaled` 정책은 파드가 스케일 다운되었을 때에만 PVC를 삭제하며, 
+파드가 다른 원인으로 삭제되면 PVC를 삭제하지 않는다. 
+조정 상황 발생 시, 스테이트풀셋 컨트롤러는 목표 레플리카 수와 클러스터 상의 실제 파드 수를 비교한다. 
+레플리카 카운트보다 큰 ID를 갖는 스테이트풀셋 파드는 부적격 판정을 받으며 삭제 대상으로 표시된다. 
+`whenScaled` 정책이 `Delete` 이면, 부적격 파드는 삭제되기 전에, 
+연결된 스테이트풀셋 템플릿 PVC의 소유자로 지정된다. 
+이로 인해, 부적격 파드가 종료된 이후에만 PVC가 가비지 콜렉트된다.
+
+이는 곧 만약 컨트롤러가 강제 종료되어 재시작되면, 
+파드의 소유자 정보가 정책에 적합하게 업데이트되기 전에는 어떤 파드도 삭제되지 않을 것임을 의미한다. 
+만약 컨트롤러가 다운된 동안 부적격 파드가 강제로 삭제되면, 
+컨트롤러가 강제 종료된 시점에 따라 소유자 정보가 설정되었을 수도 있고 설정되지 않았을 수도 있다. 
+소유자 정보가 업데이트되기까지 몇 번의 조정 절차가 필요할 수 있으며, 
+따라서 일부 부적격 파드는 소유자 정보 설정을 완료하고 나머지는 그러지 못했을 수 있다. 
+이러한 이유로, 컨트롤러가 다시 켜져서 파드를 종료하기 전에 
+소유자 정보를 검증할 때까지 기다리는 것을 추천한다. 
+이것이 불가능하다면, 관리자는 PVC의 소유자 정보를 확인하여 파드가 강제 삭제되었을 때 해당되는 오브젝트가 삭제되도록 해야 한다.
+
+### 레플리카
+
+`.spec.replicas` 은 필요한 파드의 수를 지정하는 선택적 필드이다. 기본값은 1이다.
+
+예를 들어 `kubectl scale deployment deployment --replicas=X` 명령으로 
+디플로이먼트의 크기를 수동으로 조정한 뒤, 
+매니페스트를 이용하여 디플로이먼트를 업데이트하면(예: `kubectl apply -f deployment.yaml` 실행), 
+수동으로 설정했던 디플로이먼트의 크기가 
+오버라이드된다.
+
+[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(또는 수평 스케일링을 위한 유사 API)가 
+디플로이먼트 크기를 관리하고 있다면, `.spec.replicas` 를 설정해서는 안 된다.
+대신, 쿠버네티스 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}이 
+`.spec.replicas` 필드를 자동으로 관리한다.
 
 ## {{% heading "whatsnext" %}}
 
-
-* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
-* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
-* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
-
 * [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
 * 스테이트풀셋을 사용하는 방법을 알아본다.
   * [스테이트풀셋 애플리케이션 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/) 예제를 따라한다.
@@ -309,7 +408,6 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
   * [스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)하는 방법을 배운다.
 * `StatefulSet`은 쿠버네티스 REST API의 상위-수준 리소스이다.
   스테이트풀셋 API에 대해 이해하기 위해 
-  {{< api-reference page="workload-resources/stateful-set-v1" >}}
-  오브젝트 정의를 읽는다.
+  {{< api-reference page="workload-resources/stateful-set-v1" >}} 오브젝트 정의를 읽는다.
 * [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
   이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.