Kubernetes Pod와 워크로드: Deployment·StatefulSet·DaemonSet·Job 선택 가이드

개요

Kubernetes에서 애플리케이션을 실행하는 최소 단위는 컨테이너가 아니라 Pod다. 그리고 Pod를 직접 만들어 운영하는 일은 거의 없다. 대신 목적에 맞는 워크로드 리소스(Deployment·StatefulSet·DaemonSet·Job/CronJob)를 선언하면, 이들이 컨트롤러로서 Pod의 생성·교체·복구를 대신 관리한다. 어떤 워크로드를 고르느냐가 배포 안정성과 운영 편의성을 좌우하므로, 각 리소스의 보장 조건을 이해하는 것이 중요하다. 선언형 수렴 모델의 기초는 Kubernetes - 개요와 아키텍처를 참고한다.

핵심 개념과 원리

Pod: 배포의 최소 단위

Pod는 하나 이상의 컨테이너를 묶은 논리적 호스트다. 같은 Pod 안의 컨테이너들은 다음을 공유한다.

• 네트워크 네임스페이스: 같은 IP를 공유하며 localhost로 서로 통신하고 포트를 나눠 쓴다.
• 스토리지 볼륨: 같은 볼륨을 마운트해 파일을 주고받을 수 있다.
• 생명주기: 함께 스케줄되고 같은 노드에서 실행된다.

대부분의 Pod는 컨테이너 1개지만, 사이드카(sidecar) 패턴에서는 로그 수집기·프록시(예: 서비스 메시 사이드카) 같은 보조 컨테이너를 함께 둔다. 초기화 전용 컨테이너인 initContainer는 메인 컨테이너보다 먼저 순차 실행되어 준비 작업(마이그레이션·설정 다운로드)을 처리한다.

Pod는 본질적으로 **일시적(ephemeral)**이다. 죽으면 되살아나는 게 아니라 새 IP를 가진 새 Pod로 교체된다. 그래서 Pod를 직접 만들지 않고 컨트롤러에 맡긴다.

ReplicaSet: 복제본 유지

ReplicaSet은 “지정한 개수의 동일한 Pod가 항상 실행되도록” 보장하는 컨트롤러다. label selector로 자신이 관리할 Pod를 식별하고, 부족하면 만들고 남으면 지운다. 다만 ReplicaSet을 직접 쓰는 경우는 드물다. 롤링 업데이트 기능이 없기 때문이다.

Deployment: 무상태 워크로드의 표준

Deployment는 ReplicaSet을 감싸 롤링 업데이트와 롤백을 제공하는, 무상태(stateless) 애플리케이션의 사실상 표준이다. 이미지 버전을 바꾸면 Deployment는 새 ReplicaSet을 만들고 Pod를 점진 교체하며, 각 리비전 이력을 보관해 언제든 이전 버전으로 되돌릴 수 있다.

Deployment → ReplicaSet(v1) → Pod, Pod, Pod
           ↘ ReplicaSet(v2) → Pod, Pod, Pod   (롤링 교체)

maxSurge(추가 허용 파드)와 maxUnavailable(동시 중단 허용 파드)로 교체 속도와 가용성 사이를 조절한다.

StatefulSet: 상태 있는 워크로드

데이터베이스처럼 각 인스턴스가 고유한 정체성과 저장소를 가져야 하는 워크로드는 StatefulSet을 쓴다. Deployment와 달리 다음을 보장한다.

• 안정적 네트워크 ID: Pod 이름이 db-0, db-1처럼 순서대로 고정되고, 헤드리스 Service를 통해 각 Pod에 안정적 DNS가 부여된다.
• 안정적 스토리지: volumeClaimTemplates로 Pod마다 전용 PVC가 생성되고, Pod가 재생성돼도 같은 볼륨에 다시 붙는다.
• 순차 배포·스케일: db-0 → db-1 순으로 생성하고 역순으로 종료한다.

상세한 스토리지 연동은 Kubernetes - 설정과 스토리지를 참고한다.

DaemonSet: 노드마다 하나

DaemonSet은 클러스터의 모든(또는 선택된) 노드에 정확히 하나씩 Pod를 배치한다. 노드가 추가되면 자동으로 그 노드에도 Pod가 생긴다. 로그 수집기(Fluent Bit), 모니터링 에이전트(node-exporter), CNI/스토리지 플러그인처럼 노드 단위로 동작해야 하는 인프라 컴포넌트에 쓴다.

Job과 CronJob: 배치 작업

Job은 “완료를 목표로 하는” 일회성 작업이다. 지정한 횟수만큼 Pod를 성공적으로 끝내면 완료로 표시하고 재시작하지 않는다. 데이터 마이그레이션, 배치 처리에 적합하다. CronJob은 Job을 cron 스케줄에 따라 주기 실행한다(백업, 리포트 생성).

워크로드 선택 표

워크로드	상태	정체성	대표 용도
Deployment	무상태	무작위 이름	웹/API 서버, 마이크로서비스
StatefulSet	상태	고정 순번·전용 볼륨	DB, Kafka, 분산 저장소
DaemonSet	무상태	노드당 1개	로그·모니터링 에이전트, CNI
Job	배치	완료 지향	마이그레이션, ETL
CronJob	배치(주기)	스케줄 실행	백업, 정기 리포트

실전

Deployment 롤링 업데이트와 롤백

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 교체 중 최대 1개 초과 허용
      maxUnavailable: 0    # 동시에 중단되는 파드 0개(가용성 우선)
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: myorg/api:1.4.0
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }

kubectl set image deploy/api api=myorg/api:1.5.0   # 새 버전 롤아웃
kubectl rollout status deploy/api                  # 진행 상황 확인
kubectl rollout history deploy/api                 # 리비전 이력
kubectl rollout undo deploy/api                     # 직전 버전으로 롤백
kubectl rollout undo deploy/api --to-revision=3     # 특정 리비전으로

readinessProbe가 없으면 아직 준비되지 않은 새 Pod로 트래픽이 흘러 롤아웃 중 오류가 발생한다. 무중단 롤링의 핵심은 프로브 설정이다.

StatefulSet 예시

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: pg
spec:
  serviceName: pg-headless   # 헤드리스 Service로 안정적 DNS 제공
  replicas: 3
  selector:
    matchLabels: { app: pg }
  template:
    metadata:
      labels: { app: pg }
    spec:
      containers:
        - name: pg
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:       # Pod마다 전용 PVC 자동 생성
    - metadata: { name: data }
      spec:
        accessModes: [ReadWriteOnce]
        resources:
          requests: { storage: 20Gi }

함정과 베스트 프랙티스

• DB를 Deployment로 띄우지 말 것: 무작위 이름·공유 스토리지 가정 때문에 데이터 손상 위험. 상태 워크로드는 StatefulSet.
• **maxUnavailable: 0 + readinessProbe**로 진짜 무중단 배포를 구성한다. 프로브 없는 롤링은 무중단이 아니다.
• **Job에는 backoffLimit·activeDeadlineSeconds**를 설정해 무한 재시도·좀비 작업을 막는다.
• **CronJob concurrencyPolicy**를 Forbid로 두면 이전 실행이 끝나기 전 중복 실행을 방지한다.
• **PodDisruptionBudget(PDB)**로 노드 드레인 시 동시에 내려가는 복제본 수를 제한해 가용성을 지킨다.
• Deployment 이력 보관: revisionHistoryLimit을 너무 낮추면 롤백 가능한 리비전이 사라진다.

정리

Pod는 네트워크·스토리지를 공유하는 배포 최소 단위이지만 일시적이므로 직접 다루지 않는다. 무상태 서비스는 롤링·롤백을 제공하는 Deployment, 정체성과 전용 볼륨이 필요한 상태 워크로드는 StatefulSet, 노드 단위 에이전트는 DaemonSet, 완료 지향·주기 작업은 Job/CronJob을 쓴다. 워크로드가 만든 Pod에 트래픽을 안정적으로 연결하는 방법은 Kubernetes - 서비스와 네트워킹, 무중단 교체 전략의 이론은 배포 전략 - Rolling·Blue-Green·Canary에서 이어진다.