Kubernetes DaemonSet 운영 Worker / Master 노드 스케줄링 구조

Kubernetes에서 DaemonSet은 “클러스터의 모든 노드 또는 특정 조건의 노드에 동일한 Pod을 하나씩 배포”하기 위한 워크로드입니다. 하지만 마스터 노드(Control Plane 노드) 에서 DaemonSet을 생성했다고 해서 자동으로 모든 노드에 무조건 적용되는 것은 아닙니다.

실제 동작은 다음 3가지 요소에 의해 결정됩니다.

기본 개념: DaemonSet의 배포 방식

DaemonSet은 각 노드마다 1개의 Pod을 자동 배포하는 컨트롤러입니다.

예를 들어 아래와 같은 구조입니다.

Cluster
 ├─ Node1  → Pod (DaemonSet)
 ├─ Node2  → Pod (DaemonSet)
 ├─ Node3  → Pod (DaemonSet)
 └─ Node4  → Pod (DaemonSet)

즉 클러스터에 노드가 10개 있으면 Pod도 10개 생성됩니다.

대표적인 사용 사례

사용 목적	예
로그 수집	fluentd
모니터링	node-exporter
네트워크	calico-node
보안 에이전트	Falco, Wazuh agent

“마스터 노드에서 생성” ≠ “마스터에만 배포”

Kubernetes에서 리소스는 노드에 생성되는 것이 아니라 API Server에 등록됩니다.

다음 명령을 실행하면

kubectl apply -f daemonset.yaml

이 작업은

kubectl client
    ↓
API Server
    ↓
Scheduler / Controller
    ↓
각 Node

Control Plane에서 실행했더라도 클러스터 전체에 적용됩니다.

300x250

즉 명령을 실행한 노드 위치는 중요하지 않습니다.

실제로는 마스터 노드에는 배포 안되는 경우가 많음

대부분 Kubernetes 클러스터에서는 Control Plane Node에 Taint가 걸려 있습니다.

예

kubectl describe node master

출력

Taints:
node-role.kubernetes.io/control-plane:NoSchedule

또는

node-role.kubernetes.io/master:NoSchedule

이 의미는

이 노드에는 일반 Pod 스케줄링 금지

그래서 기본적으로는

DaemonSet → Worker Node에만 생성

됩니다.

예

Cluster
 ├─ master node (NoSchedule)
 ├─ worker1
 ├─ worker2
 └─ worker3

DaemonSet 결과

worker1 → Pod
worker2 → Pod
worker3 → Pod
master  → 없음

마스터 노드에도 배포하려면 (toleration 필요)

DaemonSet YAML에 toleration을 추가해야 합니다.

예

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  selector:
    matchLabels:
      app: my-daemon
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"

      containers:
      - name: my-daemon
        image: busybox
        command: ["sleep","3600"]

또는 control-plane

tolerations:
- key: "node-role.kubernetes.io/control-plane"
  operator: "Exists"
  effect: "NoSchedule"

그러면 결과

master → Pod
worker1 → Pod
worker2 → Pod
worker3 → Pod

특정 노드만 배포 (nodeSelector / affinity)

보안 에이전트나 특수 작업의 경우 노드 필터링도 합니다.

예

nodeSelector:
  node-role.kubernetes.io/worker: ""

또는

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node-type
          operator: In
          values:
          - security-node

보안 관점에서 DaemonSet 활용 사례

EDR / Security Agent

Falco
Wazuh Agent
CrowdStrike Sensor
Aqua / Prisma Defender

구조

DaemonSet
 ├─ Node1 → Security Agent
 ├─ Node2 → Security Agent
 ├─ Node3 → Security Agent
 └─ Node4 → Security Agent

수집 데이터

syscall
container runtime
k8s audit
network activity
process

운영 점검 포인트 (Security / Ops)

보안 운영에서는 DaemonSet을 특히 주의해서 관리해야 합니다.

privileged 여부

securityContext:
  privileged: true

이 경우

Host OS 접근 가능

→ 보안 리스크

hostPath 사용 여부

volumeMounts:
- mountPath: /var/run/docker.sock
  name: docker-sock

→ container escape 위험

hostNetwork

hostNetwork: true

→ 네트워크 sniffing 가능

hostPID

hostPID: true

→ 다른 프로세스 접근 가능

실제 운영 예시 (node-exporter)

Prometheus 환경에서 많이 쓰는 DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prom/node-exporter

결과

Node1 → node-exporter
Node2 → node-exporter
Node3 → node-exporter
Node4 → node-exporter

질문	답
마스터 노드에서 DaemonSet 배포하면 모든 노드 적용?	✔ 클러스터 전체 대상
모든 노드에 무조건 배포?	❌ 아님
마스터 노드 포함 여부	Taint / Toleration에 따라 다름
기본 설정	Worker Node만

DaemonSet은 클러스터의 모든 노드에 Pod을 배포하는 컨트롤러지만, Control Plane 노드의 taint 때문에 기본적으로는 Worker 노드에만 배포됩니다.