☁️ 클라우드

DaemonSet

Kubernetes DaemonSet

모든 노드에 Pod를 실행하는 Kubernetes 리소스. 로그 수집, 모니터링 에이전트에 활용.

📖 상세 설명

DaemonSet은 Kubernetes 클러스터의 모든 노드(또는 선택된 노드)에 정확히 하나의 Pod 복제본을 실행하도록 보장하는 워크로드 리소스입니다. 새 노드가 클러스터에 추가되면 자동으로 해당 노드에 Pod가 생성되고, 노드가 제거되면 해당 Pod도 함께 정리됩니다.

전통적인 서버 환경에서는 각 호스트에 에이전트를 수동으로 설치하거나 Ansible 같은 구성 관리 도구를 사용했습니다. DaemonSet은 이러한 "노드당 하나의 프로세스" 패턴을 Kubernetes 네이티브하게 구현하여, 선언적 관리와 자동 스케일링의 이점을 제공합니다.

DaemonSet은 kube-scheduler를 거치지 않고 DaemonSet 컨트롤러가 직접 노드에 Pod를 할당합니다. 이 때문에 다른 워크로드보다 먼저 실행되어야 하는 시스템 컴포넌트(CNI, CSI 플러그인 등)에 적합합니다. 또한 nodeSelector, nodeAffinity, tolerations를 통해 특정 노드 그룹에만 Pod를 배포할 수 있습니다.

실무에서 DaemonSet은 로그 수집기(Fluentd, Fluent Bit), 메트릭 수집기(Node Exporter, Datadog Agent), 네트워크 플러그인(Calico, Cilium), 스토리지 드라이버, 보안 에이전트(Falco) 등 클러스터 인프라의 핵심 컴포넌트로 광범위하게 사용됩니다.

💻 코드 예제

# Fluent Bit 로그 수집 DaemonSet 예제
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
  labels:
    app: fluent-bit
spec:
  selector:
    matchLabels:
      app: fluent-bit
  template:
    metadata:
      labels:
        app: fluent-bit
    spec:
      serviceAccountName: fluent-bit
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:2.2
        ports:
        - containerPort: 2020
          name: metrics
        volumeMounts:
        - name: varlog
          mountPath: /var/log
          readOnly: true
        - name: containers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: config
          mountPath: /fluent-bit/etc/
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
          limits:
            cpu: 200m
            memory: 128Mi
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: containers
        hostPath:
          path: /var/lib/docker/containers
      - name: config
        configMap:
          name: fluent-bit-config
      tolerations:
      - operator: Exists  # 모든 taint 허용

🗣️ 실무에서 이렇게 말하세요

💬 회의에서
"모든 노드에서 로그를 수집해야 하니까 Fluent Bit을 DaemonSet으로 배포합시다. tolerations에 Exists를 넣으면 taint된 노드에서도 실행되어서 GPU 노드나 인그레스 전용 노드 로그도 놓치지 않아요."
💬 면접에서
"DaemonSet과 Deployment의 차이점을 말씀드리면, Deployment는 replicas 수만큼 Pod를 생성하고 노드 배치는 스케줄러가 결정합니다. 반면 DaemonSet은 노드당 정확히 하나의 Pod를 보장하며, 노드 추가/삭제에 따라 자동으로 Pod 수가 조절됩니다."
💬 장애 대응에서
"특정 노드에서 DaemonSet Pod가 안 뜨는 원인을 확인해보니, 해당 노드에 taint가 걸려있는데 DaemonSet에 해당 tolerations가 없어서였습니다. 노드 Exporter가 누락되어 해당 노드 메트릭이 수집 안 된 거예요."

⚠️ 흔한 실수 & 주의사항

tolerations 미설정

기본적으로 DaemonSet도 taint를 피합니다. master/control-plane 노드나 전용 노드 풀에 Pod가 배포되지 않아 로그/메트릭 누락이 발생합니다. 시스템 DaemonSet에는 적절한 tolerations를 반드시 추가하세요.

리소스 요청 미설정

DaemonSet Pod도 리소스를 사용합니다. requests를 설정하지 않으면 노드별 리소스 계획에 포함되지 않아, 실제 워크로드 배포 시 리소스 부족이 발생할 수 있습니다. 특히 노드 수가 많을수록 총 리소스 사용량이 커집니다.

올바른 접근법

시스템 DaemonSet에는 priorityClassName: system-node-critical을 설정하여 다른 워크로드보다 우선 실행되도록 하고, updateStrategy.rollingUpdate.maxUnavailable을 적절히 설정해서 업데이트 중에도 가용성을 유지하세요.

🔗 관련 용어

📚 더 배우기