From bd70b604e2cd4244f98e7deb34f176673a2e4dc0 Mon Sep 17 00:00:00 2001
From: Jihoon Seo <jihoon.seo@etri.re.kr>
Date: Fri, 10 Dec 2021 18:53:19 +0900
Subject: [PATCH] [ko] Update outdated files in dev-1.22-ko.4 M27-33

---
 .../workloads/controllers/cron-jobs.md        | 35 +++++++++-------
 .../workloads/controllers/deployment.md       | 39 ++++++++++++------
 .../concepts/workloads/controllers/job.md     | 25 +++++++++++-
 .../workloads/controllers/statefulset.md      | 40 +++++++++++++------
 .../concepts/workloads/pods/disruptions.md    |  4 +-
 .../concepts/workloads/pods/pod-lifecycle.md  |  2 +-
 .../pods/pod-topology-spread-constraints.md   | 10 +++--
 7 files changed, 108 insertions(+), 47 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..fed16fb6ed 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/)와 같은 웹 도구를 사용할 수도 있다.
 
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..489f1603d4 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 >}}
+
+
 ## 잡 패턴
 
 잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다.  잡 오브젝트는 과학
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
index e09a08ab47..5fb9ba547e 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
@@ -166,9 +173,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` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
 참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
@@ -285,19 +290,29 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 `.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 
 컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
-기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
-파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
-[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
+기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다). 파드가 준비가 되는 시기에 대해 
+더 자세히 알아보고 싶다면, [컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
 
 이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
 
+### 레플리카
+
+`.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 +324,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/)과
   이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.
diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md
index 4a5452a826..ad099f96c7 100644
--- a/content/ko/docs/concepts/workloads/pods/disruptions.md
+++ b/content/ko/docs/concepts/workloads/pods/disruptions.md
@@ -128,8 +128,8 @@ Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적
 기반으로 계산한다. 컨트롤 플레인은 파드의 `.metadata.ownerReferences` 를 검사하여
 소유하는 워크로드 리소스를 발견한다.
 
-PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만,
-버짓이 차감된다.
+[비자발적 중단](#자발적-중단과-비자발적-중단)은 PDB로는 막을 수 없지만, 
+버짓은 차감된다.
 
 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
 그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는
diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
index 54af7521d5..5fe7755030 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -159,7 +159,7 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한
 * `PodScheduled`: 파드가 노드에 스케줄되었다.
 * `ContainersReady`: 파드의 모든 컨테이너가 준비되었다.
 * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가
-  성공적으로 시작되었다.
+  성공적으로 완료(completed)되었다.
 * `Ready`: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드
   밸런싱 풀에 추가되어야 한다.
 
diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 865a7cd7c2..f7593c48dd 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -234,6 +234,8 @@ graph BT
 
 스케줄러는 신규 파드에 `spec.nodeSelector` 또는 `spec.affinity.nodeAffinity`가 정의되어 있는 경우, 부합하지 않는 노드들을 차이(skew) 계산에서 생략한다.
 
+### 예시: TopologySpreadConstraints와 노드 어피니티
+
 zoneA 에서 zoneC에 걸쳐있고, 5개의 노드를 가지는 클러스터가 있다고 가정한다.
 
 {{<mermaid>}}
@@ -349,12 +351,14 @@ defaultConstraints:
 비활성화된다.
 
 {{< note >}}
+`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
+없는 노드에 점수를 매기지 않는다. 
+이로 인해 기본 토폴로지 제약을 사용하는 경우의 
+레거시 `SelectorSpread` 플러그인과는 기본 정책이 다를 수 있다.
+
 노드에 `kubernetes.io/hostname` 및 `topology.kubernetes.io/zone`
 레이블 세트 **둘 다**가 설정되지 않을 것으로 예상되는 경우, 쿠버네티스 기본값을 사용하는
 대신 자체 제약 조건을 정의한다.
-
-`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
-없는 노드에 점수를 매기지 않는다.
 {{< /note >}}
 
 클러스터에 기본 파드 분배 제약 조건을 사용하지 않으려면,