[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for Kubernetes](../index.md) > [Пошаговые инструкции](index.md) > Сетевые сценарии > Настройка режима управления целевыми группами сетевых балансировщиков

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

Режим управления целевыми группами настраивается в [сервисе](../concepts/service.md#type) Kubernetes — ресурсе `Service` типа `LoadBalancer`. По настройкам сервиса контроллер Managed Service for Kubernetes автоматически создает сетевой балансировщик нагрузки [Network Load Balancer](../../network-load-balancer/concepts/index.md), который направляет трафик на узлы кластера.

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

Чтобы сократить число проверяемых узлов, для сервиса с политикой `externalTrafficPolicy: Local` можно настроить [режим управления целевыми группами](../concepts/load-balancer-target-groups.md) `v2`. Контроллер создаст для сетевого балансировщика отдельную целевую группу с узлами, на которых размещены поды приложения, и будет обновлять ее. Вы можете задать режим при создании сервиса или настроить в уже существующем.

{% note warning %}

Режим `v2` доступен в [релизном канале](../concepts/release-channels-and-updates.md) `RAPID` и требует предварительного подключения на стороне Yandex Cloud. Для подключения обратитесь в [техническую поддержку](../../support/overview.md) — укажите [идентификатор облака](../../resource-manager/operations/cloud/get-id.md) и [идентификатор кластера](kubernetes-cluster/kubernetes-cluster-list.md#list).

После подключения настройте режим `v2` по [инструкции](configure-load-balancer-target-groups.md).

{% endnote %}

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

1. [Подготовьтесь к работе](#before-you-begin).
1. [Создайте сервис](#create-service) типа `LoadBalancer` или [включите режим](#migrate-service) `v2` и политику `Local` для существующего сервиса.
1. [Проверьте состав целевой группы и доступность приложения](#verify).

## Перед началом работы {#before-you-begin}

1. Убедитесь, что кластер использует [релизный канал](../concepts/release-channels-and-updates.md) `RAPID`. Режим `v2` с политикой `Local` пока доступен только в этом канале.
1. Обратитесь в [техническую поддержку](../../support/overview.md). Укажите [идентификатор облака](../../resource-manager/operations/cloud/get-id.md) и [идентификатор кластера](kubernetes-cluster/kubernetes-cluster-list.md#list). Запросите подключение режима `v2` и дождитесь подтверждения подключения.
1. [Установите kubectl](https://kubernetes.io/ru/docs/tasks/tools/install-kubectl/) и [настройте его на работу с созданным кластером Managed Service for Kubernetes](connect/index.md#kubectl-connect).
1. Проверьте [квоты и лимиты Network Load Balancer](../../network-load-balancer/concepts/limits.md): в режиме `v2` для каждого сервиса с `Local` создается отдельная целевая группа. При необходимости запросите увеличение квот.
1. Проверьте права сервисного аккаунта кластера и группы безопасности по [инструкции подготовки инфраструктуры](create-load-balancer.md#before-you-begin).
1. Подготовьте приложение. В примерах используется приложение в пространстве имен `default`, поды которого имеют метку `app: demo` и принимают TCP-трафик на порте `8080`. Замените эти параметры своими значениями.
1. Проверьте готовность подов и их размещение:

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

## Создайте сервис типа LoadBalancer {#create-service}

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

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

   ```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](../nlb-ref/service.md).

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

   ```bash
   kubectl apply -f app-lb.yaml
   ```

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

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

   Появление адреса еще не подтверждает готовность приложения. [Проверьте результат](#verify).

## Включите режим v2 для существующего сервиса типа LoadBalancer {#migrate-service}

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

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

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

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

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

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

   Для сокращения целевой группы нужна политика `Local`. Если установлено значение `Cluster`, [проверьте, подходит ли приложению политика `Local`](create-load-balancer.md#create-lb). Чтобы перейти на нее, измените `spec.externalTrafficPolicy` в исходном манифесте сервиса и примените конфигурацию. Со значением `Cluster` режим `v2` не сокращает список целей.

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

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

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

   Если сервис управляется через Helm или GitOps, сохраните аннотацию в исходной конфигурации. Иначе последующая синхронизация может вернуть прежнее значение.
   
1. [Проверьте результат](#verify). При переводе нескольких сервисов включайте режим `v2` для них по очереди.

## Проверьте результат {#verify}

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

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

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

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

   ```bash
   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
   ```

1. Найдите сетевой балансировщик, созданный для сервиса, и [посмотрите состав подключенной целевой группы](../../network-load-balancer/operations/target-group-list.md#get). Для сочетания `v2` и `Local` цели должны соответствовать узлам с подами приложения, выбранными селектором сервиса. Сравнивайте набор узлов, а не количество подов или записей `EndpointSlice`.

1. [Проверьте состояние целевых ресурсов](../../network-load-balancer/operations/check-resource-health.md) и выполните запрос к приложению через адрес сетевого балансировщика. Если приложение обслуживает HTTP, выполните команду:

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

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

## Вернитесь к режиму legacy {#rollback}

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

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

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

## Устранение неполадок {#troubleshooting}

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

#|
|| **Проблема** | **Что проверить** ||
|| В группе остаются все узлы | Политику `externalTrafficPolicy`, точное значение аннотации, подключение режима через поддержку и поддержку режима в релизном канале, где находится кластер. При значении политики `Cluster` или размещении подов на всех узлах — это ожидаемое поведение. ||
|| Новый узел не появился в группе | Наличие подов в `EndpointSlice`, события сервиса и состояние облачных операций. ||
|| Узел есть в группе, но не проходит проверку доступности | Готовность подов, параметры сервиса, порт проверки и [группы безопасности](connect/security-groups.md). ||
|| У сервиса нет внешнего адреса | События сервиса, ошибки создания балансировщика, квоты и права сервисного аккаунта кластера. ||
|#

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

#### Полезные ссылки {#see-also}

* [Целевые группы сетевых балансировщиков](../concepts/load-balancer-target-groups.md)
* [Обеспечение доступа к приложению, запущенному в кластере Kubernetes](create-load-balancer.md)
* [Поля и аннотации ресурса Service](../nlb-ref/service.md)