StatefulSet과 Deployment 비교
| 항목 | Deployment | StatefulSet |
|---|---|---|
| 기본 목적 | 무상태(Stateless) 애플리케이션 | 유상태(Stateful) 애플리케이션 |
| 대표 사용처 | 웹 서버, API 서버, 배치 워커 | DB, Kafka, Redis, ZooKeeper |
Pod 정체성 #
Deployment는 모든 파드는 동일한 존재이며 이름은 랜덤이고 서로를 교체해도 의미 차이가 없다.
하지만 StatefulSet은 파드마다 고유하고 고정된 정체성에 이름도 유지(재시작해도 동일) 클러스터 구성에 매우 중요하다.
스토리지 #
Deployment는 PVC를 쓰더라도 Pod와 1:1 보장이 되지 않고 Pod 재생성시에 다른 볼륨이 붙을 수 있다. 데이터 정합성 책임은 애플리케이션에 있고.
StatefulSet은 Pod마다 전용 PVC가 존재하며 파드 삭제후 재생성시 같은 볼륨을 재사용해 데이터 안정성을 확보한다.
스케일링 방식 #
Deployment는 병렬 스케일링에 빠르고 순서 개념이 없다.
StatefulSet은 순차적으로 db-0 1 2 순으로 생성 종료는 2 1 0 처럼 진행한다. 클러스터 안정성을 우선시함
| 항목 | Deployment | StatefulSet |
|---|---|---|
| Rolling Update | 기본 | 지원 |
| 업데이트 순서 | 무작위 Pod 단위 | Pod 번호 순서 보장 |
| 파괴적 업데이트 위험 | 낮음 | 잘못하면 클러스터 붕괴 |
네트워크 #
Deployment는 일반 Service를 사용하며 pod ip 변경을 신경쓰지 않는다.
StatefulSet은 Headless Service 필수고 Pod마다 고정 DNS ex. db-0.db.default.svc.cluster.local를 제공한다. 노드간 직접 통신이 필요한 시스템에 필수다
장애 복구 관점 #
Deployment에서 파드 장애가 나면 다른 파드로 대체하고 요청 단위 복원에 최적이지만
StatefulSet은 파드 장애가 나면 같은 파드번호 + 같은 볼륨으로 복구해야한다. 데이터 일관성 유지
Deployment를 써야하는 경우는
- Stateless API Server
- Traffic 대응이 중요
- 파드간 구분 의미 없음
- 빠른 롤링 배포 등
StatefulSet의 경우에는
- 데이터가 로컬 디스크에 있어야함
- pod 순서 / 이름이 중요
- master-follwer 구조
- 노드 간 직접 통신이 필요할때
Deployment = 트래픽 처리용
StatefulSet = 데이터 보존용
으로 요약할 수 있겠다.