Second Korean L10n Work For Release 1.17 (#18570)

- Update to Outdated files in dev-1.17-ko.2 branch. (#18236)

- Update path of referenced links in translated documents - 1.17 (#18282)

- Use original text for a code (#18358)

- Updates to documents that do not reflect the original text - 1.17 (#18270)

- Translate services-networking/dual-stack.md in Korean. (#18251)

- Update cluster-large.md (#18232)

- Translate services-networking/network-policies.md in Korean. (#18269)

- Modify reference links for translated documents added from previous branches. (#18432)

- Translate docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md in Korean (#18484)

Co-Authored-By: Lawrence Kay <lkay9495@hotmail.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: Jmnote <opcore@gmail.com>
Co-Authored-By: Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-Authored-By: June Yi <june.yi@samsung.com>

Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr>
Co-authored-by: Jmnote <opcore@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>

content/ko/docs/concepts/_index.md

@@ -35,7 +35,7 @@ weight: 40
 * [볼륨](/docs/concepts/storage/volumes/)
 * [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)
 
-또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
+또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
 
 * [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
 * [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)

content/ko/docs/concepts/architecture/master-node-communication.md

@@ -6,10 +6,11 @@ weight: 20
 
 {{% capture overview %}}
 
-이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의 커뮤니케이션 경로를 나열해 본다.
+이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의
-그 목적은 사용자로 하여금 untrusted network(신뢰할 수 없는 네트워크) 상에서
+커뮤니케이션 경로를 나열해 본다. 그 목적은 신뢰할 수 없는 네트워크
-(또는 클라우드 제공사업자 환경에서 완전히 공인 IP로) 동작될 수 있는
+(또는 클라우드 제공자의 공인 IP만으로 구성된 네트워크)에서도 동작될 수 있는
-그러한 클러스터의 네트워크 구성을 강화하기 위해 사용자의 설치를 커스터마이즈 할 수 있도록 해주기 위함이다.
+클러스터 구축을 위해, 네트워크의 구성을 강화하는 사용자
+맞춤형 설치를 허용하기 위함이다.
 
 {{% /capture %}}
 
@@ -20,23 +21,27 @@ weight: 20
 
 클러스터에서 마스터로의 모든 커뮤니케이션 경로는 apiserver에서 끝난다
 (어떤 다른 마스터 컴포넌트도 원격 서비스를 노출하기 위해 설계되지 않는다).
-전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형태가
+전형적인 배포에서, apiserver는 하나 또는 그 이상의 클라이언트
+[인증](/docs/reference/access-authn-authz/authentication/) 형태가
 사용가능토록 하여 안전한 HTTPS 포트(443)를 통해 원격 연결에 대해 서비스 리슨하도록 구성된다.
 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
 또는 [서비스 계정 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이   
-허용된 경우에는 하나 또는 그 이상의 [인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.
+허용된 경우에는 하나 또는 그 이상의
+[인가](/docs/reference/access-authn-authz/authorization/) 형태가 사용 가능해야만 한다.
 
 노드는 유효한 클라이언트 자격증명과 함께 apiserver에 안전하게 접속할 수 있는
 그런 클러스터용 공인 루트 인증서를 가지고 제공되어야 한다.
 예를 들어, 기본 GKE 배포의 경우, kubelet에 제공되는 클라이언트 자격증명은
-클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에 대한 자동화 프로비저닝에 대해서는
+클라이언트 인증서의 형태로 존재한다. kubelet 클라이언트 인증서에
+대한 자동화 프로비저닝에 대해서는
 [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
 
 apiserver에 접속하려는 파드는 서비스 계정에 영향력을 발휘함으로써 안전하게
 그리 행할 수 있으며 따라서 쿠버네티스는 인스턴스화 될 때 공인 루트 인증서와
 유효한 베어러 토큰을 파드 속으로 자동 주입할 수 있게 된다.
 (모든 네임스페이스 내) `kubernetes` 서비스는 apiserver 상의 HTTPS 엔드포인트로  
-(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를 가지고 구성된다.
+(kube-proxy를 통해) 리다이렉트 되는 가상 IP 주소를
+가지고 구성된다.
 
 마스터 컴포넌트는 또한 신뢰할 수 있는 포트를 통해 클러스터 apiserver와 소통한다.
 
@@ -64,11 +69,12 @@ apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
 이는 연결에 대한 중간자 공격을 당하게 하고, 신뢰할 수 없는
 그리고/또는 공인 네트워크에서 운영하기에는 **불안** 하게 만든다.  
 
-이 연결을 확인하려면, apiserver에 kubelet의 제공 인증서 확인을 위해 사용하는
+이 연결을 확인하려면, apiserver에 kubelet의 제공 인증서 확인을
-루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다
+위해 사용하는 루트 인증서 번들로 `--kubelet-certificate-authority`
+플래그를 이용한다
 
 그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
-apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)을
+apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-터널)을
 사용한다.
 
 마지막으로, kubelet API를 안전하게 하기 위해
@@ -85,4 +91,15 @@ HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며
 이러한 연결들은 신뢰할 수 없는 그리고/또는 공인 네트워크에서 동작하기에
 **현재로서는 안전하지 않다**.
 
+### SSH 터널
+
+쿠버네티스는 마스터 -> 클러스터 통신 경로를 보호하는 SSH 터널을
+지원한다. 이 구성에서 apiserver는 클러스터의 각 노드에서 SSH 터널을
+시작하고(포트 22번으로 수신 대기하는 ssh 서버에 연결), 터널을 통해
+kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
+이 터널은 실행중인 노드의 트래픽이 외부로 노출되지
+않도록 보장한다.
+
+SSH 터널은 현재 사용 중단(deprecated)되었으므로, 무엇을 하고 있는지 알지 못하는 한 터널을 이용하지 말아야 한다. 이 통신 채널의 대체물을 설계 중이다.
+
 {{% /capture %}}

content/ko/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -41,7 +41,7 @@ weight: 10
 
 * [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
 
-* [쿠버네티스 컨테이너 환경](/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
+* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
 
 * [쿠버네티스 API에 대한 접근 제어](/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 계정에 어떻게 권한 설정을 하는지 설명한다.
 
@@ -62,7 +62,7 @@ weight: 10
 
 ## 선택적 클러스터 서비스
 
-* [DNS 통합](/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
+* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
 
 * [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.
 

content/ko/docs/concepts/configuration/overview.md

@@ -30,9 +30,9 @@ weight: 10
 
 ## "단독(Naked)" 파드 vs 레플리카 셋, 디플로이먼트, 그리고 잡
 
-- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
+- 가능하다면 단독 파드(즉, [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)이나 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 연결되지 않은 파드)를 사용하지 않는다. 단독 파드는 노드 장애 이벤트가 발생해도 다시 스케줄링되지 않는다.
 
-  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
+  명백하게 [`restartPolicy: Never`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)를 사용하는 상황을 제외한다면, 의도한 파드의 수가 항상 사용 가능한 상태를 유지하는 레플리카 셋을 생성하고, 파드를 교체하는 전략([롤링 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-롤링-업데이트)와 같은)을 명시하는 디플로이먼트는 파드를 직접 생성하기 위해 항상 선호되는 방법이다. [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 또한 적절할 수 있다.
 
 
 ## 서비스
@@ -62,9 +62,9 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
 
 ## 레이블 사용하기
 
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
 
-릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
+릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 생성되어 있는 서비스를 다운타임 없이 수정하기 쉽도록 만든다.
 
 오브젝트의 의도한 상태는 디플로이먼트에 의해 기술되며, 만약 그 스펙에 대한 변화가 _적용될_ 경우, 디플로이먼트 컨트롤러는 일정한 비율로 실제 상태를 의도한 상태로 변화시킨다.
 
@@ -100,7 +100,7 @@ services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다.
 
 - `kubectl apply -f <디렉터리>`를 사용한다. 이 명령어는 `<디렉터리>` 내부의 모든 `.yaml`, `.yml`, 그리고 `.json` 쿠버네티스 구성 파일을 찾아 `apply`에 전달한다.
 
-- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.
+- `get`과 `delete` 동작을 위해 특정 오브젝트의 이름 대신 레이블 셀렉터를 사용한다. [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)와 [효율적으로 레이블 사용하기](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)를 참고할 수 있다.
 
 - 단일 컨테이너로 구성된 디플로이먼트와 서비스를 빠르게 생성하기 위해 `kubectl run`와 `kubectl expose`를 사용한다. [클러스터 내부의 애플리케이션에 접근하기 위한 서비스 사용](/docs/tasks/access-application-cluster/service-access-application-cluster/)에서 예시를 확인할 수 있다.
 

content/ko/docs/concepts/containers/container-environment-variables.md

@@ -17,7 +17,7 @@ weight: 20
 
 쿠버네티스 컨테이너 환경은 컨테이너에 몇 가지 중요한 리소스를 제공한다.
 
-* 하나의 [이미지](/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템.
+* 하나의 [이미지](/ko/docs/concepts/containers/images/)와 하나 이상의 [볼륨](/docs/concepts/storage/volumes/)이 결합된 파일 시스템.
 * 컨테이너 자신에 대한 정보.
 * 클러스터 내의 다른 오브젝트에 대한 정보.
 
@@ -54,7 +54,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
 
 {{% capture whatsnext %}}
 
-* [컨테이너 라이프사이클 훅(hooks)](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
+* [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기.
 
 {{% /capture %}}

content/ko/docs/concepts/containers/container-lifecycle-hooks.md

@@ -39,7 +39,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 파라미터는 핸들러에 전달되지 않는다.
 
 종료 동작에 더 자세한 대한 설명은 
-[파드의 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)에서 찾을 수 있다.
+[파드의 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)에서 찾을 수 있다.
 
 ### 훅 핸들러 구현
 
@@ -113,7 +113,7 @@ Events:
 
 {{% capture whatsnext %}}
 
-* [컨테이너 환경](/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
+* [컨테이너 환경](/ko/docs/concepts/containers/container-environment-variables/)에 대해 더 배우기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
   실습 경험하기.
 

content/ko/docs/concepts/containers/images.md

@@ -26,7 +26,7 @@ weight: 10
 - `imagePullPolicy`와 사용할 이미지의 태그를 생략.
 - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화.
 
-`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/docs/concepts/configuration/overview/#container-images)를 참고한다.
+`:latest` 태그 사용은 피해야 한다는 것을 참고하고, 자세한 정보는 [구성을 위한 모범 사례](/ko/docs/concepts/configuration/overview/#컨테이너-이미지)를 참고한다.
 
 ## 매니페스트로 멀티-아키텍처 이미지 빌드
 
@@ -141,7 +141,7 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다
    * `DOCKER_EMAIL`: `${some-email-address}`
 
 해당 변수에 대한 값을 채우고 나면 
-[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)할 수 있다.
+[쿠버네티스 시크릿을 구성하고 그것을 파드 디플로이를 위해서 사용](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)할 수 있다.
 
 ### IBM 클라우드 컨테이너 레지스트리 사용
 IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗 이미지 레지스트리를 제공하여 사용자가 Docker 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 
@@ -149,7 +149,7 @@ IBM 클라우드 컨테이너 레지스트리는 멀티-테넌트 프라이빗
 
 IBM 클라우드 컨테이너 레지스트리 CLI 플러그인을 설치하고 사용자 이미지를 위한 네임스페이스를 생성하기 위해서는, [IBM 클라우드 컨테이너 레지스트리 시작하기](https://cloud.ibm.com/docs/services/Registry?topic=registry-getting-started)를 참고한다.
 
-[IBM 클라우드 퍼블릭 이미지](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) 및 사용자의 프라이빗 이미지로부터 컨테이너를 사용자의 IBM 클라우드 쿠버네티스 서비스 클러스터의 `default` 네임스페이스에 디플로이하기 위해서 IBM 클라우드 컨테이너 레지스트리를 사용하면 된다. 컨테이너를 다른 네임스페이스에 디플로이하거나, 다른 IBM 클라우드 컨테이너 레지스트리 지역 또는 IBM 클라우드 계정을 사용하기 위해서는, 쿠버네티스 `imagePullSecret`를 생성한다. 더 자세한 정보는, [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images#images)를 참고한다.
+[IBM 클라우드 퍼블릭 이미지](https://cloud.ibm.com/docs/services/Registry?topic=registry-public_images) 및 사용자의 프라이빗 이미지로부터 컨테이너를 사용자의 IBM 클라우드 쿠버네티스 서비스 클러스터의 `default` 네임스페이스에 디플로이하기 위해서 IBM 클라우드 컨테이너 레지스트리를 사용하면 된다. 컨테이너를 다른 네임스페이스에 디플로이하거나, 다른 IBM 클라우드 컨테이너 레지스트리 지역 또는 IBM 클라우드 계정을 사용하기 위해서는, 쿠버네티스 `imagePullSecret`를 생성한다. 더 자세한 정보는, [이미지로부터 컨테이너 빌드하기](https://cloud.ibm.com/docs/containers?topic=containers-images)를 참고한다.
 
 ### 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
 

content/ko/docs/concepts/overview/components.md

@@ -121,7 +121,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
 {{% /capture %}}
 {{% capture whatsnext %}}
 * [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기
-* [컨트롤러](/docs/concepts/architecture/controller/)에 대해 더 배우기
+* [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기
 * [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기
 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기
 {{% /capture %}}

content/ko/docs/concepts/overview/working-with-objects/annotations.md

@@ -91,7 +91,7 @@ spec:
 {{% /capture %}}
 
 {{% capture whatsnext %}}
-[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
+[레이블과 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
 {{% /capture %}}
 
 

content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -74,7 +74,7 @@ deployment.apps/nginx-deployment created
 
 {{% capture whatsnext %}}
 * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
-* 쿠버네티스의 [컨트롤러](/docs/concepts/architecture/controller/)에 대해 배운다.
+* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
 {{% /capture %}}
 
 

content/ko/docs/concepts/overview/working-with-objects/labels.md

@@ -20,7 +20,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
 }
 ```
 
-레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
+레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
 
 {{% /capture %}}
 
@@ -75,7 +75,7 @@ spec:
 
 ## 레이블 셀렉터
 
-[이름과 UID](/docs/user-guide/identifiers)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
+[이름과 UID](/ko/docs/concepts/overview/working-with-objects/names/)와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.
 
 레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.
 
@@ -184,7 +184,7 @@ kubectl get pods -l 'environment,environment notin (frontend)'
 
 ### API 오브젝트에서 참조 설정
 
-[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
+[`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
 
 #### 서비스와 레플리케이션 컨트롤러
 
@@ -209,7 +209,7 @@ selector:
 
 #### 세트-기반 요건을 지원하는 리소스
 
-[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
+[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
 
 ```yaml
 selector:

content/ko/docs/concepts/overview/working-with-objects/names.md

@@ -11,7 +11,7 @@ weight: 20
 
 예를 들어, 이름이 `myapp-1234`인 파드는 동일한 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) 내에서 하나만 가질 수 있지만, 이름이 `myapp-1234`인 파드와 디플로이먼트는 각각 가질 수 있다.
 
-유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
+유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)과 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
 
 {{% /capture %}}
 

content/ko/docs/concepts/overview/working-with-objects/namespaces.md

@@ -84,7 +84,7 @@ kubectl config view --minify | grep namespace:
 ## 네임스페이스와 DNS
 
 [서비스](/docs/user-guide/services)를 생성하면, 대응되는
-[DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
+[DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
 이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
 이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다.

content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md

@@ -0,0 +1,126 @@
+---
+title: HostAliases로 파드의 /etc/hosts 항목 추가하기
+content_template: templates/concept
+weight: 60
+---
+
+{{< toc >}}
+
+{{% capture overview %}}
+파드의 /etc/hosts 파일에 항목을 추가하는 것은 DNS나 다른 방법들이 적용되지 않을 때 파드 수준의 호스트네임 해석을 제공한다. 1.7 버전에서는, 사용자들이 PodSpec의 HostAliases 항목을 사용하여 이러한 사용자 정의 항목들을 추가할 수 있다.
+
+HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 Kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다.
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 기본 호스트 파일 내용
+
+파드 IP가 할당된 Nginx 파드를 시작해보자.
+
+```shell
+kubectl run nginx --image nginx --generator=run-pod/v1
+```
+
+```shell
+pod/nginx created
+```
+
+파드 IP를 확인해보자.
+
+```shell
+kubectl get pods --output=wide
+```
+
+```shell
+NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+nginx    1/1       Running   0          13s    10.200.0.4   worker0
+```
+
+호스트 파일의 내용은 아래와 같을 것이다.
+
+```shell
+kubectl exec nginx -- cat /etc/hosts
+```
+
+```none
+# Kubernetes-managed hosts file.
+127.0.0.1	localhost
+::1	localhost ip6-localhost ip6-loopback
+fe00::0	ip6-localnet
+fe00::0	ip6-mcastprefix
+fe00::1	ip6-allnodes
+fe00::2	ip6-allrouters
+10.200.0.4	nginx
+```
+
+기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 
+상용구들만 포함하고 있다.
+
+## HostAliases를 사용하여 추가 항목들 추가하기
+
+기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, `foo.remote`, 
+`bar.remote`가 `10.1.2.3`로 해석될 수 있도록 추가 항목들을 `hosts` 파일에 추가할 수 있으며, 
+이는 `.spec.hostAliases` 항목에서 정의하여 
+파드에 HostAliases를 추가하면 가능하다.
+
+
+{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
+
+이 파드는 다음의 명령어를 통해 시작될 수 있다.
+
+```shell
+kubectl apply -f hostaliases-pod.yaml
+```
+
+```shell
+pod/hostaliases-pod created
+```
+
+파드의 IP와 상태를 확인해보자.
+
+```shell
+kubectl get pod --output=wide
+```
+
+```shell
+NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE
+hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0
+```
+
+`hosts` 파일 내용은 아래와 같을 것이다.
+
+```shell
+kubectl logs hostaliases-pod
+```
+
+```none
+# Kubernetes-managed hosts file.
+127.0.0.1	localhost
+::1	localhost ip6-localhost ip6-loopback
+fe00::0	ip6-localnet
+fe00::0	ip6-mcastprefix
+fe00::1	ip6-allnodes
+fe00::2	ip6-allrouters
+10.200.0.5	hostaliases-pod
+
+# Entries added by HostAliases.
+127.0.0.1	foo.local	bar.local
+10.1.2.3	foo.remote	bar.remote
+```
+
+가장 마지막에 추가 항목들이 정의되어 있는 것을 확인할 수 있다.
+
+## 왜 Kubelet이 호스트 파일을 관리하는가?
+
+컨테이너가 이미 시작되고 난 후 Docker가 파일을 [수정](https://github.com/moby/moby/issues/17190)
+하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 
+[관리](https://github.com/kubernetes/kubernetes/issues/14633)
+한다.
+
+호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 
+`hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이
+덮어쓰여진다. 따라서, 호스트 파일의 내용을 
+직접 바꾸는 것은 권장하지 않는다.
+
+{{% /capture %}}

content/ko/docs/concepts/services-networking/dual-stack.md

@@ -0,0 +1,106 @@
+---
+title: IPv4/IPv6 이중 스택
+feature:
+  title: IPv4/IPv6 이중 스택
+  description: >
+    파드와 서비스에 IPv4와 IPv6 주소 할당
+
+content_template: templates/concept
+weight: 70
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+ IPv4/IPv6 이중 스택을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}} 와 {{< glossary_tooltip text="서비스" term_id="service" >}} 에 IPv4와 IPv6 주소를 모두 할당 할 수 있다.
+
+만약 쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택 네트워킹을 활성화하면, 클러스터는 IPv4와 IPv6 주소의 동시 할당을 지원하게 된다.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 지원되는 기능
+
+쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택을 활성화하면 다음의 기능을 제공한다.
+
+   * 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
+   * IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.)
+   * Kubenet 다중 주소 패밀리 지원(IPv4와 IPv6)
+   * IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 송신 라우팅(예: 인터넷)
+
+## 필수 구성 요소
+
+IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다.
+
+   * 쿠버네티스 1.16 또는 이후 버전
+   * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
+   * Kubenet 네트워크 플러그인
+   * IPVS 모드에서 구동 중인 Kube-Proxy
+
+## IPv4/IPv6 이중 스택 활성화
+
+IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다.
+
+   * kube-controller-manager:
+      * `--feature-gates="IPv6DualStack=true"`
+      * `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>` 예: `--cluster-cidr=10.244.0.0/16,fc00::/24`
+      * `--service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR>`
+      * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64이다.
+   * kubelet:
+      * `--feature-gates="IPv6DualStack=true"`
+   * kube-proxy:
+      * `--proxy-mode=ipvs`
+      * `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>` 
+      * `--feature-gates="IPv6DualStack=true"`
+
+{{< caution >}}
+명령줄에서 `--cluster-cidr` 를 통해 /24보다 큰 IPv6 주소 블럭을 지정하면 할당이 실패한다.
+{{< /caution >}}
+
+## 서비스
+
+만약 클러스터 IPv4/IPv6 이중 스택 네트워킹을 활성화한 경우, IPv4 또는 IPv6 주소로 {{< glossary_tooltip text="서비스" term_id="service" >}} 를 만들 수 있다. 해당 서비스에서 `.spec.ipFamily` 필드를 설정하면, 서비스 클러스터 IP의 주소 패밀리를 선택할 수 있다.
+새 서비스를 생성할 때만 이 필드를 설정할 수 있다. `.spec.ipFamily` 필드는 선택 사항이며 클러스터에서 {{< glossary_tooltip text="서비스" term_id="service" >}} 와 {{< glossary_tooltip text="인그레스" term_id="ingress" >}} 를 IPv4와 IPv6로 사용하도록 설정할 경우에만 사용해야 한다. 이 필드의 구성은 [송신](#송신-트래픽)에 대한 요구사항이 아니다.
+
+{{< note >}}
+클러스터의 기본 주소 패밀리는 `--service-cluster-ip-range` 플래그로 kube-controller-manager에 구성된 첫 번째 서비스 클러스터 IP 범위의 주소 패밀리이다.
+{{< /note >}}
+
+`.spec.ipFamily` 를 다음 중 하나로 설정할 수 있다.
+
+   * `IPv4`: API 서버는 `ipv4` 인 `service-cluster-ip-range` 의 IP를 할당 한다.
+   * `IPv6`: API 서버는 `ipv6` 인 `service-cluster-ip-range` 의 IP를 할당 한다.
+
+다음 서비스 사양에는 `ipFamily` 필드가 포함되어 있지 않다. 쿠버네티스는 처음 구성된 `service-cluster-ip-range` 의 IP 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당 한다.
+
+{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}}
+
+다음 서비스 명세에는 `ipFamily` 필드가 포함되어 있다. 쿠버네티스는 구성된 `service-cluster-ip-range` 의 IPv6 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당 한다.
+
+{{< codenew file="service/networking/dual-stack-ipv6-svc.yaml" >}}
+
+비교를 위해, 다음 서비스 명세에는 구성된 `service-cluster-ip-range` 의 IPv4 주소("클러스터 IP" 라고도 함)를 이 서비스에 할당한다.
+
+{{< codenew file="service/networking/dual-stack-ipv4-svc.yaml" >}}
+
+### 로드밸런서 유형
+
+IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급자들은 `type` 필드를 `LoadBalancer` 로 설정하고, 추가적으로 `ipFamily` 필드를 `IPv6` 로 설정하면 서비스에 대한 클라우드 로드 밸런서가 구축된다.
+
+## 송신 트래픽
+
+근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 송신 트래픽과 모든 응답을 위한 위장 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 는 이중 스택을 인식하기에, 이중 스택 클러스터에서 위장 IP에 ip-masq-agent 를 사용할 수 있다.
+
+## 알려진 이슈들
+
+   * Kubenet은 IP의 IPv4,IPv6의 위치 보고를 강제로 수행한다. (--cluster-cidr)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [IPv4/IPv6 이중 스택 확인](/docs/tasks/network/validate-dual-stack) 네트워킹
+
+{{% /capture %}}

content/ko/docs/concepts/services-networking/endpoint-slices.md

@@ -91,7 +91,7 @@ EndpointSlice는 다음 주소 유형을 지원한다.
 
 {{% capture whatsnext %}}
 
-* [엔드포인트 슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpoint-slices)
+* [엔드포인트 슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)
-* [애플리케이션을 서비스와 함께 연결하기](/docs/concepts/services-networking/connect-applications-service/) 를 읽는다.
+* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다.
 
 {{% /capture %}}

content/ko/docs/concepts/services-networking/network-policies.md

@@ -0,0 +1,267 @@
+---
+title: 네트워크 정책
+content_template: templates/concept
+weight: 50
+---
+
+{{< toc >}}
+
+{{% capture overview %}}
+네트워크 정책은 파드 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
+
+`NetworkPolicy` 리소스는 레이블을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다.
+
+{{% /capture %}}
+
+{{% capture body %}}
+## 전제 조건
+
+네트워크 정책은 네트워크 플러그인으로 구현되므로 `NetworkPolicy` 를 지원하는 네트워킹 솔루션을 사용해야 한다. - 컨트롤러가 없이 단순하게 리소스를 생성하게 되면 아무런 효과가 없기 때문이다. 
+
+## 격리 및 격리되지 않은 파드
+
+기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다.
+
+파드는 파드를 선택한 NetworkPolicy에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 NetworkPolicy가 있으면 해당 파드는 NetworkPolicy에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 NetworkPolicy에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.)
+
+네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다.
+
+## `NetworkPolicy` 리소스
+
+리소스에 대한 전체 정의는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다.
+
+`NetworkPolicy` 의 예시는 다음과 같다.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: test-network-policy
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  policyTypes:
+  - Ingress
+  - Egress
+  ingress:
+  - from:
+    - ipBlock:
+        cidr: 172.17.0.0/16
+        except:
+        - 172.17.1.0/24
+    - namespaceSelector:
+        matchLabels:
+          project: myproject
+    - podSelector:
+        matchLabels:
+          role: frontend
+    ports:
+    - protocol: TCP
+      port: 6379
+  egress:
+  - to:
+    - ipBlock:
+        cidr: 10.0.0.0/24
+    ports:
+    - protocol: TCP
+      port: 5978
+```
+
+*선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 API 서버에 이를 POST 하더라도 효과가 없다.*
+
+__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 `NetworkPolicy` 에는
+`apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일
+작업에 대한 일반적인 정보는
+[컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다.
+
+__spec__: `NetworkPolicy` [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다.
+
+__podSelector__: 각 `NetworkPolicy` 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다.
+
+__policyTypes__: 각 `NetworkPolicy` 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다.
+
+__ingress__: 각 `NetworkPolicy` 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
+
+__egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.
+
+따라서 예시의 NetworkPolicy는 다음과 같이 동작한다.
+
+1. 인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우).
+2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다.
+
+   * "role=frontend" 레이블이 있는 "default" 네임스페이스의 모든 파드
+   * 네임스페이스와 "project=myproject" 를 레이블로 가지는 모든 파드
+   * 172.17.0.0–172.17.0.255 와 172.17.2.0–172.17.255.255 의 범위를 가지는 IP 주소(예: 172.17.0.0/16 전체에서 172.17.1.0/24 를 제외)
+3. (이그레스 규칙)은 "role=db" 레이블이 있는 "default" 네임스페이스의 모든 파드에서 TCP 포트 5978의 CIDR 10.0.0.0/24 로의 연결을 허용한다.
+
+자세한 설명과 추가 예시는 [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다.
+
+## `to` 및 `from` 셀럭터의 동작
+
+`ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다.
+
+__podSelector__: `NetworkPolicy` 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다.
+
+__namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다.
+
+__namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelector` 를 모두 지정하는 단일 `to`/`from` 항목은 특정 네임스페이스 내에서 특정 파드를 선택한다. 올바른 YAML 구문을 사용하도록 주의해야 한다. 이 정책:
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+      podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+네임스페이스에서 레이블이 `role=client` 인 것과 레이블이 `user=alice` 인 파드의 연결을 허용하는 단일 `from` 요소가 포함되어 있다. 그러나 *이* 정책:
+
+```yaml
+  ...
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          user: alice
+    - podSelector:
+        matchLabels:
+          role: client
+  ...
+```
+
+`from` 배열에 두 개의 요소가 포함되어 있으며, 로컬 네임스페이스에 레이블을 `role=client` 로 가지는 파드 *또는* 네임스페이스에 레이블을 `user=alice` 로 가지는 파드의 연결을 허용한다.
+
+의심스러운 경우, `kubectl describe` 를 사용해서 쿠버네티스가 정책을 어떻게 해석하는지 확인해본다.
+
+__ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다.
+
+클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을
+필요로 한다. 이러한 상황이 발생하는 경우, NetworkPolicy의 처리 전 또는 후에
+발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자,
+`서비스` 구현 등의 조합에 따라 동작이 다를 수 있다.
+
+인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을 
+필터링할 수 있는 반면에 다른 경우에는 NetworkPolicy가 작동하는 
+"소스 IP"는 `LoadBalancer` 또는 파드가 속한 노드 등의 IP일 수 있다.
+
+이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은 
+`ipBlock` 기반의 정책의 적용을 받거나 받지 않을 수 있다는 것을 의미한다.
+
+## 기본 정책
+
+기본적으로 네임스페이스 정책이 없으면 해당 네임스페이스의 파드에 대한 모든 인그레스와 이그레스 트래픽이 허용된다. 다음 예시에서는 해당 네임스페이스의 기본 동작을
+변경할 수 있다.
+
+### 기본적으로 모든 인그레스 트래픽 거부
+
+모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
+```
+
+이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다.
+
+### 기본적으로 모든 인그레스 트래픽 허용
+
+만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all
+spec:
+  podSelector: {}
+  ingress:
+  - {}
+  policyTypes:
+  - Ingress
+```
+
+### 기본적으로 모든 이그레스 트래픽 거부
+
+모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny
+spec:
+  podSelector: {}
+  policyTypes:
+  - Egress
+```
+
+이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 
+기본 인그레스 격리 정책을 변경하지 않는다.
+
+### 기본적으로 모든 이그레스 트래픽 허용
+
+만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all
+spec:
+  podSelector: {}
+  egress:
+  - {}
+  policyTypes:
+  - Egress
+```
+
+### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부
+
+해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다.
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny
+spec:
+  podSelector: {}
+  policyTypes:
+  - Ingress
+  - Egress
+```
+
+이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다.
+
+## SCTP 지원
+
+{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+
+쿠버네티스는 `NetworkPolicy` 정의에서 `protocol` 값으로 SCTP를 알파 기능으로 지원한다. 이 기능을 활성화하려면 클러스터 관리자가 apiserver 에서 `SCTPSupport` 기능 게이트를 활성화 할 필요가 있다. 예를 들면, `“--feature-gates=SCTPSupport=true,...”` . 기능 게이트가 활성화 되면 `NetworkPolicy` 의 `protocol` 필드를 `SCTP` 로 설정할 수 있다.
+
+CNI 플러그인은 SCTP를 `NetworkPolicy` 에서 `protocol` 값으로 지원해야 한다.
+
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+- 자세한 설명과 추가 예시는
+  [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다.
+- NetworkPolicy 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다.
+
+{{% /capture %}}

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

@@ -6,6 +6,8 @@ weight: 80
 
 {{% capture overview %}}
 
+{{< feature-state for_k8s_version="v1.8" state="beta" >}}
+
 _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다.
 
 하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다.

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

@@ -1,7 +1,4 @@
 ---
-
-
-
 title: 레플리케이션 컨트롤러
 feature:
   title: 자가 치유
@@ -16,7 +13,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 +140,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 +254,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/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
-이것은 주로 [`디플로이먼트`](/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
+이것은 주로 [`디플로이먼트`](/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,7 +277,7 @@ API 오브젝트에 대한 더 자세한 것은
 ### 데몬셋
 
 머신 모니터링이나 머신 로깅과 같은 머신 레벨 기능을 제공하는 파드에는 레플리케이션 컨트롤러 대신
-[`데몬셋`](/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
+[`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하라. 이런 파드들의 수명은 머신의 수명에 달려 있다.
 다른 파드가 시작되기 전에 파드가 머신에서 실행되어야 하며,
 머신이 재부팅/종료 준비가 되어 있을 때 안전하게 종료된다.
 

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/),
+  [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/),
-  [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/), 또는
+  [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는
-  [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다.
+  [디플로이먼트](/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/)
+* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
-* [스테이트풀 셋](/docs/concepts/workloads/controllers/statefulset/)
+* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
-* [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)
+* [데몬 셋](/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.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/#레이블-셀렉터)를 사용한다.
 
 파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로
 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드

content/ko/docs/contribute/style/write-new-topic.md

@@ -24,8 +24,8 @@ weight: 20
 :--- | :----------
 개념 | 개념 페이지는 쿠버네티스의 일부 측면을 설명한다. 예를 들어 개념 페이지는 쿠버네티스 디플로이먼트 오브젝트를 설명하고 배치, 확장 및 업데이트되는 동안 애플리케이션으로서 수행하는 역할을 설명할 수 있다. 일반적으로 개념 페이지는 일련의 단계가 포함되지 않지만 대신 태스크나 튜토리얼에 대한 링크를 제공한다. 개념 문서의 예로서 <a href="/ko/docs/concepts/architecture/nodes/">노드</a>를 참조하자.
 태스크 | 태스크 페이지는 단일 작업을 수행하는 방법을 보여준다. 아이디어는 독자가 페이지를 읽을 때 실제로 수행할 수 있는 일련의 단계를 제공하는 것이다. 태스크 페이지는 한 영역에 집중되어 있으면 짧거나 길 수 있다. 태스크 페이지에서 수행할 단계와 간단한 설명을 혼합하는 것은 괜찮지만, 긴 설명을 제공해야 하는 경우에는 개념 문서에서 수행해야 한다. 관련 태스크와 개념 문서는 서로 연결되어야 한다. 짧은 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-volume-storage/">저장소에 볼륨을 사용하도록 파드 구성</a>을 참조하자. 더 긴 태스크 페이지의 예제는 <a href="/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/">활동성 및 준비성 프로브 구성</a>을 참조하자.
-튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다. 
+튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
-{{< /table >}} 
+{{< /table >}}
 
 새 페이지에 대한 템플릿을 사용하자. 각 페이지 타입에 있는
 [템플릿](/docs/contribute/style/page-templates/)
@@ -47,12 +47,12 @@ weight: 20
 ## 전문에 항목 제목 추가
 
 문서에서 [전문](https://gohugo.io/content-management/front-matter/)
-에 `제목` 필드를 입력하자.
+에 `title` 필드를 입력하자.
 전문은 페이지 상단의 3중 점선 사이에 있는
 YAML 블록이다. 여기 예시가 있다.
 
     ---
-    제목: HTTP 프록시를 사용하여 쿠버네티스 API에 접근
+    title: HTTP 프록시를 사용하여 쿠버네티스 API에 접근
     ---
 
 ## 디렉토리 선택
@@ -68,9 +68,9 @@ YAML 블록이다. 여기 예시가 있다.
 
 ## 목차에 항목 배치
 
-목차는 문서 소스의 디렉토리 구조를 사용하여 
+목차는 문서 소스의 디렉토리 구조를 사용하여
-동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉토리는 최상위 레벨 탐색 기능을 
+동적으로 작성된다. `/content/en/docs/` 아래의 최상위 디렉토리는 최상위 레벨 탐색 기능을
-생성하고, 하위 디렉토리는 각각 목차에 항목을 
+생성하고, 하위 디렉토리는 각각 목차에 항목을
 갖는다.
 
 각 하위 디렉토리에는 `_index.md` 파일이 있으며 이는 해당 하위 디렉토리의 컨텐츠에 대한
@@ -86,12 +86,12 @@ YAML 블록이다. 여기 예시가 있다.
 ## 문서에 코드 포함
 
 문서에 코드를 포함시키려면 마크다운 코드 블록 구문을 사용하여
-파일에 코드를 직접 삽입하자. 다음 경우에 
+파일에 코드를 직접 삽입하자. 다음 경우에
 권장된다. (전체 목록은 아님)
 
 - 이 코드는 `kubectl get deploy mydeployment -o json | jq '.status'`와 같은
   명령어의 출력을 보여준다.
-- 이 코드는 시도해보기에 적절하지 않다. 예를 들어 
+- 이 코드는 시도해보기에 적절하지 않다. 예를 들어
   특정 [FlexVolume](/docs/concepts/storage/volumes#flexvolume) 구현에 따라
   파드를 만들기 위해 YAML 파일을
   포함할 수 있다.
@@ -126,7 +126,7 @@ YAML 파일과 같은 새로운 독립형 샘플 파일을 추가할 때
 ```
 
 {{< note >}}
-위의 예와 같은 원시 Hugo 단축 코드(shortcode)를 표시하고 Hugo가 
+위의 예와 같은 원시 Hugo 단축 코드(shortcode)를 표시하고 Hugo가
 해석하지 못하게 하려면 `<` 문자 바로 다음과 `>` 문자 앞에 C 스타일 주석을 사용하자.
 그 예로서 이 페이지의 코드를 확인하자.
 {{< /note >}}
@@ -144,7 +144,7 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
 ```
 
 {{< note >}}
-`<LANG>/examples` 디렉토리에 새 YAMl 파일을 추가할 때 파일이 
+`<LANG>/examples` 디렉토리에 새 YAMl 파일을 추가할 때 파일이
 `<LANG>/examples_test.go` 파일에도 포함되어 있는지 확인하자.
 웹 사이트의 Travis CI 는 PR이 제출될 때 이 예제를 자동으로
 실행하여 모든 예제가 테스트를 통과하도록 한다.

content/ko/docs/reference/glossary/annotation.md

@@ -2,7 +2,7 @@
 title: 어노테이션(Annotation)
 id: annotation
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/annotations
+full_link: /ko/docs/concepts/overview/working-with-objects/annotations
 short_description: >
   임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍.
 

content/ko/docs/reference/glossary/controller.md

@@ -2,7 +2,7 @@
 title: 컨트롤러(Controller)
 id: controller
 date: 2018-04-12
-full_link: /docs/concepts/architecture/controller/
+full_link: /ko/docs/concepts/architecture/controller/
 short_description: >
   API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프.
 

content/ko/docs/reference/glossary/cri.md

@@ -2,7 +2,7 @@
 title: 컨테이너 런타임 인터페이스(Container runtime interface, CRI)
 id: cri
 date: 2019-03-07
-full_link: /docs/concepts/overview/components/#container-runtime
+full_link: /ko/docs/concepts/overview/components/#컨테이너-런타임
 short_description: >
   Kubelet과 컨테이너 런타임을 통합시키기 위한 API
 

content/ko/docs/reference/glossary/cronjob.md

@@ -2,7 +2,7 @@
 title: 크론잡(CronJob)
 id: cronjob
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/cron-jobs/
+full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/
 short_description: >
   주기적인 일정에 따라 실행되는 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리.
 

content/ko/docs/reference/glossary/daemonset.md

@@ -2,7 +2,7 @@
 title: 데몬셋(DaemonSet)
 id: daemonset
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/daemonset
+full_link: /ko/docs/concepts/workloads/controllers/daemonset
 short_description: >
   파드의 복제본을 클러스터 노드 집합에서 동작하게 한다.
 

content/ko/docs/reference/glossary/deployment.md

@@ -2,7 +2,7 @@
 title: 디플로이먼트(Deployment)
 id: deployment
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/deployment/
+full_link: /ko/docs/concepts/workloads/controllers/deployment/
 short_description: >
   복제된(replicated) 애플리케이션을 관리하는 API 오브젝트.
 

content/ko/docs/reference/glossary/ingress.md

@@ -2,7 +2,7 @@
 title: 인그레스(Ingress)
 id: ingress
 date: 2018-04-12
-full_link: /docs/concepts/services-networking/ingress/
+full_link: /ko/docs/concepts/services-networking/ingress/
 short_description: >
   클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.
 

content/ko/docs/reference/glossary/label.md

@@ -2,7 +2,7 @@
 title: 레이블(Label)
 id: label
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels
+full_link: /ko/docs/concepts/overview/working-with-objects/labels
 short_description: >
   사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다.
 

content/ko/docs/reference/glossary/minikube.md

@@ -2,7 +2,7 @@
 title: Minikube
 id: minikube
 date: 2018-04-12
-full_link: /docs/setup/learning-environment/minikube/
+full_link: /ko/docs/setup/learning-environment/minikube/
 short_description: >
   로컬에서 쿠버네티스를 실행하기 위한 도구.
 

content/ko/docs/reference/glossary/name.md

@@ -2,7 +2,7 @@
 title: 이름(Name)
 id: name
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /ko/docs/concepts/overview/working-with-objects/names
 short_description: >
   `/api/v1/pods/some-name`과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열.
 

content/ko/docs/reference/glossary/namespace.md

@@ -2,7 +2,7 @@
 title: 네임스페이스(Namespace)
 id: namespace
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/namespaces
+full_link: /ko/docs/concepts/overview/working-with-objects/namespaces
 short_description: >
   쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화.
 

content/ko/docs/reference/glossary/node.md

@@ -2,7 +2,7 @@
 title: 노드(Node)
 id: node
 date: 2018-04-12
-full_link: /docs/concepts/architecture/nodes/
+full_link: /ko/docs/concepts/architecture/nodes/
 short_description: >
   노드는 쿠버네티스의 작업 장비(worker machine)이다.
 

content/ko/docs/reference/glossary/pod.md

@@ -2,7 +2,7 @@
 title: 파드(Pod)
 id: pod
 date: 2018-04-12
-full_link: /docs/concepts/workloads/pods/pod-overview/
+full_link: /ko/docs/concepts/workloads/pods/pod-overview/
 short_description: >
   가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다. 
 

content/ko/docs/reference/glossary/replica-set.md

@@ -2,7 +2,7 @@
 title: 레플리카셋(ReplicaSet)
 id: replica-set
 date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/replicaset/
+full_link: /ko/docs/concepts/workloads/controllers/replicaset/
 short_description: >
   레플리카셋은 지정된 수의 파드 레플리카가 동시에 실행이 되도록 보장한다
 

content/ko/docs/reference/glossary/selector.md

@@ -2,7 +2,7 @@
 title: 셀렉터(Selector)
 id: selector
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels/
+full_link: /ko/docs/concepts/overview/working-with-objects/labels/
 short_description: >
   사용자가 레이블에 따라서 리소스 리스트를 필터할 수 있게 한다.
 

content/ko/docs/reference/glossary/uid.md

@@ -2,7 +2,7 @@
 title: UID
 id: uid
 date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /ko/docs/concepts/overview/working-with-objects/names
 short_description: >
   오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열.
 

content/ko/docs/reference/glossary/workload.md

@@ -2,7 +2,7 @@
 title: 워크로드(Workloads)
 id: workloads
 date: 2019-02-13
-full_link: /docs/concepts/workloads/
+full_link: /ko/docs/concepts/workloads/
 short_description: >
    워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다.
 

content/ko/docs/reference/issues-security/issues.md

@@ -3,7 +3,7 @@ title: 쿠버네티스 이슈 트래커
 weight: 10
 ---
 
-보안 문제를 보고하려면 [쿠버네티스 보안 공개 프로세스](/docs/reference/issues-security/security/#report-a-vulnerability)를 따른다.
+보안 문제를 보고하려면 [쿠버네티스 보안 공개 프로세스](/ko/docs/reference/issues-security/security/#취약점-보고)를 따른다.
 
 쿠버네티스 코드 작업 및 공개 이슈는 [깃허브 이슈](https://github.com/kubernetes/kubernetes/issues/)를 사용하여 추적된다.
 

content/ko/docs/reference/using-api/client-libraries.md

@@ -69,7 +69,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
 | dotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) |
 | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) |
 | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) |
-| Haskell              | [github.com/soundcloud/haskell-kubernetes](https://github.com/soundcloud/haskell-kubernetes) |
+| Haskell              | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) |
 {{% /capture %}}
 
 

content/ko/docs/setup/best-practices/cluster-large.md

@@ -18,71 +18,71 @@ weight: 20
 
 ## 설치
 
-A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane).
+클러스터는 쿠버네티스 에이전트가 구동하는 노드(물리 또는 가상 머신)의 집합이며, "마스터"(클러스터-수준 컨트롤 플레인)에 의해 관리된다.
 
-Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh)).
+보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다.
 
-Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up.
+하지만 단순히 값만 매우 크게 바꾼다면, 클라우드 프로바이더에 따라 셋업 스크립트가 실패할 수도 있다. 예를 들어, GCE에 배포할 때 쿼터 이슈가 발생하여 클러스터 구축이 실패할 수 있다.
 
-When setting up a large Kubernetes cluster, the following issues must be considered.
+큰 쿠버네티스 클러스터를 설정할 때는 다음 이슈들을 고려해야 한다.
 
 ### 쿼터 문제
 
-To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider:
+여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해 고려할 점:
 
-* Increase the quota for things like CPU, IPs, etc.
+* CPU, IP 등의 쿼터를 늘린다.
-  * In [GCE, for example,](https://cloud.google.com/compute/docs/resource-quotas) you'll want to increase the quota for:
+  * 예를 들어, [GCE의 경우](https://cloud.google.com/compute/docs/resource-quotas) 다음에 관한 쿼터를 늘릴 수 있다.
-    * CPUs
+    * CPU
-    * VM instances
+    * VM 인스턴스
-    * Total persistent disk reserved
+    * 전체 영구 디스크 예약
-    * In-use IP addresses
+    * 사용 중인 IP 주소
-    * Firewall Rules
+    * 방화벽 규칙
-    * Forwarding rules
+    * 포워딩 규칙
-    * Routes
+    * 라우트
-    * Target pools
+    * 대상 풀
-* Gating the setup script so that it brings up new node VMs in smaller batches with waits in between, because some cloud providers rate limit the creation of VMs.
+* 일부 클라우드 프로바이더는 VM 생성 속도에 상한이 있어, 셋업 스크립트 수행 간 새로운 노드 VM을 생성하는 사이사이에 대기시간이 추가되는 작은 배치가 걸릴 수 있다.
 
-### Etcd 저장소
+### etcd 저장소
 
-To improve performance of large clusters, we store events in a separate dedicated etcd instance.
+큰 클러스터의 성능 향상을 위해, 우리는 이벤트를 각각의 전용 etcd 인스턴스에 저장한다.
 
-When creating a cluster, existing salt scripts:
+클러스터 생성시의 부가 스트립트이다.
 
-* start and configure additional etcd instance
+* 추가 ectd 인스턴스 시작 및 설정
-* configure api-server to use it for storing events
+* 이벤트를 저장하기 위한 api-server 설정
 
 ### 마스터 크기와 마스터 구성 요소
 
-On GCE/Google Kubernetes Engine, and AWS, `kube-up` automatically configures the proper VM size for your master depending on the number of nodes
+GCE/구글 쿠버네티스 엔진 및 AWS에서, `kube-up`은 클러스터 내 노드의 수에 따라 마스터용으로 적합한 VM 크기를 자동으로 설정한다.
-in your cluster. On other providers, you will need to configure it manually. For reference, the sizes we use on GCE are
+기타 다른 프로바이더의 경우, 수동으로 설정해야 한다. 참고로 GCE에 적용하는 크기는 다음과 같다.
 
-* 1-5 nodes: n1-standard-1
+* 1-5 노드: n1-standard-1
-* 6-10 nodes: n1-standard-2
+* 6-10 노드: n1-standard-2
-* 11-100 nodes: n1-standard-4
+* 11-100 노드: n1-standard-4
-* 101-250 nodes: n1-standard-8
+* 101-250 노드: n1-standard-8
-* 251-500 nodes: n1-standard-16
+* 251-500 노드: n1-standard-16
-* more than 500 nodes: n1-standard-32
+* 500 노드 이상: n1-standard-32
 
-And the sizes we use on AWS are
+AWS에 적용하는 크기는 다음과 같다.
 
-* 1-5 nodes: m3.medium
+* 1-5 노드: m3.medium
-* 6-10 nodes: m3.large
+* 6-10 노드: m3.large
-* 11-100 nodes: m3.xlarge
+* 11-100 노드: m3.xlarge
-* 101-250 nodes: m3.2xlarge
+* 101-250 노드: m3.2xlarge
-* 251-500 nodes: c4.4xlarge
+* 251-500 노드: c4.4xlarge
-* more than 500 nodes: c4.8xlarge
+* 500 노드 이상: c4.8xlarge
 
 {{< note >}}
-On Google Kubernetes Engine, the size of the master node adjusts automatically based on the size of your cluster. For more information, see [this blog post](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html).
+구글 쿠버네티스 엔진에서, 마스터 노드 크기는 클러스터의 크기에 따라 자동적으로 조절된다. 자세한 사항은 [이 블로그 글](https://cloudplatform.googleblog.com/2017/11/Cutting-Cluster-Management-Fees-on-Google-Kubernetes-Engine.html)을 참고하라.
 
-On AWS, master node sizes are currently set at cluster startup time and do not change, even if you later scale your cluster up or down by manually removing or adding nodes or using a cluster autoscaler.
+AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된 그대로이며 변경되지 않는다. 이후에 클러스터를 스케일 업/다운하거나 수동으로 노드를 추가/제거하거나 클러스터 오토스케일러를 사용하더라도 그렇다.
 {{< /note >}}
 
 ### 애드온 자원
 
-To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
+[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](http://pr.k8s.io/10653/files)과 [#10778](http://pr.k8s.io/10778/files) 참고). 
 
-For example:
+예시:
 
 ```yaml
   containers:
@@ -94,35 +94,34 @@ For example:
         memory: 200Mi
 ```
 
-Except for Heapster, these limits are static and are based on data we collected from addons running on 4-node clusters (see [#10335](http://issue.k8s.io/10335#issuecomment-117861225)). The addons consume a lot more resources when running on large deployment clusters (see [#5880](http://issue.k8s.io/5880#issuecomment-113984085)). So, if a large cluster is deployed without adjusting these values, the addons may continuously get killed because they keep hitting the limits.
+힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](http://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](http://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다.
 
-To avoid running into cluster addon resource issues, when creating a cluster with many nodes, consider the following:
+많은 노드를 가진 클러스터를 생성할 때는 애드온 리소스 이슈를 피하기 위해 다음을 고려하라.
 
-* Scale memory and CPU limits for each of the following addons, if used, as you scale up the size of cluster (there is one replica of each handling the entire cluster so memory and CPU usage tends to grow proportionally with size/load on cluster):
+* 다음 애드온을 사용한다면, 클러스터의 크기를 확장할 때 그에 맞게 메모리와 CPU 상한을 규모를 조정하라 (전체 클러스터를 담당하는 각 레플리카는, 메모리와 CPU 사용량이 대체로 클러스터의 크기/부하에 따라 비율적으로 증가할 것이다).
-  * [InfluxDB and Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+  * [InfluxDB와 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
-  * [kubedns, dnsmasq, and sidecar](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+  * [kubedns, dnsmasq, 사이드카](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
   * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
-* Scale number of replicas for the following addons, if used, along with the size of cluster (there are multiple replicas of each so increasing replicas should help handle increased load, but, since load per replica also increases slightly, also consider increasing CPU/memory limits):
+* 다음 애드온들을 쓴다면 클러스터 크기에 따라 레플리카 수를 조절해준다(각각 레플리카가 여러 개 두면 늘어나는 부하를 처리하는 데 도움이 되지만, 레플리카 당 부하도 약간 늘어나게 되므로 CPU/메모리 상한을 높이는 것을 고려해보자):
   * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
-* Increase memory and CPU limits slightly for each of the following addons, if used, along with the size of cluster (there is one replica per node but CPU/memory usage increases slightly along with cluster load/size as well):
+* 다음의 애드온들을 쓴다면, 클러스터 크기에 따라 각각 메모리와 CPU 상한을 조금 더 높이자(노드 당 레플리카 1개만 있어도 클러스터 부하량/크기에 따라 CPU/메모리 사용율은 조금씩 증가한다).
-  * [FluentD with ElasticSearch Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+  * [ElasticSearch 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
-  * [FluentD with GCP Plugin](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+  * [GCP 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
 
-Heapster's resource limits are set dynamically based on the initial size of your cluster (see [#16185](http://issue.k8s.io/16185)
+힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](http://issue.k8s.io/16185)과
-and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
+[#22940](http://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면, 
-out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
+ 힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자.
 
-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
+애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting)을 참고하라.
 
-In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
+[미래](http://issue.k8s.io/13048)에는 모든 클러스터 애드온의 리소스 상한을 클러스터 크기에 맞게 설정해주고 클러스터를 키우거나 줄일 때 동적으로 조절해줄 수 있기를 기대한다.
-We welcome PRs that implement those features.
+이런 기능들에 대한 PR은 언제든 환영한다.
 
 ### 시작 시 사소한 노드 오류 허용
 
-For various reasons (see [#18969](https://github.com/kubernetes/kubernetes/issues/18969) for more details) running
+다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고 
-`kube-up.sh` with a very large `NUM_NODES` may fail due to a very small number of nodes not coming up properly.
+`kube-up.sh`을 실행하면 제대로 기동되지 않은 극소수의 노드들 때문에 실패할 수 있다.
-Currently you have two choices: restart the cluster (`kube-down.sh` and then `kube-up.sh` again), or before
+현재로서는 두 가지 선택지가 있다. 클러스터를 재시작하거나(`kube-down.sh` 한 후 다시 `kube-up.sh` ),
-running `kube-up.sh` set the environment variable `ALLOWED_NOTREADY_NODES` to whatever value you feel comfortable
+`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다. 
-with. This will allow `kube-up.sh` to succeed with fewer than `NUM_NODES` coming up. Depending on the
+이렇게 하면 `NUM_NODES`에 못 미치는 경우에도 `kube-up.sh`이 성공할 수 있다.
-reason for the failure, those additional nodes may join later or the cluster may remain at a size of
+실패 원인에 따라 일부 노드들이 늦게 결합되거나, 클러스터가 `NUM_NODES - ALLOWED_NOTREADY_NODES`의 크기로 남을 수 있다.
-`NUM_NODES - ALLOWED_NOTREADY_NODES`.

content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md

@@ -96,7 +96,7 @@ spec:
     * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
     * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며).
     * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 보여지는)로 실행한다.
-    * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/docs/concepts/services-networking/dns-pod-service/#services)와 서비스 이름으로 `curl`을 실행한다.
+    * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
     * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
     * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
 

content/ko/docs/tasks/access-application-cluster/access-cluster.md

@@ -20,7 +20,7 @@ content_template: templates/concept
 
 클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 
 인증정보를 가져야 한다. 일반적으로 이는 당신이 
-[Getting started guide](/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, 
+[Getting started guide](/ko/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, 
 다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다.
 
 kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다.
@@ -29,7 +29,7 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확
 kubectl config view
 ```
 
-많은 [예제들](/docs/user-guide/kubectl-cheatsheet)에서 kubectl을 사용하는 것을 소개하고 있으며 
+많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 kubectl을 사용하는 것을 소개하고 있으며 
 완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다.
 
 ## REST API에 직접 액세스
@@ -219,7 +219,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다.
 
 이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 
 쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 
-[노드들](/docs/admin/node), [파드들](/docs/user-guide/pods), [서비스들](/docs/user-guide/services)은 
+[노드들](/ko/docs/concepts/architecture/nodes/), [파드들](/ko/docs/concepts/workloads/pods/pod/), [서비스들](/docs/user-guide/services)은 
 모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 
 클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 
 할 수 없을 것이다.

content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md

@@ -26,7 +26,7 @@ card:
 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다.
 
 ```
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta6/aio/deploy/recommended.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
 ```
 
 ## 대시보드 UI 접근
@@ -69,15 +69,15 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
 배포 마법사는 다음 정보를 제공한다.
 
-- **앱 이름** (필수): 애플리케이션 이름. [레이블](/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다.
+- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다.
 
   애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
 
-- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다.
+- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/ko/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다.
 
 - **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다.
 
-  클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
+  클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
 
 - **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
 
@@ -87,9 +87,9 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509
 
 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
 
-- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
+- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
 
-- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
+- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
 
   예를 들면:
 

content/ko/docs/tasks/administer-cluster/cluster-management.md

@@ -17,7 +17,7 @@ content_template: templates/concept
 
 ## 클러스터 생성과 설정
 
-일련의 머신들에 쿠버네티스를 설치하려면, 환경에 맞게 기존의 [시작하기](/docs/setup/) 안내서들 중에 하나를 선택하여 참조한다.
+일련의 머신들에 쿠버네티스를 설치하려면, 환경에 맞게 기존의 [시작하기](/ko/docs/setup/) 안내서들 중에 하나를 선택하여 참조한다.
 
 ## 클러스터 업그레이드
 
@@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레
 
 ## 클러스터 크기 재조정
 
-[노드 자가 등록 모드](/docs/concepts/architecture/nodes/#self-registration-of-nodes)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. 
+[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. 
 [Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.
 
 ```shell
@@ -181,7 +181,7 @@ kubectl uncordon $NODENAME
 
 해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 
 자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; 
-이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/docs/concepts/architecture/nodes)를 참조하라.
+이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.
 
 ## 고급 주제들
 

content/ko/docs/tasks/administer-cluster/highly-available-master.md

@@ -106,7 +106,7 @@ HA 클러스터의 마스터 복제본 중 하나가 실패하면,
 
 * 다른 존에 마스터 복제본을 배치하도록 한다. 한 존이 실패하는 동안, 해당 존에 있는 마스터도 모두 실패할 것이다.
 존 장애를 극복하기 위해 노드를 여러 존에 배치한다
-(더 자세한 내용은 [멀티 존](/docs/setup/best-practices/multiple-zones/)를 참조한다).
+(더 자세한 내용은 [멀티 존](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다).
 
 * 두 개의 마스터 복제본은 사용하지 않는다. 두 개의 복제 클러스터에 대한 합의는 지속적 상태를 변경해야 할 때 두 복제본 모두 실행해야 한다.
 결과적으로 두 복제본 모두 필요하고, 어떤 복제본의 장애에도 클러스터가 대부분 장애 상태로 변한다.

content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md

@@ -26,7 +26,7 @@ title: 리소스 모니터링 도구
 ## 리소스 메트릭 파이프라인
 
 리소스 메트릭 파이프라인은 
-[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale)
+[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale)
 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는
 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인
 [metrics-server](https://github.com/kubernetes-incubator/metrics-server)에

content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -10,7 +10,7 @@ Horizontal Pod Autoscaler는
 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
 레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다.
 
-이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
+이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.
 
 {{% /capture %}}
 
@@ -28,7 +28,7 @@ Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하
 또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다.
 마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우,
 버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다.
-자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)를 참고하길 바란다.
+자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다.
 
 {{% /capture %}}
 

content/ko/docs/tutorials/hello-minikube.md

@@ -15,7 +15,7 @@ card:
 
 {{% capture overview %}}
 
-이 튜토리얼에서는 [Minikube](/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 
+이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 
 쿠버네티스에서 Node.js 로 작성된 간단한 Hello World 애플리케이션을 어떻게 실행하는지 살펴본다.
 Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
 
@@ -87,9 +87,9 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
     kubectl get deployments
     ```
 
-    출력:
+    다음과 유사하게 출력된다.
 
-    ```shell
+    ```
     NAME         READY   UP-TO-DATE   AVAILABLE   AGE
     hello-node   1/1     1            1           1m
     ```
@@ -99,9 +99,9 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
     ```shell
     kubectl get pods
     ```
-    출력:
+    다음과 유사하게 출력된다.
 
-    ```shell
+    ```
     NAME                          READY     STATUS    RESTARTS   AGE
     hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
     ```
@@ -142,9 +142,9 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
     kubectl get services
     ```
 
-    출력:
+    다음과 유사하게 출력된다.
 
-    ```shell
+    ```
     NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
     hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
     kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m
@@ -163,7 +163,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
 
 4. Katacoda 환경에서만: 플러스를 클릭한 후에 **Select port to view on Host 1** 를 클릭.
 
-5. Katacoda 환경에서만: 서비스 출력에서 `8080`의 반대편에 표시되는 5자리 포트 번호를 기록 한다. 이 포트 번호는 무작위로 생성되며, 사용자마다 다를 수 있다. 포트 번호 텍스트 상자에 `30369` 를 입력한 다음, 포트 표시를 클릭한다.
+5. Katacoda 환경에서만: 서비스 출력에서 `8080`의 반대편에 표시되는 5자리 포트 번호를 기록 한다. 이 포트 번호는 무작위로 생성되며, 사용자마다 다를 수 있다. 포트 번호 텍스트 상자에 포트 번호를 입력한 다음, 포트 표시를 클릭한다. 이전 예시를 사용해서 `30369` 를 입력한다.
 
     이렇게 하면 당신의 앱을 서비스하는 브라우저 윈도우를 띄우고 "Hello World" 메시지를 보여준다.
 
@@ -177,24 +177,27 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
     minikube addons list
     ```
 
-    출력:
+    다음과 유사하게 출력된다.
 
-    ```shell
+    ```
     addon-manager: enabled
-    coredns: disabled
     dashboard: enabled
     default-storageclass: enabled
     efk: disabled
     freshpod: disabled
+    gvisor: disabled
     heapster: disabled
+    helm-tiller: disabled
     ingress: disabled
-    kube-dns: enabled
+    ingress-dns: disabled
+    logviewer: disabled
     metrics-server: disabled
     nvidia-driver-installer: disabled
     nvidia-gpu-device-plugin: disabled
     registry: disabled
     registry-creds: disabled
     storage-provisioner: enabled
+    storage-provisioner-gluster: disabled
     ```
    
 2. 한 애드온을 활성화 한다. 예를 들어 `heapster`
@@ -203,9 +206,9 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
     minikube addons enable heapster
     ```
   
-    출력:
+    다음과 유사하게 출력된다.
 
-    ```shell
+    ```
     heapster was successfully enabled
     ```
 
@@ -215,21 +218,25 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
     kubectl get pod,svc -n kube-system
     ```
 
-    출력:
+    다음과 유사하게 출력된다.
 
     ```shell
     NAME                                        READY     STATUS    RESTARTS   AGE
+    pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
+    pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
     pod/heapster-9jttx                          1/1       Running   0          26s
+    pod/etcd-minikube                           1/1       Running   0          34m
     pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
     pod/kube-addon-manager-minikube             1/1       Running   0          34m
-    pod/kube-dns-6dcb57bcc8-gv7mw               3/3       Running   0          34m
+    pod/kube-apiserver-minikube                 1/1       Running   0          34m
-    pod/kubernetes-dashboard-5498ccf677-cgspw   1/1       Running   0          34m
+    pod/kube-controller-manager-minikube        1/1       Running   0          34m
+    pod/kube-proxy-rnlps                        1/1       Running   0          34m
+    pod/kube-scheduler-minikube                 1/1       Running   0          34m
     pod/storage-provisioner                     1/1       Running   0          34m
 
     NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
     service/heapster               ClusterIP   10.96.241.45    <none>        80/TCP              26s
     service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
-    service/kubernetes-dashboard   NodePort    10.109.29.1     <none>        80:30000/TCP        34m
     service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
     service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
     ```
@@ -240,9 +247,9 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네
     minikube addons disable heapster
     ```
   
-    출력:
+    다음과 유사하게 출력된다.
 
-    ```shell
+    ```
     heapster was successfully disabled
     ```
 

content/ko/docs/tutorials/services/source-ip.md

@@ -346,7 +346,7 @@ $ kubectl delete deployment source-ip-app
 {{% /capture %}}
 
 {{% capture whatsnext %}}
-* [서비스를 통한 애플리케이션 연결하기](/docs/concepts/services-networking/connect-applications-service/)에 대해 더 공부하기
+* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 공부하기
 * [부하분산](/docs/user-guide/load-balancer)에 대해 더 공부하기
 {{% /capture %}}
 

content/ko/docs/tutorials/stateful-application/basic-stateful-set.md

@@ -6,7 +6,7 @@ weight: 10
 ---
 
 {{% capture overview %}}
-이 튜토리얼은 스테이트풀셋([StatefulSets](/docs/concepts/workloads/controllers/statefulset/))을 이용하여
+이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여
 애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며
 스케일링하고 업데이트하는지 시연한다.
 {{% /capture %}}
@@ -16,11 +16,11 @@ weight: 10
 익숙해야 한다.
 
 * [파드](/docs/user-guide/pods/single-container/)
-* [클러스터 DNS(Cluster DNS)](/docs/concepts/services-networking/dns-pod-service/)
+* [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/)
 * [헤드리스 서비스(Headless Services)](/docs/concepts/services-networking/service/#headless-services)
 * [퍼시스턴트볼륨(PersistentVolumes)](/docs/concepts/storage/persistent-volumes/)
 * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
-* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)
+* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
 * [kubectl CLI](/docs/user-guide/kubectl/)
 
 이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록
@@ -49,7 +49,7 @@ weight: 10
 ## 스테이트풀셋 생성하기
 
 아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는
-[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인
+[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인
 예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는
 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인
 `nginx` 를 생성한다.
@@ -110,7 +110,7 @@ web-1     0/1       ContainerCreating   0         0s
 web-1     1/1       Running   0         18s
 ```
 
-`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/docs/user-guide/pod-states) 상태가 되기 전에
+`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에
 시작하지 않음을 주의하자.
 
 ## 스테이트풀셋 안에 파드
@@ -129,7 +129,7 @@ web-1     1/1       Running   0          1m
 
 ```
 
-[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서
+[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서
 언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다.
 이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는
 고유한 순번에 기인한다. 파드의 이름의 형식은
@@ -377,7 +377,7 @@ web-4     1/1       Running   0         19s
 ```
 
 스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다.
-[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는
+[스테이트풀셋 생성](#차례대로-파드-생성하기)으로 스테이트풀셋 컨트롤러는
 각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에
 이전 파드가 Running과 Ready 상태가 될 때까지
 기다린다.
@@ -656,7 +656,7 @@ k8s.gcr.io/nginx-slim:0.8
 종료되어 원래 환경설정으로 복원된다.
 
 #### 단계적 롤아웃
-[카나리 롤아웃](#rolling-out-a-canary)에서 했던 방법과 비슷하게
+[카나리 롤아웃](#카나리-canary-롤링-아웃)에서 했던 방법과 비슷하게
 분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을
 수행할 수 있다. 단계적 롤아웃을 수행하려면
 컨트롤러가 업데이트를 일시 중지할 순번으로

content/ko/docs/tutorials/stateful-application/cassandra.md

@@ -8,7 +8,7 @@ weight: 30
 {{% capture overview %}}
 이 튜토리얼은 네이티브 클라우드 [카산드라](http://cassandra.apache.org/)를 쿠버네티스에서 배포하는 방법을 소개한다. 이 예제에서 커스텀 카산드라 *시드 제공자(SeedProvider)* 는 카산드라가 클러스터에 조인한 새 카산드라 노드를 발견할 수 있게 한다.
 
-*스테이트풀셋* 은 상태있는 애플리케이션을 클러스터 환경에서 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [*스테이트풀셋*](/docs/concepts/workloads/controllers/statefulset/) 문서를 참조하자.
+*스테이트풀셋* 은 상태있는 애플리케이션을 클러스터 환경에서 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [*스테이트풀셋*](/ko/docs/concepts/workloads/controllers/statefulset/) 문서를 참조하자.
 
 **도커에서 카산드라**
 
@@ -30,14 +30,14 @@ weight: 30
 
 {{% capture objectives %}}
 * 카산드라 헤드리스 [*서비스*](/docs/concepts/services-networking/service/)를 생성하고 검증한다.
-* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다.
+* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다.
-* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 검증한다.
+* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 검증한다.
-* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 수정한다.
+* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 수정한다.
-* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과 포함된 [파드](/docs/concepts/workloads/pods/pod/)를 삭제한다.
+* [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 포함된 [파드](/ko/docs/concepts/workloads/pods/pod/)를 삭제한다.
 {{% /capture %}}
 
 {{% capture prerequisites %}}
-이 튜토리얼을 완료하려면, [파드](/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로
+이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로
 
 * *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자.
 
@@ -47,7 +47,7 @@ weight: 30
 * 실행 중인 쿠버네티스 클러스터를 소유
 
 {{< note >}}
-아직 클러스터가 없다면 [설치](/docs/setup/)를 읽도록 하자.
+아직 클러스터가 없다면 [설치](/ko/docs/setup/)를 읽도록 하자.
 {{< /note >}}
 
 ### 추가적인 Minikube 설정 요령
@@ -65,7 +65,7 @@ minikube start --memory 5120 --cpus=4
 {{% capture lessoncontent %}}
 ## 카산드라 헤드리스 서비스 생성하기
 
-쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/docs/concepts/workloads/pods/pod/)의 집합을 기술한다.
+쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다.
 
 다음의 `서비스`는 쿠버네티스 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다.
 

content/ko/docs/tutorials/stateful-application/zookeeper.md

@@ -17,12 +17,12 @@ weight: 40
 다음 쿠버네티스 개념에 친숙해야 한다.
 
 -   [파드](/docs/user-guide/pods/single-container/)
--   [클러스터 DNS](/docs/concepts/services-networking/dns-pod-service/)
+-   [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
 -   [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)
 -   [퍼시스턴트볼륨](/docs/concepts/storage/volumes/)
 -   [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
--   [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)
+-   [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
--   [파드디스룹션버짓](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)
+-   [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)
 -   [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)
 -   [kubectl CLI](/docs/user-guide/kubectl/)
 
@@ -64,8 +64,8 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변
 아래 메니페스트에는
 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services),
 [서비스](/docs/concepts/services-networking/service/),
-[파드디스룹션버짓](/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget),
+[파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget),
-[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 포함한다.
+[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다.
 
 {{< codenew file="application/zookeeper/zookeeper.yaml" >}}
 
@@ -173,7 +173,7 @@ zk-1.zk-hs.default.svc.cluster.local
 zk-2.zk-hs.default.svc.cluster.local
 ```
 
-[쿠버네티스 DNS](/docs/concepts/services-networking/dns-pod-service/)의 A 레코드는 FQDN을 파드의 IP 주소로 풀어낸다. 쿠버네티스가 파드를 리스케줄하면, 파드의 새 IP 주소로 A 레코드를 갱신하지만, A 레코드의 이름은 바뀌지 않는다.
+[쿠버네티스 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)의 A 레코드는 FQDN을 파드의 IP 주소로 풀어낸다. 쿠버네티스가 파드를 리스케줄하면, 파드의 새 IP 주소로 A 레코드를 갱신하지만, A 레코드의 이름은 바뀌지 않는다.
 
 ZooKeeper는 그것의 애플리케이션 환경설정을 `zoo.cfg` 파일에 저장한다. `kubectl exec`를 이용하여 `zk-0` 파드의 `zoo.cfg` 내용을 보자.
 
@@ -366,7 +366,7 @@ zk-2      0/1       Running   0         19s
 zk-2      1/1       Running   0         40s
 ```
 
-아래 명령어로 [무결성 테스트](#sanity-testing-the-ensemble)에서 입력한 값을
+아래 명령어로 [무결성 테스트](#앙상블-무결성-테스트)에서 입력한 값을
 `zk-2` 파드에서 얻어온다.
 
 ```shell
@@ -443,8 +443,8 @@ ZooKeeper의 서버 디렉터리에 마운트한다.
 
 ## 일관된 구성 보장하기
 
-[리더 선출 촉진](#facilitating-leader-election)과
+[리더 선출 촉진](#리더-선출-촉진)과
-[합의 달성](#achieving-consensus) 섹션에서 알렸듯이,
+[합의 달성](#합의-달성) 섹션에서 알렸듯이,
 ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한 일관된 설정이 필요하다.
 또한 Zab 프로토콜의 일관된 설정도 
 네트워크에 걸쳐 올바르게 동작하기 위해서
@@ -655,7 +655,7 @@ statefulset.apps/zk rolled back
 
 ### 프로세스 장애 관리하기
 
-[재시작 정책](/docs/user-guide/pod-states/#restartpolicy)은
+[재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)은
 쿠버네티스가 파드 내에 컨테이너의 진입점에서 프로세스 실패를 어떻게 다루는지 제어한다.
 `스테이트풀셋`의 파드에서 오직 적절한 `재시작 정책`는 Always이며
 이것이 기본 값이다. 상태가 유지되는 애플리케이션을 위해

content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md

@@ -50,11 +50,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
 
 
 위의 명령어는
-    [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)
+    [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
     오브젝트와 관련된
-    [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/)
+    [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)
     오브젝트를 생성한다. 레플리카 셋은 다섯 개의
-    [파드](/docs/concepts/workloads/pods/pod/)가 있으며,
+    [파드](/ko/docs/concepts/workloads/pods/pod/)가 있으며,
     각 파드는 Hello World 애플리케이션을 실행한다.
 
 1. 디플로이먼트에 대한 정보를 확인한다.
@@ -158,6 +158,6 @@ Hello World 애플리케이션을 실행 중인 디플로이먼트, 레플리카
 
 {{% capture whatsnext %}}
 
-[애플리케이션과 서비스 연결하기](/docs/concepts/services-networking/connect-applications-service/)에 대해
+[애플리케이션과 서비스 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해
 더 배워 본다.
 {{% /capture %}}

content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md

@@ -394,8 +394,8 @@ deployment.extensions/frontend scaled
 {{% /capture %}}
 
 {{% capture whatsnext %}}
-* [리소스 모니터링 도구](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다.
+* [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다.
-* [로깅 아키텍처](/docs/concepts/클러스터-administration/logging/)를 더 읽어본다.
+* [로깅 아키텍처](/docs/concepts/cluster-administration/logging/)를 더 읽어본다.
-* [애플리케이션 검사 및 디버깅](/docs/tasks/debug-application-cluster/)을 더 읽어본다.
+* [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다.
-* [애플리케이션 문제 해결](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다.
+* [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다.
 {{% /capture %}}

content/ko/docs/tutorials/stateless-application/guestbook.md

@@ -362,7 +362,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
 * [ELK 로깅과 모니터링](/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)을 방명록 애플리케이션에 추가하기
 * [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료
 * [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기
-* [애플리케이션 접속](/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기
+* [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기
 * [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아보기
 {{% /capture %}}
 

content/ko/examples/service/networking/dual-stack-default-svc.yaml

@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376

content/ko/examples/service/networking/dual-stack-ipv4-svc.yaml

@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  ipFamily: IPv4
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376

content/ko/examples/service/networking/dual-stack-ipv6-svc.yaml

@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-service
+spec:
+  ipFamily: IPv6
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376

content/ko/examples/service/networking/hostaliases-pod.yaml

@@ -0,0 +1,22 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: hostaliases-pod
+spec:
+  restartPolicy: Never
+  hostAliases:
+  - ip: "127.0.0.1"
+    hostnames:
+    - "foo.local"
+    - "bar.local"
+  - ip: "10.1.2.3"
+    hostnames:
+    - "foo.remote"
+    - "bar.remote"
+  containers:
+  - name: cat-hosts
+    image: busybox
+    command:
+    - cat
+    args:
+    - "/etc/hosts"