이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

데몬셋(DaemonSet)은 쿠버네티스 클러스터 내의 모든 (또는 특정 조건을 만족하는) 노드 각각에 정확히 하나의 파드 복제본이 실행되도록 보장하는 특별한 컨트롤러라고 앞서 소개했습니다. 이러한 “각 노드마다 하나씩” 실행되는 특성은 일반적인 애플리케이션 배포보다는 클러스터의 인프라스트럭처를 지원하거나 특정 노드 레벨의 작업을 수행해야 하는 시스템 유틸리티 또는 에이전트 배포에 매우 적합합니다. 마치 각 컴퓨터마다 반드시 설치되어 실행되어야 하는 백신 프로그램이나 시스템 모니터링 도구와 유사하다고 생각할 수 있습니다.

데몬셋이 없다면, 우리는 각 노드에 필요한 에이전트를 수동으로 설치하거나, 노드가 추가될 때마다 잊지 않고 해당 에이전트를 배포해야 하는 번거로움을 겪어야 할 것입니다. 또한, 디플로이먼트를 사용하여 replicas 수를 노드 수와 동일하게 맞추려고 시도하더라도, 스케줄러의 동작 방식 때문에 특정 노드에는 여러 개의 파드가 몰리거나 어떤 노드에는 아예 파드가 배포되지 않는 상황이 발생할 수 있습니다. 데몬셋은 이러한 문제들을 해결하고, 각 노드에 필요한 파드가 안정적으로 실행되도록 보장하여 클러스터 관리의 효율성과 신뢰성을 크게 향상시킵니다.

그렇다면 구체적으로 어떤 경우에 데몬셋이 유용하게 활용될 수 있을까요? 대표적인 사용 사례들을 통해 데몬셋의 필요성을 더욱 명확히 이해해 보겠습니다.

클라우드 네이티브 환경에서 애플리케이션은 수많은 컨테이너와 파드 형태로 분산되어 실행됩니다. 이렇게 분산된 환경에서는 각 애플리케이션이 생성하는 로그를 효율적으로 수집하고 중앙에서 관리하는 것이 매우 중요합니다. 로그는 시스템의 상태를 파악하고, 문제를 진단하며, 보안 감사를 수행하는 데 필수적인 정보원이기 때문입니다.

이때 각 노드에서 실행되는 모든 컨테이너의 로그(표준 출력/에러 스트림, 또는 노드 내 특정 경로의 로그 파일)를 수집하여 중앙 로그 분석 시스템(예: Elasticsearch, Splunk 등)으로 전송하는 역할을 하는 것이 바로 로그 수집 에이전트입니다. 대표적인 오픈소스 로그 수집기로는 Fluentd나 Logstash (ELK 스택의 일부) 등이 널리 사용됩니다.

이러한 로그 수집 에이전트는 클러스터 내의 모든 노드에 각각 하나씩 실행되어야 합니다. 왜냐하면 각 노드에서 실행되는 파드들의 로그는 해당 노드의 특정 위치에 저장되거나 스트리밍되기 때문입니다. 만약 어떤 노드에 로그 수집 에이전트가 실행되지 않는다면, 해당 노드에서 발생하는 중요한 로그들을 놓치게 되어 시스템 전체의 가시성이 떨어지고 문제 해결이 어려워질 수 있습니다.

바로 이 지점에서 데몬셋이 완벽한 해결책을 제공합니다.

• 배포 용이성: 데몬셋을 사용하여 Fluentd나 Logstash 파드를 정의하면, 쿠버네티스는 클러스터 내의 모든 적격한 노드에 자동으로 이 에이전트 파드를 배포합니다. 새로운 노드가 클러스터에 추가되면 해당 노드에도 즉시 로그 수집 에이전트가 실행됩니다.
• 노드 접근성: 로그 수집 에이전트는 해당 노드의 파일 시스템(예: /var/log/containers, /var/lib/docker/containers 등 컨테이너 로그가 저장되는 경로)에 접근하거나, 노드의 특정 포트를 리스닝해야 할 수 있습니다. 데몬셋으로 배포된 파드는 hostPath 볼륨이나 hostNetwork: true (필요한 경우, 보안상 주의 필요) 설정을 통해 이러한 노드 수준의 리소스에 접근할 수 있습니다.
• 안정적인 실행 보장: 만약 어떤 노드에서 로그 수집 에이전트 파드가 비정상적으로 종료되더라도, 데몬셋은 즉시 해당 파드를 해당 노드에 다시 시작시켜 로그 수집의 연속성을 보장합니다.

이처럼 데몬셋을 활용하면, 분산된 쿠버네티스 환경에서 발생하는 모든 로그를 누락 없이 안정적으로 수집할 수 있는 기반을 마련할 수 있습니다. 이는 시스템 운영의 투명성을 높이고, 장애 발생 시 신속하게 원인을 파악하여 대응하는 데 매우 중요한 역할을 합니다. 실제로 많은 쿠버네티스 로깅 솔루션들이 데몬셋을 핵심 배포 방식으로 사용하고 있습니다.

로그 수집만큼이나 중요한 것이 바로 클러스터의 각 노드에 대한 성능 지표(metrics)를 수집하고 모니터링하는 것입니다. 각 노드의 CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등과 같은 시스템 수준의 지표는 클러스터의 전반적인 건강 상태를 파악하고, 성능 병목 지점을 찾아내며, 향후 자원 계획을 수립하는 데 필수적인 데이터입니다.

이러한 노드 수준의 지표를 수집하여 중앙 모니터링 시스템(예: Prometheus, Datadog, New Relic 등)으로 전송하는 역할을 하는 것이 노드 모니터링 에이전트입니다. 클라우드 네이티브 환경에서 널리 사용되는 오픈소스 모니터링 시스템인 Prometheus의 경우, Node Exporter라는 에이전트가 바로 이 역할을 수행합니다. Node Exporter는 각 노드에서 실행되면서 해당 노드의 다양한 하드웨어 및 OS 커널 관련 지표를 수집하여 Prometheus 서버가 가져갈 수 있도록 HTTP 엔드포인트 형태로 노출합니다.

로그 수집 에이전트와 마찬가지로, 노드 모니터링 에이전트 역시 클러스터 내의 모든 노드에 각각 하나씩 실행되어야 합니다. 특정 노드의 지표가 수집되지 않는다면, 해당 노드의 상태를 알 수 없어 클러스터 전체의 건강 상태를 정확히 판단하기 어렵고, 문제 발생 시 원인 규명이 지연될 수 있습니다.

데몬셋은 이러한 노드 모니터링 에이전트를 배포하고 관리하는 데 이상적인 솔루션입니다.

• 전 노드 커버리지: 데몬셋을 사용하면 Prometheus Node Exporter와 같은 에이전트가 클러스터의 모든 노드에 자동으로 배포되어, 어떤 노드의 지표도 누락 없이 수집할 수 있도록 보장합니다.
• 시스템 정보 접근: Node Exporter는 해당 노드의 다양한 시스템 정보(예: /proc, /sys 파일 시스템)에 접근하여 지표를 수집해야 합니다. 데몬셋으로 배포된 파드는 필요한 권한(예: privileged: true 또는 특정 securityContext 설정, 역시 보안상 주의 필요)과 hostPath 볼륨 마운트를 통해 이러한 정보에 접근할 수 있습니다.
• 자동 확장 및 축소: 클러스터에 새로운 노드가 추가되면 데몬셋은 자동으로 해당 노드에도 모니터링 에이전트를 배포하고, 노드가 제거되면 해당 파드도 자동으로 정리하여 항상 최신 상태의 노드 구성을 반영합니다.

데몬셋을 통해 노드 모니터링 에이전트를 안정적으로 운영함으로써, 우리는 클러스터의 모든 구석구석을 실시간으로 감시하고, 잠재적인 문제를 사전에 예방하며, 시스템 성능을 최적으로 유지할 수 있는 강력한 기반을 갖추게 됩니다. 이는 서비스의 신뢰성과 가용성을 높이는 데 직접적으로 기여합니다.

쿠버네티스 환경에서 컨테이너가 데이터를 영구적으로 저장하기 위해서는 퍼시스턴트 볼륨(Persistent Volume, PV)이 필요합니다. 이러한 PV를 제공하는 스토리지 시스템은 매우 다양하며, 그중에는 분산 스토리지 시스템(Distributed Storage System)도 널리 사용됩니다. Ceph나 GlusterFS와 같은 오픈소스 분산 스토리지 시스템은 여러 노드의 로컬 디스크들을 하나로 묶어 거대한 공유 스토리지 풀을 만들고, 이를 통해 애플리케이션에 유연하고 확장 가능한 스토리지를 제공합니다.

이러한 분산 스토리지 시스템을 쿠버네티스 클러스터와 통합하여 사용하려면, 보통 각 스토리지 노드(또는 클러스터의 모든 노드)에서 특정 스토리지 관련 데몬(daemon)이나 에이전트가 실행되어야 합니다. 예를 들어,

• Ceph: Ceph 클라이언트는 Ceph 모니터(MON) 및 OSD(Object Storage Daemon) 데몬과 통신하여 스토리지에 접근합니다. 쿠버네티스 노드에서 Ceph 볼륨을 마운트하고 사용하기 위해서는 해당 노드에 Ceph 클라이언트 라이브러리나 관련 데몬이 필요할 수 있습니다. 또한, Ceph OSD 데몬 자체를 쿠버네티스 노드에서 실행하여 해당 노드의 디스크를 Ceph 클러스터에 기여하도록 구성할 수도 있습니다.
• GlusterFS: GlusterFS 클라이언트는 GlusterFS 서버 데몬과 통신하여 볼륨에 접근합니다. 쿠버네티스 노드에서 GlusterFS 볼륨을 사용하려면 해당 노드에 GlusterFS 클라이언트 관련 패키지나 데몬이 설치되어 실행 중이어야 합니다.

이처럼 클러스터 스토리지 시스템의 기능을 각 노드에서 활성화하거나, 노드 자체가 스토리지 클러스터의 일부로 참여하도록 만드는 데 필요한 데몬들을 배포할 때 데몬셋이 매우 유용하게 사용됩니다.

• 노드별 스토리지 에이전트 실행: 데몬셋을 사용하면 Ceph나 GlusterFS와 같은 스토리지 시스템의 클라이언트 또는 서버 데몬을 필요에 따라 클러스터의 모든 노드 또는 특정 스토리지 노드 그룹에 일관되게 배포할 수 있습니다.
• 특권 및 장치 접근: 스토리지 데몬은 종종 해당 노드의 디스크 장치에 직접 접근하거나, 커널 모듈을 로드하는 등의 특권 작업이 필요할 수 있습니다. 데몬셋으로 배포된 파드는 privileged: true 컨텍스트나 hostPath를 통해 /dev 와 같은 장치 파일에 접근하는 등 필요한 권한을 부여받을 수 있습니다 (보안 설정에 각별한 주의가 요구됩니다).
• 자동 구성 및 관리: 새로운 노드가 스토리지 클러스터에 추가될 때 데몬셋은 해당 노드에도 스토리지 데몬을 자동으로 배포하여 스토리지 풀을 확장하는 데 도움을 줄 수 있습니다.

물론, 복잡한 스토리지 시스템 전체를 쿠버네티스 위에서 데몬셋만으로 구축하는 것은 Rook나 OpenEBS와 같은 스토리지 오케스트레이션 도구(Operator 패턴 활용)를 사용하는 것에 비해 더 많은 수동 설정과 관리가 필요할 수 있습니다. 하지만 특정 스토리지 관련 컴포넌트나 에이전트를 각 노드에 배포하는 데 있어서 데몬셋은 여전히 강력하고 기본적인 도구임이 틀림없습니다.

이 외에도 데몬셋은 네트워크 플러그인(CNI 플러그인) 관련 에이전트 배포, 하드웨어 장치 드라이버나 펌웨어 관리, 노드별 보안 에이전트 실행 등 각 노드에서 특정 작업을 수행해야 하는 다양한 시나리오에서 널리 활용됩니다. 핵심은 “모든 (또는 선택된) 노드에 하나씩”이라는 요구사항이 있을 때 데몬셋이 가장 먼저 고려될 수 있는 쿠버네티스 컨트롤러라는 점입니다.