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

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

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

Сетевой балансировщик Yandex Network Load Balancer может использоваться в составе сервисов внутри кластера Yandex Managed Service for Kubernetes. Кластер самостоятельно создает объекты сетевого балансировщика в соответствии с предоставленными манифестами и следит за составом целевой группы балансировщика, куда попадают виртуальные машины (ВМ) из групп узлов этого кластера.

Одним из вариантов применения сетевого балансировщика в кластере Managed Service for Kubernetes является его использование в составе Ingress-контроллера NGINX.

В этом практическом руководстве рассмотрен переход с сетевого балансировщика на L7-балансировщик Yandex Application Load Balancer, который создается Ingress-контроллером Application Load Balancer, с подключенным профилем безопасности Yandex Smart Web Security.

Схема работы L7-балансировщика с подключенным профилем безопасности Smart Web Security:

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

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

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

  1. Дополнительно к защите от DDoS-атак на уровне L7 модели OSI с помощью Yandex Smart Web Security рекомендуется подключить защиту от DDoS-атак на уровне L3-L4. Для этого заранее зарезервируйте статический публичный IP-адрес с защитой от DDoS-атак и используйте этот адрес для обработчика L7-балансировщика.

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

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

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

    Также задайте значение MTU равным 1450 на целевых ресурсах за балансировщиком. Подробнее см. в разделе Настроить MTU при включении защиты от DDoS-атак.

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

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

  4. Для L7-балансировщика будут созданы по две ресурсные единицы в каждой из подсетей, которые будут указаны при создании ресурса Ingress. В аннотациях Ingress-ресурса не поддерживается указание минимального количества ресурсных единиц L7-балансировщика. Группа ресурсных единиц автоматически масштабируется в зависимости от внешней нагрузки на узлы балансировщика.

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

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

  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

  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:

      • Заполните раздел 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.

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

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

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

      • Заполните раздел 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: <идентификатор_подсети_ru-central1-a,идентификатор_подсети_ru-central1-b,идентификатор_подсети_ru-central1-d>
    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>
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

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

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

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

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

      curl https://<имя_домена_сервиса> \
    --resolve <имя_домена_сервиса>:443:<публичный_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-сервисе, обслуживающем публичную зону вашего домена, измените значение А-записи для доменного имени сервиса на публичный 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-балансировщик удалите сетевой балансировщик.

Предыдущая
Балансировщик NLB с целевыми ресурсами из группы виртуальных машин
Следующая
Балансировщик NLB как целевой ресурс для ALB