Какой использовал CSI драйвер в YAML?

Отличный вопрос. Очень практичный. В моей практике выбор и использование CSI (Container Storage Interface) драйвера в YAML-манифестах всегда зависели от облачной платформы (или on-prem решения) и конкретных требований к хранилищу (производительность, тип, политики доступа).

Основной принцип использования CSI в YAML

CSI — это стандартный интерфейс, который позволяет оркестраторам вроде Kubernetes работать с внешними системами хранения, не вдаваясь в их внутреннее устройство. В YAML он используется преимущественно в двух ресурсах:

1. StorageClass – для динамической подготовки томов с определенными параметрами.
2. PersistentVolumeClaim – для запроса тома у конкретного StorageClass.
3. PersistentVolume (реже, для статической подготовки) – для прямого связывания с существующим томом.

Конкретные примеры из практики

Чаще всего я работал с облачными провайдерами. Вот как это выглядело:

1. AWS EKS (драйвер ebs.csi.aws.com)

Для автоматического создания EBS-томов использовал StorageClass.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ebs-gp3
provisioner: ebs.csi.aws.com # Имя CSI-драйвера
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
volumeBindingMode: WaitForFirstConsumer # Важно для зональных томов!
reclaimPolicy: Delete
allowVolumeExpansion: true

Затем в StatefulSet или Pod использовал PVC, ссылающуюся на этот класс:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ebs-gp3 # Ссылка на класс
  resources:
    requests:
      storage: 100Gi

2. Google Cloud GKE (драйвер pd.csi.storage.gke.io)

В GKE драйвер обычно предустановлен. StorageClass "standard" или "premium-rwo" используют CSI под капотом. Но можно создать кастомизированный:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-pd-ssd-regional
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
  replication-type: regional-pd # Региональный том для высокой доступности
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

3. On-prem / гибрид: драйверы для Ceph (RBD) или NFS

Для собственных кластеров часто использовались:

• RBD Ceph CSI (rbd.csi.ceph.com) – для блочных томов с высокой производительностью.
• CephFS CSI (cephfs.csi.ceph.com) – для томов с доступом ReadWriteMany (RWX).
• NFS CSI (например, nfs.csi.k8s.io) – для простых разделяемых томов.

Пример StorageClass для Ceph RBD:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-rbd-fast
provisioner: rbd.csi.ceph.com
parameters:
  clusterID: <ceph-cluster-id>
  pool: k8s-pool
  imageFeatures: layering
  csi.storage.k8s.io/provisioner-secret-name: ceph-csi-secret
  csi.storage.k8s.io/provisioner-secret-namespace: default
  csi.storage.k8s.io/node-stage-secret-name: ceph-csi-secret
  csi.storage.k8s.io/node-stage-secret-namespace: default
reclaimPolicy: Delete

Ключевые соображения по выбору и настройке

• Динамический vs Статический provisioning: В 95% случаев использовал динамический через StorageClass. Статическое создание PersistentVolume вручную — для legacy-систем или особых требований.
• Доступ (Access Modes): Всегда сверял с требованиями приложения. ReadWriteOnce (RWO) для StatefulSet баз данных, ReadWriteMany (RWX) через CephFS или NFS — для shared контента (например, загрузки файлов веб-приложения).
• volumeBindingMode:

    *   `Immediate` – том создается сразу при создании PVC.
    *   **`WaitForFirstConsumer` (рекомендуемый)** – том создается, когда Pod, использующий PVC, будет запланирован на конкретную ноду. Критически важно в мульти-AZ окружениях (AWS, GCP), чтобы том создался в той же зоне доступности, что и под.

• Политика возврата (reclaimPolicy):

    *   `Delete` (часто по умолчанию) – том удаляется при удалении PVC. **Опасно для продакшена, если нет снапшотов!**
    *   `Retain` – том сохраняется, данные в безопасности. Нужно чистить вручную. Часто использовал для Stateful баз данных.

• Расширение томов (allowVolumeExpansion: true): Всегда включал, где это поддерживалось драйвером (большинство облачных и Ceph CSI). Это позволяет увеличить размер PVC без простоя.
• Snapshot и Clone: Современные CSI-драйверы (особенно cloud) поддерживают создание снапшотов и клонов томов через VolumeSnapshotClass. Это активно использовалось для создания тестовых сред.

Итог

В YAML я не прописывал сам CSI-драйвер напрямую в Pod. Вместо этого, через параметр provisioner в StorageClass указывал, какой именно драйвер (ebs.csi.aws.com, pd.csi.storage.gke.io, rbd.csi.ceph.com) будет обслуживать запросы на создание томов из PVC. Это обеспечивало переносимость конфигурации: манифесты приложения (PVC) ссылались на абстрактный StorageClass, а конкретная реализация хранения определялась один раз на уровне кластера. Для успешной работы всегда необходимо было предварительно установить и сконфигурировать соответствующий CSI-драйвер (через Helm chart или манифесты от вендора) и создать необходимые Kubernetes Secrets для аутентификации в облаке или storage-бэкенде.