Ingress-nginx долгое время оставался стандартным ingress-контроллером для Kubernetes, но после объявления о завершении активной поддержки многим командам пришлось задуматься о миграции. В этой статье рассказываем, как мы выбирали новый ingress-контроллер.

Почему тема смены ingress-контроллера стала актуальной

Большинство инженеров, работающих с Kubernetes, уже знают, что ingress-nginx уходит на пенсию. В официальном объявлении Kubernetes говорится, что поддержка ingress-nginx продолжится в режиме best-effort до марта 2026 года. После этого проект перестанет получать новые релизы, исправление ошибок и обновление безопасности.

Мы, как и многие команды в отрасли, долгое время использовали ingress-nginx в собственных и клиентских кластерах. Контроллер стабильно работает, хорошо изучен и закрывает базовые задачи маршрутизации трафика. При этом небольшой, но показательный опрос на Reddit показывает, что ingress-nginx до сих пор занимает почти половину рынка.

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

• куда мигрировать 

• какие риски возникают при переходе 

• сколько будет стоить миграция 

• какие ограничения и несовместимости появятся

Ingress API vs Gateway API 

Параллельно в экосистеме Kubernetes развивается новый стандарт публикации сервисов — Gateway API. Постепенно он становится основным направлением развития вместо классического Ingress API.

Gateway API решает задачи, которые раньше приходилось закрывать сложными ingress-конфигурациями, аннотациями и дополнительными механизмами. Если говорить коротко, основная идея Gateway API — более четкое разделение ответственности и более гибкая маршрутизация. В классическом Ingress все обычно описывается в одном ingress-объекте: хост, правила маршрутизации, TLS, иногда дополнительные параметры через аннотации. По мере роста инфраструктуры такие конфигурации становятся все сложнее и хуже масштабируются.

В Gateway API архитектура сразу разделена на несколько логических уровней. Объект Gateway описывает точку входа в кластер для конкретного хоста, а Route-объекты отвечают за правила маршрутизации. Если провести аналогию с nginx:

• Gateway — уровень хоста

• Route — уровень location и маршрутизации внутри него

Такой подход позволяет разным командам независимо управлять своей частью конфигурации и упрощает сопровождение инфраструктуры.

Подробнее про различия API можно прочитать в официальной документации.

При этом переход на Gateway API требует определенных трудозатрат: нужно переписывать манифесты, обновлять Helm-чарты, менять CI/CD-пайплайны и тестировать маршрутизацию и TLS.

Поэтому мы решили разделить миграцию на несколько этапов. Сначала заменить ingress-контроллер на современное поддерживаемое решение с минимальными изменениями текущих сервисов, а затем постепенно переводить инфраструктуру на Gateway API по мере готовности процессов и инструментов.

Так мы снизим риски и не будем совмещать сразу несколько крупных изменений. Дополнительно важно учитывать текущее состояние экосистемы. Многие популярные Helm-чарты, включая Bitnami и другие широко используемые решения, до сих пор ориентированы на классический Ingress и только начинают добавлять поддержку Gateway API. Поэтому Ingress какое-то время останется частью production-инфраструктур, несмотря на развитие нового стандарта.

Наш контекст: инфраструктура и ограничения

Чтобы понять масштаб миграции, важно описать контекст нашей инфраструктуры.

Сейчас в эксплуатации находятся:

• 5 собственных Kubernetes-кластеров 

• более 500 ingress-ресурсов 

• десятки клиентских кластеров в публичных облаках, on-premise инфраструктуре и в средах заказчиков. 

Любые изменения сетевого слоя затрагивают сразу большое количество систем с разными требованиями и уровнем критичности.

Отдельно стоит отметить production-окружения с высокой нагрузкой, где публикация сервисов наружу — критичная часть инфраструктуры. В таких системах любые изменения нужно выполнять максимально аккуратно, без простоев и влияния на пользователей. Это автоматически ограничивает варианты миграции. Нельзя просто переключить контроллер одним релизом или массово переписать конфигурации. Необходим постепенный переход с тестированием и возможностью отката.

Дополнительную сложность создают накопленные ingress-nginx-конфигурации. За годы эксплуатации мы активно использовали аннотации для настройки маршрутизации, безопасности и поведения прокси.

Например:

Механизмы аутентификации и интеграции с внешними сервисами

- auth-url
 - auth-signin 
 - auth-response-headers 

Управление протоколами и поведением backend-сервисов

- backend-protocol 
 - x-forwarded-prefix
 - x-forwarded-proto  Настройки CORS

- enable-cors 
 - cors-allow-origin
 - cors-allow-methods
 - cors-allow-credentials 
 
 Параметры буферизации и таймауты

- proxy-body-size 
 - proxy-buffer-size
 - proxy-buffers-number
 - proxy-connect-timeout
 - proxy-read-timeout
 - proxy-send-timeout
 - client-body-buffer-size
 
 Маршрутизация и переписывания путей

- rewrite-target 

Пользовательские сниппеты конфигурации

- configuration-snippet 

- server-snippet 

Последние два пункта особенно чувствительны при миграции. Они позволяют внедрять произвольные nginx-настройки прямо в конфигурацию ingress и дают очень высокую гибкость. Одновременно это создает сильную зависимость от конкретной реализации контроллера. Такие конструкции практически невозможно перенести на другое решение без изменений, и именно они чаще всего становятся основной точкой сложности при миграции.

Требования к новому ingress / gateway решению

Когда стало понятно, что оставаться на ingress-nginx в долгосрочной перспективе не получится, следующим шагом стало определение требований к новому решению. Нам нужен был инструмент, который стабильно работает с классическим Ingress, поддерживает Gateway API, позволяет мигрировать постепенно и минимально затрагивает текущие сервисы.

– Одним из ключевых критериев была зрелость проекта. Мы смотрели не только на функциональность, но и на активность разработки, частоту обновлений, качество документации и размер сообщества. Это напрямую связано с операционными рисками: чем шире используется решение, тем выше вероятность, что возникающие проблемы уже известны и имеют готовые способы решения.

– Не менее важной были простота и предсказуемость миграции. У нас уже есть сотни ingress-ресурсов и большое количество автоматизации вокруг них: Helm-чарты, пайплайны и шаблоны конфигураций. Поэтому мы искали решение, которое позволит максимально сохранить существующие манифесты и текущее поведение сервисов.

– Отдельно оценивались сложность настройки, удобство эксплуатации, логирование, мониторинг и удобство диагностики. Для production-окружений также критичны производительность и стабильность под нагрузкой, поэтому мы дополнительно изучали результаты нагрузочного тестирования и рекомендации сообщества.

Конечный список требований выглядел так:

• поддержка классического Ingress 

• совместимость с существующими конфигурациями 

• поддержка Gateway API 

• активное развитие проекта 

• минимальные изменения при миграции 

• предсказуемое поведение 

• высокая производительность 

• возможность работы в облаках и on-premise инфраструктуре 

Кандидаты на замену ingress-nginx 

В следующей статье расскажем, что же мы выбрали и как устроили бесшовный переход.

А вы сталкивались с такой ситуацией? Какой выбор сделали и почему?