[ko] Update outdated files in dev-1.24-ko.3 (M27-M32)

content/ko/docs/concepts/workloads/controllers/job.md

@@ -71,7 +71,7 @@ Pod Template:
            job-name=pi
   Containers:
    pi:
-    Image:      perl
+    Image:      perl:5.34.0
     Port:       <none>
     Host Port:  <none>
     Command:
@@ -125,7 +125,7 @@ spec:
         - -Mbignum=bpi
         - -wle
         - print bpi(2000)
-        image: perl
+        image: perl:5.34.0
         imagePullPolicy: Always
         name: pi
         resources: {}
@@ -356,7 +356,7 @@ spec:
     spec:
       containers:
       - name: pi
-        image: perl
+        image: perl:5.34.0
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: Never
 ```
@@ -402,7 +402,7 @@ spec:
     spec:
       containers:
       - name: pi
-        image: perl
+        image: perl:5.34.0
         command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
       restartPolicy: Never
 ```
@@ -510,8 +510,7 @@ spec:
 현재 시간으로 재설정된다. 즉, 잡이 일시 중지 및 재개되면 `.spec.activeDeadlineSeconds`
 타이머가 중지되고 재설정된다.
 
-잡을 일시 중지하면 모든 활성 파드가 삭제된다. 잡이
-일시 중지되면, SIGTERM 시그널로 [파드가 종료된다](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
+잡을 일시 중지하면, `Completed` 상태가 아닌 모든 실행중인 파드가 SIGTERM 시그널로 [종료된다](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
 파드의 정상 종료 기간이 적용되며 사용자의 파드는 이 기간 동안에
 이 시그널을 처리해야 한다. 나중에 진행 상황을 저장하거나
 변경 사항을 취소하는 작업이 포함될 수 있다. 이 방법으로 종료된 파드는
@@ -537,6 +536,20 @@ spec:
       ...
 ```
 
+명령 줄에서 잡을 패치하여 잡 일시 중지를 전환할 수 있다.
+
+활성화된 잡 일시 중지
+
+```shell
+kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":true}}'
+```
+
+일시 중지된 잡 재개
+
+```shell
+kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":false}}'
+```
+
 잡의 상태를 사용하여 잡이 일시 중지되었는지 또는 과거에 일시 중지되었는지
 확인할 수 있다.
 

content/ko/docs/concepts/workloads/controllers/replicaset.md

@@ -13,9 +13,6 @@ weight: 20
 레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다.
 이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.
 
-
-
-
 <!-- body -->
 
 ## 레플리카셋의 작동 방식
@@ -31,9 +28,9 @@ weight: 20
 레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
 이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
 
-레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에 OwnerReference이 없거나
-OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고 레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를
-가지게 될 것이다.
+레플리카셋은 셀렉터를 이용해서 필요한 새 파드를 식별한다. 만약 파드에
+OwnerReference가 없거나, OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고
+레플리카셋의 셀렉터와 일치한다면 레플리카셋이 즉각 파드를 가지게 될 것이다.
 
 ## 레플리카셋을 사용하는 시기
 
@@ -253,7 +250,9 @@ matchLabels:
 그렇지 않으면 API에 의해 거부된다.
 
 {{< note >}}
-2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은 다른 레플리카셋이 생성한 파드를 무시한다.
+2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른
+`.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은
+다른 레플리카셋이 생성한 파드를 무시한다.
 {{< /note >}}
 
 ### 레플리카
@@ -267,11 +266,14 @@ matchLabels:
 
 ### 레플리카셋과 해당 파드 삭제
 
-레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/architecture/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
+레플리카셋 및 모든 파드를 삭제하려면
+[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다.
+[가비지 수집기](/ko/docs/concepts/architecture/garbage-collection/)는
+기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.
+
+REST API 또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를
+`Background`또는 `Foreground`로 설정해야 한다. 예시:
 
-REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
-설정해야 한다.
-예시:
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@@ -281,9 +283,12 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 
 ### 레플리카셋만 삭제하기
 
-레플리카셋을 `--cascade=orphan` 옵션과 함께 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용하면 연관 파드에 영향을 주지 않고 삭제할 수 있다.
+[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에
+`--cascade=orphan` 옵션을 사용하여
+연관 파드에 영향을 주지 않고 레플리카셋을 삭제할 수 있다.
 REST API 또는 `client-go` 라이브러리를 이용할 때는 `propagationPolicy`에 `Orphan`을 설정해야 한다.
 예시:
+
 ```shell
 kubectl proxy --port=8080
 curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
@@ -294,7 +299,8 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
 기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다.
 하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
-컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다.
+컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는
+[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다.
 이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.
 
 ### 레플리카셋에서 파드 격리
@@ -310,17 +316,19 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 
 스케일 다운할 때, 레플리카셋 컨트롤러는 스케일 다운할 파드의 
 우선순위를 정하기 위해 다음의 기준으로 가용 파드를 정렬하여 삭제할 파드를 결정한다.
+
  1. Pending 상태인 (+ 스케줄링할 수 없는) 파드가 먼저 스케일 다운된다.
- 2. `controller.kubernetes.io/pod-deletion-cost` 어노테이션이 설정되어 있는 
+ 1. `controller.kubernetes.io/pod-deletion-cost` 어노테이션이 설정되어 있는 
     파드에 대해서는, 낮은 값을 갖는 파드가 먼저 스케일 다운된다.
- 3. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다.
- 4. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가 
+ 1. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다.
+ 1. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가 
     이전에 생성된 파드보다 먼저 스케일 다운된다. 
     (`LogarithmicScaleDown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면 생성 시간이 정수 로그 스케일로 버킷화된다)
     
 모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.
 
 ### 파드 삭제 비용
+
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 [`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
@@ -344,6 +352,7 @@ apiserver에서 많은 양의 파드 업데이트를 동반하기 때문이다.
 {{< /note >}}
 
 #### 사용 예시
+
 한 애플리케이션 내의 여러 파드는 각각 사용률이 다를 수 있다. 스케일 다운 시, 
 애플리케이션은 사용률이 낮은 파드를 먼저 삭제하고 싶을 수 있다. 파드를 자주 
 업데이트하는 것을 피하기 위해, 애플리케이션은 `controller.kubernetes.io/pod-deletion-cost` 값을 
@@ -387,12 +396,17 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
 
 ### 기본 파드
 
-사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는 노드의 커널 업그레이드와 같은 관리  목적의 중단 등 어떤 이유로든 종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도 레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면, 레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다. 레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 Kubelet과 같은 에이전트에게 위임한다.
+사용자가 직접 파드를 생성하는 경우와는 다르게, 레플리카셋은 노드 장애 또는
+노드의 커널 업그레이드와 같은 관리 목적의 중단 등 어떤 이유로든
+종료되거나 삭제된 파드를 교체한다. 이런 이유로 애플리케이션이 단일 파드가 필요하더라도
+레플리카셋을 이용하는 것을 권장한다. 레플리카셋을 프로세스 관리자와 비교해서 생각해본다면,
+레플리카셋은 단일 노드에서의 개별 프로세스들이 아닌 다수의 노드에 걸쳐있는 다수의 파드를 관리하는 것이다.
+레플리카셋은 로컬 컨테이너의 재시작을 노드에 있는 Kubelet과 같은 에이전트에게 위임한다.
 
 ### 잡
 
-스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신 [`잡`](/ko/docs/concepts/workloads/controllers/job/)을 이용한다
-(즉, 배치 잡).
+스스로 종료되는 것이 예상되는 파드의 경우에는 레플리카셋 대신
+[`잡`](/ko/docs/concepts/workloads/controllers/job/)을 이용한다 (즉, 배치 잡).
 
 ### 데몬셋
 
@@ -402,12 +416,12 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
 머신의 재부팅/종료가 준비되었을 때, 해당 파드를 종료하는 것이 안전하다.
 
 ### 레플리케이션 컨트롤러
-레플리카셋은 [_레플리케이션 컨트롤러_](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 계승하였다.
+
+레플리카셋은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 계승하였다.
 이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에
 설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
 따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
 
-
 ## {{% heading "whatsnext" %}}
 
 * [파드](/ko/docs/concepts/workloads/pods)에 대해 배운다.
@@ -419,3 +433,4 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
   오브젝트 정의를 읽는다.
 * [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과
   이를 사용해서 어떻게 중단 중에 애플리케이션 가용성을 관리할 수 있는지에 대해 읽는다.
+

content/ko/docs/concepts/workloads/controllers/statefulset.md

@@ -39,10 +39,18 @@ weight: 30
 
 ## 제한사항
 
-* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
-* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
-* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
-* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
+* 파드에 지정된 스토리지는 관리자에 의해
+  [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)
+  를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
+* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*.
+  이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한
+  데이터의 안전을 보장하기 위함이다.
+* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
+  가 필요하다. 사용자가 이 서비스를 생성할 책임이
+  있다.
+* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지
+  않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면,
+  삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
 * [롤링 업데이트](#롤링-업데이트)와 기본
   [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를
   함께 사용시 [복구를 위한 수동 개입](#강제-롤백)이
@@ -108,18 +116,24 @@ spec:
 
 * 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
 * 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
-* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
+* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한
+  [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서
+  안정적인 스토리지를 제공한다.
 
 스테이트풀셋 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
 ### 파드 셀렉터
 
-스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
+스테이트풀셋의 `.spec.selector` 필드는
+`.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면
+스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
 
 ### 볼륨 클레임 템플릿
 
-`.spec.volumeClaimTemplates` 를 설정하여, 퍼시스턴트볼륨 프로비저너에 의해 프로비전된 [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 이용하는 안정적인 스토리지를 제공할 수 있다.
+`.spec.volumeClaimTemplates` 를 설정하여, 퍼시스턴트볼륨 프로비저너에 의해 프로비전된
+[퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 이용하는 안정적인 스토리지를
+제공할 수 있다.
 
 
 ### 최소 준비 시간 초 {#minimum-ready-seconds}
@@ -128,9 +142,11 @@ spec:
 
 `.spec.minReadySeconds` 는 파드가 '사용 가능(available)'이라고 간주될 수 있도록 파드의 모든 컨테이너가 
 문제 없이 실행되어야 하는 최소 시간(초)을 나타내는 선택적인 필드이다. 이 기능은 베타이며 기본적으로 활성화되어 
-있음에 유의한다. 이 기능을 사용하지 않으려면 StatefulSetMinReadySeconds 플래그를 설정 해제한다. 
+있음에 유의한다. 이 기능을 사용하지 않으려면
+StatefulSetMinReadySeconds 플래그를 설정 해제한다. 
 이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.) 
-파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
+파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는
+[컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다.
 
 ## 파드 신원
 
@@ -166,8 +182,8 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 파드를 생성한 후 즉시 파드를 검색해야 하는 경우, 몇 가지 옵션이 있다.
 
 - DNS 조회에 의존하지 않고 쿠버네티스 API를 직접(예를 들어 watch 사용) 쿼리한다.
-- 쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을 편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다.
-
+- 쿠버네티스 DNS 공급자의 캐싱 시간(일반적으로 CoreDNS의 컨피그맵을
+  편집하는 것을 의미하며, 현재 30초 동안 캐시함)을 줄인다.
 
 [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
 파드의 네트워크 신원을 책임지는
@@ -189,7 +205,9 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 
 ### 안정된 스토리지
 
-쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
+스테이트풀셋에 정의된 VolumeClaimTemplate 항목마다, 각 파드는 하나의
+PersistentVolumeClaim을 받는다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와
+1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가
 명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면
 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다.
 참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은
@@ -210,7 +228,9 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 * 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다.
 * 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다.
 
-스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
+스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은
+안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은
+[스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
 
 위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가
 배포된다. web-1은 web-0이
@@ -242,6 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을
 받지 않는다.
 
+
 ## 업데이트 전략
 
 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
@@ -255,8 +276,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
 
 `RollingUpdate`(롤링 업데이트)
-: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
-구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
+: `RollingUpdate` 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
+  구현한다. 기본 업데이트 전략이다.
 
 ## 롤링 업데이트
 

content/ko/docs/concepts/workloads/pods/_index.md

@@ -320,12 +320,12 @@ _프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는
 * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
 * [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
   다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
-* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
 * [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
 * 파드는 쿠버네티스 REST API의 최상위 리소스이다.
   {{< api-reference page="workload-resources/pod-v1" >}}
   오브젝트 정의는 오브젝트를 상세히 설명한다.
 * [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](/blog/2015/06/the-distributed-system-toolkit-patterns/)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
+* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)에 대해 읽어본다.
 
 쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.
 

content/ko/docs/concepts/workloads/pods/init-containers.md

@@ -115,7 +115,7 @@ kind: Pod
 metadata:
   name: myapp-pod
   labels:
-    app: myapp
+    app.kubernetes.io/name: MyApp
 spec:
   containers:
   - name: myapp-container
@@ -159,7 +159,7 @@ kubectl describe -f myapp.yaml
 Name:          myapp-pod
 Namespace:     default
 [...]
-Labels:        app=myapp
+Labels:        app.kubernetes.io/name=MyApp
 Status:        Pending
 [...]
 Init Containers: