Выбор хостов для политики

Host selector определяет область действия политики. Политику можно назначить конкретному хосту, хостам с заданными лейблами, группе или всему парку.

Пустой selector {} соответствует всему парку. Сохранение такой политики требует подтверждения её именем. Selector {"anyOf":[]} не выбирает ни одного хоста, но этот вариант предназначен для API: форма консоли при отсутствии условий формирует {}.

Лейблы

В блоке Host selector → Labels задаются пары key=value, например:

env=prod
role=web

Один блок с несколькими парами использует условие AND: хост должен иметь все перечисленные эффективные лейблы. Эффективный набор состоит из собственных лейблов хоста и лейблов его групп; собственное значение имеет приоритет.

Условие динамическое. Оно начинает действовать на новый хост сразу после появления подходящих лейблов и перестаёт действовать после их изменения.

Конкретный хост

Добавление строки в таблице Хосты записывает в selector блок _hostId. Control Plane сопоставляет такой блок по идентификатору хоста; менять лейблы хоста не требуется.

После сохранения подключённый хост получает новое поколение правил. Офлайн-хост продолжает использовать last-good generation и синхронизируется после подключения.

Группа хостов

Добавление строки в таблице Группы записывает блок с текущими matchLabels группы и метаданными _groupId. При сопоставлении Control Plane использует лейблы, а _groupId нужен консоли для отображения назначения.

Поэтому политика действует не только на явных членов группы, но и на любой другой хост с тем же набором эффективных лейблов. Новый член группы наследует её лейблы и обычно начинает соответствовать selector автоматически.

Изменение лейблов группы может изменить область политики. Перед применением такого изменения проверяется зона влияния черновика группы.

Объединение условий

Назначения на группы, отдельные хосты и прямой блок лейблов объединяются через anyOf, то есть по OR. Хост попадает под политику, если соответствует хотя бы одному блоку. Внутри одного блока matchLabels все пары по-прежнему соединены по AND.

Пример:

{
  "anyOf": [
    { "matchLabels": { "env": "prod", "role": "web" } },
    { "_hostId": "<host-id>", "matchLabels": { "host-id": "<host-id>" } }
  ]
}

Политика действует на все production web-хосты и на один явно указанный хост.

Весь парк

Selector {} не содержит ограничений и выбирает каждый активный хост организации. Перед сохранением консоль показывает Apply to ALL hosts? и требует ввести имя политики. API требует поле "confirm_match_all": true в теле create/update-запроса, иначе возвращает 422.

Перед применением fleet-wide-политики проверяются:

• список затронутых хостов в Зоне влияния;
• разрешающие правила для SSH и других административных каналов;
• этап наблюдения с log перед широким deny;
• область по интерфейсам для многоинтерфейсных хостов.

Снятие назначения

Действие Снять в таблице Хосты удаляет блок _hostId, а в таблице Группы — блок _groupId. Правила исчезают только с хостов, которые после изменения больше не соответствуют ни одному оставшемуся блоку.

Удаление последнего блока и последней пары лейблов формирует {} — selector на весь парк, а не отключённую политику. Консоль потребует подтверждение fleet-wide. Если политика больше не должна действовать, безопасный вариант — удалить её. Для временного selector, который не выбирает хосты, API принимает {"anyOf":[]}.

Зона влияния

Для существующей политики действие Зафиксировать изменение и посмотреть зону влияния создаёт черновик и показывает хосты и изменения effective ruleset до применения. Проверка особенно важна для:

• selector по общим лейблам;
• назначения группы;
• удаления последнего условия;
• selector {} на весь парк.

Синхронизация

Control Plane пересчитывает effective ruleset после изменения политики, лейблов, состава группы или сетевого состояния, влияющего на hostset. Подключённые хосты получают новое поколение. Офлайн-хосты сохраняют last-good generation до следующего подключения.

Состояние доставки видно по desired и confirmed generation и по статусу хоста.