Kubernetes Ingress: как настроить маршрутизацию трафика в кластере

Ingress в Kubernetes — это объект API, управляющий внешним доступом к сервисам внутри кластера и обеспечивающий маршрутизацию HTTP/HTTPS-трафика. Трафик напрямую он не обрабатывает, а только задает декларативные правила. За их выполнение отвечает отдельный компонент — Ingress Controller. Он отслеживает ресурсы Ingress и на их основе настраивает прокси или балансировщик нагрузки.

После установки контроллера для каждого объекта Ingress можно задать правила маршрутизации по доменному имени и URL-пути, а также TLS-сертификаты для работы с HTTPS.

Ingress позволяет обойтись без настройки отдельных балансировщиков для каждого сервиса. Достаточно описать правила, которые контроллер будет автоматически применять на уровне сетевой инфраструктуры.

Разберем механику работы Ingress и особенности маршрутизации HTTP и HTTPS-трафика. Также сравним разные способы управления внешним доступом на уровне сети. 

Принцип работы

Важно понимать, что Ingress — это только способ управлять внешним HTTP и HTTPS-доступом к объектам в кластере Kubernetes. Сам по себе он ничего не проксирует, а описывает правила, согласно которым определяются домены и пути отправки запросов к конкретным сервисам. Задача по обработке трафика возлагается на Ingress Controller. Принцип такой:

• Когда пользователь открывает сайт, браузер отправляет запрос на определенный домен. 

• DNS указывает на внешний IP-адрес, за которым стоит Ingress Controller, куда и попадает запрос пользователя. 

• Контроллер проверяет, какой хост и путь указан и на основе правил Ingress выбирает Service. 

• Service направляет трафик к одному из подов приложения. 

Service выбирает нужный под на основе селектора — отслеживает все поды с подходящими метками и распределяет между ними нагрузку. Если какой-то из подов удален или перезапущен, то будет автоматически исключен из маршрутизации. 

Ingress может анализировать доменное имя в заголовке Host и путь в URL, которые указаны в запросе. Также он позволяет управлять множеством микросервисов, используя для внешнего доступа один IP-адрес. 

Для HTTPS в схему добавляется этап TLS-терминации. Устанавливается защищенное соединение с Ingress Controller, который использует механизмы для расшифровки трафика. Происходит стандартное TLS-рукопожатие, после чего контроллер внутри защищенного канала обрабатывает уже расшифрованный трафик и применяет стандартные правила маршрутизации по Host и пути. 

Разница между Ingress, ClusterIP, NodePort и LoadBalancer

В Kubernetes есть несколько способов организации доступа к сервисам. Они решают разные задачи и работают на разных уровнях. Самые распространенные способы управления внешним доступом на уровнях сети:

• ClusterIP — работает на уровнях L3/L4 и позволяет получить доступ к сервису через внутренний IP-адрес внутри кластера. Внешний трафик не фигурирует — связь устанавливается только между подами и сервисами в Kubernetes. 

• NodePort — работает на уровне L4 и открывает определенный порт на каждом узле кластера. Этот способ обеспечивает прямой сетевой доступ без анализа URL и HTTP-заголовков. Запросы поступают на IP-адрес ноды и указанный порт, затем передаются к сервису.

• LoadBalancer — работает на уровне L4 и создает внешний балансировщик нагрузки через облачного провайдера. Применяется в основном для публикации одного сервиса со своим внешним IP-адресом.

• Ingress — работает на уровне L7. Обеспечивает маршрутизацию на основе доменного имени и URL. Позволяет использовать общий внешний IP-адрес для нескольких сервисов. 

Первые три решения обеспечивают доступность сервисов на уровнях IP и портов. Ingress работает на уровне приложения и управляет HTTP и HTTPS-запросами, благодаря чему маршрутизация получается более гибкой.

Первые три решения обеспечивают доступность сервисов на уровнях IP и портов. Ingress работает на уровне приложения и управляет HTTP и HTTPS-запросами, благодаря чему маршрутизация получается более гибкой. 

Контроллеры бывают разных типов, поэтому нужно опираться на особенности проекта и требования к производительности. Рассказываем, из каких решений выбирают чаще всего. 

Популярные решения

Чаще всего в проектах используется одно из трех решений — NGINX Ingress Controller, Traefik или HAProxy. В таблице — их особенности и среды применения:

Выбор конкретного контроллера зависит от архитектуры проекта, требований к производительности и опыта команды. Согласно исследованию IEEE 2024 года, все три решения демонстрируют сопоставимую производительность в типовых сценариях, а ключевые различия проявляются в функциональных возможностях и удобстве эксплуатации.

NGINX Ingress Controller используется в проектах, где важны гибкость настроек и баланс производительности. Traefik выбирают за возможность автоматического обнаружения сервисов и простое управление конфигурацией. HAProxy подходит для критичных систем, где важна предсказуемость работы. 

Выбор подходящего контроллера

Выбор Ingress-контроллера стоит делать с учетом архитектуры проекта, уровня нагрузки и требований к безопасности. Критерии, на которые стоит опираться:

• Тип архитектуры проекта — для классических корпоративных систем подойдут контроллеры с возможностью ручной настройки маршрутизации. Для микросервисных динамических сред лучше выбрать решение с автоматическим обнаружением сервисов.

• Уровень нагрузки — при высокой интенсивности запросов сфокусируйтесь на производительности обработки трафика, низкой задержке и возможности масштабировать решение.

• Совместимость с инфраструктурой — проверьте, поддерживает ли решение работу с используемым оркестратором, облачными платформами и сетевыми компонентами.

• Сложность внедрения и эксплуатации — если не готовы к тонким настройкам, выбирайте решение, которое проще развернуть и в дальнейшем сопровождать.

• Отказоустойчивость — контроллер должен обеспечивать стабильную работу при сбоях отдельных узлов и поддерживать механизмы резервирования.

• Требования к безопасности — проверьте поддержку TLS-терминации, возможность контроля доступа, фильтрации запросов и интеграции с системами защиты сетевого периметра.

Настройка контроллера и балансировщика нагрузки — ответственное дело, поскольку от этого зависит корректность маршрутизации. Учитывайте требования к среде окружения и при установке Ingress Controller действуйте по четкому алгоритму. 

Предварительные требования

Перед установкой убедитесь, что кластер и среда окружения соответствуют рекомендуемым требованиям. Вот основные: 

• Версия Kubernetes. Рекомендуется 1.22 или выше, так как начиная с этой версии удалена устаревшая API-группа networking.k8s.io/v1beta1. API-группа networking.k8s.io/v1 была стабилизирована (GA) еще в версии 1.19, поэтому для работы с Ingress в актуальных версиях Kubernetes достаточно использовать v1. Для production-сред рекомендуется применять поддерживаемые версии (например, 1.30 или выше), следуя политике поддержки поставщика кластера.

• Права доступа. Нужны права администратора кластера (cluster-admin), поскольку установка контроллера затрагивает глобальные ресурсы, такие, как CustomResourceDefinitions (CRD), ClusterRoles и Namespaces.

• Сетевой плагин (CNI). В кластере должен быть настроен CNI-плагин, который поддерживает сетевые политики.

• Доступ к Cloud Provider. Если кластер развернут в облаке, убедитесь, что у сервис-аккаунта есть права на создание внешних балансировщиков нагрузки. 

Установка Ingress Controller

Рассмотрим процесс установки на примере контроллера Ingress NGINX. Рекомендованный способ — действовать через менеджер пакетов Helm. Сначала добавьте официальный репозиторий:

Запустите процесс установки:

По окончании процесса в кластере появится Deployment контроллера и Service для приема внешнего трафика. 

Настройка LoadBalancer для контроллера

Чтобы Ingress Controller принимал внешний трафик, должен быть доступен его Service. В этом поможет LoadBalancer — балансировщик нагрузки. При установке контроллера через Helm по умолчанию создается Service типа LoadBalancer. Проверьте, так ли это:

Вывод покажет примерно такое:

Можно указать тип сервиса самостоятельно:

Kubernetes создает LoadBalancer, облачный провайдер разворачивает внешний балансировщик, который получает публичный IP-адрес. После этого входящий трафик направляется на ноды кластера и обрабатывается Ingress Controller. 

Чтобы маршрутизация выполнялась корректно, нужно создать правила, с учетом которых внешние запросы будут направляться к сервисам внутри кластера. Также следует позаботиться о настройке SSL/TLS для обеспечения защищенного соединения. 

Создание правил Ingress

Правила отвечают за сопоставление входящих путей и хостов с конкретными сервисами. Их описывает Ingress-манифест в формате YAML-файла. Он определяет domain.com — хосты, /api — пути и SSL-сертификаты. Простейший манифест может выглядеть так: 

Согласно правилам, запросы с хоста example.com будут направляться к сервису my-service на порт 80. 

Можно задать правила маршрутизации по URI, если несколько сервисов обслуживаются с одного IP. Пример настройки:

Здесь /api под обслуживанием api-service, а /web — web-service.

Чтобы обслуживать несколько доменов через общий прокси, можно сопоставлять хосты на один Ingress. Перенаправление трафика в этом случае будет идти на разные сервисы. Пример настроек:

Использование SSL/TLS сертификатов

Ingress может выполнять TLS-терминацию. В этом случае HTTPS-трафик расшифровывается на уровне контроллера Ingress, а затем в открытом виде идет в кластер.Чтобы включить эту функцию, нужно создать Kubernetes Secret — объект типа kubernetes.io/tls, где будут храниться сертификат и закрытый ключ. Пример с ключами tls.crt и tls.key:

Kubernetes Secret необходимо указать в секции tls-объекта Ingress.

Полный манифест Ingress с настройкой TLS выглядит следующим образом. Обратите внимание, что секции tls и rules находятся на одном уровне вложенности внутри spec.

Из этого примера следует, что для хоста example.com на порту 443 будет использоваться сертификат из my-tls-secret. 

После настройки правил маршрутизации контролируйте, как Ingress работает в реальной среде. Регулярно анализируйте логи контроллера, следите за состоянием ресурсов. Также применяйте проверенные практики для оптимизации и безопасности Ingress-конфигураций.

Логи и конфигурации

Логи формирует контроллер, который работает в кластере. По умолчанию они доступны через kubectl logs. По логам можно отследить HTTP-запросы и коды ответов, проблемы с сертификатами, изменения конфигурации, ошибки маршрутизации. 

Логирование в каждом решении организовано по-разному. Например, в Ingress NGINX есть access-логи и error-логи. Их формат и тип содержимого можно настраивать через инструмент ConfigMap. 

Практики по оптимизации и безопасности Ingress-конфигураций

Чтобы упростить применение правил, снизить нагрузку на сервисы и минимизировать риски атак, соблюдайте базовые рекомендации:

• Используйте ingressClassName — поле в манифесте Ingress, которое явно указывает, какой контроллер отвечает за определенный ресурс. Это делает конфигурацию предсказуемой и исключает случаи, когда Ingress по ошибке обрабатывается не тем контроллером. 

• Избегайте специфичных аннотаций — из-за них конфигурация становится менее предсказуемой и сложнее поддерживается. 

• Ограничивайте область действия Ingress — лучше задать отдельные правила для разных сервисов, чем объединять все в один Ingress. Такой подход снижает риски ошибок при изменении настроек и упрощает сопровождение. 

• Настройте таймауты соединений и ограничения на размер тела запроса — это снизит риски атак типа Slowloris и нагрузку на backend-сервисы. 

• Используйте защищенное соединение для публичных сервисов — включите автоматическое перенаправление трафика HTTP на HTTPS на уровне контроллера.

Заключение

Ingress в Kubernetes — полноценный проверенный механизм управления внешним трафиком. Он позволяет выстроить прозрачную маршрутизацию и организовать централизованный контроль доступа к внутренним сервисам. Чтобы механизм корректно работал, выберите подходящий контроллер, настройте релевантные правила и следуйте рекомендациям по безопасности.