Ingress NGINX odchodzi - co teraz?

20.03.2026 ·14 min 40 s · 1 rozdział · 1 sponsor

“To moim zdaniem bezczelna promocja ładująca zamiast jednego problemu dwa problemy.” Łukasz nie przebiera w słowach, komentując sposób, w jaki Kubernetes komunikuje wycofanie NGINX Ingress Controller - używanego przez 50% środowisk Cloud Native. Bo problem nie polega na tym, że Ingress API jest deprecated (nie jest - tylko “frozen”), ale na tym, że projekt próbuje wymusić migrację na Gateway API, którego “prawdopodobnie nie potrzebujesz”. 🎯 Plot twist? F5/NGINX wypiął się na community, bo wolą sprzedawać komercyjne rozwiązanie. Projekt był utrzymywany przez dwóch kontrybutorów, wybuchły CVE, i nagle wszyscy panikują. Szymon pragmatycznie: “Jak dają, to bierzesz za darmo” - ale Łukasz ostrzega przed pułapką: “Nie rób dwóch migracji naraz” - czyli nie zmieniaj API i Controllera jednocześnie. Recepta? Zostań przy Ingress API, zmień tylko kontroler. Traefik dla on-premise, Contour dla fanów Envoy, HAProxy Ingress jak szukasz sprawdzonego open source’u — tak jak kiedyś NGINX. W chmurze? Zarządzane rozwiązanie od providera. A jeśli naprawdę chcesz Gateway API - Envoy Gateway jako referencyjna architektura. Łukasz radzi: “Zrzućcie kubectl get ingress, wrzućcie w Claude’a, żeby wyszukał niestandardowe annotations” - i przetestujcie cookies, bufory, redirecty. ⚠️ Czy Kubernetes migration to realna potrzeba, czy bezczelna próba wymuszenia adopcji? Łukasz podsumowuje: “Niepotrzebnie nastraszyli ludzi.”     A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami.     Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech   - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia

4:07 · Gateway API 2

Co ma pewien sens, no bo, nie oszukujmy się, jest ta część routingu też częścią aplikacyjną, ale też z punktu widzenia vendorów, no to te Application Gateway to są z reguły dość soczyste usługi często, jeżeli chodzi o koszty. To taka prawda, więc też taki, taki upsell, że tak powiem, czy tam cross-sell, jakkolwiek to nazwiemy, tutaj jak najbardziej ma sens, ale też z punktu widzenia aplikacji. Dobrze jest to mieć w kodzie, żeby to się nie było wyklikowane, bo niestety takie rzeczy czasami były wyklikowane i to widzieliśmy nieraz. Tak, więc jest ten element i teraz tak. Dlaczego powiedziałem o dwóch problemach? Czy jeżeli masz NGINXa, to musisz migrować się na Gateway API? No właśnie, nie. Znaczy, ja bym tu jedna rzecz, bo wtedy, co się gadaliśmy odnośnie tego projektu i fundacji.

Jestem w tym miejscu, w tym obszarze. Ja nie, dobra, czyli ty tutaj, dobra, ale zostawmy to sobie. I teraz, jakie są rekomendacje, alternatywy dla NGINX Ingress Controllera? I teraz tak, patrząc się, pierwsza, jak jesteś w chmurze, to może ten manage od Cloud Providera ma rację. O tak, podsumowując, czyli Microsoft na przykład dostarcza coś swojego na bazie NGINX. Aplication Gateway w tym przypadku. Tak. Nie, bo też jest pamięta Web Application Delivery. Zawsze mi się już nazwy inaczej tych nazw teraz mamy. Jest trochę więcej. Jest ileś alternatyw. O tak. Zostawmy. Każda chmura ma swoją i jeszcze x opcji wyboru.

Pokazano wszystkie 2 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.