Каким образом предоставить хранилище для подов в кластере Kubernetes?

Организация хранилища для Pods в Kubernetes

В Kubernetes поды (Pods) по своей природе эфемерны — они могут быть созданы, уничтожены и пересозданы в любой момент. Это создает проблему для данных, которые необходимо сохранять. Для предоставления хранилища используется концепция персистентных томов (Persistent Volumes), которая отделяет механизм хранения данных от их потребления подами. Это позволяет данным существовать независимо от жизненного цикла конкретного пода.

Основные компоненты системы хранения

Система состоит из нескольких ключевых абстракций:

1. PersistentVolume (PV) — это физический ресурс хранения в кластере (например, часть сетевого хранилища NFS, блочное устройство или облачное хранилище). PV создается администратором кластера или автоматически через Storage Classes. Он существует независимо от каких-либо подов.
2. PersistentVolumeClaim (PVC) — это "заявка" пода на использование определенного объема хранилища. Под через PVC запрашивает конкретный объем (например, 10Gi) и режим доступа (ReadWriteOnce, ReadOnlyMany, ReadWriteMany).
3. StorageClass (SC) — определяет "класс" или тип хранилища (например, fast, standard, ssd). Он описывает параметры провайдера и может включать политики рекламации (reclaim policies) и параметры создания PV. SC позволяет использовать динамическое provisionинг — автоматическое создание PV при создании PVC.

Типичный процесс предоставления хранилища

Процесс можно разделить на два основных сценария:

Статический Provisionинг (Static Provisioning)

Администратор заранее создает в кластере набор PV, представляющих реальные storage ресурсы. Затем пользователь создает PVC, которая "захватывает" подходящий PV по критериям размера и режима доступа.

Пример манифеста PV (NFS):

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

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  # storageClassName: "" # Пустая строка означает использование PV без StorageClass

Динамический Provisionинг (Dynamic Provisioning)

Это наиболее распространенный и удобный подход, особенно в облачных окружениях. Администратор создает StorageClass, описывающий тип хранилища. Когда пользователь создает PVC с ссылкой на этот StorageClass, система Kubernetes автоматически создает соответствующий PV.

Пример манифеста StorageClass для AWS EBS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp2-ebs
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true

Пример PVC, использующей этот StorageClass:

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

Подключение хранилища к Pod

После создания PVC (и связанного с ней PV), под может использовать этот объем, указав PVC в секции volumes манифеста и подключив его к контейнеру через volumeMounts.

Пример манифеста Pod с использованием PVC:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
    - name: app-container
      image: nginx
      volumeMounts:
        - name: app-storage
          mountPath: "/var/data"
  volumes:
    - name: app-storage
      persistentVolumeClaim:
        claimName: dynamic-app-pvc # Имя ранее созданной PVC

Ключевые практики и рекомендации

• Выбор режима доступа: критически важно выбрать правильный accessMode. ReadWriteOnce (RWO) — для одного пода, ReadOnlyMany (ROX) — для чтения многими, ReadWriteMany (RWX) — для совместного использования многими подами (чаще реализуется через NFS или объектные хранилища).
• Политика рекламации: определяет, что происходит с PV после удаления PVC. Delete удаляет и физический ресурс, Retain сохраняет PV и данные для возможного ручного re-use.
• Расширение объема: современные StorageClass часто поддерживают allowVolumeExpansion: true, позволяя увеличивать размер PVC (и PV) без ее recreating.
• Snapshot и резервное копирование: для критичных данных используйте механизмы снапшотов, предоставляемые провайдером (например, Volume Snapshots в CSI), или традиционные решения резервного копирования, работающие с бэкенд-хранилищем.

Таким образом, предоставление хранилища в Kubernetes — это процесс декларативного запроса ресурсов через PVC и их динамического или статического обеспечения через PV и StorageClasses, обеспечивающий сохранность данных независимо от эфемерной природы рабочих нагрузок.