Модуль 9. Российские решения: варианты развертывания и интеграции
Что решаем и как не «перетянуть одеяло»
Задача — обеспечить управляемость, масштабируемость и безопасность BI/DWH, не ломая то, что уже работает. Поэтому:
- если вендор даёт контейнеры — используем нативный деплой в k8s;
- если контейнеров нет — оставляем продукт на VM, а data-платформу (Kafka/Airflow/Trino/ClickHouse/Postgres/MinIO) ведём из k8s и аккуратно обвязываем BI;
- если нужны строгие периметры — строим гибрид с двумя Ingress-контроллерами (внутренний/внешний), mTLS и «default-deny» политиками.
PIX BI, Visiology, Модус BI — три пути интеграции
Вариант A: нативные контейнеры (если есть)
Когда выбирать: вендор поддерживает образы/чарты, совместимы с вашей версией k8s, есть инструкция по внешним зависимостям.
Паттерн:
- Web/UI — Deployment; метаданные/конфиги — внешняя БД (Postgres/MySQL на StatefulSet или управляемый кластер).
- Публикация — Ingress/Gateway с TLS, SSO (OIDC/SAML, на краю или нативно).
- Логи/метрики — Sidecar/экспортеры в Loki/Prometheus.
- Экспорты — в S3/MinIO (pre-signed URLs), а не через HTTP-ответ BI.
На что смотреть у вендора:
- поддерживаемые ОС/архитектуры, требования к kernel features, способ хранения метаданных, наличие «single scheduler» для рассылок, sticky-sessions, схема лицензирования в k8s.
Вариант B: VM рядом с кластером (часто — сегодня)
Когда выбирать: контейнеров нет, требуется Windows/особые драйверы, сложные лицензии на «сервер/сокет».
Паттерн:
- BI на VM/в шине виртуализации (отдельный VLAN/подсеть).
- Ingress (внутренний) публикует Trino/ClickHouse/Postgres из k8s для BI-VM по mTLS и IP-allowlist.
- Egress из BI-VM к S3/MinIO (для экспортов) и к API оркестрации (Airflow DAG trigger) через выделенный шлюз.
- SSO — общий IdP (Keycloak/ADFS), единые группы/роли в BI и в кластере.
Вариант C: гибрид (BI вне k8s, data-платформа внутри)
Когда выбирать: быстрый выигрыш в управляемости данных без миграции BI.
Паттерн:
- В k8s: Kafka/Debezium, Airflow, Trino, ClickHouse, Postgres Pro, MinIO, каталог/MDM.
-
BI снаружи ходит:
- к витринам Postgres/ClickHouse/Trino (ClusterIP→Ingress internal),
- в S3 за файлами,
- в IdP за токенами.
- Сетевая «клетка»: NetworkPolicy default-deny, отдельный ingressClass для «internal», mTLS на бэкенд-сервисы, IP-allowlist для BI-адресов.
Общие интеграционные точки для всех трёх продуктов:
- SSO: OIDC/SAML, мэппинг групп на роли (через заголовки на краю или нативно).
- Доступ к источникам: Trino/ClickHouse/PG — по FQDN через internal-Ingress, ограничение по IP/сертификату клиента.
- Экспорты: всегда старайтесь писать в S3/MinIO + отдавать ссылку; лимитировать размер/TTL.
- Квоты: бюджет соединений к источникам (pgBouncer/Trino limits), ограничения размеров и времени выполнения.
Arenadata в k8s: ADQM/ADPG/каталог данных
ADQM (как правило ClickHouse-совместимый OLAP)
- Деплой: оператор (или Helm), шардирование/репликация, StatefulSet, RWO-хранилище с высокой IOPS.
- Интеграция: Trino-каталог clickhouse/jdbc, BI — прямое подключение или через Trino.
- Хранилище: локальные NVMe для MergeTree и журналов; S3 — для бэкапов/архивов.
- Наблюдаемость: system.metrics, query_log → Prometheus/Loki.
ADPG (Postgres-совместимая СУБД)
- HA-паттерн: Patroni + pgBackRest/WAL-архив в S3 (см. Модуль 2).
- CDC: Debezium (logical replication).
- BI-доступ: через pgBouncer, read-replicas для отчётной нагрузки.
Arenadata Data Catalog
-
Паттерн приложения «web + БД + поиск/очередь»:
- Web — Deployment,
- БД — Postgres (StatefulSet/оператор),
- Поиск — OpenSearch/Elasticsearch (оператор),
- Очередь — Kafka/RabbitMQ (оператор).
- SSO/LDAP: встраивается через OIDC/SAML или LDAP-биндинг, роли и зоны доступа (domain/collection level).
- Публикация: Ingress с TLS, метод-уровневые лимиты, IP-allowlist для внешних интеграций.
Postgres Professional на k8s: StatefulSet-паттерны и аналитика
Базовая схема
- Patroni (лидер/реплики) + pgBackRest/WAL-G для PITR, pgBouncer для пуллинга.
- Хранилище: RWO блок (Ceph RBD/локальные NVMe), отдельный pool под WAL, WaitForFirstConsumer в StorageClass.
Под аналитические нагрузки
- Partitioning по дате/ключу (native/pg_partman), индексы BRIN/BTree по профилю запросов.
- Конфиг: work_mem, maintenance_work_mem, параллелизм (max_parallel_workers_per_gather), effective_cache_size — по измерениям.
- Витрины: материализованные представления с расписаниями (refresh в off-peak); BI — в read-реплики.
- CDC: logical для Debezium, контроль replication slot lag (алерты).
Каталоги и MDM в k8s: Arenadata DC, «Гармония MDM»
Типовая архитектура (подойдёт для обоих)
- Web/API — Deployment с readiness/liveness, HPA по CPU/RPS.
- База метаданных — Postgres (StatefulSet), PITR;
- Поиск — OpenSearch (оператор), кластер 3 ноды;
- Очередь — Kafka/RabbitMQ (оператор) при наличии событийной модели;
- SSO/LDAP — централизованно через IdP; разграничение по ролям (администратор каталога/стeward/читатель).
- Логи/метрики — Prometheus/Loki; бизнес-аудит отдельно (в SIEM, не терять!).
Обмен с DWH
- API: REST/gRPC для CRUD метаданных/заявок/глоссария.
- Стримы: Kafka-топики для событий (изменение справочника, утверждение записи).
- Пакеты: выгрузки CSV/Parquet в S3, триггеры на обновление витрин.
- Гармонизация данных (MDM): golden record + публикуемые справочники как «read-only» источники для витрин (через Postgres/Trino).
Сети, безопасность, секреты — что общее для всех
- Два Ingress-контура: external (строгий WAF/SSO, IP-allowlist), internal (для VM-BI, админок и интеграций).
- NetworkPolicy: в каждом namespace — default-deny, дальше точечно DNS/БД/S3/IdP/SMTP.
- mTLS: внутри кластера — сервис-меш (Linkerd/Cilium mesh) для шифрования трафика без ручной криптографии.
- External Secrets + Vault: секреты вне кластера, в k8s только синхронизация; по возможности динамические креды (DB engine).
- Подписи образов (cosign) и политика допуска (Kyverno/Gatekeeper).
- Аудит: K8s audit policy, логи доступа Ingress, бизнес-аудит приложений (каталог/MDM/BI) в отдельный индекс.
Практика: спроектировать 2 архитектуры и контуры безопасности
Архитектура 1: BI в k8s
Цель: контейнеризованный Superset/Metabase/российский BI (если вендор даёт образы) + data-платформа в том же кластере.
Обязательные элементы:
- Namespace bi (PSA: restricted), Deployment BI (web), Redis (кэш/очередь, если нужно), Postgres для метаданных (StatefulSet).
- Ingress external + internal, TLS от cert-manager, SSO (OIDC), WAF (detect→tune→block).
- NetworkPolicy: default-deny, разрешения к Trino/ClickHouse/PG/MinIO/SMTP/IdP.
- Экспорты в S3, pre-signed ссылки, лимиты размеров.
- HPA web по CPU/RPS и KEDA для воркеров (если есть очередь).
- Наблюдаемость: SLO BI (availability/latency), очереди, пулы коннектов.
Артефакты, которые сдаём:
- Диаграмма L3/L7 (кто с кем и как), список DNS/FQDN, сертификаты и жизненный цикл.
- Матрица RBAC/SSO групп → роли BI.
- Схема пулов соединений и «бюджеты» (BI→Trino/PG/CH).
- Политики NetworkPolicy и список открытых наружу эндпоинтов.
- План DR: бэкапы метаданных, RPO/RTO, тест восстановления.
Критерии готовности: p95 UI < 2.5s в час-пик, ошибки < 1%, отчётные задачи не на web, PITR ок.
Архитектура 2: BI вне k8s, data-платформа в k8s (гибрид)
Цель: BI остаётся на VM, внутри k8s — Kafka/Debezium, Airflow, Trino/ClickHouse/Postgres, MinIO, каталог/MDM.
Обязательные элементы:
- Внутренний Ingress для Trino/ClickHouse/PG/MinIO, mTLS и IP-allowlist только для адресов BI-VM.
- NAT/Firewall-правила между подсетями, запрет egress из k8s «во внешний интернет» (кроме IdP/SMTP/внутренних репозиториев).
- SSO единый на оба мира; BI использует сервисный аккаунт/группы для подключения к источникам.
- Экспорт из BI → S3; BI-агенты (если есть) — в k8s запрещены.
- Мониторинг «сквозного» пути (Ingress↔Trino/PG/CH, лаг CDC, freshness витрин, BI availability via synthetic checks).
Артефакты:
- Карта потоков данных (от OLTP до витрины и BI), SLO на каждый участок.
- Таблица портов/сетей/сертификатов, перечень «точек правды» (S3/каталоги/MDM).
- Чек-лист ручек BI, которые запрещены снаружи (админка, загрузки).
- Runbook «BI недоступен, платформа жива» и наоборот.
Критерии готовности: BI видит только нужные сервисы, все каналы шифрованы, «провал» одной стороны не тянет за собой вторую.
Чек-листы вопросов к вендорам (универсальные)
Для BI (PIX/Visiology/Модус BI/и др.)
- Контейнеры: есть ли официальные образы/чарт, поддерживаемые версии k8s/ОС? rootless? как обновляются?
- Лицензии: модель привязки (хост/ядро/пользователь), влияние k8s (горизонтальное масштабирование, ephemeral ноды).
- Хранилище: где и как хранятся метаданные/кэш/файлы? поддержка S3? рекомендуемый объём/IOPS?
- SSO: OIDC/SAML? Передача групп? Маппинг ролей? Есть ли SCIM?
- Сессии/липкость: нужны ли sticky-sessions? Есть ли выделенный планировщик (single scheduler)?
- Экспорт/отчётные задачи: как гарантировать «одиночность» выполнения при нескольких репликах? есть ли API для внешнего оркестратора?
- Мониторинг/логи: экспорт метрик в Prometheus? формат логов? трассировка?
- Безопасность: поддержка mTLS к источникам, загрузка кастомных CA, политика TLS, хардненг.
- Сетевые зависимости: SMTP/LDAP/внешние API? порты/протоколы?
- Импорт/экспорт конфигурации и дашбордов: есть ли способ «как код»?
Для MDM/Каталога (Arenadata DC, Гармония MDM)
- Роли и домены данных: можно ли ограничивать доступ до атрибута/домена? аудит?
- Интеграции: REST/gRPC/стримы? Подпись вызовов, версия API, платформенные SDK?
- Согласования/workflow: можно ли «автоматизировать» через вебхуки?
- Производительность поиска: требования к OpenSearch/Elasticsearch, размер индексов/ретеншн.
- Миграции версий: backward-compatible? инструменты экспорта настроек?
Для Arenadata (ADQM/ADPG)
- Операции в k8s: рекомендуемые ресурсы/узлы, operator maturity, бэкапы/DR поддержкой инструмента.
- Совместимость с Trino/BI: драйверы/SQL-диалект.
- Наблюдаемость: список метрик, логов и готовых дашбордов.
Риски и что делаем заранее
|
Риск |
Где болит |
Что делаем |
|---|---|---|
|
BI требует Windows/несовместим с контейнерами |
Деплой |
Оставляем BI на VM, строим гибрид. Проверяем агентные компоненты и переносим их на k8s-альтернативы (если есть) |
|
Sticky-sessions обязательны |
Масштабирование/HA |
Включаем sticky только на внешнем Ingress; сессии — в Redis; проверяем отказ одной реплики |
|
Дубли рассылок/экспортов |
Эксплуатация |
Single-scheduler (если поддерживается), иначе — внешний оркестратор и «distributed lock» |
|
Лицензия «на узел/ядро» |
Стоимость |
Сайзим пулы нод фиксированно, отключаем автоскейл на «лицензионных» компонентах, считаем TCO |
|
BI «топчет» источники |
БД/Тривиальные падения |
PgBouncer/лимиты Trino/ClickHouse, connection budget в HPA/KEDA |
|
Неуправляемые экспорты |
Ingress/сеть |
Экспорт в S3 + pre-signed ссылки, лимиты размера и TTL |
|
Нет телеметрии |
Support/разбор инцидентов |
Требуем у вендора метрики/логи, иначе оборачиваем прокси/sidecar, фиксируем минимальный набор SLI |
|
Разнобой ролей/SSO |
Доступы |
Единый IdP, утверждённые группы, матрица мэппинга «группа → роль BI/MDM/каталог», ревизии |
Мини-фрагменты (только где нужно)
Пример ExternalSecret для BI-метаданных (секреты в Vault)
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: bi-metadata-db
namespace: bi
spec:
refreshInterval: 1h
secretStoreRef: { name: vault-store, kind: SecretStore }
target: { name: bi-metadata-db, creationPolicy: Owner }
data:
- secretKey: username
remoteRef: { key: db/bi/metadata, property: username }
- secretKey: password
remoteRef: { key: db/bi/metadata, property: password }
NetworkPolicy: BI-ns «по умолчанию — запрет»
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
namespace: bi
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
Ingress (internal) для Trino/PG/CH с IP-allowlist BI-VM
Идея: публикуем только для подсети BI-VM, всё остальное — deny.
metadata:
annotations:
kubernetes.io/ingress.class: nginx-internal
nginx.ingress.kubernetes.io/whitelist-source-range: "10.10.20.0/24"
Что проверить перед пилотом (сводный чек-лист)
- Определён вариант интеграции (A/B/C), подтверждён вендором.
- Согласована единая модель SSO/групп и «матрица ролей».
- Есть бюджеты соединений и лимиты на источниках + пуллинги (pgBouncer/Trino).
- Экспорты идут в S3, почтовые отправки — с лимитами/ретраями.
- Сети: два Ingress-контура, mTLS внутрь, NetworkPolicy default-deny, IP-allowlist для BI-VM.
- Секреты из Vault/ESO, ключи краткоживущие.
- Наблюдаемость: SLO BI (availability/latency), очереди/экспорты/пулы; алерты burn-rate и на «lag CDC/свежесть витрин».
- Runbooks на частые сбои: «двойная рассылка», «перебор коннектов», «экспорт > лимита», «WAF-ложноположительный».
- Бэкап/DR: PITR БД метаданных BI/MDM/каталога; проверенное восстановление.
Интеграция российских BI/MDM/каталогов с k8s — это не обязательно «всё в k8s». Рабочие сценарии — от нативных контейнеров до гибридов с BI на VM, но data-платформа (Kafka/Airflow/Trino/ClickHouse/Postgres/S3) живёт в Kubernetes и даёт масштаб/надёжность. Ключ к успеху — SSO и роли «как код», сетевые периметры (internal/external Ingress, mTLS, default-deny), экспорт в S3, пулы/лимиты к источникам и наблюдаемость по SLO. Всё остальное — детали внедрения, которые вы проясните с вендором по нашим чек-листам.
