Dyskusja o ogłoszeniu o wycofaniu NGINX Ingress i skali problemu w środowiskach Cloud Native. Analiza przyczyn upadku projektu, roli F5 i CVE. Wyjaśnienie, czym jest Gateway API i czy rzeczywiście trzeba migrować. Praktyczne rekomendacje: wymiana kontrolera zamiast jednoczesnej migracji API i kontrolera oraz przegląd alternatyw jak Traefik, Contour, HAProxy i rozwiązania chmurowe.
14:40
forum Ask episode
web_stories AI Snips
view_agenda Chapters
auto_awesome Transcript
info_circle Episode notes
insights INSIGHT
Dlaczego NGINX Ingress Został Wycofany
Kubernetes ogłosił retirement NGINX Ingress Controller mimo że ~50% środowisk Cloud Native go używało.
Projekt był utrzymywany ad hoc przez dwóch kontrybutorów, F5/NGINX przestało inwestować a wcześniej pojawiły się CVE, co przyspieszyło deprecjację.
insights INSIGHT
Czym Jest Gateway API
Gateway API to rozszerzenie Ingress API które rozdziela konfiguracje infrastruktury od konfiguracji aplikacyjnej i tworzy hierarchię zasobów (GatewayClass, HTTPRoute).
To usuwa monolityczny resource Ingress i daje więcej kontroli nad routingiem i odpowiedzialnościami.
insights INSIGHT
Gateway API Ma Motywacje Biznesowe
Gateway API ma też ekonomiczny wymiar: vendorzy i dostawcy chmur widzą w nim szansę na ustandaryzowane zarządzanie API Gatewayami i upsell.
To wyjaśnia część promocji Gateway API poza technicznymi argumentami.
Get the Snipd Podcast app to discover more snips from this episode
“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
Patoarchitekci