Введение (control plane)

Previous Next

Статус: Draft Дата: 2026-04-29 Область: продуктовая и архитектурная концепция, без выбора конкретных технологий реализации.

Зачем нужен этот раздел

Сейчас многие инфраструктурные сущности в AIOps являются metadata-сущностями: cluster, node, service, deployment и marketplace service описывают объект, связи и атрибуты, но не выражают полный процесс управления реальной инфраструктурой.

Для настоящего управления инфраструктурой нужен отдельный слой control plane. Он должен описывать не только "что хранится в базе", но и:

  • какой результат пользователь хочет получить;
  • какие capabilities нужны для результата;
  • какие capabilities и artifacts создает каждый шаг;
  • какой DAG операций надо выполнить;
  • где нужны approval, verification, ручное вмешательство или AI-анализ;
  • как связать процесс выполнения с итоговым состоянием ресурса.

Главная идея

Пользователь описывает желаемый результат. Control plane строит проверяемый план, разрешает зависимости через capabilities, исполняет DAG как operation run, собирает evidence и обновляет состояние управляемых ресурсов.

flowchart LR intent[Intent
Desired result] --> resolve[Capability resolution] resolve --> plan[Editable DAG plan] plan --> run[Operation run] run --> evidence[Evidence and artifacts] evidence --> resources[Managed resources] resources --> observed[Observed state] observed --> resolve

Эта модель должна поддерживать две оптики:

  • Simple mode: "получить рабочий Kubernetes/Postgres/Tempo/S3/сервис".
  • Advanced mode: "показать DAG, стадии, контракты, логи, artifacts, evidence, gates и точки вмешательства".

Это не два разных продукта. Это один control-plane объект с разной глубиной отображения.

Почему это не CRUD

CRUD меняет данные в базе. Control plane управляет переходом реальной системы из одного состояния в другое.

Пример:

  • CRUD: создать запись cluster со статусом provisioning.
  • Control plane: проверить ноды, credentials, сеть, установить runtime, инициализировать control plane, установить CNI, добавить workers, проверить health, сохранить kubeconfig, endpoint, evidence и итоговый статус.

Ресурс и операция должны быть разными сущностями.

flowchart TB cluster[Resource: cluster/prod-k8s] operation[Operation: Create Kubernetes Cluster #482] plan[Plan: concrete editable DAG] history[Timeline, logs, artifacts, interventions] state[Resource state and health] operation --> plan operation --> history operation --> state state --> cluster

Ключевые понятия

Понятие Смысл
Resource Управляемая сущность: cluster, node, service, postgres, tempo, deployment, pod, process
Intent Намерение пользователя: желаемый результат, параметры и ограничения
Capability Способность или свойство, которое требуется или предоставляется ресурсом, сценарием или job
Artifact Конкретный объект, файл, секрет, конфиг или output, который нужен другим шагам
Evidence Доказательство, что состояние достигнуто: check, log, metric, command output, health result
Scenario Шаблон действия из marketplace или внутреннего каталога
Plan Конкретный DAG, построенный из scenario под конкретный intent и environment
Operation Фактический запуск plan с timeline, состоянием, логами и решениями
Stage Крупный этап, понятный человеку
Job Атомарный исполняемый шаг с контрактом input/output
Gate Точка остановки для approval, выбора варианта или проверки риска
Intervention Ручное или AI-вмешательство в выполнение
PlanPatch Формальное изменение plan: вставить, заменить, убрать или изменить узлы
ResourceBinding Связь requirement с конкретным resource/provider

Capability + DAG

Capability отвечает на вопрос "что нужно или что уже есть". DAG отвечает на вопрос "как безопасно этого достичь".

Marketplace-сценарий не должен жестко говорить "установи MinIO". Он должен говорить "мне нужна capability object_storage.s3". Control plane уже выбирает provider:

  • использовать существующий MinIO;
  • использовать внешний AWS S3;
  • создать dedicated MinIO через sub-operation;
  • остановиться на gate и попросить пользователя выбрать вариант.
flowchart TB tempo[Intent: Install Tempo] tempo --> k8sReq[requires kubernetes.cluster] tempo --> s3Req[requires object_storage.s3] tempo --> nsReq[requires kubernetes.namespace] k8sReq --> k8s[binds cluster/prod-k8s] s3Req --> missing{matching provider exists?} missing -->|yes| existing[bind existing S3 provider] missing -->|no| minio[run sub-operation: Install MinIO] nsReq --> namespace[create or bind namespace] k8s --> plan[Install Tempo DAG] existing --> plan minio --> plan namespace --> plan

Job как контракт трансформации

Каждый job в DAG не просто "выполняет команду". Он трансформирует входные capabilities и artifacts в новые capabilities, artifacts и evidence.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
inputs:
  capabilities:
    - ssh.access
    - linux.host
    - package.manager.apt
  artifacts:
    - node_inventory
    - registry_mirror_config

outputs:
  capabilities:
    - container.runtime.containerd
  artifacts:
    - containerd_config_snapshot
    - package_install_report
  evidence:
    - containerd_service_active
    - crictl_works

Стадия считается успешной не потому, что команда завершилась с exit code 0, а потому что заявленные output capabilities подтверждены evidence.

Marketplace как набор scenario packs

Marketplace должен содержать не только карточки сервисов, но и scenario packs:

  • какие resource types пакет умеет создавать или обслуживать;
  • какие actions поддерживает: install, upgrade, scale, repair, uninstall;
  • какие capabilities предоставляет;
  • какие capabilities требует;
  • какие plan templates поставляет;
  • какие gates, permissions и risk levels нужны;
  • какие stages можно редактировать в advanced mode.

AI и ручные вмешательства

AI не должен быть "магией сбоку". Он должен работать через тот же протокол:

  • анализировать failed stage и evidence;
  • предлагать PlanPatch;
  • добавлять diagnostic jobs;
  • предлагать sub-operation для недостающей capability;
  • объяснять риск и blast radius;
  • выполнять только разрешенные действия по policy.

Ручное вмешательство тоже является частью модели. Пользователь может починить проблему руками, отметить stage как manually fixed, после чего control plane обязан выполнить verification перед продолжением.

Документы раздела

Диаграмма: auth микросервисы Архитектура компонентов (control plane)