Merk. overs.: Denne artikkelen, skrevet av en SRE-ingeniør fra LinkedIn, går i detalj om den indre magien i Kubernetes – mer presist, interaksjonen mellom CRI, CNI og kube-apiserver – som skjer når neste pod må tildeles en IP-adresse.
Et av de grunnleggende kravene er at hver pod må ha sin egen IP-adresse og enhver annen pod i klyngen må kunne kontakte den på den adressen. Det er mange "nettverksleverandører" (Flannel, Calico, Canal, etc.) som hjelper til med å implementere denne nettverksmodellen.
Da jeg først begynte å jobbe med Kubernetes, var det ikke helt klart for meg hvordan akkurat pods får IP-adressene sine. Selv med en forståelse av hvordan de enkelte komponentene fungerte, var det vanskelig å se for seg at de skulle virke sammen. For eksempel visste jeg hva CNI-plugins var for, men jeg hadde ingen anelse om nøyaktig hvordan de ble kalt. Derfor bestemte jeg meg for å skrive denne artikkelen for å dele kunnskap om de ulike nettverkskomponentene og hvordan de fungerer sammen i en Kubernetes-klynge, som lar hver pod få sin egen unike IP-adresse.
Det er forskjellige måter å organisere nettverk på i Kubernetes, akkurat som det er forskjellige kjøretidsalternativer for containere. Denne publikasjonen vil bruke å organisere et nettverk i en klynge, og som et kjørbart miljø - . Jeg antar også at du vet hvordan nettverk mellom containere fungerer, så jeg skal bare berøre det kort, bare for kontekst.
Noen grunnleggende konsepter
Beholdere og nettverket: en kort oversikt
Det er mange utmerkede publikasjoner på Internett som forklarer hvordan containere kommuniserer med hverandre over nettverket. Derfor vil jeg bare gi en generell oversikt over de grunnleggende konseptene og begrense meg til én tilnærming, som innebærer å lage en Linux-bro og innkapsle pakker. Detaljer er utelatt, siden selve emnet containernettverk fortjener en egen artikkel. Lenker til noen spesielt innsiktsfulle og pedagogiske publikasjoner vil bli gitt nedenfor.
Containere på én vert
En måte å organisere kommunikasjon via IP-adresser mellom containere som kjører på samme vert innebærer å lage en Linux-bro. For dette formålet opprettes virtuelle enheter i Kubernetes (og Docker) . Den ene enden av veth-enheten kobles til containerens nettverksnavneområde, den andre til på vertsnettverket.
Alle containere på samme vert har den ene enden av veth koblet til en bro der de kan kommunisere med hverandre via IP-adresser. Linux-broen har også en IP-adresse og fungerer som en gateway for utgående trafikk fra podene som er bestemt til andre noder.
Containere på forskjellige verter
Pakkeinnkapsling er en metode som lar beholdere på forskjellige noder kommunisere med hverandre ved hjelp av IP-adresser. Hos Flannel er teknologien ansvarlig for denne muligheten. , som "pakker" den originale pakken inn i en UDP-pakke og deretter sender den til destinasjonen.
I en Kubernetes-klynge oppretter Flannel en vxlan-enhet og oppdaterer rutetabellen på hver node tilsvarende. Hver pakke destinert for en beholder på en annen vert passerer gjennom vxlan-enheten og er innkapslet i en UDP-pakke. På destinasjonen trekkes den nestede pakken ut og videresendes til ønsket pod.
Merk: Dette er bare én måte å organisere nettverkskommunikasjon mellom containere på.
Hva er CRI?
er en plugin som lar kubelet bruke forskjellige container-runtime-miljøer. CRI API er innebygd i ulike kjøretider, slik at brukere kan velge kjøretid etter eget valg.
Hva er CNI?
er en å organisere en universell nettverksløsning for Linux-beholdere. I tillegg inkluderer det , ansvarlig for ulike funksjoner når du setter opp et podnettverk. CNI-plugin-modulen er en kjørbar fil som samsvarer med spesifikasjonen (vi vil diskutere noen plugins nedenfor).
Tildeling av subnett til noder for å tildele IP-adresser til pods
Siden hver pod i en klynge må ha en IP-adresse, er det viktig å sørge for at denne adressen er unik. Dette oppnås ved å tilordne hver node et unikt subnett, hvorfra podene på den noden deretter blir tildelt IP-adresser.
Node IPAM-kontroller
Når nodeipam sendt som flaggparameter --controllers , allokerer den et separat undernett (podCIDR) til hver node fra klyngen CIDR (dvs. rekkevidden av IP-adresser for klyngenettverket). Siden disse podCIDR-ene ikke overlapper, blir det mulig for hver pod å bli tildelt en unik IP-adresse.
En Kubernetes-node blir tildelt en podCIDR når den først er registrert med klyngen. For å endre podCIDR for noder, må du avregistrere dem og deretter registrere dem på nytt, og gjøre passende endringer i Kubernetes kontrolllagkonfigurasjon i mellom. Du kan vise podCIDR for en node ved å bruke 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
Å planlegge en pod per node innebærer mange forberedende trinn. I denne delen vil jeg kun fokusere på de som er direkte relatert til å sette opp et podnettverk.
Planlegging av en pod til en bestemt node utløser følgende hendelseskjede:
Hjelp: .
Interaksjon mellom containerruntime og CNI-plugins
Hver nettverksleverandør har sin egen CNI-plugin. Beholderens kjøretid kjører den for å konfigurere nettverket for poden når den starter opp. Når det gjelder containerd, blir CNI-pluginen lansert av plugin-en .
Dessuten har hver leverandør sin egen agent. Den er installert på alle Kubernetes-noder og er ansvarlig for nettverkskonfigurasjonen av pods. Denne agenten er enten inkludert i CNI-konfigurasjonen eller oppretter den uavhengig på noden. Konfigurasjonen hjelper CRI-plugin-modulen med å angi hvilken CNI-plugin som skal kalles.
Plasseringen av CNI-konfigurasjonen kan tilpasses; som standard er den inne /etc/cni/net.d/<config-file>. Klyngeadministratorer er også ansvarlige for å installere CNI-plugins på hver klyngennode. Plasseringen deres kan også tilpasses; standard katalog - /opt/cni/bin.
Når du bruker containerd, kan banene for plugin-konfigurasjonen og binærfiler settes i seksjonen [plugins.«io.containerd.grpc.v1.cri».cni] в .
Siden vi bruker Flannel som nettverksleverandør, la oss snakke litt om å sette opp det:
- Flanneld (Flannels daemon) er vanligvis installert i en klynge som et DaemonSet med
install-cnisom . Install-cniskaper (/etc/cni/net.d/10-flannel.conflist) på hver node.- Flanneld oppretter en vxlan-enhet, henter nettverksmetadata fra API-serveren og overvåker podoppdateringer. Etter hvert som de opprettes, distribuerer den ruter til alle pods i hele klyngen.
- Disse rutene lar pods kommunisere med hverandre via IP-adresser.
For mer detaljert informasjon om arbeidet til Flannel, anbefaler jeg å bruke lenkene på slutten av artikkelen.
Her er et diagram over interaksjonen mellom Containerd CRI-plugin og CNI-plugin:
Som du kan se ovenfor, kaller kubelet opp Containerd CRI-plugin for å lage poden, som deretter kaller CNI-plugin for å konfigurere podens nettverk. Ved å gjøre dette kaller nettverksleverandørens CNI-plugin andre kjerne-CNI-plugins for å konfigurere ulike aspekter av nettverket.
Interaksjon mellom CNI-plugins
Det finnes ulike CNI-plugins hvis jobb er å hjelpe med å sette opp nettverkskommunikasjon mellom containere på verten. Denne artikkelen vil diskutere tre av dem.
CNI-plugin Flanell
Når du bruker Flannel som nettverksleverandør, ringer Containerd CRI-komponenten ved å bruke CNI-konfigurasjonsfilen /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-pluginen fungerer sammen med Flannel. Under oppstart henter Flanneld podCIDR og andre nettverksrelaterte detaljer fra API-serveren og lagrer 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-pluginen bruker data fra /run/flannel/subnet.env for å konfigurere og kalle CNI-bro-plugin.
CNI plugin Bridge
Denne plugin kalles med følgende konfigurasjon:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Når den kalles opp for første gang, oppretter den en Linux-bro med «name»: «cni0», som er angitt i konfigurasjonen. Deretter opprettes et veth-par for hver pod. Den ene enden av den er koblet til containerens nettverksnavneområde, den andre er inkludert i Linux-broen på vertsnettverket. kobler alle vertsbeholdere til en Linux-bro på vertsnettverket.
Etter å ha konfigurert veth-paret, kaller Bridge-pluginen den vertslokale IPAM CNI-pluginen. IPAM-plugintypen kan konfigureres i CNI-konfigurasjonen som CRI-pluginen bruker for å kalle Flannel CNI-pluginen.
Vertslokale IPAM CNI-plugins
Bridge CNI-anrop med følgende konfigurasjon:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Vertslokal IPAM-plugin (IP Adresse Management - IP-adresseadministrasjon) returnerer IP-adressen for beholderen fra subnettet og lagrer den tildelte IP-en på verten i katalogen spesifisert i delen dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Denne filen inneholder ID-en til beholderen som denne IP-adressen er tildelt.
Når du ringer den vertslokale IPAM-pluginen, returnerer den følgende data:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Oppsummering
Kube-controller-manager tildeler en podCIDR til hver node. Hver nodes poder mottar IP-adresser fra adresseområdet i det tildelte podCIDR-området. Siden nodens podCIDR-er ikke overlapper hverandre, mottar alle poder unike IP-adresser.
Kubernetes-klyngeadministratoren konfigurerer og installerer kubelet, container runtime, nettverksleverandøragenten og kopierer CNI-pluginene til hver node. Under oppstart genererer nettverksleverandøragenten en CNI-konfigurasjon. Når en pod er planlagt til en node, kaller kubelet CRI-pluginen for å lage den. Deretter, hvis containerd brukes, kaller Containerd CRI-plugin-modulen CNI-pluginen som er spesifisert i CNI-konfigurasjonen for å konfigurere podens nettverk. Som et resultat mottar poden en IP-adresse.
Det tok meg litt tid å forstå alle finessene og nyansene i alle disse interaksjonene. Jeg håper denne opplevelsen vil hjelpe deg å bedre forstå hvordan Kubernetes fungerer. Hvis jeg tar feil om noe, vennligst kontakt meg på eller på adressen . Ta gjerne kontakt hvis du ønsker å diskutere aspekter ved denne artikkelen eller noe annet. Jeg vil gjerne chatte med deg!
referanser
Containere og nettverk
Hvordan fungerer Flanell?
CRI og CNI
PS fra oversetter
Les også på bloggen vår:
- «";
- "En illustrert guide til nettverk i Kubernetes": , ;
- «'.
Kilde: www.habr.com