Seventh Korean L10n Work for Release 1.16 (#18494)

* (fix) Broken links in Korean documentation. (#18179)
* Modified link between Korean documents. (#18152)
* Update to outdated files in the dev-1.16-ko.7 (#18146)
* Updates to documents that do not reflect the original text - 1.16 (#18166)
* Update path of referenced links in translated documents - 1.16. (#18164)

Co-Authored-By: Oleg Butuzov <butuzov@users.noreply.github.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>

Co-authored-by: Oleg Butuzov <butuzov@users.noreply.github.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>

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

@@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
 
 - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
 - 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
-- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
+- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
 
 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 

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

@@ -277,7 +277,7 @@ curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
 원본이 삭제되면 새 레플리카셋을 생성해서 대체할 수 있다.
 기존 `.spec.selector`와 신규 `.spec.selector`가 같으면 새 레플리카셋은 기존 파드를 선택한다.
 하지만 신규 레플리카셋은 기존 파드를 신규 레플리카셋의 새롭고 다른 파드 템플릿에 일치시키는 작업을 수행하지는 않는다.
-컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment)를 이용하면 된다. 
+컨트롤 방식으로 파드를 새로운 사양으로 업데이트 하기 위해서는 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-생성)를 이용하면 된다. 
 이는 레플리카셋이 롤링 업데이트를 직접적으로 지원하지 않기 때문이다.
 
 ### 레플리카셋에서 파드 격리

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

@@ -16,7 +16,7 @@ weight: 20
 {{% capture overview %}}
 
 {{< note >}}
-[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
+[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다.
 {{< /note >}}
 
 _레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가
@@ -143,7 +143,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 
 ### 파드 셀렉터
 
-`.spec.selector` 필드는 [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
+`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 이다. 레플리케이션 컨트롤러는 셀렉터와 일치하는 레이블이 있는 모든 파드를 관리한다.
 직접 생성하거나 삭제된 파드와 다른 사람이나 프로세스가 생성하거나
 삭제한 파드를 구분하지 않는다. 이렇게 하면 실행중인 파드에 영향을 주지 않고
 레플리케이션 컨트롤러를 교체할 수 있다.
@@ -257,14 +257,14 @@ API 오브젝트에 대한 더 자세한 것은
 
 ### 레플리카셋
 
-[`레플리카셋`](/docs/concepts/workloads/controllers/replicaset/)은 새로운 [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) 이다.
-이것은 주로 [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
+[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
+이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
 
 
 ### 디플로이먼트 (권장되는)
 
-[`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
+[`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 는 `kubectl rolling-update` 와 비슷한 방식으로 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다.
 `kubectl rolling-update` 와는 다르게 선언적이며, 서버 사이드이고,
 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
 
@@ -280,12 +280,12 @@ API 오브젝트에 대한 더 자세한 것은
 ### 데몬셋
 
 머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
-[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
+[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
 다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
 머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
 
 ## 더 자세한 정보는
 
-[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
+[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라.
 
 {{% /capture %}}

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

@@ -44,10 +44,6 @@ weight: 40
 ## 구성 요소
 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
 
-* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
-* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
-* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
-
 ```yaml
 apiVersion: v1
 kind: Service
@@ -99,6 +95,12 @@ spec:
           storage: 1Gi
 ```
 
+위의 예시에서:
+
+* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
+* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
+* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
+
 ## 파드 셀렉터
 스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
 
@@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
  kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |
 
 {{< note >}}
-클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 
+클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 
 아니라면 `cluster.local`로 설정된다.
 {{< /note >}}
 
@@ -260,7 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
 * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
-* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
+* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
 
 {{% /capture %}}
 

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

@@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.
 
-알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
-`TTLAfterFinished` 를 통해 활성화 될 수 있다.
+알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.
 
 
 {{% /capture %}}

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

@@ -68,7 +68,7 @@ weight: 60
 - 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다.
 - 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.)
 - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 
-영역 간(또는 [다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다.)에 
+영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에 
 애플리케이션을 분산해야 한다.
 
 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다.
@@ -116,7 +116,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
 그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다.
 애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
-([디플로이먼트 업데이트](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)에 대해 알아보기.)
+([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.)
 
 파드를 Eviction API로 축출하면 정상적으로 종료된다.
 ([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.)

content/ko/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -65,7 +65,7 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수
   * `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음.
   * `Ready`: 파드는 요청들을 수행할 수 있으며
     모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함.
-  * `Initialized`: 모든 [초기화 컨테이너](/docs/concepts/workloads/pods/init-containers)가
+  * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가
     성공적으로 시작 완료되었음.
   * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서
     지금 당장은 파드를 스케줄할 수 없음.
@@ -243,7 +243,7 @@ status:
 ```
 
 파드의 새로운 조건들은
-쿠버네티스의 [레이블 키 포멧](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)을 준수해야 한다.
+쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다.
 `kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에,
 새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다.
 
@@ -271,7 +271,7 @@ PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으
 kubelet에 의해서 재시작되는 종료된 컨테이너는
 5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 기준으로 재시작되며,
 10분의 성공적 실행 후에 재설정된다.
-[파드 문서](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)에서 의논된 바와 같이,
+[파드 문서](/ko/docs/concepts/workloads/pods/pod/#파드의-내구성-또는-결핍)에서 의논된 바와 같이,
 파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다.
 
 
@@ -290,13 +290,13 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는
   지정된 경우에 적합하다.
 
 - 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는
-  [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
-  [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/), 또는
-  [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다.
+  [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/),
+  [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는
+  [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다.
   레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된
   경우에만 적합하다.
 
-- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)을 사용하길
+- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하길
   바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다.
 
 세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를
@@ -401,7 +401,7 @@ spec:
 * Hands-on 경험하기
   [활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
 
-* [컨테이너 라이프사이클 후크(hook)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.
+* [컨테이너 라이프사이클 후크(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.
 
 {{% /capture %}}
 

content/ko/docs/concepts/workloads/pods/pod-overview.md

@@ -31,7 +31,7 @@ card:
   * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
   * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)
 
-각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
+각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다.
 
 ## 어떻게 파드가 다중 컨테이너를 관리하는가
 
@@ -61,7 +61,7 @@ card:
 파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다.
 {{< /note >}}
 
-파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다.
+파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다.
 
 ### 파드와 컨트롤러
 
@@ -69,17 +69,17 @@ card:
 
 한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시.
 
-* [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)
-* [스테이트풀 셋](/docs/concepts/workloads/controllers/statefulset/)
-* [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)
+* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
+* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
+* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
 
 일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다.
 
 ## 파드 템플릿
 
-파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/),
+파드 템플릿은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/),
 [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/),
-[데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
+[데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다.
 컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다.
 아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다.
 
@@ -102,8 +102,8 @@ spec:
 {{% /capture %}}
 
 {{% capture whatsnext %}}
-* [파드](/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
+* [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
 * 파드의 동작에 대해 더 알아보자.
-  * [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
+  * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)
   * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
 {{% /capture %}}

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

@@ -144,7 +144,7 @@ spec:
 +---------------+-------+
 |     zoneA     | zoneB |
 +-------+-------+-------+
-| node1 | node2 |  nod3 |
+| node1 | node2 | node3 |
 +-------+-------+-------+
 |  P P  |   P   |  P P  |
 +-------+-------+-------+

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

@@ -45,13 +45,13 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지
 도커 컨테이너 그룹으로 모델링 된다.
 
 개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다.
-[파드의 생애](/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
+[파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
 파드가 만들어지고 고유한 ID(UID)가 할당되고,
 재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.   
 노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다.
 해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로,
 원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다.
-더 자세한 내용은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
+더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
 
 볼륨과 같이 파드와 동일한 수명이 있다고 하면,
 UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것을 의미한다.
@@ -133,10 +133,10 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
 
 일반적으로 사용자는 파드를 직접 만들 필요가 없다.
-싱글톤이라도 대부분 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
+싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
 컨트롤러는 클러스터 범위에서
 복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다.
-[StatefulSet](/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
+[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도
 위와 같은 기능 제공을 할 수 있다.
 
 사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
@@ -165,7 +165,7 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하
 1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다.  
 1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
 1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
-    1. 파드의 컨테이너 중 하나에 [preStop hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
+    1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초) 연장해서 2번 단계를 실행한다.
     1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자.
 1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다.
 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.

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

@@ -17,7 +17,7 @@ weight: 50
 `Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을
 주입하기 위한 API 리소스이다.
 주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는
-[레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다.
+[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 사용한다.
 
 파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드