- 스테이트풀셋의 스토리지는?
- 스테이트풀셋에서 파드가 안정적으로 서비스 되는 방법은 알아 봤는데
- 그렇담 스토리지는 어떻게 안정적으로 유지할까?
- 여기서 스토리지는 영구적으로 유지되어야 하고 각 파드 별로 별도의 스토리지를 가져야 한다.
- 그렇기 때문에 퍼시스턴트 볼륨 클레임을 이용하고 파드 하나당 하나의 퍼시스턴트 볼륨 클레임을 이용한다. ( 퍼시스턴트 볼륨 클레임도 인덱스를 붙여 관리한다. )
- 그래서 스테이트풀셋은 파드 템플릿과 볼륨 클레임 템플릿 모두 가질 수 있다.
- 스케일 down 시 퍼시스턴트 볼륨 클레임
- 스케일 up을 할 경우 파드와 파드에서 참조하는 퍼시스턴트 볼륨 클레임이 생성된다.
- 하지만 스케일 down 했을 때 퍼시스턴트 볼륨 클레임은 삭제되지 않는다.
- 스케일 up과 down이 레플리카 수만 수정하면 되는 쉬운 작업이다 보니 데이터가 쉽게 사라지는 것을 방지하기 위해서 볼륨의 자동 삭제는 지원하지 않는다.
- 삭제를 원할 경우 수동으로 퍼시스턴트 볼륨을 삭제하여야 한다.
- 스케일 down 했던 스테이트풀셋을 다시 스케일 up하면 자동으로 이전에 있던 퍼시스턴트 볼륨 클레임과 바인딩이 이뤄지게 된다.
- 쿠버네티스가 파드가 죽은지 확실하지 않을 때는?
- 스테이트풀셋은 최대 하나의 파드를 보장한다.
- 여기서 최대 하나란, 쿠버네티스가 단 하나의 파드만 동일한 아이덴티티, 동일한 퍼시스턴트볼륨클레임 바인딩이 가능하도록 보장해주는 것이다.
- 스테이트풀셋 사용하기
- 필요한 것
- 퍼시스턴트 볼륨 ( 동적 프로비저닝을 지원하지 않으면 직접 생성)
- 거버닝 서비스
- 스테이트풀셋 자체
- 거버닝 서비스
- 거버닝 서비스의 매니패스트, clusterIP를 None으로 생성
- apiVersion: v1 kind: Service metadata: name: kubia spec: clusterIP: None selector: app: kubia ports: - name: http - port 80
- 스테이트풀 셋 매니페스트
- 디플로이먼트 매니페스트와 다르지 않다. 다만 추가로 볼륨 클레임 템플릿이 들어간다.
- apiVersion: apps/v1beta1 kind: Statefulset metadata: name: kubia spec: serviceName: kubia replicas: 2 template: metadata: labels: app: kubia //스테이트풀셋으로 생성된 파드는 app=kubia label spec: containers: - name: kubia image: luksa/kubia-pet volumeMounts: - name: data mountPath: /var/data //pvc볼륨을 마운트 할 경로 VolumeClaimTemplates: //볼륨 클레임 생성 템플릿 - metadata: name: data spec: resources: requests: storage: 1Mi accessModes: - ReadWriteOnce
- 생성!
- 스테이트풀 셋을 생성한 즉시 보면 레플리카 수가 2인데 하나의 파드만 생성 되고 있다.
- 이는 레이스 컨디션을 방지하기 위해 하나의 파드가 완전히 가동된 후 생성이 시작되는 것이다.
- 파드를 삭제하여도 똑같은 아이덴티티를 가진 파드가 생성된다.
- 이때 생성된 파드는 다른 노드로 이사를 갈 수도 있다.
- 스테이트풀 셋 업데이트
- 템플릿이 변화 됐을때 파드들은 어떻게 될까?
- 기본적으로 레플리카셋처럼 작동하기 때문에 자동으로 변화되지 않는다.
- 템플릿에 맞춰 변화를 시키려면 파드를 강제 삭제 해주자.
- 노드 실패를 처리하는 과정 이해하기
- 노드가 갑자기 실패한다면 ( 상태를 알 수 없게 된다면 ) 그 안의 파드 상태 역시 알 수가 없다. -ex) 노드의 네트워크를 강제로 끊을 경우 상태를 알 수 없다.
- 그렇기 때문에 스테이트풀셋에서는 해당 파드가 죽었는지 확신 할 수 없기 때문에 새로운 파드를 생성치 않는다.
- 이 때 정상화 하기 위해서 노드를 완전 삭제하거나 파드를 삭제해 쿠버네티스에게 알려줘야 한다.
