89. 데몬셋 (DaemonSet) - 클러스터 백그라운드 워커

⚠️ 이 문서는 쿠버네티스(Kubernetes) 환경에서 특정 파드를 "원하는 개수만큼 아무 서버에나 띄워 줘"라고 하는 일반적인 디플로이먼트(Deployment) 방식과 달리, **"우리 클러스터에 존재하는 '모든 워커 노드(서버)'마다 단 1개의 파드는 무조건 찰거머리처럼 백그라운드에 붙어있어야 해!"라고 강제할 때 사용하는 특수 목적의 컨트롤러인 '데몬셋'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 리눅스의 백그라운드 서비스인 '데몬(Daemon)' 개념을 쿠버네티스로 가져온 것이다. 내가 100대의 서버를 운영 중이라면, 데몬셋을 통해 배포한 파드는 자동으로 100대 서버 전체에 각각 1개씩 똑같이 배포된다.
  2. 가치: 클러스터에 새로운 서버(노드)를 추가하는 순간, 관리자가 명령을 내리지 않아도 귀신같이 알아채고 새 서버에 파드를 하나 띄워준다. 서버를 줄이면 알아서 지워진다. 인프라 관리가 극도로 편해진다.
  3. 기술 체계: 사용자 트래픽을 처리하는 웹 서버(Nginx 등) 용도로는 절대 쓰지 않으며, 각 서버의 로그를 긁어모으는 수집기(Fluentd)나 서버의 CPU 사용량을 감시하는 에이전트(Prometheus Node Exporter) 같은 **'인프라 공통 감시/지원 기능'**을 배포할 때만 전용으로 쓰인다.

Ⅰ. 디플로이먼트(Deployment) 배포의 한계

일반적인 배포 방식은 '어느 서버에 뜰지' 내 맘대로 정할 수 없다.

  1. 스케줄러의 변덕:
    • 디플로이먼트로 파드 3개를 띄워달라고 하면, 쿠버네티스의 스케줄러는 서버들의 램과 CPU 여유 상태를 보고 무작위로 파드를 던진다.
    • 재수가 없으면 1번 서버에 파드 3개가 다 몰려 떠버리고, 2번 서버와 3번 서버에는 파드가 하나도 안 뜰 수도 있다. (자원 효율성 목적)
  2. 모든 서버에 파드를 하나씩 박아야 하는 상황:
    • 서버들의 에러 로그를 수집하는 '로그 수집 로봇(Fluentd)'을 띄운다고 가정하자.
    • 로그 수집 로봇이 1번 서버에 3개가 몰려있고 2, 3번 서버에 없다면, 2, 3번 서버에서 터지는 에러 로그는 영영 수집할 길이 없다.
    • 로그 수집기는 반드시 모든 서버에 정확히 1대씩만, 예외 없이 깔려 있어야 한다.

📢 섹션 요약 비유: 디플로이먼트가 배달 앱 기사들을 시내에 '수요가 많은 지역 위주로 유동적으로' 3명 배치하는 것이라면, 데몬셋은 동네마다 무조건 1개씩 세워져 있어야만 제 역할을 하는 '가로등'이나 '우체통'을 각 구역(서버 노드)마다 억지로 하나씩 강제로 박아 넣는 인프라 건설 작업입니다.

Ⅱ. 데몬셋의 독특한 동작 원리와 쓰임새

데몬셋은 일반적인 스케줄러의 눈치를 보지 않고 독자 행동을 한다.

  1. 자동 노드 스케일링 동기화:
    • 10대의 서버가 있을 때 데몬셋을 띄우면 알아서 10개의 파드가 1개씩 뜬다.
    • 트래픽이 몰려 서버(노드)를 20대로 급격히 늘렸다. 관리자는 파드를 더 띄워달라고 명령할 필요가 없다. 새 서버가 켜지는 순간, 쿠버네티스가 데몬셋 파드를 새 서버들에 자동으로 주입(Inject)해 버린다.
  2. 노드 셀렉터 (Node Selector/Affinity)의 결합:
    • 꼭 클러스터 전체(100대)에 다 띄워야만 하는 것은 아니다.
    • "서버 100대 중에서 GPU가 꽂혀있는 서버 10대에만 이 모니터링 파드를 1개씩 띄워라" 같은 조건부 데몬셋(특정 라벨을 가진 노드에만 배포)도 완벽하게 지원한다.
  3. 데몬셋의 3대 단골손님 (Use Cases):
    • 로그 수집 (Log Shippers): Fluentd, Logstash 등 컨테이너들의 로그를 중앙으로 쏴주는 에이전트.
    • 모니터링 (Monitoring Agents): Datadog Agent, Prometheus Node Exporter 등 각 서버의 CPU/RAM 상태를 읽어가는 스파이.
    • 네트워크/스토리지 플러그인: CNI(Calico 등)나 CSI 플러그인처럼 서버의 기본 네트워크와 디스크를 관장하는 커널급 데몬.

📢 섹션 요약 비유: 데몬셋은 아파트(클러스터)를 관리하기 위해 각 동(서버 노드)의 1층 경비실마다 무조건 1명씩 의무적으로 파견하는 '경비 아저씨(모니터링, 로그 수집)'입니다. 아파트 단지가 새로 1개 동을 더 지으면, 본사(쿠버네티스)에서 알아서 그 새 동의 경비실에도 경비 아저씨를 1명 추가로 보내 줌으로써 치안 공백을 자동으로 메워줍니다.

Ⅲ. 업데이트 (Update)와 주의 사항

무거운 인프라 파드들이기 때문에 조심해서 업데이트해야 한다.

  1. 롤링 업데이트 (Rolling Update) 지원:
    • 데몬셋도 디플로이먼트처럼 버전 1에서 버전 2로 넘어갈 때 롤링 업데이트가 가능하다.
    • 단, 데몬셋은 한 노드당 1개만 떠 있어야 하므로, '먼저 구버전 파드를 죽이고 $\rightarrow$ 그 자리에 신버전 파드를 띄우는' 순서를 철저히 지키며 100대의 노드를 한 땀 한 땀 돌면서 업데이트를 수행한다.
  2. 자원(Resource) 할당의 주의점:
    • 데몬셋으로 띄운 로깅 파드가 버그가 나서 한 서버의 CPU를 100% 갉아먹으면, 그 서버에서 돌아가고 있던 진짜 중요한 고객용 '웹 서버 파드'들이 함께 멈춰버리는 대형 사고가 난다.
    • 따라서 데몬셋 매니페스트(yaml)를 짤 때는 반드시 **resources.limits (메모리와 CPU 사용량 최대치 제한)**를 아주 빡빡하게 걸어두어, 데몬셋이 본분을 잊고 주인(서버)을 잡아먹지 못하게 목줄을 채워야 한다.

📢 섹션 요약 비유: 각 동마다 배치된 경비 아저씨(데몬셋)의 옷을 신형 유니폼으로 갈아입힐 때(업데이트), 100개 동 아저씨들을 한 번에 홀딱 벗기면 경비 공백이 생기니 한 동씩 차례대로 옷을 갈아입힙니다. 그리고 경비 아저씨가 너무 열정적으로 일하느라 전기를 펑펑 써서 아파트 전체 누전(CPU 고갈)이 나면 안 되므로, 초소에서 쓸 수 있는 난로(리소스 리미트)의 전력량을 엄격하게 1단으로 고정해 두어야 합니다.