Принципы работы Ingress-контроллера Application Load Balancer

К Ingress-контроллеру Application Load Balancer для Managed Service for Kubernetes относятся два пода:

• Основной под yc-alb-ingress-controller-* отвечает за создание и изменение ресурсов Application Load Balancer. Отслеживать работу с ресурсами можно по логам этого пода.
• Под для проверок состояния yc-alb-ingress-controller-hc-* с контейнером, который принимает проверочные запросы от L7-балансировщика на TCP-порт 10501 и проверяет работоспособность подов kube-proxy на каждом узле кластера. Суть проверки состояния заключается в том, что когда kube-proxy работоспособен, то даже если приложение в конкретном поде не отвечает, Kubernetes перенаправит трафик в другой под с этим приложением или на другой узел. Эта схема проверки состояния реализована в Ingress-контроллере Application Load Balancer по умолчанию. Также вы можете настроить собственные проверки состояния в параметрах ресурса HttpBackendGroup.

Основной под управляет архитектурой ресурсов Application Load Balancer по следующим правилам:

• Балансировщики и HTTP-роутеры для приема трафика и его распределения между группами бэкендов создаются по ресурсам Ingress.

  Если у нескольких Ingress одинаковые значения аннотации ingress.alb.yc.io/group-name, они объединяются в один балансировщик.

  • Чтобы балансировщик принимал HTTPS-трафик, в поле spec.tls описания Ingress должны быть указаны доменные имена и идентификаторы сертификатов из Certificate Manager:

    spec:
      tls:
        - hosts:
            - <доменное_имя>
          secretName: yc-certmgr-cert-id-<идентификатор_сертификата>
    

    Где secretName — указание на сертификат из Yandex Certificate Manager.

    В этом случае для балансировщика будут созданы обработчики двух видов: одни будут принимать HTTPS-трафик на порте 443, а другие — перенаправлять запросы с HTTP (порт 80) на HTTPS с кодом состояния 301 Moved Permanently. При этом правила распределения трафика для тех же доменных имен, явно указанные в других Ingress, без поля spec.tls, будут иметь приоритет над перенаправлением с HTTP на HTTPS.

    Если сертификат пока не добавлен в Certificate Manager, укажите секрет Kubernetes с сертификатом в поле secretName. Тогда Ingress-контроллер Application Load Balancer автоматически добавит сертификат в Certificate Manager.

  • Если в описании Ingress нет поля spec.tls, для балансировщика будут созданы только обработчики для приема HTTP-трафика на порте 80.

• Группы бэкендов, обрабатывающие полученный трафик, могут создаваться:

  • По сервисам Kubernetes, указанным в правилах Ingress напрямую. Этот способ полезен, если к маршруту нужно привязать простую группу бэкендов, состоящую из одного сервиса.

    В версиях ALB Ingress Controller до 0.2.0 каждая группа бэкендов соответствует связке параметров host, http.paths.path и http.paths.pathType в правилах Ingress. В версиях 0.2.0 и позднее группа бэкендов соответствует параметру backend.service. Из-за этого при обновлении ALB Ingress Controller могут возникнуть коллизии. Чтобы избежать их, узнайте, применимы ли ограничения при обновлении к вашей инфраструктуре.

  • По ресурсам HttpBackendGroup, позволяющим явно описывать группы бэкендов. Это custom resources из группы API alb.yc.io, предоставляемой Ingress-контроллером.

    Указывать на HttpBackendGroup, как и на сервисы, нужно в правилах Ingress (spec.rules[*].http.paths[*].backend.resource).

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

• На бэкендах развертываются сервисы, указанные в Ingress или HttpBackendGroup. Они настраиваются с помощью ресурсов Service.

  Важно

  Сервисы Kubernetes, используемые в качестве бэкендов (указанные в правилах Ingress напрямую или в HttpBackendGroup), должны иметь тип NodePort. Подробнее об этом типе см. в документации Kubernetes.

Соответствие ресурсов Application Load Balancer и KubernetesСоответствие ресурсов Application Load Balancer и Kubernetes

Идентификаторы ресурсов балансировщика в кластере KubernetesИдентификаторы ресурсов балансировщика в кластере Kubernetes

Идентификаторы ресурсов балансировщика Application Load Balancer, развернутого по конфигурации Ingress, указываются в пользовательском ресурсе IngressGroupStatus кластера Managed Service for Kubernetes. Чтобы просмотреть их: