Модуль поиска узлов с запущенными hostport сервисами (shturval-coreha)

О сервисе #

Назначение #

shturval-coreha предназначен для динамического добавления бэкендов во внешний балансировщик через DNS. Модуль отслеживает поды с заданным лейблом (по умолчанию ingress.cluster/name), предоставляет DNS-сервер на порту 1053 (на VIP API-сервера кластера), а внешний балансировщик периодически опрашивает этот DNS и автоматически обновляет список бэкендов.

Сервис нужен, если вы используете внешний балансировщик для доступа к точке входа кластера — Ingress, Gateway API или другому сервису с аналогичным функционалом.

По умолчанию модуль устанавливается в кластер в отключённом состоянии. Для включения: Сервисы и репозитории → Установленные сервисы → найдите сервис по названию выше и измените режим. Если сервиса нет в списке — установите его с страницы Доступные чарты (чарт shturval-coreha), выбрав неймспейс kube-system.

Обратите внимание! для сервиса shturval-coreha в спецификации (ssc) уже задана преднастроенная конфигурация. Она будет работать, если у отслеживаемого сервиса указан тот же ключ лейбла. Если ключ отличается, измените конфигурацию shturval-coreha через ShturvalServicePatch или посмотрите, какой конфиг фактически попал в ssc. При настройке поиска подов потребуется также внести изменения в тот сервис, поды которого отслеживает CoreHA: в примере с Ingress — Модуль управления внешними подключениями (shturval-ingress-controller); в примере с Gateway API — Модуль управления сетями кластера (shturval-networking).

Где настраивать #

Сервисы и репозитории → Установленные сервисы → найдите Модуль поиска узлов с запущенными hostport сервисами (shturval-coreha) → Управлять. Фактические значения конфигурации смотрите в блоке Спецификация сервиса. При необходимости переопределения параметров чарта примените изменения через ShturvalServicePatch.

Преднастроенная конфигурация ssc #

Для Модуля поиска узлов с запущенными hostport сервисами (shturval-coreha) в спецификации задана следующая конфигурация:

config:
  labelKey: ingress.cluster/name
  strictHostPort: true
  zoneName: <ИМЯ_КЛАСТЕРА>.coreha.shturval

Параметр config.strictHostPort: false подходит, если поды точки входа работают без hostPort — типичный случай для подов cilium-envoy при Gateway API. В преднастроенной ssc стоит true. Переопределите параметр через ShturvalServicePatch для shturval-coreha.

Эта конфигурация будет работать при условии, что у точки входа указан тот же ключ лейбла (ingress.cluster/name). Если ключ лейбла другой, потребуется изменить конфигурацию shturval-coreha.

Проверьте преднастроенную конфигурацию, чтобы понять какой запрос dig формироват: в кластере: раздел Сервисы и репозитории → Установленные сервисы → Модуль поиска узлов с запущенными hostport сервисами (shturval-coreha) → Управлять → блок Спецификация сервиса.

Если необходимо переопределить параметры, подготовьте ShturvalServicePatch для shturval-coreha и загрузите его в кластер.

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: shturval-coreha-config
spec:
  shturvalServiceConfigName: shturval-coreha
  patchOrder: 11000
  customvalues:
    config:
      zoneName: "hostport.shturval"
      labelKey: "ingress.cluster/name"
      strictHostPort: "false"
      dns_port: "1053"

Как формируется DNS-имя #

Модуль автоматически обнаруживает поды с лейблом, заданным в config.labelKey, и формирует DNS-запись по шаблону:

<label_value>.<namespace>.<config.zoneName>

Берите эти значения из фактической конфигурации ssc. При преднастроенной зоне <ИМЯ_КЛАСТЕРА>.coreha.shturval запись выглядит так:

• Ingress (NGINX): default-nginx.ingress.<ИМЯ_КЛАСТЕРА>.coreha.shturval
• Gateway API: gateway-api.kube-system.<ИМЯ_КЛАСТЕРА>.coreha.shturval

Связка с точкой входа и внешним балансировщиком #

Ниже — два типовых сценария. Шаги 3–4 (настройка внешнего балансировщика и проверка dig) одинаковы по смыслу: укажите VIP API-сервера, порт DNS (1053) и сформированное DNS-имя.

Пример: Ingress (NGINX) + внешний балансировщик (HAProxy) #

Когда в кластере работает shturval-coreha и точкой входа служит Ingress-контроллер (в платформе «Штурвал» — NGINX Ingress как пример реализации):

1. ShturvalServicePatch для shturval-ingress-controller — задайте лейбл ingress.cluster/name и при необходимости включите hostPort, NodePort (например, 30080/30443).

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: <имя ресурса>
spec:
  shturvalServiceConfigName: shturval-ingress-controller
  customvalues:
    controller:
      labels:
        ingress.cluster/name: <ваше значение параметра>
      hostPort:
        enabled: true # При включении поды ингресс контроллера также будут использовать на узлах кластера 80 и 443 порты
      service:
        nodePorts:
          http: "<ваше значение параметра>"
          https: "<ваше значение параметра>"
        type: NodePort

2. Загрузите ShturvalServicePatch в кластер (импорт манифестов или kubectl).

3. Настройте внешний балансировщик (в примере — HAProxy): используйте resolver с указанием на VIP API-сервера кластера и порт DNS (1053), backend с server-template по DNS-имени.

resolvers coredns-cluster
    nameserver ns1 <api-server-vip>:1053
    accepted_payload_size 8192

backend cluster-clustername-ingress-http
    balance source
    mode tcp
    server-template daemonset 2 default-nginx.ingress.<ИМЯ_КЛАСТЕРА>.coreha.shturval:80 check resolvers coredns-cluster init-addr none

4. Проверка — с узла с доступом к VIP API-сервера кластера соберите dig только из фактических значений ssc: dig @<api-server-vip> -p 1053 <label_value>.<namespace>.<config.zoneName>. При преднастроенной зоне и лейбле default-nginx в неймспейсе ingress: dig @<api-server-vip> -p 1053 default-nginx.ingress.<ИМЯ_КЛАСТЕРА>.coreha.shturval (должны вернуться IP подов Ingress). Если ключ лейбла у Ingress Controller не совпадает с config.labelKey в ssc, запрос не вернёт адреса узлов.

Пример: Gateway API (Cilium Envoy) + внешний балансировщик #

Начиная с релиза 2.14 маршрутизация L7 может выполняться через Gateway API на базе Cilium: прокси-поды cilium-envoy в неймспейсе kube-system обрабатывают входящий трафик. Для интеграции с CoreHA на эти поды навешивается тот же лейбл ingress.cluster/name, и модуль отдаёт их IP-адреса внешнему балансировщику через DNS.

Шаг 1. Активация CRD Gateway API (релиз 2.14) #

В платформе «Штурвал» 2.14 CRD Gateway API поставляются чартом shturval-gateway-api-crds; режим по умолчанию — Absent. Переведите сервис в активное состояние (режим управления Auto):

Сервисы и репозитории → Установленные сервисы → найдите CRD модуля Gateway API (shturval-gateway-api-crds) → Управлять.

Если сервис отсутствует: Доступные чарты → чарт shturval-gateway-api-crds → Установить; при конфигурировании создайте и выберите неймспейс gateway-system.

Проверка:

kubectl get ssc shturval-gateway-api-crds
kubectl get crd | grep gateway.networking.k8s.io

Шаг 2. Патч shturval-networking #

Чтобы CoreHA идентифицировал поды cilium-envoy, задайте лейбл ingress.cluster/name: gateway-api в секции envoy.podLabels и включите контроллер Gateway API через ShturvalServicePatch:

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: ssp-networking-gateway-api
spec:
  shturvalServiceConfigName: shturval-networking
  customvalues:
    envoy:
      podLabels:
        ingress.cluster/name: gateway-api
    gatewayAPI:
      enabled: true

Загрузите патч в кластер (импорт манифестов или kubectl apply).

Шаг 3. Проверка подов cilium-envoy #

kubectl get pods -n kube-system -l ingress.cluster/name=gateway-api -o wide

Поды должны быть в статусе Running и содержать лейбл ingress.cluster/name=gateway-api.

Шаг 4. Проверка DNS и настройка балансировщика #

Проверка разрешения DNS:

dig @<api-server-vip> -p 1053 gateway-api.kube-system.<config.zoneName>

Пример при преднастроенной зоне и лейбле gateway-api в неймспейсе kube-system: dig @192.0.2.10 -p 1053 gateway-api.kube-system.<ИМЯ_КЛАСТЕРА>.coreha.shturval — в ответе должны быть A-записи с IP подов cilium-envoy. Значения берите из фактической спецификации (ssc) shturval-coreha. Если для подов без hostPort нужен config.strictHostPort: false, переопределите его патчем shturval-coreha — в преднастроенной ssc стоит true.

resolvers k8s-coreha
    nameserver coreha-api <api-server-vip>:1053
    resolve_retries 3
    timeout retry 1s
    hold valid 10s

backend be_gateway_api
    mode http
    balance roundrobin
    server-template envoy-node 10 gateway-api.kube-system.<ИМЯ_КЛАСТЕРА>.coreha.shturval:80 check resolvers k8s-coreha init-addr none

backend be_gateway_api_tls
    mode tcp
    balance roundrobin
    server-template envoy-node-tls 10 gateway-api.kube-system.<ИМЯ_КЛАСТЕРА>.coreha.shturval:443 check resolvers k8s-coreha init-addr none

Параллельная работа при миграции #

При in-place миграции с Ingress на Gateway API оба контура могут работать одновременно. Задайте разные значения лейбла ingress.cluster/name (например, default-nginx для Ingress и gateway-api для Envoy) — CoreHA сформирует два отдельных DNS-имени, и внешний балансировщик сможет направлять трафик на нужный контур на время перехода.

Как развернуть этот сервис — Как развернуть новый сервис.