🥇Jak pod v Kubernetes získá IP adresu

Poznámka. přel.: Tento článek, napsaný SRE inženýrem z LinkedIn, se podrobně zabývá vnitřní magií v Kubernetes – přesněji interakcí CRI, CNI a kube-apiserver – ke které dochází, když je třeba dalšímu podu přiřadit IP adresu.

Jeden ze základních požadavků Síťový model Kubernetes je, že každý modul musí mít svou vlastní IP adresu a jakýkoli jiný modul v clusteru jej musí mít možnost kontaktovat na této adrese. Existuje mnoho síťových „poskytovatelů“ (Flannel, Calico, Canal atd.), kteří pomáhají implementovat tento model sítě.

Když jsem poprvé začal pracovat s Kubernetes, nebylo mi úplně jasné, jak přesně pody získávají své IP adresy. I když jsme pochopili, jak jednotlivé komponenty fungovaly, bylo těžké si představit, že by spolupracovaly. Věděl jsem například, k čemu slouží pluginy CNI, ale netušil jsem, jak se přesně jmenují. Proto jsem se rozhodl napsat tento článek, abych se podělil o znalosti o různých síťových komponentách a o tom, jak spolupracují v clusteru Kubernetes, který umožňuje každému modulu získat svou vlastní jedinečnou IP adresu.

Existují různé způsoby, jak organizovat sítě v Kubernetes, stejně jako existují různé možnosti běhu pro kontejnery. Tato publikace bude používat Flanel organizovat síť v clusteru a jako spustitelné prostředí - Kontejner. Také vycházím z předpokladu, že víte, jak funguje síťování mezi kontejnery, takže se toho jen krátce dotknu, jen pro kontext.

Některé základní pojmy

Kontejnery a síť: Stručný přehled

Na internetu existuje spousta vynikajících publikací, které vysvětlují, jak kontejnery vzájemně komunikují v síti. Proto poskytnu pouze obecný přehled hlavních konceptů a omezím se na jeden přístup, který zahrnuje vytvoření Linux- přemostění a zapouzdření paketů. Podrobnosti jsou vynechány, protože téma síťování kontejnerů si samo o sobě zaslouží samostatný článek. Níže jsou uvedeny odkazy na některé obzvláště informativní a užitečné publikace.

Kontejnery na jednom hostiteli

Jeden ze způsobů, jak organizovat komunikaci pomocí IP adres mezi kontejnery běžícími na stejném hostiteli, zahrnuje vytvoření Linux-bridge. Za tímto účelem se v Kubernetes (a Dockeru) vytvářejí virtuální zařízení. veth (virtuální ethernet). Jeden konec zařízení veth se připojuje k síťovému jmennému prostoru kontejneru, druhý k Linux-most na hostitelské síti.

Všechny kontejnery na jednom hostiteli mají jeden konec veth připojený k mostu, přes který mohou vzájemně komunikovat prostřednictvím IP adres. Linux-most má také IP adresu a funguje jako brána pro odchozí (výstupní) provoz z podů určených pro jiné uzly.

Kontejnery na různých hostitelích

Zapouzdření paketů je jednou z metod, která umožňuje kontejnerům na různých uzlech vzájemně komunikovat pomocí IP adres. Ve společnosti Flannel je za tuto příležitost zodpovědná technologie. vxlan, který „zabalí“ původní paket do paketu UDP a poté jej odešle na místo určení.

V clusteru Kubernetes vytvoří Flannel zařízení vxlan a podle toho aktualizuje směrovací tabulku na každém uzlu. Každý paket určený pro kontejner na jiném hostiteli prochází zařízením vxlan a je zapouzdřen do paketu UDP. V cíli je vnořený paket extrahován a předán do požadovaného modulu.

Poznámka: Toto je pouze jeden způsob, jak organizovat síťovou komunikaci mezi kontejnery.

Co je CRI?

CRI (Container Runtime Interface) je plugin, který umožňuje kubeletu používat různá prostředí pro běh kontejnerů. Rozhraní CRI API je zabudováno do různých běhových prostředí, takže uživatelé si mohou vybrat běhové prostředí podle svého výběru.

Co je CNI?

Projekt CNI je a Specifikace zorganizovat univerzální síťové řešení pro Linux-kontejnery. Kromě toho zahrnuje pluginy, zodpovědný za různé funkce při nastavování sítě pod. CNI plugin je spustitelný soubor, který vyhovuje specifikaci (některé pluginy probereme níže).

Přidělení podsítí uzlům pro přidělování IP adres podům

Protože každý modul v clusteru musí mít IP adresu, je důležité zajistit, aby tato adresa byla jedinečná. Toho je dosaženo tím, že každému uzlu je přiřazena jedinečná podsíť, ze které jsou pak podům na tomto uzlu přiřazeny IP adresy.

Node IPAM Controller

Kdy nodeipam předán jako parametr příznaku --controllers kube-controller-manager, přiděluje samostatnou podsíť (podCIDR) každému uzlu z klastrového CIDR (tj. rozsah IP adres pro klastrovou síť). Protože se tyto podCIDR nepřekrývají, je možné, aby každému podu byla přidělena jedinečná IP adresa.

Uzel Kubernetes je přiřazen podCIDR, když je zpočátku zaregistrován v clusteru. Chcete-li změnit podCIDR uzlů, musíte je zrušit a poté je znovu zaregistrovat a mezitím provést příslušné změny v konfiguraci řídicí vrstvy Kubernetes. PodCIDR uzlu můžete zobrazit pomocí následujícího příkazu:

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

Kubelet, kontejnerové runtime a CNI pluginy: jak to všechno funguje

Naplánování modulu na uzel zahrnuje mnoho přípravných kroků. V této části se zaměřím pouze na ty, které přímo souvisejí s nastavením sítě pod.

Naplánování podu do určitého uzlu spustí následující řetězec událostí:

FAQ: Architektura pluginů Containerd CRI.

Interakce mezi kontejnerem runtime a CNI pluginy

Každý poskytovatel sítě má svůj vlastní CNI plugin. Běhové prostředí kontejneru jej spouští, aby nakonfigurovalo síť pro pod při spouštění. V případě kontejneru je plugin CNI spuštěn pluginem Kontejnerové CRI.

Každý poskytovatel má navíc svého vlastního zástupce. Je nainstalován na všech uzlech Kubernetes a je zodpovědný za konfiguraci sítě podů. Tento agent je buď součástí konfigurace CNI, nebo jej nezávisle vytvoří na uzlu. Konfigurace pomáhá zásuvnému modulu CRI nastavit, který zásuvný modul CNI má volat.

Umístění konfigurace CNI lze přizpůsobit; ve výchozím nastavení je v /etc/cni/net.d/<config-file>. Správci klastru jsou také zodpovědní za instalaci zásuvných modulů CNI na každý uzel klastru. Jejich umístění je také přizpůsobitelné; výchozí adresář - /opt/cni/bin.

Při použití kontejneru lze v sekci nastavit cesty pro konfiguraci pluginu a binární soubory [plugins.«io.containerd.grpc.v1.cri».cni] в kontejnerový konfigurační soubor.

Vzhledem k tomu, že jako poskytovatele sítě používáme Flannel, pojďme si říci něco o jeho nastavení:

Flanneld (Flannelův démon) je obvykle instalován v clusteru jako DaemonSet s install-cni jak init kontejner.
Install-cni vytváří konfigurační soubor CNI (/etc/cni/net.d/10-flannel.conflist) na každém uzlu.
Flanneld vytvoří zařízení vxlan, načte síťová metadata ze serveru API a sleduje aktualizace pod. Jakmile jsou vytvořeny, distribuuje trasy do všech modulů v celém clusteru.
Tyto trasy umožňují modulům komunikovat mezi sebou prostřednictvím IP adres.

Pro podrobnější informace o práci Flanela doporučuji využít odkazy na konci článku.

Zde je schéma interakce mezi pluginem Containerd CRI a pluginy CNI:

Jak můžete vidět výše, kubelet volá plugin Containerd CRI, aby vytvořil modul, který pak volá plugin CNI pro konfiguraci sítě modulu. Zásuvný modul CNI poskytovatele sítě přitom volá další zásuvné moduly CNI pro konfiguraci různých aspektů sítě.

Interakce mezi pluginy CNI

Existují různé CNI pluginy, jejichž úkolem je pomoci nastavit síťovou komunikaci mezi kontejnery na hostiteli. Tento článek se bude zabývat třemi z nich.

CNI plugin Flannel

Při použití Flannel jako poskytovatele sítě volá komponenta Containerd CRI CNI plugin Flannelpomocí konfiguračního souboru 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
      }
    }
  ]
}

Plugin Flannel CNI funguje ve spojení s Flanneld. Během spouštění Flanneld načte podCIDR a další podrobnosti týkající se sítě ze serveru API a uloží je do souboru /run/flannel/subnet.env.

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

Plugin Flannel CNI používá data z /run/flannel/subnet.env pro konfiguraci a volání zásuvného modulu CNI bridge.

CNI plugin Bridge

Tento plugin se volá s následující konfigurací:

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

Při prvním volání se vytvoří Linux-můstek s «name»: «cni0», který je specifikován v konfiguraci. Poté je pro každý pod vytvořen pár veth. Jeden konec je připojen k jmennému prostoru sítě kontejneru, druhý je zahrnut v Linux-most v hostitelské síti. CNI plugin Bridge propojuje všechny hostitelské kontejnery s Linux-most v hostitelské síti.

Po dokončení nastavení páru veth zavolá zásuvný modul Bridge hostitel-lokální modul IPAM CNI. Typ zásuvného modulu IPAM lze nakonfigurovat v konfiguraci CNI, kterou zásuvný modul CRI používá k volání zásuvného modulu Flannel CNI.

Hostitelské moduly IPAM CNI

Přemostění volání CNI Host-local IPAM plugin CNI s následující konfigurací:

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

Hostitelský modul IPAM (IP Address Mspráva – správa IP adres) vrátí IP adresu kontejneru z podsítě a uloží přidělenou IP na hostiteli do adresáře uvedeného v sekci dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Tento soubor obsahuje ID kontejneru, kterému je tato IP adresa přiřazena.

Při volání místního modulu IPAM hostitele vrátí následující data:

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

Shrnutí

Kube-controller-manager přiřadí podCIDR každému uzlu. Pody každého uzlu přijímají IP adresy z adresního prostoru v přiděleném rozsahu podCIDR. Protože se podCIDR uzlů nepřekrývají, všechny pody obdrží jedinečné IP adresy.

Správce clusteru Kubernetes nakonfiguruje a nainstaluje kubelet, modul runtime kontejneru, agenta poskytovatele sítě a zkopíruje pluginy CNI do každého uzlu. Během spouštění vygeneruje agent poskytovatele sítě konfiguraci CNI. Když je modul naplánován do uzlu, kubelet zavolá plugin CRI, aby jej vytvořil. Dále, pokud je použit kontejner, modul Containerd CRI zavolá modul CNI zadaný v konfiguraci CNI pro konfiguraci sítě podu. V důsledku toho modul obdrží IP adresu.

Chvíli mi trvalo, než jsem pochopil všechny jemnosti a nuance všech těchto interakcí. Doufám, že vám tato zkušenost pomůže lépe pochopit, jak Kubernetes funguje. Pokud se v něčem mýlím, kontaktujte mě prosím na X nebo na adrese ahoj@ronaknathani.com. Neváhejte se obrátit, pokud byste chtěli prodiskutovat aspekty tohoto článku nebo cokoli jiného. Rád bych si s vámi popovídal!