Merge remote-tracking branch 'upstream/dev-1.14-ko.3' into dev-1.14-ko.3

content/ko/docs/concepts/_index.md

@@ -17,7 +17,7 @@ weight: 40
 
 쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트로* 클러스터에 대해 사용자가 *바라는 상태를* 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다.
 
-일단 바라는 상태를 설정하고 나면, *쿠버네티스 컨트롤 플레인이* 클러스터의 현재 상태를 바라는 상태와 일치시키기 위한 일을 하게 된다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작 시키거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행할 수 있게 된다. 쿠버네티스 컨트롤 플레인은 클러스터에서 돌아가는 프로세스의 집합으로 구성된다.
+일단 바라는 상태를 설정하고 나면, *쿠버네티스 컨트롤 플레인*이 Pod Lifecycle Event Generator (PLEG) 를 사용하여 클러스터의 현재 상태를 바라는 상태와 일치시키기 위한 일을 하게 된다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작 시키거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행할 수 있게 된다. 쿠버네티스 컨트롤 플레인은 클러스터에서 돌아가는 프로세스의 집합으로 구성된다.
 
 * **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 집합이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다.
 * 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다.
@@ -47,7 +47,7 @@ weight: 40
 
 쿠버네티스 마스터와 kubelet 프로세스와 같은 쿠버네티스 컨트롤 플레인의 다양한 구성 요소는 쿠버네티스가 클러스터와 통신하는 방식을 관장한다. 컨트롤 플레인은 시스템 내 모든 쿠버네티스 오브젝트의 레코드를 유지하면서, 오브젝트의 상태를 관리하는 제어 루프를 지속적으로 구동시킨다. 컨트롤 플레인의 제어 루프는 클러스터 내 변경이 발생하면 언제라도 응답하고 시스템 내 모든 오브젝트의 실제 상태가 사용자가 바라는 상태와 일치시키기 위한 일을 한다.
 
-예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트 오브젝트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다.
+예를 들어, 쿠버네티스 API를 사용해서 디플로이먼트를 만들 때에는, 바라는 상태를 시스템에 신규로 입력해야한다. 쿠버네티스 컨트롤 플레인이 오브젝트 생성을 기록하고, 사용자 지시대로 필요한 애플리케이션을 시작시키고 클러스터 노드에 스케줄링한다. 그래서 결국 클러스터의 실제 상태가 바라는 상태와 일치하게 된다.
 
 ### 쿠버네티스 마스터
 

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

@@ -48,8 +48,6 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시
 * 라우트 컨트롤러
 * 서비스 컨트롤러
 
-추가적으로, PersistentVolumeLabels 컨트롤러라 불리는 다른 컨트롤러를 작동시킨다. 이 컨트롤러는 GCP와 AWS 클라우드 내 생성된 PersistentVolumes 상에 영역과 지역 레이블을 설정하는 책임을 가진다.
-
 {{< note >}}
 볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
 {{< /note >}}
@@ -69,7 +67,6 @@ CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급
 * 노드 컨트롤러
 * 라우트 컨트롤러
 * 서비스 컨트롤러
-* PersistentVolumeLabels 컨트롤러
 
 #### 노드 컨트롤러
 
@@ -86,26 +83,14 @@ CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급
 
 #### 서비스 컨트롤러
 
-서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB  또는 구글 LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다.
-
-#### PersistentVolumeLabels 컨트롤러
-
-PersistentVolumeLabels 컨트롤러는 AWS EBS/GCE PD 볼륨이 생성되는 시점에 레이블을 적용한다. 이로써 사용자가 수동으로 이들 볼륨에 레이블을 설정할 필요가 없어진다.
-
-이들 볼륨은 오직 그것들이 속한 지역/영역 내에서만 동작되도록 제한되므로 파드 스케줄에 필수적이다. 이들 볼륨을 이용하는 모든 파드는 동일한 지역/영역 내에서 스케줄 되어야 한다.  
-
-PersistentVolumeLabels 컨트롤러는 특별하게 CCM을 위해 생성되었다. 즉, CCM이 생성되기 전에는 없었다. 쿠버네티스 API 서버의 PV에 레이블을 붙이는 로직(어드미션 컨트롤러였다)을 CCM에 옮겨서 그렇게 만들었다.  
+서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucutre LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다.
 
 ### 2. Kubelet
 
 노드 컨트롤러는 kubelet의 클라우드 종속적인 기능을 포함한다. CCM이 도입되기 이전에는, kubelet 이 IP 주소, 지역/영역 레이블 그리고 인스턴스 타입 정보와 같은 클라우드 특유의 세부사항으로 노드를 초기화하는 책임을 가졌다. CCM의 도입으로 kubelet에서 CCM으로 이 초기화 작업이 이전되었다.
 
 이 새로운 모델에서, kubelet은 클라우드 특유의 정보 없이 노드를 초기화 해준다. 그러나, kubelet은 새로 생성된 노드에 taint를 추가해서 CCM이 클라우드에 대한 정보를 가지고 노드를 초기화하기 전까지는 스케줄되지 않도록 한다. 그러고 나서 이 taint를 제거한다.  
 
-### 3. 쿠버네티스 API 서버
-
-PersistentVolumeLabels 컨트롤러는 이전 섹션에서 기술한 바와 같이, 쿠버네티스 API 서버의 클라우드 종속적인 기능을 CCM으로 이전한다.
-
 ## 플러그인 메커니즘
 
 클라우드 컨트롤러 매니저는 어떠한 클라우드에서든지 플러그 인 되어 구현될 수 있도록 Go 인터페이스를 이용한다. 구체적으로, [여기](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)에 정의된 CloudProvider 인터페이스를 이용한다.
@@ -156,17 +141,6 @@ v1/Service:
 - Patch
 - Update
 
-### PersistentVolumeLabels 컨트롤러
-
-PersistentVolumeLabels 컨트롤러는 PersistentVolume(PV) 생성 이벤트에 대해 귀기울이고 그것을 업데이트 한다. 이 컨트롤러는 PV를 get 하고 update 하기 위한 접근을 요한다.
-
-v1/PersistentVolume:
-
-- Get
-- List
-- Watch
-- Update
-
 ### 그 외의 것들
 
 CCM의 코어에 대한 구현은 이벤트를 create 하고, 보안 작업을 보장하기 위한 접근을 요하며, ServiceAccount를 create 하기 위한 접근을 요한다.

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

@@ -37,7 +37,7 @@ card:
 Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처
 제공자 간 이식이 가능하게 해준다.
 
-## 어떻게 쿠버네티스가 플랫폼이 될 수 있는가?
+## 어떻게 쿠버네티스가 플랫폼인가
 
 쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는
 새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록
@@ -101,7 +101,7 @@ PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로
 A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이
 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
 
-## 왜 컨테이너인가?
+## 왜 컨테이너인가
 
 왜 컨테이너를 써야하는지 이유를 알고 싶은가?
 
@@ -165,7 +165,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필
 * **지원 사용량**:
     고효율 고집적.
 
-## 쿠버네티스(Kubernetes)의 뜻은? K8s?
+## 쿠버네티스의 뜻은? K8s?
 
 **쿠버네티스**는 *키잡이* 나 *파일럿* 을 뜻하는 그리스어에서 유래했으며,
 이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의

content/ko/docs/concepts/overview/working-with-objects/annotations.md

@@ -0,0 +1,76 @@
+---
+title: 어노테이션
+content_template: templates/concept
+weight: 50
+---
+
+{{% capture overview %}}
+쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를
+오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다.
+{{% /capture %}}
+
+{{% capture body %}}
+## 오브젝트에 메타데이터 첨부
+
+레이블이나 어노테이션을 사용하여 쿠버네티스
+오브젝트에 메타데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트
+컬렉션을 찾을 수 있다. 반면에, 어노테이션은
+오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타데이터는
+작거나 크고, 구조적이거나 구조적이지 않을 수 있으며, 레이블에서
+허용되지 않는 문자를 포함할 수 있다.
+
+어노테이션은 레이블과 같이 키/값 맵이다.
+
+```json
+"metadata": {
+  "annotations": {
+    "key1" : "value1",
+    "key2" : "value2"
+  }
+}
+```
+
+다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
+
+* 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은
+  클라이언트 또는 서버가 설정한 기본 값,
+  자동 생성된 필드, 그리고
+  오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.
+
+* 빌드, 릴리스, 또는 타임 스탬프, 릴리즈 ID, git 브랜치,
+  PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.
+
+* 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.
+
+* 디버깅 목적으로 사용될 수 있는 클라이언트 라이브러리 또는 도구 정보:
+  예를 들면, 이름, 버전, 그리고 빌드 정보.
+
+* 다른 생태계 구성 요소의 관련 오브젝트 URL과 같은
+  사용자 또는 도구/시스템 출처 정보.
+
+* 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
+
+* 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
+  해당 정보를 찾을 수 있는 디렉토리 진입점.
+
+* 행동을 수정하거나 비표준 기능을 수행하기 위한
+  최종 사용자의 지시 사항.
+
+어노테이션을 사용하는 대신, 이 유형의 정보를
+외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
+공유 클라이언트 라이브러리와 도구 생성을
+훨씬 더 어렵게 만들 수 있다.
+
+## 문법과 캐릭터 셋
+
+_어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(`/`)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자(`[a-z0-9A-Z]`)로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(`-`), 밑줄(`_`), 점(`.`)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 하위 도메인이어야 한다. 점(`.`)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(`/`)가 붙는다.
+
+접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :`kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.
+
+`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+[레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다.
+{{% /capture %}}

content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -20,13 +20,13 @@ card:
 * 그 애플리케이션이 이용할 수 있는 리소스
 * 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
 
-쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 **의도한 상태** 가 된다.
+쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드" 이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 *의도한 상태* 가 된다.
 
 생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, [Kubernetes API](/docs/concepts/overview/kubernetes-api/)를 이용해야 한다. 예를 들어, `kubectl` 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 [Client Libraries](/docs/reference/using-api/client-libraries/) 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
 
 ### 오브젝트 스펙(spec)과 상태(status)
 
-모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 *의도한 상태* 를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
+모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 *spec* 과 오브젝트 *status* 가 그것이다. 필히 제공되어야만 하는 *spec* 은, 여러분이 오브젝트가 가졌으면 하고 원하는 특징, 즉 의도한 상태를 기술한다. *status* 는 오브젝트의 *실제 상태* 를 기술하고, 쿠버네티스 시스템에 의해 제공되고 업데이트 된다. 주어진 임의의 시간에, 쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 여러분이 제시한 의도한 상태에 일치시키기 위해 능동적으로 관리한다.
 
 
 예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해 줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 (상태 변경에) 실패가 난다면, 쿠버네티스 시스템은 보정을 통해, 이 경우에는 인스턴스 대체를 착수하여, spec과 status 간의 차이에 대응한다.
@@ -61,9 +61,10 @@ deployment.apps/nginx-deployment created
 
 * `apiVersion` - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
 * `kind` - 어떤 종류의 오브젝트를 생성하고자 하는지
-* `metadata` - `이름` 문자열, UID, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
+* `metadata` - `이름` 문자열, `UID`, 그리고 선택적인 `네임스페이스` 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
 
-여러분은 또한 오브젝트 `spec` 필드를 제공해야만 할 것이다. 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. 예를 들어, `파드` 오브젝트에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 확인할 수 있고, `디플로이먼트` 오브젝트에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
+여러분은 또한 오브젝트 `spec` 필드를 제공해야만 할 것이다. 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. 
+예를 들어, `파드`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은 [여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다.
 
 {{% /capture %}}