Kubernetes PV/PVC: StorageClass и online resize томов без простоя

Зачем вообще разбираться в PV/PVC и «онлайн-расширении»

В Kubernetes хранение почти всегда упирается в один из двух сценариев: диска стало мало или нагрузка изменилась так, что нужно быстро увеличить объём без миграций и простоев. Для этого есть поддержка расширения томов (online resize) через связку PV/PVC/StorageClass и CSI-драйвер.

Важно понимать: «kubernetes pvc resize» — это не одна операция, а цепочка. Сначала контроллер расширяет блочное устройство на стороне хранилища (expand volume), затем узел приводит в порядок файловую систему (filesystem resize), и только после этого Pod реально видит новые гигабайты.

Ниже — прикладная инструкция: какие условия должны совпасть, как выглядит корректный StorageClass с allowVolumeExpansion, где смотреть статус и события, и как отличить проблему на стороне CSI-контроллера от проблемы на ноде.

Короткая модель: PV, PVC, StorageClass, CSI — кто за что отвечает

PVC (PersistentVolumeClaim) — запрос на диск: «дай мне 20Gi, такой-то класс, такой-то режим доступа». PV (PersistentVolume) — конкретный том, который этот запрос удовлетворяет.

StorageClass описывает «как именно» будет создан PV: какой CSI-драйвер, какие параметры, политика удаления, и главное для нашей темы — разрешено ли расширение.

CSI (Container Storage Interface) — стандартный интерфейс, через который Kubernetes общается с хранилищем. Именно конкретная CSI-реализация определяет, поддерживается ли resize, можно ли делать его онлайн и будет ли выполняться расширение ФС на ноде.

Если у вас небольшой кластер в инфраструктуре провайдера, удобно держать stateful-нагрузки на VDS: проще контролировать диски, снапшоты и поведение CSI (или локального storage), а расширение томов становится частью стандартной эксплуатации.

Предпосылки: когда PVC вообще можно расширять

Расширение PVC возможно не всегда. Перед изменениями проверьте базовые условия:

• Разрешение на уровне StorageClass. В StorageClass должно быть allowVolumeExpansion: true.
• Поддержка в CSI. Драйвер обязан поддерживать ControllerExpandVolume и (для расширения на ноде) NodeExpandVolume.
• Тип бэкенда. Само хранилище/тип диска должен допускать увеличение (есть решения, где это ограничено квотами или моделью выделения места).
• Только увеличение. Уменьшение размера PVC «штатно» не поддерживается.

Эксплуатационное правило: сначала убедитесь, что ваш CSI умеет расширение и на контроллере, и на ноде. Иначе вы легко получите увеличившийся PV «на бумаге» и старый размер внутри контейнера.

Online resize и «нужно ли перезапускать Pod»

В идеальном сценарии расширение происходит без перезапуска: устройство увеличилось, kubelet выполнил filesystem resize, приложение увидело дополнительное место.

Но встречаются варианты, когда файловая система расширяется только при следующем монтировании тома. Тогда потребуется пересоздать Pod (например, удалить конкретный Pod в StatefulSet или сделать rolling restart Deployment).

Отдельный случай — volumeMode: Block: Kubernetes расширит блочное устройство, но файловую систему расширять не будет (её может не существовать по определению).

StorageClass с allowVolumeExpansion: что должно быть в манифесте

Ключевой переключатель — allowVolumeExpansion. Без него вы не сможете увеличить spec.resources.requests.storage у PVC: API либо отклонит изменение, либо операция «не поедет» на стороне контроллера.

Пример минимального StorageClass для CSI-драйвера (параметры зависят от провайдера, ниже шаблон):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-standard
provisioner: example.csi.driver
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: ssd

volumeBindingMode: WaitForFirstConsumer полезен, когда важна топология (зоны, привязка к нодам): PV создастся уже с учётом того, где реально будет запущен Pod.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Пошагово: resize PVC в Kubernetes (expand volume + filesystem resize)

1) Посмотрите текущий размер и состояние PVC

kubectl get pvc -n app
kubectl describe pvc -n app data-myapp-0

В kubectl describe смотрите:

• StorageClass — тот ли класс используется.
• Capacity и Requests — что было и что стало.
• Events — подсказки, на каком шаге всё застряло.

2) Увеличьте запрос в PVC

Расширение делается изменением spec.resources.requests.storage. Например, с 20Gi до 50Gi:

kubectl patch pvc -n app data-myapp-0 -p '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'

Альтернатива — отредактировать объект и сохранить:

kubectl edit pvc -n app data-myapp-0

После изменения Kubernetes инициирует расширение тома на стороне CSI controller (этап expand volume).

3) Наблюдайте статус и события (почему бывает «не сразу»)

С точки зрения пользователя важно понимать разницу между «запрос увеличили» и «внутри Pod появилось место». Между ними есть этап расширения на ноде.

Проверяйте:

kubectl get pvc -n app data-myapp-0 -o wide
kubectl describe pvc -n app data-myapp-0

Если PV уже расширился, а внутри Pod место не появилось — значит filesystem resize ещё не выполнен на ноде (или не может быть выполнен автоматически).

4) Убедитесь, что PV действительно увеличился

kubectl get pv
kubectl describe pv pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

На уровне PV вы должны увидеть новую Capacity. Если PV не меняется — проблема на «контроллерной» части: CSI не расширяет том в бэкенде, или операция запрещена квотами/типом диска.

5) Проверьте размер внутри контейнера

Если том смонтирован как файловая система, используйте df:

kubectl exec -n app deploy/myapp -- df -hT

Если это блочное устройство (volumeMode: Block), проверяйте lsblk:

kubectl exec -n app deploy/myapp -- lsblk

Что происходит под капотом: где именно делается filesystem resize

Обычно цепочка такая:

• CSI Controller расширяет диск в системе хранения.
• kubelet на ноде инициирует NodeExpandVolume.
• Далее kubelet (или CSI node-plugin) расширяет файловую систему (ext4/XFS).

Если вам нужно понять, чем в принципе отличается поведение файловых систем на Linux, полезно держать под рукой материал про выбор и тюнинг: ext4 vs XFS для серверных нагрузок.

Как понять, кто виноват: контроллер или нода

Для диагностики удобно делить проблемы на два класса:

• Не сработал expand volume. PV не увеличился; события намекают на ошибки CSI controller, квоты, ограничения API бэкенда.
• Не сработал filesystem resize. PV увеличился, но внутри Pod размер прежний; события/логи намекают на NodeExpandVolume, ошибки утилит ФС или особенности монтирования.

Практические нюансы: ext4, XFS, block volumes и режимы доступа

ext4

Обычно расширяется утилитой resize2fs. В большинстве сценариев ext4 поддерживает онлайн-расширение смонтированной файловой системы.

Для понимания, что происходит на ноде, полезно знать, какие команды обычно вызываются:

resize2fs /dev/DEVICE

Вручную запускать это на ноде в production обычно не стоит: лучше выяснить, почему kubelet/CSI не сделали это автоматически (и не усугубить ситуацию несогласованными действиями).

XFS

Для XFS используется xfs_growfs, и расширение выполняется по точке монтирования:

xfs_growfs /mount/point

XFS нельзя сжать, но расширять онлайн, как правило, можно.

volumeMode: Block

Если PVC создан с volumeMode: Block, Kubernetes увеличит блочное устройство, но не выполнит filesystem resize. Дальше всё зависит от того, что вы строите поверх блока (своя разметка, LVM, встроенные механизмы приложения) — и это нужно заранее закладывать в архитектуру.

ReadWriteOnce и ReadWriteMany

Сетевые RWX-тома (NFS-подобные решения) часто имеют отдельные правила расширения: иногда расширяется не PVC, а экспорт/квота на стороне сервера; иногда resize «на лету» не поддерживается конкретной реализацией. Если вы выбираете сетевое хранилище для RWX, пригодится сравнение подходов: NFS vs SSHFS как хранилище.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Типовые проблемы и быстрый чек-лист диагностики

1) StorageClass без allowVolumeExpansion

Симптом: попытка увеличить PVC отклоняется или изменение не применяется.

Проверьте:

kubectl get storageclass
kubectl describe storageclass csi-standard

Если allowVolumeExpansion выключен, его можно включить правкой StorageClass, но делайте это осознанно: это кластерная политика, и лучше понимать, какие команды и автоматизации у вас завязаны на storage.

2) PV увеличился, а внутри Pod места нет

Симптом: kubectl describe pv показывает новый размер, а df в контейнере — старый.

Что сделать по порядку:

• Посмотреть события на PVC и Pod: часто там есть причина вроде «ожидается filesystem resize».
• Проверить, поддерживает ли CSI NodeExpandVolume (и запущен ли node-plugin на нужной ноде).
• Выполнить безопасное пересоздание Pod, чтобы том перемонтировался (если ваш драйвер расширяет ФС только при mount).

3) PVC «завис» в промежуточном состоянии

Симптом: размер в spec обновился, но status.capacity не меняется долго.

Проверьте по цепочке:

• События PVC и PV.
• Логи CSI controller и CSI node-plugin (обычно Deployment и DaemonSet в namespace драйвера).
• Ограничения бэкенда: максимальный размер, квоты проекта, недоступность операции resize, конфликты со снапшотами/клонами (зависит от хранилища).

4) Ошибки утилит файловой системы

Иногда kubelet доходит до этапа расширения ФС, но натыкается на ошибки: повреждённая ФС, нужен fsck, неожиданный тип разметки, нестандартные сценарии монтирования.

Если есть подозрение на проблемы целостности, сначала обеспечьте сохранность данных (бэкап/снапшот), а уже потом переходите к «лечению». Ручные операции на нодах делайте только с планом отката.

Рекомендуемый «боевой» процесс расширения PVC

1. Проверить, что PVC создан из StorageClass с allowVolumeExpansion.
2. Понять режим: файловая система или volumeMode: Block.
3. Увеличить spec.resources.requests.storage у PVC.
4. Дождаться, что PV и status.capacity у PVC обновились.
5. Проверить размер внутри контейнера (df или lsblk).
6. Если ФС не расширилась — изучить события и логи CSI; при необходимости пересоздать Pod для перемонтирования.

Итоги

Корректный online resize в Kubernetes держится на трёх вещах: разрешение на уровне StorageClass (allowVolumeExpansion), поддержка операции в CSI-драйвере и успешный этап filesystem resize на ноде. Если мыслить цепочкой «контроллер расширил диск → kubelet расширил ФС → Pod увидел новое место», диагностика становится предсказуемой и быстрой.

Если нужно, в следующем материале можно разобрать более «боевые» кейсы: расширение StatefulSet без сюрпризов, особенности RWX, и как читать логи CSI controller/node-plugin, когда PVC «застревает».