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/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` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
 이 플러그인을 비활성화 하는 것을 권장한다.