볼륨과 스테이트 풀셋
파드는 Stateless합니다
앞서 언급했던 것처럼 파드는 일시적이며 언제나 삭제될 수 있음을 감안해야 한다.
따라서, 파드 그 자체는 Stateless하다.
이러한 파드의 교체와 배치를 담당하는 것이 디플로이먼트다.
디플로이먼트는 레플리카셋을 통해 파드를 scale out하며, 이 때 만들어지는 파드들은 상호 대체 가능하다.
파드가 사라져도 데이터를 남기고 싶다면
파드 그 자체에 상태(데이터)를 남겨야만 하는 Stateful 애플리케이션으로는 MySQL, mongoDB, redis와 같은 데이터베이스가 있을 수 있다.
데이터베이스 애플리케이션이 담긴 파드가 사라질 때, 데이터가 함께 사라지도록 두어서는 안될 것이다.
그래서 쿠버네티스에도 영속적인(Persistance) 데이터(프로그램의 실행이 종료되어도 사라지지 않는 데이터)를 저장하기 위해 볼륨(Volume)을 연결할 수 있다.
파드에 볼륨을 연결하면 데이터를 영속적으로 저장하는 것이 가능하다.
여타 클라우드 서비스에서 볼륨을 따로 분리해 놓는 것과 마찬가지이다.
Q. 볼륨과 퍼시스턴스 볼륨(Persistence Volume)은 어떤 차이가 있나요?
AWS EC2에도 비슷한 개념이 있습니다.
EBS와 인스턴스 스토어 볼륨의 차이점과 연결해서 설명해주세요.
Stateful한 애플리케이션을 관리하려면
그런데 파드 명세에 PV를 정의해서 직접 연결하는 것은 좋은 방법이 아니다.
Q. 왜 파드와 PV를 직접 연결하는 것이 좋지 않은가요?
이 때 이러한 의존도를 줄이기 위해 퍼시스턴스 볼륨 클레임(Persistence Volume Claim, 이하 PVC)을 이용하여 PV와 연결한다.
PVC는 파드가 볼륨의 세부 사항을 몰라도 볼륨을 사용할 수 있게 도와준다.
- PV는 실제로 데이터가 저장되는 공간이다.
- PVC는 PV를 선택, 연결해주는 요청 그 자체이다.
Q. PVC는 어떻게 작동되나요?
Stateful한 애플리케이션이 수평 확장한다면
앞서 설명했다시피 파드를 정의할 때, PVC를 통해 볼륨에 연결할 수 있다.
그런데 그냥 이러한 파드를 디플로이먼트로 배포해도 PVC를 통해 연결되는 볼륨은 하나이기 때문에 결국 같은 스토리지를 사용하는 모양새가 된다.
파드마다 별도의 데이터를 저장할 수 있게 만드려면 수평 확장되는 파드에 서로 다른 PV가 연결되어야 한다.
파드가 PV를 동적으로 요청해서 그때마다 볼륨이 생성되게 하면 어떨까?
스토리지 클래스(StorageClass) 리소스는 사용자가 요청할 때, 자동으로 PV를 프로비저닝할 수 있게 돕는다.
스테이트풀셋
스테이트풀셋은 애플리케이션 구성(파드)을 복제하더라도 스토리지 클래스를 이용해 파드가 필요로 하는 볼륨을 자동으로 프로비저닝하여 연결한다.
따라서 첫번째 파드를 primary(master), 두번째 파드를 secondary 복제본처럼 구성하는 것도 가능하다.
디플로이먼트와 스테이트풀셋 둘 다 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다는 점에는 같지만 가장 결정적인 차이점은 다음과 같다.
바로 스테이트풀셋은 파드의 순서와 고유성을 보장한다.
이는 가축과 애완 동물의 비유를 떠올리면 좋다.
스테이트풀셋이 생성한 파드는 상호 대체할 수 없는 파드다.
스테이트풀셋을 사용할 때의 주의사항
- 파드에 지정된 스토리지는 관리자에 의해 퍼시스턴트 볼륨 프로비저너를 기반으로 하는 storage class를 요청해서 프로비저닝하거나 사전에 프로비저닝 되어야 한다.
- 헤드리스 서비스가 필요하다.
Q. 네트워크 트래픽에 따라 요청이 랜덤하게 분산되는 일반적인 서비스에 비해 헤드리스 서비스는 특정 스테이트풀셋에게 트래픽을 보냅니다.
왜 그렇게 해야 하나요?
