Scheduling- DaemonSet

ReplicaSet/Deployment가 “원하는 개수(replicas)의 파드를 유지”하는 컨트롤러라면, DaemonSet은 목표가 다릅니다.

• 클러스터의 각 노드마다 파드 1개를 유지합니다.
• 노드가 늘어나면 새 노드에 자동으로 1개가 추가
• 노드가 줄어들면 해당 노드의 파드는 자동으로 제거

즉, DaemonSet은 “replicas=노드 개수”라고 생각하면 이해가 쉽습니다.

---

1) DaemonSet이 필요한 이유: 대표 사용 사례

DaemonSet이 빛을 발하는 영역은 “노드 단위로 반드시 있어야 하는 에이전트”입니다.

1) 모니터링 에이전트 / 로그 수집기

각 노드에서 시스템/컨테이너 로그를 수집하거나 메트릭을 올리는 에이전트가 필요할 때:

• 노드가 추가될 때마다 수동으로 설치/배포하면 운영이 어렵습니다.
• DaemonSet으로 배포하면 노드 변화에 자동 대응합니다.

예: node-exporter, fluent-bit/fluentd, datadog agent, dynatrace oneagent(환경별) 등

2) kube-proxy 같은 노드 구성요소

클러스터의 모든 노드에 공통으로 필요한 컴포넌트(네트워킹 프록시)는 DaemonSet으로 배포되는 형태가 많습니다.

• (환경에 따라 다르지만) kube-proxy는 DaemonSet으로 운영되는 대표 케이스입니다.

3) CNI 플러그인(예: Calico)

Calico 같은 네트워킹 솔루션은 노드마다 에이전트를 띄워야 합니다.
그래서 DaemonSet이 자연스러운 배포 형태입니다.

---

2) DaemonSet 매니페스트 구조: ReplicaSet과 거의 같다

DaemonSet은 구조적으로 ReplicaSet과 매우 유사합니다.

• spec.selector: “내가 관리할 Pod는 어떤 라벨인가?”
• spec.template: “그 라벨을 가진 Pod를 이렇게 만들겠다”

핵심 규칙:

• selector의 라벨과 template의 라벨이 반드시 일치해야 합니다.

예시: monitoring agent DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-daemon
spec:
  selector:
    matchLabels:
      app: monitoring-agent
  template:
    metadata:
      labels:
        app: monitoring-agent
    spec:
      containers:
      - name: agent
        image: nginx:1.27

(실제로는 agent 이미지, 볼륨 마운트, 권한 등이 들어가지만 형태는 동일합니다.)

---

3) 생성/조회/디버깅 기본 커맨드

생성

kubectl apply -f daemonset.yaml

조회

kubectl get daemonset
kubectl get ds

상세 확인

kubectl describe daemonset monitoring-daemon

실제로 각 노드에 깔렸는지 확인

kubectl get pods -o wide -l app=monitoring-agent

-o wide로 어느 노드에 올라갔는지 한 번에 확인 가능합니다.

---

4) DaemonSet은 각 노드에 파드를 “어떻게” 스케줄링하나?

강의가 던지는 핵심 질문은 이거였습니다.

“모든 노드에 파드를 하나씩 배치하려면 결국 노드별로 파드를 스케줄해야 하는데, 어떻게 하지?”

(과거 방식) Pod의 spec.nodeName으로 강제 배치

이전 강의에서 봤던 것처럼, 파드의 nodeName을 지정하면 스케줄러를 우회해 특정 노드에 붙일 수 있습니다.
과거에는 DaemonSet 구현이 이런 방식에 가깝게 동작하던 시기가 있었습니다.

(현재 방식) 기본 스케줄러 + Node Affinity 기반

강의 내용 기준으로는 Kubernetes v1.12 이후부터 DaemonSet은:

• 기본 스케줄러
• 노드 선호도(Node Affinity) 규칙

을 활용해서 각 노드에 배치되도록 동작합니다.

실무적으로 이해를 단순화하면:

• DaemonSet 컨트롤러가 “각 노드에 하나씩 있어야 한다”는 조건을 만족하도록
• 스케줄러가 배치 결정을 할 수 있게 적절한 제약/요구 조건을 설정해 주고
• 그 결과로 각 노드에 1개씩 파드가 유지됩니다.

---

5) 시험/운영에서 자주 나오는 포인트

1) “왜 replicas가 없지?”

DaemonSet에는 보통 Deployment처럼 replicas를 직접 지정하지 않습니다.
목표는 “노드마다 1개”라서 replicas는 노드 수에 의해 결정됩니다.

2) “특정 노드에는 깔고 싶지 않다”

실무에서는 control-plane 노드 제외, GPU 노드만 포함 등 조건이 필요합니다.
이때는 보통:

• nodeSelector / nodeAffinity
• taints/tolerations
  조합으로 범위를 조절합니다.

(이 부분은 강의 다음 범위와도 자연스럽게 연결됩니다.)

---

정리

• DaemonSet = 클러스터의 각 노드에 파드 1개씩 유지
• 노드 추가/제거에 따라 파드도 자동으로 따라붙고 사라짐
• 대표 사용처: 모니터링/로그 수집 에이전트, kube-proxy, CNI 에이전트(Calico 등)
• 구조는 ReplicaSet과 유사하며 selector ↔ template 라벨 일치가 핵심
• v1.12 이후에는 기본 스케줄러/노드 선호도 규칙을 활용해 배치

 

**팁

ReplicaSet, DaemonSet은 kubectl create 같은 명령어로 바로 만들 수 없어 kubectl create deployment ... > fluentd.yaml로 만든 뒤 필요한 내용 수정하면 간단히 yaml 만들 수 있음.

 

Practice Test: https://uklabs.kodekloud.com/topic/practice-test-daemonsets-2/