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-nginx в долгосрочной перспективе не получится, следующим шагом стало определение требований к новому решению. Нам нужен был инструмент, который стабильно работает с классическим Ingress, поддерживает Gateway API, позволяет мигрировать постепенно и минимально затрагивает текущие сервисы.

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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