Second Korean l10n work for release 1.18

* Translate /concepts/cluster-administration/kubelet-garbage-collection in Korean (#20274) * Translate cluster-administration/logging.md in Korean (#20409) * Translate tasks/configure-pod-container/assign-memory-resource.md in … (#20167) * Translate community/_index.html in Korean. (#20317) * Translate storage/storage-classes.md in Korean. (#20310) * Translate configuration/resource-bin-packing.md in Korean. (#20276) * Translate extend-kubernetes/compute-storage-net/device-plugins.md (#20406) * Translate compute-storage-net/network-plugins.md in Korean (#20407) * Translate concepts/cluster-administration/certificates.md (#20330) * Translate assign-pods-nodes-using-node-affinity to Korean (#20307) * Translate cluster-administration/manage-deployment.md in Korean (#20366) * Translate configuration/taint-and-toleration.md in Korean (#20404) * Translate logging-elasticsearch-kibana.md in Korean (#20300) * add anchors of subtitle in ko/docs/concepts/policy/pod-security-policy (#20399) * Translate task/scheduling-gpus in Korean (#20212) * Translate conceps/storage/volume-snapshots in Korean (#19955) * Translate network/validate-dual-stack.md in Korean (#20271) * Update to Outdated files in the dev-1.18-ko.2 branch. (#20244) * Update to a link to the newly translated document. (#20247) Co-Authored-By: bluefriday <bluefriday86@gmail.com> Co-Authored-By: cometrojan <d.gweon@samsung.com> Co-Authored-By: coolguyhong <podolsmith@naver.com> Co-Authored-By: DongMoon Kim <dmoons.kim@gmail.com> Co-Authored-By: Jerry Park <jaehwa@gmail.com> Co-Authored-By: jmyung <jesang.myung@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-Authored-By: seokho-son <shsongist@gmail.com> Co-Authored-By: sunminjeon <sunmin.jeon@samsung.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
2020-04-24 00:07:32 +09:00
parent dc3ce88f55
commit c74ce882ec
76 changed files with 4892 additions and 614 deletions
@@ -113,17 +113,15 @@ weight: 30
 디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 
 관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프
 (컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 
-만들기 위해 다른 종류의 리소스를 관리한다.
+만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는
+잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 
+확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
+잡은 다른 컨트롤러가 생성한다.

 컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, 
 간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 
 허용하도록 디자인되었다.

-예를 들어, 잡용 컨트롤러는 잡 오브젝트(새 작업을 
-발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 
-확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
-잡은 다른 컨트롤러가 생성한다.
-
 {{< note >}}
 동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다.
 이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에 
@@ -158,5 +156,5 @@ weight: 30
 * [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기
 * [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자.
 * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
-* 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)을 본다.
+* 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다.
 {{% /capture %}}
@@ -93,13 +93,28 @@ HTTPS 엔드포인트에 의해 제공되는 인증서를 확인하지 않으며

 ### SSH 터널

-쿠버네티스는 마스터 -> 클러스터 통신 경로를 보호하는 SSH 터널을
+쿠버네티스는 마스터 → 클러스터 통신 경로를 보호하는 SSH 터널을
 지원한다. 이 구성에서 apiserver는 클러스터의 각 노드에서 SSH 터널을
 시작하고(포트 22번으로 수신 대기하는 ssh 서버에 연결), 터널을 통해
 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
 이 터널은 실행중인 노드의 트래픽이 외부로 노출되지
 않도록 보장한다.

-SSH 터널은 현재 사용 중단(deprecated)되었으므로, 무엇을 하고 있는지 알지 못하는 한 터널을 이용하지 말아야 한다. 이 통신 채널의 대체물을 설계 중이다.
+SSH 터널은 현재 사용 중단(deprecated)되었으므로, 무엇을 하고 있는지 알지 못하는
+한 터널을 이용하지 말아야 한다. Konnectivity 서비스는 이 통신
+채널을 대체한다.
+
+### Konnectivity 서비스
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+SSH 터널을 대체하는 Konnectivity 서비스는 마스터 → 클러스터 통신을
+위한 TCP 수준의 프록시를 제공한다. Konnectivity는 마스터
+네트워크와 클러스터 네트워크에서 실행되는 Konnectivity 서버와 
+에이전트 두 부분으로 구성된다. Konnectivity 에이전트는
+Konnectivity 서버에 대한 연결을 시작하고, 유지한다.
+이 연결을 통해 모든 마스터 → 클러스터로의 트래픽이 통과하게 된다.
+
+클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 구성](/docs/tasks/setup-konnectivity/)
+하기를 참고한다.

 {{% /capture %}}
@@ -69,7 +69,7 @@ kubectl describe node <insert-node-name-here>
 ]
 ```

-ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controller-manager/)에 인수로 넘겨지는 `pod-eviction-timeout` 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
+ready 컨디션의 상태가 `pod-eviction-timeout` ([kube-controller-manager](/docs/admin/kube-controller-manager/)에 전달된 인수) 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.

 1.5 이전의 쿠버네티스 버전에서는, 노드 컨트롤러가 apiserver로부터 접근 불가한 이러한 파드를 [강제 삭제](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제)
 시킬 것이다. 그러나 1.5 이상에서는, 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 
@@ -80,8 +80,8 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll

 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
 [테인트(taints)](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
-스케줄러가 파드를 노드에 할당할 때, 스케줄러는 파드가 극복(tolerate)하는 테인트가
-아닌 한, 노드 계정의 테인트를 고려 한다.
+스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
+또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다.

 ### 용량과 할당가능 {#capacity}