Полный FAQ: Kubernetes для BI/DWH
Нужен ли вообще Kubernetes?
Q1. Когда k8s действительно нужен для BI/DWH?
- Когда есть несколько команд/домены данных, требующие изоляции и единой платформы.
- Когда нужен быстрый выпуск изменений (GitOps), эластичность и autoscaling.
- Когда стек гетерогенный: Kafka/Debezium, S3/Iceberg, Trino, ClickHouse, Airflow/dbt, BI.
- Когда требуется HA/DR, воспроизводимость и инфраструктура «как код».
Q2. Анти-кейс: когда не стоит?
- Один продукт, мало пользователей, фиксированные отчёты, Windows-зависимый BI.
- Нет DevOps-практик и желания их заводить.
- Жёсткие лицензии «на сокет/инстанс», которые ломают модель масштабирования.
Q3. Можно ли запускать крупные БД в k8s?
Да, только через операторы и с продуманной сториж-архитектурой:
- Postgres — Patroni + pgBackRest (PITR),
- ClickHouse — оператор (Altinity),
-
Greenplum — со специализированной автоматизацией; думайте о interconnect и локальности.
Критично: быстрый RWO-блок (NVMe/SSD), правильная раскладка по зонам и PDB/topology spread.
Q4. Если BI не контейнеризуется?
Делайте гибрид: платформа данных в k8s, BI остаётся на VM, а доступ — через internal Ingress (mTLS, IP-allowlist), SSO/LDAP общий, экспорты — в S3.
Архитектурные основы
Q5. Базовое разбиение кластера?
- Namespaces: per-team/project + data-platform (общие сервисы) + vitrines-shared (общий слой витрин).
- Node pools: stateful (БД/CH), etl (Trino/Kafka), stateless (web/BI), gpu (ML).
- Ingress: external (пользователи) и internal (BI↔платформа).
Q6. Multi-tenancy — как изолировать команды?
- ResourceQuota/LimitRange, PriorityClass.
- NetworkPolicy default-deny и точечные разрешения к DNS/S3/Trino/PG/CH.
- Пулы нод с taints/tolerations под «тяжёлые» задачи.
- Секреты и доступы сегментируйте по namespace через Vault/ESO.
Q7. Service mesh обязателен?
Нет. Он полезен для mTLS по умолчанию и L7-политик в «регулируемой» среде; в остальном достаточно Ingress + NetPol.
Хранилище и данные
Q8. RWO vs RWX и провиженеры?
- БД/CH — RWO блок (Ceph RBD / локальные NVMe).
- Общие тома (редко) — RWX (NFS/cephfs), по возможности избегайте под БД.
- Включайте WaitForFirstConsumer в StorageClass, чтобы PV создавался ближе к поду.
Q9. S3/MinIO для BI/DWH — зачем?
- Дешёвый TB-стоимость (lakehouse), версионирование, DR-репликация бакетов.
- Хранение raw/staging/curated в Parquet/Iceberg, экспорты BI, бэкапы.
Q10. Iceberg vs «просто Parquet в папках»?
Iceberg = ACID-снапшоты, эволюция схем, time-travel, меньше боли с «мелкими файлами». Требует каталог (Hive/REST) и регулярный compaction.
Q11. Бэкапы и PITR?
- PG — pgBackRest в S3 (архивация WAL), PITR учения.
- CH — clickhouse-backup в S3; restore-репетиции.
- Конфиги/манифесты — в Git (правда). Держите DR-план: backup-only / active-passive.
Стек данных
Q12. Kafka/Debezium в k8s — стабильна ли?
Да, через Strimzi. Минимум 3 брокера, TLS/ACL, корректные ретенции. Следите за slot lag в PG и за размером сегментов.
Q13. Trino или ClickHouse?
- Trino — федерация (Iceberg/S3, PG, CH…), единая SQL-точка и join’ы.
-
CH — быстрые агрегаты/высокий QPS.
На практике: Trino + CH (горячие агрегаты в CH, lakehouse в S3/Iceberg через Trino).
Q14. dbt Core в контейнерах — как вписывается?
Инкрементальные модели (merge), tests (not null/unique/relationships), exposures для BI. Запуск из Airflow/K8sPodOperator.
Q15. DQ/Lineage/Каталог — обязательно?
Да. Минимум: dbt tests + freshness. Лучше: Great Expectations/Soda + OpenLineage (Marquez/каталог) + публикация статусов в каталог.
BI-приложения
Q16. Superset/Metabase — эталонный паттерн?
- Web (2+ реплики), Redis (кэш/очередь), фоновые воркеры (Celery), БД метаданных (PG + PITR).
- Экспорт → S3 + pre-signed URL (не гоняйте гигабайты через web).
- SSO (OIDC/SAML), mapping групп → ролей. Sticky-sessions — только если без них нельзя.
Q17. Российский BI (PIX/Visiology/Модус BI)?
- Если есть контейнеры — деплой нативно.
- Если нет — гибрид: BI на VM, платформа в k8s, internal Ingress, IP-allowlist, mTLS; scheduler — один.
Q18. Как не «забить» источники коннектами из BI?
PgBouncer/лимиты Trino/CH, connection-budget в HPA/KEDA, запрос-кэш, pre-агрегации.
CI/CD и GitOps
Q19. Helm или Kustomize?
Обычно оба: Helm для приложений, Kustomize — для окружений/оверлеев. Управление — Argo CD/Flux.
Q20. Как хранить секреты и ключи?
Vault + External Secrets Operator. Никаких «секретов в YAML». Креды краткоживущие (DB engine).
Q21. Release-gates — что проверять?
Образы подписаны, скан уязвимостей, SLO зелёные, DQ/lineage зелёные, политики Gatekeeper «enforce».
Q22. С чего начать экономию?
С автоскейлинга воркеров ETL (KEDA) и стандартизации релизов через GitOps (меньше ручного, меньше простоев).
Наблюдаемость
Q23. Какие SLI/SLO для BI/DWH?
- BI availability, p95 UI;
- Trino success-rate, queued/exec time, p95;
- Freshness витрин;
- CDC lag;
- Ошибки экспортов/очередей.
Q24. Как алертить без «шума»?
Burn-rate (быстрый и тлеющий каналы), пороги для freshness/lag, SLO-дашборды «per-domain».
Q25. Логи/метрики/трейсы — сколько хранить?
- Логи: 7–14 дней горячие, 90–180 архив в S3.
- Метрики: 10–30 дней (Thanos/Mimir для долгосрочных).
- Трейсы: 1–10% семплинг, горячие 7 дней.
Надёжность и масштабирование
Q26. PDB и topology spread — для чего?
Чтобы drain/апгрейды не роняли доступность: минимум реплик остаются живы, раскладка по зонам/нодам.
Q27. Trino HA?
Workers — HPA; координатор — standby + быстрый failover. Spill — на быстрых дисках.
Q28. DR-стратегия — какая реалистична для BI?
Обычно active-passive: репликация бакетов/журналов, PG/CH реплики, разворачивание compute из Git, учения 1–4 раза в год.
Q29. Spot/Preemptible — где их можно?
Trino workers, stateless, ETL-воркеры. Не на координаторах/БД/Keeper. Держите on-demand базу + graceful shutdown.
Безопасность и соответствие
Q30. Базовый минимум безопасной платформы?
- PSA restricted, default-deny NetPol;
- Vault/ESO, подписи образов (cosign), Gatekeeper/Kyverno;
- SSO/IdP, группы → роли;
- Аудит Ingress/k8s API в SIEM;
- mTLS во внутреннем контуре (по возможности).
Q31. RLS/PII?
Делайте row-level на уровне движка (PG/CH/Trino view-policy), BI — только прокладка. PII — маски, теги в каталоге.
Экономика и сайзинг
Q32. Как прикинуть ёмкость Trino?
vCPU_need ≈ concurrency × vCPU_per_query × (1 + headroom), память — аналогично. Начать с 0.5–1 vCPU и 4–8 ГБ/запрос.
Q33. Что дороже: Ceph или S3?
TB-стоимость у S3 ниже, Ceph дороже из-за репликации ×2–3 и IOPS-профиля. Храните hot на блоке, warm/cold — в S3.
Q34. Где чаще всего «утекает бюджет»?
Малые файлы в S3 (Iceberg без compaction), избыточные логи, пересайзинг requests/limits, отсутствие spot на эластике.
Миграции
Q35. Онлайн или офлайн?
- Офлайн — просто, если есть окно простоя (часы).
- Онлайн — Debezium/logical replication (PG), replicated таблицы (CH); короткое окно cutover.
Q36. Как тестировать совместимость BI/драйверов?
Соберите пакет: коннекты PG/Trino/CH (TLS), SSO, пулы, экспорты в S3, row-policies, кэш/воркеры. Отстреляйте k6 + ваши запросы.
Q37. Rollback обязателен?
Да: Blue/Green (DNS TTL ≤ 60с), PITR, snapshot rollback (Iceberg). Чёткие триггеры отката (рост 5xx, freshness «красный»).
Команда и процессы
Q38. Минимальный штат на прод?
- Платформа/SRE (2–3),
- Data Engineers (3–6),
- DBA (1–2),
- BI Dev (1–3),
- Security (в шэринге),
-
Архитектор (part-time).
Зависит от масштаба и SLA.
Q39. Как устроить on-call?
24×7 первая линия (SRE), вторая — Data/DBA. Runbooks, MTTA ≤ 10 мин для SEV-1, пост-мортемы без поиска виноватых.
Q40. Как «держать гигиену» артефактов?
GitOps-репозитории: charts/манифесты/env, dbt/dag/DQ рядом с кодом, BI-артефакты как код (экспорт/импорт), CI-гейты на подписи/уязвимости/SLO/DQ.
Траблшутинг (короткие кейсы)
Q41. Debezium «отстаёт», WAL растёт → Увеличьте wal_keep_size, шардируйте Connect, снимите «тяжёлые» транзакции, алертите slot-lag.
Q42. Trino «в очереди» → Добавьте workers (HPA), включите spill, оптимизируйте join-порядок/статистики Iceberg.
Q43. BI 5xx/таймауты → Перенесите экспорты в фон, увеличьте таймауты Ingress/Gunicorn, проверьте пулы к метаданным/Trino.
Q44. «Малые файлы» → Поднимите batch в S3 Sink, планируйте Iceberg rewrite data files.
Q45. «Съели коннекты» → PgBouncer/лимиты Trino/CH, connection-budget на HPA/KEDA, редизайн параллелизма.
Быстрый старт (пилот за 4–6 недель)
- Платформа: k8s-кластер, MinIO (S3), Trino, Postgres/ClickHouse, Airflow, Superset, Strimzi.
- Безопасность/сеть: SSO (OIDC), два Ingress (ext/int), Vault/ESO, NetPol default-deny.
- Данные: CDC → S3 → Iceberg → Trino, dbt (1–2 модели).
- DQ/Lineage: dbt tests + OpenLineage/каталог, freshness-SLI.
- Наблюдаемость: kube-prom-stack, SLO BI/Trino/CDC.
- BI: 1–2 дашборда по витрине, экспорты в S3.
- Гейты и релизы: GitOps, canary, DQ/SLO gates.
- Учение: drain ноды + проверка SLO.
Мини-глоссарий
- Lakehouse — S3 + табличный формат (Iceberg) + движок (Trino/CH).
- Compaction — укрупнение «мелких файлов» Parquet/Iceberg.
- PITR — восстановление БД «на момент времени».
- PDB — бюджет нарушений при drain/апгрейде.
- Burn-rate — скорость «съедания» SLO-бюджета ошибок.
- ADR — зафиксированное архитектурное решение «на одной странице».
Целесообразность и стратегия
В1. Когда Kubernetes для BI/DWH оправдан, а когда нет?
Да: гетерогенный стек (Kafka/ETL/Trino/BI), частые релизы, пиковая нагрузка, требования к изоляции и SSO/аудиту, мульти-командная разработка.
Нет: маленький масштаб (1–2 сервиса с редкими изменениями), жёсткий Windows-стек, монолитные лицензии «per-VM», отсутствует DevOps-процесс.
Чек-лист: TCO/ROI, кадры и процессы, требования SLO/DR, частота релизов, вендорская поддержка контейнеров.
В2. С чего начинать обоснование (бизнес-кейс)?
Сформулировать целевые SLO (доступность, p95 BI-запросов), оценить стоимость текущей эксплуатации, спрогнозировать экономию от автоскейлинга/стандартизации релизов и риски миграции. Результат — таблица критериев и скоринговая матрица «использовать/не использовать».
В3. Что взять пилотом?
Минимальную ценность: ETL/CDC → S3 → Trino → BI на одной витрине + безопасная публикация (Ingress/SSO) и наблюдаемость. Это создаёт основу для масштабирования без «переваривания всего мира».
Архитектура Kubernetes «изнутри»
В4. Какие узкие места control plane?
etcd (IOPS/latency), перегруженный apiserver (бурст job/cron), валидирующие вебхуки. Митигируйте: быстрые диски под etcd, лимитируйте контроллеры, не ставьте критичные вебхуки с failurePolicy=Fail без плана B.
В5. Как читать «здоровье» кластера?
Дашборды: apiserver (RPS/latency/5xx), scheduler (подбор нод), kubelet (evictions), etcd (fsync/leader). Логи ошибок + события kubectl get events --all-namespaces --sort-by=.lastTimestamp.
В6. Где чаще всего «стреляет» при апгрейдах?
Устаревшие API (Ingress/CronJob), несовместимые вебхуки, CNI/Ingress-контроллеры. Используйте kubent/Pluto, стенд-канарею, поэтапный апгрейд: control plane → CNI/CSI/Ingress → ноды → приложения.
Сеть и публикация
В7. Ingress или Gateway API?
Ingress — зрелый базовый вариант. Gateway API — более выразительный L7 (раутинг/политики) и будущее стандарта. Выбирайте по экосистеме контроллера и требованиям L7.
В8. Нужен ли сервис-меш?
Если требуются сквозной mTLS, тонкий L7-контроль, канареечные маршруты «по заголовкам», трейсинг без переписывания приложения — да. Если у вас «простая» публикация BI и несколько API — начните с NetworkPolicy + Ingress.
В9. Как ограничить egress?
Default-deny на egress + FQDN-политики (Cilium/Istio EgressGW) или шлюз-прокси. В «строгих» средах — allow-list доменов, аудит исходящих соединений.
Хранилища и данные
В10. RWO против RWX для stateful?
Для БД/ClickHouse — RWO-блок (Ceph RBD/облачный диск); RWX/NFS оставьте под общие файлы/экспорты. Риск RWX для БД — блокировки и деградация I/O.
В11. Где хранить «тёплые/холодные» данные?
Горячее — на локальных/NVMe (spill/кэши/оперативные партиции), тёплое/холодное — S3/MinIO (Iceberg/TTL в CH). Разгрубляйте класс хранилища — это главный рычаг стоимости.
В12. Как организовать бэкап/restore?
Системный слой (Velero/Stash) + «нативные» инструменты БД (pgBackRest/WAL-G/clickhouse-backup). Главное — ежемесячный день восстановления (не только бэкап) и документированный RPO/RTO.
В13. PITR для Postgres и «каталоги» для таблиц на S3?
PG — WAL в S3 и PITR до T-момента. Для S3-таблиц — Iceberg/Hudi/Delta + метакаталог (Hive/Glue-аналог); бэкап и консистентность каталога — обязательны.
Безопасность
В14. С чего начать hardening?
Пакет на namespace: Pod Security (baseline/restricted), NetworkPolicy default-deny, ResourceQuota/LimitRange, аудит. Дальше — Kyverno/Gatekeeper: запрет :latest, обязательные ресурсы, минимум-прав в RBAC.
В15. Как правильно работать с секретами?
External Secrets Operator / Secrets Store CSI + Vault/IdP с короткими TTL. Запрет на секреты в ConfigMap/env-дампы, аудит «кто и что читал».
В16. SSO/группы/SCIM — must-have?
Да, для BI/каталогов — иначе ручной зоопарк пользователей. Требуйте OIDC/SAML + SCIM (или регулярный групповый импорт).
В17. Как защититься от supply-chain рисков?
Подписи образов (cosign), SBOM, скан уязвимостей в CI, политический гейт на кластер («только подписанные/из утверждённых реестров»).
Наблюдаемость и SLO
В18. Какие SLI/SLO выбирать для BI?
Доступность портала, p95 времени построения отчёта, процент успешных рассылок, p95 latency запросов к DWH, error rate коннекторов. SLO задайте с бюджетом ошибок и burn-rate алертами (быстрый/медленный канал).
В19. Что логировать?
Всё в stdout/структурный JSON. Ключевые поля: tenant/user, query_id, источники/фермы, latency, размер ответа. Хранение логов — с ретеншном и фильтрацией PII.
В20. Как «поймать» деградации?
Алерты на HPA=max, OOM/eviction, throttling, рост p95, ошибки TLS/Ingress, deny по NetworkPolicy. Сшивайте трейсы (ОТЕЛ) между BI → Trino/БД.
GitOps и CI/CD
В21. Зачем GitOps, если и так «работает»?
Предсказуемость, откаты, аудит, средовая промоция Dev→Stage→Prod, единые артефакты (Helm/Kustomize). Без GitOps вы не стабилизируете релизы и апгрейды.
В22. Helm или Kustomize?
Helm — как пакетный менеджер (чарты, зависимостя). Kustomize — удобные оверлеи окружений. На практике часто Helm-чарт + Kustomize-оверлеи.
В23. Как деплоить безопасно?
Стратегии rolling/canary/blue-green, SMOKE-тесты, политики admission, подписи образов, «break-glass» процесс (временный ручной фикс + обязательный PR).
Stateful: Postgres/ClickHouse/Greenplum
В24. Реально держать Postgres в k8s?
Да, с Patroni/pgpool (или оператором), RWO-томами, PITR, PDB/anti-affinity и быстрыми дисками. Не кладите WAL/journal на RWX/NFS.
В25. ClickHouse: основы эксплуатационной схемы?
Оператор, топология shards × replicas, Keeper, hot на RWO, S3-tiering + TTL, матвью. Следите за merges/replication queue; лимитируйте BI и ETL.
В26. Greenplum: на что смотреть?
Плейсмент сегментов по зонам (anti-affinity/topology spread), быстрый interconnect, мониторинг skew/очередей, PITR/restore по схеме. ETL и BI — в разные окна/пулы.
BI-приложения
В27. Какие типовые «болячки» BI в k8s?
Шторм соединений к DWH, тяжёлые запросы без лимитов, рассылки «убивают» SMTP/файловую подсистему, устаревшие драйверы. Лечение: пулы/квоты/таймауты, кеширование, лимиты экспорта, фиксированные версии драйверов.
В28. SSO и разграничение в BI?
SSO (OIDC/SAML), маппинг групп→ролей, RLS/CLS на уровне источников. Не храните локальных пользователей в BI в проде.
В29. Как публиковать BI наружу?
Ingress с HTTPS и WAF-правилами, ограничение IP/Geo, мТLS для внутреннего трафика, отдельный домен/IngressClass, контроль экспорта файлов в S3.
Российские решения и гибрид
В30. BI-продукт не контейнеризуется — что делать?
Гибрид: data-платформа в k8s (ETL/S3/Trino/БД), BI — на VM рядом. Интеграция: SSO, драйверы, публикация через Ingress, egress-Правила, файловые экспорты в S3.
В31. На что спрашивать у вендора?
Helm/оператор, работа без root/privileged, SSO и SCIM, Prometheus-метрики, поддержка cert-manager, матрица совместимости k8s/CNI/Ingress/DB, офлайн лицензии.
Многопользовательность и изоляция
В32. Как изолировать команды?
Namespace-на-команду, Quota/LimitRange, default-deny NetworkPolicy, отдельные пулы нод для тяжёлых задач (в т.ч. GPU), разделение секретов/ролей.
В33. Общие витрины при изоляции?
Выделенный «read-only» слой (Trino/прочие), публикация через стабильные Service/Ingress, контроль прав на уровне источников и ролей BI.
Надёжность, DR и апгрейды
В34. Что обязательно для HA?
PDB, anti-affinity/TopologySpread, мульти-AZ, readiness/startup пробы, отказ от локальных зависимостей на одной ноде, регулярные chaos-дриллы.
В35. DR: backup-only или active-passive?
Начните с backup-only (проста и дёшево), добавьте active-passive, если SLO требуют короткий RTO. Документируйте последовательность восстановления по слоям (секреты→каталоги→данные→приложения).
В36. Как безопасно обновлять кластер?
Инвентаризация API/операторов, канареечные ноды, «развязать» вебхуки, поэтапно апгрейдить и держать rollback-план. Smoke-набор BI обязателен.
Экономика, сайзинг и автоскейлинг
В37. Как считать TCO?
Ноды (on-demand/spot), хранилище (блок/S3), трафик, лицензии, человеко-часы, простои. Сценарии: «как есть», «k8s минимальный», «k8s с оптимизациями». Покажите ROI на год+.
В38. Какие быстрые рычаги экономии?
Правильные requests (по p50–p70), HPA/VPA, spot-пулы для эластичных воркеров, ретеншн логов/экспортов, tiering в S3.
В39. Риски автоскейлинга?
Over-/under-provision, OOM при пиках, прерывания spot. Снимайте: профилирование, PDB/terminationGracePeriod, «шторм-защита» (коннекты/квоты).
Качество данных и каталог
В40. Как построить DQ/lineage?
Great Expectations/dbt tests в пайплайнах; OpenLineage/Marquez для lineage; публикация статусов в каталог; алерты на провал DQ-чеков.
В41. Роли и ответственность?
Стюарды/владельцы датасетов, SLA витрин, RACI в инцидентах (кто чинит ETL, кто оптимизирует запросы, кто масштабирует инфраструктуру).
Миграция в k8s
В42. С чего начать перенос?
Инвентаризация, контейнеризация «обвязки», перенос без state (stateless/BI-шлюз/Ingress), затем stateful (БД/CH/GP) при готовности операторов и хранилищ. Мини-миграция: одна витрина + отчёты.
В43. Как тестировать производительность?
Нагрузочное k6/JMeter для BI, synthetic SQL для DWH, сравнение p95/p99 до/после, профилирование дисков/сети. Фиксируйте драйверы/версии.
В44. Как обеспечить обратимость?
План rollback, параллельный контур (blue/green), freeze-окно на изменения схем, миграции через Liquibase/Flyway с откатами.
Автоматизация и API
В45. Чем автоматизировать рутину?
GitOps как основа, Terraform для кластеров/сетей, Ansible для ОС-подготовки, Python/client-go для операционки (генерация манифестов, отчёты). В проде — минимум «живого kubectl».
В46. Где нужна «своя логика»?
Повторяющиеся процедуры (массовые PVC/секреты, бэкап-каталоги) и объединение данных мониторинга — в маленькие сервисы/операторы (с лимитами и аудитом).
Анти-паттерны и диагностика
В47. Топ-5 «красных флагов»?
:latest, нет requests/limits, данные в emptyDir/RWX для БД, плоская сеть без NetworkPolicy, ручные kubectl edit в проде.
В48. Почему «всё зелёное», а пользователи жалуются?
Мониторинг не покрывает бизнес-SLI. Добавьте p95 отчётов, успех рассылок, глубину очередей, HPA=max, TLS-ошибки, трейсинг.
В49. Медленные запросы — где копать?
Сначала воспроизведите SQL вне BI; проверьте план/индексы/партиции; измерьте диски/сеть; проверьте пулы/таймауты/кэш BI; убедитесь, что ETL не съедает I/O параллельно.
Организация и команда
В50. Какая минимальная команда и навыки?
Платформенная (SRE/DevOps), DBA, Data Engineer/Orchestrator, BI-разработчик, Sec/Observability. Для малого масштаба роли совмещают, но runbook/playbook/политики обязательны.
В51. Как развивать команду 3–6 месяцев?
0–1 мес: база/гигиена (NS-пакет, GitOps, SSO, мониторинг). 2–3 мес: безопасность/политики, autoscaling, SLO. 4–6 мес: DR-дриллы, расходная оптимизация (spot/tiering), кейсы CH/GP.
Быстрая шпаргалка «правила большого пальца»
- Для БД/CH — только RWO-блок, S3 для тёплого/холодного.
- Везде requests/limits; включите VPA (recommend).
- Сеть: default-deny + egress-контроль.
- GitOps-«религия», без ручных правок в проде.
- SSO/SCIM, короткие токены, Vault/ESO.
- SLO на бизнес-метрики, burn-rate алерты.
- DR не существует без restore-дня.
- Экономия начинается с профилирования + autoscaling + tiering.
