Cloud IP Validator · микросервисный деплой

Control Plane и Data Plane

Система ревалидации освобождённых публичных IPv4-адресов в облаке на базе SDN VK Cloud. С переходом на docker-compose каждый компонент — control-api, admin-dashboard, prober, validator-agent — разворачивается отдельным контейнером по своему профилю (COMPOSE_PROFILES), на своём хосте. Ниже показано, как они связаны между собой (control plane) и что именно проверяется в реальном сетевом трафике (data plane).

1 Control plane: кто кем управляет

Оператор — через веб-панель или напрямую curl'ом — обращается к единственному источнику истины, control-api. validator-agent и prober сами инициируют все вызовы (pull-модель): регистрируются, шлют heartbeat, забирают назначение, отчитываются о результатах. control-api сам к ним не обращается.

Оператор инженер эксплуатации Управляющая машина profiles: control-plane, dashboard admin-dashboard браузерная панель оператора · :8090 control-api HTTP API + оркестратор + SQLite · единственный stateful-сервис :8080 curl /api/v1/admin/* · :8080 OpenStack API · mode: real OpenStack Keystone · Neutron / Sprut associate / disassociate floating ip Внешние площадки ×N profiles: prober prober TCP + ICMP пробы наружу по 1 на площадку ВМ-валидаторы ×N profiles: validator validator-agent egress-проверки + self-check по 1 на ВМ-валидатор register · heartbeat assignments · results → /api/v1/probers/* register · heartbeat self-check · events results · complete → /api/v1/agents/* управляющий вызов (control-plane API) только при openstack.mode: real
control-api — единственный компонент с состоянием (SQLite) и единственная точка принятия решений: какой IP кому назначить и когда считать проверку завершённой. Остальные сервисы развёрнуты по одному контейнеру на профиль docker-compose — на управляющей машине, на каждой внешней площадке и на каждой ВМ-валидаторе; все стрелки к control-api идут от них — это они опрашивают control-api, а не наоборот. Связь с облаком идёт через сеть OpenStack — Neutron и его альтернативная реализация в SDN VK Cloud, Sprut, — поэтому на схеме указаны оба.

2 Data plane: что реально проверяется

Один и тот же публичный адрес проверяется одновременно с двух независимых сторон. Этот сетевой трафик control-api не видит напрямую — он получает только заявленный агентами результат по отдельному управляющему каналу (см. схему control plane выше).

Floating IP 203.0.113.10 ВМ-валидатор validator-agent слушает 22/80/443/8080 1. self-check + проверки IP-echo сервис api.ipify.org и т.п., вне облака GET, сравнение адреса Целевые серверы (targets) HTTPS · ICMP · SSH (опционально) 2. HTTPS / ICMP / SSH prober ×N площадок внешние тестовые точки, независимо друг от друга TCP 22/80/443/8080 + ICMP
Egress (слева): validator-agent сам всегда обращается наружу через назначенный Floating IP — сначала self-check во внешнем IP-echo сервисе (адрес обязан быть вне облака — иначе SNAT не сработает), затем проверки из конфига до целей. Inbound (справа): N внешних площадок независимо стучатся в тот же адрес снаружи. Только сочетание обоих направлений даёт полную картину — адрес может нормально работать «наружу», но быть заблокирован для конкретной внешней сети, и наоборот.
egress-проверка (от validator-agent, через FIP) inbound-проверка (от внешних площадок, в FIP)