Что такое pv, pvc?

Определения PV (PersistentVolume) и PVC (PersistentVolumeClaim)

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

PersistentVolume (PV): "Том как ресурс кластера"

PersistentVolume (PV) — это абстракция, представляющая собой кусок сетевого или физического хранилища в кластере. PV — это ресурс кластера, подобный узлу (Node). Он существует независимо от подов (Pods), которые его будут использовать. Администратор кластера заранее подготавливает набор PV, используя различные StorageClass или статически.

PV описывает конкретную реализацию хранилища: его тип (например, NFS, iSCSI, облачный диск AWS EBS, GCE Persistent Disk, Ceph RBD), емкость, политики доступа (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) и другие параметры (например, ID диска, путь на NFS-сервере).

Пример манифеста PV для NFS:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-example
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.1.100
    path: "/exports/data"

PersistentVolumeClaim (PVC): "Заявка на том"

PersistentVolumeClaim (PVC) — это запрос пользователя (разработчика, манифеста приложения) на определенное количество ресурсов хранилища с определенными характеристиками. Фактически, это заявка на использование PV. PVC определяет потребности в хранилище без знания деталей его реализации: сколько нужно (например, 5 Гиб), в каком режиме доступа (например, ReadWriteOnce) и, опционально, какой класс хранилища (storageClassName) предпочтителен.

Когда пользователь создает PVC, система Kubernetes (контроллер PersistentVolume) ищет подходящий PV, который соответствует требованиям по емкости и режимам доступа, и связывает (bind) его с этой заявкой. После успешной привязки PVC можно монтировать в под (Pod) как том.

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-ssd # Опционально, может быть стандартным или ""

Взаимодействие и жизненный цикл

1. Создание PV: Администратор создает набор томов (статически или используя StorageClass для динамической подготовки).
2. Создание PVC: Разработчик в манифесте приложения создает PVC с требованиями.
3. Динамическое Provisioning (рекомендуемый способ): Более современный подход, где администратор не создает PV вручную. Вместо этого определяется один или несколько StorageClass.

    *   `StorageClass` описывает "типовой" том: провайдера (AWS, GCP), тип диска (ssd, hdd), параметры (зона, уровень IOPS).
    *   В PVC указывается `storageClassName` (например, `fast-ssd`).
    *   При создании такого PVC **не** ищется существующий PV. Вместо этого контроллер динамического provisioning'а (`external-provisioner`), связанный с указанным StorageClass, автоматически создает новый том в соответствующей облачной или сетевой системе хранения и тут же создает PV-объект в Kubernetes, который немедленно связывается с ожидающей заявкой PVC.

1. Привязка (Binding): PVC находит подходящий PV (статический или динамически созданный) и связывается с ним в связку "один к одному".
2. Использование: PVC указывается в спецификации Pod'а. Внутри Pod'а том монтируется по указанному пути.

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
   spec:
     containers:
     - name: app
       image: nginx
       volumeMounts:
       - mountPath: "/var/www/html"
         name: data-volume
     volumes:
     - name: data-volume
       persistentVolumeClaim:
         claimName: app-data-claim # Ссылка на созданный PVC
   

3. Освобождение (Releasing): Когда Pod удаляется, PVC (и связанный с ним PV) могут быть освобождены. Поведение после освобождения определяется политикой возврата (persistentVolumeReclaimPolicy) PV:

    *   **Retain** (Хранить): Данные и том сохраняются. PVC удаляется, но PV переходит в состояние `Released`. Администратор должен вручную очистить данные и PV, чтобы использовать его снова.
    *   **Delete** (Удалить): Том автоматически удаляется во внешней системе хранения (например, облачный диск уничтожается).
    *   **Recycle** (Устарело, не рекомендуется): Данные на томе удаляются (например, с помощью `rm -rf /volume/*`), и том становится доступен для новой PVC.

Ключевые преимущества

• Разделение ответственности: Разработчик декларирует потребности (мне нужно 10 ГБ на чтение-запись), не зная деталей инфраструктуры.
• Гибкость и портируемость: Один и тот же манифест приложения (с PVC) может работать в разных кластерах (AWS, GCP, on-premise), где администратор настроил соответствующие StorageClass.
• Эффективное управление ресурсами: Динамический provisioning предотвращает создание избыточных томов заранее, ресурсы выделяются "по требованию" (on-demand).

Таким образом, связка PV/PVC, особенно в сочетании с StorageClass, является краеугольным камнем системы управления состоянием (stateful workloads) в Kubernetes, обеспечивая надежное, переносимое и управляемое хранение данных для контейнеризированных приложений.