Node Local Gateway
Node Local Gateway — это компонент, работающий на каждом узле кластера в виде Static Pod. Использование Node Local Gateway дает несколько преимуществ:
-
Стандартизованный прием HTTP-трафика — входящие подключения всегда обрабатываются на одних и тех же портах 80, 443.
-
Совместимость с сетевыми политиками — трафик к ingress-контроллерам можно контролировать через существующие механизмы безопасности.
1. Принцип работы
Node Local Gateway принимает и обрабатывает трафик на каждом узле кластера в следующих случаях:
-
узел является точкой обработки (входа) внешнего трафика, т.е. ingress endpoint;
-
сервисы на узле получают отказоуйстойчивый доступ к Kubernetes API (например, Kubelet или StarVault).
Благодаря такому подходу:
-
Ingress-контроллеры могут работать в стандартном режиме (через Deployment), без привязки к host-сети, что повышает управление и масштабирование;
-
Конфигурация маршрутизации обновляется автоматически, поддерживая актуальное состояние без ручного вмешательства.
2. Метки и аннотации для узлов
В текущей версии платформы изменена логика установки меток на узлы, а также добавлены новые конфигурационные аннотации, которые определяют роль ноды и параметры этой роли. В таблице ниже перечислены описания новых меток и аннотаций.
Тип |
Ключ |
Значение |
Описание |
label |
|
- |
Базовая метка, которая устанавливается на любой узел, если необходимо объявить его точкой входа трафика, независимо от того есть ли на узле Ingress-контроллер или нет. |
annotation |
|
|
Тип точки входа трафика: узел может обслуживать входящий трафик либо ingress-nginx, либо istio-ingressgateway. |
annotation |
|
номер порта, например, |
Указывается номер порта, в который необходимо направлять HTTP-трафик. |
annotation |
|
номер порта, например, |
Указывается номер порта, в который необходимо направлять HTTPS-трафик. |
annotation |
|
cluster или local |
Политика cluster позволяет принимать трафик для ingress-контроллера и направлять его на любой другой pod контроллера, если pod отсутствует непосредственно на текущем узле. Политика local запрещает такое поведение, и узел может принять трафик только если на нем локально располагается pod с контроллером. |
3. Конфигурация узлов при развертывании и обновлении
3.1. Infra-узлы
Для всех infra-узлов автоматически задаются:
-
Метки
node-role.kubernetes.io/infra: '' node.nova-platform.io/ingress-endpoint: '' -
Аннотации
ingress-endpoint.nova-platform.io/backend-http-port: '80' ingress-endpoint.nova-platform.io/backend-https-port: '443' ingress-endpoint.nova-platform.io/internal-traffic-policy: cluster ingress-endpoint.nova-platform.io/type: ingress-nginx
Это означает, что каждый infra-узел принимает входящий трафик на портах 80/443, даже если на ней нет пода с ingress-nginx.
Количество реплик nova-ingress-internal-controller:
-
если infra-узел < 3 → 1 реплика
-
если infra-узел ≥ 3 → 2 реплики.
3.2. Worker-узлы
Если нет отдельных ingress-узлов, то для всех worker-узлов автоматически задаются:
-
Метки
node-role.kubernetes.io/worker: '' node.nova-platform.io/ingress-endpoint: '' -
Аннотации
ingress-endpoint.nova-platform.io/backend-http-port: '80' ingress-endpoint.nova-platform.io/backend-https-port: '443' ingress-endpoint.nova-platform.io/internal-traffic-policy: cluster ingress-endpoint.nova-platform.io/type: ingress-nginx
Количество реплик nova-ingress-public-controller:
-
если в конфигурации явно указан блок с ingress-узлами → число реплик совпадает с числом этих нод;
-
если блок отсутствует:
-
при количестве мастер-узлов < 3 → создается 1 реплика;
-
при количестве мастер-узлов ≥ 3 → создается 2 реплики.
-
4. Конфигурация узлов при масштабировании
-
Новый worker-узел будет при добавлении иметь следующий набор меток:
labels: <...> node-role.kubernetes.io/worker: '' -
Новый infra-узел будет при добавлении иметь следующий набор меток:
labels: <...> node-role.kubernetes.io/infra: ''
|
Для только что добавленных worker либо infra-узлов отсутствует метка |