Mentionsy
Patoarchitekci
Patoarchitekci
20.03.2026 07:00

Ingress NGINX odchodzi - co teraz?

“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

NGINXa Gateway Kubernetes Kloda Łukaszu Envoy Gateway API Gateway'a Google Guys Ingress Controller NGINX Aplication Gateway NGINX Ingress Controllera NGINXem NGINXa

Sponsorzy odcinka (1)

Gateway API mid-roll

"to oczywiście moim zdaniem bezczelna promocja ładująca zamiast jednego problemu dwa problemy, a mianowicie jak dają, to bierzesz za darmo. Przekierowywanie na Gateway API, ładnie mówiąc. Który jest..."

Szukaj w treści odcinka

Wyczyść
Znaleziono 20 wyników dla "Gateway"

No sorry, to jest po prostu próba wymuszenia moim zdaniem, żeby migrujmy się, jest nowe lepsze Gateway API, którego nie potrzebujesz prawdopodobnie.

Przekierowywanie na Gateway API, ładnie mówiąc.

Może czym jest Gateway API?

Zamiast po prostu mieć ingress jako obiekt, to mamy gateway-class, gateway-http-route zamiast monolicznego resource'a.

Gateway API, skąd się wziął?

W założeniu był prostym obiektem i spora część rynku, w szczególności vendorów, chciała, żeby zacząć automatyzować API gatewaye.

Czyli, że będziemy mogli zautomatyzować poprzez konfigurację i wrzucić w sposób ustandaryzowany konfigurację API Gateway'a.

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.

Czy jeżeli masz NGINXa, to musisz migrować się na Gateway API?

Jeżeli chodzi, czyli że chcesz nadal korzystać z obiektu ingress, a masz NGINX ingress controller, no to nie musisz się migrować na gateway API, jeżeli na to nie patrzyłeś.

Więc powiedzenie, że jest w zamrażarce, no to w sumie no sorry, to jest po prostu przymuszenie trochę, inaczej próba wymuszenia moim zdaniem, żeby migrujmy się, jest nowe, lepsze Gateway API, którego nie potrzebujesz prawdopodobnie.

Jeżeli zaczynasz nowy projekt, to być może warto rozważyć te gateway API.

Inaczej, prawdopodobnie jak przemigrujesz się na nowy ingress controller, to możesz zapomnieć o Gateway API i nie będzie ci to przeszkadzać.

Sorry, Szymon, ja tutaj będę niestety... Jak było wyklikiwane, nikt i tak tego nie ruszy, nie zautomatyzuje i nie przeniesie ci z API Gateway jakiegoś fairparty na go jak do Gateway API i do YAML-a.

Aplication Gateway w tym przypadku.

Okej, a czy podałeś w ogóle temat tego, jaka jest adopcja właśnie Gateway API w sprzętowych rzeczach, że tak powiem bardziej, bo ingresowa była przez jakiś czas.

Czyli Gateway API to jest już typowy software.

Jak macie tak zobaczyć inaczej, jakbym teraz powiedział, że chcecie iść w Gateway API,

To tutaj poszedłbym następująco i rozważył na początek dwie rzeczy, czyli Envoy Gateway albo KGateway.

I Envoy Gateway jest taką, część osób może się do mnie przyczepić, ale bym powiedział, że będzie to taka referencyjna architektura, o tak to nazwijmy.

Ostatnie odcinki