PV и PVC в Kubernetes: практическое руководство по настройке хранилища в 2026

Работа с данными в Kubernetes требует четкого понимания двух ключевых объектов: PersistentVolume (PV) и PersistentVolumeClaim (PVC). PV представляет физический или логический ресурс хранения в кластере, например, диск или сетевую папку. PVC - это запрос приложения на использование этого ресурса. Разделение позволяет администраторам управлять инфраструктурой независимо от разработчиков. Разработчики просто описывают свои требования к хранилищу в PVC, а система автоматически связывает их с подходящим PV.

Эта архитектура устраняет хаос при масштабировании и обеспечивает безопасность данных. В этой статье мы разберем создание PV и PVC для локальных дисков, NFS и облачных томов, настроим автоматическое выделение через StorageClass и выберем правильную политику очистки для защиты информации.

Зачем в Kubernetes нужны PV и PVC: разделение ответственности

Прямое монтирование диска в Pod приводит к проблемам при масштабировании и управлении. Разделение PV и PVC создает четкую границу между инфраструктурой и приложением.

PersistentVolume (PV): как кластер видит ресурсы хранения

PersistentVolume - это объект уровня кластера, описывающий доступное хранилище. Его манифест содержит ключевые параметры:

capacity: объем тома, например, 10Gi.
accessModes: определяет, как Pod могут использовать этот объем. Основные режимы: ReadWriteOnce (один Pod для чтения и записи), ReadOnlyMany (многие Pod только для чтения), ReadWriteMany (многие Pod для чтения и записи).
persistentVolumeReclaimPolicy: определяет действие после удаления PVC (Retain, Delete, Recycle).
storageClassName: имя класса хранилища для группировки PV.
спецификация тома: определяет тип и параметры физического хранилища (hostPath, nfs, awsElasticBlockStore, csi).

PV - это абстракция физического диска в дата-центре или облачном провайдере.

PersistentVolumeClaim (PVC): как приложение запрашивает данные

PersistentVolumeClaim создается в namespace и представляет запрос на ресурсы от приложения. Основные параметры PVC:

resources.requests.storage: требуемый объем, например, 5Gi.
accessModes: режимы доступа, которые должны поддерживаться PV.
storageClassName: имя класса хранилища для автоматического поиска PV.
selector: для явной привязки к конкретному PV по его меткам.

После создания PVC контроллер Kubernetes находит подходящий PV и связывает их (binding). PVC - это заявка от разработчика на использование ресурса, которую инфраструктура обязана удовлетворить.

Практика: создаем PV и PVC для разных типов хранилищ

Примеры манифестов ниже проверены на актуальных версиях Kubernetes в 2026 году. Адаптируйте пути, адреса и параметры под свою инфраструктуру.

Локальное хранилище (hostPath): для тестов и одноузловых кластеров

Тип hostPath монтирует директорию с узла кластера в Pod. Используйте его только для тестовых или одноузловых сред, например, в Minikube или kind.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  hostPath:
    path: /mnt/data
    type: DirectoryOrCreate

Этот PV описывает локальную директорию /mnt/data на узле кластера. Политика очистки Retain сохранит данные после удаления PVC. Для использования этого тома создайте PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-local-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: local-storage

Примените манифесты командой kubectl apply -f. Данные привязываются к конкретному узлу. Если Pod запустится на другом узле, он не сможет получить доступ к этому PV. Этот подход не подходит для production из-за рисков безопасности и отсутствия отказоустойчивости.

Сетевая файловая система (NFS): общее хранилище для нескольких Pod

NFS позволяет нескольким Pod одновременно читать и записывать данные. Это решение для приложений, требующих режим ReadWriteMany, например, файловых хранилищ.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-shared-pv
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-storage
  nfs:
    server: 192.168.1.100
    path: /exports/shared

Манифест указывает на сервер NFS 192.168.1.100 и экспортированную папку /exports/shared. Сервер NFS должен быть предварительно настроен и доступен из кластера. Соответствующий PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-shared-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: nfs-storage

Частая проблема - конфликты прав доступа (uid/gid). Убедитесь, что пользователь внутри контейнера имеет права на чтение и запись в NFS папке. Это можно настроить через параметры безопасности Pod или настроить сервер NFS для соответствующего пользователя.

Облачные тома (на примере Yandex Cloud): продакшен-решение

Облачные провайдеры предлагают управляемые диски через CSI драйверы. Пример PV для предварительно созданного диска в Yandex Cloud:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: yc-manual-pv
spec:
  capacity:
    storage: 30Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: yc-standard
  csi:
    driver: disk.yandex.cloud
    volumeHandle: yc-disk-id-12345
    fsType: ext4

Поле volumeHandle содержит идентификатор диска в облаке. Политика Retain критически важна для production данных: при удалении PVC облачный диск сохранится, предотвращая случайную потере информации. Для динамического создания дисков при каждом PVC используйте StorageClass, как описано в следующем разделе.

Динамическое выделение хранилища (Dynamic Provisioning) через StorageClass

StorageClass описывает тип хранилища и механизм его создания. При создании PVC с указанием storageClassName Kubernetes автоматически создает соответствующий PV через provisioner.

Как работает StorageClass: от запроса до готового тома

Процесс динамического выделения:

Пользователь создает PVC с параметром storageClassName: "fast-ssd".
Контроллер PersistentVolume в кластере находит StorageClass с этим именем.
StorageClass вызывает указанный в provisioner драйвер, например, disk.yandex.cloud.
Драйвер через API облачного провайдера создает физический диск и регистрирует новый PV в Kubernetes.
PVC автоматически связывается с созданным PV.

Это стандартный подход в облачных средах и при использовании CSI драйверов.

Примеры конфигурации StorageClass для разных сред

StorageClass для локального хранилища с использованием local volume provisioner:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

Параметр volumeBindingMode: WaitForFirstConsumer гарантирует, что PV будет создан на узле, где запущен первый Pod, использующий этот PVC. Это важно для локальных хранилищ.

StorageClass для NFS с использованием внешнего provisioner (например, nfs-client):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  server: 192.168.1.100
  path: /exports
  onDelete: "retain"

Provisioner создает отдельные поддиректории в указанном path для каждого PVC.

StorageClass для Yandex Cloud:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: yc-standard
provisioner: disk.yandex.cloud
parameters:
  type: "network-hdd"
  zones: "ru-central1-a"
reclaimPolicy: Retain
allowVolumeExpansion: true

Параметр type определяет тип диска (HDD или SSD), zones - зону размещения. reclaimPolicy: Retain на уровне StorageClass устанавливает политику очистки для всех автоматически созданных PV. allowVolumeExpansion: true позволяет увеличивать размер тома после создания.

Динамическое выделение через StorageClass - основной метод управления хранилищем в production кластерах. Он автоматизирует рутинные операции и снижает нагрузку на администраторов. Для сравнения подходов к управлению данными в разных оркестраторах, ознакомьтесь с практическим руководством по управлению постоянными данными в кластерах Docker Swarm и Kubernetes.

Политика очистки (reclaimPolicy): как не потерять данные при удалении PVC

Политика очистки определяет действие с PV после удаления связанного PVC. Выбор политики зависит от ценности данных и среды эксплуатации.

Retain: для критичных данных и ручного управления

Политика Retain сохраняет PV и его данные после удаления PVC. Статус PV меняется на Released. Используйте эту политику для production данных, которые нельзя потерять, например, для баз данных.

Чтобы использовать сохраненный том заново:

Вручную очистите данные на физическом диске или в облачном ресурсе.
Удалите объект PV в Kubernetes командой kubectl delete pv <name>.
Создайте новый PV манифестом, указывающим тот же физический ресурс (например, тот же volumeHandle для облачного диска).

Этот процесс требует вмешательства администратора, но гарантирует сохранность данных.

Delete: для временных данных и полной автоматизации

Политика Delete приводит к физическому удалению ресурса хранения при удалении PVC. В облачных средах это удаляет диск; для локальных хранилищ может очищать директорию.

Применяйте Delete для тестовых сред, кэшей, временных логов или данных, которые легко воссоздать. Убедитесь, что у вас есть резервные копии критичной информации вне этого тома. Использование этой политики в production без дополнительных мер защиты приведет к необратимой потере данных.

Recycle: почему эта политика устарела и что использовать вместо нее

Политика Recycle выполняла базовую очистку тома (например, rm -rf /volume/*) и делала его доступным для нового PVC. Она небезопасна, не поддерживается большинством современных provisioner, особенно CSI, и удалена из актуальных версий Kubernetes.

Если вы встретите эту политику в старых руководствах, игнорируйте ее. Альтернативы:

Для безопасного повторного использования тома: политика Retain с последующей ручной очисткой и пересозданием PV.
Для полностью новых томов при каждом запросе: динамическое выделение с политикой Delete.

Выбор reclaimPolicy - одна из ключевых точек принятия решения при проектировании storage инфраструктуры. Для комплексного управления ресурсами кластера, включая ограничение количества PVC, изучайте объекты ResourceQuota и LimitRange.

Итоги и рекомендации: осознанный выбор для вашего приложения

Выбор типа хранилища и политики очистки зависит от типа приложения и среды.

Тип приложения / Среда	Тип хранилища	Рекомендуемая политика очистки
База данных в production (облако)	Облачный диск через StorageClass (CSI)	Retain
Кэш Redis в staging (локальный кластер)	hostPath или local volume	Delete
Файловое хранилище веб-приложения (on-premise)	NFS	Retain
StatefulSet с уникальными данными	Любой тип с гарантией сохранности	Retain
Логи приложения (если агрегируются отдельно)	Любой тип	Delete

Ключевой принцип: данные, которые нельзя воссоздать из кода или конфигурации, защищайте политикой Retain. Для автоматизации и снижения операционных затрат используйте динамическое выделение через StorageClass.

Архитектура PV и PVC в Kubernetes обеспечивает гибкость и безопасность работы с данными. Понимание этих объектов позволяет строить надежные stateful-приложения. Для автоматизации развертывания таких приложений рассмотрите использование инструментов Infrastructure as Code, сравнение которых представлено в практическом руководстве по IaC для Kubernetes.

Для управления версиями приложений и обеспечения стандартов в кластере полезно ознакомиться с стратегиями хранения версий в метках или в имени пода и готовыми политиками для корпоративных стандартов Kubernetes.

Инструменты для управления конфигурациями и интеграции с внешними сервисами могут упростить работу. Например, агрегатор API AiTunnel предоставляет единый интерфейс для более 200 моделей нейросетей, включая GPT, Gemini и Claude, что может быть полезно для автоматизации задач анализа логов или генерации конфигураций.