Kubernetes kończy z Ingress NGINX – czas na migrację i nowe wyzwania

Czy Twój klaster ma właśnie tykającą bombę z opóźnionym zapłonem? Jeśli korzystasz z Ingress NGINX, odpowiedź może brzmieć: tak.

Kubernetes oficjalnie żegna Ingress NGINX w marcu 2026. Po tej dacie nie będzie już żadnych wydań, łatek ani aktualizacji bezpieczeństwa. Liderzy projektu mówią wprost: połowa środowisk cloud native wciąż na tym stoi, a pozostanie przy nim po wygaszeniu oznacza realne ryzyko ataku. Migracja jest konieczna i nie będzie bezbolesna.

Ingress NGINX był kiedyś domyślnym sposobem wpuszczania ruchu HTTP(S) do usług w Kubernetesie. Sukces stał się ciężarem: wieloletni niedobór maintainerów, narastający dług techniczny i wzrost oczekiwań bezpieczeństwa sprawiły, że utrzymanie projektu przestało być rozsądne. Społeczności poleca się przenosiny na Gateway API lub jeden z aktywnie utrzymywanych kontrolerów komercyjnych/otwartoźródłowych. To nie jest migracja „drop-in”. [7]

Co się właściwie dzieje

W komunikacie Komitetu Sterującego i Komitetu Reagowania Bezpieczeństwa padają rzadko spotykane w projektach open source sformułowania: „nie możemy przecenić wagi sytuacji” i „pozostanie przy Ingress NGINX po jego emeryturze naraża was i waszych użytkowników na atak”. W marcu 2026 repozytoria przejdą w tryb tylko do odczytu, artefakty (obrazy, chart Helm) zostaną, a istniejące wdrożenia będą dalej działać – i to jest najgroźniejsze. Jeśli nie sprawdzisz proaktywnie, możesz nie wiedzieć, że jesteś zagrożony, dopóki podatność nie zostanie wykorzystana. [2][1]

Tak sprawdzisz, czy problem dotyczy ciebie: z uprawnieniami administratora klastra uruchom komendę kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx

Dlaczego to ważne (i skąd ten pośpiech)

Według wewnętrznych danych Datadoga około 50% środowisk cloud native polega dziś na Ingress NGINX. Projekt stał się popularny wcześnie: elastyczny, pełen funkcji, niezależny od chmury. Ta elastyczność miała jednak cenę. Adnotacje pozwalające na „snippets” – wstrzykiwanie własnych dyrektyw NGINX – kiedyś dawały moc, dziś oznaczają zbyt dużą powierzchnię ataku. Badacze bezpieczeństwa wykazywali poważne luki (w 2025 r. głośne znaleziska opisał m.in. Wiz), a mały zespół utrzymujący kod po godzinach nie miał jak zapewnić standardu bezpieczeństwa, który ekosystem uznaje za akceptowalny.

Kulisy decyzji odsłonięto podczas KubeCon NA 2025 w Atlancie. Maintainerzy ogłosili wtedy wstrzymanie rozwoju Ingress NGINX (i planowanego następcy, InGate, który nie wystartował poza zalążek). Presja? Ogromna. Jak relacjonował James Strong, były momenty, gdy część liderów naciskała na natychmiastową deprecjację; ostatecznie wynegocjowano finał w marcu 2026, z ostatnim wydaniem zgranym z KubeCon Europe. To szybciej, niż chcieli maintainerzy, ale wolniej, niż chcieli niektórzy decydenci. Innymi słowy: kompromis wymuszony bezpieczeństwem. [2][8]

Migracja: twarda rzeczywistość, a nie „kliknij i działa”

Rekomendacja jest jasna: Gateway API. Ten projekt osiągnął stabilność w 2023 r. i powstał właśnie po to, by naprawić ograniczenia Ingress: role rozdzielające odpowiedzialności, obsługa nie tylko HTTP/HTTPS, ale też TCP/UDP/gRPC, natywne dzielenie ruchu i matchowanie po nagłówkach bez vendorowych adnotacji. Problem? Nie jest to zamiennik 1:1. Spora część mocy Ingress NGINX wynikała z adnotacji wykraczających poza specyfikację Ingress – i tych rzeczy Gateway API albo jeszcze nie robi, albo świadomie nie będzie robił. Jak ujął to Ricardo Katz z Red Hata, jeśli mówimy o „czystym” Ingress bez adnotacji, Gateway API potrafi wszystko; ale rzeczywistość bywa inna, a adnotacje tworzą sporą lukę funkcjonalną.

Nawet przesiadka na inny kontroler Ingress nie jest banalna. F5 NGINX Ingress używa innych adnotacji i ma własne przewodniki migracyjne. Dostawcy reagują – HAProxy wypuściło Unified Gateway, który ma jednocześnie wspierać reguły Ingress i Gateway API, by ułatwić przejście. Ale to nadal migracja, nie zmiana jednego ustawienia. [6]

Sygnały z terenu: część organizacji już idzie w stronę warstwy service mesh i bram Gateway w Istio; inni zwracają uwagę, że nazywanie Gateway API „gotowym” bywa odważne, skoro np. prosta autoryzacja wciąż w niektórych implementacjach jest eksperymentalna. Innymi słowy: na papierze jest dobrze, w praktyce bywa różnie, zależnie od stacku.

Fakty, które trzeba znać (bez zadęcia)

• Po marcu 2026 nie ma już łatek ani aktualizacji Ingress NGINX. Kropka.
• Istniejące wdrożenia będą działać – i to może uśpić czujność do czasu kompromitacji.
• Alternatywy istnieją: Gateway API (rekomendowane) albo inne kontrolery Ingress (NGINX od F5, Kong, Traefik, HAProxy i inne). Różnią się funkcjami, wydajnością i modelem utrzymania.
• Żaden wariant nie jest „drop-in”. Potrzebne są plan, budżet i czas inżynierski.

Komentarz: lekcja droższa niż każdy audyt

To historia o tym, jak krytyczna infrastruktura potrafi wisieć na pracy jednej-dwóch osób. I o tym, że „wielka elastyczność” często oznacza „wielkie ryzyko”, gdy rzeczywistość bezpieczeństwa zmienia się szybciej niż community jest w stanie łatać. Czy termin jest ostry? Tak. Czy z perspektywy bezpieczeństwa ekosystemu – konieczny? Też tak. Dla wielu zespołów to będzie pierwszy poważny remont sieciowej warstwy Kubernetes od lat. Lepiej zacząć wcześniej.

Na koniec: co zrobić dziś, nie jutro

• Sprawdź, czy używasz Ingress NGINX (komenda wyżej).
• Zrób inwentaryzację adnotacji i niestandardów – to one rozstrzygną trudność migracji.
• Wybierz ścieżkę: Gateway API (docelowo) czy tymczasowo inny kontroler Ingress; oceń wsparcie, zgodność, governance.
• Zaplanuj rollout i testy. Istniejące instalacje będą „działać”, ale to już będzie abandonware.

Podsumowanie

Kubernetes zrobił to, co zwykle odkładamy „na potem”: przeciął temat, zanim kolejna luka przejdzie przez nagłówki. Jeśli jesteś w tej „połowie” użytkowników, nie czekaj na marcowy dzwonek. Zadaj zespołowi proste pytanie: czy wolimy migrację na naszych warunkach, czy incydent na cudzych?

FAQ

Czy Ingress NGINX otrzyma jeszcze jakiekolwiek aktualizacje po marcu 2026?

Nie, po marcu 2026 nie będzie kolejnych wydań, łatek ani poprawek bezpieczeństwa. Repozytoria pozostaną tylko do odczytu, a artefakty dostępne wyłącznie referencyjnie.

Jak sprawdzić, czy mój klaster Kubernetes używa Ingress NGINX?

Najszybciej: uruchom z uprawnieniami administratora komendę kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx. Jeśli zwróci zasoby, masz temat do pilnej migracji.

Czy istnieje „drop-in” zamiennik dla Ingress NGINX?

Nie, żadne rozwiązanie nie jest bezpośrednim zamiennikiem. Migracja wymaga planowania i pracy inżynierskiej, zwłaszcza jeśli używasz adnotacji specyficznych dla Ingress NGINX.

Czy Ingress API w Kubernetes też jest wycofywany?

Nie, Ingress API pozostaje stabilny. Wycofany jest konkretny kontroler Ingress NGINX; rekomendowany kierunek to Gateway API lub inny utrzymywany kontroler Ingress. [7]

Jakie są rekomendowane alternatywy dla Ingress NGINX?

Oficjalnie rekomendowany jest Gateway API. Alternatywnie możesz wybrać inne aktywnie utrzymywane kontrolery Ingress (np. od NGINX/F5, Kong, Traefik, HAProxy), ale wymagają one własnych ścieżek migracji.

Źródła

• [1] https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/
• [2] https://devclass.com/2026/01/29/kubernetes-leadership-warns-of-ingress-nginx-risks-but-has-also-hastened-its-deprecation/
• [3] https://linkedin.com/posts/cloud-native-computing-foundation_ingress-nginx-statement-from-the-kubernetes-activity-7422677623337717760-Lick
• [4] https://theregister.com/2025/11/14/nginx_retirement/
• [5] https://infoq.com/news/2025/11/kubernetes-ingress-nginx/
• [6] https://thenewstack.io/cncf-retires-the-ingress-nginx-controller-for-kubernetes/
• [7] https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• [8] https://theregister.com/2025/12/02/ingress_nginx_opinion/