데몬셋 FAQ 실무에서 마주하는 결정적 순간들
새로운 워커 노드를 클러스터에 추가했는데, 로그 수집 에이전트가 작동하지 않아 당황했던 적이 있으신가요? 분명히 데몬셋을 배포했는데 특정 노드에서만 파드가 생성되지 않거나, 마스터 노드에는 왜 에이전트가 뜨지 않는지 의문이 생길 때가 많아요. 대규모 트래픽을 관리하는 SRE라면 이런 작은 설정 차이가 전체 관측성(Observability)에 얼마나 큰 공백을 만드는지 잘 알고 계실 거예요.
데몬셋은 모든 노드에 반드시 하나씩 실행되어야 하는 특수 목적의 컨트롤러예요. 하지만 데몬셋 FAQ를 찾아보지 않고 대충 설정했다가는 스케줄링 오류나 자원 고갈 문제로 이어지기 십상이죠. 특히 Taints와 Tolerations, Node Affinity 같은 고급 기능이 섞이기 시작하면 실무자들도 머리를 싸매게 됩니다.
이 글은 단순히 이론적인 정의를 나열하지 않아요. 실제 운영 환경에서 엔지니어들이 가장 자주 겪는 삽질 포인트와, 이를 해결하기 위한 명확한 가이드를 제공해요. 이 글을 끝까지 읽고 나면, 복잡한 데몬셋 설정 앞에서도 당황하지 않고 문제를 진단할 수 있는 눈을 갖게 될 거예요.
이번 가이드에서는 다음과 같은 내용을 심도 있게 다뤄요.
- 데몬셋의 핵심 개념과 다른 컨트롤러와의 결정적 차이점
- 노드 선택을 위한 스케줄링 전략과 고급 설정법
- 업데이트 방식에 따른 운영 안정성 확보 방법
- 실무에서 빈번하게 발생하는 장애 유형과 해결 시나리오
- 운영 효율을 높이는 핵심 FAQ 정리
사전 준비 — 데몬셋 작동 원리와 판단 기준
데몬셋을 본격적으로 다루기 전에, 우리가 왜 이 컨트롤러를 사용해야 하는지 명확히 정의할 필요가 있어요. 모든 파드를 데몬셋으로 만들 수는 없으니까요. 데몬셋의 본질은 노드당 하나의 복제본(Replica) 보장에 있어요. 만약 노드가 늘어나면 파드도 자동으로 늘어나고, 노드가 줄어들면 파드도 사라지는 방식이에요.
운영 환경에서 어떤 컨트롤러를 사용할지 결정하는 기준은 매우 중요해요. 잘못된 선택은 자원 낭비나 서비스 중단으로 이어지거든요. 아래 표를 통해 상황별 최적의 선택지를 비교해 보세요.
| 컨트롤러 유형 | 주요 목적 | 노드당 파드 개수 | 권장 활용 사례 |
|---|---|---|---|
| Deployment | 무상태 애플리케이션 배포 | N개 (자유로움) | 웹 서버, API 서버 |
| StatefulSet | 상태 저장 애플리케이션 | N개 (순서 보장) | 데이터베이스, 메시지 큐 |
| DaemonSet | 인프라/백그라운드 서비스 | 무조건 1개 | 로그 수집기, 모니터링 에이전트 |
데몬셋을 설계할 때 반드시 체크해야 할 세 가지 전제 조건이 있어요. 첫째, 해당 파드가 노드 자체의 자원이나 정보에 접근해야 하는가? 둘째, 노드가 추가될 때마다 자동으로 실행되어야 하는가? 셋째, 특정 노드군(예: GPU 노드)에만 선택적으로 배포되어야 하는가? 이 질문들에 모두 ‘예’라고 답할 수 있다면 데몬셋이 정답이에요.
데몬셋은 기본적으로 클러스터의 모든 노드에 파드를 배치하려고 시도해요. 하지만 노드에 설정된 Taints(용인되지 않은 노드 표시)가 있다면, 적절한 Tolerations 설정 없이는 배포가 실패할 수 있다는 점을 기억하세요.
또한, 데몬셋은 일반적인 Deployment와 달리 스케줄러가 파드를 배치하는 방식이 조금 더 엄격해요. Deployment는 리소스 여유가 있는 곳을 찾아 돌아다니지만, 데몬셋은 ‘노드’라는 물리적/논리적 단위에 종속적이기 때문이죠. 따라서 리소스 요청(Requests)과 제한(Limits) 설정을 매우 보수적으로 잡아야 해요. 자칫하면 시스템 에이전트가 노드의 핵심 자원을 모두 점유해 버리는 대참사가 일어날 수 있어요.
데몬셋 운영의 핵심: 단계별 설정 및 최적화 전략
데몬셋을 실무 수준으로 끌어올리기 위해서는 단순 배포를 넘어 스케줄링과 업데이트 전략을 정교하게 설계해야 해요. 단계별로 핵심 기술 요소를 살펴볼게요.
STEP 1. 정교한 노드 타겟팅 전략 수립하기
모든 노드에 데몬셋을 띄우는 것은 때로 비효율적이에요. 예를 들어, 로그 수집기는 일반 워커 노드에는 필요하지만, 계산 전용 GPU 노드에는 필요 없을 수도 있죠. 이때 사용하는 것이 NodeSelector와 Node Affinity예요.
NodeSelector는 가장 간단한 방법으로, 노드에 설정된 라벨을 기준으로 파드를 배치해요. 하지만 조건이 단순하다는 단점이 있어요. 반면, Node Affinity는 훨씬 강력한 논리 구조를 제공해요. ‘이 라벨이 있는 노드에 배치하되, 만약 없다면 다른 곳을 찾아봐’ 혹은 ‘반드시 이 라벨이 있는 곳에만 배치해’ 같은 복잡한 명령이 가능하죠. 실무에서는 가용성을 위해 Preferred(선호) 방식과 Required(필수) 방식을 적절히 섞어서 사용하는 것을 권장해요.
STEP 2. Taints와 Tolerations로 배포 범위 제어하기
클러스터의 마스터 노드(Control Plane)를 경험해 보셨다면, 일반 파드가 왜 거기서 안 뜨는지 궁금했을 거예요. 바로 마스터 노드에 Taint가 걸려 있기 때문이죠. 데몬셋도 예외는 아니에요. 만약 모니터링 에이전트를 마스터 노드에서도 실행하고 싶다면, 데몬셋 설정에 반드시 Tolerations를 추가해야 해요.
이 과정에서 흔히 하는 실수는 Taint의 키(Key)나 효과(Effect)를 잘못 적는 것이에요. `NoSchedule`인지 `NoExecute`인지 정확히 구분하지 않으면, 파드는 생성되었으나 실행되지 않거나 노드에서 계속 쫓겨나는 무한 루프에 빠질 수 있어요. 반드시 `kubectl describe node` 명령어로 노드에 걸린 Taint를 먼저 확인한 뒤 설정을 진행하세요.
STEP 3. 자원 관리와 안정성 확보
데몬셋은 시스템의 기반이 되는 서비스인 경우가 많아요. 따라서 자원 설정(Resources)이 잘못되면 클러스터 전체가 위험해질 수 있어요. 자원 할당의 불균형은 데몬셋 운영의 가장 큰 적이에요.
- Requests 설정: 파드가 최소한으로 보장받아야 할 자원이에요. 너무 낮게 잡으면 노드 부하가 심할 때 에이전트가 죽어버리고, 너무 높게 잡으면 노드에 사용 가능한 공간이 부족해져요.
- Limits 설정: 파드가 최대로 사용할 수 있는 자원이에요. 로그 수집기가 갑자기 폭발적인 로그를 처리할 때, 이 제한이 없으면 노드 전체의 CPU/Memory를 다 써버릴 수 있어요.
실무에서는 CPU는 Limits를 넉넉히 주되, Memory는 Limits에 도달하면 OOM(Out Of Memory) Kill이 발생하더라도 시스템 전체 보호를 위해 엄격하게 제한하는 방식을 선호해요.
STEP 4. 업데이트 전략: RollingUpdate vs OnDelete
데몬셋의 설정을 변경했을 때, 기존 파드들을 어떻게 교체할 것인가의 문제입니다. 쿠버네티스는 두 가지 옵션을 제공해요.
- RollingUpdate: 기본값이며, 노드를 하나씩 돌아가며 파드를 교체해요. 서비스 중단을 최소화할 수 있지만, 업데이트 도중 클러스터에 일시적인 리소스 압박이 올 수 있어요.
- OnDelete: 사용자가 직접 기존 파드를 삭제해야 새로운 설정이 적용된 파드가 떠요. 업데이트 속도는 느리지만, 아주 정통적인 제어권을 갖고 싶을 때 사용해요.
대규모 클러스터에서는 RollingUpdate를 쓰되, `maxUnavailable` 설정을 통해 한 번에 교체될 파드의 비율을 조절하는 것이 안전해요. 예를 들어, 전체 노드의 10%만 업데이트 중지 상태로 두어 관측성 공백을 최소화하는 식이죠.
STEP 5. 볼륨 마운트와 권한 관리
데몬셋은 주로 호스트의 로그 파일이나 커널 정보를 읽기 위해 hostPath 볼륨을 사용해요. 이는 매우 강력하지만 위험한 도구예요. 파드가 노드의 파일 시스템에 직접 접근할 수 있기 때문이죠. 보안을 위해서는 파드가 필요한 경로에만 최소한의 권한(ReadOnly)으로 접근할 수 있도록 securityContext를 반드시 설정해야 해요.
hostPath를 사용할 때는 노드 재부팅이나 디렉토리 경로 변경 시 파드가 실패할 수 있어요. 호스트의 경로가 모든 노드에서 동일한지, 그리고 권한(Permissions)이 파드 내부 유저와 일치하는지 반드시 확인하세요.
실제 운영 시나리오를 하나 들어볼게요. 로그 수집기를 업데이트했는데, 특정 노드에서만 파드가 `ContainerCreating` 상태에서 멈춰 있다면? 대부분은 hostPath로 지정한 로그 디렉토리가 해당 노드에 존재하지 않거나, 권한 문제로 접근이 거부된 경우예요. 이럴 때는 `kubectl describe pod`을 통해 이벤트를 확인하는 것이 가장 빠른 길이에요.
자주 하는 실수와 해결법 + FAQ
자주 하는 실수와 해결법
현장에서 엔지니어들이 가장 자주 겪는 실수들을 정리했어요. 비슷한 상황을 겪고 있다면 아래 해결법을 즉시 적용해 보세요.
- ❌ 실수: 노드에 Taint가 있는데 Toleration을 빠뜨림 → 왜 발생하는가: 마스터 노드나 특수 목적 노드에 파드가 뜨지 않음 → ✅ 해결법: `kubectl describe node`로 Taint를 확인하고 YAML에 정확한 Toleration 추가
- ❌ 실수: NodeSelector에 오타가 있음 → 왜 발생하는가: 파드가 어디에도 스케줄링되지 않고 Pending 상태로 남음 → ✅ 해결법: `kubectl get nodes –show-labels`로 실제 라벨과 대조
- ❌ 실수: hostPath 경로 권한 문제 → 왜 발생하는가: 파드는 떴으나 로그를 읽지 못하거나 권한 오류로 CrashLoopBackOff 발생 → ✅ 해결법: `securityContext`와 호스트 디렉토리 권한(chmod/chown) 확인
- ❌ 실수: 자원 제한(Limits)을 너무 낮게 설정 → 왜 발생하는가: 트래픽 급증 시 에이전트가 OOM Kill 당함 → ✅ 해결법: 모니터링 데이터를 바탕으로 Requests/Limits 상향 조정
- ❌ 실수: RollingUpdate 중 자원 부족 → 왜 발생하는가: 새 파드가 뜨기 전 기존 파드가 먼저 죽어서 노드 가용성 저하 → ✅ 해결법: `maxUnavailable` 값을 0으로 설정하여 새 파드가 뜨는 것을 확인 후 기존 파드 삭제
자주 묻는 질문
Q. 데몬셋(DaemonSet)과 디플로이먼트(Deployment)의 가장 큰 차이점은 무엇인가요?
Deployment는 클러스터 전체에서 파드의 총 개수를 유지하는 데 집중하지만, DaemonSet은 노드 하나당 파드 하나를 유지하는 데 집중해요. 즉, 노드 수가 변하면 데몬셋의 파드 수도 자동으로 변한다는 점이 가장 큰 차이예요.
Q. 마스터 노드에서도 데몬셋을 실행하고 싶어요. 어떻게 하나요?
마스터 노드는 보통 `node-role.kubernetes.io/control-plane:NoSchedule` 같은 Taint가 걸려 있어요. 이를 해결하려면 데몬셋의 `tolerations` 섹션에 해당 Taint를 허용하는 설정을 넣어야 해요.
Q. 데몬셋 파드가 특정 노드에서만 안 떠요. 확인해 볼 것은?
가장 먼저 해당 노드의 라벨을 확인하세요. NodeSelector나 Affinity 조건에 맞지 않을 확률이 가장 높아요. 그다음으로 노드의 Taint와 파드의 Toleration을, 마지막으로 hostPath로 마운트하려는 경로가 그 노드에 실제로 존재하는지 확인해 보세요.
Q. 데몬셋을 업데이트할 때 서비스 중단이 걱정돼요.
`updateStrategy`를 `RollingUpdate`로 설정하고, `maxUnavailable` 값을 조절하세요. 만약 서비스 안정성이 극도로 중요하다면, `OnDelete` 방식으로 변경하여 관리자가 수동으로 하나씩 교체하는 방법도 고려할 수 있어요.
Q. 데몬셋 파드가 자원을 너무 많이 써서 노드가 느려져요.
데몬셋은 인프라 서비스인 경우가 많아 자원 사용량이 튀기 쉬워요. 반드시 `resources.limits`를 설정해서 특정 파드 하나가 노드의 모든 CPU를 독점하지 못하게 물리적인 벽을 세워둬야 해요.
데몬셋 운영을 위한 최종 체크리스트
데몬셋은 편리하지만, 잘못 다루면 클러스터 전체의 안정성을 해칠 수 있는 양날의 검이에요. 운영 환경에 배포하기 전, 아래 항목들을 반드시 다시 한번 검토해 보세요.
- 노드별 스케줄링을 위해 NodeSelector나 Affinity가 정확히 설정되었는가?
- 마스터 노드 배포를 위해 필요한 Tolerations가 포함되었는가?
- 리소스 Requests와 Limits가 노드 안정성을 해치지 않을 정도로 적절한가?
- hostPath 사용 시 경로의 존재 여부와 보안 권한(ReadOnly 등)을 확인했는가?
- 업데이트 전략(RollingUpdate)의 파라미터가 서비스 가용성을 보장하는가?
- 모니터링 에이전트라면 클러스터 규모 변화에 따른 자원 변화를 고려했는가?
오늘 배운 내용을 바탕으로 지금 바로 운영 중인 클러스터의 데몬셋 설정을 점검해 보세요. 특히 자원 제한이 없는 에이전트가 있다면, 이번 주 안에 반드시 Limits 설정을 완료하는 것을 추천드려요.
실습 환경에서 직접 YAML을 수정해 보고, 예상치 못한 동작이 나타난다면 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하면 더 나은 인프라를 만들 수 있어요!
더 깊이 있는 쿠버네티스 학습을 원하신다면 다음 글들도 참고해 보세요.
- 쿠버네티스 데몬셋 기본 개념과 활용 사례
- 클러스터 구축 및 노드 관리 입문 가이드
