🥇Hoe een pod in Kubernetes een IP-adres ontvangt

Opmerking vertaler.: Dit artikel, geschreven door een SRE-engineer van LinkedIn, bespreekt in detail die 'interne magie' in Kubernetes - meer specifiek, de interactie tussen CRI, CNI en kube-apiserver - wat er gebeurt wanneer een pod een IP-adres moet toewijzen.

Een van de basisvereisten van het Kubernetes-netwerkmodel is dat elke pod zijn eigen IP-adres moet hebben en dat elke andere pod in de cluster met hem moet kunnen communiceren via dat adres. Er zijn verschillende netwerk 'providers' (Flannel, Calico, Canal, enz.) die helpen bij de implementatie van dit netwerkmodel.

Toen ik net begon met werken met Kubernetes, was het me niet helemaal duidelijk hoe pods precies hun IP-adressen kregen. Zelfs met begrip van hoe de afzonderlijke componenten werken, was het moeilijk om hun samenwerking voor te stellen. Bijvoorbeeld, ik wist waarvoor CNI-plugins nodig zijn, maar ik kon me niet voorstellen hoe ze precies worden aangeroepen. Daarom besloot ik dit artikel te schrijven om kennis te delen over de verschillende netwerkcomponenten en hun samenwerking in de Kubernetes-cluster, die elk een unieke IP-adres voor hun pod mogelijk maakt.

Er zijn verschillende manieren om netwerkcommunicatie in Kubernetes te organiseren - net zoals er verschillende uitvoeringsomgevingen (runtime) voor containers bestaan. In deze publicatie zal worden gebruikt Flannel om het netwerk in de cluster te organiseren, en als uitvoeringsomgeving - Containerd. Ik ga er ook vanuit dat je weet hoe netwerkcommunicatie tussen containers werkt, dus ik zal het slechts kort aanstippen, uitsluitend voor de context.

Enkele basisconcepten

Containers en netwerken: een korte introductie

Er zijn veel uitstekende publicaties op internet die uitleggen hoe containers met elkaar verbonden zijn via het netwerk. Daarom zal ik alleen een algemeen overzicht van de basisconcepten geven en me beperken tot één benadering die het creëren van een Linux-brug en het encapsuleren van pakketten inhoudt. De details zijn weggelaten, omdat het onderwerp van netwerkcommunicatie tussen containers een apart artikel verdient. Links naar enkele bijzonder inhoudelijke en informatieve publicaties zullen hieronder worden gegeven.

Containers op hetzelfde host

Een van de manieren om verbinding te maken via IP-adressen tussen containers die op dezelfde host draaien, is het creëren van een Linux-brug. Hiervoor worden in Kubernetes (en Docker) virtuele apparaten aangemaakt. veth (virtuele ethernet). Eén uiteinde van het veth-apparaat is verbonden met de netruimte van de container, het andere - met de Linux-brug op het netwerk van de host.

Bij alle containers op dezelfde host is één uiteinde van de veth verbonden met de brug, waardoor ze via IP-adressen met elkaar kunnen communiceren. De Linux-brug heeft ook een IP-adres en fungeert als gateway voor uitgaande (egress) verkeer vanuit pods naar andere knooppunten.

Containers op verschillende hosts

Pakketencapsulatie is een van de manieren die het containers op verschillende knooppunten mogelijk maakt om via IP-adressen met elkaar te communiceren. In Flannel wordt deze mogelijkheid geleverd door de technologie vxlan, die het oorspronkelijke pakket 'verpakt' in een UDP-pakket en het vervolgens naar de bestemming verzendt.

In een Kubernetes-cluster creëert Flannel een vxlan-apparaat en vult de routetabel op elke knoop overeenkomstig aan. Elk pakket dat bedoeld is voor een container op een andere host gaat via het vxlan-apparaat en wordt ingekapseld in een UDP-pakket. Op de bestemming wordt het ingekapselde pakket uitgepakt en naar de juiste pod doorgestuurd.

Opmerking: Dit is slechts één van de manieren om netwerkintegratie tussen containers te organiseren.

Wat is CRI?

CRI (Container Runtime Interface) is een plugin waarmee de kubelet verschillende container-runtime omgevingen kan gebruiken. De CRI-API is ingebouwd in verschillende runtime omgevingen, zodat gebruikers de runtime naar keuze kunnen selecteren.

Wat is CNI?

Het CNI-project is specificatie is bedoeld voor het creëren van een universele netwerkoplossing voor Linux-containers. Bovendien omvat het plug-ins, die verantwoordelijk zijn voor verschillende functies bij het instellen van het netwerk van de pod. Een CNI-plugin is een uitvoerbaar bestand dat voldoet aan de specificatie (sommige plugins zullen we hieronder bespreken).

Toewijzing van subnets aan knooppunten voor de toewijzing van IP-adressen aan pods

Aangezien elke pod in het cluster een IP-adres moet hebben, is het belangrijk om ervoor te zorgen dat dit adres uniek is. Dit wordt bereikt door elk knooppunt een unieke subnettoewijzing te geven, waaruit vervolgens IP-adressen aan de pods op dat knooppunt worden toegewezen.

De IPAM-controller van het knooppunt

Wanneer nodeipam wordt doorgegeven als een vlagparameter --controllers van de kube-controller-manager., het wijst elk knooppunt een afzonderlijk subnets (podCIDR) toe uit de CIDR van het cluster (d.w.z. een bereik van IP-adressen voor het cluster). Aangezien deze podCIDR's niet overlappen, is het mogelijk om aan elke pod een unieke IP-adres toe te kennen.

Aan een Kubernetes-knooppunt wordt tijdens zijn initiële registratie in het cluster een podCIDR toegewezen. Om de podCIDR van knooppunten te wijzigen, moeten ze worden afgemeld en vervolgens opnieuw geregistreerd, terwijl in de tussentijd de nodige wijzigingen in de configuratie van de Kubernetes-beheerlaag worden aangebracht. De podCIDR van een knooppunt kan worden weergegeven met de volgende opdracht:

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

Kubelet, de container-runtime en CNI-plugins: hoe dit alles werkt

De planning van een pod op een knooppunt is verbonden met het uitvoeren van veel voorbereidende acties. In dit gedeelte concentreer ik me alleen op die acties die direct verband houden met de netwerkconfiguratie van de pod.

De planning van een pod op een bepaald knooppunt start de volgende keten van gebeurtenissen:

Help: Architectuur van CRI-plugins Containerd.

Interactie tussen de container-runtime en CNI-plugins

Elke netwerkaanbieder heeft zijn eigen CNI-plugin. De container-runtime start deze om het netwerk voor de pod te configureren tijdens het opstartproces. In het geval van containerd wordt de CNI-plugin uitgevoerd door de plugin Containerd CRI.

Elke provider heeft zijn eigen agent. Deze wordt op alle Kubernetes-knooppunten geïnstalleerd en is verantwoordelijk voor de netwerkinstelling van pods. Deze agent wordt ofwel meegeleverd met de CNI-configuratie, of creëert deze zelf op het knooppunt. De configuratie helpt de CRI-plugin om te bepalen welke CNI-plugin moet worden aangeroepen.

De locatie van de CNI-configuratie kan worden ingesteld; standaard is deze te vinden in /etc/cni/net.d/<config-file>. De clusterbeheerders zijn ook verantwoordelijk voor het installeren van CNI-plugins op elk knooppunt van het cluster. Hun locatie kan ook worden ingesteld; de standaarddirectory is /opt/cni/bin.

Bij het gebruik van containerd kunnen de paden voor de configuratie en de binaire bestanden van de plugin worden ingesteld in het gedeelte [plugins."io.containerd.grpc.v1.cri".cni] in in het configuratie bestand van containerd.

Aangezien we Flannel als netwerkaanbieder gebruiken, laten we het een beetje over de configuratie ervan hebben:

Flanneld (de daemon van Flannel) wordt meestal als een DaemonSet in het cluster geïnstalleerd met install-cni als init-container.
Install-cni creëert de CNI-configuratie (/etc/cni/net.d/10-flannel.conflist) op elk knooppunt.
Flanneld creëert een vxlan apparaat, haalt netwerkmethoden op via de API-server en houdt de updates van pods in de gaten. Naarmate ze worden aangemaakt, verspreidt het routes voor alle pods door het hele cluster.
Deze routes stellen pods in staat om met elkaar te communiceren via IP-adressen.

Voor meer gedetailleerde informatie over Flannel raad ik aan de links aan het einde van het artikel te bekijken.

Hier is een diagram van de interactie tussen de Containerd CRI-plugin en de CNI-plugins:

Zoals hierboven te zien is, roept kubelet de Containerd CRI-plugin aan om een pod te maken, en deze roept vervolgens de CNI-plugin aan voor de netwerkconfiguratie van de pod. De CNI-plugin van de netwerkprovider roept daarbij andere basis CNI-plugins aan om verschillende aspecten van het netwerk in te stellen.

Interactie tussen CNI-plugins

Er zijn verschillende CNI-plugins die helpen de netwerkcommunicatie tussen containers op de host in te stellen. In dit artikel zullen we het over drie van hen hebben.

CNI-plugin Flannel

Bij het gebruik van Flannel als netwerkprovider roept de Component Containerd CRI aan CNI-plugin Flannel, met gebruik van het CNI-configuratiebestand /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
      }
    }
  ]
}

De CNI-plugin Flannel werkt samen met Flanneld. Tijdens de opstart haalt Flanneld podCIDR en andere netwerkinformatie op van de API-server en slaat deze op in een bestand /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

De CNI-plugin Flannel gebruikt gegevens uit /run/flannel/subnet.env om de CNI-bridge plugin in te stellen en aan te roepen.

CNI-plugin Bridge

Deze plugin wordt aangeroepen met de volgende configuratie:

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

Bij de eerste aanroep creëert het een Linux-brug met "name": "cni0", zoals aangegeven in de configuratie. Voor elke pod wordt een paar veth aangemaakt. Het ene eind is verbonden met de netwerkruimte van de container, het andere eind gaat de Linux-brug in het netwerk van de host binnen. CNI-plugin Bridge verbindt alle containers op de host met de Linux-brug in het netwerk van de host.

Zodra de configuratie van het veth-paar is voltooid, roept de Bridge-plugin de host-local CNI-plugin IPAM aan. Het type IPAM-plugin kan worden ingesteld in de CNI-configuratie die de CRI-plugin gebruikt om de CNI-plugin Flannel aan te roepen.

Lokale host IPAM-plugins CNI

Bridge CNI roept de host-local IPAM-plugin CNI aan met de volgende configuratie:

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

Host-local IPAM-plugin (IP Aadres Mbeheer — IP-adressenbeheer) geeft een IP-adres terug voor de container uit het subnet en slaat het toegewezen IP op de host op in de directory die is opgegeven in het dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Dit bestand bevat de ID van de container die het toegewezen IP-adres heeft ontvangen.

Wanneer de host-local IPAM-plugin wordt aangeroepen, retourneert deze de volgende gegevens:

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

Samenvatting

De Kube-controller-manager kent elk knooppunt een podCIDR toe. Pods van elk knooppunt ontvangen IP-adressen uit het adresruimte in het toegewezen bereik van podCIDR. Aangezien de podCIDR's van de knooppunten niet overlappen, krijgen alle pods unieke IP-adressen.

De Kubernetes-clusterbeheerder configureert en installeert kubelet, de container-runtime, de netwerkaanbieder-agent en kopieert CNI-plugins naar elk knooppunt. Tijdens de opstart genereert de netwerkaanbieder-agent de CNI-configuratie. Wanneer een pod op een knooppunt wordt gepland, roept kubelet de CRI-plugin aan voor de creatie ervan. Vervolgens, als containerd wordt gebruikt, roept de Containerd CRI-plugin de CNI-plugin aan die in de CNI-configuratie is opgegeven voor het configureren van het netwerk van de pod. Als gevolg hiervan krijgt de pod een IP-adres.

Het kostte me enige tijd om alle subtiliteiten en nuances van deze interacties te begrijpen. Ik hoop dat de opgedane ervaring ook jou helpt om beter te begrijpen hoe Kubernetes werkt. Als ik ergens een fout maak, neem dan gerust contact met mij op via Twitter of op hello@ronaknathani.com. Aarzel niet om contact op te nemen als je aspect van dit artikel of iets anders wilt bespreken. Ik praat graag met je!