Ingress NGINX odchodzi - co teraz?

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 migrujmy się, jest nowe lepsze 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 Kołużny. I Szymon Warda.

I tak jak teraz to nagrywamy, jest marzec, więc mamy już ten retirement ingresa 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 Jak dają, to bierzesz za darmo. Przekierowywanie na Gateway API, ładnie mówiąc. Który jest promowany już od jakiegoś czasu. Tak. I teraz o co w tym chodzi? Teraz bardzo ważna rzecz. Może czym jest Gateway API? To jest rozbudowanie ingress API, które było w Kubernetesie, żeby rozdzielić infrastrukturę i admina od dewelopera, 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 gateway-class, gateway-http-route zamiast monolicznego resource'a. 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 ingres był prostym. Patrząc po annotation tak nie jest. No był prostym obiektem. 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ć 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. 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.

Właśnie, postała to fundacja, która zbiera nieutrzymywane projekty. I co się tam będzie działo? W sensie, tak, póki niczego nie ruszasz i jest to bezpieczne? Dobra, Szymon, zostawmy wątki. Ingress API vs. Ingress Controller NGINX. Nie mieszajmy, dobra, nie mieszajmy. Dobra, jest tak, inaczej. 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ś. 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 naprawdę deprecated w samym Kubernetesie.

Nie jest. Właśnie, nie jest. Jest frozen, jest sobie w zamrażarce. I teraz powiedzmy sobie, że to tak jak z deploymentem, jego match czy daemon setem, tam już praktycznie nic się nie zmienia. Albo z replikatem, tam się nic nie zmieni po prostu, nie ma sensu, to już jest zbliżały i tyle. W sensie tak, 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, 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. Zupełnie, zupełnie szczerze. Jest to oznaczenie tego, że już jak robisz coś od zera, to może niekoniecznie właśnie ingres API. I to jest sensowne.

Migracja? Spokojnie, że tak powiem. I problemem nie jest to, że masz obiekty ingress, ale że masz kontroler z NGINXem. I to jest problem. I teraz jeżeli chodzi o całość tutaj rekomendacji i podejścia. Jeżeli ingress pokrywa Twoje case'y, to nie paniku, trzeba po prostu zmienić ingress controller. Jak zaczynać... Ja bym powiedział jeszcze jedną rzecz. Pokrywa Twoje case'y tu i teraz, bez zdumania, że a może byśmy, a tak dalej, a tak dalej. Tak realnie i rozsądnie. 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 kontrolę.

No pytanie właśnie. Pytanie, czy chcesz będzie używać tego krokowo, bo to ci będzie wiele nie da. Inaczej, prawdopodobnie jak przemigrujesz się na nowy ingress controller, to możesz zapomnieć o Gateway API i nie będzie ci to przeszkadzać. Tak, chociaż dla niektórych organizacji i większych to może mieć sens trzymanie tego przejąć części tego właśnie. 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. Nie, ja mówię o tym scenariuszu. Jak część była wyklikiwana, część była zabana tak i tak dalej. Uspłynienie tego na poziomie... 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 Gateway jakiegoś fairparty na go jak do Gateway API i do YAML-a. Nie oszukujmy się, takie coś nie nastąpi.

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.

Bo jest prosty. To jest naprawdę. Można się zastanowić nad HAProxy ingresem. Można go rozważyć, bo to też jest bardzo sprawdzone w boju rozwiązanie. 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. 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 może się do mnie przyczepić, ale bym powiedział, że będzie to taka referencyjna architektura, o tak to nazwijmy. Siły nie rozwijają, więc jak najbardziej tak. Tak, no i Envoy jest całą podstawą całej sieciówki teraz takich rozwiązań sieciowych. Pewnie ten, cały Google Cloud i Load Balancery na tym latają, więc jest to naprawdę wymęczone w boju. Więc to jest w tym. Dobrze, to w takim razie podsumowanie powoli robimy. Co teraz, w kilku zdaniach? Dobra, pierwsze, jak używasz ingress-controllera, możesz to sobie sprawdzić, co tam masz, kubectl, get-pods i szukamy w tych selektorem ap-kubernetes-io-name ingress-nginx, czy masz.