19. listopadu 2025

Kubernetes Ingress-NGINX odchází do důchodu

Letos (v roce 2025) na KubeConu v Londýně, maintaineři Kubernetes projektu Ingress-NGINX (open-source Ingress controller, přímo od Kubernetes projektu) oznámili, že bude ukončen jeho vývoj a následně i jeho podpora. Náhradou za Ingress-NGINX měl být projekt InGate.

Původní časový plán vypadal takhle:

InGate měl být náhradou, která s sebou nenese technický dluh a není to "maintenance hell", jak tomu je u Ingress-NGINXu. Zároveň měl InGate podporovat nejen Ingress API, jehož vývoj je zastavený od Kubernetes v1.19, které vyšlo v srpnu 2020, ale i nové Gateway API. Jako HTTP proxy měl zůstat NGINX, vedle kterého by paralelně běžel controller v Go, sledující změny v Kubernetes clusteru.

InGate ale vypadá mrtvě. Lépe řečeno nikdy neoživnul. Projekt má 39 commitů za celý rok a několik posledních je jen od Dependabota.

Všechno je jinak

Nakonec, jak tomu bývá, je všechno jinak. Ingress-NGINX přechází do maintenance režimu už v březnu 2026. To bylo nedeávno oznámeno Kubernetes Blogu. Společně s Ingress-NGINXem končí i InGate u kterého se nepodařilo projekt nakopnout a zároveň udržet Ingress-NGINX na přechodnou dobu.

Tím se tedy všichni, kdo používáme Ingress-NGINX dostáváme do dost nepříjemné situace.

Další kroky

Co Kubernetes projekt doporučuje (a já taky), je zmigrovat na jiné řešení, a to co nejdříve, protože Ingress-NGINX skončí a žádné opravy chyb nebo nové verze nebudou. A to všechno nastane už v březnu 2026, což je odteď za pět měsíců!

Vhodná náhrada za Ingress-NGINX

Obecně univerzální náhradní řešení není. Ono totiž záleží, co používáte, co potřebujete. Co je váš use-case. Pokud vám stačí Ingress a chcete toho co nejméně měnit, tak výměna za jiný Ingress controller je ta nejlepší možnost. Na webu Kubernetes je seznam Ingress controllerů.

Mám v plánu vyzkoušet několik Ingress controllerů, které jsou podobné nebo nabízejí podobné funkce jako měl Ingress-NGINX a které já a moji klienti využíváme (redirecty, rewrite URL, rate limiting, proxy body size (pro nahrávání souborů na server), timeouty, integrace s Cert-Managerem, metriky pro Prometheus, WAF ochranu (třeba přes ModSecurity nebo Coraza). A to vše ideálně v open-source verzi.

Po průzkumu existujících controllerů jsem skončil u následujících možností:

Pokud chcete použít Gateway API, koukněte se na následující implementace:

Za mě je Gateway API dělané spíš pro SaaS služby a mikroslužby. Prostě počítá s Gateway, na které jsou napojené všechny routy, které se nasazují společně s aplikací.

Seznam všech Gataway API implementací mají zde na webu.

Doporučení, čím Ingress-NGINX nahradit

Za nejlepší/nejsnažší náhradu, pokud chci zůstat u Ingress API považuju:

  1. Traefik – jednodychý, má vlastní dashboard, umí řešit HTTPS automaticky (nepotřebuju Cert-Manager)
  2. HAProxy Ingress – snadná migrace, umí skoro všechno co Ingress-NGINX, tak by to neměl být extra bolehlav

Pokud chcete jít do Gateway API, podívejte se na:

  1. Envoy Gateway – za mě jednoznačně nejvíc funkcí snadno a rychle (globální (na celou gateway) rate limiting, lokální (na konkrétní Route – HTTPRoute, GRPCRoute,...) rate limiting, retry, circuit breaking, autentizace – Basic Auth, JWT, OIDC, traffic management: traffic spliting, request mirroring,...), navíc je plně open-source pod CNCF bez enterprise edice (a tedy placených funkcionalit)
  2. Istio – umí toho také spoustu a pokud uvažujete o Service Mesh, dokážete zabít dvě mouchy jednou ranou

Pozor, pokud u Gateway API, potřebujete několik domén s HTTPS a nechcete jeden certifikát pro všechny domény, kde je pak možné se velmi snadno podívat, jaké domény jsou pro certifikát platné a zjistit tak informace o vaší aplikaci, které třeba nechcete zveřejňovat.

Pokud se chcete tomto problému vyhnout, musíte na Gateway mít několik listenerů na portu 443 a pro každý zvlášť mít dedikovaný certifikát a to vše pak mapovat na správné routy. Tím přicházíte prakticky o veškerou flexibilitu z hlediska rozdělení vlastnictví Gateway a rout – Gateway vlastní platformní tým a routy teamy vlastnící aplikace. A vlastně je to spíš use-case pro běžný Ingress. Plus, pro padesát domén by tohle už bylo třeba hodně pracné nebo třeba pro multi-tenantní aplikace na různých doménách nevhodné.

Gateway API není náhrada za Ingress ve smyslu "1:1", je potřeba udělat změny.

Na pomoc s migrací z Ingressu na Gateway API existuje nástroj ingress2gateway a Gateway API má o migraci i stránku v dokumentaci.

Čemu bych se naopak vyhnul, je Cilium řešení, jak pro Ingress tak pro Gateway API. Mrzí mě to, protože Cilium mám moc rád a má spoustu skvělých fičur. Ale Ingress a Gateway API je hrozné – vyzkoušeno za vás. Je to prakticky nesrovnatelné s Ingress-NGINXem co se fičur týče, neumí to URL rewrite, redirect, proxy body size a další užitečné a skoro bych i řekl základní věci.

Envoy jako nástupce NGINXu

Na závěr malý postřeh.

Prakticky všichni dnes používají Envoy místo NGINXu. Výjimkou je HAProxy Ingress, používá (nečekaně) HAProxy, NGINX Gateway Fabric & NGINX Ingress controller, které používají NGINX a Traefik.

Jinak všichni ostatní používají Envoy. I třeba Istio používá Envoy jak v sidecar, tak v ambient (DaemonSet režim pro proxy) režimu, kde Envoy propojuje služby a aplikuje L7 (HTTP) politiky. Nebo Cilium, u kterého je možné zapnout Envoy jako proxy, což je podmínka pro používání Ingressu a Gateway API, ale lze tím spravovat L7 CiliumNetworkPolicy. Cool.

Envoy je open-source HTTP (L7) proxy, která dnes patří pod CNCF a je "Graduated project".

Kubernetes školení

Zajímá Vás Kubernetes a chcete se dozvědět víc? Jak pracovat s Kubernetes, jak spravovat cluster, jak nasadit aplikaci do Kubernetes atd.? Pak přijďte na moje školení o Kubernetes. Školení probíhá formou workshopu, kde si všechno vyzkoušíte na vlastní kůži. Přihlaste se buď na veřejný termín nebo mě kontaktujte ohledně firemního školení.

Nezávazně poptat firemní školeníVíce informací o školení