🥇W jaki sposób pod w Kubernetesie uzyskuje adres IP

Notatka. przeł.: Ten artykuł, napisany przez inżyniera SRE z LinkedIn, szczegółowo opisuje wewnętrzną magię Kubernetesa – a dokładniej interakcję CRI, CNI i kube-apiserver – która ma miejsce, gdy kolejnemu podowi trzeba przypisać adres IP.

Jeden z podstawowych wymagań Model sieci Kubernetesa polega na tym, że każdy pod musi mieć swój własny adres IP, a każdy inny pod w klastrze musi mieć możliwość skontaktowania się z nim pod tym adresem. Istnieje wielu „dostawców” sieci (Flannel, Calico, Canal itp.), którzy pomagają we wdrażaniu tego modelu sieci.

Kiedy zaczynałem pracę z Kubernetesem, nie było dla mnie do końca jasne, w jaki sposób pody uzyskują swoje adresy IP. Nawet mając wiedzę o działaniu poszczególnych komponentów, trudno było sobie wyobrazić je współpracujące. Wiedziałem np. do czego służą wtyczki CNI, ale nie miałem pojęcia jak dokładnie się nazywają. Dlatego zdecydowałem się napisać ten artykuł, aby podzielić się wiedzą na temat różnych komponentów sieciowych i tego, jak ze sobą współdziałają w klastrze Kubernetes, który pozwala każdemu podowi uzyskać swój własny, unikalny adres IP.

Istnieją różne sposoby organizowania sieci w Kubernetesie, podobnie jak istnieją różne opcje środowiska wykonawczego dla kontenerów. Ta publikacja będzie używana Flanela do organizowania sieci w klastrze i jako środowisko wykonywalne - Kontenerowe. Zakładam również, że wiesz, jak działa sieć między kontenerami, więc poruszę ten temat krótko, tak dla kontekstu.

Kilka podstawowych pojęć

Kontenery i sieć: krótki przegląd

W sieci znajduje się wiele doskonałych publikacji wyjaśniających, jak kontenery komunikują się ze sobą w sieci. Dlatego przedstawię jedynie ogólny przegląd głównych koncepcji i ograniczę się do jednego podejścia, które polega na tworzeniu… Linux- mostkowanie i enkapsulacja pakietów. Szczegóły pominięto, ponieważ sam temat sieci kontenerowych zasługuje na osobny artykuł. Poniżej znajdują się linki do szczególnie pouczających i wnikliwych publikacji.

Kontenery na jednym hoście

Jednym ze sposobów organizacji komunikacji za pomocą adresów IP między kontenerami działającymi na tym samym hoście jest tworzenie Linux-bridge. W tym celu w Kubernetes (i Dockerze) tworzone są urządzenia wirtualne. veth (wirtualny Ethernet). Jeden koniec urządzenia Veth łączy się z sieciową przestrzenią nazw kontenera, a drugi z Linux-most w sieci hosta.

Wszystkie kontenery na pojedynczym hoście mają jeden koniec véth podłączony do mostu, za pomocą którego mogą się ze sobą komunikować za pośrednictwem adresów IP. Linux- most posiada również adres IP i działa jako brama dla ruchu wychodzącego (wyjściowego) z kontenerów przeznaczonych dla innych węzłów.

Kontenery na różnych hostach

Hermetyzacja pakietów to jedna z metod umożliwiających kontenerom w różnych węzłach komunikację między sobą przy użyciu adresów IP. We Flannel technologia jest odpowiedzialna za tę możliwość. vxlan, który „pakuje” oryginalny pakiet w pakiet UDP, a następnie wysyła go do miejsca docelowego.

W klastrze Kubernetes Flannel tworzy urządzenie vxlan i odpowiednio aktualizuje tabelę tras w każdym węźle. Każdy pakiet przeznaczony do kontenera na innym hoście przechodzi przez urządzenie vxlan i jest hermetyzowany w pakiecie UDP. W miejscu docelowym zagnieżdżony pakiet jest wyodrębniany i przekazywany do żądanego zasobnika.

Uwaga: to tylko jeden ze sposobów zorganizowania komunikacji sieciowej pomiędzy kontenerami.

Co to jest CRI?

CRI (interfejs wykonawczy kontenera) to wtyczka, która pozwala kubeletowi używać różnych środowisk wykonawczych kontenerów. Interfejs API CRI jest wbudowany w różne środowiska wykonawcze, dzięki czemu użytkownicy mogą wybrać dowolne środowisko wykonawcze.

Co to jest CNI?

Projekt CNI jest a specyfikacja zorganizować uniwersalne rozwiązanie sieciowe dla Linux-kontenerów. Ponadto zawiera wtyczki, odpowiedzialny za różne funkcje podczas konfigurowania sieci kapsuł. Wtyczka CNI jest plikiem wykonywalnym zgodnym ze specyfikacją (niektóre wtyczki omówimy poniżej).

Przydzielanie podsieci do węzłów w celu przypisywania adresów IP do podów

Ponieważ każdy pod w klastrze musi mieć adres IP, ważne jest, aby upewnić się, że adres ten jest unikalny. Osiąga się to poprzez przypisanie każdemu węzłowi unikalnej podsieci, z której następnie moduły w tym węźle otrzymują adresy IP.

Kontroler węzła IPAM

Kiedy nodeipam przekazywany jako parametr flagi --controllers menedżer-kontrolera kube, przydziela oddzielną podsieć (podCIDR) każdemu węzłowi z klastra CIDR (tj. zakresu adresów IP dla sieci klastrowej). Ponieważ te podCIDR nie nakładają się na siebie, możliwe jest przydzielenie każdemu podowi unikalnego adresu IP.

Węzeł Kubernetes otrzymuje podCIDR podczas początkowej rejestracji w klastrze. Aby zmienić podCIDR węzłów, należy je wyrejestrować, a następnie ponownie zarejestrować, wprowadzając w międzyczasie odpowiednie zmiany w konfiguracji warstwy kontrolnej Kubernetes. Możesz wyświetlić podCIDR węzła za pomocą następującego polecenia:

$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24

Kubelet, środowisko wykonawcze kontenerów i wtyczki CNI: jak to wszystko działa

Planowanie poda na węzeł obejmuje wiele kroków przygotowawczych. W tej sekcji skupię się tylko na tych, które są bezpośrednio związane z konfiguracją sieci podów.

Zaplanowanie poda do określonego węzła uruchamia następujący łańcuch zdarzeń:

FAQ: Architektura wtyczek Containerd CRI.

Interakcja między środowiskiem wykonawczym kontenera a wtyczkami CNI

Każdy dostawca sieci ma własną wtyczkę CNI. Środowisko wykonawcze kontenera uruchamia go, aby skonfigurować sieć dla modułu podczas jego uruchamiania. W przypadku kontenera wtyczka CNI jest uruchamiana przez wtyczkę Kontenerowy CRI.

Ponadto każdy dostawca ma własnego agenta. Jest instalowany na wszystkich węzłach Kubernetes i odpowiada za konfigurację sieciową podów. Ten agent jest albo dołączony do konfiguracji CNI, albo niezależnie tworzy go w węźle. Konfiguracja pomaga wtyczce CRI ustawić, którą wtyczkę CNI ma wywołać.

Można dostosować lokalizację konfiguracji CNI; domyślnie jest włączone /etc/cni/net.d/<config-file>. Administratorzy klastra są również odpowiedzialni za instalację wtyczek CNI na każdym węźle klastra. Ich lokalizację można również dostosować; domyślny katalog - /opt/cni/bin.

W przypadku korzystania z kontenera w sekcji można ustawić ścieżki do konfiguracji wtyczki i plików binarnych [plugins.«io.containerd.grpc.v1.cri».cni] в plik konfiguracyjny kontenera.

Ponieważ używamy Flannel jako naszego dostawcy sieci, porozmawiajmy trochę o jego konfiguracji:

Flanneld (demon Flannela) jest zwykle instalowany w klastrze jako zestaw DaemonSet install-cni jak kontener startowy.
Install-cni tworzy Plik konfiguracyjny CNI (/etc/cni/net.d/10-flannel.conflist) w każdym węźle.
Flanneld tworzy urządzenie vxlan, pobiera metadane sieciowe z serwera API i monitoruje aktualizacje podów. Po ich utworzeniu rozdziela trasy do wszystkich zasobników w klastrze.
Trasy te umożliwiają podom komunikację między sobą za pośrednictwem adresów IP.

Po bardziej szczegółowe informacje na temat twórczości Flaneli polecam skorzystać z linków na końcu artykułu.

Oto schemat interakcji pomiędzy wtyczką Containerd CRI i wtyczkami CNI:

Jak widać powyżej, kubelet wywołuje wtyczkę Containerd CRI w celu utworzenia poda, który następnie wywołuje wtyczkę CNI w celu skonfigurowania sieci poda. W ten sposób wtyczka CNI dostawcy sieci wywołuje inne podstawowe wtyczki CNI w celu skonfigurowania różnych aspektów sieci.

Interakcja pomiędzy wtyczkami CNI

Istnieją różne wtyczki CNI, których zadaniem jest pomoc w skonfigurowaniu komunikacji sieciowej pomiędzy kontenerami na hoście. W tym artykule omówimy trzy z nich.

Wtyczka CNI Flanelowa

Gdy używasz Flannel jako dostawcy sieci, komponent Containerd CRI wywołuje Wtyczka CNI Flanelowaza pomocą pliku konfiguracyjnego CNI /etc/cni/net.d/10-flannel.conflist.

$ cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cni0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
         "ipMasq": false,
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    }
  ]
}

Wtyczka Flannel CNI działa w połączeniu z Flanneld. Podczas uruchamiania Flanneld pobiera podCIDR i inne szczegóły związane z siecią z serwera API i zapisuje je w pliku /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

Wtyczka Flannel CNI wykorzystuje dane z /run/flannel/subnet.env aby skonfigurować i wywołać wtyczkę mostu CNI.

Mostek z wtyczkami CNI

Ta wtyczka nazywa się z następującą konfiguracją:

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

Przy pierwszym połączeniu tworzy Linux-most z «name»: «cni0», który jest określony w konfiguracji. Następnie dla każdego kontenera tworzona jest para veth. Jeden koniec jest połączony z przestrzenią nazw sieci kontenera, a drugi jest w niej zawarty. Linux-most w sieci hosta. Mostek z wtyczkami CNI łączy wszystkie kontenery hosta Linux-most w sieci hosta.

Po zakończeniu konfigurowania pary veth wtyczka Bridge wywołuje lokalną wtyczkę CNI IPAM hosta. Typ wtyczki IPAM można skonfigurować w konfiguracji CNI, której wtyczka CRI używa do wywoływania wtyczki Flannel CNI.

Wtyczki IPAM CNI hostowane lokalnie

Mostek połączeń CNI Host-lokalna wtyczka IPAM CNI z następującą konfiguracją:

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

Wtyczka IPAM hosta lokalnego (IP Adres Mzarządzanie - zarządzanie adresami IP) zwraca adres IP kontenera z podsieci i przechowuje przydzielony adres IP na hoście w katalogu określonym w sekcji dataDir Do /var/lib/cni/networks/<network-name=cni0>/<ip>. Plik ten zawiera identyfikator kontenera, do którego przypisany jest ten adres IP.

Wywołując lokalną wtyczkę IPAM hosta, zwraca następujące dane:

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

Streszczenie

Menedżer kontrolera Kube przypisuje podCIDR do każdego węzła. Pody każdego węzła otrzymują adresy IP z przestrzeni adresowej w przydzielonym zakresie podCIDR. Ponieważ numery podCIDR węzłów nie pokrywają się, wszystkie pody otrzymują unikalne adresy IP.

Administrator klastra Kubernetes konfiguruje i instaluje kubelet, środowisko uruchomieniowe kontenera, agenta dostawcy sieci oraz kopiuje wtyczki CNI do każdego węzła. Podczas uruchamiania agent dostawcy sieci generuje konfigurację CNI. Kiedy kapsuła jest przypisywana do węzła, kubelet wywołuje wtyczkę CRI, aby ją utworzyć. Następnie, jeśli używany jest kontenerd, wtyczka Containerd CRI wywołuje wtyczkę CNI określoną w konfiguracji CNI, aby skonfigurować sieć kapsuły. W rezultacie kapsuła otrzymuje adres IP.

Zrozumienie wszystkich subtelności i niuansów wszystkich tych interakcji zajęło mi trochę czasu. Mam nadzieję, że to doświadczenie pomoże Ci lepiej zrozumieć, jak działa Kubernetes. Jeśli się w czymś mylę, proszę o kontakt pod adresem Twitter lub pod adresem cześć@ronaknathani.com. Jeśli chcesz omówić pewne aspekty tego artykułu lub cokolwiek innego, skontaktuj się z nami. Bardzo chciałbym z Tobą porozmawiać!