Application Gateway for Containers в Azure

Важно: одно название изменилось — Azure Active Directory теперь Microsoft Entra ID. Это не меняет функциональность Application Gateway, но следует учитывать при работе с документацией и ролями доступа.

Что произошло и почему это важно

Недавно Azure Active Directory получила новое имя — Microsoft Entra ID. Это изменение брендинга не влияет на базовые сервисы, но пользователям стоит помнить новое имя при работе с идентификацией и доступом. Параллельно Microsoft анонсировала Application Gateway for Containers — SKU Application Gateway, ориентированный на рабочие нагрузки в Kubernetes. Это логический шаг развития AGIC, направленный на более тесную интеграцию L7 балансировки и динамики контейнерных сред.

Краткое определение

Application Gateway for Containers — это эволюция Application Gateway Ingress Controller (AGIC). По сути, это L7 (HTTP/HTTPS) балансировщик приложений, спроектированный для управления трафиком к подам в Kubernetes-кластерe (AKS) с улучшенной синхронизацией и масштабируемостью.

Компоненты и архитектура

Application Gateway for Containers — основной ресурс SKU в Azure.
Frontends — публичные или приватные фронтенд IP/порт конфигурации, через которые проходит трафик.
Associations — связи между Kubernetes-ресурсами и настройками Application Gateway.

Зависимости при развертывании: приватный IP-адрес, делегирование подсети и пользовательская управляемая идентификация (User-assigned Managed Identity).

Визуализация Application Gateway for Containers в Azure

Схема работы Application Gateway for Containers

Преимущества и сценарии использования

Производительность: почти реальное время сходимости конфигурации — добавление/удаление подов, маршрутов и health-проб отражается быстрее, чем у классического AGIC.
Масштабируемость: превышает текущие ограничения AGIC — более 1400 backend-подов и более 100 listeners.
Гибкость развертывания: ARM/PowerShell/CLI/Bicep/Terraform или полностью декларативное управление из Kubernetes.
Поддержка Gateway API: более выразительный и расширяемый подход к описанию сетевых интерфейсов и политики маршрутизации в Kubernetes.
Взвешенное распределение трафика: позволяет реализовать blue-green, canary и active/active или active/passive схемы.

Когда это особенно подходит

Большие AKS-развертывания с сотнями или тысячами подов.
Требуется быстрая реакция на изменения конфигурации внутри кластера.
Необходима нативная интеграция с Azure Resource Manager и управляемыми идентификациями.

Два подхода к развертыванию

Bring your own (BYO). Ресурсы Application Gateway for Containers, Associations и Frontend создаются и управляются из Azure (портал, CLI, Terraform и т. д.), затем ссылаются в Kubernetes-конфигурациях.
Managed by ALB Controller. ALB Controller, запущенный в Kubernetes, отвечает за lifecycle Application Gateway for Containers: при создании custom resource ApplicationLoadBalancer контроллер создаёт соответствующий ресурс в Azure и поддерживает его.

Поддерживаемые регионы

В начальном релизе Application Gateway for Containers поддерживается в следующих регионах:

Australia East
Central US
East Asia
East US
East US2
North Central US
North Europe
South Central US
Southeast Asia
UK South
West US
West Europe

Как это работает — краткий рабочий процесс

Вы создаёте либо ресурсы Application Gateway в Azure (BYO), либо описываете ApplicationLoadBalancer custom resource в Kubernetes (Managed).
Контроллер синхронизирует изменения Kubernetes-ресурсов (Ingress/Services/Gateway API) с конфигурацией Application Gateway через Azure Resource Manager.
Application Gateway применяет L7 правила, health probes и распределение трафика к backend-подам.

Возможные ограничения и когда это может не подойти

Если ваша платформа привязана к другим облачным балансировщикам (например, multi-cloud, где требуется единая точка входа вне Azure), имеет смысл рассмотреть Azure Front Door или сторонние решения.
Для очень простых кластеров с несколькими подами классический Ingress Controller (NGINX) может быть проще и дешевле.
Если необходима детальная L4 балансировка (TCP/UDP) без L7 фич — Application Gateway может быть избыточен.

Альтернативы и сравнение (микросводка)

AGIC (старое решение): тесная интеграция, но ограниченная масштабируемость и скорость сходимости.
Ingress NGINX / Traefik: хороши для простоты и контроля внутри кластера, не дают немедленной интеграции с ARM.
ALB Controller + Application Gateway for Containers: полный контролируемый жизненный цикл через Kubernetes.
Azure Front Door: глобальный CDN + WAF + L7 с глобальным балансированием, подходит для глобальных точек входа.

Факт-бокс — ключевые числа:

Поддержка более 1400 backend-подов
Более 100 listeners
Доступность в ~12 регионах на старте

Модель принятия решения (Mermaid)

flowchart TD
  A[Нужна L7 балансировка для AKS?] -->|Нет| B[Рассмотрите Ingress NGINX или простой LB]
  A -->|Да| C[Требуется быстрая синхронизация и масштаб?]
  C -->|Да| D[Application Gateway for Containers]
  C -->|Нет| E[AGIC или ALB Controller]
  D --> F{Где управлять ресурсами?}
  F -->|В Azure| G[BYO - создать ресурсы вручную]
  F -->|В Kubernetes| H[Managed by ALB Controller]

Чек-листы по ролям

Архитектор:
- Оценить необходимость L7 фич (WAF, session affinity, path-based routing).
- Сравнить с Azure Front Door при глобальных сценариях.
- Проверить ограничения регионов и соответствие требованиям DR.
DevOps / SRE:
- Решить модель управления (BYO vs Managed).
- Настроить User-assigned Managed Identity и права доступа через RBAC.
- Автоматизировать создание Frontend/Association через Terraform/Bicep при BYO.
- Настроить мониторинг и alerting для health probes и latency.
Команда безопасности:
- Проверить интеграцию с WAF и правилами защиты.
- Убедиться в правильной настройке private IP и подсетей для минимизации экспонирования.

Методология миграции — мини-инструкция

Оцените текущий Ingress и трафик: сколько listeners, сколько backend-подов и требований к SSL/WAF.
Выберите модель (BYO/Managed) и подготовьте инфраструктуру (подсеть, делегирование, Managed Identity).
Разверните в тестовом кластере и прогоните нагрузочные тесты и проверки health.
Переключите трафик постепенно с использованием weighted routing / blue-green.
Наблюдайте метрики и откатывайте по заранее подготовленному плану.

Критерии приёмки

Время сходимости конфигурации соответствует ожиданиям (целевое — близко к реальному времени).
Все маршруты проходят health probes и отвечают корректно.
Латентность и пропускная способность сравнимы с предыдущим решением.
Безопасность (WAF/NSG/подсети) соответствует требованиям компании.

Безопасность и соответствие

Application Gateway for Containers работает поверх Azure Resource Manager и использует User-assigned Managed Identity для доступа. Убедитесь, что права минимально необходимы и что подсети делегированы корректно. При обработке личных данных применяйте общие правила GDPR: минимизация данных, шифрование in transit и at rest, аудит доступа.

Резюме

Application Gateway for Containers — логичное развитие AGIC для сценариев с высокой динамикой и масштабами в AKS. Оно объединяет возможности L7 балансировки, более быструю синхронизацию и различные варианты управления ресурсами (BYO или Managed). Перед миграцией оцените требования к масштабируемости, latency и географии трафика; протестируйте модель в staging и подготовьте rollback-планы.

Примечание: если вы уже используете AGIC, план миграции можно разбить на этапы: тестирование, частичное переключение через взвешенное распределение, полный cutover.

Поделитесь в комментариях: какие у вас сценарии для L7 балансировки в AKS и планируете ли вы переход на Application Gateway for Containers?