PVC приложения завис в статусе Pending — как системно найти причину, связанную со StorageClass?

Короткий ответ

Чаще всего причина — несуществующий или неверно указанный storageClassName, отсутствие provisioner'а для динамического создания томов в этом классе, недоступность запрошенного объёма/режима доступа у облачного хранилища, либо WaitForFirstConsumer binding mode, при котором PVC намеренно остаётся Pending до тех пор, пока соответствующий Pod не будет запланирован на конкретный узел/зону.

Как это работает подробнее

при создании PVC контроллер admission и provisioning смотрит на storageClassName; если такого StorageClass не существует в кластере, PVC останется Pending без автоматического создания PV. Если класс существует, но использует volumeBindingMode: WaitForFirstConsumer (распространено для облачных дисков, привязанных к зоне), PVC нормально остаётся в Pending до момента, когда планировщик определит зону для использующего его Pod — это не ошибка, а штатное поведение, которое легко спутать с проблемой.

Пример кода

Команды и выводКопировать

kubectl describe pvc data-claim
Events:
  Warning  ProvisioningFailed  1m  Failed to provision volume: rpc error: storage quota exceeded

Что использовать на практике

• Практика. диагностику начинают с kubectl describe pvc, где в Events обычно прямо указана причина — "waiting for first consumer", "no persistent volumes available", или ошибка provisioner'а (например, недостаточно квоты в облаке на создание диска). Проверка kubectl get storageclass подтверждает, что указанный класс вообще существует и какой у него provisioner и volumeBindingMode.

Подводные камни

• Риски. сразу считать зависший PVC багом хранилища, не проверив банальную опечатку в имени storageClassName; не знать про WaitForFirstConsumer и пытаться "чинить" PVC, который на самом деле корректно ждёт привязки к Pod — реальная проблема в этом случае может быть не в PVC, а в том, что сам Pod не может быть запланирован.