🥇Sådan får en pod i Kubernetes en IP-adresse

Bem. overs.: denne artikel, skrevet af en SRE-ingeniør fra LinkedIn, beskriver detaljeret den "interne magi" i Kubernetes — nærmere bestemt interaktionen mellem CRI, CNI og kube-apiserver — hvad der sker, når en ny pod har brug for at få tildelt en IP-adresse.

Et af de grundlæggende krav til Kubernetes-netværksmodellen er, at hver pod skal have sin egen IP-adresse, og enhver anden pod i klyngen skal have mulighed for at kommunikere med den via denne adresse. Der er mange netværks "udbydere" (Flannel, Calico, Canal osv.), der 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 får deres IP-adresser. Selv med forståelsen for, hvordan de enkelte komponenter fungerer, var det svært at forestille sig deres samlede arbejde. For eksempel vidste jeg, hvad formålet med CNI-plugins var, men jeg havde ikke en idé om, hvordan de faktisk blev kaldt. Derfor besluttede jeg at skrive denne artikel for at dele viden om de forskellige netværkskomponenter og deres samarbejde i Kubernetes-klyngen, som gør det muligt for hver pod at få sin unikke IP-adresse.

Der findes forskellige måder at organisere netværk i Kubernetes — ligesom forskellige typer runtime-miljøer for containere. I denne publikation vil Flannel blive brugt til at organisere netværket i klyngen, og som runtime-miljø vil jeg bruge Containerd. Jeg tager også udgangspunkt i, at du ved, hvordan netværksinteraktionen mellem containere fungerer, så jeg vil kun kort berøre det for at give kontekst.

Nogle grundlæggende koncepter

Containere og netværk: en kort oversigt

Der er masser af fremragende publikationer på internettet, der forklarer, hvordan containere kommunikerer med hinanden over netværket. Derfor vil jeg kun give en generel oversigt over de grundlæggende begreber og begrænse mig til én tilgang, der indebærer oprettelse af en Linux-bro og inkapsling af pakker. Detaljerne udelades, da emnet netværksinteraktion mellem containere fortjener en artikel for sig selv. Links til nogle særligt informative og lærende publikationer vil blive givet nedenfor.

Containere på samme vært

En af måderne at organisere IP-adressekommunikation mellem containere, der kører på samme vært, indebærer oprettelse af en Linux-bro. Dette gøres i Kubernetes (og Docker) ved at oprette virtuelle enheder veth (virtuel ethernet). Den ene ende af veth-enheden forbindes til containerens netværksnavnrum, den anden til Linux-broen i værtsnetværket.

Alle containere på en vært har den ene ende af veth-forbindelsen til broen, hvormed de kan kommunikere med hinanden via IP-adresser. Linux-broen har også en IP-adresse og fungerer som gateway for udgående (egress) trafik fra pods, der er rettet mod andre noder.

Containere på forskellige værter

Indkapsling af pakker er en af måderne, der tillader containere på forskellige noder at kommunikere med hinanden via IP-adresser. I Flannel er denne mulighed drevet af teknologien vxlan, som "pakker" den oprindelige pakke i en UDP-pakke og sender den til destinationen.

I Kubernetes-klyngen opretter Flannel et vxlan-enhed og opdaterer rute- -tabellen på hver af noderne. Hver pakke, der er beregnet til en container på en anden vært, passerer gennem vxlan-enheden og indkapsles i en UDP-pakke. I destinationen bliver den indkapslede pakke udtrukket og videresendt til den ønskede pod.

Bemærk: Dette er kun en metode til at organisere netværksinteraktion mellem containere.

Hvad er CRI?

CRI (Container Runtime Interface) er en plugin, der giver kubelet mulighed for at bruge forskellige container-execution-miljøer. CRI API'en er indbygget i forskellige execution-miljøer, så brugerne kan vælge runtime efter eget ønske.

Hvad er CNI?

CNI-projektet repræsenterer specifikationen for at organisere en universel netværksløsning for Linux-containere. Desuden inkluderer det plugins, som er ansvarlige for forskellige funktioner ved opsætning af pod-netværket. CNI-pluginen er en eksekverbar fil, der overholder specifikationen (nogle plugins vil vi diskutere nedenfor).

Tildeling af subnetter til noder for at tildele IP-adresser til pods

Da hver pod i klyngen 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 subnet, fra hvilket IP-adresser derefter tildeles pods på denne node.

Node IPAM-controlleren

Når nodeipam overføres som en parameter til flaget --controllers kube-controller-manager’ens, tildeler han hvert node et separat subnet (podCIDR) fra CIDR-klusteret (dvs. IP-adresseområdet for klusteret). Da disse podCIDR’er ikke overlapper, er det muligt at tildele hver pod en unik IP-adresse.

En Kubernetes-node tildeles podCIDR i det øjeblik, den først registreres i klusteret. For at ændre podCIDR for noderne skal de afregistreres og derefter registreres igen, mens ændringerne i konfigurationen af Kubernetes-kontrollaget udføres. Du kan udskrive nodens podCIDR ved hjælp af følgende kommando:

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

Kubelet, container-runtime og CNI-plugins: hvordan fungerer det hele

Planlægning af en pod på en node er forbundet med udførelsen af mange forberedende opgaver. I dette afsnit vil jeg kun fokusere på de, der er direkte relateret til konfigurationen af pod-netværket.

Planlægning af en pod på en bestemt node udløser følgende kæde af begivenheder:

Hjælp: Arkitekturen af CRI-plugins til Containerd.

Interaktionen mellem container-runtime og CNI-plugins

Hver netværksudbyder har sin egen CNI-plugin. Container-runtime kalder den for at konfigurere netværket for pod'en under dens opstart. I tilfælde af containerd håndteres opstarten af CNI-plugin'en af pluginen Containerd CRI.

Hver udbyder har desuden sin egen agent. Den installeres på alle Kubernetes-noder og er ansvarlig for netværkskonfigurationen af pods. Denne agent følger med enten CNI-konfigurationen eller opretter den selv på noden. Konfigurationen hjælper CRI-pluginen med at bestemme, hvilken CNI-plugin der skal kaldes.

Placeringen af CNI-konfigurationen kan konfigureres; som standard ligger den i /etc/cni/net.d/<config-file>. Klusteradministratorerne er også ansvarlige for installation af CNI-plugins på hver node i klusteret. Deres placering kan også konfigureres; standardmappen er /opt/cni/bin.

Ved brug af containerd kan stierne til konfigurationen og plugin-binarierne angives i sektionen [plugins."io.containerd.grpc.v1.cri".cni] i i containerds konfigurationsfil.

Da vi bruger Flannel som netværksudbyder, lad os tale lidt om dets opsætning:

Flanneld (Flannels dæmon) installeres normalt i klusteret som en DaemonSet med install-cni som init-container.
Install-cni opretter CNI-konfigurationsfilen (/etc/cni/net.d/10-flannel.conflist) på hver node.
Flanneld opretter en vxlan-enhed, henter netværksmetadata fra API-serveren og holder øje med opdateringer til pods. Når de oprettes, distribuerer det 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 funktioner anbefaler jeg at benytte linksene i slutningen af artiklen.

Her er diagrammet for interaktionen mellem Containerd CRI-plugin og CNI-plugins:

Som vist ovenfor kalder kubelet Containerd CRI-plugin for at oprette en pod, som derefter kalder CNI-plugin for at konfigurere netværket til pod'en. Under dette kalder netværksudbyderens CNI-plugin andre grundlæggende CNI-plugins for at konfigurere forskellige aspekter af netværket.

Interaktionen mellem CNI-plugins

Der er forskellige CNI-plugins, hvis opgave er at hjælpe med at konfigurere netværksinteraktionen mellem containere på værten. Denne artikel vil fokusere på tre af dem.

CNI-plugin Flannel

Når Flannel bruges som netværksudbyder, kalder Containerd CRI-komponenten CNI-plugin Flannel, ved hjælp af konfigurationsfilen 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 arbejder sammen med Flanneld. 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

CNI-plugin Flannel bruger data fra /run/flannel/subnet.env til at konfigurere og kalde CNI-bro-plugin-et (bridge).

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"
  }
}

Ved første kald opretter det en Linux-bro med «name»: «cni0», som angivet i konfigurationen. Derefter oprettes et par veth for hver pod. Den ene ende tilsluttes containerens netværksnavnrum, mens den anden går ind i Linux-broen på værtsnetværket. CNI-plugin Bridge forbinder alle containere på værten til Linux-broen på værtsnetværket.

Når opsætningen af veth-paret er afsluttet, kalder Bridge-pluginet den lokale host (host-local) CNI-plugin IPAM. Typen af IPAM-pluginet kan konfigureres i CNI-konfigurationen, som CRI-pluginet bruger til at kalde CNI-pluginet Flannel.

Lokale host IPAM-plugins CNI

Bridge CNI kalder den host-lokale IPAM-plugin CNI med følgende konfiguration:

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

Host-local IPAM-plugin (IP Aadresse Mhåndtering — administration af IP-adresser) returnerer IP-adressen til containeren fra subnettet og gemmer den tildelte IP på værten i den angivne mappe i afsnittet dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Denne fil indeholder ID’en på containeren, som denne IP-adresse er tildelt.

Når host-local IPAM-plugin’en kaldes, returnerer den følgende data:

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

CV

Kube-controller-manager tildeler hvert knude et podCIDR. Pods på hver knude får IP-adresser fra adresserumet i det tildelte podCIDR-interval. Da podCIDR’erne for knuderne ikke overlapper, får alle pods unikke IP-adresser.

Kubernetes-klyngeadministratoren konfigurerer og installerede kubelet, container runtime-miljøet, netværksudbyder-agenten og kopierer CNI-plugins til hver knude. Under opstart genererer netværksudbyder-agenten CNI-konfigurationen. Når en pod er planlagt på en knude, kalder kubelet CRI-plugin’en for dens oprettelse. Derefter, hvis containerd bruges, kalder Containerd CRI-plugin’et den CNI-plugin, der er angivet i CNI-konfigurationen, for at konfigurere netværket for pod’en. Som et resultat får pod’en en IP-adresse.

Det tog mig noget tid at forstå alle detaljerne og nuancerne i disse interaktioner. Jeg håber, at den erfaring, jeg har fået, også hjælper dig med bedre at forstå, hvordan Kubernetes fungerer. Hvis jeg tager fejl et sted, så kontakt mig venligst på Twitter eller via hello@ronaknathani.com. Tøv ikke med at kontakte mig, hvis du ønsker at diskutere aspekter af denne artikel eller noget andet. Jeg vil med glæde tale med dig!