[Ch10] 스테이트풀셋: 복제된 스테이트풀 애플리케이션 배포하기

[lees741]

Ch10. 스테이트풀셋: 복제된 스테이트풀 애플리케이션 배포하기

10.1 스테이트풀 파드 복제하기

• 레플리카셋을 통해 복제된 파드는 모두 동일한 퍼시스턴트 볼륨 클레임을 참조
• 즉 모든 레플리카는 동일한 퍼시스턴트 볼륨을 사용하게 된다.

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

• 각 파드가 별도의 스토리지를 사용하게 하려면? 레플리카셋을 사용할 수 없다.

수동으로 파드 생성하기

• 서로 다른 퍼시스턴트 볼륨 클레임을 가지는 파드를 수동으로 생성
• 레플리카셋을 통해 관리되지 않으므로 수동으로 파드 관리가 필요
• 노드가 죽거나하면 다시 수동으로 파드 만들어야 함
• 현실적으로 어려움

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

• 여러 개의 레플리카셋을 생성 (파드 하나 당 레플리카셋 생성)
• 그러나 파드 스케일링 시에 레플리카 수를 변경하는 대신 레플리카셋을 추가로 생성
• 최선의 방법이 아님

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

• 모든 파드가 동일한 퍼시스턴트 볼륨을 사용하게 하되 각 파드 볼륨 내부에서 별도 디렉터리 사용
• 레플리카셋은 단일 파드 템플릿을 사용하기 때문에 각 인스턴스에 어떤 디렉터리를 사용해야 하는지 전달 불가능
• 각 인스턴스가 생성되는 시점에 다른 인스턴스가 사용하지 않는 디렉터리를 자동으로 선택하거나 새로 생성하도록 할 수 있음
• 인스턴스 간 조정이 필요하고 올바르게 수행하기 쉽지 않음 + 공유 스토리지 볼륨에 병목 현상 발생

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

• 스토리지 뿐만 아니라 특정 클러스터 애플리케이션은 각 인스턴스에서 장시간 지속되는 안정적인 아이덴티티를 필요로 함
• 파드가 교체되면서 스토리지에 저장된 데이터는 이전 파드의 것을 그대로 이어 받는다 해도 새로운 네트워크 아이덴티티로 인해 문제 발생 (호스트 이름과 IP)
• 분산 스테이트풀 애플리케이션에서는 관리자가 다른 모든 클러스터 멤버의 리스트와 호스트 이름, IP 주소를 각 멤버의 설정 파일에 기재해야 함
• 파드가 재스케줄링 되면서 네트워크 아이덴티티가 바뀌게 되고 모든 애플리케이션 클러스터가 재구성되어야 함

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

• 위 문제를 해결하기 위해서는 개별 멤버에게 쿠버네티스 서비스를 생성해 할당하는 것 (파드가 교체되어도 안정적인 네트워크 아이덴티티 제공 가능)
• 그러나 이전에 설명한 개별 스토리지 사용을 위해 여러 개의 레플리카셋 사용하는 방법과 크게 다를 것이 없음
• 심지어 개별 파드는 자신이 어떤 서비스를 통해 노출되는지도 모르기 때문에 그 IP를 사용해 다른 파드에 자신을 등록할 수도 없음

10.2 스테이트풀셋 이해하기

• 이런 유형의 파드를 사용하기 위해선 ReplicaSet 대신 StatefulSet 리소스를 사용함

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

애완동물과 가축 비유로 스테이트풀 파드 이해하기

초기에 스테이트풀셋을 PetSets로 불렀음

• 스테이트리스 애플리케이션은 가축처럼 취급하는 편이 나음
  • 인스턴스가 죽더라도 새로운 인스턴스를 만들 수 있고 사람들은 그 차이를 알아차리지 못함 (병든 가축을 교체하는 것처럼)
• 반면 스테이트풀 애플리케이션은 애완동물과 같음
  • 애완동물이 죽었을 때 새 애완동물을 바로 살 수 없고 바뀌어도 알아차릴 것임

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

• 레플리카셋으로 관리되는 파드는 대부분 스테이트리스로 언제든 교체 가능
• 스테이트풀셋으로 관리되는 파드는 종료되면 새로운 파드는 이전과 동일한 이름, 네트워크 아이덴티티, 상태 그대로 살아나야 함
• 스테이트풀셋도 레플리카셋처럼 의도한 레플리카 수 필드가 있어 쉽게 조절 가능

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

• 스테이트풀셋으로 생성된 파드는 (0부터 시작하는) 서수 인덱스가 할당됨
• 이 인덱스는 파드의 이름과 호스트 이름, 안정적인 스토리지를 붙이는 데 사용됨
• 즉, 파드는 임의의 이름이 아닌 잘 정리된 이름을 가짐

거버닝 서비스 소개

• 스테이트풀 파드는 각각 서로 다르므로 그룹의 특정 파드에서 동작하기를 원하는 경우가 있음
• 이런 이유로 거버닝 헤드리스 서비스를 생성해 각 파드에게 실제 네트워크 아이덴티티 제공해야 함
• 이 서비스를 통해 각 파드는 자체 DNS 엔트리를 가지며 피어 혹은 다른 클라이언트가 호스트 이름을 통해 파드 주소 지정 가능

잃어버린 애완동물 교체하기

• 스테이트풀 파드 인스턴스가 사라지면 스테이트풀셋은 새로운 인스턴스로 교체되도록 함
• 이전 인스턴스와 다른 노드에 스케줄링되더라도 이전과 같은 호스트 이름으로 접근 가능해야 함

스테이트풀셋 스케일링

• 스케일 업의 경우 사용하지 않는 다음 서수 인덱스를 갖는 새로운 파드 인스턴스를 생성함
• 스케일 다운의 경우 항상 가장 높은 서수 인덱스를 먼저 제거함
• 스테이트풀셋은 한 번에 하나의 파드 인스턴스만 스케일 다운, 파드 생성할 때도 하나씩
  • ex) 분산 데이터 스토어에서 여러 개 노드가 동시에 다운되면 데이터 손실 가능

cf. 레플리카셋의 스케일 다운

• 책에는 레플리카셋의 스케일 다운 시 어떤 파드를 제거할지 지정할 수 없다고 되어 있음
• 실제로 레플리카셋의 스케일 다운할 파드의 우선순위는 아래 기준으로 정해짐
  1. Pending 상태인 (+ 스케줄링할 수 없는) 파드가 먼저 스케일 다운된다.
  2. controller.kubernetes.io/pod-deletion-cost 어노테이션이 설정되어 있는 파드에 대해서는, 낮은 값을 갖는 파드가 먼저 스케일 다운된다.
  3. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다.
  4. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가 이전에 생성된 파드보다 먼저 스케일 다운된다. (LogarithmicScaleDown 기능 게이트가 활성화되어 있으면 생성 시간이 정수 로그 스케일로 버킷화된다)
• 여기서 controller.kubernetes.io/pod-deletion-cost 어노테이션은 Kubernetes v1.22 [beta] 기능

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

• 새롭게 교체된 스테이트풀 인스턴스는 이전과 동일한 스토리지에 연결되어야 함

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

• 동일한 파드 템플릿에서 어떻게 서로 다른 퍼시스턴트 볼륨 클레임을 사용?
• 스테이트풀셋은 파드 템플릿 뿐만 아니라 볼륨 클레임 템플릿도 가질 수 있음

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

• 스테이트풀셋 스케일 다운을 할 때 파드만 제거하고 퍼시스턴트 볼륨 클레임은 남겨둠
• 레플리카 수를 줄이는 것처럼 단순하게 클레임이 삭제되면 위험하기 때문에 퍼시스턴트 볼륨 클레임을 수동으로 삭제해야 함
• 퍼시스턴트 볼륨 클레임이 남아 있기 때문에 이후 스케일 업 할 때 동일한 스토리지 사용 가능

10.2.4 스테이트풀셋 보장 이해하기

• 파드가 안정적인 아이덴티티와 스토리지를 갖는 것으로 끝나지 않음
• 스테이트풀 파드 인스턴스가 최대 하나임을 보장해야 함 (at-most-one semantics)

안정된 아이덴티티와 스토리지의 의미

• 스테이트풀 인스턴스가 삭제되었을 때 동일한 인스턴스를 생성해 주는데 만약 쿠버네티스가 파드 상태를 확신할 수 없을 때는?
• 2개의 인스턴스가 동일한 아이덴티티를 가지고 시스템에서 실행될 수 있음
  • 동일한 스토리지에 바인딩되고 동일한 아이덴티티로 같은 파일을 쓰려고 할 것임

10.4 스테이트풀셋의 피어 디스커버리

• 클러스터된 애플리케이션의 중요한 요구 사항은 클러스터의 다른 멤버를 찾는 기능(피어 디스커버리)
• API 서버와 통신해 다른 멤버를 찾을 수 있지만, 애플리케이션이 쿠버네티스에 독립적이어야 하기 때문에 이는 바람직하지 않음 (Kubernetes-agnostic)
• DNS 레코드 중 SRV 레코드를 이용하는 방법이 있음

SRV 레코드 소개

• 특정 서비스를 제공하는 서버의 호스트 이름과 포트를 가리키는데 사용됨
• 쿠버네티스는 거버닝 헤드리스 서비스에 연결된 파드의 호스트 이름을 가리키도록 SRV 레코드 생성
• 파드가 스테이트풀셋의 다른 모든 파드의 목록을 가져오려면 SRV DNS 룩업을 수행하기만 하면 됨 (순서는 랜덤)

10.4.1 DNS를 통한 피어 디스커버리

• 쿠버네티스 노드는 모든 클러스터 노드의 데이터를 응답하기 위해 모든 피어를 찾아야 함

1. 애플리케이션이 요청을 받으면 서버는 먼저 거버닝 헤드리스 서비스의 SRV 레코드 룩업 수행
2. 요청을 서비스에 연결된 각 파드에 전송
3. 각 노드에 저장된 데이터를 합쳐 모든 노드의 리스트를 반환

10.4.2 스테이트풀셋 업데이트

• 이미 실행 중인 스테이트풀셋의 파드 템플릿을 업데이트하면 이미 실행중인 파드의 이미지는 업데이트 되지 않음
• 이는 스테이트풀셋이 레플리카셋과 유사하고 디플로이먼트와는 비슷하지 않기 때문

💡 쿠버네티스 버전 1.7부터 스테이트풀셋도 디플로이먼트나 데몬셋과 같은 방식으로 롤링 업데이트 지원

$ kubectl rollout status statefulset kubia
Waiting for 1 pods to be ready...
Waiting for partitioned roll out to finish: 2 out of 3 new pods have been updated...
Waiting for 1 pods to be ready...
partitioned roll out complete: 3 new pods have been updated...

10.5 스테이트풀셋이 노드 실패를 처리하는 과정 이해하기

• 10.2.4절에서 쿠버네티스는 새로운 대체 파드를 생성하기 전 스테이트풀 파드가 완전히 죽은 것을 확신해야 한다고 말했음
• 노드가 갑자기 죽으면 쿠버네티스는 그 안의 파드 상태를 알 수 없음 (파드가 죽은 건지, kubelet이 보고를 중지한 건지)
• 오직 클러스터 관리자가 알려줘야만 알 수 있음. 이를 위해 관리자는 파드를 삭제하거나 전체 노드 삭제해야 함

10.5.1 노드의 네트워크 연결 해제 시뮬레이션

• 노드의 네트워크를 의도적으로 셧다운하면 컨트롤 플레인은 노드를 NotReady로 표시
• 노드에 있는 모든 파드의 상태는 Unknown이 됨

UNKNOWN 상태인 파드에 무슨 일이 일어나는지 이해하기

• 노드가 다시 온라인 상태로 돌아오면 파드는 다시 Running으로 표시됨
• 하지만 일정 시간(이 시간은 설정 가능)이 지나도 파드의 상태가 Unknown으로 남아 있다면 파드는 자동으로 제거됨
• 이는 마스터에서 수행되며 파드 리소스를 삭제해 파드 제거함.
• kubelet이 파드가 deletion으로 표시된 것을 확인하면 파드 종료 시작
• 그러나 kubelet이 더 이상 마스터에 연결할 수 없으면 파드는 계속 실행 중임을 의미

10.5.2 수동으로 파드 삭제하기

• 리스케줄링을 위해서는 파드를 수동으로 삭제해야 함
• kubectl delete pod 명령을 수행해도 네트워크가 유실되었기 때문에 전달되지 않음
• kubectl delete pod <NAME> --force --grace-period 0 명령으로 강제 삭제해야 함 (이 명령은 노드가 죽은게 확실한 경우에만 실행해야 함)