3.5.1 · блок 3

Зачем распределённое хранилище в Kubernetes

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

В модуле 3.3 вы уже видели PV/PVC и StorageClass. Но откуда берётся сам диск? В облаке провайдер создаёт EBS или Persistent Disk автоматически. В on-prem или учебном кластере на bare metal такого «магического» API нет — нужен слой, который превращает локальные диски node'ов в надёжное блочное хранилище для Pod'ов.

Для ML это критично:

Checkpoint'ы обучения — процесс может идти часами; потеря диска при падении node = потеря прогресса.
Кэш моделей на inference — быстрый read с локального тома вместо скачивания 5 GB из object storage при каждом рестарте Pod.
Базы метаданных (Feature Store, MLflow backend) — StatefulSet с постоянным томом на каждую реплику.

Распределённое блочное хранилище (Longhorn, Ceph RBD, OpenEBS) даёт Kubernetes динамические тома с репликацией между node'ами — как если бы у каждого Pod был свой «мини-диск в облаке», только внутри вашего кластера.

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

Локальный диск node vs распределённый том.

Локальный hostPath или local PV — быстро, но при переезде Pod на другую node данные не едут с ним.
Распределённый том — данные реплицируются; Pod может перезапуститься на другой node и смонтировать тот же PVC.

Репликация. Типично 2–3 копии блока на разных node'ах. Отказ одной машины не убивает том. Цена — лишний трафик и место на дисках.

Согласованность и производительность. Блочное хранилище хорошо для БД и random I/O (checkpoint, SQLite, PostgreSQL). Для огромных артефактов моделей (десятки GB) чаще используют object storage (MinIO, модуль 3.5.3) — дешевле и проще шарить между сервисами.

StorageClass как контракт. Админ кластера создаёт класс longhorn с параметрами репликации. Разработчик в PVC пишет только storageClassName: longhorn и 10Gi — не думает, на какой node лежат блоки.

Связь с access modes (повторение 3.3.5).

RWO — один Pod пишет; Longhorn отлично подходит.
RWX — несколько Pod одновременно пишут; Longhorn поддерживает, но не всегда это лучший выбор для ML (лучше object storage + локальный кэш).

Когда НЕ нужен Longhorn. Статeless inference без локального кэша — достаточно emptyDir или скачивания модели при старте из MinIO. Не создавайте PVC «на всякий случай»: каждый том — операционная нагрузка (backup, мониторинг, capacity planning).

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

Типичная схема для ML inference с кэшем:


MinIO (модель v42)  →  init container скачивает в PVC  →  main container читает /models
                              ↑
                         Longhorn RWO 10Gi

1. Data scientist публикует model.onnx в bucket ml-models.

2. Deployment с PVC model-cache (StorageClass longhorn).

3. Init container: aws s3 cp s3://ml-models/v42/model.onnx /models/ (или mc/minio client).

4. Основной контейнер с FastAPI/Triton монтирует /models read-only.

При eviction Pod'а Kubernetes поднимает новый экземпляр на другой node — Longhorn reattach'ит том, init container при необходимости догружает diff.

Диагностика на платформе MDP:


kubectl get storageclass
kubectl get pvc -n ml-dev
kubectl get volumes.longhorn.io -n longhorn-system   # если CRD установлен

Если PVC в Pending — нет provisioner'а, исчерпан pool дисков или не совпадает StorageClass.

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

[ ] Нарисуйте схему: где живут данные модели (object storage vs PVC) для вашего учебного сервиса.
[ ] Объясните своими словами: почему checkpoint обучения лучше на RWO PVC, а финальный артефакт — в S3/MinIO.
[ ] Выполните kubectl get storageclass в учебном кластере и запишите, какой класс используется по умолчанию.

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

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