[IT-방법] 데몬셋 설정 방법 및 쿠버네티스 실전 배포 가이드 – 클러스터 전 노드에 에이전트를 안정적으로 배포하는 절차

왜 데몬셋(DaemonSet)을 사용해야 할까요

클러스터에 새로운 노드가 추가될 때마다 로그 수집기나 모니터링 에이전트를 일일이 수동으로 설치해 본 적이 있나요? 만약 노드가 100대라면 그 작업만으로도 하루가 다 지나가 버릴 거예요. 실수 하나로 특정 노드에 에이전트가 누락되면 전체 시스템의 가시성이 깨지는 끔찍한 상황이 발생하기도 해요.

이런 번거로운 작업을 해결해 주는 것이 바로 데몬셋(DaemonSet)이에요. 데몬셋은 클러스터 내의 모든 노드(또는 특정 조건에 맞는 노드)에 지정된 포드를 반드시 하나씩 실행하도록 보장해 주는 아주 똑똑한 기능이에요. 운영 환경에서 인프라 레벨의 서비스를 관리할 때 이보다 효율적인 방법은 없어요.

오늘 우리는 단순한 개념 공부를 넘어, 실무에서 바로 쓸 수 있는 데몬셋 설정 방법을 단계별로 깊이 있게 다뤄볼 거예요. 이 글을 끝까지 읽고 나면 여러분은 클러스터 확장과 상관없이 인프라 에이전트를 완벽하게 제어할 수 있는 능력을 갖게 될 거예요.

이번 가이드에서 우리가 함께 살펴볼 내용은 다음과 같아요.

• 데몬셋 배포 전 반드시 확인해야 할 환경 준비물
• 실전 YAML 파일을 활용한 단계별 설치 절차
• 노드 선택과 제어를 위한 고급 설정 옵션 활용법
• 배포 후 정상 동작 여부를 검증하는 방법
• 설정 과정에서 흔히 겪는 오류와 해결책

데몬셋 배포를 위한 사전 준비와 체크리스트

데몬셋을 무턱대고 배포하기 전에 먼저 현재 클러스터의 상태를 점검해야 해요. 준비가 되지 않은 상태에서 명령어를 입력했다가는 포드가 생성되지 않거나, 엉뚱한 노드에서 무한 재시작을 반복하는 상황을 마주할 수 있어요.

배포 전 필수 확인 사항

가장 먼저 확인해야 할 것은 kubectl 명령어를 사용할 수 있는 적절한 권한이에요. 데몬셋은 클러스터 전체 노드에 영향을 미치기 때문에 관리자 권한(RBAC)이 반드시 필요해요. 또한, 배포하려는 에이전트의 이미지가 프라이빗 레지스트리에 있다면, 해당 이미지를 가져올 수 있는 ImagePullSecret이 미리 준비되어 있어야 해요.

두 번째로 중요한 것은 노드의 상태예요. 노드에 테인트(Taint)가 설정되어 있다면, 데몬셋 포드가 해당 노드에 배치되지 못할 수도 있어요. 이를 대비해 톨러레이션(Toleration) 설정을 미리 고민해 두는 것이 좋아요.

워크로드 유형별 비교

많은 초보 개발자가 데몬셋을 디플로이먼트(Deployment)와 혼동하곤 해요. 어떤 상황에 무엇을 써야 할지 아래 표를 통해 명확하게 구분해 보세요.

위 표에서 볼 수 있듯이, 모든 노드에 동일한 기능을 수행하는 프로세스를 띄워야 한다면 고민하지 말고 데몬셋을 선택하면 돼요. 이제 준비가 끝났다면 본격적인 설정 단계로 넘어가 볼까요?

데몬셋 설정 및 실전 배포 단계

이제 본격적으로 데몬셋을 클러스터에 적용해 볼게요. 우리는 가장 흔한 사례인 플루언트디(Fluentd) 로그 수집기를 예로 들어 실습을 진행할 거예요. 이 과정을 통해 YAML 작성부터 세부 옵션 조절까지 마스터할 수 있어요.

STEP 1. 데몬셋 YAML 매니페스트 작성하기

데몬셋을 설치하기 위해서는 먼저 선언적인 정의를 담은 YAML 파일이 필요해요. 데몬셋의 구조는 크게 메타데이터, 스펙, 그리고 실제 실행될 템플릿으로 나뉘어요. 가장 중요한 부분은 spec.template.spec 부분인데, 이곳에 어떤 컨테이너를 어떤 설정으로 띄울지가 결정되기 때문이에요.

다음은 기본적인 데몬셋의 뼈대 예시예요.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-logger
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      – name: fluentd
        image: fluentd:latest

여기서 selector는 데몬셋 컨트롤러가 어떤 포드를 관리할지 결정하는 기준이 돼요. 템플릿 내부의 labels와 반드시 일치해야 한다는 점을 잊지 마세요. 이 부분이 다르면 데몬셋은 포드를 생성하고도 자신이 만든 포드인지 알아보지 못하는 무한 루프에 빠지게 돼요.

STEP 2. 특정 노드에만 배포하도록 제한하기

현업에서는 모든 노드가 아니라 특정 역할을 가진 노드(예: GPU 노드, 스토리지 노드)에만 데몬셋을 띄워야 할 때가 많아요. 이때 사용하는 것이 노드 셀렉터(NodeSelector)예요. 노드에 설정된 라벨을 기준으로 배포 대상을 좁힐 수 있어요.

예를 들어, 노드에 role=worker라는 라벨이 붙어 있다면, YAML의 spec.template.spec 아래에 다음과 같이 추가해 주세요.

nodeSelector:
  role: worker

이렇게 설정하면 마스터 노드나 다른 특수 목적 노드에는 로그 수집기가 뜨지 않게 되어 자원을 효율적으로 아낄 수 있어요. 만약 더 복잡한 논리(예: A 라벨이 있으면서 B 라벨은 없는 노드)가 필요하다면 노드 어피니티(Node Affinity)를 공부해야 하지만, 단순한 구분은 셀렉터만으로도 충분해요.

STEP 3. 마스터 노드의 테인트를 극복하기

많은 입문자가 겪는 당혹스러운 순간이 있어요. 데몬셋을 분명히 배포했는데, 마스터(Control-plane) 노드에는 포드가 나타나지 않는 현상이죠. 이는 쿠버네티스 마스터 노드에 테인트(Taint)가 걸려 있어 일반적인 포드의 접근을 막고 있기 때문이에요.

이를 해결하려면 데몬셋 설정에 톨러레이션(Toleration)을 명시해야 해요. 즉, “나는 마스터 노드의 테인트를 견딜 수 있어”라고 선언하는 것이죠. 다음과 같은 설정을 추가해 보세요.

tolerations:
– key: node-role.kubernetes.io/master
 operator: Exists
– key: node-role.kubernetes.io/control-plane
  operator: Exists

이 설정을 빠뜨리면 마스터 노드는 항상 관리용으로만 깨끗하게 유지되지만, 인프라 모니터링 관점에서는 사각지대가 발생하게 된다는 사실을 꼭 기억하세요.

STEP 4. 자원 제한(Resource Limits) 설정하기

데몬셋은 시스템 레벨에서 돌아가는 서비스예요. 만약 로그 수집기나 모니터링 툴이 갑자기 메모리를 폭발적으로 사용한다면, 그 노드에서 실행 중인 실제 서비스(애플리케이션)들이 죽어버리는 대참사가 일어날 수 있어요. 따라서 자원 제한 설정은 선택이 아닌 필수예요.

포드 스펙 안에 resources 항목을 만들어 요청(requests)과 제한(limits)을 명확히 구분해 주세요.

resources:
  requests:
    cpu: “100m”
    memory: “256Mi”
  limits:
    cpu: “200m”
    memory: “512Mi”

보통 요청량은 실제 구동에 필요한 최소한으로 잡고, 제한량은 갑작스러운 트래픽 증가 시에도 노드 전체를 마비시키지 않을 정도로 넉넉하게 설정하는 것이 노하우예요.

STEP 5. 배포 및 실시간 동작 검증

모든 설정이 끝났다면 이제 명령어를 통해 배포를 진행할 차례예요. 파일명이 daemonset.yaml이라고 가정한다면, 아래 명령어를 입력하세요.

kubectl apply -f daemonset.yaml

배포 직후에는 반드시 다음 세 가지 명령어를 통해 상태를 꼼꼼히 확인해야 해요.

1. kubectl get ds: 데몬셋 자체가 정상적으로 생성되었는지, 원하는 수의 복제본(Desired)과 현재 실행 중인 수(Current)가 일치하는지 확인해요.
2. kubectl get pods -o wide: 생성된 포드들이 실제로 모든 노드에 골고루 배치되었는지, 특정 노드에서만 뜨고 있지는 않은지 확인해요.
3. kubectl describe ds [데몬셋이름]: 만약 배포가 안 된다면 이 명령어를 통해 이벤트 로그를 확인하세요. 왜 스케줄링이 안 되었는지 정답이 적혀 있을 거예요.

자주 하는 실수와 해결법 및 FAQ

데몬셋을 운영하다 보면 예상치 못한 변수가 항상 발생해요. 현장에서 가장 자주 마주치는 문제들을 정리했으니, 문제가 생기면 당황하지 말고 아래 내용을 먼저 체크해 보세요.

자주 하는 실수와 해결법

❌ 실수: 데몬셋은 배포했는데 마스터 노드에는 포드가 안 떠요.
왜 발생하는가: 마스터 노드에 설정된 테인트(Taint)가 포드의 배포를 차단하고 있기 때문이에요.
✅ 해결법: YAML 파일의 tolerations 섹션에 마스터 노드의 테인트를 허용하는 설정을 추가하세요.

❌ 실수: 새로운 노드를 추가했는데 데몬셋 포드가 자동으로 안 생겨요.
왜 발생하는가: 노드의 라벨이 데몬셋의 nodeSelector 조건과 맞지 않거나, 노드 상태가 NotReady 상태일 수 있어요.
✅ 해결법: kubectl describe node [노드이름]으로 노드 라벨과 상태를 확인하고, 셀렉터 조건을 수정하세요.

❌ 실수: 포드가 계속 CrashLoopBackOff 상태에 머물러 있어요.
왜 발생하는가: 컨테이너 내부 설정 오류, 권한 부족(RBAC), 또는 필요한 볼륨 마운트 실패가 원인일 확률이 높아요.
✅ 해결법: kubectl logs [포드이름] 명령어로 컨테이너 내부의 에러 로그를 직접 확인하는 것이 가장 빠릅니다.

❌ 실수: 데몬셋 업데이트를 했는데 노드 전체가 버벅거려요.
왜 발생하는가: 업데이트 중 너무 많은 노드의 포드가 동시에 재시작되면서 시스템 부하가 급증했기 때문이에요.
✅ 해결법: strategy.rollingUpdate.maxUnavailable 값을 1 또는 적은 숫자로 설정하여 순차적으로 업데이트되도록 제어하세요.

❌ 실수: 이미지(Image)를 못 가져온다고(ErrImagePull) 나와요.
왜 발생하는가: 프라이빗 레지스트리 인증 정보가 없거나 이미지 태그가 틀렸을 때 발생해요.
✅ 해결법: imagePullSecrets가 올바르게 설정되었는지, 이미지 이름과 태그가 정확한지 다시 확인하세요.

자주 묻는 질문

Q. 데몬셋은 정말 모든 노드에 무조건 하나씩 생기나요?

데몬셋의 기본 동작은 그렇지만, 노드 셀렉터나 어피니티 설정을 사용하면 특정 조건을 만족하는 노드에만 골라서 배치할 수 있어요. 모든 노드가 아니라 ‘필요한 노드’에만 띄우는 것이 실무의 핵심이에요.

Q. 데몬셋과 디플로이먼트의 차이점을 한 문장으로 요약해 주세요.

디플로이먼트는 애플리케이션의 개수를 유지하는 데 집중하고, 데몬셋은 모든 노드에 포드를 하나씩 배치하는 데 집중해요.

Q. 노드가 삭제되면 데몬셋 포드는 어떻게 되나요?
노드가 삭제되면 해당 노드에 있던 데몬셋 포드도 자동으로 삭제돼요. 걱정하실 필요 없어요.

Q. 데몬셋 업데이트 중에 서비스 중단을 최소화하려면 어떻게 하나요?
RollingUpdate 전략을 사용하되, maxUnavailable 값을 아주 작게 설정하여 한 번에 한두 개의 노드만 업데이트되도록 관리하세요.

Q. 데몬셋 설정 시 보안(RBAC)이 왜 중요한가요?
로그 수집기 같은 데몬셋은 노드의 로그 파일이나 시스템 정보에 접근해야 하는 경우가 많아요. 권한을 너무 넓게 주면 보안 위협이 될 수 있고, 너무 좁게 주면 작동하지 않으니 적절한 Role과 ClusterRole 설정이 필수적이에요.

성공적인 데몬셋 운영을 위한 마지막 점검

데몬셋은 클러스터의 기반을 닦는 아주 강력한 도구예요. 하지만 강력한 만큼 잘못 설정했을 때의 파급력도 크다는 사실을 잊지 마세요. 오늘 배운 내용을 바탕으로 실무에 적용할 때 다음 사항들을 꼭 다시 한번 확인해 보길 바라요.

앞으로의 실행 계획

이론을 알았다면 이제 손으로 익힐 차례예요. 다음 스케줄에 맞춰 하나씩 실행해 보세요.

• 오늘 할 일: 현재 사용 중인 클러스터에 간단한 Nginx 데몬셋을 배포하여 스케줄링 과정을 눈으로 확인해 보세요.
• 이번 주 할 일: 실제 운영 환경에서 쓰이는 로그 수집기(Fluentd 등)의 공식 YAML을 분석하고, 우리 환경에 맞게 셀렉터와 리소스를 수정해 보세요.
• 실행 직전 할 일: 배포 전 반드시 kubectl apply --dry-run=client 명령어로 문법 오류가 없는지 검증하세요.

데몬셋 설정이 생각보다 까다롭거나, 특정 환경에서 예상치 못한 동작이 발생한다면 주저하지 말고 댓글로 질문을 남겨 주세요. 여러분의 고민을 함께 해결해 드릴게요!

함께 읽으면 좋은 글: 쿠버네티스 데몬셋 기본 개념 총정리, 클러스터 구축 및 초기 설정 입문 가이드