First Korean L10n Work For Relase 1.17

* Modified link between Korean documents. (#18072)
* Translate services-networking/connect-applications-service.md in Korean. (#18087)
* Translate services-networking/service-topology.md in Korean. (#18096)
* Update to outdated files in the dev-1.17-ko.1 (#18070)

Co-Authored-By: Yuk, Yongsu <[email protected]>
Co-Authored-By: Seokho Son <[email protected]>

content/ko/_index.html

@@ -45,12 +45,12 @@ <h2>150+ 마이크로서비스를 쿠버네티스로 마이그레이션하는 
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019" button id="desktopKCButton">Attend KubeCon in San Diego on Nov. 18-21, 2019</a>
+        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/" button id="desktopKCButton">Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020</a>
+        <a href="https://events.linuxfoundation.cn/kubecon-cloudnativecon-open-source-summit-china/" button id="desktopKCButton">Attend KubeCon in Shanghai on July 28-30, 2020</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/ko/docs/concepts/architecture/cloud-controller.md

@@ -52,7 +52,7 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시
 볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
 {{< /note >}}
 
-CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 Flex 볼륨을 사용하기 위한 것이었다. 그러나, CSI라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
+CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
 
 이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다.
 

content/ko/docs/concepts/architecture/nodes.md

@@ -78,19 +78,10 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 
 노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
 
-1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
-[taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
-마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다. 
-대신 노드의 taint와 toleration을 살펴본다.
-
-현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다. 
-아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의 
-taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다.
-
-{{< caution >}}
-이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 
-시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
-{{< /caution >}}
+노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
+[테인트(taints)](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
+스케줄러가 파드를 노드에 할당할 때, 스케줄러는 파드가 극복(tolerate)하는 테인트가
+아닌 한, 노드 계정의 테인트를 고려 한다.
 
 ### 용량과 할당가능 {#capacity}
 
@@ -169,18 +160,28 @@ NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는
 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
 
-쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가
-된다. node lease 기능은 1.14 부터 기본값으로 활성화 되었으며, 베타 기능이다 
-(기능 게이트 `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). 
-node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해 
-갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고 
-NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다. 
-NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만 
-(기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.) 
-노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다. 
-노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과
-성능 두 가지 측면에서 노드 하트비트를 상당히 
-경제적이도록 해준다.
+#### 하트비트
+
+쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다.
+하트비트의 두 가지 형태는 `NodeStatus` 와
+[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io) 이다.
+각 노드에는 `kube-node-lease` 라는
+{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다.
+리스는 경량 리소스로, 클러스터가 확장될 때
+노드의 하트비트 성능을 향상 시킨다.
+
+kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
+의무가 있다.
+
+- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
+  `NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트
+  주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초
+  보다 훨씬 길다).
+- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
+  리스 업데이트는 `NodeStatus` 업데이트와는
+  독립적으로 발생한다.
+
+#### 안정성
 
 쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에 
 문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) 

content/ko/docs/concepts/overview/what-is-kubernetes.md

@@ -64,7 +64,7 @@ card:
 * **자동화된 복구(self-healing)**
 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
 * **시크릿과 구성 관리**
-쿠버네티스를 사용하면 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
+쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
 
 ## 쿠버네티스가 아닌 것
 
@@ -74,9 +74,9 @@ card:
 
 * 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
 * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
-* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
+* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
 * 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
-* 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
+* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
 * 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
 * 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.