# 데몬셋 > 데몬셋은 노드 로컬 기능을 제공하는 파드를 정의한다. 이러한 파드는 네트워킹 도우미 도구처럼 클러스터 운영에 필수적인 기능일 수도 있고 애드온의 일부일 수도 있다. --- LLMS index: [llms.txt](/llms.txt) --- _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 보장한다. 노드가 클러스터에 추가되면 파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다. 데몬셋의 일부 대표적인 용도는 다음과 같다. - 모든 노드에서 클러스터 스토리지 데몬 실행 - 모든 노드에서 로그 수집 데몬 실행 - 모든 노드에서 노드 모니터링 데몬 실행 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. ## 데몬셋 사양 작성 ### 데몬셋 생성 YAML 파일에 데몬셋 명세를 작성할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.

    controllers/daemonset.yaml
    
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # 이 톨러레이션(toleration)은 데몬셋이 컨트롤 플레인 노드에서 실행될 수 있도록 만든다.
      # 컨트롤 플레인 노드가 이 파드를 실행해서는 안 되는 경우, 이 톨러레이션을 제거한다.
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

YAML 파일을 기반으로 데몬셋을 생성한다. ``` kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` ### 필수 필드 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 일반적인 설정파일 작업에 대한 정보는 [스테이트리스 애플리케이션 실행하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다. 데몬셋 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다. ### 파드 템플릿 `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다. `.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 와 정확히 같은 스키마를 가진다. 데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 한다([파드 셀렉터](#파드-셀렉터)를 본다). 데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)는 `Always` 를 가져야 하며, 명시되지 않은 경우 기본으로 `Always`가 된다. ### 파드 셀렉터 `.spec.selector` 필드는 파드 셀렉터이다. 이것은 [잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다. `.spec.template`의 레이블과 매치되는 파드 셀렉터를 명시해야 한다. 또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 는 바꿀 수 없다. 파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다. `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다. * `matchLabels` - [레플리케이션컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 `.spec.selector` 와 동일하게 작동한다. * `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를 명시해서 보다 정교한 셀렉터를 만들 수 있다. 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다. `.spec.selector` 는 `.spec.template.metadata.labels` 와 일치해야 한다. 이 둘이 서로 일치하지 않는 구성은 API에 의해 거부된다. ### 오직 일부 노드에서만 파드 실행 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. ## 데몬 파드가 스케줄 되는 방법 데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 데몬셋 컨트롤러는 각 적격한 노드에 파드를 생성하고 파드의 `spec.affinity.nodeAffinity` 필드를 추가하여 대상 호스트와 일치시킨다. 파드가 생성되면 일반적으로 기본 스케줄러가 작업을 인계받아 `.spec.nodeName` 필드를 설정하여 파드를 대상 호스트에 바인딩한다. 새 파드가 노드에 맞지 않으면 기본 스케줄러가 새 파드의 [우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)에 따라 기존 파드 중 일부를 선점(제거)할 수 있다.

참고:

데몬셋 파드가 각 노드에서 실행되는 것이 중요한 경우, 데몬셋의 .spec.template.spec.priorityClassName 을 더 높은 우선순위를 가진 프라이어리티클래스(PriorityClass)로 설정하여 이러한 축출이 발생하도록 하는 것이 좋다.

사용자는 데몬셋의 `.spec.template.spec.schedulerName` 필드를 설정하여 데몬셋의 파드에 다른 스케줄러를 지정할 수 있다. `.spec.template.spec.affinity.nodeAffinity` 필드(지정된 경우)에 지정된 원래 노드 어피니티는 데몬셋 컨트롤러가 적격 노드를 평가할 때 고려되지만, 생성된 파드에서는 적격 노드의 이름과 일치하는 노드 어피니티로 대체된다. ```yaml nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchFields: - key: metadata.name operator: In values: - target-host-name ``` ### 테인트(taints)와 톨러레이션(tolerations) 데몬셋 컨트롤러는 데몬셋 파드에 세트를 자동으로 추가한다.

데몬셋 파드를 위한 톨러레이션
톨러레이션 키	영향	설명
`node.kubernetes.io/not-ready`	`NoExecute`	데몬셋 파드는 상태가 좋지 않거나 파드를 수용할 준비가 되지 않은 노드에 스케줄링 될 수 있다. 이러한 노드에서 실행중인 데몬셋 파드는 제거되지 않는다.
`node.kubernetes.io/unreachable`	`NoExecute`	데몬셋 파드는 노드 컨트롤러에서 접근할 수 없는 노드에 예약될 수 있다. 이러한 노드에서 실행 중인 데몬셋 파드는 제거되지 않는다.
`node.kubernetes.io/disk-pressure`	`NoSchedule`	데몬셋 파드는 디스크 압박 문제가 있는 노드에 예약될 수 있다.
`node.kubernetes.io/memory-pressure`	`NoSchedule`	데몬셋 파드는 메모리 부족 문제가 있는 노드에 예약될 수 있다.
`node.kubernetes.io/pid-pressure`	`NoSchedule`	데몬셋 파드는 프로세스 부족 문제가 있는 노드에 예약될 수 있다.
`node.kubernetes.io/unschedulable`	`NoSchedule`	데몬셋 파드는 예약할 수 없는 노드에 예약될 수 있다.
`node.kubernetes.io/network-unavailable`	`NoSchedule`	호스트 네트워킹을 요청하는 데몬셋 파드에만 추가되었다, 즉, `spec.hostNetwork: true`를 가진 파드이다. 이러한 데몬셋 파드는 네트워크를 사용할 수 없는 노드에 예약될 수 있다.

데몬셋의 파드 템플릿에서 정의하여, 데몬셋의 파드에 자체 톨러레이션을 추가할 수도 있다. 데몬셋 컨트롤러가 `node.kubernetes.io/unschedulable:NoSchedule` 톨러레이션을 자동으로 설정하므로, 쿠버네티스는 _unschedulable_ 로 표시된 노드에서 데몬셋 파드를 실행할 수 있다. 데몬셋을 사용하여 [클러스터 네트워킹](/ko/docs/concepts/cluster-administration/networking/)과 같은 중요한 노드 수준 기능을 제공하는 경우, 쿠버네티스가 데몬셋 파드를 노드가 준비되기 전에 노드에 배치하는 것이 도움이 된다. 예를 들어, 이러한 특별한 허용 범위가 없으면 네트워크 플러그인이 실행 중이 아니기 때문에 노드가 준비 완료로 표시되지 않고, 동시에 노드가 아직 준비되지 않았기 때문에 네트워크 플레인이 해당 노드에서 실행되지 않는 교착 상태에 빠질 수 있다. ## 데몬 파드와 통신 데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다. - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 구성되어 있다. 그들은 클라이언트들을 가지지 않는다. - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP 목록을 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. - **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 검색한다. - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 임의의 노드의 데몬에 도달한다. [서비스 내부 트래픽 정책](/ko/docs/concepts/services-networking/service-traffic-policy/)을 사용하여 동일한 노드에 있는 파드로 제한한다. ## 데몬셋 업데이트 만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 일치하지 않는 노드에서 파드를 삭제한다. 사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다. 사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=orphan` 를 명시하면 파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, 새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 `updateStrategy` 에 따라 파드를 교체한다. 사용자는 데몬셋에서 [롤링 업데이트를 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)할 수 있다. ## 데몬셋의 대안 ### 초기화 스크립트 데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다. (예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 프로세스를 실행하면 몇 가지 장점이 있다. - 애플리케이션과 동일한 방법으로 데몬 로그를 모니터링하고 관리할 수 있다. - 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`). - 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 애플리케이션 컨테이너와 데몬간의 격리가 강화된다. 그러나 데몬을 파드가 아닌 컨테이너에서 실행하여 이를 달성할 수도 있다. ### 베어(Bare) 파드 직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여 어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 생성하는 것보다는 데몬셋을 사용해야 한다. ### 스태틱(static) 파드 {#static-pods} Kubelet이 감시하는 특정 디렉터리에 파일을 작성하여 파드를 생성할 수 있다. 이것을 [스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 한다. 데몬셋과는 다르게 스태틱 파드는 kubectl 또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 않기 때문에 클러스터를 초기 구동(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단될 수 있다. ### 디플로이먼트 데몬셋은 파드를 생성하고 해당 파드에서는 프로세스가 종료되지 않을 것으로 예상한다(예: 웹 서버, 스토리지 서버)는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하다. 파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운하고, 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면, 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다. 예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다. ## 다음 내용 * [파드](/ko/docs/concepts/workloads/pods/)에 대해 배운다. * 쿠버네티스 컴포넌트를 기동하는데 유용한 [스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)에 대해 배운다. * 데몬셋을 어떻게 사용하는지 알아본다. * [데몬셋 롤링 업데이트 수행하기](/ko/docs/tasks/manage-daemon/update-daemon-set/) * [데몬셋 롤백하기](/ko/docs/tasks/manage-daemon/rollback-daemon-set/) (예를 들어, 롤 아웃이 예상대로 동작하지 않은 경우). * [쿠버네티스가 파드를 노드에 할당하는 방법](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 이해한다. * 데몬셋으로 구동되곤 하는, [디바이스 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)과 [애드온](/ko/docs/concepts/cluster-administration/addons/)에 대해 배운다. * `DaemonSet`은 쿠버네티스 REST API에서 상위 수준 리소스이다. 데몬셋 API에 대해 이해하기 위해 오브젝트 정의를 읽는다.