[Kubernetes] Ch2. 워크로드 API 카테고리 - (3) DaemonSet, StatefulSet

데몬셋(DaemonSet)

레플리카셋의 특수한 형태라고 할 수 있는 리소스다

레플리카셋은 각 노드에 파드를 배치할 때, 상황에 따라 배치된다 (모든 노드에 반드시 배치되지 않는다)

하지만 데몬셋은 각 노드에 파드를 하나씩 배치하는 리소스다

레플리카 수를 지정할 수 없고 하나의 노드에 두 개의 파드를 배치할 수도 없다

만약 배치하고 싶지 않은 노드가 있다면 스케줄링으로 예외 처리를 할 수 있다

쿠버네티스 노드를 늘렸을 때도 데몬셋의 파드는 자동으로 늘어난 노드에서 기동한다

따라서 데몬셋은 호스트 단위로 수집하는 Fluentd나 각 파드 리소스 사용 현황 및 노드 상태를 모니터링하는 Datadog 등 모든 노드에서 반드시 수행해야 하는 프로세스를 위해 사용하는 것이 유용하다

데몬셋 생성

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: sample-ds
spec:
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - image: nginx:1.16
        name: nginx

kubectl get pods -o wide
NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
sample-ds-h62nw                      1/1     Running   0          31s   10.244.2.19   kindcluster-worker    <none>           <none>
sample-ds-k5klk                      1/1     Running   0          31s   10.244.1.15   kindcluster-worker2   <none>           <none>

데몬셋을 생성 후, 실행하면 각 노드에 하나씩 파드가 기동된 것을 확인할 수 있다

데몬셋 업데이트 전략

두 가지 업데이트 전략이 있다

OnDelete

데몬셋 매니페스트가 변경되었을 때, 기존 파드는 업데이트 되지 않는다

디플로이먼트와 달리 데몬셋은 모니터링이나 로그 전송과 같은 용도로 많이 사용하기 때문이다

업데이트는 다음 번에 다시 생성할 때나 수동으로 임의의 시점에 하게 되어 있다

RollingUpdate

디플로이먼트와 달리 동시에 생성할 수 있는 최대 파드 수(maxSurge)를 설정할 수 없다

(하나의 노드에 동일한 파드를 여러 개 생성할 수 없기 때문이다)

동시에 정지 가능한 파드 수(maxUnavailable)만 지정하여 RollingUpdate를 한다

스테이트풀셋(StatefulSet)

스테이트풀셋도 데몬셋과 마찬가지로 레플리카의 특수한 형태라고 할 수 있는 리소스다

데이터베이스 등과 같은 stateful한 워크로드에 사용하기 위한 리소스다

레플리카셋과 주된 차이점

• 생성되는 파드명의 접미사는 숫자 인덱스 부여
  • sample-statefulset-0, sample-statefulset-1 ….
  • 파드명이 바뀌지 않음
• 데이터를 영구적으로 저장하기 위한 구조
  • PersistentVolume을 사용하는 경우에는 파드를 재기동할 때 같은 디스크를 사용하여 다시 실행한다

스테이트풀셋 생성

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sample-statefulset
spec:
  serviceName: sample-statefulset
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - image: nginx:1.16
        name: nginx-container
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1G

spec.volumeClaimTemplates를 지정하여 영구 볼륨 클레임을 설정할 수 있다

이 설정은 클러스터 외부의 네트워크를 통해 제공되는 영구 볼륨 파드에 연결할 수 있다

파드를 재기동할 때나 다른 노드로 이동할 때 같은 데이터를 보유한 상태를 유지할 수 있다

kubectl get statefulsets
NAME                 READY   AGE
sample-statefulset   3/3     23s

kubectl get pods -o wide
NAME                                 READY   STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
sample-statefulset-0                 1/1     Running   0          4m14s   10.244.1.17   kindcluster-worker2   <none>           <none>
sample-statefulset-1                 1/1     Running   0          4m9s    10.244.2.21   kindcluster-worker    <none>           <none>
sample-statefulset-2                 1/1     Running   0          4m4s    10.244.1.19   kindcluster-worker2   <none>           <none>

# 스테이트풀셋에서 사용되고 있는 영구 볼륨 클레임 확인
kubectl get persistentvolumeclaims
NAME                       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
www-sample-statefulset-0   Bound    pvc-18d737c1-dbad-4034-9810-da5b3f8c5279   1G         RWO            standard       5m8s
www-sample-statefulset-1   Bound    pvc-ab76f95d-3dc2-4686-941e-5ba587d64a21   1G         RWO            standard       5m3s
www-sample-statefulset-2   Bound    pvc-847064f2-e229-4c86-9c30-247f47b4cc4d   1G         RWO            standard       4m58s

# 스테이트풀셋에서 사용되고 있는 영구 볼륨 확인
kubectl get persistentvolumes
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                              STORAGECLASS   REASON   AGE
pvc-18d737c1-dbad-4034-9810-da5b3f8c5279   1G         RWO            Delete           Bound    default/www-sample-statefulset-0   standard                8m3s
pvc-847064f2-e229-4c86-9c30-247f47b4cc4d   1G         RWO            Delete           Bound    default/www-sample-statefulset-2   standard                7m53s
pvc-ab76f95d-3dc2-4686-941e-5ba587d64a21   1G         RWO            Delete           Bound    default/www-sample-statefulset-1   standard                7m58s

스테이트풀셋 스케일링

스케일 아웃일 때는 인덱스가 가장 작은 것부터 파드를 하나씩 생성하고 이전에 생성된 파드가 Read 상태가 되고 나서 다음 파드를 생성한다

반면, 스케일 인일 때는 인덱스가 가장 큰 파드부터 삭제한다

스테이트풀셋은 0번째 파드가 항상 가장 먼저 생성되고 가장 늦게 삭제되기 때문에 0번째 파드를 마스터 노드로 사용하는 이중화 구조 애플리케이션에 적합하다

스테이트풀셋 라이프사이클

spec.podManagementPolicy

1. OrderedReady : 하나씩 파드를 생성하며 Ready 상태가 되면 다음 파드를 생성 - [기본값]
2. Parallel : 레플리카셋 등과 마찬가지로 병렬로 동시에 파드를 기동시킬 수 있다

스테이트풀셋 업데이트 전략

OnDelete

매니페스트를 수정하여 변경했더라도 기존 파드는 업데이트되지 않는다

업데이트는 다음 번에 다시 생성할 때나 수동으로 임의의 시점에 하게 되어 있다

RollingUpdate (기본값)

디플로이먼트와 다르게 추가 파드를 생성해서 롤링 업데이트를 할 수 없다

파드마다 Ready 상태인지 확인하고 업데이트하게 된다