Update outdated content in dev-1.16-ko.1

content/ko/_index.html

@@ -3,6 +3,7 @@
 abstract: "자동화된 컨테이너 배포, 스케일링과 관리"
 cid: home
 ---
+{{< announcement >}}
 
 {{< deprecationwarning >}}
 

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

@@ -223,13 +223,14 @@ rules:
 
 다음은 클라우드 제공사업자들이 구현한 CCM들이다.
 
-* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
-* [Azure](https://github.com/kubernetes/cloud-provider-azure)
-* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
 * [AWS](https://github.com/kubernetes/cloud-provider-aws)
+* [Azure](https://github.com/kubernetes/cloud-provider-azure)
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
+* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
 * [Linode](https://github.com/linode/linode-cloud-controller-manager)
+* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
+* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
 
 ## 클러스터 관리
 

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

@@ -190,9 +190,20 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄
 
 파드 형태가 아닌 프로세스에 대해 명시적으로 리소스를 확보하려면, [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) 튜토리얼을 따른다.
 
+## 노드 토폴로지
+
+{{< feature-state state="alpha" >}}
+
+`TopologyManager` 
+[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
+활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
 
 ## API 오브젝트
 
 노드는 쿠버네티스 REST API 내 탑-레벨 리소스 이다. API 오브젝트에 대한 보다 자세한 내용은 [노드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)에서 확인할 수 있다.
 
 {{% /capture %}}
+{{% capture whatsnext %}}
+* [노드 컴포넌트](https://kubernetes.io/docs/concepts/overview/components/#node-components)에 대해 읽기
+* 노드 수준 토폴로지에 대해 읽기: [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/)
+{{% /capture %}}

content/ko/docs/concepts/containers/runtime-class.md

@@ -54,10 +54,9 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
 연관된 문서를 통해서 확인한다([아래](#cri-configuration)).
 
 {{< note >}}
-런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정
-(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
-설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다
-([파드를 노드에 할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
+런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정
+(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다.
+이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄링](#scheduling)을 참고한다.
 {{< /note >}}
 
 해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
@@ -144,6 +143,42 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 더 자세한 cri-o의 구성 문서를 살펴본다.
 https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
 
+### 스케줄
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+쿠버네티스 v1.16 부터는, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다.
+이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다.
+이 스케줄링 기능을 사용하려면, 런타임 클래스 [어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다.
+
+파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
+해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.
+런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로
+각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다.
+
+지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면,
+`tolerations`를 런타임 클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 
+해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된
+노드의 합집합을 취한다.
+
+노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면
+[노드에 파드 할당](/docs/concepts/configuration/assign-pod-node/)을 참고한다.
+
+[어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/
+
+### 파드 오버헤드
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+쿠버네티스 v1.16 부터는, 런타임 클래스에는 구동 중인 파드와 관련된 오버헤드를
+지정할 수 있는 기능이 [`PodOverhead`](/docs/concepts/configuration/pod-overhead.md) 기능을 통해 지원된다.
+`PodOverhead`를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
+활성화 시켜야 한다. (기본 값으로는 비활성화 되어 있다.)
+
+
+파드 오버헤드는 런타임 클래스에서 `Overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
+해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
+쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.
 
 ### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta}
 
@@ -172,4 +207,11 @@ https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
   더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
   (위를 참조).
 
+### 더 읽기
+
+- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
+- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [Pod Overhead](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
+- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
+
 {{% /capture %}}

content/ko/docs/concepts/workloads/controllers/deployment.md

@@ -227,7 +227,7 @@ _디플로이먼트_ 컨트롤러는 [파드](/ko/docs/concepts/workloads/pods/p
     다음에 이러한 파드를 업데이트 하려면 디플로이먼트의 파드 템플릿만 다시 업데이트 하면 된다.
 
     디플로이먼트는 업데이트되는 동안 일정한 수의 파드만 중단되도록 보장한다. 기본적으로
-    적어도 의도한 파드 수의 25% 이상이 동작하도록 보장한다(최대 25% 이상 불가).
+    적어도 의도한 파드 수의 75% 이상이 동작하도록 보장한다(최대 25% 불가).
 
     또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
     기본적으로, 의도한 파드의 수 기준 최대 25%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).

content/ko/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -101,21 +101,29 @@ kubelet은 컨테이너에 의해서 구현된
 * Failure: 컨테이너가 진단에 실패함.
 * Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.
 
-kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 종류의 프로브를 수행하고
+kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
 그에 반응할 수 있다.
 
-* `livenessProbe`는 컨테이너가 동작 중인지 여부를 나타낸다. 만약
+* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약
    활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
    [재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가
    활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다.
 
-* `readinessProbe`는 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
+* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
    만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
    파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
    초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를
    지원하지 않는다면, 기본 상태는 `Success`이다.
 
-### 언제 활성 또는 준비성 프로브를 사용해야 하는가?
+* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
+   스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 
+   활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
+   컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 
+   프로브가 없는 경우, 기본 상태는 `Success`이다.
+
+### 언제 활성 프로브를 사용해야 하는가?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
 
 만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한
 상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가
@@ -125,6 +133,10 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
 프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를
 지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
 
+### 언제 준비성 프로브를 사용해야 하는가?
+
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
+
 프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다.
 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만,
 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서
@@ -142,6 +154,13 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
 파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
 남아있는다.
 
+### 언제 스타트업 프로브를 사용해야 하는가?
+
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+
+컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds` 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 체크하도록 명시해야 한다. `periodSeconds`의 기본 값은 30s 이다.
+이 때 컨테이너가 활성화 프로브의 기본 값 변경 없이 기동되도록 하려면 `failureThreshold`를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.
+
 활성 프로브 및 준비성 프로브를 설정하는 방법에 대한 추가적인 정보는,
 [활성 프로브 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다.
 

content/ko/docs/reference/_index.md

@@ -18,11 +18,11 @@ content_template: templates/concept
 
 * [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
 * 쿠버네티스 API 버전
+  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
   * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
   * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
   * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
   * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
-  * [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
 
 ## API 클라이언트 라이브러리
 

content/ko/docs/reference/glossary/applications.md

@@ -5,7 +5,6 @@ date: 2019-05-12
 full_link:
 short_description: >
   컨테이너화된 다양한 애플리케이션들이 실행되는 레이어.
-
 aka:
 tags:
 - fundamental

content/ko/docs/reference/glossary/static-pod.md

@@ -2,13 +2,17 @@
 title: 스태틱 파드(Static Pod)
 id: static-pod
 date: 2019-02-12
-full_link: /docs/tasks/administer-cluster/static-pod/
+full_link: /docs/tasks/configure-pod-container/static-pod/
 short_description: >
   특정 노드의 Kubelet 데몬이 직접 관리하는 파드
 
-aka:
+aka: 
 tags:
 - fundamental
 ---
- API 서버가 관찰하지 않고, 특정 노드의 Kubelet 데몬이
- 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}.
+
+특정 노드의 Kubelet 데몬이
+ 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}로,
+ <!--more-->
+
+API 서버가 관찰하지 않는다.

content/ko/docs/reference/glossary/workload.md

@@ -9,20 +9,15 @@ short_description: >
 aka: 
 tags:
 - fundamental
-- core-object
-- workload
 ---
-  워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다.
+  워크로드는 쿠버네티스에서 구동되는 애플리케이션이다.
 
 <!--more--> 
 
-쿠버네티스는 
-애플리케이션의 현재 상태에 따라 워크로드의 디플로이먼트와 업데이트를 수행한다.
-워크로드는 데몬셋, 디플로이먼트, 잡, 파드, 레플리카셋, 레플리케이션컨트롤러, 스테이트풀셋과 같은 오브젝트를 포함한다.
+데몬셋, 디플로이먼트, 잡, 레플리카셋, 그리고 스테이트풀셋 오브젝트를 포함해서
+서로 다른 워크로드의 유형이나 부분을 대표하는 다양한 핵심 오브젝트.
 
-예를 들어, 웹 요소와 데이터베이스 요소가 있는 워크로드는 
-데이터베이스를 {{< glossary_tooltip text="파드" term_id="pod" >}}의 한 
-{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, 
-웹서버를 많은 웹 앱 {{< glossary_tooltip text="파드" term_id="pod" >}}로 구성된 
-{{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다.
+예를 들어, 웹 서버와 데이터베이스가 있는 워크로드는
+데이터베이스를 한 {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, 
+웹서버를 {{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다.
 

content/ko/docs/setup/_index.md

@@ -78,7 +78,7 @@ card:
 | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) |       |✔  | ✔     |  |     | ✔
 | [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)     |      |  |      | |    ✔       | ✔
 | [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)     |      |  |      | |           | ✔
-| [Gardener](https://gardener.cloud/)       |              |✔  |         | ✔   |          |
+| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ (via OpenStack) | ✔ | |
 | [Giant Swarm](https://giantswarm.io/)     | ✔       | ✔ |   ✔    |     |
 | [Google](https://cloud.google.com/)           |  [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/)       | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/)       |  |  |     |  |      |       |  |
 | [IBM](https://www.ibm.com/in-en/cloud)        | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
@@ -105,5 +105,6 @@ card:
 | [Tencent Cloud](https://intl.cloud.tencent.com/)  | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) |   ✔   |   ✔ |    |      |   ✔  |
 | [VEXXHOST](https://vexxhost.com/)         | ✔             | ✔      |             |      |          |
 | [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)              |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)        |   [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks)          | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)      |          |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks)
+| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | |
 
 {{% /capture %}}

content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md

@@ -40,7 +40,7 @@ kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
-kubernetesVersion: v1.13.0
+kubernetesVersion: v1.16.0
 apiServer:
   extraArgs:
     advertise-address: 192.168.0.103
@@ -57,7 +57,7 @@ apiServer:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
-kubernetesVersion: v1.13.0
+kubernetesVersion: v1.16.0
 controllerManager:
   extraArgs:
     cluster-signing-key-file: /home/johndoe/keys/ca.key
@@ -73,7 +73,7 @@ controllerManager:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta2
 kind: ClusterConfiguration
-kubernetesVersion: v1.13.0
+kubernetesVersion: v1.16.0
 scheduler:
   extraArgs:
     address: 0.0.0.0

content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md

@@ -102,6 +102,10 @@ weight: 75
 윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다.
 {{< /note >}}
 
+## 설정 가능한 컨테이너 username 사용하기
+
+쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다. 
+
 ## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기
 
 쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자.