В марте 2026 года проект kubernetes/ingress-nginx официально завершён. Важно не перепутать: это не NGINX как веб-сервер и не коммерческий nginxinc/kubernetes-ingress от F5 — закрыт именно community-контроллер, который годами стоял дефолтным ingress в большинстве кластеров. На практике это значит одно: больше нет ни новых релизов, ни багфиксов, ни — что критичнее — закрытых уязвимостей. Существующие установки продолжают принимать трафик, но это уже unsupported-инфраструктура прямо на периметре кластера.
Почему это срочно: IngressNightmare и blast radius
Это не задача «на следующий квартал». Спусковым крючком ретайра стала IngressNightmare — CVE-2025-1974 с оценкой CVSS 9.8. Admission-webhook контроллера допускал RCE через инъекцию в AdmissionReview, а дефолтные права давали read-доступ ко всем Secrets кластера. Связка очевидна: контроллер на входе, который больше никто не патчит, плюс класс уязвимостей, ведущих к утечке всех секретов сразу. Blast radius — не один сервис, а весь кластер. Каждый день на retired-контроллере — это accepted risk, который растёт с каждой новой CVE без шанса на фикс.
Gateway API: разделение ролей, а не новый логотип
Паниковать и переписывать всё за ночь не нужно — но и тянуть нельзя. Целевая модель уже зрелая: Gateway API стабилизировался к Kubernetes 1.35. И это не «ещё один Ingress с другим логотипом», а другая модель ответственности.
Старый Ingress смешивал инфраструктуру и приложение в одном объекте: TLS, аннотации контроллера и бизнес-роутинг жили вместе, аннотации не переносились между контроллерами, а поведение зависело от вендора. Gateway API разводит роли по владельцам:
GatewayClassиGateway— точка входа и поведение инфраструктуры, владеет platform-команда;HTTPRoute— правила трафика приложения, владеет product-команда.
Canary теперь задаётся полем weight в самом маршруте, а не аннотацией конкретного контроллера, и конфигурация портируема между реализациями. Это и есть главный выигрыш: вы перестаёте быть заложником одного вендора аннотаций.
Как мигрировать: аудит, две стопки, поэтапный cutover
Миграция начинается с аудита, а не с установки. Разложите все объекты Ingress на две стопки. Простые (TLS плюс базовый роутинг) переносятся в Gateway + HTTPRoute почти механически. Сложные — annotation-heavy кейсы с rewrites, canary и canonical-доменами — это кандидаты не на перенос, а на редизайн под модель Gateway API; именно они съедят основное время.
Дальше — параллельная установка. Поднимите новый контроллер рядом со старым и переключайте трафик через ingressClassName поэтапно: сначала non-critical сервисы, затем critical, в конце — high-value. Маршруты на новом контроллере стоит проверить под реальным трафиком до того, как переключите DNS, а не после.
Какой контроллер выбрать
Выбор реализации зависит от платформы: Envoy Gateway (CNCF, нативный Gateway API), Cilium Gateway (если Cilium уже ваш CNI — единая control plane), AWS ALB / Lattice для EKS, а также Traefik или Contour/Kong. Если давит время, рабочий промежуточный шаг — Traefik как drop-in: его Middleware-CRD заменяет «зоопарк аннотаций» переиспользуемыми объектами (rate-limit, basic-auth, CORS, strip-prefix). Но стратегическая цель — именно Gateway API: он переживёт смену контроллера, в отличие от аннотаций.
Не забыть про upgrade hygiene
Ретайр ingress-nginx — частный случай более общей болезни: утечки deprecated-API в апгрейдах. Сделайте сканеры kubent и Pluto обязательным шагом CI перед любым обновлением кластера — тогда следующий «внезапно удалённый» компонент вы увидите заранее, а не в проде.
«Работает» ≠ «поддерживается»
Дедлайн уже позади. Это переводит миграцию из категории «технический roadmap» в категорию «управление риском»: «работает» больше не равно «поддерживается», а на периметре кластера эта разница измеряется в украденных секретах.