🥇Hur en pod i Kubernetes får en IP-adress

Obs. övers.: Den här artikeln, skriven av en SRE-ingenjör från LinkedIn, beskriver i detalj den "inre magin" i Kubernetes – närmare bestämt interaktionen mellan CRI, CNI och kube-apiserver – och vad som sker när en pod behöver tilldelas en IP-adress.

Ett av de grundläggande kraven för det nätverksmodell Kubernetes är att varje pod måste ha sin egen IP-adress och alla andra poddar i klustret ska kunna kommunicera med den via denna adress. Det finns många nätverks "leverantörer" (Flannel, Calico, Canal, etc.) som hjälper till att implementera denna nätverksmodell.

När jag först började arbeta med Kubernetes var jag inte helt klart över hur poddar fick sina IP-adresser. Även med förståelse för hur de enskilda komponenterna fungerar var det svårt att föreställa sig deras samarbete. Jag visste till exempel varför CNI-plugins behövs, men jag hade ingen aning om hur de faktiskt anropas. Därför bestämde jag mig för att skriva denna artikel för att dela med mig av kunskap om de olika nätverkskomponenterna och deras samarbete i Kubernetes-klustret, vilket möjliggör att varje pod får sin unika IP-adress.

Det finns olika sätt att organisera nätverkskommunikation i Kubernetes – liknande de olika typer av runtime för containrar. I denna publikation kommer jag att använda Flannel för att organisera nätverket i klustret, samt använda Containerd. Jag utgår också från att du vet hur nätverkskommunikationen mellan containrar fungerar, så jag kommer endast att kort beröra det, uteslutande för kontextens skull.

Några grundläggande begrepp

Containrar och nätverk: en kort översikt

Det finns flera utmärkta publikationer på internet som förklarar hur containrar kommunicerar med varandra genom nätverket. Därför kommer jag att ge en allmän översikt av de grundläggande begreppen och begränsa mig till en metod som innebär att skapa en Linux-brygga och kapsla in paket. Detaljer har uteslutits eftersom själva ämnet för nätverksinteraktion mellan containrar förtjänar en egen artikel. Länkar till några särskilt informativa och lärorika publikationer kommer att ges nedan.

Containrar på samma värd

Ett sätt att organisera IP-adresserad kommunikation mellan containrar som körs på samma värd är att skapa en Linux-bro. För detta skapas virtuella enheter i Kubernetes (och Docker) veth (virtuell ethernet). Den ena änden av veth-enheten kopplas till containerns nätverksnamnrymd, den andra till Linux-bro i värdets nätverk.

Alla containrar på en värd har en av ändarna av veth kopplad till bron, genom vilken de kan kommunicera med varandra via IP-adresser. Linux-bron har också en IP-adress och fungerar som en gateway för utgående (egress) trafik från poddar som är avsedda för andra noder.

Containrar på olika värdar

Inkapsling av paket är ett sätt som gör att containrar på olika noder kan kommunicera med varandra via IP-adresser. I Flannel ansvarar tekniken vxlan, som "paketerar" det ursprungliga paketet i ett UDP-paket och skickar det till destinationen.

I Kubernetes-klustret skapar Flannel en vxlan-enhet och kompletterar routingtabellen på varje nod. Varje paket som är avsett för en container på en annan värd går genom vxlan-enheten och inkapslas i ett UDP-paket. Vid destinationen extraheras det inkapslade paketet och vidarebefordras till den önskade podden.

Obs: Detta är bara ett av sätten att organisera nätverksinteraktion mellan containrar.

Vad är CRI?

CRI (Container Runtime Interface) är ett plugin som tillåter kubelet att använda olika containerkörmiljöer. CRI-API är inbyggt i olika körmiljöer, så användare kan välja runtime efter eget val.

Vad är CNI?

CNI-projektet representerar specifikationen för att organisera en universell nätverkslösning för Linux-containrar. Dessutom inkluderar det plugins, som ansvarar för olika funktioner vid inställning av podnätverk. CNI-plugin är en körbar fil som uppfyller specifikationen (vissa plugins diskuterar vi nedan).

Tilldelning av delnät till noder för att tilldela IP-adresser till poddar

Eftersom varje pod i klustret måste ha en IP-adress är det viktigt att se till att denna adress är unik. Detta uppnås genom att tilldela varje nod ett unikt delnät, från vilket IP-adresser sedan tilldelas poddar på den noden.

IPAM-kontrollern för noden

När nodeipam överlämnas som en parameterflagga --controllers kube-controller-manager, tilldelar det varje nod ett separat delnät (podCIDR) från klustrets CIDR (dvs. IP-adressområden för klusternät). Eftersom dessa podCIDR:er inte överlappar varandra, blir det möjligt att tilldela varje pod en unik IP-adress.

En Kubernetes-nod får sitt podCIDR när den registreras första gången i klustret. För att ändra podCIDR på noder måste de avregistreras och sedan registreras om, med motsvarande ändringar gjorda i konfigurationen av Kubernetes styrskikt under mellanperioden. Du kan visa nodens podCIDR med hjälp av följande kommando:

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

Kubelet, container runtime-miljön och CNI-plugins: hur allt detta fungerar

Schemaläggning av en pod på en nod innebär att åtskilliga förberedande åtgärder måste vidtas. I denna sektion kommer jag att fokusera endast på de som direkt relaterar till konfigurationen av podens nätverk.

Schemaläggning av en pod på en viss nod utlöser följande kedja av händelser:

Hänvisning: Arkitekturen för CRI-plugins i Containerd.

Interaktionen mellan container runtime-miljö och CNI-plugins

Varje nätverksleverantör har sin egen CNI-plugin. Container-runtimen kör den för att konfigurera nätverket för pod’en vid dess start. I fallet med containerd är det plugin Containerd CRI.

Varje leverantör har sin egen agent. Den installeras på alla Kubernetes-noder och ansvarar för nätverkskonfigurationen av pod’ar. Denna agent levereras antingen med CNI-konfigurationen eller skapar den autonomt på noden. Konfigurationen hjälper CRI-plugin att veta vilken CNI-plugin som ska anropas.

Platsen för CNI-konfigurationen kan ställas in; som standard finns den i /etc/cni/net.d/<config-file>. Klustrets administratörer ansvarar också för att installera CNI-plugins på varje nod i klustret. Deras plats kan också ställas in; standardkatalogen är /opt/cni/bin.

Vid användning av containerd kan sökvägarna för konfiguration och plugin-binarier anges i avsnittet [plugins."io.containerd.grpc.v1.cri".cni] på containerds konfigurationsfil.

Eftersom vi använder Flannel som nätverksleverantör, låt oss prata lite om dess konfiguration:

Flanneld (Flannels demon) installeras vanligtvis i klustret som DaemonSet med install-cni som init-container.
Install-cni skapar CNI-konfigurationsfilen (/etc/cni/net.d/10-flannel.conflist) på varje nod.
Flanneld skapar en vxlan-enhet, hämtar nätverksmetadata från API-servern och övervakar uppdateringar av poddar. I takt med att de skapas sprider den rutter för alla poddar över hela klustret.
Dessa rutter gör det möjligt för poddar att kommunicera med varandra via IP-adresser.

För mer information om hur Flannel fungerar rekommenderar jag att använda länkarna i slutet av artikeln.

Här är en översikt över interaktionen mellan Containerd CRI-plugin och CNI-plugins:

Som visas ovan anropar kubelet Containerd CRI-plugin för att skapa en pod, sedan anropar den CNI-plugin för att konfigurera poddets nätverk. Samtidigt anropar nätverksleverantörens CNI-plugin andra grundläggande CNI-plugins för att konfigurera olika aspekter av nätverket.

Interaktionen mellan CNI-plugins

Det finns olika CNI-plugins vars uppgift är att hjälpa till att ställa in nätverkskommunikation mellan containrar på värden. I denna artikel kommer vi att fokusera på tre av dem.

CNI-plugin Flannel

Vid användning av Flannel som nätverksleverantör anropar Containerd CRI-komponenten CNI-plugin Flannel, med hjälp av 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
      }
    }
  ]
}

CNI-plugin Flannel fungerar tillsammans med Flanneld. Vid start hämtar Flanneld podCIDR och andra nätverksrelaterade detaljer från API-servern och sparar 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 använder data från /run/flannel/subnet.env för att konfigurera och anropa CNI-bridge-plugin.

CNI-plugin Bridge

Denna plugin anropas med följande konfiguration:

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

Vid första anropet skapar den en Linux-bro med "name": "cni0", vilket anges i konfigurationen. Sedan skapas ett par veth för varje pod. Den ena änden kopplas till nätverksnamnrymden för containern, den andra går in i Linux-bro nätverket på värden. CNI-plugin Bridge kopplar samman alla värdcontainrar till Linux-bro nätverket på värden.

När inställningen av veth-paret är klar anropar Bridge-plugin den lokala (host-local) CNI-pluginen IPAM. Typen av IPAM-plugin kan konfigureras i CNI-konfigurationen som CRI-plugin använder för att anropa CNI-pluginen Flannel.

Lokala host-IPAM-plugins CNI

Bridge CNI anropar host-local IPAM-plugin CNI med följande konfiguration:

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

Host-local IPAM-plugin (IP Aadress Mmanagement — hantering av IP-adresser) returnerar en IP-adress för containern från subnettet och sparar den allokerade IP-adressen på värden i den katalog som anges i avsnittet dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. I den här filen finns ID:t på containern som tilldelades denna IP-adress.

Vid anrop av host-local IPAM-pluginet returneras följande data:

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

Sammanfattning

Kube-controller-manager tilldelar varje nod en podCIDR. Pods på varje nod får IP-adresser från adressrymden inom det tilldelade intervallet för podCIDR. Eftersom podCIDR:er för noderna inte överlappar, får alla pods unika IP-adresser.

Kubernetes-klusteradministratören konfigurerar och installerar kubelet, container-runtime-miljö, nätverksleverantörens agent och kopierar CNI-plugins till varje nod. Vid start genererar nätverksleverantörens agent CNI-konfigurationen. När en pod planeras på en nod anropar kubelet CRI-pluginet för att skapa den. Därefter, om containerd används, anropar Containerd CRI-pluginet det CNI-plugin som anges i CNI-konfigurationen för att ställa in nätverket för podden. Som ett resultat får podden en IP-adress.

Det tog mig lite tid att förstå alla detaljer och nyanser av dessa interaktioner. Jag hoppas att den erfarenheten också hjälper dig att bättre förstå hur Kubernetes fungerar. Om jag gör något fel, tveka inte att kontakta mig på Twitter eller via hello@ronaknathani.com. Tveka inte att höra av dig om du vill diskutera aspekter av denna artikel eller något annat. Jag ser fram emot att prata med dig!