Merge remote-tracking branch 'upstream/master' into zacharysarah-merged-master-dev-1.18

2020-03-03 12:07:32 -08:00
parent 78193337e4 c04ffcdce8
commit 4582f017e2
115 changed files with 3895 additions and 613 deletions
@@ -13,8 +13,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
 데몬셋의 일부 대표적인 용도는 다음과 같다.

 - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
- 모든 노드에서 [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/) 와 같은 노드 모니터링 데몬의 실행.
+- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행.
+- 모든 노드에서 [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/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행.

 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 
@@ -88,9 +88,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 ### 오직 일부 노드에서만 파드 실행

 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 
-[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/#nodeselector)와 
+[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/#노드-셀렉터-nodeselector)와 
 일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 
-데몬셋 컨트롤러는 [노트 어피니티](/docs/concepts/configuration/assign-pod-node/#node-affinity)와 일치하는 노드에 파드를 생성한다. 
+데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/configuration/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 
 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.

 ## 데몬 파드가 스케줄 되는 방법
@@ -161,7 +161,7 @@ nodeAffinity:
 - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
  구성되어있다. 그들은 클라이언트들을 가지지 않는다.
 - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 만들고, 
+- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 
  그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
  검색한다.
 - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
@@ -22,7 +22,7 @@ weight: 10
 레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을
 사용한다.

-레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)
+레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent)
 필드를 통해서 제공되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다.
 레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다.
 이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다.
@@ -250,7 +250,7 @@ matchLabels:

 ### 레플리카셋과 해당 파드 삭제

-레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
+레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.

 REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로 
 설정해야 한다.
@@ -34,7 +34,7 @@ weight: 40

 * 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
 * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. 
-* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
+* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
 * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
 * [롤링 업데이트](#롤링-업데이트)와 기본 
  [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를
@@ -121,7 +121,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 `$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 
 `web-0,web-1,web-2` 이다.
 스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 
-[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 사용할 수 있다.
+[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다.
 이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, 
 여기서 "cluster.local"은 클러스터 도메인이다.
 각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 
@@ -130,7 +130,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있

 [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는
 파드의 네트워크 신원을 책임지는 
-[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 생성할 책임이 있다.
+[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다.

 여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 
 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다.
@@ -9,7 +9,7 @@ weight: 65
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
-제한하는 TTL 메커니즘을 제공한다. TTL 컨트롤러는 현재
+제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
 [잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.