Skip to content

Commit 3183be9

Browse files
EundmsEundms
authored
[ko] Update /ko/concepts/workloads/controllers/daemonset.md (#52944)
* [ko] Update /ko/concepts/workloads/controllers/daemonset.md * fix based on review
1 parent a73957c commit 3183be9

File tree

1 file changed

+86
-64
lines changed

1 file changed

+86
-64
lines changed

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

Lines changed: 86 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -6,13 +6,19 @@
66
# - janetkuo
77
# - kow3ns
88
title: 데몬셋
9+
api_metadata:
10+
- apiVersion: "apps/v1"
11+
kind: "DaemonSet"
12+
description: >-
13+
데몬셋은 노드 로컬 기능을 제공하는 파드를 정의한다. 이러한 파드는 네트워킹 도우미 도구처럼 클러스터 운영에 필수적인 기능일 수도 있고 애드온의 일부일 수도 있다.
914
content_type: concept
1015
weight: 40
16+
hide_summary: true # Listed separately in section index
1117
---
1218

1319
<!-- overview -->
1420

15-
_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면
21+
_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 보장한다. 노드가 클러스터에 추가되면
1622
파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로
1723
수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다.
1824

@@ -35,7 +41,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
3541
YAML 파일에 데몬셋 명세를 작성할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은
3642
fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
3743

38-
{{< codenew file="controllers/daemonset.yaml" >}}
44+
{{% code_sample file="controllers/daemonset.yaml" %}}
3945

4046
YAML 파일을 기반으로 데몬셋을 생성한다.
4147

@@ -79,12 +85,12 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
7985
`.spec.template`의 레이블과 매치되는
8086
파드 셀렉터를 명시해야 한다.
8187
또한, 한 번 데몬셋이 만들어지면
82-
`.spec.selector` 는 바꿀 수 없다.
83-
파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.
88+
`.spec.selector` 는 바꿀 수 없다. 파드 셀렉터를 변형하면
89+
의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.
8490

8591
`.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.
8692

87-
* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의
93+
* `matchLabels` - [레플리케이션컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의
8894
`.spec.selector` 와 동일하게 작동한다.
8995
* `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를
9096
명시해서 보다 정교한 셀렉터를 만들 수 있다.
@@ -105,30 +111,31 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
105111

106112
## 데몬 파드가 스케줄 되는 방법
107113

108-
### 기본 스케줄러로 스케줄
109-
110-
{{< feature-state for_k8s_version="1.17" state="stable" >}}
111-
112-
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
113-
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
114-
데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다.
115-
이에 대한 이슈를 소개한다.
116-
117-
* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
118-
그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
119-
이것은 사용자에게 혼란을 준다.
120-
* [파드 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)은
121-
기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
122-
파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
123-
124-
`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신
125-
`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본
126-
스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
127-
스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에
128-
이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에
129-
원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
130-
데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
131-
데몬셋의 `spec.template` 은 변경되지 않는다.
114+
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다.
115+
데몬셋 컨트롤러는 각 적격한 노드에 파드를 생성하고
116+
파드의 `spec.affinity.nodeAffinity` 필드를 추가하여 대상 호스트와 일치시킨다.
117+
파드가 생성되면 일반적으로 기본 스케줄러가 작업을 인계받아
118+
`.spec.nodeName` 필드를 설정하여 파드를 대상 호스트에 바인딩한다.
119+
새 파드가 노드에 맞지 않으면 기본 스케줄러가 새 파드의
120+
[우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)에 따라
121+
기존 파드 중 일부를
122+
선점(제거)할 수 있다.
123+
124+
{{< note >}}
125+
데몬셋 파드가 각 노드에서 실행되는 것이 중요한 경우, 데몬셋의
126+
`.spec.template.spec.priorityClassName` 을 더 높은 우선순위를 가진
127+
[프라이어리티클래스(PriorityClass)](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)로 설정하여
128+
이러한 축출이 발생하도록 하는 것이 좋다.
129+
{{< /note >}}
130+
131+
사용자는 데몬셋의 `.spec.template.spec.schedulerName` 필드를 설정하여
132+
데몬셋의 파드에 다른 스케줄러를 지정할 수 있다.
133+
134+
`.spec.template.spec.affinity.nodeAffinity` 필드(지정된 경우)에
135+
지정된 원래 노드 어피니티는
136+
데몬셋 컨트롤러가 적격 노드를 평가할 때 고려되지만,
137+
생성된 파드에서는 적격 노드의 이름과 일치하는 노드 어피니티로
138+
대체된다.
132139

133140
```yaml
134141
nodeAffinity:
@@ -141,25 +148,40 @@ nodeAffinity:
141148
- target-host-name
142149
```
143150
144-
또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로
145-
자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를
146-
스케줄링시 `unschedulable` 노드를 무시한다.
147151
148152
### 테인트(taints)와 톨러레이션(tolerations)
149153
150-
데몬 파드는
151-
[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 존중하지만,
152-
다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에
153-
톨러레이션을 추가한다.
154+
데몬셋 컨트롤러는 데몬셋 파드에
155+
{{< glossary_tooltip text="톨러레이션" term_id="toleration" >}} 세트를 자동으로 추가한다.
156+
157+
{{< table caption="데몬셋 파드를 위한 톨러레이션" >}}
154158
155-
| 톨러레이션 키 | 영향 | 버전 | 설명 |
156-
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
157-
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
158-
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. |
159-
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | 데몬셋 파드는 기본 스케줄러에서 디스크-압박(disk-pressure) 속성을 허용한다. |
160-
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | 데몬셋 파드는 기본 스케줄러에서 메모리-압박(memory-pressure) 속성을 허용한다. |
161-
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. |
162-
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. |
159+
| 톨러레이션 키 | 영향 | 설명 |
160+
| --------------------------------------------------------------------------------------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
161+
| [`node.kubernetes.io/not-ready`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-not-ready) | `NoExecute` | 데몬셋 파드는 상태가 좋지 않거나 파드를 수용할 준비가 되지 않은 노드에 스케줄링 될 수 있다. 이러한 노드에서 실행중인 데몬셋 파드는 제거되지 않는다. |
162+
| [`node.kubernetes.io/unreachable`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-unreachable) | `NoExecute` | 데몬셋 파드는 노드 컨트롤러에서 접근할 수 없는 노드에 예약될 수 있다. 이러한 노드에서 실행 중인 데몬셋 파드는 제거되지 않는다. |
163+
| [`node.kubernetes.io/disk-pressure`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-disk-pressure) | `NoSchedule` | 데몬셋 파드는 디스크 압박 문제가 있는 노드에 예약될 수 있다. |
164+
| [`node.kubernetes.io/memory-pressure`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | 데몬셋 파드는 메모리 부족 문제가 있는 노드에 예약될 수 있다. |
165+
| [`node.kubernetes.io/pid-pressure`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | 데몬셋 파드는 프로세스 부족 문제가 있는 노드에 예약될 수 있다. |
166+
| [`node.kubernetes.io/unschedulable`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-unschedulable) | `NoSchedule` | 데몬셋 파드는 예약할 수 없는 노드에 예약될 수 있다. |
167+
| [`node.kubernetes.io/network-unavailable`](/ko/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **호스트 네트워킹을 요청하는 데몬셋 파드에만 추가되었다**, 즉, `spec.hostNetwork: true`를 가진 파드이다. 이러한 데몬셋 파드는 네트워크를 사용할 수 없는 노드에 예약될 수 있다.|
168+
169+
{{< /table >}}
170+
171+
데몬셋의 파드 템플릿에서 정의하여,
172+
데몬셋의 파드에 자체 톨러레이션을 추가할 수도 있다.
173+
174+
데몬셋 컨트롤러가
175+
`node.kubernetes.io/unschedulable:NoSchedule` 톨러레이션을 자동으로 설정하므로,
176+
쿠버네티스는 _unschedulable_ 로 표시된 노드에서 데몬셋 파드를 실행할 수 있다.
177+
178+
데몬셋을 사용하여 [클러스터 네트워킹](/ko/docs/concepts/cluster-administration/networking/)과 같은
179+
중요한 노드 수준 기능을 제공하는 경우,
180+
쿠버네티스가 데몬셋 파드를 노드가 준비되기 전에 노드에 배치하는 것이 도움이 된다.
181+
예를 들어, 이러한 특별한 허용 범위가 없으면 네트워크 플러그인이
182+
실행 중이 아니기 때문에 노드가 준비 완료로 표시되지 않고,
183+
동시에 노드가 아직 준비되지 않았기 때문에 네트워크 플레인이
184+
해당 노드에서 실행되지 않는 교착 상태에 빠질 수 있다.
163185

164186
## 데몬 파드와 통신
165187

@@ -169,12 +191,13 @@ nodeAffinity:
169191
구성되어 있다. 그들은 클라이언트들을 가지지 않는다.
170192
- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며,
171193
노드IP를 통해 파드에 접근할 수 있다.
172-
클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
194+
클라이언트는 노드IP 목록을 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
173195
- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고,
174196
그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나
175197
DNS에서 여러 A레코드를 검색한다.
176198
- **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
177-
임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다).
199+
임의의 노드의 데몬에 도달한다. [서비스 내부 트래픽 정책](/ko/docs/concepts/services-networking/service-traffic-policy/)을 사용하여
200+
동일한 노드에 있는 파드로 제한한다.
178201

179202
## 데몬셋 업데이트
180203

@@ -198,55 +221,54 @@ nodeAffinity:
198221

199222
데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다.
200223
(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬
201-
프로세스를 실행하면 몇 가지 이점 있다.
224+
프로세스를 실행하면 몇 가지 장점이 있다.
202225

203-
- 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다.
226+
- 애플리케이션과 동일한 방법으로 데몬 로그를 모니터링하고 관리할 수 있다.
204227
- 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`).
205-
- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서
206-
데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다.
228+
- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 애플리케이션 컨테이너와
229+
데몬간의 격리가 강화된다. 그러나 데몬을 파드가 아닌 컨테이너에서 실행하여 이를 달성할 수도 있다.
207230

208231
### 베어(Bare) 파드
209232

210233
직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나
211234
데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여
212235
어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를
213-
생성하는 것보다는 데몬 셋을 사용해야 한다.
236+
생성하는 것보다는 데몬셋을 사용해야 한다.
214237

215238
### 스태틱(static) 파드 {#static-pods}
216239

217-
Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
218-
[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
240+
Kubelet이 감시하는 특정 디렉터리에 파일을 작성하여 파드를 생성할 수 있다. 이것을
241+
[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 한다.
219242
데몬셋과는 다르게 스태틱 파드는 kubectl
220243
또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지
221-
않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단될 수 있다.
244+
않기 때문에 클러스터를 초기 구동(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단될 수 있다.
222245

223246
### 디플로이먼트
224247

225-
데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고,
226-
해당 파드에서는 프로세스가 종료되지 않을 것으로
227-
예상한다(예: 웹 서버).
248+
데몬셋은 파드를 생성하고 해당 파드에서는 프로세스가 종료되지 않을 것으로
249+
예상한다(예: 웹 서버, 스토리지 서버)는 점에서
250+
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하다.
228251

229-
파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
252+
파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운하고,
230253
업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
231254
디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면,
232255
파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
233256

234257
예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
235258

259+
236260
## {{% heading "whatsnext" %}}
237261

238262
* [파드](/ko/docs/concepts/workloads/pods/)에 대해 배운다.
239-
* 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
240-
컴포넌트를 기동하는데 유용한
241-
[스태틱 파드](#static-pods)에 대해 배운다.
263+
* 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트를 기동하는데 유용한
264+
[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)에 대해 배운다.
242265
* 데몬셋을 어떻게 사용하는지 알아본다.
243266
* [데몬셋 롤링 업데이트 수행하기](/ko/docs/tasks/manage-daemon/update-daemon-set/)
244267
* [데몬셋 롤백하기](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)
245268
(예를 들어, 롤 아웃이 예상대로 동작하지 않은 경우).
246269
* [쿠버네티스가 파드를 노드에 할당하는 방법](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 이해한다.
247270
* 데몬셋으로 구동되곤 하는, [디바이스 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)과
248271
[애드온](/ko/docs/concepts/cluster-administration/addons/)에 대해 배운다.
249-
* `DaemonSet`은 쿠버네티스 REST API에서 상위-수준 리소스이다.
272+
* `DaemonSet`은 쿠버네티스 REST API에서 상위 수준 리소스이다.
250273
데몬셋 API에 대해 이해하기 위해
251-
{{< api-reference page="workload-resources/daemon-set-v1" >}}
252-
오브젝트 정의를 읽는다.
274+
{{< api-reference page="workload-resources/daemon-set-v1" >}} 오브젝트 정의를 읽는다.

0 commit comments

Comments
 (0)