Для работы с дисками для данных, которые должны храниться постоянно, Kubenetes предоставляет два типа ресурсов – PersistentVolume и PersistentVolumeClaim.

PersistentVolume – непосредственно система хранения, раздел на жёстком диске, например AWS EBS, подключенном к одному из AWS EC2, и с точки зрения этого кластера является таким же ресурсом как, например, Kubernetes Worker Node.

PersistentVolumeClaim – запрос от пользователя на использование такого диска, аналог Kubernetes pod – поды используют ресурсы Worker Node, а PVC – ресурсы PersistentVolume. По аналогии же с подами – поды запрашивают у рабочей ноды ЦПУ и память, а PVC – необходимый им размер диска, и тип доступа – ReadWriteOnce, ReadOnlyMany или ReadWriteMany, см. AccessModes.

PersistentVolume могут быть созданы двумя способами – динамически (рекомендуемый способ), и статически.

При статичном методе сначала создаётся набор дисков, например EBS, которые затем используются кластером для PersistentVolumeClaim.

В случе, если для PersistentVolumeClaim не удалось найди подходящий PV – кластер может создать отдельный PV конкретно для этого PVC – это и будет динамическое создание PVC.

При этом в PVC должен быть задан Storage Class, и такой класс должен поддерживаться кластером.

К примеру, для AWS EKS по-умолчанию создан StorageClass gp2:

Типы дисков

Для понимания роли PersistentVolume – рассмотрим доступные системы хранения:

• Node-local хранение (emptyDir и hostPath)
• Cloud volumes (например, awsElasticBlockStore, gcePersistentDisk и azureDiskVolume)
• File-sharing volumes, такие как Network File System
• Distributed-file systems (например, CephFS, RBD и GlusterFS)
• специальные типы разделов, такие как PersistentVolumeClaim, secret и gitRepo

emptyDir и hostPath подключаются к подам, и хранят данные или в памяти, или на диске. Но т.к. они зависимы от подов, их содержимое доступно только пока работает контейнер, и когда контейнере останавливается – данные удаляются.

Cloud volumes, NFS и PersistentVolume разделы независимы от подов, и располагаются вне их.

Создание PersistentVolumeClaim

Static PersistentVolume provisioning

Создание EBS

При Static provisioning – сначала создаётся AWS EBS, и затем объект PersistentVolume, которому явно указывается использование этого EBS.

Создаём EBS:

Сохраняем его ID – “vol-0928650905a2491e2”.

Создание PersistentVolume

Описываем манифест, назовём его pv-static.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-static
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: gp2
  awsElasticBlockStore:
    fsType: ext4
    volumeID: vol-0928650905a2491e2

Тут:

• capacity: размер диска
• accessModes: типа доступа, тут ReadWriteOnce – раздел может быть смонтирован только к одной рабочей ноде с правами чтения/записи
• storageClassName: тип хранилища, см. ниже
• awsElasticBlockStore: тип используемого диска
  • fsType: тип файловой системы
  • volumeID: ID AWS EBS диска

Создаём PersistentVolume:

Проверяем:

StorageClass

Параметр storageClassName определяет тип хранилища.

И для PVC, и для PV должен быть задан один и тот же класс, иначе PVC не подключит PV, и STATUS такого PVC будет Pending.

Если для PVC не задан StorageClass – будет использован дефолтный:

При этом если StorageClass не указан для PV – он будет создан без указания класса, и PVC с классом по-умолчанию его не подключит, а выдаст ошибку “Cannot bind to requested volume “pvname”: storageClassName does not match“:

См. документацию тут>>> и тут>>>.

Создание PersistentVolumeClaim

Добавляем PersistentVolumeClaim, который будет использовать этот PV:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-static
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  volumeName: pv-static

Создаём его:

Проверяем:

Dynamic PersistentVolume provisioning

Динамическое создание PersistentVolume аналогично статическому с той разницей, что мы не создаём EBS, и не создаём отдельного ресурса PersistentVolume – вместо этого мы опишем PersistentVolumeClaim, который самостоятельно создаст EBS, и смонтирует его к EC2 WorkerNode:

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

Создаём PVC:

Проверяем:

Но почему статус Pending? Смотрим события:

WaitForFirstConsumer

Проверим ещё раз наш дефолтный StorageClass:

Тут VolumeBindingMode определяет, как именно будет создаваться PersistentVolume. При значении Immediate – PV будет создан сразу же при появлении соотвествующего PVC, а при WaitForFirstConsumer – кластер сначала ожидает появления пода, который запросит этот PV, и затем, в зависимости от AvailbiltyZone рабочей ноды, на которой был запущен под, создёт PV.

Давайте создадим поды, которые будут использовать эти PVC.

Использование PersistentVolumeClaim в Pod

Dynamic PersistentVolumeClaim

Опишем под, который будет использовать наш dynamic PVC:

apiVersion: v1
kind: Pod
metadata:
  name: pv-dynamic-pod
spec:
  volumes:
    - name: pv-dynamic-storage
      persistentVolumeClaim:
        claimName: pvc-dynamic
  containers:
    - name: pv-dynamic-container
      image: nginx
      ports:
        - containerPort: 80
          name: "nginx"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pv-dynamic-storage

Тут:

• volumes:
  • persistentVolumeClaim:
    • claimName: указываем имя PVC, который будет запрошен создаваемым подом для создания раздела
• containers:
  • volumeMounts: монтируем volume с именем pv-dynamic-storage в каталог /usr/share/nginx/html

Создаём под:

Проверяем ещё раз наш PVC:

Теперь у нас появился созданный Volume с ID pvc-6d024b40-a239-4c35-8694-f060bd117053 – проверяем его:

Проверим раздел:

И vol-040a5e004876f1a40 в AWS:

Проверим в самом поде:

nvme1n1 – наш диск.

Запишем данные:

Убиваем под:

Создадим заново:

Проверяем данные:

Всё на месте.

Static PersistentVolumeClaim

Теперь попробуем использовать статичный PV.

Используем тот же манифест того же PV, который использовали ранее, pv-static.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-static
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: gp2
  awsElasticBlockStore:
    fsType: ext4
    volumeID: vol-0928650905a2491e2

И берём тот же PVC – pvc-static.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-static
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  volumeName: pv-static

Создаём PV:

Проверяем:

Создаём PVC:

Проверяем:

STATUS Bound – значит PVC нашёл свой PV, и подключился к нему.

Pod nodeAffinity

Определяем, в какой AvailabilityZone расположен наш EBS:

us-east-2a – окей, значит, нам надо и под создавать в той же AvailabilityZone.

Пишем манифест для пода:

apiVersion: v1
kind: Pod
metadata:
  name: pv-static-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - us-east-2a
  volumes:
    - name: pv-static-storage
      persistentVolumeClaim:
        claimName: pvc-static
  containers:
    - name: pv-static-container
      image: nginx
      ports:
        - containerPort: 80
          name: "nginx"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pv-static-storage

В отличии от Dynamic PVC – тут через nodeAffinity мы явно задаём поиск ноды для этого пода в зоне us-east-2a.

Создаём под:

Проверяем события:

Разделы в самом поде:

nvme1n1 смонтирован, всё работает.

PersistentVolume nodeAffinity

Другой вариант – PV nodeAffinity.

В таком случае, при создании пода, который использует этот PV – Kubernetes сначала проверит, к каким рабочим нодам этот PV можно подключить, и после запустит под на одной из доступных для этого PV ноде.

В описании пода убираем nodeAffinity:

apiVersion: v1
kind: Pod
metadata:
  name: pv-static-pod
spec:
  volumes:
    - name: pv-static-storage
      persistentVolumeClaim:
        claimName: pvc-static
  containers:
    - name: pv-static-container
      image: nginx
      ports:
        - containerPort: 80
          name: "nginx"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pv-static-storage

И добавляем его к самому PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-static
spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: failure-domain.beta.kubernetes.io/zone
          operator: In
          values:
          - us-east-2a    
  capacity:
    storage: 50Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: gp2
  awsElasticBlockStore:
    fsType: ext4
    volumeID: vol-0928650905a2491e2

Создаём PV:

Создаём PVC – там ничего не менялось:

Создаём под:

Проверяем логи:

Удаление PersistentVolume и PersistentVolumeClaim

Когда пользователь удаляет PVC, который используется подом, этот PVC удаляется не сразу – удаление откладывается, пока не будет остановлен использующий его под.

Аналогично, при удалении PV, к которому есть binding от какого-либо PVC, этот PV тоже удаляется не сразу, до тех пор, пока существует связь между PVC и PV.

Reclaiming

Документация тут>>>.

Когда пользователь заканчивает работу с PersistentVolume, он может удалить его объект из кластера, что бы освободить ресурс AWS EBS (reclaim).

Reclaim policy для PersistentVolume указывает кластеру, что делать с овободившимся диском, и может иметь значение Retained, Recycled или Deleted.

Retain

Retain политика позволяет выполнять ручную очистку диска.

После удаления соответвующего PersistentVolumeClaim, PersistentVolume остаётся, и отмечается как “released“, однако становится недоступен для новых PersistentVolumeClaim, т.к. содержит данные предыдущего PersistentVolumeClaim.

Для того, что бы использовать такой ресурс повторно – можно либо удалить объект PersistentVolume, при этом AWS EBS останется доступен, био вручную удалить данные с диска.

Delete

При Delete – удаление PVC приводит к удалению и соответствующего устройсва, такого как AWS EBS, GCE PD или Azure Disk.

Разделы, созданные автоматически наследуют политику из StorageClass, которая по умолчанию задана в Delete.

Recycle

Устарела. Выполняет удаление с раздела обычным rm -rf.

Пример удаление PV и PVC

Итак, у нас имеется под:

К которому подключен PVC:

Который биндится на PV:

У нашего PV RECLAIM POLICY задана в Retain – значит, после удаления PVC и PV данные должны остаться на месте.

Пробуем – запишем данные:

Выходим, и удаляем под, затем PVC:

Проверяем статус PV:

STATUS == Released, и сейчас мы не сможем подключить его обратно к поду через PVC.

Попробуем – создадим ещё раз PVC:

Под:

И проверяем статус PVC:

Статус Pending.

Снова удалим под, PVC, и теперь и сам PV:

Создаём заново:

Проверяем PVC:

И проверим данные в поде:

Данные на месте.

Изменение Reclaim Policy для PersistentVolume

Документация тут>>>.

Сейчас наш PV имеет политику Retain:

Патчим его – меням политику на Delete:

Проверяем:

Удаляем под и PVC:

Проверяем PV:

И AWS EBS, который использовался для этого PV:

В целом, на этом всё.

Ссылки по теме

• Topology-Aware Volume Provisioning in Kubernetes
• Using preexisting persistent disks as PersistentVolumes
• Persistent volumes with persistent disks
• Kubernetes Persistent Storage: Why, Where and How
• Stateful Containers on Kubernetes using Persistent Volume and Amazon EBS