W ostatnich miesiącach ekosystem Kubernetes przechodzi przez znaczące turbulencje. Niedawno Bitnami zamknęło dostęp do darmowych obrazów i Helm’ów, a teraz przyszedł czas na jeszcze większą bombę i to od samego projektu Kubernetes – oficjalny koniec wsparcia dla Ingress Nginx. To nie są przypadkowe wydarzenia, ale symptomy głębszych zmian w świecie infrastruktury cloud-native.
Bitnami – koniec pewnej epoki
Od 28 sierpnia 2025 roku Bitnami (należący do Broadcomu) oficjalnie skończył oferować darmowy dostęp do darmowych obrazów kontenerów. Tym razem to był poważny cios dla wielu zespołów DevOps na całym świecie. Przez lata Bitnami był skrótem do produktywności – gotowe, dobrze utrzymywane obrazy dla PostgreSQL, Redis, Kafka, NGINX i setek innych aplikacji. Wystarczyło docker pull bitnami/postgresql:13.7.0 i miałeś produkcyjny obraz do pracy.
Teraz sytuacja wygląda zupełnie inaczej. Broadcom zdecydował się skierować produkt bardziej w stronę enterprise’owych klientów z planem Bitnami Secure Images w cenie około 6000 dolarów miesięcznie. Dla reszty z nas?
Stare obrazy trafiły do repozytorium bitnamilegacy, które nigdy nie będzie aktualizowane.
Koniec Ingress Nginx – co się stało?
Teraz przychodzi kolej na Ingress Nginx. Kubernetes SIG Network i Security Response Committee ogłosiły oficjalnie: Ingress Nginx przechodzi na emeryturę.
Oficjalnie mamy best-effort maintenance do marca 2026 roku. Potem? Nic. Żadnych poprawek, żadnych aktualizacji bezpieczeństwa, żaden support dla odkrywanych podatności. Istniejące wdrożenia będą działać, obrazy i charty zostaną dostępne, ale to koniec rozwoju.
Co było powodem? Historia smutna – przez lata Ingress Nginx utrzymywany był przez zaledwie jedną lub dwie osoby w swoim wolnym czasie. Mimo ogromnej popularności projektu (miliardy żądań obsłużone na świecie), zespół po prostu się wypalił z przepracowania. Ostatni rok zespół próbował znaleźć wsparcie, ale bez efektów. Zamiast tego stworzono projekt InGate, mający być zamiennikiem, ale nigdy nie zdołał osiągnąć statusu production-ready i również będzie wycofywany.
Rzeczywisty problem? Ingress Nginx miał zbyt wiele elastyczności i opcji – rzeczy, które kiedyś były uważane za genialne features (jak adnotacje snippets pozwalające na dodawanie dowolnych dyrektyw NGINX), teraz postrzegane są jako poważne luki bezpieczeństwa. Techniczny dług był po prostu zbyt duży.
Co teraz? Alternatywy dla Ingress Nginx
Nie łudźmy się – jeśli używasz Ingress Nginx w produkcji, pora się ruszać. Kubernetes SIG Network rekomenduje Gateway API jako nowoczesną zamianę dla Ingress, ale jeśli musisz zostać z tradycyjnym Ingress, masz co najmniej kilka solidnych opcji.
Gateway API – przyszłość, której nie chcesz ignorować
Gateway API to nowa generacja routingu w Kubernetesie – zaprojektowana bezpośrednio przez SIG Network. Jeśli Twój provider (np. DigitalOcean Kubernetes z Cilium, czy GKE) go wspiera, to jest to najprostsze rozwiazanie. Problem? Nie wszyscy providerzy go wspierają, a jeśli masz własny klaster, to będzie zależne od Twojej implementacji sieci.
APISIX – wysokowydajny, elastyczny, pełen możliwości
Apache APISIX to API gateway zbudowany na NGINX i etcd. Jeśli Ingress Nginx wystarczał Ci przez lata, to APISIX to krok naprzód – dynamiczna konfiguracja bez restartów, bogaty ekosystem wtyczek w Lua i WebAssembly, wsparcie dla wielu protokołów (HTTP/2, gRPC, WebSocket). Obsługuje też Gateway API.
Traefik – najprostszy wybór dla chmury
Traefik to król uproszczenia. Cloud-native, piękny dashboard, automatyczne odkrywanie usług, dynamiczna konfiguracja przez labele lub Ingress resources. Nie musisz czyścić starego kodu – Traefik obsługuje zarówno tradycyjne Ingress jak i swoje IngressRoute CRDs. Obsługuje też Gateway API.
Istio – dla tych, którzy potrzebują wszystkiego
Istio to service mesh, nie tylko ingress. Jeśli chcesz zaawansowanego routingu, traffic management’u, observability’ego i security’ego na poziomie layer 7 dla całej sieci mikrousług – to jest to. Ale uwaga – Istio to duża, ciężka infrastruktura. Dodaje 40-400% latencji w stosunku do Linkerd, wymaga dużej wiedzy i zasobów. Dla małych klastrów to overkill.
Linkerd – prostota i bezpieczeństwo domyślne
Linkerd to service mesh, ale ultra-lekki. Automatyczne mTLS dla wszystkich połączeń TCP, super niskie zasoby, wydajność – dodaje 40-400% mniej latencji niż Istio. Napisany w Rust, co eliminuje całe klasy podatności związanych z pamięcią. Problem? Nie ma wbudowanego ingress gateway – musisz dodać NGINX czy coś innego.
HAProxy – dla purystów i wymagających
HAProxy Kubernetes Ingress Controller to grumpy old man z dobrymi manierami. Solidny, niezawodny, obsługuje TCP/UDP (nie tylko HTTP/HTTPS jak klasyczne Ingress). Oferuje zaawansowane możliwości balansowania i autoryzacji. Wspiera też Gateway API. Problem? Community jest mniejsze, dokumentacja czasami zagmatwana (istnieją dwie różne implementacje HAProxy dla Kubernetesa).
Nginx Ingress – nie pomyl z Ingress Nginx!
Czekaj, czekaj – czy istnieje oficjalny Nginx Ingress? Odpowiedź to… już nie. NGINX wycofał się z aktywnego wsparcia dla tradycyjnego Ingress Controllers. Masz dostęp do NGINX Plus (komercyjny), ale to drogo i nie jest to to samo.
Porównanie – szybka tabelka
| Aspekt | APISIX | Traefik | Istio | Linkerd | HAProxy |
|---|---|---|---|---|---|
| Złożoność | Średnia | Niska | Wysoka | Niska | Średnia |
| Wydajność | Bardzo dobra | Dobra | Słaba | Wyśmienita | Bardzo dobra |
| Krzywa uczenia | Średnia | Niska | Bardzo wysoka | Niska | Średnia |
| Obsługa TCP/UDP | Tak | Nie | Nie | Nie | Tak |
| Gateway API | Tak | Tak | Tak | Nie | Tak |
| Wtyczki | Lua/WASM/RPC | Golang | Envoy filters | Ograniczone | Ograniczone |
| Zasoby | Średnie | Niskie | Wysokie | Bardzo niskie | Średnie-Wysokie |
| Community | Rosnąca | Duża | Bardzo duża | Mała-Średnia | Mała |
Rekomendacje na podsumowanie
- Dla startupów i małych zespołów: Traefik lub Gateway API (jeśli dostępna)
- Dla dużych deploymentów z wymaganiami: APISIX czy Istio
- Dla purystów obsługi TCP/UDP: HAProxy
- Dla minimalistycznych service mesh: Linkerd
- Ogólnie: Gateway API warta polecenia jeśli dostępna – to przyszłość
Oba wydarzenia – koniec Bitnami i koniec Ingress Nginx – pokazują jedną rzecz: w ekosystemie open-source’a trzeba być gotowym na zmiany. Starsze projekty, które nie mają wystarczającego wsparcia, kiedyś albo umrą, albo przejdą transformację. Lepiej się tego spodziewać niż być zaskoczonym.
Pora ruszać się z Ingress Nginx i szukać alternatywy, która pasuje do Twoich potrzeb. Gateway API to droga przyszłości, ale jeśli potrzebujesz czegoś teraz – wybierz między Traefik (prostotą) a APISIX (mocą) i zarezerwuj sobie parę dni na migrację.
