🥇How a pod in Kubernetes gets an IP address

Obs. overs.: denne artikkelen, skrevet av en SRE-ingeniør fra LinkedIn, gir en detaljert forklaring på den «indre magien» i Kubernetes — nærmere bestemt samspillet mellom CRI, CNI og kube-apiserver, og hva som skjer når en pod trenger å tildele seg en IP-adresse.

Et av de grunnleggende kravene til det nettverksmodellen i Kubernetes er at hver pod må ha sin egen IP-adresse, og enhver annen pod i klyngen må kunne kommunisere med den via denne adressen. Det finnes mange «leverandører» av nettverk (Flannel, Calico, Canal, osv.) som bidrar til å implementere denne nettverksmodellen.

Da jeg nettopp begynte å jobbe med Kubernetes, var jeg ikke helt klar over hvordan pod-er skaffer seg sine IP-adresser. Selv med forståelse for hvordan de enkelte komponentene fungerer, var det vanskelig å se for seg hvordan de samhandler. For eksempel, jeg visste hva CNI-pluginene var til for, men hadde ingen anelse om hvordan de faktisk blir kalt. Derfor bestemte jeg meg for å skrive denne artikkelen for å dele kunnskap om de forskjellige nettverkskomponentene og deres interaksjon i Kubernetes-klyngen som gjør det mulig for hver pod å få sin unike IP-adresse.

Det finnes forskjellige måter å organisere nettverksinteraksjon i Kubernetes — på samme måte som det er ulike alternativer for runtime-miljøer for containere. I denne publikasjonen vil Flannel bli brukt for å organisere nettverket i klyngen, mens "Containerd" vil bli brukt som kjøringsmiljø. Jeg forutsetter også at du vet hvordan nettverksinteraksjonen mellom containere fungerer, så jeg vil bare kort berøre dette, utelukkende for konteksten.Noen grunnleggende begreper

Containere og nettverk: en kort oversikt

Det finnes mange utmerkede publikasjoner på internett som forklarer hvordan containere kobles sammen over nettverket. Derfor vil jeg bare gi en generell oversikt over de grunnleggende begrepene og fokusere på én tilnærming som innebærer oppretting av en Linux-bro og inkapsulering av pakker. Detaljene utelates, siden selve temaet for nettverksinteraksjon mellom containere fortjener en egen artikkel. Jeg vil gi lenker til noen spesielt informative og lærerike publikasjoner nedenfor.

Containere på samme vert

Containere på en vert

En av metodene for å organisere kommunikasjon via IP-adresser mellom containere som kjører på samme vert, innebærer opprettelse av en Linux-bro. For dette opprettes virtuelle enheter i Kubernetes (og Docker) veth (virtuelt ethernet). Den ene enden av veth-enheten kobles til nettverksnavnet til containeren, den andre til Linux-broen i vertsnettet.

Alle containere på én vert har den ene enden av veth koblet til broen, slik at de kan kommunisere med hverandre via IP-adresser. Linux-broen har også en IP-adresse, og fungerer som gateway for utgående (egress) trafikk fra pod-er, ment for andre noder.

Containere på forskjellige verter

Pakkeinnkapsling er en av metodene som lar containere på forskjellige noder kommunisere med hverandre via IP-adresser. I Flannel er det teknologien vxlan, som "pakker" den originale pakken inn i en UDP-pakke og sender den til destinasjonen.

I Kubernetes-klyngen oppretter Flannel en vxlan-enhet og gjør nødvendige endringer i rutetabellen på hver av nodene. Hver pakke som er ment for en container på en annen vert, går gjennom vxlan-enheten og innkapsles i en UDP-pakke. På destinasjonen blir den innkapslede pakken hentet ut og videresendt til den aktuelle pod-en.

Merk: Dette er bare en av måtene å organisere nettverksinteraksjoner mellom containere.

Hva er CRI?

CRI (Container Runtime Interface) er en plugin som lar kubelet bruke forskjellige containerkjøringsmiljøer. CRI-API-et er innebygd i ulike kjøringsmiljøer, så brukerne kan velge kjøring etter eget ønske.

Hva er CNI?

CNI-prosjektet RabbitMQ. Del 1. Introduksjon. Erlang, AMQP og RPC spesifikasjonen for å organisere en generell nettverksløsning for Linux-containere. Det omfatter også plugins, som ansvarer for ulike funksjoner ved konfigurering av pod-nettverket. CNI-plugin er en kjørbar fil som overholder spesifikasjonen (noen av pluginene vil vi diskutere nedenfor).

Tildeling av delnett til noder for tildeling av IP-adresser til pod-er

Siden hver pod i klyngen må ha en IP-adresse, er det viktig å sikre at denne adressen er unik. Dette oppnås ved å tildele hver node et unikt delnett, fra hvilket pod-er på denne noden tildeles IP-adresser.

Node IPAM-kontroller

Når nodeipam sendes som en parameterflagg --controllers kube-controller-manager, han tildeler hvert noden et eget subnett (podCIDR) fra CIDR-klusteret (dvs. IP-adresseområdet for klusteret). Siden disse podCIDR-ene ikke overlapper, blir det mulig å gi hver pod en unik IP-adresse.

En Kubernetes-node tildeles podCIDR i løpet av registreringen sin i klusteret. For å endre podCIDR på nodene, må de deregistreres og så registreres på nytt, i mellomtiden må endringene gjøres i konfigurasjonen av Kubernetes-kontrolleren. Du kan hente podCIDR for noden med følgende kommando:

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

Kubelet, containerkjøring og CNI-plugins: hvordan dette fungerer

Planlegging av en pod på en node innebærer mange forberedende tiltak. I dette avsnittet vil jeg fokusere på de som er direkte relatert til nettverksinnstillingen for podden.

Planlegging av en pod til en node utløser følgende hendelseskjede:

Tips: Arkitektur for CRI-plugins Containerd.

Samarbeidet mellom containerkjøringsmiljøet og CNI-plugins

Hver nettverksleverandør har sin egen CNI-plugin. Containerkjøringen starter den for å konfigurere nettverket til podden under oppstarten. I tilfellet med containerd håndteres oppstarten av CNI-plugin av pluginen. Containerd CRI.

Hver leverandør har sin egen agent. Den installeres på alle Kubernetes-noder og er ansvarlig for nettverksinnstillingen av poddene. Denne agenten kommer enten med CNI-konfigurasjonen eller oppretter den på noden selv. Konfigurasjonen hjelper CRI-pluginen med å bestemme hvilken CNI-plugin som skal kalles.

Plasseringen av CNI-konfigurasjonen kan konfigureres; den ligger som standard i /etc/cni/net.d/<config-file>. Clusteradministratorene er også ansvarlige for å installere CNI-plugins på hver node i klusteret. Plasseringen deres kan også konfigureres; standardkatalogen er /opt/cni/bin.

Ved bruk av containerd kan stiene for konfigurasjonen og plugin-binærene settes i delen [plugins."io.containerd.grpc.v1.cri".cni] i i konfigurasjonsfilen for containerd.

Siden vi bruker Flannel som nettverksleverandør, la oss snakke litt om konfigurasjonen hans:

Flanneld (Flannel-demonen) blir vanligvis installert i klusteret som DaemonSet med install-cni som init-container.
Install-cni oppretter CNI-konfigurasjonsfilen (/etc/cni/net.d/10-flannel.conflist) på hver node.
Flanneld oppretter en vxlan-enhet, henter nettverksmetadata fra API-serveren og overvåker oppdateringer av pod-er. Når de blir opprettet, sprer den ruter for alle pod-er over hele klyngen.
Disse rutene gjør det mulig for pod-er å kommunisere med hverandre via IP-adresser.

For mer detaljert informasjon om hvordan Flannel fungerer, anbefaler jeg å bruke lenkene på slutten av artikkelen.

Her er et diagram som viser samspillet mellom Containerd CRI-plugin og CNI-plugins:

Som vist ovenfor, kaller kubelet Containerd CRI-plugin for å opprette en pod, og deretter kaller den CNI-plugin for å konfigurere nettverket til pod-en. CNI-pluginen for nettverksleverandøren kaller andre grunnleggende CNI-plugins for å konfigurere ulike aspekter av nettverket.

Samarbeidet mellom CNI-plugins

Det finnes forskjellige CNI-plugins hvis oppgave er å hjelpe til med å konfigurere nettverkskommunikasjon mellom containere på verten. Denne artikkelen vil handle om tre av dem.

CNI-plugin Flannel

Når Flannel brukes som nettverksleverandør, kaller Containerd CRI-komponenten CNI-plugin Flannel, 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
      }
    }
  ]
}

CNI-plugin Flannel fungerer sammen med Flanneld. Ved oppstart henter Flanneld podCIDR og andre nettverksrelaterte detaljer fra API-serveren og lagrer dem i filen /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 bruker data fra /run/flannel/subnet.env for å konfigurere og kalle bro (bridge) CNI-plugin.

CNI-plugin Bridge

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

Ved første kall oppretter den en Linux-bro med "name": "cni0", som spesifisert i konfigurasjonen. Deretter opprettes et par av veth for hver pod. Den ene enden kobles til nettverksnavet til containeren, mens den andre går inn i Linux-broen i vertsnettverket. CNI-plugin Bridge kobler alle vertens containere til Linux-broen i vertsnettverket.

Når konfigurasjonen av veth-parret er fullført, kaller Bridge-plugin den lokale IPAM-pluginen for verten. Type IPAM-pluginen kan konfigureres i CNI-konfigurasjonen, som CRI-pluginen bruker for å kalle CNI-plugin Flannel.

Lokale IPAM-plugins for verten

Bridge CNI kaller den lokale IPAM-pluginen for verten (host-local) med følgende konfigurasjon:

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

Host-local IPAM-plugin (IP AAddress MManagement — management of IP addresses) returns an IP address for the container from the subnet and keeps the assigned IP on the host in the directory specified in the section dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. This file contains the ID of the container assigned this IP address.

When the host-local IPAM-plugin is called, it returns the following data:

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

Sammendrag

The Kube-controller-manager allocates podCIDR to each node. Pods of each node receive IP addresses from the address space in the allocated podCIDR range. Since the podCIDRs of nodes do not overlap, all pods receive unique IP addresses.

The Kubernetes cluster administrator configures and installs kubelet, the container runtime environment, the network provider agent, and copies CNI plugins onto each node. During startup, the network provider agent generates the CNI config. When a pod is scheduled on a node, kubelet calls the CRI plugin to create it. Then, if containerd is used, the Containerd CRI plugin calls the CNI plugin specified in the CNI config to set up the pod's network. As a result, the pod receives an IP address.

It took me some time to grasp all the nuances and subtleties of these interactions. I hope the experience gained helps you better understand how Kubernetes works. If I make any mistakes, please contact me at Twitter or at hello@ronaknathani.com. Feel free to reach out if you want to discuss aspects of this article or anything else. I would be delighted to chat with you!