Storage и данные

Что нужно знать перед уроком

M1 урок 6 — базовая модель StorageClass. Этот урок обзорно разбирает типы StorageClass в Deckhouse и специфичный для платформы ReplicatedStorageClass.

Теория

Напоминание: reclaimPolicy и volumeBindingMode

Как разобрано ранее в курсе: reclaimPolicy: Delete (дефолт для большинства динамических StorageClass) уничтожает физические данные вместе с PersistentVolume при удалении PersistentVolumeClaim; reclaimPolicy: Retain, выставленный вручную, сохраняет данные, отсоединяя PersistentVolume от PersistentVolumeClaim, но не удаляя их — ключевой механизм защиты данных, уже встречавшийся в M6 уроке 7. volumeBindingMode: Immediate провижинирует том сразу при создании PVC (может привести к unschedulable Pod при топологических ограничениях диска — например, локальный диск существует только на конкретном узле, а Pod запланирован на другой); WaitForFirstConsumer откладывает провижининг до момента, когда планировщик уже выбрал узел для Pod — обязателен для локальных дисков.

ReplicatedStorageClass — уровни репликации Deckhouse

1
2
3
4
5
6
7
8
9

apiVersion: storage.deckhouse.io/v1alpha1
kind: ReplicatedStorageClass
metadata:
  name: replicated-sc-ssd-r2
spec:
  storagePool: data-ssd-nvme-unsafe
  replication: Availability
  reclaimPolicy: Delete
  topology: Ignored

ReplicatedStorageClass — специфичный для Deckhouse тип StorageClass, обеспечивающий репликацию данных между узлами на уровне самого хранилища (в отличие от репликации на уровне приложения — например, встроенной репликации PostgreSQL). Три уровня replication:

Какой уровень репликации выбрать для БД-зависимого Application

Для типового Application, зависящего от managed-postgres/подобного Module (M6), сама реплицируемость данных обычно уже обеспечена на уровне Module (managed-сервис PostgreSQL, как правило, сам управляет своей репликацией через собственный StatefulSet+Patroni/подобный механизм) — конечному Application-разработчику часто не нужно напрямую создавать ReplicatedStorageClass для данных СУБД, это ответственность Module. Однако если Application сам управляет собственным персистентным хранилищем (например, для файлов, загружаемых пользователями, не относящихся к БД), выбор уровня репликации становится прямой ответственностью разработчика — здесь Availability обычно достаточен для большинства сценариев, а ConsistencyAndAvailability оправдан только для данных, где даже кратковременная рассинхронизация после сетевого сбоя неприемлема.

Частые ошибки и подводные камни

• Использовать replication: None для критичных пользовательских данных «по умолчанию», не задумываясь о последствиях. Потеря единственного узла с диском без репликации означает необратимую потерю данных — уровень None подходит только для действительно некритичных, легко восстановимых данных.
• Выбирать ConsistencyAndAvailability везде «для надёжности» без учёта trade-off по производительности. Более строгие гарантии консистентности обычно означают более высокую задержку записи (кворумное подтверждение) — избыточно строгий уровень для некритичных данных неоправданно снижает производительность.
• Дублировать репликацию, создавая собственный ReplicatedStorageClass для данных, уже реплицируемых на уровне зависимого Module (managed-БД). Это избыточно и может создавать путаницу в ответственности за консистентность данных — репликация СУБД обычно должна оставаться в зоне ответственности управляющего ей Module.

Практика в кластере

1
2
3

d8 k get storageclass
d8 k get replicatedstorageclass
d8 k get pvc -n course-m10-umami -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.storageClassName}{"\n"}{end}'

Определите, какой StorageClass/ReplicatedStorageClass используется для PVC пакета Umami в вашем практическом кластере, и оцените, соответствует ли выбранный уровень репликации критичности данных этого PVC.

Практика разработки

Проведите ревизию всех PVC, объявленных в шаблонах пакета Umami — для каждого явно задокументируйте (в комментарии YAML) требуемый уровень репликации и обоснование выбора, опираясь на критичность конкретных данных (файлы аплоадов vs временный кэш).

Шпаргалка команд урока

1

d8 k get storageclass,replicatedstorageclass

Полная сводная таблица kubectl/d8 k — 📋 kubectl .

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — ReplicatedStorageClass (CRD модуля sds-replicated-volume)
• kubernetes.io — Persistent Volumes
• kubernetes.io — Storage Classes

Статьи и блоги

• Основные концепции сетевой архитектуры Kubernetes (Volumes, StorageClass) — Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий урок: M10.06 — PDB для Application.
• Следующий урок: M10.08 — Backup: что действительно бэкапится, а что нет.

✓ Урок пройден — все вопросы самопроверки отвечены верно