앞서 살펴본 동적 프로비저닝은 직접 PV를 생성하지 않고 자동 생성하기에 어떻게 프로비저닝을 할 것인지에 대한 정의가 별도로 필요하다
이것이 정의되어 있는 것이 바로 Storage Class 이다
스토리지 유형?
스토리지 유형으로는 여러가지가 존재하며, 현재 플랫폼에서 지원하는 스토리지만 사용할 수 있다
(AKS - 애저 파일스, 애저 디스크, EKS - EBS, 온프레미스 - NFS, 로컬 - local 등)
클레임 생성 시 스토리지 유형이 지정되지 않거나 일치하는 것이 없다면, 기본 스토리지를 사용하는 볼륨에서 할당한다
(따라서 기본 스토리지 클래스를 지정해줘야 한다)
구성 요소
스토리지 클래스를 작성하는 데에는 여러가지 요소가 있는데, 그 부분에 대해서 자세히 알아보자
프로비저너
PV를 프로비저닝할 때 사용되는 볼륨 플러그인을 설정하는 필드이다. 다음을 참고하자(https://kubernetes.io/ko/docs/concepts/storage/storage-classes/#%ED%94%84%EB%A1%9C%EB%B9%84%EC%A0%80%EB%84%88)
파라미터
파일 시스템 타입 등 볼륨의 정보에 대해 설정하는 값들이다
Key-Value 쌍으로 설정되며, 사용하는 프로비저너에 따라 다르다. 역시 다음을 참고하면 된다
(https://kubernetes.io/ko/docs/concepts/storage/storage-classes/#%ED%8C%8C%EB%9D%BC%EB%AF%B8%ED%84%B0)
리클레임 정책
-
Delete(기본)
클레임이 삭제될 때 볼륨도 삭제 -
Retain
클레임이 삭제되더라도 볼륨은 그대로
볼륨 확장 허용
PVC의 할당량에 따라 PV를 확장할지 여부를 결정한다
-
False(기본)
확장 불가. PVC가 PV 용량을 넘을 수 없다. PV는 고정 -
True
확장 가능. PVC가 PV 용량을 넘기면 PV는 확장된다
볼륨 바인딩 모드
-
Immediate(기본)
PVC가 생성되자마자 PV가 프로비저닝되고 PVC와 바인딩이 이뤄진다
만약 파드에 별도의 스케줄링이 있다면, 이를 무시하고 즉시 PV가 생성될 수 있기에 다른 모드를 사용해야 한다 -
WaitForFirstConsumer
파드의 스케줄링 등을 고려하여 프로비저닝과 바인딩을 뒤로 미루는 옵션이다
