Настройка режима управления целевыми группами для сетевых балансировщиков

Режим управления целевыми группами настраивается в сервисе Kubernetes — ресурсе Service типа LoadBalancer. По настройкам сервиса контроллер Managed Service for Kubernetes автоматически создает сетевой балансировщик нагрузки Network Load Balancer, который направляет трафик на узлы кластера.

По умолчанию балансировщики нагрузки используют общую целевую группу, включающую все узлы кластера. Балансировщик проверяет доступность всех узлов кластера, даже если поды приложения, к которому он направляет трафик, размещены только на нескольких из них.

Чтобы сократить число проверяемых узлов, для сервиса с политикой externalTrafficPolicy: Local можно настроить режим управления целевыми группами v2. Контроллер создаст для сетевого балансировщика отдельную целевую группу с узлами, на которых размещены поды приложения, и будет обновлять ее. Вы можете задать режим при создании сервиса или настроить в уже существующем.

Чтобы настроить режим управления целевыми группами:

1. Подготовьтесь к работе.
2. Создайте сервис типа LoadBalancer или включите режим v2 и политику Local для существующего сервиса.
3. Проверьте состав целевой группы и доступность приложения.

Перед началом работыПеред началом работы

1. Убедитесь, что кластер использует релизный канал RAPID. Режим v2 с политикой Local пока доступен только в этом канале.

2. Обратитесь в техническую поддержку. Укажите идентификатор облака и идентификатор кластера. Запросите подключение режима v2 и дождитесь подтверждения подключения.

3. Установите kubectl и настройте его на работу с созданным кластером Managed Service for Kubernetes.

4. Проверьте квоты и лимиты Network Load Balancer: в режиме v2 для каждого сервиса с Local создается отдельная целевая группа. При необходимости запросите увеличение квот.

5. Проверьте права сервисного аккаунта кластера и группы безопасности по инструкции подготовки инфраструктуры.

6. Подготовьте приложение. В примерах используется приложение в пространстве имен default, поды которого имеют метку app: demo и принимают TCP-трафик на порте 8080. Замените эти параметры своими значениями.

7. Проверьте готовность подов и их размещение:

   kubectl -n default get pods -l app=demo -o wide
   

Создайте сервис типа LoadBalancerСоздайте сервис типа LoadBalancer

Чтобы создать сервис типа LoadBalancer, для которого контроллер автоматически создаст сетевой балансировщик с отдельной целевой группой:

1. Сохраните спецификацию сервиса в файл app-lb.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: app-lb
     namespace: default
     annotations:
       yandex.cloud/controller-reconcile-mode: "v2"
   spec:
     type: LoadBalancer
     externalTrafficPolicy: Local
     selector:
       app: demo
     ports:
       - name: http
         port: 80
         targetPort: 8080
         protocol: TCP
   

   Где:

   • type: LoadBalancer в разделе spec — тип сервиса, для которого контроллер автоматически создает сетевой балансировщик нагрузки.
   • yandex.cloud/controller-reconcile-mode: "v2" в разделе metadata.annotations — аннотация, которая включает режим управления целевыми группами v2.
   • externalTrafficPolicy: Local в разделе spec — политика, при которой узел направляет внешний трафик только в поды приложения на этом же узле. В сочетании с режимом v2 целевая группа включает только узлы с подами, выбранными селектором сервиса.

   Дополнительные параметры приведены в справочнике Service.

2. Создайте сервис:

   kubectl apply -f app-lb.yaml
   

3. Дождитесь появления IP-адреса сетевого балансировщика в поле EXTERNAL-IP сервиса:

   kubectl -n default get service app-lb --watch
   

   Появление адреса еще не подтверждает готовность приложения. Проверьте результат.

Включите режим v2 для существующего сервиса типа LoadBalancerВключите режим v2 для существующего сервиса типа LoadBalancer

Миграция существующего сервиса типа LoadBalancer на v2 поддерживается без простоя. Чтобы включить режим управления v2 для существующего сервиса:

1. Сохраните конфигурацию сервиса:

   kubectl -n default get service app-lb -o yaml > app-lb-backup.yaml
   

   Запишите адрес балансировщика, состав целевой группы и результаты проверок доступности. Убедитесь, что приложение доступно через балансировщик.

2. Проверьте политику трафика в настройках сервиса:

   kubectl -n default get service app-lb -o jsonpath='{.spec.externalTrafficPolicy}'
   

   Для сокращения целевой группы нужна политика Local. Если установлено значение Cluster, проверьте, подходит ли приложению политика Local. Чтобы перейти на нее, измените spec.externalTrafficPolicy в исходном манифесте сервиса и примените конфигурацию. Со значением Cluster режим v2 не сокращает список целей.

3. Добавьте аннотацию в объект Service:

   kubectl -n default annotate service app-lb \
     yandex.cloud/controller-reconcile-mode=v2 --overwrite
   

   Команда не меняет externalTrafficPolicy. Контроллер обновит облачные ресурсы и удалит ресурсы прежнего режима, когда они больше не используются.

   Если сервис управляется через Helm или GitOps, сохраните аннотацию в исходной конфигурации. Иначе последующая синхронизация может вернуть прежнее значение.

4. Проверьте результат. При переводе нескольких сервисов включайте режим v2 для них по очереди.

Проверьте результатПроверьте результат

После создания сервиса или изменения режима управления целевыми группами в его настройках:

1. Посмотрите настройки и события сервиса:

   kubectl -n default get service app-lb -o yaml
   kubectl -n default describe service app-lb
   

2. Посмотрите размещение подов приложения, сведения о подах в объектах EndpointSlice, связанных с сервисом, и адреса узлов:

   kubectl -n default get pods -l app=demo -o wide
   kubectl -n default get endpointslices \
     -l kubernetes.io/service-name=app-lb -o yaml
   kubectl get nodes -o wide
   

3. Найдите сетевой балансировщик, созданный для сервиса, и посмотрите состав подключенной целевой группы. Для сочетания v2 и Local цели должны соответствовать узлам с подами приложения, выбранными селектором сервиса. Сравнивайте набор узлов, а не количество подов или записей EndpointSlice.

4. Проверьте состояние целевых ресурсов и выполните запрос к приложению через адрес сетевого балансировщика. Если приложение обслуживает HTTP, выполните команду:

   curl http://<ip_адрес_балансировщика>/
   

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

Вернитесь к режиму legacyВернитесь к режиму legacy

Чтобы сетевой балансировщик снова использовал общую целевую группу со всеми узлами кластера, задайте значение legacy в аннотации объекта Service:

kubectl -n default annotate service app-lb \
  yandex.cloud/controller-reconcile-mode=legacy --overwrite

Если сервис управляется через Helm или GitOps, также сохраните изменения в исходной конфигурации. Проверьте результат.

Устранение неполадокУстранение неполадок

Если результат отличается от ожидаемого, проверьте следующие условия:

Если состав группы не соответствует размещению подов после завершения операций, сохраните YAML-описание сервиса, события и время изменения для обращения в техническую поддержку. Не удаляйте системные записи в поле metadata.finalizers и общие целевые группы вручную.

Полезные ссылкиПолезные ссылки

• Целевые группы сетевых балансировщиков
• Обеспечение доступа к приложению, запущенному в кластере Kubernetes
• Поля и аннотации ресурса Service