Update to outdated files in the dev-1.17-ko.1 (#18070)

* Update to outdated files in the dev-1.17-ko.1 * Fix typo daemonset.md * Update cloud-provider.md * Update URLs. * Apply suggestions from code review Co-Authored-By: Seokho Son <[email protected]> * Update user-guide-windows-containers.md * Update nodes.md Co-authored-by: Seokho Son <[email protected]>
kubernetes · Dec 20, 2019 · 92544b7 · 92544b7
1 parent 0cb63a4
commit 92544b7
Show file tree

Hide file tree

Showing 28 changed files with 333 additions and 106 deletions.
diff --git a/content/ko/_index.html b/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>

diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/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가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다.
 

diff --git a/content/ko/docs/concepts/architecture/nodes.md b/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에서, 대량의 노드들이 마스터 접근에 
 문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) 

diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/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로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
 

diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md
@@ -12,7 +12,7 @@ weight: 10
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
 
 _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
 추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
@@ -24,7 +24,7 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
 
 ## 엔드포인트 슬라이스 리소스 {#endpointslice-resource}
 
-쿠버네티스에서 엔드포인트 슬라이스는 일련의 네트워크 엔드 포인트에 대한
+쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한
 참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 EndpointSlice
 컨트롤러는 자동으로 엔드포인트 슬라이스를 생성한다. 이 엔드포인트 슬라이스는
 서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트
@@ -34,21 +34,20 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
 리소스 샘플이 있다.
 
 ```yaml
-apiVersion: discovery.k8s.io/v1alpha1
+apiVersion: discovery.k8s.io/v1beta1
 kind: EndpointSlice
 metadata:
   name: example-abc
   labels:
     kubernetes.io/service-name: example
-addressType: IP
+addressType: IPv4
 ports:
   - name: http
     protocol: TCP
     port: 80
 endpoints:
   - addresses:
     - "10.1.2.3"
-    - "2001:db8::1234:5678"
     conditions:
       ready: true
     hostname: pod-1
@@ -65,6 +64,14 @@ endpoints:
 신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
 서비스에 대해 성능 향상을 제공해야 한다.
 
+## 주소 유형
+
+EndpointSlice는 다음 주소 유형을 지원한다.
+
+* IPv4
+* IPv6
+* FQDN (Fully Qualified Domain Name)
+
 ## 사용동기
 
 엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는

diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
 
 - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
 - 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
-- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
+- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
 
 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 
@@ -95,21 +95,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 ## 데몬 파드가 스케줄 되는 방법
 
-### 데몬셋 컨트롤러에 의해서 스케줄(1.12 이후로 기본값으로 사용 안함)
+### 기본 스케줄러로 스케줄
 
-일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 머신이 선택된다. 그러나 데몬셋 
-컨트롤러에 의해 생성된 파드는 이미 머신이 선택되어 있다(`.spec.nodeName` 이 
-파드가 생성될 때 명시되므로, 스케줄러에서는 무시된다). 그러므로 다음과 같다.
-
- - 데몬셋 컨트롤러는 노드의 [`unschedulable`](/ko/docs/concepts/architecture/nodes/#수동-노드-관리) 
-   필드를 존중하지 않는다.
- - 데몬셋 컨트롤러는 스케줄러가 시작되지 않은 경우에도 파드를 만들 수 있어 클러스터 부트스트랩을 
-   도울 수도 있다.
-
-
-### 기본 스케줄러로 스케줄(1.12 이후로 기본값으로 사용)
-
-{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
+{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
 
 데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 
 쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 

diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -44,10 +44,6 @@ weight: 40
 ## 구성 요소
 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
 
-* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
-* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
-* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
-
 ```yaml
 apiVersion: v1
 kind: Service
@@ -99,6 +95,12 @@ spec:
           storage: 1Gi
 ```
 
+위의 예시에서:
+
+* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
+* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
+* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
+
 ## 파드 셀렉터
 스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
 
@@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
  kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |
 
 {{< note >}}
-클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 
+클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 
 아니라면 `cluster.local`로 설정된다.
 {{< /note >}}
 
@@ -260,7 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
 
 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
 * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
-* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
+* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
 
 {{% /capture %}}
 
diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.
 
-알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
-`TTLAfterFinished` 를 통해 활성화 될 수 있다.
+알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.
 
 
 {{% /capture %}}