Модуль 14. Миграция на k8s: пошаговый план

Что считаем успехом

Витрины и BI работают с теми же или лучшими SLO (доступность, p95 латентность, свежесть).
Есть обратимость: понятный rollback, проверенный PITR/восстановление.
Эксплуатация — как код (GitOps, секреты, политики), наблюдаемость включена с первого дня.
Команды знают роли (Owner/Steward/On-call), cutover прошёл без сюрпризов.

Дорожная карта миграции (фазы)

Инвентаризация и целевая архитектура
Потоки данных, критичность, RTO/RPO, зависимости (SSO, SMTP, каталог, файлы, сети).
Подготовка платформы
Кластер, storage, сетевые контуры, безопасность (PSA/RBAC/NetworkPolicy), GitOps, observability.
Контейнеризация/подготовка сервисов
BI, оркестратор, коннекторы, Trino/ClickHouse/PG, вспомогательные (Redis, pgBouncer, MinIO).
Перенос данных (онлайн/офлайн)
Бэкап/restore, logical replication/CDC, валидация.
Совместимость BI/драйверов/SSO
Тесты коннекторов, кэш/пулы, отчётные кроны, экспорт в S3.
Производительность
Бейзлайн, нагрузочные прогоны, SLO-гейты.
Cutover и стабилизация
Подробный план переключения, «горячая смена», гиперкэр, критерии успеха/rollback.

Инвентаризация: что собрать «на берегу»

Каталог систем и потоков

Источники: OLTP БД (версия, объёмы, WAL/журналы), файлы.
Слоё вой: staging/curated/marts, объёмы TB (hot/warm/cold).
BI: список дашбордов/подписок/экспортов, уязвимые отчётные окна.
Интеграции: SSO/LDAP, почта, вебхуки, data catalog, OpenLineage.
Сети: подсети, ACL, DNS, требуемые FQDN/TLS.

Критичность и цели

Для каждого домена — RTO/RPO, окна изменений, SLA витрин (свежесть/точность/доступность).
Матрица «что переносим в k8s, что оставляем на VM» (см. Модуль 9 — гибриды).

Артефакты: диаграмма потоков L3/L7, инвентарь таблиц/витрин, матрица доступов, список SLO.

Платформа и «готовность к посадке»

Storage: блок (Ceph/локальные NVMe) для БД и ClickHouse, S3/MinIO для lakehouse/экспортов. RF/ретеншн — согласованы (Модуль 12).
Сеть: два Ingress-контроллера (external/internal), default-deny egress, whitelist для BI/VM.
Безопасность: PSA restricted, Gatekeeper/Kyverno политики, External Secrets + Vault, подписи образов (cosign).
GitOps: Argo CD/Flux, разделение app-repo/env-repo (Модуль 6).
Наблюдаемость: kube-prometheus-stack, Loki/EFK, OpenTelemetry (lineage/DQ см. Модуль 13). SLO-дашборды готовы.

Критерий готовности: чек-лист платформы «зелёный», есть тестовые неймспейсы и pipeline «hello-world».

Контейнеризация: что переносим и как

Паттерны

Нативно-контейнерные: Trino, Airflow, Superset/Metabase, Redis, MinIO — через Helm/операторы.
СУБД: Postgres Pro (Patroni+pgBackRest), ClickHouse (operator). Для критичных нагрузок — отдельный пул нод.
BI-вендоры (PIX/Visiology/Модус BI): если есть образы — lift-and-shift; если нет — оставляем на VM и строим гибрид (см. Модуль 9).

Технические требования

Requests/Limits и health-пробы; Log/metrics endpoints; конфиги через ConfigMap/Secret; секреты из Vault (ESO).
Пулы соединений (pgBouncer), лимиты к Trino/ClickHouse; экспорт в S3 с pre-signed ссылками.

Артефакты: Helm values/Kustomize overlays, SSO/Ingress конфиг, NetworkPolicy.

Перенос схем и данных: онлайн vs офлайн

Офлайн (простая остановка)

Подходит при доступном окне простоя (часы).
1. Freeze записей → 2) Бэкап (pgBackRest/снапшот CH/экспорт S3) → 3) Restore в k8s → 4) Smoke-тесты → 5) Cutover.
Риски: затянувшееся восстановление, ошибки совместимости версий.

Онлайн (минимальный простой)

Postgres: logical replication/pglogical или Debezium CDC.
Шаги: snapshot → запуск репликации → догоняем лаг → короткое окно cutover (секунды/минуты).
ClickHouse: реплицируемые таблицы; временно включаем dual-write/replicated MergeTree и свитч читающих клиентов.
Lakehouse (S3+Iceberg): переезд каталога и бакетов (или репликация бакетов), rebuild метаданных, проверка snapshot lineage.

Валидация данных

Счёт строк (row count), контроль сумм по ключевым полям, spot-checks, контроль распределений; DQ (GE/dbt tests) — до публикации.
Для PG: сравнение хэш-агрегатов md5(array_agg(...)) на выборках; для Iceberg — сверка snapshot-ID и counts.

Важно: следите за WAL/slot lag (при logical rep), чтобы не «забить» диск источника.

Совместимость BI/драйверов и SSO

Драйверы: версии JDBC/ODBC к Postgres/Trino/ClickHouse на новой стороне, TLS/mTLS, параметры таймаутов.
SSO: OIDC/SAML; группы ↔ роли; при «на краю» — корректная передача заголовков (ingress annotations).
Пулы и таймауты: BI pool_size ≤ лимитов pgBouncer/Trino; почтовые/экспортные задачи вынесены в фоновые воркеры.

Тест-пакет: интерактивные дашборды, SQL Lab/ад-hoc, рассылки, экспорты (в S3), row-level политики (если есть).

Производительность и SLO-гейты

Бейзлайн до миграции

Снимите текущие p95 latency BI/API, success-rate, Trino queued/exec time, свежесть витрин, pg/CH топ-запросы.

Прогоны на новой стороне

BI: k6 (профиль RPS и пользовательских сценариев), SLO: p95 ≤ X с, errors < 1%.
SQL: TPC-DS/TPC-H «как якорь» + ваши 20–30 репрезентативных запросов (включая тяжёлые join/agg).
ETL: DAG-окна и SLA; backfill’ы отдельно.

Гейты

Если любой из SLO «красный» — не промотируем на Stage/Prod (блок GitOps PR).

Обратимость и rollback

Blue/Green: старая и новая площадки живут параллельно; переключение через DNS/Ingress route, TTL DNS ≤ 60 сек.
Данные: PITR (PG/CH), Iceberg snapshot rollback; при онлайн-миграции — «write-stop» на старую сторону во время финального свитча.
Триггеры отката: рост 5xx/latency > X мин, падение свежести, деградация коннекторов, недоступность SSO/BI.

Runbooks: «возврат DNS», «restore PITR на t-1», «откат чарта/версии образа».

План cutover (по минутам)

Freeze изменений (оцените «сколько»), отключить отчётные heavy-jobs/экспорты.
Финальная синхронизация (онлайн — догон lag=0; офлайн — восстановление завершено).
Smoke-тесты чек-листом: SSO, основные дашборды, SQL Lab, экспорт в S3, рассылки.
Переключение трафика (DNS/Ingress), мониторинг пиковых SLI 30–60 мин.
Гиперкэр: усиленный on-call 24–72 ч, сводка по инцидентам/улучшениям.
Вывод старой площадки в read-only → деcommission по плану.

Роли: Change manager, Incident commander, DB lead, BI lead, Network/Sec, Comms (уведомления).

Риски миграции и как их снимать

Риск	Проявление	Митигировать
Неучтённые интеграции	BI/каталог/почта не работают	Полный инвентарь, тест-кейсы на все внешние точки
WAL переполнен при logical rep	Исходная БД «встаёт»	Мониторинг slot lag, увеличение wal_keep_size, быстрый коннектор
Драйверы не совпадают	Ошибки коннекта/SSL	Матрица совместимости, тесты с реальными версиями
Перенос схожих, но разных схем	BI падает на запросах	Контракты схем (expand/contract), dbt tests, выкат совместимый
SLO «просел» после свитча	Рост жалоб	Canary/Blue-Green, быстрый rollback, capacity headroom
Нет DR-плана	Нет восстановления	Прогон DR (restore + приложения), документированный RTO/RPO
«Ручной» cutover	Человеческий фактор	Скриптованный план, контрольные точки, dry-run на Stage

Мини-фрагменты (ровно сколько нужно)

Postgres: офлайн перенос (snaphot → restore → cutover)

pgBackRest backup → restore в k8s → ANALYZE → smoke-тесты → BI переключение.

Postgres: онлайн через logical replication (упрощённо)

На источнике: включить wal_level=logical, создать публикацию.
На целевом: подписка + первичная загрузка → догон lag → короткий write-freeze → свитч клиентов.

ClickHouse: создать ReplicatedMergeTree таблицы, включить репликацию между кластерами, свитч ридеров.

(Полные команды и скрипты держите в runbook’ах; здесь — контрольные точки.)

Практика: мини-миграция «Витрина + BI-дашборды»

Исходные данные

Витрина marts.sales.fct_orders в Postgres/ClickHouse, 300 ГБ; 5 дашбордов в BI; SLO свежесть ≤ 60 мин.
Новая платформа в k8s: Postgres/ClickHouse/Trino, Superset/Metabase, MinIO, Airflow, GitOps, observability.

Шаги

Инвентарь и SLO: зафиксировать список дашбордов, пользователей, рассылок; измерить текущие p95/успехи.
Платформа: развернуть целевые компоненты, завести namespace bi-pilot, включить SSO/NetworkPolicy/ESO.
Данные:
- PG: logical replication публикует fct_orders; CH: реплика/копия таблицы.
- Проверка: row count, контроль сумм, ключей, выборочные сверки.
BI: поднять экземпляр в bi-pilot, импортировать объекты (дашборды), переключить датасеты на новую витрину (или на Trino).
Нагрузка: прогнать k6 по BI и SQL-набор на витрину; сравнить с бейзлайном.
Cutover:
freeze рассылок;
свитч DNS/Ingress для 1 пилотной группы пользователей;
1–2 часа наблюдения;
полное переключение.
Гиперкэр: 48 ч; включить burn-rate алерты на BI/коннекторы, freshness витрины.
Документация: lineage (OpenLineage), каталог обновлён (owner/steward, описание), runbook’и обновлены.

Критерии приёмки

SLO: p95 UI ≤ целевого, errors < 1%, свежесть ≤ 60 мин, no data loss.
DQ (unique/not null/FK) — зелёные.
В каталоге виден lineage и статус качества.
Rollback — проверен на Stage (dry-run) и выполним ≤ 15 мин.

Артефакты

План миграции (по минутам) и «Go/No-Go» чек-лист.
Отчёт сравнения производительности (до/после).
Док-файлы: схемы, роли, SSO-мэппинг, NetworkPolicy, Helm values.
Отчёт по инцидентам/улучшениям за гиперкэр.

Чек-лист «готово к cutover»

Платформа готова: Storage, Ingress, Security, GitOps, Observability.
Контейнеризация завершена, образы подписаны, политики «enforce».
Стратегия переноса данных выбрана; выполнены тестовые restore/replication; DQ зелёный.
BI/драйверы/SSO протестированы; пуллинги/лимиты согласованы (pgBouncer/Trino/CH).
Нагрузочные тесты пройдены; SLO-гейты «зелёные».
Cutover-план, роли и каналы связи определены; DNS TTL снижен.
Rollback-план проверен (PITR/blue-green); решены триггеры отката.
Документация/каталог/lineage обновлены; runbook’и на инциденты готовы.
Согласовано окно работ с бизнесом; рассылки/экспорты спланированы.

Миграция на k8s — это инженерная дисциплина: инвентаризация → платформа → контейнеризация → перенос данных (с валидацией) → проверка совместимости BI → производительность и SLO-гейты → обратимость → cutover. Если всё оформлено «как код» и отработано на пилоте, переход превращается из «большого взрыва» в контролируемую серию коротких шагов с предсказуемым результатом.

← Предыдущая статья

Модуль 13. Данные, качество и каталог

Следующая статья →

Модуль 15. Команда, роли и процессы