[CKAD] DaemonSet: 노드 레벨 인프라 에이전트의 보장된 배포 및 관리

안녕하세요! 오늘은 쿠버네티스에서 워크로드를 관리하는 4대장 중, 조금은 특별한 임무를 수행하는 친구를 만나볼 시간입니다. 웹 서버나 API 서버처럼 트래픽에 따라 늘었다 줄었다 하는 녀석이 아닙니다. 묵묵히 모든 노드(서버)에 하나씩 존재해야만 하는 인프라 레벨의 파수꾼, 바로 데몬셋(DaemonSet)입니다. 🛡️

CKAD 시험에서도 종종 "특정 노드들에만 로그 수집기를 배포하시오"와 같은 형태로 출제되곤 하니, 오늘 15분만 투자해서 확실하게 개념을 잡아보자구요!

---

 

1. 들어가며: 왜 모든 노드에 파드가 필요할까요? 🤔

우리가 일반적으로 사용하는 디플로이먼트(Deployment)는 "우리 서비스 파드를 3개 띄워줘!"라고 요청하면, 스케줄러가 알아서 자원이 남는 노드에 적절히 배치합니다. 한 노드에 2개가 뜰 수도 있고, 3개가 다 다른 노드에 뜰 수도 있죠.

하지만 상황을 바꿔볼까요?

여러분에게 100대의 서버(노드)로 이루어진 쿠버네티스 클러스터가 있습니다. 이 100대의 서버에서 발생하는 시스템 로그를 모두 수집해야 한다고 가정해 봅시다.

• 디플로이먼트로 replicas: 100을 설정하면 될까요?
  • 👉 아닙니다! 운이 나쁘면 어떤 노드엔 로그 수집기가 2개 뜨고, 어떤 노드엔 하나도 안 뜰 수 있습니다.

이럴 때 필요한 것이 바로 "클러스터의 모든 노드(또는 특정 조건을 만족하는 노드)에 파드 사본이 정확히 하나씩 실행되도록 보장"하는 컨트롤러, 데몬셋(DaemonSet)입니다.

2. DaemonSet의 주요 임무 (Use Cases) 🛠️

데몬셋은 보통 애플리케이션 로직보다는 인프라 스트럭처 레벨의 작업을 수행하는 데 사용됩니다. 노드 자체를 관리하거나 모니터링하는 "에이전트(Agent)" 역할이 주된 임무죠.

대표적인 사용 사례는 다음과 같습니다:

1. 📝 로그 수집 데몬 실행:
   • 각 노드에서 발생하는 컨테이너 로그나 시스템 로그를 수집해서 중앙 로그 저장소(Elasticsearch, Loki 등)로 전송합니다.
   • 예시: Fluentd, Fluent Bit, Filebeat
2. 📊 모니터링 데몬 실행:
   • 각 노드의 CPU, 메모리, 디스크 사용량 등 노드 자체의 상태 정보를 수집합니다.
   • 예시: Prometheus Node Exporter, Datadog Agent
3. 🌐 클러스터 스토리지 데몬 및 네트워크 플러그인:
   • 각 노드에서 스토리지를 마운트 할 수 있게 돕거나, 노드 간 네트워크 통신을 담당하는 CNI 플러그인을 실행합니다.
   • 예시: Glusterd, Ceph, Calico, Flannel

💡 핵심 요약: 노드가 클러스터에 새로 추가되면 데몬셋이 알아서 파드를 생성해주고, 노드가 제거되면 파드도 같이 정리해줍니다. 정말 든든한 파수꾼이죠?

3. CKAD 실전! YAML로 만나는 DaemonSet 📄

백문이 불여일견! 실제 코드를 보면서 디플로이먼트와 어떤 점이 다른지 살펴봅시다.

가장 큰 차이점은 replicas 필드가 없다는 것입니다. 개수는 노드의 수가 결정하니까요!

아래는 모든 노드에 fluentd라는 로그 수집기를 배포하는 간단한 데몬셋 예시입니다.

apiVersion: apps/v1
kind: DaemonSet  # 👈 종류는 DaemonSet 입니다.
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system # 보통 인프라 관련은 kube-system에 배포합니다.
  labels:
    k8s-app: fluentd-logging
spec:
  # replicas: 3  👈 Deployment와 달리 이 필드가 없습니다!
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template: # 여기서부터는 파드 템플릿과 동일합니다.
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      # 노드의 시스템 로그 경로를 파드에 마운트하는 설정 (예시)
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
      # 마스터 노드(컨트롤 플레인)에도 배포되게 하려면 테인트 용인이 필요할 수 있습니다.
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule

4. CKAD 심화: "특정 노드에만 배포하고 싶어요!" (Node Selector) 🎯

CKAD 시험에서는 단순히 데몬셋을 만드는 것보다, 조건을 주는 경우가 많습니다.

"GPU가 달려있는 노드들에만 모니터링 에이전트를 DaemonSet으로 배포하세요."

기본적으로 데몬셋은 모든 노드에 배포되지만, nodeSelector나 affinity를 사용하면 특정 레이블(Label)을 가진 노드에만 파드를 띄울 수 있습니다.

 

예시 시나리오: 노드들 중 type=gpu-node 라는 레이블이 붙은 노드에만 배포하고 싶다면?

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: gpu-monitor
spec:
  selector:
    matchLabels:
      app: gpu-monitor
  template:
    metadata:
      labels:
        app: gpu-monitor
    spec:
      # 👇 이 부분이 핵심입니다!
      nodeSelector:
        type: gpu-node
      containers:
      - name: nvidia-gpu-exporter
        image: nvidia/gpu-monitoring-tools
        # ... 생략 ...

이렇게 설정하면 데몬셋 컨트롤러는 클러스터의 노드 중 type=gpu-node 레이블을 가진 노드만 골라서 파드를 하나씩 생성해 줍니다. 아주 스마트하죠? 🧠

5. 데몬셋의 업데이트 전략 (RollingUpdate vs OnDelete) 🔄

데몬셋으로 배포된 파드의 이미지를 변경하면 어떻게 될까요? 디플로이먼트와 마찬가지로 데몬셋도 업데이트 전략을 가지고 있습니다.

• RollingUpdate (기본값):
  • 가장 권장되는 방식입니다. 디플로이먼트처럼 한 번에 모든 파드를 죽이지 않고, 노드 하나씩 순차적으로 구버전 파드를 삭제하고 신버전 파드를 생성합니다. 서비스 중단 없이 인프라 에이전트를 업데이트할 수 있습니다.
  • maxUnavailable 설정을 통해 동시에 몇 개의 노드까지 업데이트를 진행할지(파드가 잠시 없어도 되는지) 제어할 수 있습니다 (기본값 1).
• OnDelete:
  • 이름 그대로 "삭제될 때" 업데이트합니다. 템플릿을 수정해도 이미 실행 중인 파드는 변하지 않습니다.
  • 운영자가 수동으로 해당 노드의 파드를 kubectl delete pod ...로 삭제해야만, 데몬셋 컨트롤러가 새로운 버전의 파드를 생성합니다. 업데이트 시점을 완전히 수동으로 통제하고 싶을 때 사용합니다.

6. 정리하며: CKAD 시험장 꿀팁 🍯

DaemonSet은 개념만 확실히 잡으면 디플로이먼트만큼이나 쉽습니다.

1. 목적 기억하기: "서비스 확장(Scaling)"이 아니라 "노드당 하나씩 인프라 관리"가 목적입니다.
2. YAML 구조: replicas가 없다는 점을 꼭 기억하세요.
3. 노드 선택: 시험에서 "특정 노드에만 배포하라"는 요구사항이 나오면 당황하지 말고 파드 템플릿(spec.template.spec) 안에 nodeSelector를 추가하세요.
4. Toleration: 혹시 마스터 노드에도 배포가 되어야 한다면, 마스터 노드의 Taint를 견딜 수 있는 tolerations 설정이 필요할 수 있다는 점을 염두에 두세요. (최신 버전은 자동으로 추가되기도 하지만, 명시적인 게 좋습니다.)

---

오늘 배운 데몬셋, 어떠셨나요? 클러스터를 안정적으로 유지하기 위해 보이지 않는 곳에서 열일하는 든든한 지원군 같지 않나요? 👮‍♂️

CKAD 시험 준비하시면서 궁금한 점이 있다면 언제든 질문해 주세요. 여러분의 합격을 진심으로 응원합니다! 화이팅! 💪

---