Если компонент годами "просто работает", можно ли считать его безопасным? История ingress-nginx показывает: нет. Поддержка OSS — такой же архитектурный риск, как single point of failure в проде.

Kubernetes SIG Network и Security Response Committee объявили retirement ingress-nginx в ноябре 2025. Best-effort maintenance шла до марта 2026. После этого: никаких новых релизов, bugfix и security updates.

Важно: Ingress API не умер. Закрыт конкретный community controller ingress-nginx. Установленные инстансы не выключились, а charts, images и код остались доступны. Но новых патчей не будет.

Почему закрыли проект

Maintainers не "бросили" пользователей. Они заранее объявили сроки, сохранили артефакты и предупредили о дальнейшем риске.

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

Параллельно рос technical и security debt. Сила ingress-nginx была в гибкости, но она же стала проблемой. Пример — произвольные NGINX-директивы через "snippets" annotations.

Что произошло с InGate

План был не просто выключить ingress-nginx. Maintainers хотели вместе с Gateway API community сделать замену — InGate.

Но InGate не собрал достаточно участников и не дорос до зрелой замены. Его тоже закрыли.

Управленческий вывод: нельзя строить roadmap на надежде "сообщество потом допишет замену", если нет людей, бюджета и владельца миграции.

Финальная точка

19 марта 2026 вышли последние релизы:

— controller-v1.15.1 — helm-chart-4.15.1 — финальные патчи controller-v1.14.5 и controller-v1.13.9 — chart 4.14.5 и 4.13.9

GitHub API показывает kubernetes/ingress-nginx как archived/read-only. Последний push — 23 марта 2026.

Что делать инженерным командам

Есть два реалистичных пути.

— Быстрый lift-and-shift: остаться на Ingress API, но перейти на поддерживаемый controller. Это снижает срочный security risk, но не убирает зависимость от feature-frozen Ingress API и vendor-specific annotations.

— Стратегический переход на Gateway API. Это дороже: придется переписать routing manifests и проверить поведение. Зато модель лучше ложится на platform engineering: infra/platform команда управляет Gateway, продуктовые команды — HTTPRoute.

Ingress2Gateway 1.0 переводит Ingress resources и часть annotations, отмечая то, что нельзя перенести один в один. Но это помощник, а не кнопка "сделать безопасно".

Практический порядок:

— inventory кластеров и ingress-nginx инстансов — список Ingress resources, annotations, snippets и нестандартных timeout/rewrite/body-size правил — critical traffic и внешние SLA — выбор пути: новый Ingress controller, Gateway API или гибрид — параллельный контур в dev/stage, затем некритичные workloads — метрики эквивалентности: route match, redirects, headers, TLS, latency, 4xx/5xx, rollback time — постепенный shift traffic через DNS, load balancer или platform traffic-splitting

Что делать руководителям

Не сводить это к тикету "обновить ingress".

Правильный вопрос: какие еще компоненты у нас production-critical, но держатся на best-effort OSS без понятной support model?

В банках, бигтехе и регулируемых средах это должно попадать в реестр рисков: владелец, обновления, EOL-мониторинг, security response, fallback и бюджет миграции.

Главная мысль простая: "работает" не равно "безопасно". Если компонент стоит на входе всего трафика, его maintainability — часть вашей системы.

А у вас ingress-nginx уже в плане миграции, или пока живет как "стабильный и не трогать"?

#kubernetes #devops #sre #platformengineering #opensource #security #gatewayapi #ingressnginx #techlead #izagprog