Ingress NGINX больше не получает патчей с марта 2026: как проверить кластер и куда переезжать
Контроллер, через который в Kubernetes заходит трафик на сайты, перестал чиниться, и при этом он продолжает спокойно работать, так что тревоги не будет.
Kubernetes (система, которая запускает и перезапускает контейнеры с приложениями на группе серверов) сам по себе не знает, как пустить на сайт посетителя из интернета. Для этого в кластер ставят отдельную программу — Ingress-контроллер: она принимает запросы снаружи и раздаёт их нужным приложениям. Самый распространённый такой контроллер — Ingress NGINX. В ноябре 2025 года блог Kubernetes объявил о его закрытии: поддержка по мере сил шла до марта 2026, после этого — ни релизов, ни исправления багов, ни закрытия уязвимостей.
Сейчас октябрь 2026, срок прошёл. По странице репозитория, он заархивирован 24 марта 2026 и доступен только для чтения. Если у компании сайт или API крутятся в Kubernetes, стоит выяснить, на чём они стоят.
Почему закрыли проект, который стоит почти везде
В январе 2026 Комитеты Kubernetes (управляющий и по реагированию на уязвимости) назвали Ingress NGINX критичной инфраструктурой примерно для половины cloud-native-окружений. Причина закрытия при этом житейская: по словам авторов блога, проект держался на одном-двух людях, которые занимались им в свободное время. Запланированная замена InGate так и не созрела и тоже будет закрыта.
Вторая причина — сама гибкость. Часть возможностей, например «сниппеты» (аннотации, в которые можно вписать произвольный кусок конфигурации NGINX), в Kubernetes теперь считают серьёзным риском для безопасности.
Работать продолжит, а чинить будет некому
Авторы подчёркивают: уже развёрнутые установки не сломаются, а Helm-чарты (пакеты для установки в Kubernetes) и образы контейнеров остаются доступными. Именно поэтому проблема коварная. Ничего не падает, мониторинг зелёный, а если в контроллере найдут новую уязвимость, исправления не будет. Контроллер стоит на границе кластера и смотрит в интернет, то есть это самое неудачное место для неподдерживаемого софта.
Готовой замены «один в один» нет: в январском заявлении Комитетов сказано, что ни одна из альтернатив не является прямой заменой. Разработчики Kubernetes советуют переходить на Gateway API — новый стандарт маршрутизации трафика. Кому нужно остаться на Ingress, есть список других контроллеров в документации.
Шаг 1. Выяснить, стоит ли он в кластере
Первая команда — проверка из блога Kubernetes, запускать её нужно с правами администратора кластера. Вторая и третья показывают, какие классы Ingress есть и какие ресурсы вообще используются:
Если первая команда вернула поды — контроллер стоит. Пустой ответ не гарантия: селектор рассчитан на стандартную установку, при нестандартных метках вывод будет пустым. Тогда смотреть на колонку CONTROLLER во второй команде. Облачные кластеры от провайдера могут нести свой контроллер или ставить этот скрытно, поэтому лучше спросить поддержку. Обычный NGINX на отдельном сервере закрытие не затрагивает.
Шаг 2. Составить опись и понять, что именно используется
Из третьей команды получается список всех Ingress. Для каждого полезно записать: домены, где завершается TLS (шифрование HTTPS), и есть ли аннотации — особенно с префиксом nginx.ingress.kubernetes.io. Именно они не переезжают сами: в руководстве Gateway API сказано, что функции, привязанные к аннотациям и выходящие за рамки стандарта, зависят от выбранной реализации. Их соответствие придётся искать в её документации.
Отдельно блог Kubernetes выпустил материал о том, что у Ingress NGINX есть неочевидные умолчания и побочные эффекты, которые, скорее всего, есть в любом работающем кластере. Перед миграцией его стоит прочитать: Before You Migrate.
Шаг 3. Понять, как устроен Gateway API
В Ingress один ресурс описывает всё сразу. В Gateway API обязанности разделены: Gateway описывает точки входа (порты, TLS), а HTTPRoute — маршруты к приложениям. Первым обычно владеет администратор кластера, вторым — команда разработчиков. По руководству по миграции, порядок такой:
- завести Gateway со слушателями на портах 80 и 443 и привязать к HTTPS-слушателю секрет с сертификатом;
- перенести маршруты в HTTPRoute, привязав их к слушателю через parentRefs;
- редирект с HTTP на HTTPS сделать отдельным HTTPRoute с фильтром RequestRedirect;
- вместо бэкенда по умолчанию добавить явное правило для префикса / — прямого аналога в Gateway API нет.
Нюанс: в Ingress у каждого хоста свои правила, а правила одного HTTPRoute действуют на все его хосты. Этот документ при этом честно предупреждает, что не готовит к миграции без простоя.
Шаг 4. Автоматический конвертер — только черновик
Проект Ingress2Gateway переводит ресурсы Ingress в Gateway API, и в марте 2026 вышла его версия 1.0. В руководстве по миграции прямо написано, что результат конвертации нужно всегда тестировать и проверять. Значит, сначала прогнать на тестовом кластере, сравнить поведение со старым и только потом переключать трафик.
Что проверить у себя
- Выяснить, стоит ли в кластерах Ingress NGINX, включая тестовые и забытые, а у управляемого Kubernetes — спросить провайдера.
- Записать все Ingress и их аннотации и отметить те, у которых нет поля в Gateway API.
- Выбрать реализацию Gateway API или другой поддерживаемый Ingress-контроллер и прочитать, как в нём делаются нужные функции.
- Прогнать конвертер на копии конфигурации и проверить результат руками.
- Назначить срок отключения старого контроллера: «работает» — не причина его оставлять, патчей для него больше не будет.
Разборы аварий и практику для админов публикуем в Telegram-канале «Полный Ops».