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ů 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 organizovat síť v clusteru a jako spustitelné prostředí - . 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 je spousta vynikajících publikací, které vysvětlují, jak mezi sebou kontejnery komunikují po síti. Uvedu proto pouze obecný přehled základních pojmů a omezím se na jeden přístup, který zahrnuje vytvoření linuxového mostu a zapouzdření balíčků. Podrobnosti jsou vynechány, protože samotné téma kontejnerových sítí si zaslouží samostatný článek. Níže budou uvedeny odkazy na některé zvláště poučné a vzdělávací publikace.
Kontejnery na jednom hostiteli
Jedním ze způsobů, jak organizovat komunikaci prostřednictvím IP adres mezi kontejnery běžícími na stejném hostiteli, je vytvoření linuxového mostu. Za tímto účelem jsou virtuální zařízení vytvořena v Kubernetes (a Docker) . Jeden konec zařízení veth se připojuje k síťovému jmennému prostoru kontejneru, druhý k na hostitelské síti.
Všechny kontejnery na stejném hostiteli mají jeden konec veth připojený k mostu, přes který mohou mezi sebou komunikovat přes IP adresy. Linuxový most má také IP adresu a funguje jako brána pro odchozí provoz z modulů 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. , 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?
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?
je a organizovat univerzální síťové řešení pro kontejnery Linux. Kromě toho zahrnuje , 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 , 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: .
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 .
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] в .
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-cnijak . Install-cnivytváří (/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 pomocí 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í vytvoří linuxový most s «name»: «cni0», který je uveden v konfiguraci. Potom se pro každý lusk vytvoří veth pár. Jeden její konec je připojen k síťovému jmennému prostoru kontejneru, druhý je součástí linuxového mostu v hostitelské síti. připojí všechny hostitelské kontejnery k linuxovému mostu 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 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 nebo na adrese . 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!
reference
Kontejnery a síť
Jak Flanel funguje?
CRI a CNI
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- "Ilustrovaný průvodce sítí v Kubernetes": , ;
- «".
Zdroj: www.habr.com