Перейти к содержимому

Группы Ingress

Группа Ingress — это набор нод Ingress на nginx, обычно по одной на площадку, которые обслуживают одни и те же Routes и Domains. Каждый участник сам формирует конфигурацию каждого Route группы и хранит собственную копию каждого сертификата, который используют эти Routes, поэтому участник продолжает обслуживать запросы, пока Opfield или другой участник недоступен. Из группы можно обслуживать Routes к нагрузкам Docker, сайты Pages и публичную страницу состояния.

Группа определяет, какие ноды обслуживают имя. Она не выбирает, к какому участнику попадёт клиент: это решают DNS или балансировщик нагрузки перед участниками; см. DNS и Балансировщик нагрузки перед группой.

  • Участниками могут быть ноды nginx, демон которых сообщает возможность ingress_group_v1; её сообщает nginx-демон 2.11. Нода может входить в несколько групп.
  • Создание группы и всё, что её расширяет (добавление участников или изменение их порядка, изменение настроек, размещение на ней Routes или Domains), требует Business или Enterprise, как и Workload Availability. Существующие группы продолжают работать и без этого, а удалить участника или группу можно всегда.
  • Для групп действуют права на ноды. Для просмотра нужны nodes:details или nodes:manage — в целом или на папку нод группы; для изменений — nodes:manage на эту папку, а для добавления ноды ещё и nodes:manage на саму ноду.
  • Для размещения Route или Domain на группе нужны proxy:create или domains:create, покрывающие каждого участника: в целом, в папке назначения или через права на каждую ноду-участника.
  1. Откройте Ingress → Ingress Groups и нажмите New Group.
  2. Введите имя, при необходимости описание и папку и выберите ноды-участники в порядке предпочтения площадок.
  3. Откройте группу, чтобы следить за состоянием каждого участника (State), его здоровьем Ingress (Ingress health) и доставкой Routes группы.

На странице группы можно добавлять, удалять участников и менять их порядок, а также видеть для каждого Route, что применил каждый участник: хеш конфигурации, версию сертификата или причину ошибки. Там же показаны адреса, которые DNS публикует для Domains группы.

Те же операции доступны через /api/ingress-groups и инструмент MCP manage_ingress_group.

При создании Route или Domain в списке нод Ingress также есть Ingress groups (served by every member). Route, созданный для Domain группы, попадает в эту группу. Через API и MCP передайте ingressGroupId вместо nodeId (для Domains — вместо nginxNodeId).

Чтобы перенести существующий Route или Domain, используйте его подробности в Console или convert_route и convert_domain. Перенос на группу проходит без простоя: сначала каждый новый участник получает конфигурацию и сертификаты, и только в конце меняется DNS. Перенос обратно на одну ноду (ingressGroupId: null вместе с нодой-участником) сначала меняет DNS, а остальных участников очищает потом. Имя должно быть уникальным среди всех нод и участников групп, на которых оно обслуживается.

Route группы показывает ноды, которые его обслуживают (servingNodeIds), свою группу и доставку на каждого участника (ingressDelivery).

Состояние Значение
Joining Нода получает конфигурацию каждого Route, сертификаты и источники Secure Links группы. В DNS она пока не публикуется. Отключённая нода остаётся в этом состоянии, пока не переподключится.
Active Нода обслуживает запросы и опубликована в DNS.
Draining Нода ещё обслуживает запросы, но уже убрана из DNS. Она удаляется, когда ни одно публичное имя группы больше на неё не указывает и истёк TTL DNS, но не позже чем через 24 часа.

Удаление участника сначала убирает его из DNS и даёт ему завершить работу. Для участника в состоянии Draining кнопка Remove now (force в API) удаляет его сразу, хотя закэшированные ответы DNS ещё могут направлять к нему клиентов. Последнего активного участника группы, которая ещё обслуживает Routes или Domains, удалить нельзя, а удалить можно только группу без Routes и Domains.

Opfield доставляет каждое изменение каждому участнику. Изменять Route группы можно и тогда, когда один из участников отключён: он отмечается как ожидающий и догоняет изменения после переподключения. Opfield каждую минуту и при каждом переподключении участника восстанавливает отсутствующие или устаревшие конфигурации и копии сертификатов. Если изменение отклонено уже после того, как его приняли некоторые участники, эти участники получают прежний Route обратно.

Каждый участник хранит копию каждого сертификата своих Routes, а продления доходят до каждого участника. Проверки HTTP-01 размещаются на каждом подключённом участнике. Так как DNS может направить запрос проверки к любому участнику, в том числе к отключённому, сертификаты для имён в Domain группы, управляемом через Cloudflare, выпускаются и продлеваются через DNS-01 с помощью коннектора Cloudflare, который не зависит ни от одной ноды Ingress.

Состояние Route проверяется через каждого участника: Route получает состояние degraded, если проверку не проходит какой-либо участник, и offline, если его не обслуживает ни один. Каждый участник пишет собственные журналы nginx; журнал Route и его история объединяют записи всех участников по времени.

Каждый блок server, сформированный Opfield, и сервер по умолчанию отвечают на зарезервированный путь /.well-known/gateway-ingress-health. Ответ формирует сама нода, поэтому он работает и тогда, когда Opfield недоступен:

Код Значение
200 с JSON "status": "serving" nginx работает на конфигурации последней успешной перезагрузки демона, а на ноде с Secure Links доступен хотя бы один транспорт Relay
503 с JSON "status": "unavailable" и reasons nginx работает не на текущей конфигурации или для её Secure Links не подключён ни один транспорт Relay
502 nginx-демон не запущен

Для проверок, которые обращаются к участнику по IP-адресу, нода также отвечает на зарезервированное имя ingress-health.gateway.invalid на портах 80 и 443. На порту 443 используется самоподписанный сертификат. Режим обслуживания, Access Lists и базовая аутентификация на этот путь не действуют.

Режим переключения DNS группы — none: для Domain группы, управляемого через Cloudflare, Opfield публикует адреса всех активных участников, и клиенты распределяются по кругу. Эти записи не проверяются на доступность, поэтому недоступный участник продолжает получать свою долю клиентов, пока его не удалят из группы. Участники без обнаруженного публичного адреса Ingress не публикуются. Внешний DNS остаётся в вашем ведении; Opfield только проверяет, что он указывает на участников.

Для переключения между участниками поставьте перед ними балансировщик нагрузки, который проверяет их состояние. С Cloudflare Load Balancing:

  1. Создайте пул, источниками которого являются публичные адреса активных участников группы.
  2. Подключите монитор состояния для пути /.well-known/gateway-ingress-health, который ожидает 200. Используйте HTTP на порту 80 с заголовком Host ingress-health.gateway.invalid или с именем, которое обслуживает группа; для монитора HTTPS к зарезервированному имени отключите проверку сертификата, потому что для этого имени используется самоподписанный сертификат.
  3. Создайте балансировщик нагрузки для имени, которое обслуживают ваши Routes, с этим пулом.

Коннектор Cloudflare в Opfield никогда не создаёт, не изменяет и не удаляет балансировщики нагрузки, пулы и мониторы Cloudflare. При добавлении или удалении участников обновляйте пул сами. Для Domain группы, управляемого через Cloudflare, Opfield по-прежнему ведёт описанные выше обычные записи DNS.