1. 데몬 서비스 패턴 개요

1) 데몬 서비스 패턴

• 인프라 중심 파드의 우선 배치 클러스터 운영자가 쿠버네티스 플랫폼 기능을 확장하거나, 노드 단위로 특화된 작업을 실행할 때 활용합니다.
  

2) 데몬 서비스

• 쿠버네티스는 기본적으로 Pod를 여러 노드에 분산 스케줄링하지만, 모든 노드에서 상시 실행이 필요한 관리 작업이 있습니다.
  
• 대표 사례
  • 로그 수집 에이전트: Fluentd, Promtail
  • 노드 모니터링: Prometheus Node Exporter 등
  • 네트워크 관리 컴포넌트: kube-proxy, CNI 플러그인
• 이러한 작업을 자동화하고 각 노드에서 지속 실행하기 위해 DaemonSet 리소스를 사용합니다.

3) DaemonSet 개념

• 각 노드마다 1개의 Pod를 자동 배치·관리하는 쿠버네티스 리소스.
• 주요 특징
  • 새로운 노드가 추가/삭제되면 자동으로 Pod 생성/삭제
  • 모든 노드에서 동일한 에이전트가 항상 실행되는 상태를 보장

2. 설계시 고려사항

• 자원 격리(Resource Requests/Limits) 모든 노드에 Pod가 배포되므로 CPU·메모리 사용량을 반드시 제한해야 합니다.
  
• Node Selector & Tolerations 특정 노드에만 배치하려면 nodeSelector·nodeAffinity·tolerations를 적절히 설정해야 합니다.
  
• Rolling Update 전략 에이전트 버전 변경 시 안정적 업그레이드를 위해 updateStrategy와 maxUnavailable을 활용합니다.
  
• 보안 정책 호스트 네임스페이스·디스크 마운트 등을 다루므로 RBAC·PodSecurityContext를 주의 깊게 관리해야 합니다.
  

3. 운영 시 모범 사례 (Best Practices)

• 자원 사용량 측정: CPU/메모리 Requests·Limits 설정은 필수.
• 버전 관리: Canary 업그레이드로 일부 노드만 먼저 업데이트 후 전체 반영.
• 모니터링 연계: kubectl get daemonset의 Ready Pod 수, Node 매핑 상태를 지속적으로 모니터링.

4. DaemonSet의 주요 단점과 한계

1. 자원 사용 부담
   • 노드 수에 비례해 Pod 수와 자원 사용량이 선형 증가.
   • 로그·모니터링 에이전트의 지속 I/O로 비용·성능 부담이 커질 수 있음.
2. 업데이트·롤백 리스크
   • RollingUpdate 중 잘못된 설정은 전체 노드에 영향을 미침.
   • OnDelete 전략은 대규모 클러스터에서 수동 작업이 번거롭다.
3. 스케줄링 제어 한계
   • 기본 동작은 “모든 노드 1 Pod”이므로, 특정 노드를 완전히 제외하려면 taint/toleration 관리가 중요.
   • 복잡한 Pod 간 anti-affinity를 정교하게 적용하기 어렵다.
4. 운영 복잡도
   • 수백~수천 노드 환경에서 각 노드 Pod 상태를 일관되게 모니터링·알림해야 한다.
   • 호스트 네임스페이스를 직접 다루는 경우 RBAC·PodSecurityContext 설정이 까다롭다.
5. 스토리지·네트워크 이슈
   • 로컬 스토리지 사용 시 노드 재부팅·삭제에 따른 데이터 유실 위험.
   • 모든 노드가 중앙 시스템으로 데이터 전송 시 네트워크 부하가 커질 수 있다

2. 내용 보강 (kubernetes v1.34)

1) 문서 및 설정 항목 강화

• .spec.selector 변경 불가 생성 후 수정 시 기존 Pod 매칭이 깨져 orphan Pod가 발생하므로, 초기 설계 단계에서 정확히 정의해야 한다.
  
• priorityClassName 권장 자원 부족으로 Pod가 축출(Eviction)될 때 DaemonSet Pod가 유지되도록 높은 우선순위를 설정.
  
• Node Affinity / Tolerations 규칙 명확화 NodeSelector·Affinity·Toleration의 적용 순서가 공식 문서에 상세히 기술됨. → nodeAffinity와 tolerations 동시 사용 시 스케줄러의 평가 순서를 반드시 이해해야 한다.
  

2) RollingUpdate 전략 고도화

• updateStrategy의 RollingUpdate/OnDelete 옵션은 그대로 유지.
• maxUnavailable, minReadySeconds 등을 활용해 업데이트 중 가용성을 세밀히 조정.
• 대규모 클러스터는 Canary 롤아웃으로 단계적 업데이트를 권장.

3) Unschedulable 노드 스케줄링 주의

• DaemonSet Pod는 기본적으로 node.kubernetes.io/unschedulable:NoSchedule taint에 대해 자동 Toleration을 가짐. → kubectl cordon으로 노드를 unschedulable 상태로 만들어도 새로운 DaemonSet Pod가 배포될 수 있음.
  
• 유지보수 중 Pod를 완전히 차단하려면 NoExecute taint를 함께 설정하거나 DaemonSet tolerations를 명시적으로 재정의해야 한다.

5. 참조

• Kubernetes 공식 DaemonSet 문서 : https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
• 도서: Kubernetes Patterns