🥇Jak pod v Kubernetes získává IP adresu

Pozn. přek.: Tento článek, napsaný SRE inženýrem z LinkedIn, podrobně popisuje tu ‚vnitřní magii‘ v Kubernetes — konkrétně interakci mezi CRI, CNI a kube-apiserver, co se děje, když je určitému podu přidělená IP adresa.

Jedním ze základních požadavků síťového modelu Kubernetes je, že každý pod musí mít svou vlastní IP adresu a jakýkoli jiný pod v clustru by se měl být schopný s ním spojit na této adrese. Existuje mnoho síťových ‚poskytovatelů‘ (Flannel, Calico, Canal atd.), kteří pomáhají realizovat tento síťový model.

Když jsem začínal pracovat s Kubernetes, nebylo mi úplně jasné, jak přesně podi získávají své IP adresy. I když jsem rozuměl, jak jednotlivé komponenty fungují, bylo obtížné si představit jejich spolupráci. Například jsem věděl, k čemu jsou CNI pluginy, ale nepředstavoval jsem si, jak přesně jsou volány. Proto jsem se rozhodl napsat tento článek, abych se podělil o znalosti o různých síťových komponentách a jejich spolupráci v clustru Kubernetes, které umožňují každému podu získat svou unikátní IP adresu.

Existují různé způsoby organizace síťové interakce v Kubernetes — podobně jako různé typy runtime pro kontejnery. V tomto příspěvku bude použito Flannel pro organizaci sítě v clustru, a jako runtime — Containerd. Také předpokládám, že víte, jak funguje síťová interakce mezi kontejnery, proto se jím budu věnovat pouze okrajově, výhradně pro kontext.

Některé základní pojmy

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

Na internetu je dostatek vynikajících publikací, které vysvětlují, jak se kontejnery spojují navzájem přes síť. Proto poskytnu pouze obecný přehled základních pojmů a omezím se na jeden přístup, který zahrnuje vytvoření Linuxového mostu a enkapsulaci paketů. Podrobnosti jsou vynechány, protože samotné téma síťové interakce kontejnerů si zaslouží samostatný článek. Odkazy na některé zvlášť obsahově bohaté a poučné publikace budou uvedeny níže.

Kontejnery na jednom hostiteli

Jedním z způsobů, jak organizovat komunikaci pomocí IP adres mezi kontejnery běžícími na stejném hostiteli, je vytvoření Linuxového mostu. K tomu se v Kubernetes (a Dockeru) vytvářejí virtuální zařízení. veth (virtuální ethernet). Jeden konec veth zařízení je připojen k síťovému prostorovému jménu kontejneru, druhý — k Linuxovému mostu v síti hostitele.

Všechny kontejnery na jednom hostiteli mají jeden konec veth připojen k mostu, přes který se mohou navzájem spojit pomocí IP adres. Linuxový most má také IP adresu a slouží jako brána pro odchozí (egress) provoz z podů určeného pro jiné uzly.

Kontejnery na různých hostitelích

Kapslování paketů je jedním ze způsobů, jak umožnit kontejnerům na různých uzlech se navzájem spojit pomocí IP adres. Ve Flannelu tuto možnost zajišťuje technologie vxlan, která "zabaluje" původní paket do UDP paketu a poté jej odesílá na cílové místo.

V clusteru Kubernetes Flannel vytváří zařízení vxlan a odpovídajícím způsobem doplňuje routovací tabulku na každém z uzlů. Každý paket určený pro kontejner na jiném hostiteli prochází zařízením vxlan a je kapslován do UDP paketu. Na cílovém místě je vnořený paket extrahován a směrován na požadovaný pod.

Poznámka: Toto je pouze jeden ze způsobů organizace síťové interakce mezi kontejnery.

Co je CRI?

CRI (Container Runtime Interface) je plugin, který umožňuje kubeletu používat různé běhové prostředí kontejnerů. API CRI je integrováno do různých běhových prostředí, takže uživatelé mohou vybrat runtime podle svých potřeb.

Co je CNI?

Projekt CNI představuje specifikaci za účelem vytvoření univerzálního síťového řešení pro Linux kontejnery. Kromě toho zahrnuje plugins, které se starají o různé funkce při nastavování sítě podu. CNI plugin je spustitelný soubor, který odpovídá specifikaci (některé pluginy si zde probereme).

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

Jelikož každý pod ve clustru musí mít IP adresu, je důležité zajistit, aby byla tato adresa unikátní. Toho se dosáhne tím, že každému uzlu je přidělena unikátní podsíť, ze které jsou poté podům na tomto uzlu přiřazovány IP adresy.

Kontroler IPAM uzlu

Když nodeipam je předáván jako parametr příznaku --controllers kube-controller-managerovi, každý uzel získává samostatnou podsíť (podCIDR) z CIDR clusteru (tzn. rozsahu IP adres pro cluster). Jakmile se tyto podCIDR překrývají, je možné každému podu přiřadit unikátní IP adresu.

PodCIDR je přidělen uzlu Kubernetes během jeho počáteční registrace v clusteru. Chcete-li změnit podCIDR u uzlů, je třeba je deregistrovat a následně znovu registrovat, přičemž během tohoto procesu je nutné provést odpovídající změny v konfiguraci řídicí vrstvy Kubernetes. PodCIDR uzlu lze vypsat pomocí následujícího příkazu:

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

Kubelet, prostředí pro spuštění kontejnerů a pluginy CNI: jak to všechno funguje

Plánování podu na uzel je spojeno s prováděním mnoha přípravných kroků. V této části se zaměřím pouze na ty, které se přímo týkají nastavení sítě podu.

Plánování podu na určitém uzlu spustí následující řetězec událostí:

Nápověda: Architektura pluginů CRI pro Containerd.

Interakce prostředí pro spuštění kontejnerů a pluginů CNI

Každý poskytovatel sítě má svůj vlastní plugin CNI. Runtime kontejneru jej spouští, aby konfiguroval síť pro pod během jeho spuštění. V případě containerd je spuštěním CNI pluginu pověřen plugin. Containerd CRI.

Každý poskytovatel má svého agenta. Ten je nainstalován na všechny uzly Kubernetes a zodpovídá za síťové nastavení podů. Tento agent je buď dodáván spolu s konfigurací CNI, nebo jej vytváří samostatně na uzlu. Konfigurace pomáhá CRI pluginu určit, který plugin CNI volat.

Umístění konfigurace CNI lze nakonfigurovat; ve výchozím nastavení se nachází v /etc/cni/net.d/<config-file>. Administrátoři clusteru také zodpovídají za instalaci pluginů CNI na každý uzel clusteru. Jejich umístění je také nastavitelné; výchozí adresář je /opt/cni/bin.

Při použití containerd lze cesty pro konfiguraci a binární soubory pluginu nastavit v sekci [plugins."io.containerd.grpc.v1.cri".cni] v v konfiguračním souboru containerd.

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

Flanneld (démon Flannel) se obvykle instaluje do clusteru jako DaemonSet s install-cni jako init-kontejnerem.
Install-cni vytváří konfigurační soubor CNI (/etc/cni/net.d/10-flannel.conflist) na každém uzlu.
Flanneld vytváří zařízení vxlan, získává síťové metadata z API serveru a sleduje aktualizace podů. Jakmile jsou vytvořeny, šíří trasy pro všechny pody v celém clusteru.
Tyto trasy umožňují podům vzájemné propojení pomocí IP adres.

Pro podrobnější informace o fungování Flannel doporučuji využít odkazy na konci článku.

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

Jak je patrné výše, kubelet volá plugin Containerd CRI pro vytvoření podu, a ten poté volá plugin CNI pro nastavení sítě podu. Přičemž plugin CNI poskytovatele sítě volá další základní pluginy CNI pro konfiguraci různých aspektů sítě.

Interakce mezi pluginy CNI

Existují různé pluginy CNI, jejichž úkolem je pomoci nastavit síťovou interakci mezi kontejnery na hostiteli. V tomto článku se zaměříme na tři z nich.

CNI plugin Flannel

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

CNI plugin Flannel pracuje ve spolupráci s Flanneld. Během spuštění Flanneld získává podCIDR a další související síťové detaily z API serveru a ukládá 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

CNI plugin Flannel používá data z /run/flannel/subnet.env k nastavení a vyžádání CNI pluginu mostu (bridge).

CNI plugin Bridge

Tento plugin je volán 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í vytváří Linux most s „name“: „cni0“, což je uvedeno v konfiguraci. Poté je pro každého podu vytvořen pár veth. Jeden jeho konec je připojen k prostorům názvů kontejneru, druhý vstupuje do Linux mostu v síti hostitele. CNI plugin Bridge připojuje všechny kontejnery hostitele k Linux mostu v síti hostitele.

Po dokončení nastavení páru veth plugin Bridge volá lokální pro hostitele (host-local) CNI plugin IPAM. Typ pluginu IPAM lze nastavit v konfiguraci CNI, kterou plugin CRI používá pro vyžádání pluginu CNI Flannel.

Lokální pro hostitele IPAM pluginy CNI

Bridge CNI volá 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"
  }
}

IPAM plugin host-local (IP Aadresa Mmanagement — správa IP adres) vrací IP adresu pro kontejner z podsítě a uchovává přidělenou IP na hostiteli ve složce uvedené v části dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Tento soubor obsahuje ID kontejneru, jemuž byla přiřazena tato IP adresa.

Při volání pluginu IPAM host-local vrací následující data:

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

Shrnutí

Kube-controller-manager přiděluje každému uzlu podCIDR. Pod každého uzlu získávají IP adresy z adresního prostoru v přiděleném rozsahu podCIDR. Protože podCIDR uzlů se nepřekrývají, všechny pod mají jedinečné IP adresy.

Administrátor clusteru Kubernetes konfiguruje a instaluje kubelet, prostředí pro spuštění kontejnerů, agenta síťového poskytovatele a kopíruje pluginy CNI na každý uzel. Při spuštění generuje agent síťového poskytovatele konfiguraci CNI. Když je pod naplánován na uzel, kubelet volá CRI plugin pro jeho vytvoření. Dále, pokud se používá containerd, plugin Containerd CRI volá CNI plugin uvedený v konfiguraci CNI pro nastavení sítě pod. V důsledku toho pod získává IP adresu.

Chvíli mi trvalo, než jsem pochopil všechny nuance a detaily těchto interakcí. Doufám, že získané zkušenosti pomohou i vám lépe pochopit, jak Kubernetes funguje. Pokud se mýlím, prosím, obraťte se na mě na Twitter nebo na adresu hello@ronaknathani.com. Neváhejte se ozvat, pokud byste chtěli diskutovat o aspektech tohoto článku nebo o čemkoli jiném. Rád s vámi budu komunikovat!