Ingress-NGINX v AKS končí v listopadu 2026: migrace na Gateway API krok za krokem

Většina nucených migrací v Azure je nuda — přepíšete API verzi, změníte SKU, jedete dál. Tahle není. Ingress-NGINX má v AKS obrovskou instalovanou bázi, deadline je tvrdý a náhrada není stejná věc s jiným jménem. Je to jiná datová rovina, jiný objektový model a jiné rozdělení odpovědnosti mezi platformní a aplikační tým.

Tenhle článek je mapa: co přesně končí, co to nahrazuje, jak přeložit anotace, a hlavně co ekvivalent nemá — protože právě ty tři anotace vám migraci prodlouží z týdne na měsíc.

Dvě data, která platí

Po listopadu 2026 vám nic nespadne. Controller poběží dál. Ale nová CVE v NGINX už nikdo neopraví, a to je rozdíl mezi „funguje to" a „projde to auditem". Pokud provozujete cokoliv pod NIS2, PCI DSS nebo interním bezpečnostním standardem banky, je prosinec 2026 datum, kdy máte v clusteru nepodporovanou komponentu na hraně sítě.

Plánujte tedy na říjen 2026 jako reálný cutover, ne na listopad.

Co to nahrazuje

Náhrada je App Routing add-on s implementací Gateway API. Šla GA v AKS release 20260428 a přinesla tři věci:

• GatewayClass jménem approuting-istio — datovou rovinou je Envoy řízený Istiem, spravuje ho Microsoft
• managed instalace Gateway API CRD a controlleru — už si je neinstalujete sami a neřešíte, jestli vám je někdo přepíše
• release 20260529 navíc přidal integraci Azure DNS a Key Vaultu plus strukturované JSON Envoy access logy na stdout jako default

Ta poslední položka je tišší, než si zaslouží. Pokud dnes na každý cluster instalujete cert-manager a external-dns, aby vám ingress uměl TLS a DNS, po migraci je můžete odinstalovat. Certifikát referencujete rovnou z Key Vaultu bez SecretProviderClass a DNS záznam v Azure DNS zóně vznikne sám.

Změna, kterou musíte pochopit dřív než syntax

Ingress byl jeden objekt. Gateway API jsou dva, a dělí se podle toho, kdo je vlastní:

Ingress (1 objekt, vlastní ho ... někdo)
   │
   ├─→ Gateway        ← platformní tým: listenery, porty, TLS, IP adresa
   │                     jeden na cluster nebo na prostředí
   │
   └─→ HTTPRoute      ← aplikační tým: hostname, cesty, backendy, filtry
                         jeden na aplikaci, žije v namespace aplikace

Tohle není kosmetika. Znamená to, že aplikační tým už nemůže sáhnout na TLS konfiguraci ani na sdílenou IP adresu — a naopak, platformní tým už nemusí schvalovat každou změnu cesty. Pokud jste dosud měli jeden Ingress na aplikaci a v něm všechno, migrace vám tenhle rozdíl vnutí, ať chcete nebo ne.

Gateway drží platformní tým:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gw-prod
  namespace: platform
spec:
  gatewayClassName: approuting-istio
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: '*.priklad.cz'
      tls:
        mode: Terminate
        certificateRefs:
          # Key Vault přímo, bez SecretProviderClass
          - kind: Secret
            name: kv-wildcard-priklad-cz
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: 'true'

HTTPRoute drží aplikační tým, ve svém namespace:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api
  namespace: prod
spec:
  parentRefs:
    - name: gw-prod
      namespace: platform
  hostnames:
    - api.priklad.cz
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: svc-api
          port: 8080

Všimněte si allowedRoutes na Gateway. To je bezpečnostní hranice, kterou Ingress neměl vůbec — bez ní si kterýkoliv namespace může připnout route na vaši produkční IP.

Mapování anotací

Tohle je jádro práce. Projděte si svoje Ingress objekty anotaci po anotaci:

Poslední dva řádky jsou ten rozdíl mezi týdnem a měsícem. configuration-snippet je úniková klapka, do které týmy roky lepily všechno, co anotace neuměly — a Gateway API je záměrně typované, takže ekvivalent nebude nikdy existovat. Každý snippet musíte přeložit ručně do Istio konfigurace, nebo ho zrušit.

Audit: zjistěte rozsah dřív, než něco slíbíte

Než dáte odhad, spusťte tohle. Vypíše každou nginx.ingress anotaci v clusteru s počtem výskytů:

kubectl get ingress -A -o json \
  | jq -r '.items[]
      | . as $i
      | (.metadata.annotations // {})
      | to_entries[]
      | select(.key | startswith("nginx.ingress.kubernetes.io/"))
      | "\(.key)"' \
  | sort | uniq -c | sort -rn

Typický výstup ze středně velkého clusteru vypadá takhle:

     34 nginx.ingress.kubernetes.io/rewrite-target
     28 nginx.ingress.kubernetes.io/ssl-redirect
     19 nginx.ingress.kubernetes.io/proxy-body-size
      7 nginx.ingress.kubernetes.io/configuration-snippet
      4 nginx.ingress.kubernetes.io/auth-url
      2 nginx.ingress.kubernetes.io/canary

Prvních dvou se nebojte, ty jsou mechanické. Vaše práce jsou ty spodní tři řádky — a configuration-snippet si musíte přečíst všech sedm, protože v každém je něco jiného.

Druhý dotaz, který chcete mít, najde namespace vlastnící každý dotčený Ingress — to je seznam týmů, se kterými budete mluvit:

kubectl get ingress -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName \
  --no-headers | sort | uniq -c | awk '{print $2}' | sort -u

Fázování, které funguje

Gateway API a Ingress mohou v clusteru běžet vedle sebe. Toho využijte — big-bang cutover tady nedává smysl.

1. Zapněte App Routing s Gateway API a nechte starý NGINX běžet. Nic se nerozbije, jen máte druhou datovou rovinu.
2. Postavte Gateway v platformním namespace, s vlastní IP a certifikátem z Key Vaultu. Otestujte na testovacím hostname.
3. Migrujte aplikace po jedné, od nejjednodušší. Pro každou vytvořte HTTPRoute, ověřte na dočasném hostname, pak přehoďte DNS.
4. Nechte si configuration-snippet aplikace na konec. Ty budete potřebovat Istio konfiguraci a možná i rozhodnutí, že se dané chování ruší.
5. Odinstalujte cert-manager a external-dns až na úplný závěr, když už je z ingressu nikdo nepotřebuje.
6. Smažte NGINX controller a teprve tím je migrace hotová.

Kroky 1–3 zvládnete v běžném sprintu. Krok 4 je ten, který si zaslouží vlastní odhad — a proto ho chcete mít zauditovaný z předchozí sekce dřív, než komukoliv slíbíte termín.

Kde je hranice s Istiem

Pokud stejně směřujete k service mesh, stojí za zvážení jít rovnou tam. Na AKS Automatic s Kubernetes 1.36+ jde vypnout výchozí app-routing add-on a jet Istio add-on s Istio CNI. Dostanete stejné Gateway API, ale s plnou kontrolou nad mesh konfigurací.

Rozhodovací pravidlo, které používám:

• Chcete jen ingress → App Routing. GatewayClass approuting-istio pod kapotou Istio stejně používá, ale spravuje ho Microsoft a vy neřešíte upgrade cyklus.
• Chcete mTLS mezi službami, L7 autorizaci nebo traffic mirroring → Istio add-on rovnou. Jinak byste App Routing stejně za půl roku vypínali.

Pokud na clusteru řešíte i network policy, tenhle rozhovor se překrývá s volbou dataplane — k tomu jsem psal samostatně v článku o migraci z Calico na Cilium.

Co si z toho odnést

Deadline je listopad 2026, ale reálný termín je říjen — chcete mít měsíc rezervy, ne dojíždět na poslední patch. Migrace není drop-in: mění se objektový model i rozdělení odpovědnosti mezi platformní a aplikační tým, což je změna procesu, ne jen YAMLu.

A odhad nedávejte, dokud nespustíte ten audit skript. Rozdíl mezi clusterem, kde je jen rewrite-target a ssl-redirect, a clusterem se sedmi configuration-snippet, je řádový.

Ostatní věci, které chcete mít v AKS clusteru srovnané před takhle velkým zásahem, jsem shrnul v produkčním checklistu pro AKS. Pokud řešíte migraci na Gateway API ve větším prostředí a chcete se poradit o fázování, mrkněte na služby cloudové architektury.

Zdroje

• App Routing: Gateway API GA — AKS blog, 10. 6. 2026
• Azure/AKS issue #5516 — timeline podpory managed NGINX