Bemærk. overs.: Denne artikel, skrevet af en SRE-ingeniør fra LinkedIn, går i detaljer om den indre magi i Kubernetes - mere præcist interaktionen mellem CRI, CNI og kube-apiserver - der sker, når den næste pod skal tildeles en IP-adresse.
Et af de grundlæggende krav er, at hver pod skal have sin egen IP-adresse, og enhver anden pod i klyngen skal kunne kontakte den på den adresse. Der er mange netværks-"udbydere" (Flannel, Calico, Canal osv.), som hjælper med at implementere denne netværksmodel.
Da jeg først begyndte at arbejde med Kubernetes, var det ikke helt klart for mig, hvordan pods præcist får deres IP-adresser. Selv med en forståelse af, hvordan de enkelte komponenter fungerede, var det svært at forestille sig, at de arbejdede sammen. For eksempel vidste jeg, hvad CNI-plugins var til, men jeg anede ikke præcis, hvordan de hed. Derfor besluttede jeg at skrive denne artikel for at dele viden om de forskellige netværkskomponenter, og hvordan de arbejder sammen i en Kubernetes-klynge, som gør det muligt for hver pod at få sin egen unikke IP-adresse.
Der er forskellige måder at organisere netværk på i Kubernetes, ligesom der er forskellige runtime muligheder for containere. Denne publikation vil bruge at organisere et netværk i en klynge og som et eksekverbart miljø - . Jeg går også ud fra, at du ved, hvordan netværk mellem containere fungerer, så jeg vil lige berøre det kort, bare for kontekst.
Nogle grundlæggende begreber
Containere og netværket: et kort overblik
Der er masser af fremragende publikationer på internettet, der forklarer, hvordan containere kommunikerer med hinanden over netværket. Derfor vil jeg kun give et generelt overblik over de grundlæggende begreber og begrænse mig til én tilgang, som går ud på at skabe en Linux-bro og indkapsle pakker. Detaljer er udeladt, da selve emnet containernetværk fortjener en separat artikel. Links til nogle særligt indsigtsfulde og pædagogiske publikationer vil blive givet nedenfor.
Containere på én vært
En måde at organisere kommunikation via IP-adresser mellem containere, der kører på den samme vært, involverer at oprette en Linux-bro. Til dette formål oprettes virtuelle enheder i Kubernetes (og Docker) . Den ene ende af veth-enheden forbinder til containerens netværksnavneområde, den anden til på værtsnetværket.
Alle containere på samme vært har den ene ende af veth forbundet til en bro, hvorigennem de kan kommunikere med hinanden via IP-adresser. Linux-broen har også en IP-adresse og fungerer som en gateway for udgående trafik fra pods, der er bestemt til andre noder.
Containere på forskellige værter
Pakkeindkapsling er en metode, der tillader containere på forskellige noder at kommunikere med hinanden ved hjælp af IP-adresser. Hos Flannel er teknologien ansvarlig for denne mulighed. , som "pakker" den originale pakke til en UDP-pakke og derefter sender den til sin destination.
I en Kubernetes-klynge opretter Flannel en vxlan-enhed og opdaterer rutetabellen på hver node i overensstemmelse hermed. Hver pakke, der er bestemt til en container på en anden vært, passerer gennem vxlan-enheden og er indkapslet i en UDP-pakke. På destinationen udtrækkes den indlejrede pakke og videresendes til den ønskede pod.
Bemærk: Dette er kun én måde at organisere netværkskommunikation mellem containere på.
Hvad er CRI?
er et plugin, der tillader kubelet at bruge forskellige container runtime-miljøer. CRI API er indbygget i forskellige kørselstider, så brugere kan vælge kørselstid efter eget valg.
Hvad er CNI?
er en at organisere en universel netværksløsning til Linux-containere. Derudover omfatter det , ansvarlig for forskellige funktioner ved opsætning af et pod-netværk. CNI-plugin'et er en eksekverbar fil, der overholder specifikationen (vi vil diskutere nogle plugins nedenfor).
Tildeling af undernet til noder for tildeling af IP-adresser til pods
Da hver pod i en klynge skal have en IP-adresse, er det vigtigt at sikre, at denne adresse er unik. Dette opnås ved at tildele hver node et unikt undernet, hvorfra pods på den node derefter tildeles IP-adresser.
Node IPAM-controller
Hvornår nodeipam videregivet som en flagparameter --controllers , allokerer den et separat undernet (podCIDR) til hver node fra klyngen CIDR (dvs. rækken af IP-adresser for klyngenetværket). Da disse podCIDR'er ikke overlapper hinanden, bliver det muligt for hver pod at få tildelt en unik IP-adresse.
En Kubernetes-node tildeles en podCIDR, når den oprindeligt er registreret i klyngen. For at ændre nodernes podCIDR skal du afregistrere dem og derefter omregistrere dem, og foretage passende ændringer i Kubernetes kontrollags konfiguration ind imellem. Du kan vise podCIDR for en node ved hjælp af følgende kommando:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, container runtime og CNI plugins: hvordan det hele fungerer
Planlægning af en pod pr. node involverer en masse forberedende trin. I dette afsnit vil jeg kun fokusere på dem, der er direkte relateret til at oprette et pod-netværk.
Planlægning af en pod til en bestemt node udløser følgende kæde af hændelser:
Help: .
Interaktion mellem container runtime og CNI plugins
Hver netværksudbyder har sit eget CNI-plugin. Containerens runtime kører den for at konfigurere netværket til poden, når den starter op. I tilfælde af containerd lanceres CNI-plugin'et af plugin'et .
Desuden har hver udbyder sin egen agent. Den er installeret på alle Kubernetes noder og er ansvarlig for netværkskonfigurationen af pods. Denne agent er enten inkluderet i CNI-konfigurationen eller opretter den selvstændigt på noden. Konfigurationen hjælper CRI-plugin'et med at indstille hvilket CNI-plugin der skal kaldes.
Placeringen af CNI-konfigurationen kan tilpasses; som standard er den i /etc/cni/net.d/<config-file>. Klyngeadministratorer er også ansvarlige for at installere CNI plugins på hver klynge node. Deres placering kan også tilpasses; standard mappe - /opt/cni/bin.
Når du bruger containerd, kan stierne til plugin-konfigurationen og binære filer indstilles i sektionen [plugins.«io.containerd.grpc.v1.cri».cni] в .
Da vi bruger Flannel som vores netværksudbyder, lad os tale lidt om at konfigurere det:
- Flanneld (Flannel's daemon) er normalt installeret i en klynge som et DaemonSet med
install-cnisom . Install-cniskaber (/etc/cni/net.d/10-flannel.conflist) på hver node.- Flanneld opretter en vxlan-enhed, henter netværksmetadata fra API-serveren og overvåger pod-opdateringer. Efterhånden som de oprettes, distribuerer den ruter til alle pods i hele klyngen.
- Disse ruter gør det muligt for pods at kommunikere med hinanden via IP-adresser.
For mere detaljeret information om Flannels arbejde anbefaler jeg at bruge linkene i slutningen af artiklen.
Her er et diagram over interaktionen mellem Containerd CRI plugin og CNI plugins:
Som du kan se ovenfor, kalder kubelet Containerd CRI-plugin'et for at oprette poden, som derefter kalder CNI-plugin'et for at konfigurere pod'ens netværk. Ved at gøre det kalder netværksudbyderens CNI-plugin andre kerne-CNI-plugins for at konfigurere forskellige aspekter af netværket.
Interaktion mellem CNI-plugins
Der er forskellige CNI-plugins, hvis opgave er at hjælpe med at opsætte netværkskommunikation mellem containere på værten. Denne artikel vil diskutere tre af dem.
CNI plugin Flannel
Når du bruger Flannel som netværksudbyder, kalder Containerd CRI-komponenten ved hjælp af CNI-konfigurationsfilen /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
}
}
]
}
Flannel CNI-plugin'et fungerer sammen med Flannel. Under opstart henter Flanneld podCIDR og andre netværksrelaterede detaljer fra API-serveren og gemmer dem i en fil /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Flannel CNI-plugin'et bruger data fra /run/flannel/subnet.env for at konfigurere og kalde CNI bridge plugin.
CNI plugin Bridge
Dette plugin kaldes med følgende konfiguration:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Når den kaldes for første gang, opretter den en Linux-bro med «name»: «cni0», som er angivet i config. Derefter oprettes et veth-par for hver pod. Den ene ende af det er forbundet med containerens netværksnavneområde, den anden er inkluderet i Linux-broen på værtsnetværket. forbinder alle værtscontainere til en Linux-bro på værtsnetværket.
Efter at have afsluttet opsætningen af veth-parret, kalder Bridge-plugin'et det værtslokale IPAM CNI-plugin. IPAM-plugin-typen kan konfigureres i den CNI-konfiguration, som CRI-plugin'et bruger til at kalde Flannel CNI-plugin'et.
Værtslokale IPAM CNI-plugins
Bridge CNI opkald med følgende konfiguration:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Værtslokalt IPAM-plugin (IP Adresse Management - IP-adressehåndtering) returnerer IP-adressen for containeren fra undernettet og gemmer den tildelte IP på værten i den mappe, der er angivet i afsnittet dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Denne fil indeholder ID'et for den container, som denne IP-adresse er tildelt.
Når du kalder det værtslokale IPAM-plugin, returnerer det følgende data:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Resumé
Kube-controller-manager tildeler en podCIDR til hver node. Hver nodes pods modtager IP-adresser fra adresserummet i det tildelte podCIDR-område. Da nodernes podCIDR'er ikke overlapper hinanden, modtager alle pods unikke IP-adresser.
Kubernetes-klyngeadministratoren konfigurerer og installerer kubelet, container runtime, netværksudbyderagent og kopierer CNI-plugins til hver node. Under opstart genererer netværksudbyderens agent en CNI-konfiguration. Når en pod er planlagt til en node, kalder kubelet CRI-plugin'et for at oprette den. Dernæst, hvis containerd bruges, kalder Containerd CRI-pluginnet det CNI-plugin, der er angivet i CNI-konfigurationen, for at konfigurere pod'ens netværk. Som et resultat modtager poden en IP-adresse.
Det tog mig noget tid at forstå alle finesser og nuancer af alle disse interaktioner. Jeg håber, at denne oplevelse vil hjælpe dig med bedre at forstå, hvordan Kubernetes fungerer. Hvis jeg tager fejl i noget, så kontakt mig venligst på eller på adressen . Du er velkommen til at kontakte os, hvis du gerne vil diskutere aspekter af denne artikel eller noget andet. Jeg vil elske at chatte med dig!
RЎSЃS <P "RєRё
Containere og netværk
Hvordan virker Flannel?
CRI og CNI
PS fra oversætteren
Læs også på vores blog:
- «";
- "En illustreret guide til netværk i Kubernetes": , ;
- «'.
Kilde: www.habr.com