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

Longhorn — распределённое блочное хранилище для Kubernetes от Rancher/SUSE. На платформе MDP это типичный StorageClass для PVC: динамическое создание томов, репликация, UI для ops, snapshot/backup. Как ML-инженер вы не админите Longhorn каждый день, но должны понимать: как создаётся том, что происходит при падении node и как не «сломать» данные при удалении PVC.

Если вы привыкли к файлам на своём ноутбуке — представьте Longhorn как RAID-массив, размазанный по серверам кластера, с API для Kubernetes.

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

Архитектура (упрощённо).

Longhorn Manager — control plane в namespace longhorn-system.
Engine — процесс на node, обслуживающий конкретный том (блочный I/O).
Replica — копия данных на другом node.
Instance Manager — управляет engine/replica на node.

Kubernetes видит только StorageClass → PV → mount в Pod. Внутренности Longhorn скрыты, пока всё healthy.

Dynamic provisioning. PVC с storageClassName: longhorn → Longhorn provisioner создаёт том нужного размера → биндится PV.

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: training-checkpoints namespace: ml-train spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 50Gi

Number of Replicas. В StorageClass или аннотациях задаётся число реплик (часто 3). Больше реплик — выше отказоустойчивость, меньше — экономия диска.

Snapshots. Point-in-time снимок тома — быстрый способ «заморозить» состояние перед рискованным экспериментом или перед upgrade модели на inference PVC.

Backup. Snapshot можно отправить в S3/MinIO (backup target) — disaster recovery, если погиб весь кластер.

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

Node failure. Longhorn перестраивает реплику на живой node; Pod с RWO может перезапуститься и reattach. Время восстановления зависит от размера тома и сети — для больших checkpoint'ов закладывайте это в SLO.

Anti-pattern для ML. Один RWO том на Deployment с replicas: 3 — только одна реплика сможет смонтировать том. Для горизонтального масштабирования inference используйте object storage + локальный emptyDir или RWX с пониманием ограничений.

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

Сценарий: checkpoint при обучении в Kubernetes Job.

Job монтирует PVC checkpoints (Longhorn 100Gi).
Python-код пишет checkpoint_epoch_10.pt каждые N шагов.
Node падает — Job retry, новый Pod на другой node, тот же PVC, обучение продолжается с последнего файла на диске.
По завершении Job артефакт копируется в MinIO (mc cp), PVC можно удалить или оставить для отладки.

Проверка состояния (read-only для студента):

` kubectl get pvc -n ml-train kubectl describe pvc training-checkpoints -n ml-train

UI Longhorn (если доступен в MDP): Volume → Replicas → Health

Типичные проблемы.

Симптом	Возможная причина
PVC Pending	Нет default StorageClass, нет свободного места на node
Pod ContainerCreating	Том ещё attaching, degraded replica
Медленный I/O	Перестройка реплик, сеть между node'ами

Связь с Helm/Argo. Chart inference-сервиса включает PersistentVolumeClaim template с storageClassName из values — окружения dev/prod могут использовать разные классы или размеры.

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

Создайте PVC с StorageClass Longhorn (или аналог в учебном кластере) и смонтируйте в Pod; запишите файл, удалите Pod, убедитесь что данные на месте.
Объясните, почему три реплики Longhorn не заменяют backup в MinIO/S3.
Посмотрите reclaim policy вашего StorageClass и опишите риск при helm uninstall chart с PVC.

Longhorn на практике: тома, реплики, снимки