데몬셋 장애가 클러스터 전체를 흔드는 순간
새벽에 갑자기 운영 중인 쿠버네티스 클러스터의 모니터링 대시보드가 멈췄다는 알람을 받았다고 상상해 보세요. 로그 수집기나 네트워크 프록시 같은 핵심 서비스가 담당하는 데몬셋(DaemonSet)이 갑자기 오작동하기 시작하면 문제는 단순히 하나의 파드(Pod)에서 끝나지 않아요. 모든 노드에서 서비스가 중단되거나 데이터가 유실되는 심각한 상황으로 이어질 수 있죠.
현장에서 가장 당혹스러운 순간은 데몬셋 파드가 CrashLoopBackOff 상태에 빠져서 모든 노드에서 계속 재시작을 반복할 때예요. 분명 어제까지는 잘 돌아갔는데, 설정 하나를 바꿨거나 클러스터를 업데이트한 뒤에 이런 일이 발생하곤 해요. 원인은 설정 오류일 수도 있고, 노드의 리소스 부족이나 네트워크 정책 문제일 수도 있어요. 원인을 정확히 모른 채 명령어를 아무거나 입력하다가는 클러스터 상태를 더 악화시킬 뿐이에요.
이 글에서는 데몬셋 문제로 골머리를 앓고 있는 백엔드 개발자와 데브옵스 엔지니어를 위해 실무적인 해결책을 준비했어요. 단순한 이론이 아니라, 실제 터미널 앞에서 어떤 명령어를 치고 어떤 메시지를 읽어야 하는지 그 흐름을 따라가 볼 거예요. 이 가이드를 끝까지 읽고 나면 당황하지 않고 문제를 진단하는 능력을 갖추게 될 거예요.
- 데몬셋 장애를 유발하는 대표적인 증상 파악하기
- 진단을 위해 반드시 준비해야 할 도구와 기본 지식
- 단계별로 실행하는 체계적인 원인 분석 프로세스
- 상황별 복구 조치와 재발 방지를 위한 설정 방법
문제 해결을 위한 진단 준비물과 체크리스트
무작정 로그부터 뒤지기 전에, 현재 내가 사용할 수 있는 무기가 무엇인지 파악하는 것이 중요해요. 데몬셋 트러블슈팅은 클러스터 전체를 대상으로 하기 때문에, 잘못된 조작이 전체 시스템에 영향을 줄 수 있다는 점을 항상 염두에 두어야 해요.
가장 먼저 확인해야 할 것은 본인의 권한이에요. 데몬셋은 노드 수준의 리소스를 사용하기 때문에, 이를 상세히 조회하려면 cluster-admin 권한이나 그에 준하는 읽기 권한이 반드시 필요해요. 권한이 부족해서 `kubectl describe` 명령어를 쳤는데 정보가 누락된다면 진단 자체가 불가능하니까요.
또한, 현재 클러스터의 상태를 빠르게 파악할 수 있는 도구들이 준비되어 있어야 해요. 단순히 명령어를 치는 것을 넘어, 에러 메시지의 패턴을 읽어낼 수 있는 눈이 필요하죠. 아래 표를 통해 문제 해결 과정에서 주로 사용하는 도구와 그 용도를 정리해 두었으니 참고해 보세요.
| 진단 도구 | 주요 용도 | 확인 가능한 정보 |
|---|---|---|
| kubectl get pods | 전체 상태 확인 | 파드의 상태(Running, Pending 등) 및 재시작 횟수 |
| kubectl describe | 상세 정보 분석 | 이벤트 로그, 스케줄링 실패 사유, 노드 선택 조건 |
| kubectl logs | 애플리케이션 내부 진단 | 컨테이너 내부의 에러 메시지 및 스택 트레이스 |
| kubectl get events | 클러스터 이벤트 추적 | 이미지 풀링 실패, 볼륨 마운트 오류 등 인프라 이슈 |
진단을 시작하기 전, 반드시 스스로에게 질문해 보세요. “이 데몬셋이 어떤 노드에 배포되어야 하는가?” 그리고 “그 노드들은 현재 정상적으로 동작하고 있는가?” 이 두 가지 질문에 대한 답을 찾는 과정이 트러블슈팅의 절반을 차지한다고 해도 과언이 아니에요. 노드의 상태가 불안정하면 데몬셋은 절대로 안정적으로 돌아갈 수 없어요.
데몬셋을 수정할 때 RollingUpdate 전략을 사용 중이라면, 한 번에 너무 많은 노드에서 파드가 교체되지 않도록
maxUnavailable 값을 적절히 설정했는지 반드시 확인하세요. 설정이 잘못되면 전체 클러스터의 서비스가 순식간에 중단될 수 있어요.단계별 데몬셋 장애 원인 분석과 해결 프로세스
이제 본격적으로 문제를 파헤쳐 볼 시간이에요. 데몬셋 문제는 크게 세 가지 범주로 나뉘어요. 첫째는 파드가 아예 생성되지 못하는 스케줄링 문제, 둘째는 생성은 되었지만 계속 죽는 런타임 문제, 셋째는 실행은 되는데 제 역할을 못 하는 설정 및 네트워크 문제예요. 이 흐름을 따라가며 진단해 보세요.
STEP 1. 파드 상태를 통한 1차 진단 수행하기
먼저 `kubectl get pods -n
- Pending 상태: 파드가 노드에 배치되지 못하고 대기 중인 상태예요. 대부분 스케줄링 조건이 맞지 않거나 리소스가 부족할 때 발생해요.
- ImagePullBackOff 상태: 컨테이너 이미지를 가져오지 못하고 있어요. 이미지 이름이 틀렸거나, 레지스트리 인증 정보(imagePullSecrets)가 누락되었을 가능성이 매우 높아요.
- CrashLoopBackOff 상태: 컨테이너가 실행되었다가 즉시 종료되는 현상이에요. 애플리케이션 코드의 버그, 잘못된 환경 변수, 혹은 실행 권한 문제일 확률이 커요.
- OOMKilled 상태: 컨테이너가 할당된 메모리 한도를 초과해서 커널에 의해 강제 종료된 거예요. 리소스 제한(limits) 설정을 검토해야 해요.
상태를 확인했다면 즉시 `kubectl describe pod
자주 하는 실수와 해결법
실무에서 데몬셋을 운영하다 보면 누구나 한 번쯤은 저지를 수 있는 실수들이 있어요. 비슷한 상황이 반복되지 않도록 아래 사례들을 눈여겨보세요.
- ❌ 실수: 노드 라벨을 변경하면서 데몬셋의 nodeSelector를 수정하지 않음
→ 원인: 라벨과 선택 조건이 일치하지 않아 파드가 생성되지 않음
→ ✅ 해결법: 노드 라벨 변경 시 데몬셋의 Selector 값도 함께 업데이트하거나, 더 유연한 affinity 설정을 사용하세요. - ❌ 실수: 데몬셋의 리소스 Limit을 너무 타이트하게 설정함
→ 원인: 노드 부하가 조금만 늘어나도 데몬셋 파드가 OOMKilled로 종료됨
→ ✅ 해결법: 실제 사용량의 1.5~2배 정도 여유 있게 Limit을 설정하세요. - ❌ 실수: Taint가 걸린 노드에 Toleration 없이 배포함
→ 원인: 특정 노드(예: GPU 노드)에 데몬셋이 배포되지 않음
→ ✅ 해결법: `kubectl describe node`로 테인트를 확인하고, 해당 테인트를 허용하는 toleration을 추가하세요. - ❌ 실수: ConfigMap의 키(Key) 이름을 오타 냄
→ 원인: 애플리케이션이 환경 변수를 읽지 못해 CrashLoopBackOff 발생
→ ✅ 해결법: ConfigMap 정의와 파드 YAML의 env/envFrom 섹션을 대조하세요. - ❌ 실수: 이미지 태그를 ‘latest’로 사용함
→ 원인: 의도치 않은 이미지 업데이트로 인해 갑작스러운 장애 발생
→ ✅ 해결법: 반드시 특정 버전(예: v1.2.3)을 명시하여 배포의 안정성을 확보하세요.
자주 묻는 질문
Q. 데몬셋 파드를 강제로 재시작하려면 어떻게 해야 하나요?
가장 깔끔한 방법은 데몬셋을 삭제하는 것이 아니라, `kubectl rollout restart daemonset <이름>` 명령어를 사용하는 거예요. 이렇게 하면 쿠버네티스가 순차적으로 파드를 교체하며 안전하게 재시작을 진행해 줘요.
Q. 일부 노드에만 데몬셋이 안 뜨는데 이유가 뭘까요?
해당 노드의 라벨이 데몬셋의 조건과 맞지 않거나, 노드에 걸린 Taint 때문일 확률이 가장 높아요. 혹은 노드의 디스크 공간이 부족하거나 리소스가 아예 없는 상태일 수도 있으니 `kubectl describe node`로 노드 상태를 꼭 확인해 보세요.
Q. 데몬셋 업데이트 중에 서비스가 끊기면 어떡하죠?
`spec.updateStrategy.type`을 `RollingUpdate`로 설정하고, `maxUnavailable` 값을 1 정도로 낮게 설정하세요. 그러면 한 번에 하나의 노드씩만 업데이트되므로 전체 서비스 중단을 막을 수 있어요.
Q. 이미지 풀링 에러가 계속 나는데 인증 문제인가요?
네, 그럴 가능성이 커요. `imagePullSecrets`가 데몬셋 설정에 포함되어 있는지, 그리고 해당 시크릿이 모든 네임스페이스에서 접근 가능한지 확인해 보세요.
Q. 데몬셋이 노드를 너무 많이 점유해요.
데몬셋은 모든 노드에 뜨는 것이 기본이에요. 만약 특정 노드 그룹에만 뜨게 하고 싶다면 `nodeSelector`나 `nodeAffinity`를 사용해서 배포 범위를 명확히 제한해야 해요.
장애 대응을 위한 최종 체크리스트
데몬셋 장애는 당황하기 쉽지만, 체계적인 절차만 있다면 충분히 빠르게 해결할 수 있어요. 오늘 배운 내용을 바탕으로 실무에서 문제가 발생했을 때 바로 꺼내 쓸 수 있도록 정리해 두세요.
- 파드 상태(Pending, CrashLoopBackOff 등)를 통해 문제의 성격(스케줄링 vs 런타임)을 먼저 구분하기
- `kubectl describe`와 `kubectl logs –previous`를 사용하여 구체적인 에러 메시지 확보하기
- 노드의 라벨(Label)과 테인트(Taint)가 데몬셋의 조건과 일치하는지 대조하기
- 리소스 제한(Limits)과 볼륨 마운트 경로가 실제 환경과 맞는지 확인하기
- 설정 변경 시에는 `RollingUpdate` 전략을 통해 점진적으로 배포하기
지금 바로 여러분의 클러스터에서 실행 중인 데몬셋의 리소스 사용량과 배포 전략을 점검해 보는 건 어떨까요? 문제가 터지기 전에 미리 대비하는 것이 가장 훌륭한 운영 방법이에요.
오늘 내용이 도움이 되셨다면, 실제 환경에서 테스트해 보시고 잘 안 풀리는 부분은 언제든 댓글로 질문을 남겨 주세요. 함께 고민하면 해결책을 찾을 수 있을 거예요!
함께 읽어보면 좋은 글:
– 쿠버네티스 데몬셋 기본 개념 및 활용법
– 클러스터 구축 입문: 환경 설정부터 운영까지
