Seventh Korean L10n Work for Release 1.16 (#18494)

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

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

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

content/ko/docs/concepts/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와 소통한다.
 
@@ -68,7 +73,7 @@ apiserver는 kubelet의 제공 인증서를 확인하지 않는데,
 루트 인증서 번들로 `--kubelet-certificate-authority` 플래그를 이용한다
 
 그것이 불가능한 경우, 신뢰할 수 없는 또는 공인 네트워크에 대한 연결을 피하고 싶다면,
-apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)을
+apiserver와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/master-node-communication/#SSH-터널)을
 사용한다.
 
 마지막으로, kubelet API를 안전하게 하기 위해
@@ -77,12 +82,24 @@ apiserver와 kubelet 사이에 [SSH 터널링](/docs/concepts/architecture/maste
 ### apiserver에서 노드, 파드, 그리고 서비스로
 
 apiserver에서 노드, 파드, 또는 서비스로의 연결은 보통 HTTP 연결을
-기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드, 파드, 또는 서비스 이름에
-`https:` 프리픽스를 붙임으로써 안전한 HTTPS 연결로 동작될 수 있지만,
-HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며
-클라이언트 자격증명 또한 제공하지 않는다.
+기본으로 하므로 인증도 암호화도 되지 않는다. API URL 내 노드,
+파드, 또는 서비스 이름에 `https:` 프리픽스를 붙임으로써 안전한 HTTPS
+연결로 동작될 수 있지만, HTTPS 엔드포인트에 의해 제공되는
+인증서를 확인하지 않으며 클라이언트 자격증명 또한 제공하지 않는다.
 그래서 연결이 암호화될 동안, 어떠한 무결성도 제공되지 않을 것이다.
-이러한 연결들은 신뢰할 수 없는 그리고/또는 공인 네트워크에서 동작하기에
+이러한 연결들은 신뢰할 수 없는 그리고/또는 공인
+네트워크에서 동작하기에
 **현재로서는 안전하지 않다**.
 
+### SSH 터널
+
+쿠버네티스는 마스터 -> 클러스터 통신 경로를 보호하는 SSH 터널을
+지원한다. 이 구성에서 apiserver는 클러스터의 각 노드에서 SSH 터널을
+시작하고(포트 22번으로 수신 대기하는 ssh 서버에 연결), 터널을 통해
+kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
+이 터널은 실행중인 노드의 트래픽이 외부로 노출되지
+않도록 보장한다.
+
+SSH 터널은 현재 사용 중단(deprecated)되었으므로, 무엇을 하고 있는지 알지 못하는 한 터널을 이용하지 말아야 한다. 이 통신 채널의 대체물을 설계 중이다.
+
 {{% /capture %}}