Для того чтобы позволить приложениям запрашивать хранилище в кластере Kubernetes без необходимости иметь дело со спецификой инфраструктуры, были введены два новых ресурса. Это постоянный том (PersistentVolume) и заявка на постоянный том (PersistentVolumeClaim). Эти имена могут вводить в заблуждение, поскольку, как вы видели в предыдущих томах, даже обычные тома Kubernetes могут использоваться для постоянного хранения данных. Использовать постоянный том PersistentVolume внутри модуля немного сложнее, чем использовать обычный том модуля, на рисунке показано каким образом связаны между собой модули, заявки на постоянный том PersistentVolumeClaim, постоянные тома PersistentVolume и фактическое базовое хранилище.

Вместо того чтобы разработчик добавлял в свой модуль том, относящийся к конкретной технологии, администратор кластера настраивает базовое хранилище, а затем регистрирует его в Kubernetes, создавая ресурс PersistentVolume через сервер API Kubernetes.
Если этот материал кажется затруднительным для понимания, то лучше изучить кластер Kubernetes с нуля. Эту информацию хорошо разбирают преподаватели, когда проводят обучение системных администраторов и DevOps. Эксперты сайта KursHub составили список лучших курсов [DevOps] для начинающих. В описании курсов ищите, чтобы в плане обучения обязательно присутствовал блок про Kubernetes.
При создании ресурса PersistentVolume админ определяет его размер и режимы доступа. Когда пользователю кластера необходимо использовать постоянное хранилище в одном из своих модулей, он сначала создает манифест с заявкой Persis­tentVolumeClaim, указывая минимальный размер и требуемый режим доступа. Затем пользователь отправляет манифест с заявкой PersistentVolumeClaim в API-сервер Kubernetes, и Kubernetes находит соответствующий ресурс PersistentVolume и связывает его с заявкой. Заявка PersistentVolumeClaim затем может использоваться как один из томов в модуле. Другие пользователи не могут использовать тот же том PersistentVolume до тех пор, пока он не будет высвобожден путем удаления связанной заявки PersistentVolumeClaim.

Пример создания ресурса PersistentVolume

apiVersion:
v1 kind: PersistentVolume
 metadata:
name: mongodb-pv
 spec:
  capacity:
    storage: 1Gi
  accessModes:
  – ReadWriteOnce
  – ReadOnlyMany
 persistentVolumeReclaimPolicy: Retain
 gcePersistentDisk:
   pdName: mongodb
   fsType: ext4

При создании ресурса PersistentVolume администратор должен сообщить Kubernetes, какова его емкость и предназначен ли он для чтения и/или записи единственным узлом или несколькими узлами одновременно. Он также должен сообщить Kubernetes, что делать с ресурсом PersistentVolume, когда он высвобождается (когда заявка PersistentVolumeClaim, к которой он привязан, удаляется). И последнее, но, разумеется, не менее важное, он должен указать тип, расположение и другие свойства фактического хранения, которые поддерживает этот ресурс PersistentVolume. Если вы посмотрите внимательно, эта последняя часть точно такая же, как и ранее, когда вы напрямую ссылались на GCE Persistent Disk в томе модуля (снова показано в следующем ниже листинге).

Подача заявки на PersistentVolume путем создания ресурса PersistentVolumeClaim

Подача заявки на PersistentVolume – это совершенно другой процесс, отдельный от создания модуля, потому что вы хотите, чтобы та же самая заявка PersistentVolumeClaim оставалась в наличии, даже если модуль будет переназначен (напомним, переназначение означает, что предыдущий модуль удаляется и создается новый).

Создание заявки PersistentVolumeClaim

Необходимо подготовить манифест PersistentVolumeClaim, как показано в следующем ниже листинге, и отправить его в API Kubernetes с помощью команды kubectl create.

apiVersion: v1 kind:
PersistentVolumeClaim
metadata:
   name: mongodb-pvc
spec:
   resources:
    requests:
      storage: 1Gi
 accessModes:
  – ReadWriteOnce
 storageClassName: «»

Как только вы создаете заявку, Kubernetes находит соответствующий PersistentVolume и связывает его с заявкой. Емкость ресурса PersistentVolume должна быть достаточно большой, чтобы удовлетворить запросы в заявке. Кроме того, режимы доступа тома должны включать режимы доступа, запрошенные в заявке. В вашем случае в заявке запрашивается 1 Гб хранилища и режим доступа ReadWriteOnce. Ресурс PersistentVolume, созданный ранее, соответствует этим двум требованиям, поэтому он привязывается к вашей заявке. Это можно увидеть, проинспектировав заявку

Вывод списка заявок PersistentVolumeClaim

Выведите список всех заявок PersistentVolumeClaim, чтобы увидеть состояние вашей заявки PVC:

$ kubectl get pvc

Заявка показана как связанная (Bound) с ресурсом PersistentVolume mongodb-pv. Обратите внимание на аббревиатуры, используемые для режимов доступа:

• RWO – ReadWriteOnce – только один узел может монтировать том для чтения и записи;
• ROX – ReadOnlyMany – несколько узлов могут монтировать том для чтения;
• RWX – ReadWriteMany – несколько узлов могут монтировать том как для чтения, так и для записи.

ПРИМЕЧАНИЕ. RWO, ROX и RWX относятся к числу рабочих узлов, которые могут использовать том одновременно, а не к числу модулей.

Вывод списка томов PersistentVolume

Вы также можете увидеть, что том PersistentVolume теперь связан (Bound) и его больше нет в наличии (Available), проверив его с помощью команды kubectl get

$ kubectl get pv

Том PersistentVolume показывает, что он связан с заявкой default/mongodb-pvc. Префикс default является пространством имен, в котором расположена заявка (вы создали заявку в пространстве по умолчанию). Мы уже говорили, что ресурсы PersistentVolume находятся в области кластера и поэтому не могут быть созданы в каком-то определенном пространстве имен, однако ресурсы PersistentVolumeClaim могут быть созданы только в конкретном пространстве имен. И затем они могут использоваться лишь модулями в том же пространстве имен.