ClusterIP vs NodePort vs LoadBalancer

sorry, że zawracam głowę takimi rzeczami... niby naczytałem się o co w tym chodzi, ale praktyka burzy mi całe zrozumienie.

Myślałem, że ClusterIP umożliwia tylko komunikację między podami. Ale można sforłardować cały serwis przez minikube i on chyba zadnego serwisu wtedy nie tworzy nowego tylko jakieś proxy pewnie.

Myślałem, że NodePort umożliwia komunikacje między klientami tej samej sieci, a podami. Ale wychodzi na to, że mój host na którym lata cluster jest w innej sieci, on sobie tworzy tam jakąś wirtualną? W takim razie po co NodePort... Z lokalnego kompa muszę strzelić do clustra i on forwarduje do NodePort'a. ClusterID nie wystarczyłby?

Myślałem, że LoadBalancer umożliwia komunikację między całym internetem a podami. A nie widzę by zachowywał się inaczej niż NodePort.

ClusterIP jest routowalny tylko wewnątrz klastra (nie wiem jak masz to odpalone lokalnie - pewnie można na wiele sposobów, ale produkcyjnie klaster musi mieć wydzieloną swoją adresację, która się nie pokrywa z innymi adresacjami w twojej sieci).

NodePort umożliwia wystawienie serwisu na zewnątrz za pomocą adresu IP węzła. NodePort otworzy port na każdym węźle w klastrze i uderzając bezpośrednio na ten <adres-węzła>:<node-port> będziesz mógł dobić się do serwisu. Ale w takim przypadku klient musi znać konkretne adresy IP węzłów, a te w środowiskach chmurowych są dynamiczne. Zaraz cloud provider może ci ubić starą maszynkę, dostawić nową i masz nowy adres IP węzła i problem ;) Samemu musisz też ogarniać load balancing pomiędzy nodami.

LoadBalancer z kolei to jest coś co musi być zaimplementowane przez providera udostępniającego ci klaster. W środowiskach chmurowych utworzy ci się chmurowy load balancer, którego kubernetes z automatu będzie konfigurował w momencie wystawiania nowych serwisów, dodawania/usuwania węzłów, czyli pozbywasz się problemu z NodePort, gdzie klient musiał znać wewnętrzne adresy twoich węzłów, które są dynamiczne.

W przypadku klastrów bare-metal, według mojej wiedzy rzeczywiście LoadBalancer nie różni się od NodePort (ale mogę się mylić). Są jakieś projekty typu MetalLB, które jakoś obsługują serwisy LoadBalancer na klastrach bare-metal, ale nigdy z tego nie korzystałem, bo korzystałem tylko z klastrów chmurowych :)

some_ONE napisał(a):

W przypadku klastrów bare-metal, według mojej wiedzy rzeczywiście LoadBalancer nie różni się od NodePort (ale mogę się mylić). Są jakieś projekty typu MetalLB, które jakoś obsługują serwisy LoadBalancer na klastrach bare-metal, ale nigdy z tego nie korzystałem, bo korzystałem tylko z klastrów chmurowych :)

No nie wiem. LB wymaga osobnego zewnętrznego IP dla każdego serwisu. NodePort wymaga osobnego portu dla każdego serwisu, ale IP pochodzi od węzła.

Do tego co napisał @some_ONE dodam że ze względów security (czyli bezpośrednie wystawiania na swiat naszych komponentów) lepiej unikać NodePortów, tylko używac LoadBalancerów

A czy to normalne, że przed ingresa wystawia się jeszcze load balancera? Po co tak?

Load balancer -> ingress -> [serwisy (Load Balancery)] -> pody

to normalna ścieżka?

Bo Ingress musi być jeszcze jakoś wystawiony na świat, o ile ten Ingress jest w klastrze, a nie przed klastrem (w sumie nie wiem czy się tak da, ale nic chyba nie stoi na przeszkodzi by ingress controller był w klastrze, a sam LB L7 robiący za ingress przed klastrem).

myślałem, że zawsze jest przed klastrem

No nie. Ingress to zwykły Load balancer L7 (czytaj HTTP/HTTPS), jak Nginx, Kong albo HAproxy i parę innych, który jest automatycznie konfigurowany przez jakiś ingress controller.

LitwinWileński napisał(a):

A czy to normalne, że przed ingresa wystawia się jeszcze load balancera? Po co tak?

Load balancer -> ingress -> [serwisy (Load Balancery)] -> pody

to normalna ścieżka?

Standardowo ingress controller masz w klastrze i on się konfiguruje na podstawie definicji ingressów, które wrzucasz do klastra.
Ingress za pomocą ingress controllera realizuje funkcjonalność L7 load balancera.

Teraz znowu chcesz jakoś wystawić ten ingress controller na świat (tak jak wcześniej była mowa o wystawianiu serwisów, bo ingress controller będzie serwisem w klastrze). Więc albo go wystawiasz jako sam NodePort (co nie ma sensu) albo jako LoadBalancer.

W tym schemacie który rozrysowałeś nie do końca rozumiem co masz na myśli przez serwisy (Load Balancer). Jak używasz ingressa to zazwyczaj pojedynczych serwisów nie wystawiasz oddzielnie jako serwisy typu LoadBalancer tylko to ingress controller zajmuje się routingiem do nich na podstawie hosta/ścieżek.