Merge pull request #23814 from gochist/dev-1.19-ko.1

First Korean l10n work for release-1.19

Author: k8s-ci-robot

content/ko/_index.html

@@ -41,11 +41,6 @@ <h2>150+ 마이크로서비스를 쿠버네티스로 마이그레이션하는 
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Attend KubeCon EU virtually on August 17-20, 2020</a>
-        <br>
-        <br>
-        <br>
-        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Attend KubeCon NA virtually on November 17-20, 2020</a>
 </div>
 <div id="videoPlayer">

content/ko/docs/_index.md

@@ -1,3 +1,4 @@
 ---
+linktitle: 쿠버네티스 문서
 title: 문서
 ---

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

@@ -23,7 +23,7 @@ weight: 40
 
 ## 디자인
 
-![쿠버네티스 컴포넌트](/images/docs/components-of-kubernetes.png)
+![쿠버네티스 컴포넌트](/images/docs/components-of-kubernetes.svg)
 
 클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로,
 파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일
@@ -213,4 +213,3 @@ rules:
 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다.
 
 플러그인 개발에 대한 자세한 내용은 [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참조한다.
-

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

@@ -6,14 +6,14 @@ weight: 30
 
 <!-- overview -->
 
-로보틱스와 자동화에서 _컨트롤 루프_ 는 
+로보틱스와 자동화에서 _컨트롤 루프_ 는
 시스템 상태를 조절하는 종료되지 않는 루프이다.
 
 컨트롤 루프의 예시: 실내 온도 조절기
 
 사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를
 온도 조절기에 알려준다.
-*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서 
+*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
 현재 상태를 의도한 상태에 가깝게 만든다.
 
 {{< glossary_definition term_id="controller" length="short">}}
@@ -28,64 +28,64 @@ weight: 30
 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다.
 이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
 는 의도한 상태를 표현하는 사양 필드를 가지고 있다.
-해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 
+해당 리소스의 컨트롤러(들)은 현재 상태를 의도한
 상태에 가깝게 만드는 역할을 한다.
 
-컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로, 
-쿠버네티스에서는 컨트롤러가 
+컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로,
+쿠버네티스에서는 컨트롤러가
 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 로
 유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다.
 
 {{< comment >}}
-네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는 
-오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는 
+네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는
+오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는
 자세한 설명을 생략한다.
 {{< /comment >}}
 
 ### API 서버를 통한 제어
 
-{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스 
-내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 
+{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스
+내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와
 상호 작용하며 상태를 관리한다.
 
-잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 
-작업을 수행한 다음 중지하는 
+잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고,
+작업을 수행한 다음 중지하는
 쿠버네티스 리소스 이다.
 
-(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet 
+(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet
 의 의도한 상태 중 일부가 된다.)
 
-잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 
+잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
 노드 집합의 kubelet이 작업을 수행하기에 적합한
 수의 파드를 실행하게 한다.
 잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다.
-대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록 
+대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록
 지시한다.
-{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의
 다른 컴포넌트는 신규 정보
-(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여, 
+(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여,
 결국 해당 작업을 완료시킨다.
 
 새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다.
-잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게 
-만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서 
+잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게
+만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서
 잡이 완료에 가까워 지도록 한다.
 
 또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다.
 예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는
 잡 오브젝트가 `Finished`  로 표시되도록 업데이트한다.
 
-(이것은 지금 방 온도가 설정한 온도인 것을 표시하기 
+(이것은 지금 방 온도가 설정한 온도인 것을 표시하기
 위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다).
 
 ### 직접 제어
 
-잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을 
+잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을
 변경해야 할 필요가 있다.
 
-예를 들어, 만약 컨트롤 루프를 사용해서 
+예를 들어, 만약 컨트롤 루프를 사용해서
 클러스터에 충분한 {{< glossary_tooltip text="노드들" term_id="node" >}}이
-있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록 
+있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록
 현재 클러스터 외부의 무언가를 필요로 한다.
 
 외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한
@@ -101,7 +101,7 @@ weight: 30
 쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인
 변화에 대응할 수 있다.
 
-작업이 발생함에 따라 어떤 시점에서든 클러스터가 
+작업이 발생함에 따라 어떤 시점에서든 클러스터가
 변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로,
 클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다.
 
@@ -110,26 +110,26 @@ weight: 30
 
 ## 디자인
 
-디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 
+디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을
 관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프
-(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 
+(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로
 만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는
-잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 
+잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를
 확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
 잡은 다른 컨트롤러가 생성한다.
 
-컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, 
-간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 
+컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다,
+간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를
 허용하도록 디자인되었다.
 
 {{< note >}}
 동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다.
-이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에 
+이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에
 연결된 리소스에만 주의를 기울인다.
 
 예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다.
-잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다. 
-이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는 
+잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다.
+이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는
 정보({{< glossary_tooltip term_id="label" text="레이블" >}})가 있기 때문이다.
 {{< /note >}}
 
@@ -139,23 +139,22 @@ weight: 30
 내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이
 내장 컨트롤러는 중요한 핵심 동작을 제공한다.
 
-디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의 
+디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의
 자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다.
-쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로, 
+쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로,
 어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다.
 
 컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다.
 또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다.
-소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나, 
+소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나,
 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
 따라 달라진다.
 
 
 
 ## {{% heading "whatsnext" %}}
 
-* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기
-* [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자.
+* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기
+* [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자.
 * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
 * 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다.
-

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

@@ -29,7 +29,7 @@ content_type: concept
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
 * [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
-* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
+* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
 
 ## 서비스 검색