Konec Ingress NGINX: jak naplánovat migraci na Gateway API

Co přesně skončilo a co ne

Kubernetes SIG Network a Security Response Committee oznámily 11. listopadu 2025, že údržba Ingress NGINX poběží v režimu „best effort“ do března 2026. Poté podle oznámení nebudou žádné další verze, žádné opravy chyb a žádné aktualizace řešící bezpečnostní zranitelnosti. Stávající nasazení fungují dál a instalační artefakty zůstávají dostupné.

Stav k říjnu 2026: repozitář na GitHubu byl 24. března 2026 archivován a je jen pro čtení. Poslední řada v tabulce podporovaných verzí je v1.15.1 s NGINX 1.27.1 a podporou Kubernetes 1.31 až 1.35.

Tři věci se často pletou, proto je dobré je oddělit:

• Končí komunitní controller ingress-nginx (projekt Kubernetes), ne NGINX jako takový a ne komerční NGINX Ingress Controller od F5, což je jiný produkt s jinou konfigurací.
• Nekončí Ingress API. Objekty Ingress v clusteru fungují dál a oznámení výslovně připouští i přechod na jiný Ingress controller. Jako moderní náhradu ale projekt doporučuje Gateway API.
• Nic se samo nevypne. Právě proto je riziko zrádné: provoz běží, jen přestal mít kdo opravovat chyby.

Dosah je velký. Společné prohlášení Steering Committee a Security Response Committee z 29. ledna 2026 uvádí s odkazem na interní výzkum Datadogu, že na tomto nástroji stojí zhruba 50 % cloud native prostředí. A dodává větu, která určuje povahu celé migrace: žádná z dostupných alternativ není přímou „drop-in“ náhradou.

Proč nestačí „zatím to běží“

Ingress controller je komponenta vystavená do internetu, která typicky smí číst Secrets napříč namespacy. Historie ingress-nginx ukazuje, jak často se v ní závažné chyby objevovaly.

• Březen 2025: IngressNightmare. Wiz zveřejnil sadu čtyř zranitelností (mj. CVE-2025-1974, CVSS 9.8) umožňujících neautentizované vzdálené spuštění kódu a převzetí clusteru. Podle Wizu bylo zranitelných asi 43 % cloudových prostředí a přes 6 500 clusterů vystavovalo admission controller do internetu.
• Březen 2026: CVE-2026-4342. Pět dní před archivací byla zveřejněna injekce konfigurace přes kombinaci anotací (CVSS 8.8) vedoucí ke spuštění kódu v kontextu controlleru a k úniku Secrets. Opravená je ve verzích v1.13.9, v1.14.5 a v1.15.1, tedy v posledních, které kdy vyšly.
• Květen 2026: CVE-2026-42945 („NGINX Rift“). Přetečení haldy v modulu rewrite samotného NGINX, podle shrnutí The Hacker News s CVSS v4 9.2. Postižen je NGINX Open Source 1.0.0 až 1.30.0, oprava je ve verzích 1.30.1 a 1.31.0.

Třetí bod je první zkouškou stavu „po konci podpory“. NGINX 1.27.1, který ingress-nginx v1.15.1 obsahuje, spadá do postiženého rozsahu a archivovaný projekt novou verzi s opraveným NGINX nevydá.

K technickému riziku se přidává auditní. Správa zranitelností předpokládá, že pro nalezenou chybu existuje cesta k opravě; u archivovaného projektu taková cesta není a jedinou odpovědí zůstává kompenzační opatření nebo výměna komponenty. Více k procesu v článku o řízení zranitelností.

Výběr cíle: Gateway API, nebo jiný Ingress controller

Gateway API už není experiment. Verze 1.5, vydaná 27. února 2026, přesunula do kanálu Standard mimo jiné ListenerSet, TLSRoute, CORS filtr pro HTTPRoute a ověřování klientských certifikátů. Verze 1.6 z 30. června 2026 přidala do Standard kanálu TCPRoute a UDPRoute. Řada věcí, které se v ingress-nginx řešily anotací nebo ConfigMapou, má dnes typované pole v API.

Aktuální stav implementací sleduje oficiální přehled s výsledky konformance. V době psaní jsou jako konformní vedeny mimo jiné Envoy Gateway, Cilium, NGINX Gateway Fabric, Traefik Proxy, Istio, kgateway a GKE; AWS Load Balancer Controller je veden jako částečně konformní.

Azure (AKS)

Pokud používáte spravovaný NGINX v application routing add-onu, máte tvrdý termín: Microsoft podle dokumentace AKS přestane spravovaný NGINX po listopadu 2026 podporovat a migraci na implementaci Gateway API nebo jinou podporovanou implementaci je potřeba dokončit do listopadu 2026. To je za několik týdnů. Nástupcem je implementace Gateway API v témže add-onu, postavená na control plane Istio, který spravuje jen infrastrukturu pro Gateway API; dokumentace ji označuje jako doporučený výchozí model pro produkci a od AKS 1.36 je výchozí v nových clusterech AKS Automatic. Mezi uvedenými omezeními je, že nenabízí limity velikosti hlaviček a těla požadavku, Lua skripty ani rate limiting a nelze ji zapnout současně s add-onem Istio service mesh. Alternativou je Application Gateway for Containers.

AWS (EKS)

AWS Load Balancer Controller má od 6. března 2026 obecně dostupnou podporu Gateway API: HTTPRoute a GRPCRoute nad ALB, TCPRoute a UDPRoute nad NLB. Specifika AWS se místo anotací nastavují přes CRD LoadBalancerConfiguration, TargetGroupConfiguration a ListenerRuleConfiguration. Pozor na rozdíl v architektuře: ALB není proxy v clusteru, takže se mění model nákladů i limity pravidel.

Kdy zůstat u Ingress API

Legitimní protiargument: Ingress API funguje a velká migrace pod časovým tlakem je sama o sobě riziko. Traefik má například provider, který čte řadu anotací ingress-nginx a míří přesně na tento scénář. Je to rozumný mezikrok, pokud ho tak i pojmenujete a ověříte, že pokrývá právě vaše anotace. „Řada“ neznamená „všechny“.

Inventura: kolik práce to opravdu je

Rozsah migrace neurčuje počet Ingress objektů, ale počet různých anotací a globálních nastavení. Začněte třemi dotazy:

# 1. Běží v clusteru ingress-nginx? (příkaz z prohlášení Kubernetes)
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# 2. Které anotace se používají a kolikrát
kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep nginx.ingress.kubernetes.io | sort | uniq -c | sort -rn

# 3. Globální nastavení controlleru
kubectl get configmap -n ingress-nginx -o yaml

Výsledek roztřiďte do tří skupin:

• Má standardní ekvivalent: přesměrování, přepis cesty, hlavičky, CORS, TLS k backendu, váhy.
• Řeší se rozšířením konkrétní implementace: rate limiting, externí autentizace, timeouty, limity velikosti těla.
• Nemá ekvivalent: configuration-snippet, server-snippet, Lua. Tady nejde o překlad, ale o přepsání záměru, případně o přesun logiky do aplikace.

Třetí skupina je nejlepší prediktor pracnosti.

Do inventury patří i to, co na ingress navazuje: cert-manager (issuery a solvery vázané na Ingress), external-dns, WAF, dashboardy a alerty postavené na metrikách NGINX, formát access logů, zachování zdrojové IP adresy a allowlisty na straně partnerů.

Pět chování, která se nepřenesou sama

Nejhorší migrační chyby nevznikají z anotací, které vidíte, ale z výchozího chování, o kterém nikdo neví. Kubernetes k tomu vydal samostatný článek o pěti překvapivých vlastnostech Ingress-NGINX:

• Regex cesty jsou prefixové a nerozlišují velikost písmen. Vzor, který vypadá jako přesná shoda, zachytí i delší cesty.
• Anotace use-regex platí pro všechny cesty daného hostu napříč všemi Ingress objekty, ne jen pro ten, kde je uvedena.
• rewrite-target implikuje regex, a to se stejným dosahem na celý host.
• Požadavek bez koncového lomítka dostane přesměrování 301 na cestu s lomítkem, pokud je pravidlo definováno pro cestu s lomítkem na konci.
• URL se před vyhodnocením pravidel normalizují.

Gateway API se chová striktněji a předvídatelněji. Po přepnutí tak může část provozu začít dostávat 404, nebo naopak přestane platit pravidlo, které nechtěně fungovalo jako ochrana. Ke každému hostu proto sepište skutečné cesty z access logů a udělejte z nich testovací sadu.

ingress2gateway: dobrý start, ne hotová migrace

Ingress2Gateway 1.0 vyšel 20. března 2026. Zatímco dřívější verze uměly tři anotace ingress-nginx, verze 1.0 jich pokrývá přes 30 (CORS, backend TLS, regex, přepis cest a další). Projekt má integrační testy, které pouští skutečný controller Ingress-NGINX vedle několika implementací Gateway API a porovnávají chování za běhu, ne jen strukturu YAML. Verze 1.1 z dubna 2026 přidala anotace from-to-www-redirect, app-root a ssl-passthrough (převádí se na TLSRoute), aktuální je verze 1.2.0 z července 2026.

# Převod všech Ingress objektů z běžícího clusteru
ingress2gateway print --providers=ingress-nginx --all-namespaces > gwapi.yaml

# S rozšířeními konkrétní implementace
ingress2gateway print --providers=ingress-nginx \
  --namespace my-api --emitter envoy-gateway > gwapi.yaml

Nejcennějším výstupem jsou varování. Nástroj upozorní, že configuration-snippet nepodporuje, že proxy-body-size nemá v Gateway API ekvivalent a že normalizace URL se mezi implementacemi liší a standardem ji nastavit nelze. Seznam varování je váš skutečný backlog.

Postup migrace bez výpadku

Princip je stejný jako u jiných změn v cestě provozu: nový controller postavit vedle starého, ověřit ho na reálných požadavcích a provoz převádět postupně s možností okamžitého návratu. Stejný postup doporučuje i oznámení Ingress2Gateway 1.0: ověření ve vývojovém clusteru a postupný přesun provozu přes vážené DNS, cloudový load balancer nebo traffic splitting.

1. Nainstalujte CRD Gateway API a zvolený controller vedle ingress-nginx. Dostane vlastní LoadBalancer a vlastní IP adresu; stávající provoz se nemění.
2. Vytvořte Gateway a HTTPRoute pro první, málo kritickou službu. Staré Ingress objekty ponechte beze změny.
3. Vyřešte TLS předem. Certifikát musí být na nové Gateway platný dřív, než na ni přijde první požadavek. Pozor na ACME HTTP-01 výzvy, které míří tam, kam ukazuje DNS.
4. Testujte proti nové IP adrese sadou cest z access logů: curl --resolve app.example.com:443:NOVÁ_IP https://app.example.com/cesta. Porovnávejte stavové kódy, přesměrování a hlavičky, ne jen „odpovídá to“.
5. Snižte TTL DNS záznamů s dostatečným předstihem (migrační návod pro AKS uvádí 60 sekund).
6. Přepínejte postupně: váženým DNS, nebo na úrovni CDN či externího load balanceru, pokud ho před clusterem máte. Sledujte míru chyb 4xx a 5xx a latenci proti stavu před změnou.
7. Rollback mějte jako jeden krok: vrácení DNS záznamu. Proto starý controller nemažte hned.
8. Úklid až po stabilizaci: smazání Ingress objektů, IngressClass, admission webhooku, Helm release a starých dashboardů.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
  namespace: my-api
spec:
  parentRefs:
    - name: public
      namespace: gateway-system
  hostnames: ["api.example.com"]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /v1 }
      backendRefs:
        - name: api-v1
          port: 8080

Postupné přepínání má dvě slabiny, se kterými je potřeba počítat. Dlouhá spojení (WebSocket, gRPC streamy) zůstanou na starém controlleru, dokud se neukončí. A dokud běží oba controllery, existují dvě cesty do clusteru, takže bezpečnostní politiky, WAF pravidla i síťová pravidla musí platit pro obě. Obecné zásady nasazování bez výpadku shrnuje článek Kubernetes zero-downtime deployment.

Když migraci do konce roku nestihnete

U velkých prostředí je to realistický scénář. Pak jde o to snížit plochu útoku a mít rozhodnutí zdokumentované.

Poslední bod bývá přehlížený. Neudržovaný controller se časem stane překážkou upgradu clusteru, takže se z jednoho dluhu stanou dva. Plánujete-li upgrade, řešte ingress ve stejném plánu (viz upgrade Kubernetes).

Existují i komerční nabídky prodloužené podpory nebo vlastní fork. Fork znamená převzít sestavování image a sledování CVE v NGINX, OpenSSL, Lua modulech i Go závislostech. Je to trvalý závazek, který je potřeba ocenit střízlivě.

Klíčové poznatky

• Projekt je uzavřený. Repozitář ingress-nginx je od 24. března 2026 archivovaný; poslední verze je v1.15.1 a další nebudou.
• Riziko už není teoretické. CVE-2026-42945 v NGINX z května 2026 se týká rozsahu verzí, do kterého přibalený NGINX 1.27.1 spadá, a upstream oprava nepřijde.
• Drop-in náhrada neexistuje. Říká to přímo prohlášení řídicích orgánů Kubernetes. Počítejte s projektem, ne s výměnou Helm chartu.
• Pracnost určují anotace a skryté chování, ne počet Ingress objektů. Inventura je první krok a zabere hodiny, ne týdny.
• ingress2gateway zrychlí začátek, ale jeho varování jsou seznam práce, která zbývá na lidech.
• Migrujte paralelně a postupně. Nový controller vedle starého, test proti nové IP, přepínání přes DNS, rollback jedním krokem.
• Na AKS se spravovaným NGINX platí termín listopad 2026: poté ho Microsoft přestane podporovat.