Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Предостережение
Сеть SIG Kubernetes и Комитет по реагированию на безопасность объявили о предстоящем выходеиз проекта Ingress NGINX с обслуживанием, заканчивающимся в марте 2026 года. Для кластеров AKS, использующих надстройку маршрутизации приложений с NGINX, немедленные действия не требуются. Корпорация Майкрософт предоставит официальную поддержку критически важных исправлений безопасности для ресурсов ngINX Ingress для маршрутизации приложений до ноября 2026 года.
AKS соответствует вышестоящему Kubernetes путем перехода в API шлюза в качестве долгосрочного стандарта для входящего трафика и управления трафиком L7. Рекомендуется приступить к планированию пути миграции на основе текущей настройки:
- Пользователи надстройки маршрутизации приложений: производственные нагрузки остаются полностью поддерживаемыми до ноября 2026 года. Перейдите на реализацию API шлюза маршрутизации приложений для управления входящим трафиком с использованием API шлюза.
-
Пользователи OSS NGINX имеют несколько вариантов:
- Перейдите на надстройку для маршрутизации приложений с помощью NGINX, чтобы воспользоваться официальной поддержкой до ноября 2026 года, планируя вашу долгосрочную миграцию на Gateway API.
- Перейдите на реализацию API шлюза маршрутизации приложений для управления входящим трафиком с использованием API шлюза.
- Выполните миграцию на шлюз приложений для контейнеров, который поддерживает как Ingress API, так и Gateway API.
- Пользователи сервисной сетки: Если вы планируете использовать сервисную сетку, рассмотрите дополнение к сервисной сетке на основе Istio. Используйте Istio Ingress уже сейчас и планируйте переход на Istio Gateway API, который теперь доступен для общего использования.
Ingress в AKS — это ресурс Kubernetes, управляющий внешним доступом HTTP-подобного трафика к службам в кластере. Механизм входящего трафика AKS может предоставлять такие услуги, как балансировка нагрузки, SSL терминализация и виртуальное размещение с использованием имен. Дополнительные сведения о Kubernetes Ingress см. в документации по Kubernetes Ingress.
Для большинства рабочих нагрузок начните с AKS Automatic. AKS Automatic — это рекомендуемый в AKS вариант по умолчанию для рабочей среды, который предоставляет управляемые параметры по умолчанию для сетевого взаимодействия, масштабирования, безопасности, мониторинга и обновлений. Для входящего трафика это означает, что вы можете начать с пути управляемого входящего трафика и перейти только к более специализированным параметрам, если требуется более глубокий контроль над топологией, поведением маршрутизации или интеграцией сетки служб.
Используйте AKS Standard, если вам нужен более явный контроль над выбором контроллера входящего трафика, топологией развертывания или расширенной сетевой интеграцией.
Режимы кластера AKS и входящий трафик
AKS поддерживает два режима кластера:
- AKS Automatic: Рекомендуемая отправная точка для большинства рабочих нагрузок в рабочей среде. Она снижает эксплуатационные затраты и предоставляет управляемые значения по умолчанию для входящих и связанных сетевых компонентов.
- AKS Standard: лучше всего, если вам нужен явный контроль над размещением контроллера входящего трафика, уязвимостью службы и шаблонами расширенного управления трафиком.
Рекомендации по настройке входящего трафика, приведённые в этой статье, применимы к обоим режимам. Основное различие заключается в том, кто владеет большей частью платформы по умолчанию и сколько настроек необходимо управлять напрямую.
Ингресс-контроллеры
При управлении трафиком приложения инфраструктурные контроллеры предоставляют расширенные возможности, осуществляя операцию на уровне 7. Они могут направлять HTTP-трафик в различные приложения на основе входящего URL-адреса, что позволяет использовать более интеллектуальные и гибкие правила распределения трафика. Например, контроллер входящего трафика может направлять трафик в разные микрослужбы в зависимости от пути URL-адреса, повышая эффективность и организацию служб.
С другой стороны, служба типа LoadBalancer при создании настраивает базовый ресурс балансировки нагрузки Azure. Этот балансировщик нагрузки работает на уровне 4, распределяя трафик к pod'ам в вашей службе по указанному порту. Однако службы уровня 4 не знают о фактических приложениях и не могут реализовать эти типы сложных правил маршрутизации.
Понимание различий между этими двумя подходами помогает выбрать подходящее средство для управления трафиком.
Если вы используете AKS Automatic, сначала начните с управляемого пути входящего трафика и используйте более специализированные параметры только в том случае, если для рабочей нагрузки требуется их. В AKS Standard вы можете выбрать контроллер и топологию входящего трафика, которые лучше всего соответствуют архитектуре.
Сравнение вариантов входа
Сравнение функций
В следующей таблице перечислены различия функций между различными параметрами контроллера входящего трафика. Для большинства производственных рабочих нагрузок AKS рекомендуемым вариантом по умолчанию является подход с управляемым ingress в AKS Automatic, если только вам не требуются настраиваемая маршрутизация, интеграция с service mesh или ingress, размещённый в Azure.
| Функция | Надстройка маршрутизации приложений | Шлюз приложений для контейнеров | сетка службы Azure / сетка службы Istio |
|---|---|---|---|
| Контроллер входящего трафика или шлюза | Контроллер входящего трафика NGINX | Шлюз приложений Azure для контейнеров | Шлюз Istio Ingress |
| API | API входящего трафика | API входа и API шлюза | API Istio Ingress |
| Услуги размещения | В кластере | Размещено в Azure | В кластере |
| Масштабирование | Автомасштабирование | Автомасштабирование | Автомасштабирование |
| Балансировка нагрузки | Внутренний или внешний | Внешнее | Внутренний или внешний |
| Завершение SSL | В кластере | Да: разгрузка и сквозное шифрование SSL | В кластере |
| mTLS | Не применимо | Да: интерфейсная и серверная часть | Да |
| Статический IP-адрес | Да | FQDN (без статического IP-адреса) | Не применимо |
| Хранимые SSL-сертификаты Azure Key Vault | Да | Да | Не применимо |
| Интеграция Azure DNS для управления зонами DNS | Да | Да | Не применимо |
Когда следует использовать каждый контроллер входящего трафика
В следующей таблице перечислены различные сценарии, в которых можно использовать каждый контроллер входящего трафика:
| Вариант входа | Когда следует использовать |
|---|---|
| Managed NGINX — надстройка для маршрутизации приложений | • Размещенные в кластере, настраиваемые и масштабируемые контроллеры входа NGINX. • Основные возможности балансировки нагрузки и маршрутизации. • Внутренняя и внешняя конфигурация подсистемы балансировки нагрузки. • Конфигурация статических IP-адресов. • Интеграция с Azure Key Vault для управления сертификатами. • Интеграция с зонами Azure DNS для общедоступного и частного управления DNS. • Поддерживает API Ingress. |
| Шлюз приложений для контейнеров | • Шлюз для входящего трафика, размещенный на Azure. • Гибкие стратегии развертывания, управляемые контроллером или принести собственный шлюз приложений для контейнеров. • Расширенные функции управления трафиком, такие как автоматические повторные попытки, отказоустойчивость в зонах доступности, взаимная аутентификация (mTLS) с целевым сервером бэкенда, разделение трафика и взвешенный циклический перебор, а также автомасштабирование. • Интеграция с Azure Key Vault для управления сертификатами. • Интеграция с зонами Azure DNS для общедоступного и частного управления DNS. • Поддерживает Ingress API и Gateway API. |
| Шлюз входящего трафика Istio | • На основе Envoy при использовании с Istio для сервисной сети. • Расширенные функции управления трафиком, такие как ограничение скорости запросов и размыкание цепи. • Поддержка mTLS. |
Замечание
В настоящее время надстройка Istio не поддерживает Gateway API для входящего трафика Istio.
Создать ресурс Ingress
Надстройка Application Routing — это рекомендуемый способ настройки контроллера Ingress в AKS, и для большинства рабочих нагрузок именно с этого управляемого варианта ingress следует начинать в AKS Automatic. Надстройка маршрутизации приложений — это полностью управляемый контроллер входящего трафика для AKS, предоставляющий следующие функции:
- Простая настройка управляемых контроллеров входящего трафика NGINX на основе контроллера входящего трафика Kubernetes NGINX.
- Интеграция с Azure DNS для управления общедоступными и частными зонами.
- Завершение SSL с сертификатами, хранящимися в Azure Key Vault.
Для большинства рабочих нагрузок это правильное значение по умолчанию для начала. Если вам нужна настраиваемая топология ingress, ingress, размещённый в Azure, или поведение сетки сервисов, вы можете перейти к одному из других вариантов ingress.
Дополнительные сведения о надстройке "Маршрутизация приложений" см. в надстройке "Управление входящего трафика NGINX" с помощью надстройки "Маршрутизация приложений".
Сохранение IP-адресов источника клиента
Настройте контроллер входящего трафика, чтобы сохранить ИСХОДНЫй IP-адрес клиента для запросов к контейнерам в кластере AKS. Когда контроллер входящего трафика направляет запрос клиента в контейнер в кластере AKS, исходный ИСХОДНЫй IP-адрес этого запроса недоступен целевому контейнеру. Если включить сохранение IP-адресов источника клиента, исходный IP-адрес клиента доступен в заголовке запроса в разделе X-Forwarded-For.
Если вы используете сохранение IP-адресов источника клиента на контроллере входящего трафика, вы не можете использовать сквозную передачу TLS. Сохранение IP-адресов клиента и сквозной протокол TLS можно использовать с другими службами, такими как тип LoadBalancer .
Это остается важным вариантом проектирования как в AKS Automatic, так и в AKS Standard, так как обработка исходных IP-адресов влияет на наблюдаемость, возможность аудита и поведение приложений независимо от режима кластера.
Дополнительные сведения о сохранении IP-адресов источника клиента см. в статье о том, как работает сохранение исходного IP-адреса клиента для служб LoadBalancer в AKS.