Ko: Second Korean l10n work for release-1.20

- Update outdated files in the dev-1.20-ko.2(p1) (#25915)
- Update outdated files in the dev-1.20-ko.2(p2) (#25916)
- Fix issue with links to already translated ko documents (#25991)
- Translate reference/glossary/dynamic-volume-provisioning.md in Korean (#26047)

Co-authored-by: seokho-son <shsongist@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: santachopa <santachopa@naver.com>

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

@@ -8,50 +8,73 @@ no_list: true
 
 {{< glossary_definition term_id="workload" length="short" >}}
 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의
-[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
-쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
+[_파드_](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다.
+쿠버네티스에서 `Pod` 는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}}
 집합을 나타낸다.
 
-파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고
-해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서
-심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
-최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다.
+쿠버네티스 파드에는 [정의된 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)이 있다.
+예를 들어, 일단 파드가 클러스터에서 실행되고 나서
+해당 파드가 동작 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에
+심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를
+최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 `Pod` 를 새로 생성해야 한다.
 
-그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다.
+그러나, 작업이 훨씬 쉽도록, 각 `Pod` 를 직접 관리할 필요는 없도록 만들었다.
 대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다.
 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이
 실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를
 구성한다.
 
-이러한 워크로드 리소스에는 다음이 포함된다.
+쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다.
 
-* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
-  (레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체);
-* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/);
-* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는
-  파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
-* 완료될 때까지 실행되는 작업에 대한
-  [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및
-  [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/)
+* [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 및 [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)
+  (레거시 리소스
+  {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체).
+  `Deployment` 는 `Deployment` 의 모든 `Pod` 가 필요 시 교체 또는 상호 교체 가능한 경우,
+  클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.
+* [`StatefulSet`](/ko/docs/concepts/workloads/controllers/statefulset/)는
+  어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가
+  데이터를 지속적으로 기록하는 경우, 사용자는 `Pod` 와
+  [`PersistentVolume`](/ko/docs/concepts/storage/persistent-volumes/)을 연계하는 `StatefulSet` 을 실행할 수 있다.
+  전체적인 회복력 향상을 위해서, `StatefulSet` 의 `Pods` 에서 동작 중인 코드는 동일한 `StatefulSet` 의
+  다른 `Pods` 로 데이터를 복제할 수 있다.
+* [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)은 노드-로컬 기능(node-local facilities)을 제공하는 `Pods` 를 정의한다.
+  이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다.
+  예를 들면, 네트워킹 지원 도구 또는
+  {{< glossary_tooltip text="add-on" term_id="addons" >}} 등이 있다.
+  `DaemonSet` 의 명세에 맞는 노드를 클러스터에 추가할 때마다,
+  컨트롤 플레인은 해당 신규 노드에 `DaemonSet` 을 위한 `Pod` 를 스케줄한다.
+* [`Job`](/ko/docs/concepts/workloads/controllers/job/) 및
+  [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)은
+  실행 완료 후 중단되는 작업을 정의한다. `CronJobs` 이 스케줄에 따라 반복되는 반면,
+  잡은 단 한 번의 작업을 나타낸다.
 
-관련성을 찾을 수 있는 두 가지 지원 개념도 있다.
-* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
-  제거된 후 클러스터에서 오브젝트를 정리한다.
-* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
-  완료된 이후 정의된 시간이 경과되면 잡을 제거한다.
+더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드
+리소스도 찾을 수 있다.
+[커스텀 리소스 데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)을 사용하면,
+쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를
+추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 `Pods` 의 그룹을 실행하되
+_모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은),
+사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다.
 
 ## {{% heading "whatsnext" %}}
 
 각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
 
-* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
+* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
 * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
   또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
-* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
+* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
+
+코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는,
+[구성](/ko/docs/concepts/configuration/)을 참고하길 바란다.
+
+다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는
+두 가지 개념이다.
+* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가
+  제거된 후 클러스터에서 오브젝트를 정리한다.
+* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는
+  잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.
 
 일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로
 사용하거나, 웹 애플리케이션의 경우에만
 [인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다.
-
-[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의
-메커니즘에 대해 알아볼 수도 있다.

content/ko/docs/concepts/workloads/controllers/cron-jobs.md

@@ -1,4 +1,8 @@
 ---
+
+
+
+
 title: 크론잡
 content_type: concept
 weight: 80
@@ -45,6 +49,36 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 ([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는
 이 예시를 더 자세히 설명한다.)
 
+### 크론 스케줄 문법
+
+```
+# ┌───────────── 분 (0 - 59)
+# │ ┌───────────── 시 (0 - 23)
+# │ │ ┌───────────── 일 (1 - 31)
+# │ │ │ ┌───────────── 월 (1 - 12)
+# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
+# │ │ │ │ │                                   특정 시스템에서는 7도 일요일)
+# │ │ │ │ │
+# │ │ │ │ │
+# * * * * *
+```
+
+
+| 항목   										 | 설명	      																								  | 상응 표현       |
+| ------------- 						| ------------- 																							|-------------  |
+| @yearly (or @annually)		| 매년 1월 1일 자정에 실행                 										   | 0 0 1 1 * 		|
+| @monthly 									| 매월 1일 자정에 실행  	                                        | 0 0 1 * * 		|
+| @weekly 									| 매주 일요일 자정에 실행							                             | 0 0 * * 0 		|
+| @daily (or @midnight)			| 매일 자정에 실행 																             	| 0 0 * * * 		|
+| @hourly 									| 매시 0분에 시작                          								       | 0 * * * * 		|
+
+
+예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다.
+
+`0 0 13 * 5`
+
+크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
+
 ## 크론잡의 한계 {#cron-job-limitations}
 
 크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는

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

@@ -1,4 +1,7 @@
 ---
+
+
+
 title: 잡
 content_type: concept
 feature:
@@ -35,6 +38,7 @@ weight: 50
 ```shell
 kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
 ```
+출력 결과는 다음과 같다.
 ```
 job.batch/pi created
 ```
@@ -44,6 +48,7 @@ job.batch/pi created
 ```shell
 kubectl describe jobs/pi
 ```
+출력 결과는 다음과 같다.
 ```
 Name:           pi
 Namespace:      default
@@ -88,6 +93,7 @@ Events:
 pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
 echo $pods
 ```
+출력 결과는 다음과 같다.
 ```
 pi-5rwd7
 ```
@@ -100,7 +106,7 @@ pi-5rwd7
 ```shell
 kubectl logs $pods
 ```
-다음과 유사하게 출력된다.
+출력 결과는 다음과 같다.
 ```shell
 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
 ```
@@ -395,10 +401,11 @@ spec:
 잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_.
 삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다.
 
-```
+```shell
 kubectl get job old -o yaml
 ```
-```
+출력 결과는 다음과 같다.
+```yaml
 kind: Job
 metadata:
   name: old
@@ -417,7 +424,7 @@ spec:
 시스템이 일반적으로 자동 생성하는 셀렉터를 사용하지 않도록 하기 위해
 새 잡에서 `manualSelector: true` 를 지정해야 한다.
 
-```
+```yaml
 kind: Job
 metadata:
   name: new

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

@@ -1,4 +1,6 @@
 ---
+
+
 title: 파드
 content_type: concept
 weight: 10
@@ -189,6 +191,34 @@ spec:
 시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을
 확장할 수 있게 한다.
 
+## 파드 갱신 및 교체
+
+이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드
+템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신
+갱신된 템플릿을 기반으로 신규 파드를 생성한다.
+
+쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다.
+동작 중인 파드의 필드를 갱신하는 것도 가능하다.
+그러나,
+[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 및
+[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)와 같은
+파드 갱신 작업에는 다음과 같은 제약이 있다.
+
+- 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는
+  `namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다.
+  그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는
+  갱신만 허용한다.
+- `metadata.deletionTimestamp` 가 설정된 경우,
+  `metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다.
+- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`,
+  `spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는
+  변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다.
+- `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만
+  허용한다.
+
+  1. 지정되지 않은 필드를 양수로 설정;
+  1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신.
+
 ## 리소스 공유와 통신
 
 파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을

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

@@ -1,4 +1,6 @@
 ---
+
+
 title: 초기화 컨테이너
 content_type: concept
 weight: 40
@@ -47,9 +49,9 @@ weight: 40
 또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다.
 왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다.
 
-만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을
+만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을
 한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다.
-모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을
+모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을
 초기화하고 평소와 같이 실행한다.
 
 ## 초기화 컨테이너 사용하기

content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -66,7 +66,7 @@ graph TB
 
 API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다.
 
-```
+```yaml
 apiVersion: v1
 kind: Pod
 metadata:
@@ -290,7 +290,7 @@ graph BT
 - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우.
 - 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우.
 
-기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서
+기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서
 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다.
 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로
 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러,
@@ -315,7 +315,7 @@ profiles:
 
 {{< note >}}
 기본 스케줄링 제약 조건에 의해 생성된 점수는
-[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에
+[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에
 의해 생성된 점수와 충돌 할 수 있다.
 `PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
 이 플러그인을 비활성화 하는 것을 권장한다.