1. 스테이트풀 서비스란?

• 스테이트리스 앱: 모든 요청을 어디서 처리해도 결과가 동일 (예: 웹 서버, API 서버)
• 스테이트풀 앱: 각 인스턴스가 고유한 상태(state)와 데이터를 유지해야 함 (예: MySQL, Redis, Kafka)

쿠버네티스에서 스테이트풀 서비스를 다룰 때 가장 큰 문제는 다음과 같습니다:

1. 네트워크 아이덴티티

   파드가 재시작되더라도 동일한 이름/주소를 가져야 클러스터 내에서 안정적으로 통신 가능.

2. 스토리지 지속성

   파드가 죽더라도 데이터가 유지되어야 하므로, 파드와 분리된 퍼시스턴트 볼륨(Persistent Volume, PV) 필요.

2. StatefulSet: 스테이트풀 서비스 핵심

쿠버네티스에서 스테이트풀 워크로드를 다룰 때 사용하는 기본 컨트롤러가 StatefulSet입니다.

StatefulSet의 특징

• 고정된 파드 네임: mysql-0, mysql-1, mysql-2처럼 순번이 부여됨.
• 순차적 배포/종료: Pod는 순서대로 생성되고 삭제됨.
• 고정된 네트워크 ID: Headless Service와 함께 사용하여 각 Pod가 고유 DNS 이름을 가짐.
• 퍼시스턴트 스토리지: VolumeClaimTemplate을 통해 각 Pod에 독립적인 PVC가 생성됨.

---

3. 주요 컴포넌트

(1) Headless Service

• 클러스터 IP를 부여하지 않고, 각 파드의 DNS를 직접 반환.
• 예: mysql-0.mysql.default.svc.cluster.local

  apiVersion: v1
  kind: Service
  metadata:
    name: mysql
  spec:
    clusterIP: None   # Headless Service
    selector:
      app: mysql
    ports:
    - port: 3306
      name: mysql

(2) StatefulSet

• 스테이트풀 서비스의 본체

  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: mysql
  spec:
    serviceName: mysql
    replicas: 3
    selector:
      matchLabels:
        app: mysql
    template:
      metadata:
        labels:
          app: mysql
      spec:
        containers:
        - name: mysql
          image: mysql:8.0
          ports:
          - containerPort: 3306
          volumeMounts:
          - name: data
            mountPath: /var/lib/mysql
    volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

여기서 volumeClaimTemplates는 각 파드별로 PVC를 자동 생성하여 데이터를 보존합니다.

4. 스테이트풀 서비스 예시: MySQL 클러스터

1. Headless Service 생성 → mysql-0, mysql-1, mysql-2 DNS 자동 할당.
2. StatefulSet 배포 → 각 파드가 고유한 PVC를 가져서 데이터 보존.
3. Pod 순서 보장 → mysql-0이 먼저 실행된 뒤, 그다음 mysql-1 실행.

이를 통해 단순한 DB뿐 아니라 ZooKeeper, Kafka, Redis Sentinel 같은 분산 시스템도 쿠버네티스에서 안정적으로 운영할 수 있습니다.

5. 운영 시 고려사항

• 스토리지 클래스: 퍼시스턴트 볼륨 프로비저닝 정책(예: SSD, HDD)을 잘 선택해야 함.
• 백업/복구 전략: PV에 의존하기 때문에 스토리지 레벨의 백업 필요.
• 스케일링: StatefulSet은 수평 확장이 가능하지만, 데이터 일관성/샤딩 고려가 필요.
• 롤링 업데이트: 순차적으로 파드를 교체하므로, DB 마이그레이션 같은 과정과 잘 맞물려야 함.

6. 내용 보강

쿠버네티스 v1.34 기준으로 StatefulSet 및 스테이트풀 서비스 운영 시 고려해야 할 추가적인 보강점과 한계는 다음과 같습니다.

한계점

1. PVC 누수 문제

   StatefulSet을 삭제해도 PVC는 기본적으로 남아 있습니다. 이는 데이터 보호 차원에서는 안전하지만, 관리자가 직접 삭제하지 않으면 스토리지 리소스 누수가 발생할 수 있습니다.

2. 스토리지 확장/재할당의 어려움

   StatefulSet이 관리하는 PVC는 자동 확장 및 재할당이 까다롭습니다. 대규모 데이터베이스 환경에서는 스토리지 확장이 수동 개입을 필요로 하며, 운영 복잡도가 올라갑니다.

3. 라이브 마이그레이션 부재

   파드를 상태 유지한 채 다른 노드로 옮기는 live migration 기능은 여전히 제공되지 않습니다. 따라서 노드 장애나 리밸런싱 시 다운타임이 발생할 수 있습니다.

4. Pod 순서 보장 한계

   StatefulSet은 파드의 순차 실행/종료를 보장하지만, 데이터 마이그레이션 로직이나 복잡한 동기화 작업이 필요한 경우에는 유연성이 부족합니다.

보강 방향

1. Operator 도입

   MySQL, Kafka, Redis와 같은 스테이트풀 서비스는 전용 Operator를 사용하면 스케일링, 백업, 장애 복구 자동화가 가능해 운영 효율성이 크게 향상됩니다.

2. 스토리지 전략 강화

   • 스토리지 클래스(StorageClass) 정책을 서비스 특성에 맞게 선택
   • 볼륨 스냅샷/복제/멀티 존 복제 활용
   • 데이터 복제 전략(DB 레플리카, 로그 복제 등) 병행

3. 백업 및 복구 체계 확립

   PV 수준 백업과 애플리케이션 레벨 백업을 동시에 운영해야 안정성이 확보됩니다. 특히 장애 복구 시 PVC와 Pod 순서를 보장하는 전략이 필요합니다.

4. 롤링 업데이트/마이그레이션 전략 개선

   단순히 순차적 교체만으로는 부족하므로, 데이터 변환 로직이나 복제 전략을 업데이트 과정에 통합해야 합니다.

5. 모니터링 및 알림 체계 강화

   스테이트풀 서비스는 CPU/메모리뿐 아니라 I/O 패턴, 지연 시간, 스토리지 사용량을 세밀히 모니터링해야 합니다. OpenTelemetry, Prometheus, Grafana 등을 연동하는 것이 권장됩니다.

6. 커뮤니티 기능 추적 및 실험적 기능 활용

   StatefulSet 개선을 위한 KEP(쿠버네티스 개선 제안)과 SIG 활동을 꾸준히 추적하여, 차세대 기능(live migration, 더 정교한 볼륨 재배치 등)에 대비하는 것이 필요합니다.