Kubernetes에서 API 서버와 고정 식별자·디스크가 필요한 저장 서버를 배포합니다. Pod, Deployment, StatefulSet은 어떤 역할이 다른가요?

Pod는 함께 배치되어 네트워크·스토리지 볼륨·일부 수명을 공유하는 컨테이너 실행 단위입니다. Deployment와 StatefulSet은 Pod 자체가 아니라 Pod 집합을 원하는 상태로 유지하고 교체하는 상위 리소스입니다. 일반적인 API처럼 각 복제본이 대체 가능하고 안정적인 이름이나 전용 디스크가 필요하지 않다면 Deployment가 자연스럽습니다. 반대로 각 인스턴스의 순서 있는 이름, 안정적인 네트워크 식별자, Pod별 저장소가 필요하면 StatefulSet이 도움을 줍니다.

Deployment의 api-abc123 Pod가 죽으면 새로운 이름의 Pod가 생겨도 서비스가 같은 역할을 수행하면 됩니다. 반면 StatefulSet의 db-0, db-1은 재생성 뒤에도 ordinal 식별자를 유지하고, 각 Pod에 연결된 PVC를 다시 사용할 수 있습니다. 그러나 이름과 PVC를 유지한다는 것만으로 데이터 복제·리더 선출·트랜잭션 복구가 생기지는 않습니다. 애플리케이션이 각 노드의 역할과 복제 프로토콜을 구현하고, 여러 Pod가 같은 데이터를 동시에 쓰지 않을 조건도 정해야 합니다.

실행 단위와 관리자를 나눕니다

하나의 Pod 안 컨테이너는 같은 네트워크 네임스페이스를 사용하고 localhost로 통신할 수 있으며 함께 스케줄되고 함께 종료되는 경향이 있습니다. 그래서 밀접하게 결합된 보조 컨테이너를 넣을 수 있지만, 서로 독립적으로 확장되는 서버를 무조건 한 Pod에 넣으면 자원 단위와 장애 단위가 묶입니다. Deployment는 ReplicaSet을 통해 지정한 수의 교체 가능한 Pod를 유지하고 rolling update를 수행합니다. Service는 이 Pod들 중 Ready endpoint로 트래픽을 보낼 뿐, Pod 내부 상태를 복제하지 않습니다.

StatefulSet은 Pod 이름과 순서, PVC 연결을 안정적으로 유지하는 관리자입니다. Headless Service를 함께 사용하면 각 Pod를 DNS 이름으로 발견할 수 있어 클러스터 멤버 식별에 유용합니다. 하지만 순서 있는 시작이나 종료를 켠다고 DB의 quorum이 자동으로 맞춰지지는 않습니다. 애플리케이션이 db-0을 리더로 볼지, 재시작 중 데이터가 최신인지, 오래된 노드가 다시 쓰지 않는지를 별도로 검증해야 합니다.

선택 기준은 상태라는 이름보다 계약입니다

메모리 캐시가 있는 API를 StatefulSet으로 바꾼다고 메모리가 유지되지 않습니다. Pod가 죽으면 메모리는 사라지고, PVC에 저장하지 않은 상태는 복구되지 않습니다. 반대로 Deployment도 외부 DB를 사용하는 상태ful 서비스의 프런트엔드로 쓰일 수 있습니다. 중요한 질문은 Pod가 교체되어도 같은 역할을 맡을 수 있는지, 인스턴스별 식별이 프로토콜에 필요한지, 데이터 저장소의 수명이 Pod와 어떻게 연결되는지입니다.

스토리지 서버를 StatefulSet으로 배포한다면 attach·detach 지연, 영역 제약, fencing, 스냅샷과 복구 절차를 점검하겠습니다. API 서버라면 readiness와 무상태성, 세션 저장 위치, rolling update 중 구·신 버전 호환성을 확인합니다. 테스트는 Pod 재시작, 노드 장애, PVC 재연결, 여러 replica 동시 시작을 나누고 실제 상태·데이터·사용자 요청 결과를 관찰합니다. 이처럼 실행 컨테이너를 묶은 단위와 이를 교체·복구하는 선언적 관리자를 분리하는 것이 워크로드 컨트롤러(workload controller)의 핵심입니다.