스토리지 용량
스토리지 용량 (Storage Capacity)
스토리지 용량은 제한적이며 Pod가 실행되는 노드에 따라 달라질 수 있어요: 네트워크 연결 스토리지는 모든 노드가 접근하지 못할 수도 있고, 스토리지가 처음부터 노드에 로컬일 수도 있어요.
FEATURE STATE: Kubernetes v1.24 [stable]
이 페이지는 Kubernetes가 스토리지 용량을 어떻게 추적하고, 스케줄러가 그 정보를 이용해 남은 누락 볼륨을 위한 충분한 스토리지 용량에 접근할 수 있는 노드로 Pod를 스케줄링하는지 설명해요. 스토리지 용량 추적이 없으면 스케줄러는 볼륨을 프로비저닝할 충분한 용량이 없는 노드를 선택할 수 있고, 여러 번의 스케줄링 재시도가 필요할 수 있어요.
시작하기 전에
Kubernetes v1.36은 스토리지 용량 추적을 위한 클러스터 수준 API 지원을 포함해요. 이를 사용하려면 용량 추적을 지원하는 CSI 드라이버도 사용해야 해요.
API
이 기능에는 두 개의 API 확장이 있어요.
- CSIStorageCapacity 객체: CSI 드라이버가 설치된 네임스페이스에서 드라이버가 생성해요. 각 객체는 한 storage class의 용량 정보를 포함하고 어떤 노드가 그 스토리지에 접근할 수 있는지 정의해요.
- CSIDriverSpec.StorageCapacity 필드:
true로 설정하면 Kubernetes 스케줄러가 CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려해요.
스케줄링
스토리지 용량 정보는 다음 조건에서 Kubernetes 스케줄러가 사용해요.
- Pod가 아직 생성되지 않은 볼륨을 사용하고,
- 그 볼륨이 CSI 드라이버를 참조하는 StorageClass를 사용하고
WaitForFirstConsumer볼륨 바인딩 모드를 사용하며, - 드라이버의
CSIDriver객체가StorageCapacity를 true로 설정한 경우.
그 경우 스케줄러는 충분한 스토리지가 있는 노드만 Pod 후보로 고려해요. 이 검사는 매우 단순해서 노드를 포함하는 토폴로지의 CSIStorageCapacity 객체에 나열된 용량과 볼륨 크기만 비교해요.
Immediate 볼륨 바인딩 모드의 볼륨은 스토리지 드라이버가 볼륨을 사용할 Pod와 무관하게 생성 위치를 결정해요. 그러면 스케줄러는 볼륨이 생성된 후 볼륨을 사용할 수 있는 노드에 Pod를 스케줄링해요.
CSI ephemeral 볼륨의 경우 스케줄링은 항상 스토리지 용량을 고려하지 않고 수행돼요.
재스케줄링 (Rescheduling)
WaitForFirstConsumer 볼륨이 있는 Pod에 노드가 선택되면 그 결정은 여전히 잠정적이에요. 다음 단계로 CSI 스토리지 드라이버가 선택된 노드에서 볼륨을 사용할 수 있어야 한다는 힌트와 함께 볼륨 생성을 요청받아요.
Kubernetes가 오래된 용량 정보에 기반해 노드를 선택했을 수 있으므로, 볼륨을 실제로 생성하지 못할 가능성이 있어요. 그러면 노드 선택이 리셋되고 스케줄러가 Pod를 위한 노드를 다시 찾으려고 해요.
한계
스토리지 용량 추적은 첫 시도에서 스케줄링이 성공할 확률을 높이지만 보장하지는 못해요. 스케줄러는 잠재적으로 오래된 정보에 기반해 결정해야 하기 때문이에요.
영구적으로 스케줄링이 실패할 수 있는 한 상황은 Pod가 여러 볼륨을 사용할 때예요. 하나의 볼륨이 이미 어떤 토폴로지 세그먼트에 생성됐는데 그 세그먼트에 다른 볼륨을 위한 충분한 용량이 남지 않은 경우예요. 용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등 수동 개입이 필요해요.