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
В следующей статье расскажем, что же выбрали и как устроили бесшовный переход.
А вы сталкивались с такой ситуацией? Какой выбор сделали и почему?