Updated 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/tasks/access-application-cluster/web-ui-dashboard.md

@@ -9,6 +9,7 @@ card:
 ---
 
 {{% capture overview %}}
+
 대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
 
 또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다.
@@ -25,7 +26,7 @@ card:
 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다.
 
 ```
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta4/aio/deploy/recommended.yaml
 ```
 
 ## 대시보드 UI 접근
@@ -160,6 +161,7 @@ track=stable
 
 {{% capture whatsnext %}}
 
-더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다.
+더 많은 정보는 
+[쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다.
 
 {{% /capture %}}