Связаться с намиПодключиться

Миграция сервисов с балансировщика NLB с целевыми ресурсами из кластера Yandex Managed Service for Kubernetes на L7-балансировщик ALB с помощью консоли управления

Статья создана
Обновлена 23 октября 2025 г.

Важно

Часть ресурсов, необходимых для прохождения практического руководства, доступны только в регионе Россия.

Чтобы мигрировать сервис с сетевого балансировщика на L7-балансировщик:

  1. Ознакомьтесь с рекомендациями по миграции сервисов.
  2. Создайте инфраструктуру для миграции.
  3. Создайте профиль безопасности Smart Web Security.
  4. Установите Ingress-контроллер Application Load Balancer и создайте ресурсы в кластере Managed Service for Kubernetes. На этом этапе вы подключите профиль безопасности Smart Web Security к L7-балансировщику.
  5. Проверьте работу L7-балансировщика.
  6. Мигрируйте пользовательскую нагрузку с сетевого балансировщика на L7-балансировщик.

Рекомендации по миграции сервисов

  1. Подключите защиту от DDoS-атак на уровне L3-L4 (модель OSI). Она станет дополнением к защите на уровне L7, которую после миграции обеспечит Yandex Smart Web Security.

    Чтобы подключить защиту на уровне L3-L4:

    1. Перед миграцией зарезервируйте статический публичный IP-адрес с защитой от DDoS-атак и используйте этот адрес для обработчика L7-балансировщика. Если для сетевого балансировщика публичный IP-адрес с защитой уже есть, его можно сохранить при миграции. В противном случае IP-адрес придется поменять на защищенный.

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

    3. Задайте значение MTU равным 1450 на целевых ресурсах за балансировщиком. Подробнее см. в разделе MTU и TCP MSS.

  2. Проводите миграцию в часы наименьшей пользовательской нагрузки. Если вы решили сохранить публичный IP-адрес, то во время миграции ваш сервис будет недоступен, пока этот IP-адрес переносится с сетевого балансировщика на L7-балансировщик. Обычно это занимает несколько минут.

  3. При использовании L7-балансировщика запросы на бэкенды приходят с IP-адресом источника из диапазона внутренних IP-адресов подсетей, указанных при создании L7-балансировщика. Исходный IP-адрес источника запроса (пользователя) фигурирует в заголовке X-Forwarded-For. Если необходимо логировать публичные IP-адреса пользователей на веб-сервере, измените его конфигурацию.

  4. Перед миграцией определите минимальное количество ресурсных единиц для настройки автомасштабирования в L7-балансировщике.

    Количество ресурсных единиц выберите на основе анализа нагрузки на ваш сервис по следующим показателям:

    • количество запросов в секунду (RPS);
    • количество одновременных активных соединений;
    • количество новых соединений в секунду;
    • объем трафика в секунду.

  5. Функциональные возможности балансировщика Application Load Balancer могут отличаться от возможностей, используемых в вашем балансировщике, развернутом в кластере Managed Service for Kubernetes. Ознакомьтесь с описанием Ingress-контроллера Application Load Balancer и принципами его работы.

  6. Настройте проверки состояния бэкендов на балансировщике Application Load Balancer. Благодаря проверкам состояния балансировщик своевременно отслеживает недоступные бэкенды и направляет трафик на другие бэкенды. После обновления приложения трафик будет снова распределен на все бэкенды.

    Подробнее см. в разделах Рекомендации по настройке проверок состояния Yandex Application Load Balancer и Аннотации (metadata.annotations).

Создайте инфраструктуру

  1. Создайте подсети в трех зонах доступности. Эти подсети будут использоваться для L7-балансировщика.

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

  3. При использовании протокола HTTPS добавьте TLS-сертификат вашего сервиса в Yandex Certificate Manager.

  4. (Опционально) Зарезервируйте публичный статический IP-адрес с защитой от DDoS на уровне L3-L4 для L7-балансировщика.

  5. Сервисы Managed Service for Kubernetes, которые используются в качестве бэкендов, должны иметь тип NodePort. Если ваши сервисы используют другой тип, измените его на NodePort. Подробнее об этом типе см. в документации Kubernetes.

Создайте профиль безопасности Smart Web Security

Создайте профиль безопасности Smart Web Security, выбрав вариант создания По преднастроенному шаблону.

При создании профиля задайте настройки:

  • В поле Действие для базового правила по умолчанию выберите Разрешить.
  • Для правила Smart Protection включите опцию Только логирование (dry run).

С этими настройками информация о трафике будет логироваться, но к трафику не будут применяться никакие действия. Это позволит снизить риск отключения пользователей из-за проблем в настройке профиля. В дальнейшем вы сможете отключить опцию Только логирование (dry run) и настроить правила с запрещающими действиями в профиле безопасности для вашего сценария.

Установите Ingress-контроллер Application Load Balancer и создайте ресурсы в кластере Managed Service for Kubernetes

Совет

Вместо Ingress-контроллера Application Load Balancer рекомендуется использовать новый контроллер Yandex Cloud Gwin.

  1. Установите Ingress-контроллер Yandex Application Load Balancer.

  2. Создайте ресурс IngressClass для Ingress-контроллера L7-балансировщика:

    1. Создайте YAML-файл, в котором опишите ресурс IngressClass.

      Пример ресурса IngressClass:

      apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
  name: ingress-alb
spec:
  controller: ingress.alb.yc.io/yc-alb-ingress-controller

    2. Создайте ресурс IngressClass с помощью команды:

      kubectl apply -f <файл_с_ресурсом_IngressClass>

  3. Создайте ресурс Ingress:

    1. Ознакомьтесь с описанием полей и аннотаций ресурса Ingress и примером.

    2. Создайте YAML-файл, в котором опишите ресурс Ingress:

      1. Заполните раздел annotations для настроек L7-балансировщика:

        • ingress.alb.yc.io/subnets — идентификаторы подсетей в трех зонах доступности для узлов L7-балансировщика. Идентификаторы перечисляются через запятую без пробелов.

        • ingress.alb.yc.io/security-groups — идентификатор одной или нескольких групп безопасности для L7-балансировщика. Идентификаторы нескольких групп перечисляются через запятую без пробелов.

        • ingress.alb.yc.io/external-ipv4-address — зарезервированный ранее статический публичный IP-адрес.

        • ingress.alb.yc.io/group-name — имя группы ресурсов Ingress. Ресурсы Ingress объединяются в группы, каждая из которых обслуживается отдельным экземпляром Application Load Balancer с отдельным публичным IP-адресом.

        • ingress.alb.yc.io/security-profile-id — идентификатор созданного ранее профиля безопасности Smart Web Security.

          Важно

          Профиль безопасности будет привязан к виртуальному хосту L7-балансировщика. Подключение сервиса Smart Web Security невозможно без привязки профиля безопасности к виртуальному хосту L7-балансировщика.

        • ingress.alb.yc.io/autoscale-min-zone-size — минимальное количество ресурсных единиц в каждой зоне доступности в соответствии с ожидаемой нагрузкой на ваш сервис.

      2. Для поля ingressClassName укажите имя созданного ранее ресурса IngressClass.

      3. При использовании протокола HTTPS заполните раздел tls:

        • hosts — доменное имя вашего сервиса, которому соответствует TLS-сертификат.
        • secretName — TLS-сертификат вашего сервиса в Yandex Certificate Manager в формате yc-certmgr-cert-id-<идентификатор_сертификата>.

      4. Заполните раздел rules в соответствии с правилами распределения входящего трафика по бэкендам в зависимости от доменного имени (поле host) и запрашиваемого ресурса (поле http.paths):

        • host — имя домена вашего сервиса.

        • pathType — тип указания на запрашиваемый ресурс:

          • Exact — путь в URI запроса должен совпадать со значением поля path.
          • Prefix — путь в URI запроса должен начинаться со значения поля path.

        • path — путь в URI входящего запроса (если тип Exact) или его начало (если тип Prefix).

        • backend — указание на бэкенд или группу бэкендов, которые должны обрабатывать запросы с указанным доменным именем и путем в URI. Укажите либо сервис-бэкенд (service), либо группу бэкендов (resource), но не оба одновременно:

          • service — сервис Managed Service for Kubernetes, который должен обрабатывать запросы в качестве бэкенда:

            • name — имя сервиса Managed Service for Kubernetes. Ресурс Service, на который указывает это поле, должен быть описан по конфигурации.
            • port — порт сервиса, к которому будет обращаться Ingress. Для порта сервиса укажите либо номер (number), либо имя (name), но не оба одновременно.

            Важно

            Сервисы Managed Service for Kubernetes, используемые в качестве бэкендов, должны иметь тип NodePort.

          • resource — указание на группу бэкендов HttpBackendGroup, которые должны обрабатывать запросы. Бэкендами в такой группе могут быть сервисы Managed Service for Kubernetes и бакеты Yandex Object Storage. При использовании группы бэкендов доступна расширенная функциональность Application Load Balancer. Также можно указывать относительные веса бэкендов для пропорционального распределения трафика между ними.

            • kind — HttpBackendGroup.
            • name — имя группы бэкендов. Оно должно совпадать с именем, указанным в поле metadata.name ресурса HttpBackendGroup. Ресурс HttpBackendGroup, на который указывает это поле, должен быть описан по конфигурации.
            • apiGroup — alb.yc.io.

      Пример ресурса Ingress:

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: <имя_ресурса>
  annotations:
    ingress.alb.yc.io/subnets: <идентификаторы_подсетей_в_трех_зонах_доступности>
    ingress.alb.yc.io/security-groups: <идентификатор_группы_безопасности_L7-балансировщика>
    ingress.alb.yc.io/external-ipv4-address: <статический_публичный_IP-адрес>
    ingress.alb.yc.io/group-name: <имя_группы_ресурсов>
    ingress.alb.yc.io/security-profile-id: <идентификатор_профиля_безопасности_Smart_Web_Security>
    ingress.alb.yc.io/autoscale-min-zone-size: <минимальное_количество_ресурсных_единиц_L7-балансировщика_в_каждой_зоне>
spec:
  ingressClassName: <имя_ресурса_IngressClass>
  tls:
    - hosts:
        - <имя_домена_сервиса>
      secretName: yc-certmgr-cert-id-<идентификатор_сертификата>
  rules:
    - host: <имя_домена_сервиса>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: <имя_сервиса_Kubernetes>
              port:
                number: <443_или_другой_номер_порта>

    3. Создайте ресурс Ingress с помощью команды:

      kubectl apply -f <файл_с_ресурсом_Ingress>

  4. По конфигурации ресурса Ingress будет развернут L7-балансировщик. Дождитесь завершения его создания и привязки к Ingress публичного IP-адреса. Этот IP-адрес понадобится для проверки запросов. Посмотреть информацию о ресурсе вы можете с помощью команды:

    kubectl get ingress <имя_ресурса_Ingress> -w

Проверьте работу L7-балансировщика

Протестируйте запрос к сервису через L7-балансировщик. Например, одним из способов:

  • В файле hosts на рабочей станции добавьте запись <публичный_IP-адрес_L7-балансировщика> <имя_домена_сервиса>. Удалите запись после тестирования.

  • Выполните запрос с помощью cURL в зависимости от типа протокола:

    curl http://<имя_домена_сервиса> \
    --resolve <имя_домена_сервиса>:<порт_сервиса>:<публичный_IP-адрес_L7-балансировщика>

    curl https://<имя_домена_сервиса> \
    --resolve <имя_домена_сервиса>:<порт_сервиса>:<публичный_IP-адрес_L7-балансировщика>

Мигрируйте пользовательскую нагрузку с сетевого балансировщика на L7-балансировщик

Выберите один из вариантов миграции:

Сохранить публичный IP-адрес для вашего сервиса

  1. Если у сетевого балансировщика используется динамический публичный IP-адрес, сделайте его статическим.

  2. В сетевом балансировщике удалите все обработчики для освобождения статического публичного IP-адреса. После этого ваш сервис не будет доступен через сетевой балансировщик.

  3. В L7-балансировщике назначьте обработчику публичный IP-адрес, который ранее был у сетевого балансировщика:

    1. Откройте YAML-файл с описанием ресурса Ingress.

    2. В разделе annotations для поля ingress.alb.yc.io/external-ipv4-address укажите публичный IP-адрес, который ранее был у сетевого балансировщика.

    3. Примените изменения с помощью команды:

      kubectl apply -f <файл_с_ресурсом_Ingress>

  4. Дождитесь завершения изменения публичного IP-адреса у ресурса Ingress. Посмотреть информацию о ресурсе вы можете с помощью команды:

    kubectl get ingress <имя_ресурса_Ingress> -w

    После изменения IP-адреса восстановится доступность вашего сервиса через L7-балансировщик.

  5. Перейдите в L7-балансировщик:

    1. В консоли управления перейдите в каталог, в котором находится кластер Managed Service for Kubernetes.
    2. Выберите сервис Managed Service for Kubernetes.
    3. Выберите нужный кластер.
    4. Слева выберите Сеть, а в правой части — вкладку Ingress. Для вашего Ingress-ресурса в столбце Балансировщик перейдите по ссылке на L7-балансировщик.
    5. Наблюдайте за пользовательской нагрузкой, поступающей на L7-балансировщик, на графиках статистики работы балансировщика.

  6. Удалите освободившийся статический публичный IP-адрес, который был зарезервирован для L7-балансировщика.

  7. (Опционально) После переноса пользовательской нагрузки на L7-балансировщик удалите сетевой балансировщик.

Не сохранять публичный IP-адрес для вашего сервиса

  1. Чтобы мигрировать пользовательскую нагрузку с сетевого балансировщика на L7-балансировщик, в DNS-сервисе, обслуживающем публичную зону вашего домена, измените значение A-записи для доменного имени сервиса на публичный IP-адрес L7-балансировщика. Если публичная зона домена была создана в Yandex Cloud DNS, то измените запись по инструкции.

    Примечание

    Миграция нагрузки может выполняться долго, так как распространение изменений в записи DNS зависит от времени жизни записи (TTL) и количества звеньев цепочки DNS-запросов.

  2. По мере распространения изменений в записи DNS наблюдайте за ростом запросов, поступающих на L7-балансировщик:

    1. В консоли управления перейдите в каталог, в котором находится кластер Managed Service for Kubernetes.
    2. Выберите сервис Managed Service for Kubernetes.
    3. Выберите нужный кластер.
    4. Слева выберите Сеть, а в правой части — вкладку Ingress. Для вашего Ingress-ресурса в столбце Балансировщик перейдите по ссылке на L7-балансировщик.
    5. Наблюдайте за пользовательской нагрузкой, поступающей на L7-балансировщик, на графиках статистики работы балансировщика.

  3. Наблюдайте за снижением нагрузки на сетевой балансировщик с помощью метрик балансировщика processed_bytes и processed_packets. Для визуализации этих метрик можно создать дашборд. Если нагрузка на сетевом балансировщике долгое время отсутствует, то перенос на L7-балансировщик завершен.

  4. (Опционально) После переноса пользовательской нагрузки на L7-балансировщик удалите сетевой балансировщик.

Предыдущая
Обзор
Следующая
Terraform