Łukasz Kałużny: To jest najważniejsze. To oczywiście moim zdaniem bezczelna promocja ładująca zamiast jednego problemu dwa problemy. No sorry, to jest po prostu próba wymuszenia moim zdaniem, żeby o, migrujmy się, jest nowy, lepszy gateway API, którego nie potrzebujesz prawdopodobnie. To będzie najgorsza rzecz, że prawdopodobnie jeżeli macie więcej jakichś annotations od cookiesów, od buforów, być może jakieś redirecty, to trzeba zaplanować takie zmiany w aplikacji i je przetestować. Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka: góra, lewo, prawo, Google, ChatGPT, Claude, Claude’a bardziej polecamy, ogarniecie. Albo po prostu Patoarchitekci.io, gdzieś na dole, ogarniacie.

Łukasz Kałużny: Dobra.

Szymon Warda: Dobrze Łukaszu, konferencja, konferencja.

Łukasz Kałużny: Tak, szybciutko. Konferencja Pato200, prawdopodobnie jak w momencie nagrywamy, bo w zeszłym odcinku było do Was pytanie o czym miałbym powiedzieć i wrzuciłem też pod spodem linka do ankiety. I ogólnie dwie prośby, które się pojawiły: bez AI-a.

Szymon Warda: No i Łukasz będzie milczał.

Łukasz Kałużny: Nie, słuchaj, bo wymyśliłem parę tytułów i wygrywającym w tym momencie i chyba się na niego zdecyduję, 200 odcinków później, powtarzające się patologie, które nigdy nie umierają.

Szymon Warda: Widziałem to. To jest dobra rzecz. W ogóle taka trochę retrospektywa. To jest dobry pomysł ogólnie rzecz biorąc.

Łukasz Kałużny: Tak, łączy mi się akurat z osiemnastką w IT.

Szymon Warda: W końcu będziesz legalny, że tak powiem.

Łukasz Kałużny: Pełnoletni, będę mógł wreszcie kupić alkohol w tym. No więc możecie też zaproponować temat dla Szymona, bo Szymon rozważał mocno AI-owy ze swojego życia chyba.

Szymon Warda: Ja też właśnie wrzucę tą ankietę, to jest dobra opcja w ogóle. Zapraszamy na naszego Discorda, tam się naprawdę dzieje, jest naprawdę żywy, muszę powiedzieć tak trochę z boku patrząc.

Łukasz Kałużny: Więc Patoarchitekci.io/szkolenia i link do konferencji też znajdziecie na dole. Już niebawem ładniejszy landing page jak ustalimy już tematy sesji. No to co? Zaczynamy Szymonie odcinek.

Szymon Warda: Zaczynam, dobrze. Trochę o tym, że coś…

Łukasz Kałużny: Wybuchło.

Szymon Warda: Jest deplicated ale nie jest deplicated. Działa, nie działa. Całe zamieszanie, o którym chyba mówiliśmy swoją drogą. Mówiliśmy w kontekście…

Łukasz Kałużny: Było w jakimś shortcie.

Szymon Warda: Było w shortcie, bo mówiliśmy o fundacji, która zbierała projekty, które są już nieutrzymywane, a tym projektem jest NGINX-owy Ingress, do którego każdy miał, dotykał praktycznie, no nie.

Łukasz Kałużny: Dobra, to przejdźmy tak do problemu. Dzisiaj odcinek wynikający z pytań, które mamy w Protopii, w naszej firmie, w naszej rzeczy. Czyli pamiętajcie, Patoarchitekci to też Protopia i zajmujemy się doradztwem oprócz tego, co widzicie tutaj w podcaście. Dobra i rzecz, która się tutaj znajduje i mieliśmy rozmowy z klientami i tłumaczenie, to Kubernetes ogłosił jako projekt, że ubija Ingress NGINX. I co tutaj się zadziało? Po pierwsze, jak pójdziemy tam na dane z Datadoga, środowiska Cloud Native, 50% środowisk prawdopodobnie używało Ingress NGINX-a jako domyślnego Ingress Controllera. Nie dziwi mnie to. Sami go polecaliśmy.

Szymon Warda: Tak, no brainer, działał, szybki, spoko.

Łukasz Kałużny: Projekt był utrzymywany ad hoc przez tak, powiedzmy, że dwóch kontrybutorów. Mimo apeli nikt do tego nie dołączył. NGINX w sumie się wypiął, bo F5 chce tylko sprzedawać swój komercyjny produkt, to jest istotny element. I w zeszłym roku też był wybuch CVE i problemów z bezpieczeństwem. I teraz mamy switch z “kiedyś umrze” na “już umarło”, tak patrząc się. I tak jak teraz to nagrywamy, jest marzec, więc mamy już ten retirement Ingressa. I to jest taki element. Więc jeżeli Cię dotyczy, to jest odcinek dla Ciebie. I rzecz, która się zadziała, to jest najważniejsze, to oczywiście moim zdaniem bezczelna promocja ładująca zamiast jednego problemu dwa problemy, a mianowicie przekierowywanie…

Szymon Warda: Jak dają to bierzesz, za darmo.

Łukasz Kałużny: Przekierowywanie na Gateway API, ładnie mówiąc.

Szymon Warda: Który jest promowany już od jakiegoś czasu.

Łukasz Kałużny: Tak. I teraz o co w tym chodzi? Teraz bardzo ważna rzecz. Może czym jest Gateway API? To jest rozbudowywanie Ingress API, które było w Kubernetesie, żeby rozdzielić infrastrukturę i admina od developera, czyli w zależności kto co konfiguruje, jak zrobi. Jest tam taka… Zamiast jednego prostego obiektu jest teraz hierarchia zasobów pod spodem. Zamiast po prostu mieć Ingress jako obiekt, to mamy GatewayClass, Gateway HTTPRoute, zamiast monolicznego resource’a. I teraz chyba istotna rzecz, o której trzeba sobie powiedzieć. Gateway API, skąd się wziął? To jest dwojaka potrzeba, ale ta pierwotna to jest to, że Ingress był prostym, patrząc po annotation tak nie jest.

Szymon Warda: Był prostym obiektem.

Łukasz Kałużny: W założeniu. W założeniu był prostym obiektem. I spora część rynku, w szczególności vendorów, chciała, żeby zacząć automatyzować API gatewaye za pomocą Yamli w Kubernetesie. Czyli że będziemy mogli zautomatyzować i poprzez konfigurację i wrzucić w sposób ustandaryzowany konfigurację API gateway’a.

Szymon Warda: Co ma pewien sens. No bo nie oszukujmy się, to jest część, jest ta część routingu, która jest częścią aplikacyjną, ale też z punktu widzenia vendorów, no to te application gatewaye to są z reguły dość soczyste usługi często, jeżeli chodzi o koszty, to taka prawda. Więc też 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 wyklikiwane, bo niestety takie rzeczy czasami były wyklikiwane i to widzieliśmy nieraz.

Łukasz Kałużny: Tak więc jest ten element. I teraz tak, dlaczego powiedziałem o dwóch problemach? Czy jeżeli masz NGINX-a to musisz migrować się na Gateway API? No właśnie nie.

Szymon Warda: Ja bym tu jedną rzecz, bo wtedy co właśnie gadaliśmy odnośnie tego projektu i fundacji. Właśnie powstała ta fundacja, która zbiera nieutrzymywane projekty. I co się tam będzie działo? W sensie tak, póki niczego nie ruszasz jest to bezpieczne.

Łukasz Kałużny: Dobra, zostawmy, Szymon, zostawmy wątki. Ingress API versus Ingress Controller NGINX, nie mieszajmy, dobra, nie mieszajmy.

Szymon Warda: Ok, jak masz Ingress API, jest spoko.

Łukasz Kałużny: Jest, tak. Inaczej, jeżeli chodzi, czyli, że chcesz nadal korzystać z obiektu Ingress, a masz NGINX Ingress Controller, to nie musisz się migrować na Gateway API. Jeżeli na to nie patrzyłeś, to prawdopodobnie tego nie potrzebujesz, o tak to teraz powiedzmy sobie szczerze w tym momencie i nie ma co się bawić. Czyli jeżeli Ingress pokrywa Twoje case’y, to teraz istotna rzecz, bo część rzeczy, która poleciała, newsów, to że jest tak na prawdę deplicated w samym Kubernetesie.

Szymon Warda: Nie jest.

Łukasz Kałużny: Właśnie, nie jest, jest frozen, jest sobie w zamrażarce. I teraz powiedzmy sobie, że to tak jak z deploymentem jego mać czy demon setem, tam już praktycznie nic się nie zmienia, bo…

Szymon Warda: (…) tam się nic nie zmieni po prostu, nie ma sensu. To już jest dojrzałe i tyle.

Łukasz Kałużny: Więc jak popatrzycie sobie na Ingress API i definicję tego obiektu w Kubernetesie, to tam nie ma co za dużo zrobić i wymyślać. Więc powiedzenie, że jest w zamrażarce, to w sumie sorry, to jest po prostu przymuszenie trochę, inaczej, próba wymuszenia moim zdaniem, żeby o, migrujmy się, jest nowe, lepsze Gateway API, którego nie potrzebujesz prawdopodobnie. Zupełnie, zupełnie szczerze.

Szymon Warda: Jest to oznaczenie tego, że już jak robisz coś od zera, to może niekoniecznie właśnie Ingress API i to jest sensowne. Migracja spokojnie, że tak powiem.

Łukasz Kałużny: I problemem nie jest to, że masz obiekty Ingress, ale że masz kontroler z NGINX-em. I to jest prawda. I teraz jeżeli chodzi o całość tutaj rekomendacji i podejścia. Jeżeli Ingress pokrywa Twoje case’y, to nie panikuj, trzeba po prostu zmienić Ingress Controller. Jak…

Szymon Warda: Ja bym dodał jeszcze jedną rzecz. Pokrywa Twojej case’y tu i teraz, bez dumania, że a może byśmy i tak dalej. Tak realnie i rozsądnie podejdźmy.

Łukasz Kałużny: Zero-jedynkowo patrzymy tu i teraz. Jeżeli zaczynasz nowy projekt, to być może warto rozważyć te Gateway API. Może u dostawcy cloudowego będzie Ci się spinać. Jeżeli już teraz masz zarządzany Ingress, więc bym się tym nie przejmował. I element najistotniejszy, jak zawsze, nie rób dwóch migracji naraz, czyli że zmieniamy API i Controller.

Szymon Warda: Pytanie właśnie, pytanie czy chcesz w tym momencie używać tego krokowo, bo to Ci w tym momencie wiele nie da.

Łukasz Kałużny: Inaczej, prawdopodobnie jak przemigrujesz się na nowy Ingress Controller, to możesz zapomnieć o Gateway API i nie będzie Ci to przeszkadzać.

Szymon Warda: Tak, chociaż dla niektórych organizacji większych to może mieć sens trzymanie tego, przynajmniej części tego właśnie w Yamlach.

Łukasz Kałużny: Szymon, ja będę ten, jeżeli nie było do tej pory potrzeby i teraz ktoś się obudził, to nie było na to potrzeby.

Szymon Warda: NIe, ja mówię o innym scenariuszu. Jak część było wyklikiwana, część była zrobiona tak i tak dalej, uspójnienie tego na poziomie klastrów.

Łukasz Kałużny: Dobra Szymon, ale dobra, 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 Gatewaya jakiegoś third party nagle do Gateway API i do Yamla. Nie oszukujmy się, takie coś nie nastąpi.

Szymon Warda: Ja nie tracę nadziei. Jestem optymistą w tym obszarze mimo wszystko.

Łukasz Kałużny: 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 i podsumowując, czyli Microsoft na przykład dostarcza coś swojego na bazie NGINX-a ze swoim supportem.

Szymon Warda: Application Gateway w tym przypadku.

Łukasz Kałużny: Tak. Nie, bo też jest, pamiętaj, web application delivery. Zawsze mi się już nazwy… Inaczej, tych nazw teraz mamy, jest…

Szymon Warda: Jest trochę więcej.

Łukasz Kałużny: Ileś alternatyw, o tak, zostawmy. Każda chmura ma swoją i jeszcze X opcji wyboru. Więc jak teraz popatrzymy sobie, w zależności co masz. W on premie, jak masz na przykład RKE Ranchera, to support na przykład dla tego NGINX-a i wersji jest jeszcze na rok czasu realnie, więc w ogóle. Jak chcesz się już teraz przemigrować i o tym zapomnieć, to traffic w Rancherze na przykład czy w on premie poszedłbm ze względu na popularność. Drugi, następny będzie Traffic, to jest jedna rzecz. W cloudzie, jak powiedzieliśmy, to czy może już od manage providera. Jeżeli chcesz envoya pod spodem, to Contour i to też bym brał jako solidne podejście. Można też rozważać, jeżeli patrzyłeś na NGINX-a jako rzecz, znajdę informację co się dzieje pod spodem, bo to jest też Szymon istotne, bo na NGINX-a, my sami rekomendowaliśmy NGINX-a, że o każdej porze dnia i nocy znajdziesz kogoś, kto Ci pomoże.

Szymon Warda: Bo jest prosty. To jest naprawdę…

Łukasz Kałużny: Tak, to można się zastanowić nad HAProxy Ingressem. Można go rozważyć, bo to też jest bardzo sprawdzone w boju rozwiązanie.

Szymon Warda: Okej, a czy badałeś w ogóle temat tego, jak się właśnie, jaka jest adopcja właśnie Gateway API w…

Łukasz Kałużny: Wiesz co…

Szymon Warda: W sprzętowych rzeczach, że tak powiem bardziej, bo ingresowa była przez jakiś czas.

Łukasz Kałużny: Ingresowa, to nie istnieje tak naprawdę, wszystko poszło w software Szymon, o tak, proste. 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. To są dwa projekty, które bym od nich być może zaczął, o tak, jeżeli popatrzymy. I Envoy Gateway jest taką, część osób się może do mnie przyczepić, ale bym powiedział, że będzie to taka referencyjna architektura, o tak to nazwijmy.

Szymon Warda: Się ładnie rozwijają, więc jak najbardziej tak.

Łukasz Kałużny: I Envoy jest całą podstawą całej sieciówki teraz, takich rozwiązań sieciowych. Pewnie ten cały Google Cloud i load balancer na tym latają, więc jest to naprawdę wymęczone w boju, więc to jest w tym.

Szymon Warda: Dobrze. To w takim razie podsumowanie powoli robimy. Co teraz? W kilku zdaniach.

Łukasz Kałużny: Dobra, pierwsze, jak używasz Ingress Controllera, możesz to sobie sprawdzić, co tam masz: kubectl get pods i szukamy w tych selektorem app.kubernetes.io name ingress nginx czy masz.

Szymon Warda: Albo po namespacie, bo to też jest w namespacie, Controller.

Łukasz Kałużny: Tak, w zależnoścui jak zrobiliśmy, tak. Nie panikuj, zaplanuj, to jest też rozmowa z klientami. Guys, to było też dosłownie rozmowa. Czekamy, aż zakończycie jedno sprzątanie, zajmiemy się drugim problemem, nie dwa problemy na raz. To jest w ogóle taka rzecz.

Szymon Warda: Dobra praktyka życiowa.

Łukasz Kałużny: Dobra, jak macie, to zrzućcie sobie po prostu wszystkie kubectl get ingress -a -o YamL. Zapiszcie sobie wynik do pliku i weźcie w Claude’a wrzućcie, żeby wyszukał Wam wszystkich niestandardowych annotations. I potem zastanówcie się co potrzebujecie, żeby wskazać, co będziecie musieli przetestować. Bo to jest, to będzie najgorsza rzecz, że prawdopodobnie jeżeli macie więcej jakichś annotations od cookiesów, od buforów, być może jakieś redirecty, to trzeba zaplanować takie zmiany w aplikacji i je przetestować. I potem to co? Zaplanuj migracje, zazwyczaj możesz mieć je obok siebie. Czyli to jest też rzecz, którą polecamy. Trochę zdradzę się z tajników pracy Szymon w tym, możemy mieć alternatywę taką, że stawiamy sobie drugiego Ingress Controllera, drugie obiekty i nawet na produkcji testujemy. I potem jak wszystko jest okej, po prostu podmieniamy IP-ka albo DNS-y na nowego IP-ka.

Szymon Warda: Takie migracje są łatwe. Dobrze Łukaszu, to co, kończymy?

Łukasz Kałużny: Kończymy. Niepotrzebnie nastraszyli ludzi. Na razie.

Szymon Warda: Trzeba sprzedawać. Na razie, heja.