StatefulSet — 순서와 고유 정체성이 필요한 워크로드
Kubernetes 공식 문서(kubernetes.io) 및 운영 블로그 종합 — 아키텍처부터 스케줄링까지 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/overview/components, workloads/pods, services-networking, pod-qos, pod-lifecycle) + 운영 블로그(Komodor, Datadog 등) 교차 확인 Kubernetes 공식문서 StatefulSets, Basic StatefulSet Tutorial
이 모듈을 다 읽으면
- StatefulSet이 Deployment와 달리 Pod에 순서 있는 고유 식별자를 부여하는 이유를 설명할 수 있다
- 헤드리스 서비스(clusterIP: None)가 StatefulSet과 함께 쓰이는 이유를 설명할 수 있다
k8s-learn-02의 Deployment(Pod가 서로 대체 가능·구분 불필요)와 대비해, StatefulSet이 왜 각 Pod에 안정적이고 고유한 정체성을 부여하는 별도의 워크로드 컨트롤러로 존재하는지를 정리한다.
순서 있는 고유 인덱스 — Deployment의 Pod와 근본적으로 다른 점
Deployment가 관리하는 Pod들은 서로 완전히 대체 가능(interchangeable)해서 이름도 무작위 해시가 붙는다. 반면 StatefulSet의 Pod는 고유한 순서 인덱스(ordinal index)를 가지며, 이름이 `<StatefulSet이름>-<인덱스>` 형태(예: web-0, web-1)로 고정된다 — 즉 web-0이 죽고 재생성되어도 다시 web-0이라는 이름과 정체성을 그대로 유지한다. 이 '안정적인 네트워크 정체성'은 분산 데이터베이스처럼 '어느 노드가 어떤 역할(리더/특정 샤드)을 맡는지'가 중요한 상태 저장 애플리케이션에 필수적이다.
핵심 포인트
- Deployment의 Pod: 이름이 무작위 해시, 서로 완전히 대체 가능 vs StatefulSet의 Pod: `이름-인덱스` 형태의 고정 식별자, 재생성돼도 같은 이름·정체성 유지
- 이 안정적 정체성은 리더/샤드 역할이 노드마다 고정돼야 하는 분산 데이터베이스류 워크로드에 필수
헤드리스 서비스와 함께 써야 하는 이유
일반 Service는 clusterIP로 단일 가상 IP를 만들어 그 뒤의 Pod들에 트래픽을 로드밸런싱한다 — 이러면 '어느 특정 Pod'에 직접 접속할 방법이 없다. StatefulSet은 이 대신 clusterIP: None으로 설정한 헤드리스 서비스와 함께 쓰는데, 헤드리스 서비스는 단일 가상 IP를 만들지 않고 각 Pod마다 개별 DNS 레코드를 만들어준다 — 그 결과 `web-0.서비스이름`, `web-1.서비스이름`처럼 특정 Pod를 이름으로 직접 지목해 접속할 수 있게 된다. 이는 StatefulSet의 순서 있는 고유 정체성을 네트워크 계층(DNS)까지 그대로 이어주는 짝이다.
핵심 포인트
- 일반 Service(단일 가상 IP, 로드밸런싱)로는 특정 Pod를 직접 지목해 접속할 수 없음
- 헤드리스 서비스(clusterIP: None)는 단일 IP 대신 Pod마다 개별 DNS 레코드를 생성 — `web-0.서비스이름`처럼 특정 Pod를 직접 지목 가능, StatefulSet의 고유 정체성을 DNS까지 확장