kubernetes 스테이트풀셋

스테이트 풀셋

참고
스테이트리스 - 하나만 있으면 되는 파드 또는 퍼시스턴트 데이터를 갖지 않는 상태가 없는 어플리케이션
스테이트풀 - 데이터 스토어 처럼 데이터를 계속 유지하는 상태가 있는 어플리케이션

 

스테이트풀 파드 복제하기

 

스테이트풀 파드를 복제할때 레플리카셋을 사용하면?

레플리카셋은 하나의 파드 템플릿에서 여러개의 파드 레플리카를 생성하는데 생성된 모든 파드는 하나의 퍼시스턴트  볼륨 클레임을 사용해야 한다.

즉, 각 레플리카가 각자의 퍼시스턴트 볼륨 클레임을 가질 수 없다.

 

 

개별 스토리지를 갖는 레플리카 여러개 실행하기

 

개별 스토리지 볼륨을 사용하는 파드를 가지려면 어떻게 해야할까

 

수동으로 파드 생성하기

 

파드를 수동으로 생성해서 각 파드가 다른 퍼시스턴트 볼륨 클레임을 가지게 한다.

근데 이건 레플리카셋이 감시하지 않으니까 직접 파드를 관리하고 생성 삭제해야한다 아주 안좋음

 

파드 인스턴스 별로 하나의 레플리카셋 사용하기

 

파드를 직접 생성하지 않고 대신 여러개의 레플리카셋을 생성

이렇게하면 노드 실패나 고장으로 인한 삭제는 자동으로 재스케줄링은 되지만, (레플리카셋을 사용하니까)

단일 레플리카셋을 쓰는것보다 훨씬 번거롭다. 관리 포인트가 많아지니

 

 

동일 볼륨을 여러 개 디렉터리로 사용하기

 

 

동일한 퍼시스턴트 볼륨을 사용하지만, 각 파드가 볼륨 내부에서 별도 디렉토리를 사용하는 방법도 있을 수 있다.

하지만 파드 템플릿에서 어떤 파드가 어떤 디렉토리를 써야할지 전달 할 수 없다.

 

 

각 파드에 안정적인 아이덴티티 제공하기

 

특정 어플리케이션은 안정적인 네트워크 아이덴티티가 필요하다

종료되거나 새로운 것으로 교체되도 동일한 호스트 이름과 ip를 갖는게 필요한 걸 의미한다.

ACL 등 다양한 이유 떄문

 

쿠버네티스에서는 파드가 재스케줄링 되기 쉽고, 새로운 파드는 새로운 호스트 이름과 ip 주소를 할당 받는다.

안정적인 네트워크 아이덴티티가 없다면 파드 등이 재스케줄링 될때마다 모든 어플리케이션 클러스터가 재구성되야 한다.

 

 

각 파드 인스턴스별 전용 서비스 사용하기

 

이 문제를 해결하려면?

각 개별 레플리카에 개별 쿠버네티스 서비스를 생성해서 클러스터에 안정적인 네트워크 주소를 제공한다.

서비스의 ip는 안정적이니 각 멤버를 서비스 ip 로 접근시키는 방법이 있다.

 

하지만, 개별 파드는 자신의 ip 를 알 수 없어서 다른 파드에서 사용할 수 없다?

 

이런 문제들을 해결하기 위해 스테이트풀셋 이 있다.

 

스테이트풀셋

 

스테이트풀셋은 어플리케이션의 인스턴스가 각각 안정적인 이름과 상태를 가지고 독립적으로 취급된다.

 

스테이트풀셋과 레플리카셋 비교

스테이트풀은 개별 인스턴스에 이름을 부여하고 개별적으로 관리한다.

스테이트풀 파드가 종료되면 새로운 파드는 교체되는 파드와 동일한 이름, 네트워크, 상태 그대로 다른 노드에서 살아난다.

 

레플리카셋은 이름을 정확히 알 필요가 없고 언제든 완전히 새로운 파드로 교체된다.

 

 

안정적인 네트워크 아이덴티티 제공하기

 

스테이트풀셋으로 생성된 파드는 파드 뒤에 인덱스(0부터 시작)가 할당되고 파드의 이름과 호스트 이름, 안정적인 스토리지를 붙일 수 있다.

 

 

 

거버닝 서비스

 

스테이트풀 파드는 때론 호스트 이름으로 다뤄져야 할 필요가 있다

스테이트풀셋은 거버닝 헤드리스 서비스를 생성해서 파드에게 네트워크를 제공한다.

이 서비스를 통해 자체 DNS 로 파드의 주소를 지정할 수 있다.

 

예를들어 a-0.foo.default.svc.cluster.local 로 파드 A-0 에 접근 할 수 있다.

레플리카셋에서는 이게 불가능하다.

 

스테이트풀셋 교체하기

 

스테이트풀셋은 레플리카셋이랑 비슷하게 새로운 인스턴스로 교체되도록 하는데,

교체되더라도 이전에 사라진 파드와 동일한 호스트 이름을 갖는다.

 

스테이트풀셋 스케일링

 

특징 3가지

 

• 스테이트풀셋의 스케일 다운의 좋은 점은 어떤 파드가 제거될지 알 수 있다는 것,
  • 레플리카셋과 대조적이다
• 스테이트풀셋의 스케일 다운은 항상 가장 높은 인덱스의 파드를 먼저 제거한다
  • 따라서 예측이 가능하다
• 스테이트풀셋은 인스턴스 하나라도 비정상이면 스케일 다운 작업을 하지 않는다.
  • 여러개 노드가 동시에 다운 되는 경우 데이터를 잃을 수 있기 때문

 

 

스테이트풀 인스턴스에 안정적인 전용 스토리지 제공

 

스테이트풀 파드의 스토리지는 영구적이어야 하고 파드와 분리되어야 한다.

스테이트풀셋의 각 파드는 별도의 퍼시스턴트 볼륨 클레임을 참조해야한다. (스테이트풀셋에서 제공된다.)

 

볼륨 클레임 템플릿과 파드 템플릿을 같이 구성한다.

스테이트풀셋이 퍼시스턴트 볼륨 클레임 또한 생성할 수 있다.

 

퍼시스턴트볼륨클레임의 생성과 삭제의 이해

 

생성할땐 파드와 퍼시스턴트 볼륨 클레임을 생성했다가, 

스케일 다운을 하면 클레임은 남겨뒀다가 파드만 삭제한다

만약 클레임을 삭제하고 싶으면 수동으로 삭제해줘야 한다.

 

동일 파드의 새 인스턴스에 클레임 다시 붙이기

클레임은 유지 되어있다가  스케일 업될때 다시 해당 클레임을 연결 한다.

 

 

스테이트풀셋 사용하기

 

먼저 데이터 파일 저장을 위한 퍼시스턴트 볼륨과 스테이트풀셋에 필요한 거버닝 서비스와

스테이트풀셋을 생성한다.

 

퍼시스턴트 볼륨 생성하기

 

디스크를 먼저 생성하고

gcloud compute disks create --size=1GiB --zone=europe-west1-b pv-a
gcloud compute disks create --size=1GiB --zone=europe-west1-b pv-b
gcloud compute disks create --size=1GiB --zone=europe-west1-b pv-c

퍼시스턴트 볼륨을 생성한다.

kind: List
apiVersion: v1
items:
- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv-a
  spec:
    capacity:
      storage: 1Mi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    gcePersistentDisk:
      pdName: pv-a
      fsType: ext4
- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv-b
  spec:
    capacity:
      storage: 1Mi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    gcePersistentDisk:
      pdName: pv-b
      fsType: ext4
- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv-c
  spec:
    capacity:
      storage: 1Mi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    gcePersistentDisk:
      pdName: pv-c
      fsType: ext4

 

거버닝 서비스 생성하기

apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  clusterIP: None
  selector:
    app: kubia
  ports:
  - name: http
    port: 80

 

스테이트풀셋 생성하기

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kubia
spec:
  serviceName: kubia
  replicas: 2
  selector:
    matchLabels:
      app: kubia # has to match .spec.template.metadata.labels
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: luksa/kubia-pet
        ports:
        - name: http
          containerPort: 8080
        volumeMounts:
        - name: data
          mountPath: /var/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      resources:
        requests:
          storage: 1Mi
      accessModes:
      - ReadWriteOnce

 

생성된 파드 살펴보기

kubectl get po kubia-0 -o yaml