[ko] Update /ko/concepts/workloads/controllers/daemonset.md

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

@@ -6,8 +6,14 @@
 # - janetkuo
 # - kow3ns
 title: 데몬셋
+api_metadata:
+- apiVersion: "apps/v1"
+  kind: "DaemonSet"
+description: >-
+ 데몬셋은 노드 로컬 기능을 제공하는 파드를 정의한다. 이러한 파드는 네트워킹 도우미 도구처럼 클러스터 운영에 필수적인 기능일 수도 있고 애드온의 일부일 수도 있다. 
 content_type: concept
 weight: 40
+hide_summary: true # Listed separately in section index
 ---
 
 <!-- overview -->
@@ -35,7 +41,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
 YAML 파일에 데몬셋 명세를 작성할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 
 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
 
-{{< codenew file="controllers/daemonset.yaml" >}}
+{{% code_sample file="controllers/daemonset.yaml" %}}
 
 YAML 파일을 기반으로 데몬셋을 생성한다.
 
@@ -79,12 +85,12 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 `.spec.template`의 레이블과 매치되는 
 파드 셀렉터를 명시해야 한다.
 또한, 한 번 데몬셋이 만들어지면 
-`.spec.selector` 는 바꿀 수 없다.
-파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.
+`.spec.selector` 는 바꿀 수 없다. 파드 셀렉터를 변형하면 
+의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.
 
 `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.
 
-* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 
+* `matchLabels` - [레플리케이션컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 
 `.spec.selector` 와 동일하게 작동한다.
 * `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를
   명시해서 보다 정교한 셀렉터를 만들 수 있다.
@@ -105,30 +111,31 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 ## 데몬 파드가 스케줄 되는 방법
 
-### 기본 스케줄러로 스케줄
-
-{{< feature-state for_k8s_version="1.17" state="stable" >}}
-
-데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
-쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
-데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다.
-이에 대한 이슈를 소개한다.
-
-* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
-  그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
-  이것은 사용자에게 혼란을 준다.
-* [파드 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)은
-  기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
-  파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
-
-`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신
-`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본
-스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
-스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에
-이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 
-원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
-데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
-데몬셋의 `spec.template` 은 변경되지 않는다.
+데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 
+데몬셋 컨트롤러는 각 적격한 노드에 파드를 생성하고 
+파드의 `spec.affinity.nodeAffinity` 필드를 추가하여 대상 호스트와 일치시킨다.
+파드가 생성되면 일반적으로 기본 스케줄러가 작업을 인계받아 
+`.spec.nodeName` 필드를 설정하여 파드를 대상 호스트에 바인딩한다. 
+새 파드가 노드에 맞지 않으면 기본 스케줄러가 새 파드의 
+[우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)에 따라 
+기존 파드 중 일부를 
+선점(제거)할 수 있다. 
+
+{{< note >}}
+데몬셋 파드가 각 노드에서 실행되는 것이 중요한 경우, 데몬셋의 
+`.spec.template.spec.priorityClassName` 을 더 높은 우선순위를 가진 
+[프라이어리티클래스(PriorityClass)](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)로 설정하여
+이러한 축출이 발생하도록 하는 것이 좋다.
+{{< /note >}}
+
+사용자는 데몬셋의 `.spec.template.spec.schedulerName` 필드를 설정하여
+데몬셋의 파드에 다른 스케줄러를 지정할 수 있다.
+
+`.spec.template.spec.affinity.nodeAffinity` 필드(지정된 경우)에 
+지정된 원래 노드 어피니티는 
+데몬셋 컨트롤러가 적격 노드를 평가할 때 고려되지만,
+생성된 파드에서는 적격 노드의 이름과 일치하는 노드 어피니티로 
+대체된다.
 
 ```yaml
 nodeAffinity:
@@ -141,25 +148,40 @@ nodeAffinity:
         - target-host-name
 ```
 
-또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로
-자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를
-스케줄링시 `unschedulable` 노드를 무시한다.
 
 ### 테인트(taints)와 톨러레이션(tolerations)
 
-데몬 파드는
-[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 존중하지만,
-다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에
-톨러레이션을 추가한다.
+데몬셋 컨트롤러는 데몬셋 파드에 
+{{< glossary_tooltip text="톨러레이션" term_id="toleration" >}} 세트를 추가한다.
+
+{{< table caption="데몬셋 파드를 위한 톨러레이션" >}}
 
-| 톨러레이션 키                              | 영향       | 버전    | 설명                                                           |
-| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
-| `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
-| `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
-| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | 데몬셋 파드는 기본 스케줄러에서 디스크-압박(disk-pressure) 속성을 허용한다. |
-| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | 데몬셋 파드는 기본 스케줄러에서 메모리-압박(memory-pressure) 속성을 허용한다. |
-| `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. |
-| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. |
+| 톨러레이션 키                                                                                                            | 영향       | 설명                                                                                                                                       |
+| --------------------------------------------------------------------------------------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`node.kubernetes.io/not-ready`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-not-ready)             | `NoExecute`  | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
+| [`node.kubernetes.io/unreachable`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-unreachable)         | `NoExecute`  | 데몬셋 파드는 노드 컨트롤러에서 접근할 수 없는 노드에 예약될 수 있다. 이러한 노드에서 실행 중인 데몬셋 파드는 제거되지 않는다.  |
+| [`node.kubernetes.io/disk-pressure`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-disk-pressure)     | `NoSchedule` | 데몬셋 파드는 디스크 압박 문제가 있는 노드에 예약될 수 있다.                                                                         |
+| [`node.kubernetes.io/memory-pressure`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | 데몬셋 파드는 메모리 부족 문제가 있는 노드에 예약될 수 있다.                                                                        |
+| [`node.kubernetes.io/pid-pressure`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | 데몬셋 파드는 프로세스 압력 문제가 있는 노드에 예약될 수 있다.                                                                        |
+| [`node.kubernetes.io/unschedulable`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-unschedulable)   | `NoSchedule` | 데몬셋 파드는 예약할 수 없는 노드에 예약될 수 있다.                                                                             |
+| [`node.kubernetes.io/network-unavailable`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **호스트 네트워킹을 요청하는 데몬셋 파드에만 추가되었다**, 즉, `spec.hostNetwork: true`를 가진 파드이다. 이러한 데몬셋 파드는 네트워크를 사용할 수 없는 노드에 예약될 수 있다.|
+
+{{< /table >}}
+
+데몬셋의 파드 템플릿에서 정의하여, 
+데몬셋의 파드에 자체 톨러레이션을 추가할 수도 있다.
+
+데몬셋 컨트롤러가 
+`node.kubernetes.io/unschedulable:NoSchedule` 톨러레이션을 자동으로 설정하므로,
+쿠버네티스는 _unschedulable_ 로 표시된 노드에서 데몬셋 파드를 실행할 수 있다.
+
+데몬셋을 사용하여 [클러스터 네트워킹](/ko/docs/concepts/cluster-administration/networking/)과 같은 
+중요한 노드 수준 기능을 제공하는 경우, 
+쿠버네티스가 데몬셋 파드를 노드가 준비되기 전에 노드에 배치하는 것이 도움이 된다.
+예를 들어, 이러한 특별한 허용 범위가 없으면 네트워크 플러그인이 
+실행 중이 아니기 때문에 노드가 준비 완료로 표시되지 않고, 
+동시에 노드가 아직 준비되지 않았기 때문에 네트워크 플레인이 
+해당 노드에서 실행되지 않는 교착 상태에 빠질 수 있다.
 
 ## 데몬 파드와 통신
 
@@ -174,7 +196,8 @@ nodeAffinity:
   그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 
   DNS에서 여러 A레코드를 검색한다.
 - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
-  임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다).
+  임의의 노드의 데몬에 도달한다. [서비스 내부 트래픽 정책](/ko/docs/concepts/services-networking/service-traffic-policy/)을 사용하여
+  동일한 노드에 있는 파드로 제한한다.
 
 ## 데몬셋 업데이트
 
@@ -224,7 +247,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
 
 데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고,
 해당 파드에서는 프로세스가 종료되지 않을 것으로
-예상한다(예: 웹 서버).
+예상한다(예: 웹 서버, 스토리지 서버).
 
 파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
@@ -233,12 +256,12 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
 
 예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
 
+
 ## {{% heading "whatsnext" %}}
 
 * [파드](/ko/docs/concepts/workloads/pods/)에 대해 배운다.
-  * 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
-    컴포넌트를 기동하는데 유용한
-    [스태틱 파드](#static-pods)에 대해 배운다. 
+  * 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트를 기동하는데 유용한
+    [스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)에 대해 배운다. 
 * 데몬셋을 어떻게 사용하는지 알아본다.
   * [데몬셋 롤링 업데이트 수행하기](/ko/docs/tasks/manage-daemon/update-daemon-set/)
   * [데몬셋 롤백하기](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)
@@ -248,5 +271,4 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
   [애드온](/ko/docs/concepts/cluster-administration/addons/)에 대해 배운다.
 * `DaemonSet`은 쿠버네티스 REST API에서 상위-수준 리소스이다.
   데몬셋 API에 대해 이해하기 위해 
-  {{< api-reference page="workload-resources/daemon-set-v1" >}}
-  오브젝트 정의를 읽는다.
+  {{< api-reference page="workload-resources/daemon-set-v1" >}} 오브젝트 정의를 읽는다.