Dzisiaj tematów kilka i będzie o uaktualnionym ebooku, o temacie głównym dla wszystkich korzystających z Kubernetesa i na koniec o ciekawym narzędziu dla zarządzających własnymi klastrami.

Uaktualniony e-book o darmowym klastrze

Dokonałem ostatnio przeglądu mojego ebooka, który umożliwia uruchomienie czterowęzłowego klastra w chmurze.
Przy okazji zaktualizowałem go i uszczegółowiłem kilka elementów – głównie tych związanych z ustawianiem load balancera dla dostępu i dla Ingressu, ponieważ wymagany był dodatkowy krok.
Z tej okazji dodałem do swojej osobistej kolekcji dodatkowy klaster i teraz mam już łącznie dwa. Mojego pierwszego używam już od ponad dwóch lat nie płacąc ani grosza, a ostatnio nawet zaktualizowałem go do najnowszej wersji kubernetesa (całość operacji trwała około 10 minut).

Jeśli masz ochotę to zapraszam do jego pobrania.

Ingress czy Service?

Ostatnio prowadziłem szkolenie gdzie ponownie temat Ingress był tym najtrudniej przyswajalnym. Widziałem to po oczach ludzi, gdy tłumaczyłem różnice między load balancerami L7 i L4  w oparciu o model ISO/OSI.
Dla tych co mają do czynienia z sieciami temat nie jest tak skomplikowany, a dla reszty zasada użycia jest dość prosta:

Jeśli chcesz puszczać coś na zewnątrz i jest to aplikacja komunikująca się po http to w większości wypadków użyjesz obiektu Ingress.

W przeciwnym wypadku pozostaje Ci obiekt Service typu Load Balancer. Pewnym wyzwaniem może być jedynie brak jego obsługi w przypadku własnych klastrów poza chmurą, ale to da się ogarnąć co omawiam w jednym z modułów części Pro mojego kursu.

A co z ruchem wewnątrz klastra?

Service dla ruchu wewnętrznego

To wydaje się dość proste – dla ruchu wewnętrznego używamy obiektu Service typu ClusterIP. Jest to uniwersalne rozwiązanie, które zadziała zawsze i wszędzie niezależnie od tego gdzie jest uruchomiony klaster.
Ale w przypadku klastra w chmurze możliwe jest również użycie typu Load Balancer. Dostawcy tacy jak AWS, Azure czy GCP umożliwiają użycie ich natywnych load balancerów dla ruchu wewnątrz klastra.
To może mieć sens jeśli chcesz użyć zaawansowanych funkcji takich jak connection draining, logowanie ruchu czy natywna integracja z ich usługami (np. WAF).

A czemu by nie użyć zaawansowanych funkcji Ingress do tego typu ruchu?

Ingress wewnątrz klastra?

Większość używa ingresu dla ruchu zewnętrznego, bo z to ogranicza koszty, ułatwia zarządzanie i umożliwia wykorzystanie funkcji protokołu http do kontroli ruchu.
Podobnie Ingress może być użyty dla ruchu wewnętrznego! Nie jest to popularne, ponieważ przypadków użycia nie ma tak dużo. Wiąże się to też z potencjalnie większymi opóźnieniami, gdyż przekazywanie ruchu http wykonywane jest przez oprogramowanie (kontrolery Ingress), a nie sam kernel jak w przypadku ruchu sieciowego (load balancery ustawianie przez Service).
Ingress może być dobrym sposobem na rozdzielenie aplikacji webowych komunikujących się wewnątrz klastra. Mogą to być mikroserwisy z różnych bounded contextów z Domain-driven Design (DDD).
Może być to też konieczność filtrowania ruchu na L7 lub używania funkcji takich jak sticky sessions, szyfrowanie TLS, mTLS, uwierzytelnianie, autoryzacja lub innych.

🧰 Narzędzie tygodnia

Zbudowałeś klaster i szukasz lepszego sposobu na aktualizację węzłów?
Polecam projekt od Adobe – k8s-shredder. Dzięki niemu szybciej i sprawniej zaktualizujesz klaster z łagodnymi krokami niwelującymi przerwy w dostępie do uruchomionych serwisów.