First Korean l10n work for release-1.16 (#16551)

* Modify #16415, #16417 korean docs. (#16467)
* Modify #16364 and links in korean docs. (#16508)
* Translate concepts/workloads/controllers/statefulset.md in Korean (#16443)
* Update outdated content in dev-1.16-ko.1 (#16502)
* Translate concepts/workloads/controllers/daemonset.md in Korean (#16477)
* Translate concepts/services-networking/dns-pod-service in Korean (#16299)

Co-Authored-By: June Yi <june.yi@samsung.com>
Co-Authored-By: Yoon <learder@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
Co-Authored-By: SoHye Choi <wergreat10@naver.com>
Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>

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)에 대해 읽기
+* 노드 수준 토폴로지에 대해 읽기: [노드의 토폴로지 정책 제어하기](/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
   더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
   (위를 참조).
 
+### 더 읽기
+
+- [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
+- [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
+- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
+
 {{% /capture %}}

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

@@ -148,7 +148,7 @@ _집합성 기준_ 요건은 _일치성 기준_ 요건과 조합해서 사용할
 
 ### LIST와 WATCH 필터링
 
-LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀럭터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
+LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 2가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).
 
   * _불일치 기준_ 요건: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
   * _집합성 기준_ 요건: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29`
@@ -181,11 +181,11 @@ kubectl get pods -l 'environment,environment notin (frontend)'
 
 [`서비스`](/docs/user-guide/services) 와 [`레플리케이션 컨트롤러`](/docs/user-guide/replication-controller)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [`파드`](/docs/user-guide/pods)와 같은 다른 리소스 집합을 선택한다.
 
-#### 서비스와 리플리케이션 컨트롤러
+#### 서비스와 레플리케이션 컨트롤러
 
-`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `리플레케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
+`서비스`에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 `레플리케이션 컨트롤러`가 관리하는 파드의 개체군도 레이블 셀렉터로 정의한다.
 
-서비스와 리플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
+서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 `json` 또는 `yaml` 파일에 매핑된 _균등-기반_ 요구사항의 셀렉터만 지원한다.
 
 ```json
 "selector": {

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

@@ -27,16 +27,16 @@ weight: 30
 
 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다.
 
-다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근  제어 정책을 갖게 된다.
+다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적으로 동일한 접근  제어 정책을 갖게 된다.
 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.
 
 같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서
 복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를
-구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다.
+구분하기 위해서는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.
 
 ## 네임스페이스 다루기
 
-네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에
+네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에
 기술되어 있다.
 
 ### 네임스페이스 조회
@@ -94,7 +94,7 @@ kubectl config view | grep namespace:
 
 대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
-그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
+그리고 [nodes](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
 네임스페이스에도 속하지 않는다.
 
 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하기 위해서는,

content/ko/docs/concepts/services-networking/_index.md

@@ -0,0 +1,4 @@
+---
+title: "서비스, 로드밸런싱, 네트워킹"
+weight: 60
+---