03 · Платформа: DevOps, k8s, сеть, хранилище3.3 · Kubernetes углублённо3.3.5сложный

Хранилище: PV, PVC и StorageClass

Зачем это нужно

Контейнеры с ephemeral filesystem: при удалении Pod локальные данные исчезают. ML-сценарии с долговременным state: кэш больших embeddings на диске, checkpoint при длинном обучении, read-only mount каталога моделей с Longhorn (модуль 3.5). PersistentVolume (PV) и PersistentVolumeClaim (PVC) — стандартный способ подключить диск к Pod.

Без PVC вы либо запекаете гигабайтную модель в образ (медленный pull), либо теряете данные при каждом restart.

Основные идеи

PersistentVolume (PV). Ресурс хранения в кластере: NFS, cloud disk, Longhorn, local path. Часто создаётся автоматически через StorageClass.

PersistentVolumeClaim (PVC). «Заявка» Pod'а: «мне нужно 10Gi, ReadWriteOnce». Scheduler + provisioner выделяют PV.

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: model-cache spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: longhorn

StorageClass. Шаблон динамического provisioning: kubectl get storageclass. Параметры: тип диска, репликация (Longhorn), reclaim policy.

Access modes.

  • RWO (ReadWriteOnce) — один node монтирует том read-write; несколько Pod на этом же node могут использовать том. Если нужен именно один Pod read-write, используйте ReadWriteOncePod (при поддержке драйвером).

  • ROX (ReadOnlyMany) — несколько Pod read-only (общая модель на NFS).

  • RWX (ReadWriteMany) — несколько Pod read-write — реже, нужна поддерживающая FS.

Mount в Pod.

` volumes:

  • name: models persistentVolumeClaim: claimName: model-cache containers:
  • volumeMounts:
    • name: models mountPath: /models readOnly: true

`

Reclaim policy. Retain — PV остаётся после удаления PVC (ручная очистка); Delete — том удаляется вместе с claim (осторожно в prod).

emptyDir. Временный том на node — логи, scratch; не переживает reschedule на другую node.

Object storage vs block. Большие артефакты моделей часто в S3/MinIO; PVC — для low-latency local cache или БД. Не дублируйте 50GB модель и в образ, и на PVC без причины.

Как это выглядит на практике

Inference с hot-reload модели с диска:

  1. CI кладёт model.onnx в S3.

  2. Init container или sidecar скачивает в PVC при старте Pod.

  3. Main container читает /models/model.onnx с readiness после загрузки.

StatefulSet для metadata DB — volumeClaimTemplates: каждый Pod получает свой PVC data-scorer-0.

Отладка:

kubectl get pvc -n ml-prod kubectl describe pvc model-cache

Pending — нет StorageClass или не хватает capacity на Longhorn.

Практикум модуля 3.3: Deployment + Service + PVC + HPA — PVC для конфигурации или кэша; HPA масштабирует реплики. RWO не гарантирует эксклюзивность одного Pod и не подходит как общий диск для реплик на разных node: для этого нужен RWX или object storage.

Что сделать после занятия

  • Создайте PVC и смонтируйте в Deployment; запишите файл в /models и перезапустите Pod — данные должны сохраниться.

  • Сравните RWO и RWX: когда для 3 реплик inference нужен object storage вместо PVC?

  • Выполните kubectl get storageclass и опишите, какой класс использует ваш учебный кластер.

Официальные материалы