Модуль 23. Хранилища в Kubernetes
BI/DWH-нагрузки живут на данных. От выбора хранилища зависит SLA отчётности, стоимость владения и простота эксплуатации. В Kubernetes опорные понятия — PV/PVC/StorageClass/CSI. Дальше — вопрос правильного бэкенда под профиль I/O и потребности по доступности.
База: как Kubernetes работает с дисками
Объекты и роли
- PersistentVolume (PV) — реальный том (диск/раздел/сеть). Живёт отдельно от подов.
- PersistentVolumeClaim (PVC) — «заявка» на том: сколько, где, с каким классом.
- StorageClass (SC) — политика: какие параметры у создаваемых PV (тип диска, зона, reclaimPolicy и т. п.).
- CSI-драйвер — плагин, который умеет создавать/монтировать/снапшотить тома конкретного сториджа.
Ключевые настройки
-
Доступ: RWO (один writer), ROX (многие читатели), RWX (много читателей/писателей).
Для БД → почти всегда RWO. Для шаринга файлов/экспортов → RWX. - VolumeMode: Filesystem (обычно) или Block (сырой блок для некоторых СУБД/датаплейнов).
- Binding: WaitForFirstConsumer (SC создаёт PV в зоне выбранного нодой пода) — снижает перекос по зонам.
- ReclaimPolicy: Delete (удалить бэкенд-том вместе с PV) или Retain (не удалять данные).
- Расширение: allowVolumeExpansion: true в SC. Планируйте заранее.
- Снапшоты: VolumeSnapshotClass + VolumeSnapshot. Работает, если CSI поддерживает.
Мини-эскизы (для ориентира):
# StorageClass с ленивым биндингом
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: fast-rwo }
provisioner: rbd.csi.ceph.com # пример
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
parameters:
csi.storage.k8s.io/fstype: xfs
# PVC под БД
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: db-data }
spec:
accessModes: [ ReadWriteOnce ]
storageClassName: fast-rwo
resources: { requests: { storage: 500Gi } }
Подбираем хранилище под BI/DWH (hot/warm/cold)
-
Hot (низкая латентность, высокий QPS): журналы и данные онлайн-БД (Postgres/ClickHouse), координаторы/кэши.
RWO SSD/NVMe (локальный PV или Ceph RBD на быстрых дисках). -
Warm (сканы/агрегации, высокие MB/s): сегменты ClickHouse, Trino spill, промежуточные файлы.
RWO SSD/HDD — чаще RBD/локальный, XFS/ext4; для CH — XFS предпочтительно. -
Cold (дёшево много TB, архивы, lakehouse): сырые/курируемые датасеты, бэкапы, экспорты.
Объектное S3 (MinIO/Ceph RGW/облако) с форматом Parquet/Iceberg.
Правило: БД и «псевдо-POSIX» над S3 — плохо. Для объявлений POSIX берите блок/файловые тома. S3 — через нативные клиенты/приложения (Trino, Spark, MinIO SDK).
Бэкенды и их применение
NFS (RWX-классика)
- Плюсы: просто, дешёво, удобно для совместного доступа (экспорты, статические файлы BI, артефакты).
-
Минусы: блокировки/метаданные медленнее, «stale file handle», нет транзакционности под БД.
Не храните на NFS активные Postgres/ClickHouse.
Ceph (Rook) — универсальный «швейцарский нож»
- RBD (блок, RWO): для БД/чувствительных к латентности нагрузок.
- CephFS (файловая, RWX): шары для нескольких подов (экспорты, общие каталоги).
- RGW (S3): объектное хранилище «как у облака».
- Плюсы: один кластер — три интерфейса; репликация, стабильность, CSI/снапшоты.
- Минусы: сложнее в эксплуатации, требует компетенций и быстрых дисков.
Локальные PV (NVMe/SSD)
- Плюсы: максимальная производительность (особенно для CH/временных данных).
- Минусы: привязка к ноде; надо решать отказоустойчивость на уровне приложения/репликации.
Диски облака (EBS/ComputeDisk/…)
- Плюсы: быстро стартовать, есть снапшоты, многозонные типы.
- Минусы: lock-in по провайдеру, цена за IOPS/через-пут выше, чем у «своего» Ceph при больших объёмах.
MinIO (S3-совместимое внутри кластера)
- Плюсы: быстрый S3 для lakehouse/бэкапов/экспортов BI; мультисайтовая репликация.
- Минусы: это отдельный сервис, его тоже надо бэкапить/мониторить; не POSIX.
«S3-адаптеры» и псевдо-FS над S3 (s3fs-fuse, goofys, JuiceFS)
- Когда уместно: legacy-приложению очень нужен «каталог», а переписать на S3-SDK нельзя.
- Риски: eventual consistency, странные ошибки POSIX, непредсказуемые задержки. Не для БД и интенсивных метаданных.
Производительность и настройки (что реально влияет)
- Файловая система: для CH/больших файлов — XFS, для PG — ext4/XFS (тестируйте).
- Mount-опции: noatime, nobarrier (осторожно!), discard по расписанию, lazytime — по профилю.
- Размеры и блоки: выравнивание на RAID/страйп, readahead для последовательных сканов.
- Ceph RBD: пул для журналов/данных отдельно; следите за op latency, pg autoscaler.
- NFS: rsize/wsize, версии протокола (v4.1+), actimeo — осторожно.
- S3: размер объектов и «мелкие файлы» влияют на сканы → планируйте compaction (Iceberg/Spark jobs).
- Trino spill: быстрый RWO и достаточный fsync/IOPS, иначе будет деградация интерактива.
Безопасность и доступ
- Шифрование на дисках (dm-crypt/LUKS или на уровне провайдера), в полёте — TLS к S3/NAS.
- Секреты доступа — только через External Secrets Operator/Vault.
- Сегментация: NetworkPolicy к хранилищам (RGW/NFS/мониторы Ceph).
- Права POSIX: fsGroup, runAsUser, избегайте root-доступа без нужды.
- Bucket-policy: least privilege (под каждый сервис — свой user/key).
- Бэкапы секретов и ротации ключей — в регламент.
Операции и бэкапы
- Velero (бэкап манифестов и PV): через снапшоты CSI или restic. Обязательно учения restore.
- Снапшоты БД: pgBackRest/PITR, clickhouse-backup — в S3/облако.
- Мониторинг: заполнение PV, fio-тесты при приёмке, метрики RBD/NFS/S3 (latency/throughput/4xx/5xx).
- Retention: горячие бэкапы — 7–30 дней, архив — в «холоде» (S3 glacier-подобные).
- Документируйте пути миграции (SC→SC, S3→S3, Ceph→облако) и их RTO/RPO.
Риски и анти-паттерны
|
Риск |
Как проявляется |
Что делать |
|---|---|---|
|
Lock-in в бэкенд |
Тяжело мигрировать/дорого масштабировать |
Абстрагироваться PVC/SC, избегать экзотики, держать путь экспорта (S3/снапшоты), Own-Ceph/MinIO для снижения зависимости |
|
БД на RWX/NFS |
Блокировки/потери, деградация |
Для БД только RWO-блок (RBD/локальный), NFS — для шаринга файлов |
|
«S3 как диск» под нагрузкой |
Таймауты, «битые» каталоги |
Только нативный S3-доступ; FUSE — максимум для редких, не критичных задач |
|
Нет WaitForFirstConsumer |
ПВ в «не той» зоне → латентность |
Включить в SC, проверять топологию |
|
Мелкие файлы в S3 |
Медленные сканы Trino/CH |
Compaction/merge, крупные батчи ingest |
|
Reclaim=Delete без оглядки |
Потеря данных при удалении PVC |
На проде чаще Retain и ручная утилизация |
|
Нет DR-репликации S3 |
Потеря площадки = потеря бэкапов |
Репликация бакетов/версионирование, периодические restore-учения |
Практика (лабораторка)
-
Создать два StorageClass:
fast-rwo (Ceph RBD/локальный NVMe, WaitForFirstConsumer, Retain) и shared-rwx (CephFS/NFS). - Развернуть Postgres на fast-rwo и прогнать короткий тест I/O (pgbench), снять латентность.
- Поднять MinIO (S3) с пользователем под BI-экспорты; сформировать бакет-policy только на putObject/getObject для сервиса.
- Сделать бэкап (pgBackRest в S3/Velero снапшот PVC) и восстановить в тестовый namespace.
- Профилировать Trino spill на fast-rwo vs «медленный» SC — зафиксировать разницу p95.
- Проверить compaction в Iceberg (сделать задачку перепаковки мелких файлов).
Чек-лист «готово к продакшену (хранилища)»
- Под каждую роль — свой SC: fast RWO (БД), shared RWX (шары), объектное S3 (lakehouse/бэкапы).
- SC с WaitForFirstConsumer, PVC расширяемы (allowVolumeExpansion).
- ReclaimPolicy = Retain для критичных томов; регламент утилизации «осиротевших» PV.
- Снапшоты CSI/Velero настроены, учения восстановления проведены.
- Шифрование на дисках и TLS к S3/NAS; секrets — через Vault/ESO.
- Мониторинг IOPS/latency/throughput + заполнение PV, S3 4xx/5xx, compaction в lakehouse.
- Документированы пути миграции и оценки TCO (Ceph vs облако, S3 vs блок).
- NFS не используется для БД; S3 не монтируется как POSIX под критичные нагрузки.
Вопрос-ответ
В: Какой SC дать Postgres/ClickHouse?
О: RWO-блок на быстрых дисках (Ceph RBD/локальный NVMe). Для CH — XFS, для PG — XFS/ext4. RWX/NFS — нельзя.
В: Можно ли развернуть MinIO и хранить всё там?
О: Для lakehouse/бэкапов/экспортов — отлично. Для БД и POSIX-нагрузок — нет, S3 не POSIX.
В: Стоит ли брать облачные диски или поднимать свой Ceph?
О: Для старта/малого масштаба — облачные диски. Для крупных объёмов/стоимости — свой Ceph окупается, но требует компетенций.
В: Нужен ли Retain?
О: Для критичных БД — да, чтобы удаление PVC не удалило данные. Управляйте утилизацией вручную.
В: Как избежать «мелких файлов» в S3?
О: Пишите крупными батчами (≥ 64–128 МБ), используйте compaction (Iceberg/Spark), планируйте периодические merge-задачи.
В: Можно ли расширить том без простоя?
О: Да, если SC/PVC поддерживают expansion и ФС умеет online-grow. Но протестируйте на стенде и внесите в runbook.
В: RWX нам нужен для BI?
О: Да — для общих каталогов (экспорты, статические отчёты, временные файлы), но не для БД.
В: Как снизить риск lock-in?
О: Держите данные в открытых форматах (Parquet/Iceberg), используйте CSI-стандарты, избегайте экзотических фич, имейте план миграции SC/бэкенда и репликацию бакетов.
Правильное хранилище в Kubernetes — это подбор SC/CSI под профиль I/O, разделение hot/warm/cold, дисциплина в снапшотах и бэкапах, и осознанная работа с S3 (как объектным, а не «монтируемым» POSIX). Так вы держите SLA BI/DWH, не превращая платформу в «заложника» одного бэкенда — и всегда понимаете, сколько это стоит и как оттуда выйти.
