Konrad Kowalski (rootsher)Principal Platform & Reliability Architect010011011001111111001100011010101000000100001000

Networking w Kubernetes

data
kategoria
Containers
także w
Networking
czytanie
2 min / 455 słów

Samo uruchomienie kontenera nie wystarcza.

Pod musi jeszcze:

  • dostać adres IP,
  • komunikować się z innymi Podami,
  • korzystać z Service,
  • mieć możliwość wysyłania i odbierania ruchu.

Networking w Kubernetes jest dlatego osobnym i bardzo ważnym elementem architektury.

Najważniejsze pojęcia w tym obszarze to:

  • model sieci Podów,
  • CNI,
  • kube-proxy,
  • datapath realizowany np. przez iptables albo eBPF.

Model sieci Kubernetes

Kubernetes zakłada, że każdy Pod może mieć własny adres IP.

To istotne, bo dzięki temu Pody mogą komunikować się ze sobą bez ręcznego mapowania portów na poziomie hosta.

W uproszczeniu:

text
Pod A: 10.0.1.10
Pod B: 10.0.2.15

Pod A może wysłać ruch do Pod B.

Sposób, w jaki ten ruch faktycznie przechodzi przez sieć, zależy od implementacji.

CNI: Container Network Interface

Kubernetes nie implementuje całej sieci samodzielnie.

Zamiast tego korzysta ze standardu CNI (Container Network Interface).

CNI definiuje sposób integracji runtime i klastra z pluginem sieciowym.

Popularne rozwiązania to:

  • Calico,
  • Cilium,
  • Flannel.

Plugin CNI może odpowiadać m.in. za:

  • przydzielenie adresu IP,
  • utworzenie interfejsów,
  • routing,
  • konfigurację tras,
  • polityki sieciowe.

Zakres zależy od konkretnego rozwiązania.

Dlaczego CNI istnieje

Podobnie jak CRI oddziela Kubernetes od konkretnego container runtime, tak CNI oddziela Kubernetes od konkretnej implementacji sieci.

To ważny wzorzec architektoniczny.

Kubernetes określa:

Pod powinien mieć działającą sieć

ale nie narzuca jednego sposobu realizacji.

Service i wirtualny adres

Pody mogą być tworzone i usuwane.

Ich adresy IP mogą się zmieniać.

Dlatego bezpośrednie łączenie aplikacji z konkretnym Pod IP jest niewygodne.

Kubernetes wprowadza obiekt Service, który daje stabilny punkt dostępu do grupy endpointów.

Przykładowo:

text
Service IP
   |
   v
Pod A
Pod B
Pod C

Service IP jest adresem logicznym. Ktoś musi jeszcze sprawić, że ruch wysłany na ten adres faktycznie trafi do jednego z Podów.

kube-proxy

Klasycznie tę rolę realizuje kube-proxy.

Proces działa na node i konfiguruje mechanizmy sieciowe systemu operacyjnego tak, aby ruch do Service był kierowany do odpowiednich endpointów.

W zależności od trybu i środowiska może korzystać z mechanizmów takich jak:

  • iptables,
  • wcześniej również IPVS.

Ważne:

kube-proxy zwykle nie działa jak klasyczny proxy aplikacyjny, przez który przechodzi każdy pakiet.

Często jego zadaniem jest przygotowanie reguł w kernelu.

eBPF i nowszy datapath

W rozwiązaniach takich jak Cilium część funkcji może być realizowana przez eBPF.

W takim modelu możliwe jest zastąpienie klasycznego kube-proxy własnym datapath.

Dla podstaw architektury najważniejsze jest jednak nie to, jaka technologia jest użyta, ale jaka funkcja musi zostać spełniona:

text
Service IP
-> musi zostać przetłumaczony
-> na właściwy endpoint

CNI vs kube-proxy

To bardzo częste źródło nieporozumień.

Najprościej:

text
CNI
-> zapewnia connectivity Podów

kube-proxy / eBPF datapath
-> realizuje zachowanie Service

To nie są dwa zamienne komponenty.

Dotykają tej samej domeny, czyli sieci, ale rozwiązują inne problemy.

Co zapamiętać

Networking Kubernetes można uprościć do trzech pytań:

  1. Jak Pod dostaje IP?
  2. Jak Pod komunikuje się z innym Podem?
  3. Jak ruch do Service trafia do właściwego endpointu?

CNI odpowiada głównie na pierwsze dwa.

kube-proxy lub alternatywny datapath odpowiada na trzecie.