PersistentVolumeClaim¶

PersistentVolumeClaim (PVC) — это объект в системе оркестрации контейнеров Kubernetes, который используется для запроса ресурсов хранения данных (persistent storage) со стороны подов (pod). PVC представляет собой абстракцию, позволяющую разработчикам и администраторам разделить управление инфраструктурой хранения (предоставляемой администраторами) и её потреблением (приложениями). PVC запрашивает определённый объём, режим доступа и класс хранения, а Kubernetes автоматически связывает его с подходящим PersistentVolume (PV) — заранее подготовленным или динамически создаваемым томом. PVC является ключевым элементом для обеспечения сохранности данных при перезапуске, миграции или масштабировании контейнерных приложений.

¶История и контекст появления

Kubernetes, изначально разработанный компанией Google и открытый в 2014 году, быстро стал стандартом для развёртывания контейнерных приложений. В ранних версиях (до 1.0) управление хранилищем было жёстко привязано к конкретным подам: тома (volumes) определялись непосредственно в спецификации пода, что создавало проблемы при переносе приложений между кластерами или облачными провайдерами. Для решения этой проблемы в Kubernetes 1.0 (выпущен в июле 2015 года) были введены абстракции PersistentVolume и PersistentVolumeClaim. Идея заключалась в том, чтобы отделить «предложение» хранилища (PV) от «спроса» (PVC), аналогично тому, как в виртуализации отделяются виртуальные машины от физических ресурсов.

С тех пор PVC стал стандартным механизмом для работы с постоянными данными в Kubernetes. В версии 1.6 (2017 год) была добавлена поддержка динамического выделения хранилища (Dynamic Provisioning) через StorageClass, что позволило автоматически создавать PV при появлении PVC. В версии 1.9 (2017 год) появилась возможность изменять размер PVC (volume expansion), а в версии 1.13 (2018 год) — поддержка локальных томов (local persistent volumes). На 2025 год PVC является обязательным компонентом для большинства stateful-приложений (базы данных, очереди сообщений, файловые хранилища) в Kubernetes.

¶Архитектура и взаимодействие с PersistentVolume

PVC работает в паре с PersistentVolume (PV). PV — это ресурс кластера, представляющий собой реальный том хранения (например, раздел на NFS-сервере, диск в облаке AWS EBS, GCE Persistent Disk, Azure Disk, Ceph RBD, local path). PV создаётся администратором или динамически через StorageClass. PVC — это запрос от пользователя (или приложения) на использование хранилища.

¶Жизненный цикл связи PVC и PV

Создание PVC: Пользователь создаёт манифест PVC, указывая:

accessModes: режим доступа (ReadWriteOnce — RWO, ReadOnlyMany — ROX, ReadWriteMany — RWX, ReadWriteOncePod — RWOP).
resources.requests.storage: минимальный объём хранилища (например, 10Gi).
storageClassName: класс хранения (опционально, если не указан — используется класс по умолчанию).
selector: метки для точного выбора PV (опционально).

Поиск подходящего PV: Kubernetes (компонент kube-controller-manager) ищет существующий PV, который удовлетворяет условиям PVC:

Доступный объём (capacity) >= запрошенного.
Совместимый accessMode.
Соответствие storageClassName (если указан).
Соответствие меткам (если указан selector).
PV не должен быть занят другим PVC (статус Available).

Связывание (binding): Если подходящий PV найден, он связывается с PVC. Статус PV меняется на Bound, PVC также получает статус Bound. Если PV не найден, PVC остаётся в статусе Pending до появления подходящего тома (вручную или через динамическое выделение).
Использование в поде: В спецификации пода указывается имя PVC в поле volumes. При запуске пода Kubernetes монтирует соответствующий PV в контейнер.
Освобождение (reclaim): После удаления PVC политика reclaimPolicy PV определяет дальнейшую судьбу тома: Retain (сохранить), Delete (удалить) или Recycle (очистить и переиспользовать, устаревшая опция).

¶Динамическое выделение (Dynamic Provisioning)

Если в кластере определён StorageClass с параметром provisioner, то при создании PVC, для которого нет подходящего PV, Kubernetes автоматически создаёт новый PV через соответствующий провайдер (например, AWS EBS, GCE PD, Azure Disk, Ceph, NFS). Это упрощает администрирование: администратору не нужно вручную создавать PV для каждого запроса. StorageClass также может содержать параметры, такие как тип диска (SSD/HDD), IOPS, репликация.

¶Виды и классификация PVC

PVC классифицируются по нескольким признакам:

¶По режиму доступа (accessModes)

ReadWriteOnce (RWO): Том может быть смонтирован только одним подом в режиме чтения и записи. Наиболее распространённый режим для баз данных (например, PostgreSQL, MySQL).
ReadOnlyMany (ROX): Том может быть смонтирован несколькими подами, но только для чтения. Используется для распространения статического контента (например, конфигурационных файлов, библиотек).
ReadWriteMany (RWX): Том может быть смонтирован несколькими подами в режиме чтения и записи. Требует поддержки со стороны файловой системы (например, NFS, CephFS, GlusterFS). Используется для общего хранилища (например, shared workspace для CI/CD).
ReadWriteOncePod (RWOP): Том может быть смонтирован только одним подом (в версии 1.22+). Более строгий вариант RWO, предотвращающий монтирование несколькими контейнерами в одном поде.

¶По классу хранения (StorageClass)

Стандартный (Standard): Обычно HDD или SSD с базовыми характеристиками.
Быстрый (Fast): SSD с высоким IOPS (например, для баз данных).
Архивный (Archive): Низкая стоимость, медленный доступ (например, для резервных копий).

¶По способу выделения

Статический (static): PVC связывается с заранее созданным PV.
Динамический (dynamic): PVC вызывает автоматическое создание PV через StorageClass.

¶Применение в реальных системах

PVC широко используется в production-средах для обеспечения сохранности данных. Основные сценарии:

Базы данных: PostgreSQL, MySQL, MongoDB, Redis (с персистентностью) — используют PVC типа RWO для хранения данных на диске.
Очереди сообщений: RabbitMQ, Apache Kafka — требуют PVC для хранения логов и сообщений.
Файловые хранилища: Nextcloud, ownCloud, MinIO — используют PVC типа RWX для общего доступа.
CI/CD системы: Jenkins, GitLab Runner — используют PVC для хранения артефактов сборки и кэша.
Stateful-приложения: StatefulSet в Kubernetes автоматически создаёт PVC для каждого реплицируемого пода (например, для Cassandra, Elasticsearch).

¶Пример манифеста PVC

```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes:

ReadWriteOnce

resources: requests: storage: 10Gi storageClassName: fast-ssd ```

Этот PVC запрашивает 10 гигабайт хранилища с режимом доступа RWO и классом хранения fast-ssd. Если в кластере есть подходящий PV или StorageClass, он будет связан.

¶Преимущества и ограничения

¶Преимущества

Абстракция: Разработчики не заботятся о физическом расположении хранилища.
Динамическое выделение: Автоматическое создание томов под запрос.
Переносимость: Приложения могут быть перенесены между кластерами с разными провайдерами (например, с AWS на GCP) без изменения кода, если используются StorageClass.
Управление жизненным циклом: Автоматическое удаление томов при удалении PVC (если reclaimPolicy = Delete).

¶Ограничения

Зависимость от провайдера: Динамическое выделение работает только для поддерживаемых провайдеров (AWS, GCP, Azure, Ceph и т.д.).
Сложность с RWX: Режим ReadWriteMany требует специальной файловой системы (NFS, CephFS), что добавляет точку отказа.
Производительность: PVC добавляет накладные расходы на уровне ядра (mount, bind), особенно при большом количестве томов.
Ограничения по размеру: Некоторые провайдеры (например, AWS EBS) имеют ограничения на максимальный размер тома (16 ТБ для gp3).

¶Интересные факты

PVC является частью API-группы v1 в Kubernetes, что делает его стабильным и обратно совместимым.
В Kubernetes 1.27 была введена поддержка volumeAttributesClass — возможность изменять атрибуты тома (например, IOPS) без пересоздания PVC.
PVC может быть использован не только для подов, но и для других ресурсов, таких как StatefulSet, Deployment (через volumeClaimTemplates).
В некоторых облачных провайдерах (например, Yandex Cloud) PVC может быть привязан к конкретной зоне доступности, что требует осторожности при распределённых развёртываниях.

¶Критика и альтернативы

Основная критика PVC связана с тем, что абстракция не всегда прозрачна: разработчики могут не знать о реальных ограничениях хранилища (например, IOPS, latency). Кроме того, в сложных сценариях (например, миграция данных между кластерами) PVC может создавать проблемы с привязкой к конкретному PV. Альтернативы включают:

CSI (Container Storage Interface): Более гибкий стандарт для подключения сторонних хранилищ (например, Rook/Ceph, Portworx, Longhorn).
Local Persistent Volumes: Для высокопроизводительных приложений, где важна низкая задержка (например, базы данных на локальных SSD).
Ephemeral Volumes: Для временных данных (например, emptyDir, CSI ephemeral volumes).

¶Источники

Kubernetes Documentation: Persistent Volumes (kubernetes.io/docs/concepts/storage/persistent-volumes/)
Kubernetes Documentation: PersistentVolumeClaim (kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/)
Kubernetes GitHub Repository: Enhancement proposals for PVC (github.com/kubernetes/enhancements)
«Kubernetes in Action» by Marko Luksa (Manning Publications, 2018)
«Kubernetes: Up and Running» by Brendan Burns, Joe Beda, Kelsey Hightower (O'Reilly Media, 2019)

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →