Kubernetes Statefulset / 쿠버네티스, 워크로드, 스테이트풀셋, 서비스

Kubernetes Statefulset

---

Statefulset은 application의 상태를 관리해주는 API 오브젝트

Deployment와 비슷하게 container spec에 기반을 두지만, Pod간 독자성을 제공

즉, persistent한 식별자를 제공해주며 네트워크, 스토리지, 순서등의 기능이 있다는 뜻

말 그대로 stateless한 서비스에는 지금까지 공부한 다른 것들을 이용해도 되지만, stateful한 서비스 (ex. DB, network)등에 대해서는 Statefulset을 사용하여 서비스해야함

Deployment에서 Replicas를 1로 고정하여 사용해도 되긴 하지만, 기능과 의미를 완벽히 보장하지 않기에 권장하지 않음

 

간단하게 정리하자면

  - Deployment(Replicaset) -> 동일하고 교체 가능한 서버

  - Statefulset -> 개별 관리가 필요하고 대체가 불가능한 서버

로 이해하면 된다.

아래 예시는 network statefulset 에 대한 내용이다.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  minReadySeconds: 10 # by default is 0
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

nginx의 headless-service가 있고 headless-service의 특성상 Pod의 endpoint로 DNS가 생성됨

web의 이름을 가진 3개의 nginx container가 특정 Pod에서 띄워진다는 의미

volumeClaimTemplates를 통해 각 파드에 PVC를 생성하는 템플릿

 

Statefulset Deploy

---

그리고 각각 순서를 보장해주는데 해당 명세를 기준으로 설명하자면,

- 3개의 replicas가 있으니 Pod를 {0 .. N-1}의 순서로 생성

- 삭제될때는 역순으로 종료

- Scaling이 될때는 앞선 Pod가 Running or Ready state일때 진행 됨

- Pod가 종료될 땐 모든 후속 Pod가 종료되어야 완전히 종료됨

등의 특징을 갖고 있다.

즉 web-0, web-1, web-2순으로 각각 0이 Running or Ready state어야지 1번이 실행된다는 뜻이고,

반대로 Scaling하여 replicas=1로 한다면, 2가 완전히 종료되고 1이 종료되는 순서이다.

그리고 web-0에 문제가 있다면 web-1은 종료되지 않는다.

Kubernetes Statefulset 순서도

 

Deployment와 마찬가지로 주로 Rolling Update를 사용하는데,

Deployment에서도 사용하던 옵션인 .spec.updateStrategy.rollingUpdate.maxUnavailable 옵션도 있어서, 업데이트 과정에 사용하지 않아도 괜찮은 Pod의 수를 지정해줄 수 있음

Percentage(5%) 또는 integer(1)로 설정 가능

.spec.podManagrementPolicy를 Parallel로 설정하면 병렬로 실행, 종료도 가능함

이런 옵션을 통해 순차적 처리가 필요없는 케이스도 처리 가능

volumeClaimTemplates로 생성된 PVC도 정책에 따라 Pod가 삭제되어도 바로 삭제되지 않도록 설정 가능

apiVersion: apps/v1
kind: StatefulSet
...
spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain #삭제될때 유지해주는 옵션
    whenScaled: Delete #Scale될때 바로 삭제하는 옵션
...

이런식으로 삭제, scale등에 따라 각각 옵션 설정 가능

 

해당 예시에서는 Network statefulset 관련 예시 위주로 확인했지만 스토리지, 순서 등 다양한 케이스에서 활용 가능

Cloud native한 환경에서는 항상 Stateful한 Service에 대한 고민이 많이 필요한 것 같다.