Принципы работы 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 по умолчанию. Чтобы контролировать работу приложений на всех подах, вы можете настроить собственные проверки состояния.
Важно
Не изменяйте напрямую ресурсы Application Load Balancer, созданные основным подом контроллера. Любые изменения будут автоматически отменены. Вместо этого пользуйтесь стандартными способами управления кластером Managed Service for Kubernetes.
Основной под управляет архитектурой ресурсов 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
из группы APIalb.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 |
---|---|
Балансировщик | Набор ресурсов Ingress с одинаковыми значениями аннотации ingress.alb.yc.io/group-name |
Виртуальные хосты HTTP-роутера | Ingress.spec.rules |
Маршруты виртуального хоста | Ingress.spec.rules[*].http.paths |
Группа бэкендов | HttpBackendGroup или набор сервисов |
Целевая группа | Группа узлов кластера |
Идентификаторы ресурсов балансировщика в кластере Kubernetes
Идентификаторы ресурсов балансировщика Application Load Balancer, развернутого по конфигурации Ingress
, указываются в пользовательском ресурсе IngressGroupStatus
кластера Managed Service for Kubernetes. Чтобы просмотреть их:
- В консоли управления
выберите каталог, в котором создан нужный кластер Managed Service for Kubernetes. - В списке сервисов выберите Managed Service for Kubernetes.
- Выберите кластер Managed Service for Kubernetes, по конфигурации
Ingress
которого был создан балансировщик. - На странице кластера Managed Service for Kubernetes перейдите на вкладку
Пользовательские ресурсы. - Выберите
ingressgroupstatuses.alb.yc.io
и перейдите на вкладку Ресурсы. - Выберите ресурс с именем группы ресурсов
Ingress
, указанным в аннотацииingress.alb.yc.io/group-name
, и перейдите на вкладку YAML.
-
Установите kubectl
и настройте его на работу с созданным кластером. -
Выполните команду:
kubectl describe IngressGroupStatus