Workload API vol. 3: DaemonSet, StatefulSet, Job, Cronjob

---

들어가며 👋

지난 포스팅에서는 무중단 서비스의 든든한 기반이 되는 레플리카셋(ReplicaSet) 과 디플로이먼트(Deployment) 에 대해 알아보았습니다. 이 둘은 웹 서버나 API 서버처럼 상태가 없고(Stateless) 계속 켜져 있어야 하는 서비스에 최적화되어 있었죠.

하지만 실제 운영 환경에서는 "모든 노드에 하나씩만 떠야 하는 파드", "데이터를 영구적으로 저장해야 하는 파드", "한 번 작업하고 깔끔하게 끝나는 파드" 등 다양한 요구사항이 존재합니다.

오늘은 쿠버네티스에서 이러한 특수 목적을 달성하기 위해 사용하는 4가지 특수 워크로드(DaemonSet, StatefulSet, Job, CronJob)와, 클러스터 운영의 필수 스킬인 노드 관리(Cordon, Drain)에 대해 알아보겠습니다. 🚀

---

1. 데몬셋 (DaemonSet): 모든 노드에 하나씩 👻

데몬셋은 레플리카셋의 특수한 형태로, 클러스터 내의 모든 노드에 파드를 딱 한 개씩만 생성하도록 보장하는 워크로드입니다.

가장 큰 특징은 replicas (파드 개수)를 아예 지정할 수 없다는 점입니다.

클러스터에 노드가 새로 추가되면 쿠버네티스가 알아서 새 노드에 데몬셋 파드를 하나 띄워주고, 노드가 삭제되면 파드도 함께 사라집니다. (특정 노드에 띄우고 싶지 않다면 nodeSelector나 Anti-Affinity로 예외 처리를 할 수 있습니다.)

💡 언제 사용할까?

주로 각 노드의 리소스 상태를 수집하는 모니터링 에이전트(Datadog, Prometheus Node Exporter)나 노드별 로그를 수집하는 로그 수집기(Fluentd) 등 모든 노드에서 반드시 돌아가야 하는 백그라운드 프로세스에 사용합니다.

① 데몬셋 배포 실습 (Prometheus-exporter)

정확한 이해를 위해 모니터링을 위한 프로메테우스 익스포터를 데몬셋으로 띄워보겠습니다.

# daemonset.yaml
apiVersion: apps/v1  # 데몬셋도 apps/v1을 사용합니다
kind: DaemonSet
metadata:
  name: prometheus-daemonset
spec:
  selector:
    matchLabels:
      tier: monitoring # 기능구별을 위한 이름표
      name: prometheus-exporter
  template:
    metadata:
      labels:
        tier: monitoring
        name: prometheus-exporter
    spec:
      containers:
      - name: prometheus
        image: prom/node-exporter
        ports:
        - containerPort: 80

# 생성 및 확인
$ kubectl apply -f daemonset.yaml
$ kubectl get pods -o wide  # 파드가 각 노드마다 하나씩 균등하게 배치된 것을 확인!

NAME                         READY   STATUS    RESTARTS   AGE     IP             NODE      NOMINATED NODE   READINESS GATES
prometheus-daemonset-2plvc   1/1     Running   0          4m17s   10.244.1.134   worker2   <none>           <none>
prometheus-daemonset-8g9bn   1/1     Running   0          4m17s   10.244.2.100   worker1   <none>           <none>

실행 결과를 보시면 각 워커 노드에 1개씩 데몬셋이 생성되어 돌아가고 있는 것을 확인할 수 있습니다.

② 데몬셋의 업데이트 전략

데몬셋의 업데이트 전략은 디플로이먼트와는 조금 다르게 동작합니다.

• OnDelete: 매니페스트(YAML)를 수정해 이미지를 변경해도 기존 파드가 자동으로 업데이트되지 않습니다. 관리자가 kubectl delete pod 명령으로 수동 삭제해야만 새 버전의 파드가 뜹니다. 데몬셋은 한 번 띄우면 장기간 켜두는 모니터링 용도가 많아 과거에 주로 쓰던 방식입니다.

• RollingUpdate: 최신 쿠버네티스에서 지원하는 방식입니다. 단, 하나의 노드에 파드를 2개 띄울 수 없으므로 maxUnavailable(동시에 삭제 가능한 파드 수)만 지정해서 롤링 업데이트를 수행합니다.

---

2. 스테이트풀셋 (StatefulSet): 영원한 데이터와 이름 💾

이름 그대로 상태(State)를 유지(ful) 해야 하는 워크로드를 위한 리소스입니다. 데이터베이스(MySQL, MongoDB 등)처럼 파드가 재시작되더라도 이전의 데이터를 그대로 가지고 있어야 할 때 사용합니다.

디플로이먼트(레플리카셋)와 비교하면 큰 차이점이 두 가지 있습니다.

1. 예측 가능한 이름: 파드 이름 뒤에 무작위 문자열이 붙는 디플로이먼트와 달리, sample-statefulset-0, sample-statefulset-1처럼 순차적인 숫자 인덱스가 붙습니다. 삭제될 때는 번호가 큰 것부터 역순으로 삭제됩니다.

2. 독립적인 영구 볼륨: spec.volumeClaimTemplates 설정을 통해 파드마다 고유한 영구 볼륨(Persistent Volume)을 붙여줍니다. 파드가 죽고 다른 노드에서 다시 살아나도, 이름이 똑같기 때문에 기존에 쓰던 볼륨을 그대로 다시 연결하여 데이터를 보존합니다.

① 스테이트풀셋 생성 실습

실습을 통해서 알아봅시다.

# sample-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sample-statefulset
spec:
  # 스테이트풀셋은 파드의 고유한 네트워크 ID를 위해 반드시 전용 Service가 필요함
  serviceName: sample-statefulset
  # 생성될 파드의 개수 (0번, 1번, 2번 순서대로 생성됨)
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: nginx-container
        image: nginx
        volumeMounts:
        # 하단의 volumeClaimTemplates에서 정의한 이름을 여기에 연결
        - name: www
          # 컨테이너 내부에서 데이터가 저장될 경로
          mountPath: /usr/share/nginx/html

  # 스테이트풀셋의 핵심: 각 파드마다 '개별' 볼륨을 자동으로 생성해주는 템플릿
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      # 한 노드에서만 읽기/쓰기 가능하도록 설정
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          # 각 파드별로 할당될 저장 공간 크기
          storage: 1G

$ kubectl apply -f sample-statefulset.yaml

# 파드 확인 (0, 1, 2 순서대로 생성됨)
$ kubectl get pods
# 볼륨 및 클레임 확인
$ kubectl get pvc
$ kubectl get pv

현 시점에서는 해당 명령어가 안될텐데 StatefulSet은 volumeClaimTemplates를 통해 각 파드마다 1GB짜리 전용 디스크 (PVC)를 요구합니다. 하지만 우리가 직접 구축한 로컬 쿠버네티스 환경에는 디스크를 자동으로 만들어주는 시스템(StorageClass) 이 기본적으로 없기 때문에, 디스크를 받지 못해 실행이 안되는 겁니다.

가능하게 하려면, 조건에 맞는 PV(Persistent Volume) 3개를 수동으로 직접 만들면 됩니다.

---

3. 잡 (Job): 목표 달성 후 깔끔하게 사라짐 🏃‍♂️

앞서 본 리소스들이 웹서버처럼 계속 켜져 있어야 하는 리소스라면, 잡(Job) 은 한 번(또는 지정된 횟수만큼)만 실행되고 목적을 달성하면 스스로 종료(Completed)되는 워크로드입니다.

주기적인 백업, 대규모 연산, 배치(Batch) 작업 등에 쓰입니다.

① 원주율(Pi) 계산 Job 실습

바로 실습 먼저 해보겠습니다.

# sample-job.yaml
apiVersion: batch/v1  # Job은 batch/v1을 사용합니다
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4  # 실패를 허용하는 최대 횟수

$ kubectl apply -f sample-job.yaml
$ kubectl logs pi-일련번호  # 완료된 파드의 로그를 찍어보면 파이 2천 자리가 출력됨!

해당 파드는 연산이 끝나면 Running 상태에서 Completed(완료) 상태로 변경되어 작업을 멈춥니다.

(이후 하단에 설명할 ttlSecondsAfterFinished 옵션을 주지 않으면 로그 확인을 위해 파드 자체는 삭제되지 않고 남아있습니다.)

② 핵심 파라미터 알아보기

• restartPolicy (실패 시 대처법)

• Never: 장애가 나면 아예 새로운 이름의 파드를 새로 생성해서 다시 시도합니다.

• OnFailure: 파드는 새로 만들지 않고, 기존 파드 안의 컨테이너 명령어만 다시 수행합니다.

• ttlSecondsAfterFinished: 잡이 '성공'하고 나서 일정 시간이 지나면 파드를 자동으로 삭제(청소)해주는 유용한 옵션입니다.

• 병렬 처리 옵션

  목적에 따라 잡을 병렬로 큐잉하여 처리할 수 있습니다.

  작업 유형	completions (성공 횟수)	parallelism (병렬 실행 수)
  한 번만 실행하는 단일 태스크	1 (기본값)	1 (기본값)
  지정된 횟수(N번)를 병렬로 실행	N	임의의 숫자
  순서대로 하나씩 실행하는 큐	설정 안 함	1
  N개를 병렬로 뽑아 쓰는 큐	설정 안 함	임의의 숫자 (N)

---

4. 크론잡 (CronJob): 주기적인 스케줄링 ⏰

잡(Job)이 수동으로 한 번 실행하는 것이라면, 크론잡(CronJob) 은 리눅스의 crontab처럼 특정 주기마다 Job을 자동으로 생성해 주는 워크로드입니다.

매일 자정 데이터베이스 백업, 매시간 로그 아카이빙 등에 필수적입니다.

# cronjob.yaml
apiVersion: batch/v1
kind: CronJob 
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"  # 1분마다 실행 (분 시 일 월 요일)
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent 
            command:
            - /bin/sh
            - -c
            - date; echo Hello from Kubernetes cluster
          restartPolicy: OnFailure

크론잡은 지정된 시간마다 파드를 계속 재생성합니다. 과거의 이력은 기본적으로 3개까지만 남기고 오래된 파드는 알아서 지워줍니다.

① 동시 실행 제어 (spec.concurrencyPolicy)

실행 주기가 짧거나 작업이 오래 걸려 이전 작업이 덜 끝났는데 다음 주기 시간이 되었을 때의 동작을 정의합니다.

• Allow (기본값): 제한 없이 무조건 새 잡을 실행합니다.

• Forbid: 이전 잡이 안 끝났으면 이번 주기는 건너뜁니다.

• Replace: 이전 잡을 강제로 취소하고 새로운 잡으로 덮어씌웁니다.

💡 [핵심] 실무 강사님 꿀팁: 로그는 반드시 외부(External)로!

크론잡이나 파드의 로그를 확인할 때 매번 터미널에서 kubectl logs를 치는 것은 매우 비효율적입니다. 실무(운영 단계)에서는 외부 로그 시스템(Elasticsearch, Datadog 등)으로 로그를 리다이렉션하여 중앙 집중화하는 것을 강력히 권장합니다.

1. 로그 파편화 해결: 워커 노드에 뿔뿔이 흩어진 로그를 한 곳에서 검색/분석

2. 고가용성(HA): K8s 클러스터나 노드가 죽어도 로그는 안전하게 보존

3. 참고: 과거에는 HostPath를 써서 노드에 직접 남기기도 했으나 요즘은 안 쓰는 추세입니다.

---

5. 노드 자원 보호하기 (Cordon & Drain) 🚧

지금까지 파드를 띄우는 법을 배웠다면, 이번엔 "문제가 있는 노드(서버)에서 파드를 대피시키거나 띄우지 못하게 막는 방법" 을 알아보겠습니다.

하드웨어 점검이나 커널 업데이트 시 필수적인 클러스터 운영 기술입니다.

① Cordon: "여기엔 더 이상 파드 배정 금지!"

특정 노드에 문제가 감지되어 현 상태는 유지하되, 새로운 파드가 스케줄링(배치)되는 것만 막고 싶을 때 사용합니다.

# worker1 노드를 스케줄링 불가능 상태로 변경
$ kubectl cordon worker1

# 디플로이먼트를 4개로 스케일 아웃 해보면?
$ kubectl scale deployment sample-deployment --replicas=4

👉 확인해 보면 기존에 worker1에 있던 파드는 그대로 살아있지만, 새로 추가된 파드들은 모두 worker2에만 몰려서 생성됩니다.

② Drain: "방빼세요. 노드 비우기"

노드를 완전히 재부팅하거나 교체해야 해서, 해당 노드에 돌고 있는 모든 파드를 다른 건강한 노드로 강제 대피(Eviction) 시킬 때 사용합니다. drain을 실행하면 해당 노드는 자동으로 cordon 상태가 됩니다.

# worker1의 모든 파드를 대피시킴
$ kubectl drain worker1 --ignore-daemonsets

👉 주의: 각 노드마다 반드시 하나씩 떠있어야 하는 데몬셋(DaemonSet) 파드는 대피가 불가능하므로 에러가 납니다.

따라서 위 명령어처럼 --ignore-daemonsets 옵션을 주어 데몬셋은 무시하고 나머지 파드들만 대피시켜야 합니다.

---

마치며 ✍️

오늘은 각 노드를 관리하는 데몬셋부터, 데이터를 지키는 스테이트풀셋, 일회성 작업을 위한 잡/크론잡, 그리고 노드를 안전하게 비우는 운영 스킬까지 쿠버네티스의 심화 워크로드들을 살펴보았습니다.

이러한 특수 워크로드들을 목적에 맞게 적재적소에 배치하는 것이 쿠버네티스를 쿠버네티스답게 쓰는 지름길입니다. 다음 포스팅에서는 외부 사용자에게 우리 서비스를 오픈하는 관문, 서비스(Service)와 인그레스(Ingress) 에 대해 다루어 보겠습니다.