Жизнь после ingress-nginx

Если ваш кластер до сих пор пускает трафик через ingress-nginx, вы эксплуатируете софт, который больше некому чинить. Репозиторий заархивирован 24 марта 2026 года. Не будет ни новых релизов, ни исправлений багов, и самое главное — не будет никаких патчей безопасности, ни для одной уязвимости, никогда. В тот день ничего не сломалось, и в этом-то и проблема: ingress продолжает работать, поэтому ничто не заставило вас шевелиться.

Это руководство написано после дедлайна, а не до него. В нём: как измерить масштаб проблемы четырьмя командами, как выбрать цель по фактам, а не по ощущениям, какие поведения ingress-nginx при переводе молча меняют смысл, и какая последовательность выката позволяет вернуть трафик обратно, если новый data plane повёл себя не так.

Что произошло на самом деле — и что не произошло

Хронология короткая, и её стоит воспроизвести точно, потому что пересказы её изрядно исказили. SIG Network Kubernetes и Security Response Committee объявили о выводе из эксплуатации 11 ноября 2025 года. 29 января 2026 года Steering Committee и SRC усилили формулировки в необычно прямом совместном заявлении: остаться на Ingress NGINX после его вывода из эксплуатации — значит оставить себя и своих пользователей уязвимыми для атаки, и ни одна из доступных альтернатив не является прямой заменой.^{[retire][steering]}

Последнюю строку чаще всего понимают неправильно. Ingress API не является устаревшим. В документации сказано, что он находится в статусе general availability, что проект не планирует его удалять и что он просто заморожен — никаких дальнейших изменений и обновлений. Ваши объекты Ingress в networking.k8s.io/v1 — валидный Kubernetes и останутся таковыми. Умер конкретный контроллер, который их читает.^[ingressdoc]

Что вы наследуете, если остаётесь

Проще всего оценить риск по тем исправлениям безопасности, которые проект выпустил в последние недели. 2 февраля 2026 года — через четыре дня после заявления Steering и за семь недель до перевода репозитория в режим только для чтения — SRC раскрыл четыре уязвимости в ingress-nginx: CVE-2026-1580, CVE-2026-24512, CVE-2026-24513 и CVE-2026-24514. Наиболее серьёзные получили оценку HIGH 8.8 и были исправлены в v1.13.7 и v1.14.3.^[advisory]

CVE-2026-24512 — та, которую стоит запомнить. Через поле rules.http.paths.path объекта Ingress можно было инжектировать конфигурацию в NGINX, что вело к произвольному выполнению кода в контексте контроллера и к раскрытию всех Secret, которые контроллер может прочитать, — а в установке по умолчанию это все Secret кластера. Временной мерой был validating admission controller, отклоняющий Ingress с path type ImplementationSpecific. Обратите внимание, что этот класс уязвимости требует от атакующего: возможности создать Ingress. Любой, у кого есть права на запись в неймспейсе, подходит.^[cve24512]

Дальше было ещё две, и именно они достраивают аргумент. CVE-2026-3288, раскрытая 9 марта 2026 года с оценкой HIGH 8.8, — инъекция конфигурации через аннотацию rewrite-target, ту самую, о которой предупреждает таблица семантики ниже; исправлена в v1.13.8, v1.14.4 и v1.15.0. Затем CVE-2026-4342, раскрытая 19 марта 2026 года, с той же оценкой 8.8 и тем же вектором: инъекция конфигурации через комментарии, снова с выполнением кода в контроллере и раскрытием Secret по всему кластеру. Исправлена в v1.13.9, v1.14.5 и controller-v1.15.1. То есть в финальном релизе. Последнее, что этот проект вообще выпустил, — патч безопасности, за пять дней до перевода репозитория в режим только для чтения. Всё, что появится дальше, не получит ничего.^{[cve3288][cve4342][lastrel]}

Для оценки верхней границы есть прецедент — CVE-2025-1974, «IngressNightmare», март 2025 года, CVSS 9.8. Проект Kubernetes описал её прямым текстом: что угодно в сети подов имело хорошие шансы захватить кластер, без всяких учётных данных. Для той был патч. Для следующей его не будет.^[nightmare]

Существующие развёртывания продолжат работать, поэтому, если вы не проверите это сами, вы можете узнать, что затронуты, только после компрометации.^[steering]

О масштабе: Steering Committee и SRC заявляют, что около 50 % cloud native окружений зависят от этого контроллера, ссылаясь на внутреннее исследование Datadog. Считайте это ориентиром, а не измерением — исходный набор данных не опубликован и отражает окружения под мониторингом Datadog, — но порядок величины подтверждается собственной оценкой проекта за 2025 год: «более 40 % кластеров Kubernetes». В любом случае это не задача из разряда мелкой уборки.

Проверьте, затронуты ли вы

До любого планирования — измерьте. Первая команда взята из публикаций самого проекта Kubernetes; остальные три показывают реальный объём работ, потому что стоимость этой миграции определяется не количеством объектов Ingress, а количеством различных аннотаций за ними.

# 1. The check the Kubernetes project itself publishes
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# 2. Which controller image, and therefore which version, is actually running
kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'

# 3. How much surface you have to translate: every Ingress bound to it
kubectl get ingress -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.ingressClassName}{"\n"}{end}'

# 4. The real cost driver - the annotations, ranked by how often you use them
kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep -F 'nginx.ingress.kubernetes.io/' | sort | uniq -c | sort -rn

Четвёртая команда и есть оценка. Кластер с шестьюдесятью Ingress и четырьмя аннотациями — это один вечер. Кластер с двенадцатью Ingress и двадцатью двумя аннотациями, включая configuration-snippet, — это проект, и вы только что выяснили почему.

Выберите цель до того, как трогать YAML

Честных вариантов три, и правильный зависит от того, насколько сильно вы на самом деле завязаны на поведение ingress-nginx. Что полезно знать до составления шорт-листа: единственные Ingress-контроллеры, которые Kubernetes как проект поддерживает и сопровождает, — это контроллеры AWS и GCE. Всё остальное из документированного списка — Traefik, HAProxy, Contour, Kong, APISIX, Cilium, Higress, Istio и прочие — сторонние решения. И ещё: kubernetes/ingress-nginx на той странице больше вообще не значится.^[ctrldoc]

Если идёте путём Gateway API: текущий релиз — v1.6.0, тег поставлен в конце июня 2026 года, анонс вышел 3 августа 2026 года. TCPRoute и UDPRoute в этом релизе перешли из Experimental в Standard в версии v1, присоединившись к Gateway, GatewayClass, HTTPRoute, GRPCRoute, TLSRoute, ListenerSet, ReferenceGrant и BackendTLSPolicy. Версии v1alpha2 для TCPRoute и UDPRoute объявлены устаревшими с v1.6 и будут удалены. Ставьте текущий патч — v1.6.1 от 16 июля 2026 года, а не v1.6.0. По версиям кластера: проект не публикует жёсткой нижней границы, его заявленная политика — поддерживать пять последних минорных версий Kubernetes. Сверяйтесь с этой политикой, а не с числом из чьего-то поста.^{[gw16][gw16rel][gw161][versioning]}

Одно структурное изменение в v1.6 стоит учесть при планировании: новые экспериментальные ресурсы теперь живут в отдельной API-группе gateway.networking.x-k8s.io, а имена типов получают префикс X — XBackend, XMesh. При переходе в Standard тип переименовывается в gateway.networking.k8s.io и теряет префикс. Это осознанный сигнал: если kind, на который вы собираетесь опереться, начинается с X, это не обещание продакшена.^[gw16]

Выбирайте по фактам. Проект Gateway API публикует по каждому релизу отчёты о соответствии, где указано ровно столько, сколько нужно: какое количество расширенных возможностей проходит каждая реализация по каждому типу маршрута. Эта таблица — инструмент отбора лучше любой сравнительной страницы вендора, включая эту статью. Смотрите строку той версии, которую собираетесь запускать, а не прошлогодней. Учтите: не каждая реализация подаёт отчёт к каждому релизу, поэтому отсутствующая строка означает «нет отчёта для этой версии», а не «не соответствует спецификации».^[conform]

Отдельно про реалии, в которых работает часть читателей: если коммерческая подписка и вендорская поддержка недоступны, вариант «купить контракт на поддержку» просто выпадает из списка. Практический вывод — при отборе смотрите не только на функциональность, но и на то, сможете ли вы сопровождать выбранный data plane самостоятельно: насколько понятны его логи и метрики, насколько активен апстрим, есть ли внятный путь обновления без внешней подписки. По той же причине заранее уточните, какой контроллер предлагает ваш провайдер управляемого Kubernetes и на какую версию Gateway API он сертифицирован: на управляемой платформе темп миграции чаще задаёт цикл обновления самой платформы, а не ваш бэклог.

Пять поведений, которые не переживают перевод

Именно здесь миграции идут не так, и этот раздел стоит прочитать, даже если цель уже выбрана. ingress-nginx накопил поведения, которых никогда не было в спецификации Ingress, от которых ваши приложения теперь молча зависят и которые не воспроизводит ни одна соответствующая спецификации реализация Gateway API. Проект Kubernetes задокументировал пять из них специально, чтобы избавить людей от этого открытия.^[gotchas]

На практике больнее всего бьёт редирект по завершающему слешу, потому что он не падает громко. Запросы на /api, которые раньше редиректились на /api/, теперь возвращают 404 от приложения, и ошибка всплывает в логах вашего сервиса, а не на границе — так что первая гипотеза будет «баг в сервисе», а не «вчерашняя миграция».

ingress2gateway: что он конвертирует, а что — нет

Официальный конвертер существует, и он стал заметно лучше. ingress2gateway вышел в версии 1.0 20 марта 2026 года как подпроект SIG Network. Главное изменение: покрытие аннотаций ingress-nginx выросло с трёх до более чем тридцати, включая CORS, TLS до бэкенда, сопоставление по регулярным выражениям и переписывание путей. В 1.0 также добавили интеграционные тесты уровня контроллера, которые поднимают настоящий ingress-nginx и настоящий контроллер Gateway API в живых кластерах и сравнивают их поведение во время работы, а не просто диффят YAML.^[i2gblog]

# Install the official converter (Go 1.25.5 or newer to build from source)
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# or: brew install ingress2gateway

# Convert a manifest on disk, without touching the cluster
ingress2gateway print --input-file ingress.yaml \
  --providers=ingress-nginx > gwapi.yaml

# Convert one namespace from a live cluster
ingress2gateway print --namespace shop \
  --providers=ingress-nginx > gwapi.yaml

# Convert everything, and keep the warnings - they are the migration backlog
ingress2gateway print --all-namespaces \
  --providers=ingress-nginx > gwapi.yaml 2> unsupported.log

Поддерживаются девять провайдеров — ingress-nginx, nginx, traefik, kong, istio, apisix, cilium, gce и openapi — и шесть эмиттеров вывода, среди них envoy-gateway и kgateway. Вывод ориентирован на Gateway API v1.5.0. Чего инструмент за вас не сделает:^[i2g]

• configuration-snippet и server-snippet — не поддерживаются, аналога не существует. Произвольные директивы NGINX — ровно то проектное решение, которое проект Kubernetes назвал источником «непреодолимого технического долга». Если в ваших сниппетах зашита бизнес-логика, её придётся переносить в приложение, в фильтр или в policy-CRD конкретной реализации.^[retire]
• proxy-body-size — аналога в Gateway API нет. Настраивается на уровне data plane, а значит становится специфичным для реализации и перестаёт быть переносимым.
• proxy-read-timeout / proxy-send-timeout — отображение по принципу best-effort в timeouts.request, что не одно и то же. Перемеряйте под нагрузкой, а не предполагайте паритет.
• Нормализация URL — через стандартный Gateway API не настраивается вовсе. Если вы на неё полагались, вы полагались на data plane, и это нужно проверять для каждой реализации отдельно.

Читайте предупреждения инструмента как бэклог миграции, а не как шум. Всё, что он пишет в stderr, — это поведение, которое он не смог перенести, и каждое из них — инцидент в проде, ожидающий смены DNS.

Ingress и Gateway API рядом

Минимальный, но реалистичный пример: один хост, TLS и путь, разделённый между API и веб-фронтендом. Смысл поставить их рядом в том, что версия на Gateway API длиннее — и эта лишняя длина не церемония, а то самое поведение, которое ingress-nginx давал вам неявно, теперь выписанное явно.

Было — один Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-example-com-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Стало — один Gateway и два HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop-gateway
  namespace: shop
spec:
  gatewayClassName: nginx          # must match an installed GatewayClass
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: shop.example.com
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      protocol: HTTPS
      port: 443
      hostname: shop.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - group: ""              # empty string = core API group
            kind: Secret
            name: shop-example-com-tls
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: https
  hostnames: [shop.example.com]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-service
          port: 80
---
# ingress-nginx redirected HTTP to HTTPS for you. Gateway API does not.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route-ssl-redirect
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: http
  hostnames: [shop.example.com]
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 308

Три вещи, на которые стоит обратить внимание. sectionName привязывает маршрут к конкретному listener — так вы разделяете поведение HTTP и HTTPS. allowedRoutes — это разделение ролей, которого у Ingress API никогда не было: платформенная команда владеет Gateway и решает, какие неймспейсы могут к нему подключаться, а команды приложений владеют своими HTTPRoute. А третий объект существует только для того, чтобы воспроизвести редирект, который ingress-nginx делал по умолчанию, — и это, пожалуй, честное резюме всей миграции.^[gwapi]

Переключение, которое реально можно откатить

Самое полезное свойство этой миграции — оба контроллера могут работать одновременно. Это разные объекты, они следят за разными ресурсами и стоят за разными балансировщиками. Ничто не заставляет переключаться разом, так что не делайте этого.

1. Поставьте новый контроллер рядом со старым. Отдельный GatewayClass, отдельный неймспейс, собственный Service типа LoadBalancer и собственный внешний адрес. Трафик по-прежнему идёт в ingress-nginx.
2. Сконвертируйте и вычитайте. Запустите ingress2gateway на один неймспейс, прочитайте предупреждения и руками доделайте аннотации, которые он не смог перевести. Не применяйте вывод, не прочитав его.
3. Примените объекты Gateway API с теми же хостами. Для пользователей пока ничего не меняется — у нового контроллера свой IP, и ни одна DNS-запись на него не указывает.
4. Сравните две границы напрямую через --resolve, запрос за запросом: коды ответов, цели редиректов, заголовки и отдельно случаи с завершающим слешем и регулярными выражениями. Именно этот шаг ловит пять поведений выше.
5. Переводите DNS постепенно — запись с низким TTL, взвешенная политика или сначала один некритичный хост. Пусть ingress-nginx продолжает обслуживать трафик, пока новая граница не переживёт реальный пик.
6. Выводите из эксплуатации осознанно. Удалите Deployment ingress-nginx, его Service, его IngressClass и его ValidatingWebhookConfiguration. Оставленный admission-вебхук — это классический способ получить сломанный кластер через несколько недель.

# Install the Standard channel CRDs (server-side apply, as the project documents)
kubectl apply --server-side -f \
  https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/standard-install.yaml

# The Gateway must be Programmed before you move any traffic to it
kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.conditions[?(@.type=="Programmed")].status}{"\n"}'

# Every parentRef must be Accepted, and every backendRef ResolvedRefs.
# Nested ranges keep each condition paired with its own status.
kubectl get httproute shop-route -n shop -o jsonpath='{range .status.parents[*]}{.controllerName}{"\t"}{range .conditions[*]}{.type}={.status}{" "}{end}{"\n"}{end}'

# Compare old and new on the same request, before DNS moves.
# A cloud load balancer publishes either .ip or .hostname - AWS uses .hostname,
# so --connect-to is used instead of --resolve: it accepts both.
OLD=$(kubectl get svc -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}{.status.loadBalancer.ingress[0].hostname}')
NEW=$(kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.addresses[0].value}')
for edge in "$OLD" "$NEW"; do
  curl -sS -o /dev/null -w "$edge  %{http_code}  %{redirect_url}\n" \
    --connect-to "shop.example.com:443:$edge:443" https://shop.example.com/api
done

Обратите внимание на условие Programmed во второй команде. Существующий Gateway — ещё не обслуживающий Gateway; условия в status и есть контракт, и проверить их дешевле, чем обнаружить разницу во время смены DNS.

ingress-nginx, NGINX Ingress и NGINX Gateway Fabric

Три разных проекта, похожие названия — и реальный источник неверных решений именно во время этой миграции. Кто-то мигрирует с ingress-nginx на «NGINX Ingress», считая, что что-то изменил, и удивляется позже; кто-то, наоборот, вычёркивает NGINX целиком, полагая, что все три умерли вместе.

Проекту Kubernetes пришлось прописать это отдельно: оба используют NGINX как data plane, но в остальном никак не связаны. Переход с community-контроллера на контроллер F5 — это полноценная миграция со своей работой по переводу аннотаций, а не переименование.^[gotchas]

Что бы я сделал на этой неделе

Если ещё не начинали: сегодня же выполните четыре команды диагностики, потому что количество аннотаций — единственное число, которое скажет вам, это вечер или квартал. Если ответ «вечер», сделайте это на этой неделе и перестаньте нести риск. Если ответ «квартал», полезное действие всё равно то же: поставить второй контроллер параллельно уже сейчас и перенести один некритичный хост — потому что именно на первой миграции вы выясняете, какие из ваших допущений на самом деле были поведением ingress-nginx.

Более общий вывод я уже описывал в скучных облачных архитектурах: больнее всего бьют те компоненты, о которых никто не думает, — именно потому, что они годами работают. Ingress-контроллер, который поддерживали один-два волонтёра и который стоял перед половиной cloud native мира, был концентрацией риска задолго до архивации. Стоит проверить, что ещё в вашем стеке имеет такую же форму, — и спросить, как в статье о том, когда не стоит использовать Kubernetes, оправдывает ли платформа ту операционную поверхность, в которую она вам обходится.

Частые вопросы

Безопасно ли пока оставить ingress-nginx?

Он работает и продолжит работать. Но он больше никогда не получит патч безопасности — и стоит посмотреть, чем на самом деле был финальный релиз: controller-v1.15.1 — это исправление CVE-2026-4342, инъекции конфигурации, доходившей до выполнения кода в контроллере и раскрытия Secret по всему кластеру, выпущенное в день публикации бюллетеня и за пять дней до перевода репозитория в режим только для чтения. Это была шестая такая ошибка за семь недель. У следующей исправления не будет. Если приходится держать его ещё несколько недель, как минимум ограничьте круг тех, кто может создавать объекты Ingress, отберите у контроллера доступ к Secret на уровне кластера, если ваша установка его выдаёт, и не выставляйте наружу admission-вебхук.

Ingress API в Kubernetes тоже устарел?

Нет, и это самое частое заблуждение. Ingress API находится в статусе general availability с обычными гарантиями стабильности GA, и проект Kubernetes заявил, что не планирует его удалять. Он заморожен: развитие прекращено. Из эксплуатации вывели только community-контроллер NGINX, а не API, который он реализует.

В чём разница между ingress-nginx и nginx-ingress?

Это разные проекты разных организаций. kubernetes/ingress-nginx сопровождался сообществом Kubernetes и заархивирован. nginx/kubernetes-ingress — это NGINX Ingress Controller от F5, он активно развивается. Формулировка самого проекта Kubernetes: оба используют NGINX как data plane, но в остальном никак не связаны. Переход с одного на другой — полноценная миграция, а не переименование.

Может ли ingress2gateway мигрировать кластер автоматически?

Частично. Версия 1.0 покрывает более тридцати аннотаций ingress-nginx вместо прежних трёх и является правильной отправной точкой. Но configuration-snippet не имеет аналога и не поддерживается, у proxy-body-size нет эквивалента в Gateway API, таймауты прокси отображаются только по принципу best-effort, а нормализация URL не выражается вовсе. Прочитайте всё, что он пишет в stderr, — этот вывод и есть ваша оставшаяся ручная работа.

Переходить на Gateway API или просто сменить Ingress-контроллер?

Смена контроллера быстрее и сохраняет существующие объекты, но вы приземляетесь на замороженный API и всё равно переписываете каждую аннотацию на новом диалекте — то есть, скорее всего, сделаете это ещё раз. Gateway API — большая переработка, но именно там идёт разработка, и он даёт разделение ролей между платформенной командой, владеющей Gateway, и командами приложений, владеющими своими маршрутами. Большой парк простых Ingress склоняет к смене контроллера; общая граница на несколько команд — к Gateway API.

Какую реализацию Gateway API выбрать?

Выбирайте по опубликованным отчётам о соответствии, а не по маркетинговым страницам. Проект Gateway API по каждому релизу указывает, сколько именно расширенных возможностей проходит каждая реализация для HTTPRoute, GRPCRoute и TLSRoute. Смотрите отчёт по той версии, которую действительно собираетесь запускать, убедитесь, что реализация поддерживает конкретно те возможности, в которые превратились ваши аннотации, и что она поддерживается на вашей платформе.

Нужно ли обновлять Kubernetes перед установкой Gateway API?

Проект не публикует фиксированной минимальной версии Kubernetes; его заявленная политика — поддерживать пять последних минорных версий, поэтому сверяйтесь с ней, а не с числом из чьего-то поста. Устанавливайте CRD канала Standard из текущего патч-релиза — v1.6.1 от 16 июля 2026 года — через server-side apply, как это документирует сам проект. Если ставите канал Experimental, его CRD в любом случае слишком велики для клиентского kubectl apply, а экспериментальные типы теперь несут префикс X в отдельной API-группе — как раз чтобы вы случайно не построили на них продакшен.

Та же дисциплина применима и к криптографии уровнем ниже: в статье про постквантовые SSH и TLS описано, что проверять на соединениях, от которых зависят эти системы.

Источники

Каждое утверждение выше прослеживается до одного из этих источников. Только первичные и официальные: публикации и документация проекта Kubernetes, состояние репозиториев, бюллетени безопасности и спецификация Gateway API.

1. Kubernetes blog — Ingress NGINX Retirement: What You Need to Know (11 Nov 2025)
2. Kubernetes blog — Ingress NGINX: Statement from the Steering and Security Response Committees (29 Jan 2026)
3. Kubernetes blog — Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know (27 Feb 2026)
4. GitHub — kubernetes/ingress-nginx (public archive, read-only since 24 Mar 2026)
5. GitHub — ingress-nginx controller-v1.15.1, the final release (19 Mar 2026)
6. Kubernetes Security Response Committee — [Security Advisory] Multiple issues in ingress-nginx (2 Feb 2026)
7. kubernetes/kubernetes#136678 — CVE-2026-24512, configuration injection via the Ingress path field
8. kubernetes/kubernetes#137560 — CVE-2026-3288, configuration injection via the rewrite-target annotation
9. kubernetes/kubernetes#137893 — CVE-2026-4342, comment-based configuration injection (fixed by the final release)
10. Kubernetes blog — Ingress-nginx CVE-2025-1974: What You Need to Know (24 Mar 2025)
11. Kubernetes documentation — Ingress (the API is generally available and frozen)
12. Kubernetes documentation — Ingress Controllers
13. Gateway API — API overview and channel status
14. Kubernetes blog — Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard (3 Aug 2026)
15. GitHub — Gateway API v1.6.0 release notes
16. GitHub — Gateway API v1.6.1, the current patch release (16 July 2026)
17. Gateway API — v1.6 conformance reports by implementation
18. GitHub — kubernetes-sigs/ingress2gateway
19. Kubernetes blog — Announcing Ingress2Gateway 1.0: Your Path to Gateway API (20 Mar 2026)
20. GitHub — nginx/kubernetes-ingress, the F5 NGINX Ingress Controller (a different project)
21. GitHub — nginx/nginx-gateway-fabric, F5's Gateway API implementation
22. Gateway API — versioning, release channels and graduation criteria