Kubernetes에서 Stateful 앱에 Blue-Green 배포를 적용할 수 있을까?

들어가며

Kubernetes를 운영하다 보면 이런 고민을 하게 됩니다.

"우리 앱은 데이터를 로컬에 저장해야 하는데, Blue-Green 배포도 하고 싶어요"

결론부터 말하면, PVC 고정 + HPA + Blue-Green을 동시에 만족하는 깔끔한 방법은 없습니다. 하지만 이 문제를 해결하는 과정에서 Kubernetes 배포 전략의 본질을 이해할 수 있었습니다.

---

Kubernetes 워크로드 리소스 복습

먼저 기본기를 짚고 가겠습니다.

네 가지 주요 워크로드

리소스	핵심 목적	스케줄링
ReplicaSet	Pod 복제본 수 유지	임의 노드
Deployment	ReplicaSet + 롤링 업데이트/롤백	임의 노드
StatefulSet	상태 유지 (고유 ID, PVC)	순차적
DaemonSet	모든 노드에 1개씩	노드당 1개

 

핵심은 Deployment = Stateless, StatefulSet = Stateful입니다.

---

문제: Argo Rollouts에서 PVC를 고정하고 싶다면?

Argo Rollouts는 Blue-Green, Canary 같은 고급 배포 전략을 제공합니다. 하지만 Deployment 기반이라 StatefulSet처럼 volumeClaimTemplates를 지원하지 않습니다.

시도할 수 있는 방법들

1. 미리 생성한 PVC 참조

spec:
  replicas: 1  # RWO라면 1개만 가능
  template:
    spec:
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: my-app-pvc

한계: replicas를 늘릴 수 없음

 

2. EFS (ReadWriteMany) 사용

spec:
  replicas: 3  # RWX라 여러 Pod 가능
  template:
    spec:
      volumes:
      - name: shared
        persistentVolumeClaim:
          claimName: efs-pvc

한계: Pod별 고유 PVC가 아닌 공유 스토리지

 

3. StatefulSet 2개 + Service 전환

Blue/Green 두 개의 StatefulSet을 만들고 Service selector로 전환하는 방식입니다.

# Green으로 전환
kubectl patch svc my-app -p '{"spec":{"selector":{"version":"green"}}}'

한계: 수동 관리, 복잡도 증가, PVC 비용 2배

 

---

 왜 다들 Stateless로 설계할까?

여기서 의문이 생깁니다.

"그냥 StatefulSet에서 partition으로 카나리 배포하면 되지 않나?"

가능은 합니다. 하지만 현업에서는 거의 사용하지 않습니다.

 

12-Factor App이 답이다

 

현대 클라우드 네이티브 애플리케이션의 표준인 12-Factor App 원칙을 보면:

• Stateless Processes: 앱 프로세스는 상태를 저장하지 않음
• Backing Services: DB, 캐시는 외부 서비스로 분리
• Disposability: 빠른 시작/종료, 언제든 교체 가능

즉, 애플리케이션은 Stateless로, 데이터는 외부 저장소로 분리하는 게 표준입니다.

 

현업 표준 아키텍처

---

StatefulSet은 언제 쓰는가?

그렇다면 StatefulSet은 쓸모없는 걸까요? 아닙니다.

 

StatefulSet 사용 사례

• 자체 운영 DB: MySQL, PostgreSQL 클러스터
• 메시지 큐: Kafka, RabbitMQ
• 검색 엔진: Elasticsearch
• 분산 시스템: Zookeeper, etcd

StatefulSet의 표준 배포 전략: Rolling Update

StatefulSet에서는 Rolling Update가 90% 이상을 차지합니다.

역순(2→1→0)으로 업데이트: 보통 pod-0이 Primary/Master이기 때문

왜 Blue-Green이 아닐까요?

 

이유	설명
비용	PVC 2배 필요
복잡도	데이터 동기화 문제
안정성	DB는 빠른 배포보다 안전이 우선

 

Stateful 워크로드의 원칙: "느리고 안전하게"

---

워크로드별 배포 전략 총정리

워크로드	리소스	배포 전략
웹/API 서버	Argo Rollouts	Blue-Green, Canary
백그라운드 워커	Deployment	Rolling Update
DB (관리형)	RDS, Aurora	AWS 콘솔
자체 운영 DB	StatefulSet	Rolling Update
로깅 에이전트	DaemonSet	Rolling Update

---

결론

처음 질문으로 돌아가 봅시다.

"PVC 고정 앱에 Blue-Green 배포를 하고 싶다면?"

답변:

1. 정말 로컬 스토리지가 필요한지 재검토
2. 가능하면 Stateless로 재설계 + 외부 저장소 사용
3. 어쩔 수 없다면 StatefulSet + Rolling Update 사용

무리하게 StatefulSet에 Blue-Green을 적용하려 하기보다, 아키텍처를 개선하는 게 장기적으로 훨씬 이득입니다.

"복잡한 배포 전략보다 단순한 아키텍처가 낫다"

---

참고 자료

• Kubernetes 공식 문서 - Workloads
• Argo Rollouts 공식 문서
• 12-Factor App