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)와 쿠버네티스 클러스터 사이의 커뮤니케이션 경로를 나열해 본다.
-그 목적은 사용자로 하여금 untrusted network(신뢰할 수 없는 네트워크) 상에서
-(또는 클라우드 제공사업자 환경에서 완전히 공인 IP로) 동작될 수 있는
-그러한 클러스터의 네트워크 구성을 강화하기 위해 사용자의 설치를 커스터마이즈 할 수 있도록 해주기 위함이다.
+이 문서는 마스터(실제 apiserver)와 쿠버네티스 클러스터 사이의
+커뮤니케이션 경로를 나열해 본다. 그 목적은 신뢰할 수 없는 네트워크
+(또는 클라우드 제공자의 공인 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의 제공 인증서 확인을 위해 사용하는
-루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다
+이 연결을 확인하려면, apiserver에 kubelet의 제공 인증서 확인을
+위해 사용하는 루트 인증서 번들로 `--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,15 +141,15 @@ 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 이미지를 안전하게 저장하고 공유할 수 있도록 한다. 기본적으로, 
 프라이빗 레지스트리의 이미지는 통합된 취약점 조언기(Vulnerability Advisor)를 통해 조사되어 보안 이슈와 잠재적 취약성을 검출한다. 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 %}}