Pojęcia i zasoby związane z siecią w Kubernetesie.
Model sieci Kubernetesa składa się z kilku części:
Każdy pod otrzymuje swój własny unikalny adres IP w całym klastrze.
localhost.Sieć podów (znana również jako sieć klastra) obsługuje komunikację między podami. Zapewnia, że (z zastrzeżeniem celowego segmentowania sieci):
Wszystkie pody mogą komunikować się ze wszystkimi innymi podami, niezależnie od tego, czy znajdują się na tym samym węźle, czy na różnych węzłach. Pody mogą komunikować się ze sobą bezpośrednio, bez użycia proxy ani translacji adresów (NAT).
W systemie Windows ta reguła nie dotyczy podów z siecią hosta.
Agenci na węźle (takie jak demony systemowe czy kubelet) mogą komunikować się ze wszystkimi podami na tym węźle.
Obiekt API Service pozwala na udostępnienie stabilnego (długoterminowego) adresu IP lub nazwy hosta dla usługi zrealizowanej przez jeden lub więcej backendowych podów, gdzie poszczególne pody składające się na usługę mogą zmieniać się w czasie.
Kubernetes automatycznie zarządza obiektami EndpointSlice aby dostarczać informacje o Podach obsługujących daną usługę.
Implementacja proxy serwisu monitoruje zestaw obiektów Service i EndpointSlice, a także konfiguruje warstwę danych w celu kierowania ruchu serwisowego do jego backendów, używając API systemu operacyjnego lub dostawcy chmury do przechwytywania lub przepisania pakietów.
Obiekt API Gateway (lub jego poprzednik, Ingress ) umożliwia udostępnienie usług klientom znajdującym się poza klastrem.
type: LoadBalancer, pod warunkiem
korzystania z obsługiwanego dostawcy chmury (Cloud Provider).NetworkPolicy to wbudowane API Kubernetesa, które pozwala na kontrolowanie ruchu pomiędzy podami, lub pomiędzy podami a światem zewnętrznym.
W starszych systemach kontenerowych nie było automatycznej łączności pomiędzy kontenerami na różnych hostach, więc często konieczne było jawne tworzenie połączeń między kontenerami lub mapowanie portów kontenerów na porty hostów, aby były osiągalne przez kontenery na innych hostach. W Kubernetesie nie jest to potrzebne; model Kubernetesa polega na tym, że pody mogą być traktowane podobnie jak maszyny wirtualne lub fizyczne hosty z perspektyw alokacji portów, nazewnictwa, wykrywania usług, równoważenia obciążenia, konfiguracji aplikacji i migracji.
Tylko kilka części tego modelu jest implementowanych przez Kubernetesa samodzielnie. Dla pozostałych części Kubernetes definiuje API, ale odpowiadającą funkcjonalność zapewniają zewnętrzne komponenty, z których niektóre są opcjonalne:
Konfiguracja przestrzeni nazw sieci poda jest obsługiwana przez oprogramowanie systemowe implementujące Interfejs Uruchomieniowy Kontenera (ang. Container Runtime Interface).
Sama sieć podów jest zarządzana przez implementację sieci podów. W systemie Linux, większość środowisk uruchomieniowych kontenerów używa Container Networking Interface (CNI) do interakcji z implementacją sieci podów, dlatego te implementacje często nazywane są wtyczkami CNI.
Kubernetes dostarcza domyślną implementację proxy usług, nazywaną kube-proxy, ale niektóre implementacje sieciowe poda używają zamiast tego własnego proxy usług, które jest ściślej zintegrowane z resztą implementacji.
NetworkPolicy jest zazwyczaj również implementowane przez implementację sieci poda. (Niektóre prostsze implementacje sieci poda nie implementują NetworkPolicy, lub administrator może zdecydować się na skonfigurowanie sieci poda bez wsparcia dla NetworkPolicy. W takich przypadkach API będzie nadal obecne, ale nie będzie miało żadnego efektu.)
Istnieje wiele implementacji Gateway API, z których niektóre są specyficzne dla określonych środowisk chmurowych, inne bardziej skupione na środowiskach "bare metal", a jeszcze inne bardziej ogólne.
Samouczek Łączenie aplikacji z usługami pozwala na naukę o Usługach i sieciach Kubernetesa poprzez praktyczne przykłady.
Dokumentacja Sieci Klastra wyjaśnia, jak skonfigurować sieć dla twojego klastra, a także dostarcza przegląd użytych technologii.