3.3.5 · блок 3

Хранилище: 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 и опишите, какой класс использует ваш учебный кластер.

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

Открыть интерактивную версию