Архитектура runtime
Как Multi-Tenant Runtime планирует, изолирует и наблюдает за плагинами.
Multi-Tenant Runtime (BC-19) — место, где запускается ваш плагин. Эта страница о том, что он реально делает с вашим контейнером на install-time и в runtime.
Поток установки
Когда тенант устанавливает плагин, BC-02 (Lifecycle) передаёт манифест в BC-19 (Runtime). BC-19:
- Верифицирует образ — Cosign-подпись должна совпадать с публичным ключом публикатора. Kyverno отклоняет всё остальное на admission.
- Создаёт namespace —
plugin-{tenant-id}-{plugin-slug}под AppProjectplugins. - Разворачивает секреты — каждый элемент под
spec.secretsвplugin.yamlрезолвится через External Secrets Operator. Пути Vault namespaced:adapstory/plugins/{plugin-name}/{tenant-id}/.... - Применяет лимиты — CPU, память, storage, бюджеты LLM-токенов, rate limit.
- Настраивает NetworkPolicy — egress только к декларированным целям (Plugin Gateway, Kafka, Data Model Engine). Никакой LAN-разведки.
- Планирует pod — с
pod-security.kubernetes.io/enforce: restricted,runAsNonRoot: true,allowPrivilegeEscalation: false.
Ваш образ обязан запускаться не от root. Если он hardcode'ит USER root, admission-контроллер его отклонит.
Per-tenant изоляция
Каждая пара плагин-тенант получает свой namespace и свою PostgreSQL-схему. Runtime:
- Инъектирует короткоживущий JWT с
sub=plugin:{name}:{tenant}— используйте для вызовов core-API. - Биндит tenant-scoped PostgreSQL-пользователя (
plugin_{name}_{tenant_id}) с правами только на свою схему. - Маршрутизирует Kafka-трафик через ACL по ключу
(tenant-id, plugin-name). Вы видите только события своего тенанта.
Cross-tenant доступ — нарушение контракта, ловится audit-логами + per-namespace NetworkPolicies.
Observability
Каждый pod плагина автоматически получает три агента:
| Агент | Что собирает | Куда отправляет |
|---|---|---|
| OTEL Collector sidecar | Трейсы + метрики (OTLP) | Tempo / Prometheus |
| Grafana Alloy (DaemonSet) | CPU-профили непрерывно (eBPF) | Pyroscope |
| Fluent Bit | Структурированные JSON-логи | Loki |
Вашему коду достаточно:
- Эмитить OpenTelemetry spans (большинство SDK делают это бесплатно).
- Логировать JSON (
log-format=json). - Включать
tenant.idкак span-атрибут в каждый вызов.
Режимы отказа
- LLM-вызов сверх бюджета — BC-01 возвращает HTTP 429 с заголовком
X-LLM-Budget-Reset. Плагин должен деградировать корректно (кэш, фолбэк, очередь). - Kafka consumer lag — алерты срабатывают при p99 > 60s на 5м. Runtime не scales вас автоматически; вы тюнить
maxReplicasв манифесте. - Нарушение guardrail — BC-01 возвращает HTTP 403 с
X-Guardrail-Rule. Не retry — починить промпт или контент. - Невалидная подпись — install fail-fast с
ImagePullBackOff+ Kyverno audit event. Переподпишите и опубликуйте заново.
Откат
Откаты детерминированы: bd plugin rollback <name> --tenant <id> (или через админку) вызывает BC-02, который переприменяет последний known-good манифест и сливает трафик на старую версию.
- Миграции схемы БД — forward-compatible — если v1.3 добавила колонку, v1.2 всё ещё работает (просто игнорирует).
- Если миграция не forward-compatible, BC-15 отклонит манифест на install. Разбейте миграцию на две версии.
Дальше: Quickstart по плагину.