🥇Hoe een Kubernetes-pod een IP-adres krijgt

Opmerking. vert.: Dit artikel, geschreven door een SRE-ingenieur van LinkedIn, gaat gedetailleerd in op de innerlijke magie in Kubernetes - meer precies, de interactie van CRI, CNI en kube-apiserver - die plaatsvindt wanneer aan de volgende pod een IP-adres moet worden toegewezen.

Eén van de basisvereisten Kubernetes-netwerkmodel is dat elke pod zijn eigen IP-adres moet hebben en dat elke andere pod in het cluster op dat adres contact met hem moet kunnen opnemen. Er zijn veel netwerkaanbieders (Flannel, Calico, Canal, enz.) die dit netwerkmodel helpen implementeren.

Toen ik voor het eerst met Kubernetes begon te werken, was het mij niet helemaal duidelijk hoe pods precies aan hun IP-adressen komen. Zelfs als je wist hoe de afzonderlijke componenten functioneerden, was het moeilijk voor te stellen dat ze zouden samenwerken. Ik wist bijvoorbeeld waar CNI-plug-ins voor waren, maar ik had geen idee hoe ze precies heetten. Daarom heb ik besloten dit artikel te schrijven om kennis te delen over de verschillende netwerkcomponenten en hoe ze samenwerken in een Kubernetes-cluster, waardoor elke pod zijn eigen unieke IP-adres krijgt.

Er zijn verschillende manieren om netwerken in Kubernetes te organiseren, net zoals er verschillende runtime-opties zijn voor containers. Deze publicatie zal gebruik maken van Flanel om een netwerk in een cluster te organiseren, en als een uitvoerbare omgeving - Gecontaineriseerd. Ik ga er ook van uit dat je weet hoe netwerken tussen containers werkt, dus ik zal er even kort op ingaan, alleen voor de context.

Enkele basisconcepten

Containers en het netwerk: een kort overzicht

Er zijn tal van uitstekende publicaties op internet die uitleggen hoe containers via het netwerk met elkaar communiceren. Daarom zal ik alleen een algemeen overzicht geven van de basisconcepten en mezelf beperken tot één benadering, namelijk het maken van een Linux-bridge en het inkapselen van pakketten. Details zijn weggelaten, omdat het onderwerp containernetwerken zelf een apart artikel verdient. Hieronder vindt u links naar enkele bijzonder inzichtelijke en educatieve publicaties.

Containers op één host

Eén manier om de communicatie via IP-adressen te organiseren tussen containers die op dezelfde host draaien, is het maken van een Linux-bridge. Hiervoor worden virtuele apparaten aangemaakt in Kubernetes (en Docker) veth (virtueel ethernet). Het ene uiteinde van het veth-apparaat maakt verbinding met de netwerknaamruimte van de container, het andere uiteinde met Linux-brug op het hostnetwerk.

Bij alle containers op dezelfde host is het ene uiteinde van de container verbonden met een brug waarmee ze via IP-adressen met elkaar kunnen communiceren. De Linux-bridge heeft ook een IP-adres en fungeert als gateway voor uitgaand verkeer van de pods dat bestemd is voor andere knooppunten.

Containers op verschillende hosts

Pakketinkapseling is een methode waarmee containers op verschillende knooppunten met elkaar kunnen communiceren via IP-adressen. Bij Flannel is technologie verantwoordelijk voor deze mogelijkheid. vxlan, dat het originele pakket in een UDP-pakket "verpakt" en het vervolgens naar zijn bestemming verzendt.

In een Kubernetes-cluster maakt Flannel een vxlan-apparaat en werkt de routetabel op elk knooppunt dienovereenkomstig bij. Elk pakket dat bestemd is voor een container op een andere host gaat door het vxlan-apparaat en wordt ingekapseld in een UDP-pakket. Op de bestemming wordt het geneste pakket geëxtraheerd en doorgestuurd naar de gewenste pod.

Opmerking: dit is slechts één manier om netwerkcommunicatie tussen containers te organiseren.

Wat is CRI?

CRI (Container Runtime-interface) is een plug-in waarmee kubelet verschillende containerruntime-omgevingen kan gebruiken. De CRI API is ingebouwd in verschillende runtimes, zodat gebruikers de runtime van hun keuze kunnen kiezen.

Wat is CNI?

Project CNI vertegenwoordigen zichzelf specificatie het organiseren van een universele netwerkoplossing voor Linux-containers. Bovendien omvat het plug-ins, verantwoordelijk voor verschillende functies bij het opzetten van een pod-netwerk. De CNI-plug-in is een uitvoerbaar bestand dat voldoet aan de specificatie (we zullen hieronder enkele plug-ins bespreken).

Toewijzing van subnetten aan knooppunten voor het toewijzen van IP-adressen aan peulen

Omdat elke pod in een cluster een IP-adres moet hebben, is het belangrijk ervoor te zorgen dat dit adres uniek is. Dit wordt bereikt door aan elk knooppunt een uniek subnet toe te wijzen, van waaruit de pods op dat knooppunt vervolgens IP-adressen krijgen toegewezen.

Knooppunt IPAM-controller

Wanneer nodeipam doorgegeven als een vlagparameter --controllers kube-controller-managerwijst het een afzonderlijk subnet (podCIDR) toe aan elk knooppunt van de cluster CIDR (d.w.z. het bereik van IP-adressen voor het clusternetwerk). Omdat deze podCIDR's elkaar niet overlappen, wordt het mogelijk dat aan elke pod een uniek IP-adres wordt toegewezen.

Aan een Kubernetes-knooppunt wordt een podCIDR toegewezen wanneer het voor het eerst bij het cluster wordt geregistreerd. Als u de podCIDR van knooppunten wilt wijzigen, moet u de registratie ervan ongedaan maken en ze vervolgens opnieuw registreren, waarbij u tussendoor de nodige wijzigingen aanbrengt in de configuratie van de Kubernetes-besturingslaag. U kunt de podCIDR van een knooppunt weergeven met behulp van de volgende opdracht:

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

Kubelet, container runtime en CNI-plug-ins: hoe het allemaal werkt

Het plannen van een pod per node vergt veel voorbereidende stappen. In deze sectie zal ik me alleen concentreren op de problemen die rechtstreeks verband houden met het opzetten van een pod-netwerk.

Het plannen van een pod voor een bepaald knooppunt activeert de volgende reeks gebeurtenissen:

Help: Architectuur van Containerd CRI-plug-ins.

Interactie tussen containerruntime en CNI-plug-ins

Elke netwerkprovider heeft zijn eigen CNI-plug-in. De runtime van de container voert deze uit om het netwerk voor de pod te configureren terwijl deze opstart. In het geval van containerd wordt de CNI-plug-in gelanceerd door de plug-in Gecontaineriseerde CRI.

Bovendien heeft elke aanbieder zijn eigen agent. Het wordt geïnstalleerd op alle Kubernetes-knooppunten en is verantwoordelijk voor de netwerkconfiguratie van pods. Deze agent is opgenomen in de CNI-configuratie of maakt deze onafhankelijk op het knooppunt. De configuratie helpt de CRI-plug-in bij het instellen welke CNI-plug-in moet worden aangeroepen.

De locatie van de CNI-configuratie kan worden aangepast; standaard is het binnen /etc/cni/net.d/<config-file>. Clusterbeheerders zijn ook verantwoordelijk voor het installeren van CNI-plug-ins op elk clusterknooppunt. Hun locatie is ook aanpasbaar; standaardmap - /opt/cni/bin.

Bij gebruik van containerd kunnen de paden voor de plug-inconfiguratie en binaire bestanden in de sectie worden ingesteld [plugins.«io.containerd.grpc.v1.cri».cni] в gecontainerd configuratiebestand.

Omdat we Flanel als onze netwerkprovider gebruiken, laten we het even hebben over het instellen ervan:

Flanneld (Flannel's daemon) wordt meestal in een cluster geïnstalleerd als een DaemonSet met install-cni als init-container.
Install-cni creëert CNI-configuratiebestand (/etc/cni/net.d/10-flannel.conflist) op elk knooppunt.
Flanneld maakt een vxlan-apparaat, haalt netwerkmetagegevens op van de API-server en bewaakt pod-updates. Terwijl ze worden gemaakt, distribueert het routes naar alle pods in het hele cluster.
Via deze routes kunnen pods met elkaar communiceren via IP-adressen.

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

Hier is een diagram van de interactie tussen de Containerd CRI-plug-in en de CNI-plug-ins:

Zoals je hierboven kunt zien, roept de kubelet de Containerd CRI-plug-in aan om de pod te maken, die vervolgens de CNI-plug-in aanroept om het netwerk van de pod te configureren. Daarbij roept de CNI-plug-in van de netwerkprovider andere kern-CNI-plug-ins aan om verschillende aspecten van het netwerk te configureren.

Interactie tussen CNI-plug-ins

Er zijn verschillende CNI-plug-ins die tot taak hebben netwerkcommunicatie tussen containers op de host op te zetten. In dit artikel worden er drie besproken.

CNI-plug-in Flanel

Bij gebruik van Flanel als netwerkprovider roept de Containerd CRI-component aan CNI-plug-in Flanelmet behulp 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 Flannel CNI-plug-in werkt in combinatie met Flanneld. Tijdens het opstarten haalt Flanneld podCIDR en andere netwerkgerelateerde details 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 Flannel CNI-plug-in gebruikt gegevens van /run/flannel/subnet.env om de CNI-bridge-plug-in te configureren en aan te roepen.

CNI-plug-in Bridge

Deze plug-in 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"
  }
}

Wanneer het voor de eerste keer wordt aangeroepen, wordt er een Linux-brug gemaakt met «name»: «cni0», wat wordt aangegeven in de config. Vervolgens wordt voor elke pod een veth-paar gemaakt. Het ene uiteinde ervan is verbonden met de netwerknaamruimte van de container, het andere is opgenomen in de Linux-bridge op het hostnetwerk. CNI-plug-in Bridge verbindt alle hostcontainers met een Linux-bridge op het hostnetwerk.

Nadat het veth-paar is ingesteld, roept de Bridge-plug-in de host-lokale IPAM CNI-plug-in aan. Het type IPAM-plug-in kan worden geconfigureerd in de CNI-configuratie die de CRI-plug-in gebruikt om de Flannel CNI-plug-in aan te roepen.

Host-lokale IPAM CNI-plug-ins

CNI-oproepen overbruggen host-lokale IPAM-plug-in CNI met de volgende configuratie:

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

Host-lokale IPAM-plug-in (IP Adres Mbeheer - IP-adresbeheer) retourneert het IP-adres voor de container uit het subnet en slaat het toegewezen IP-adres op de host op in de map die is opgegeven in de sectie dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Dit bestand bevat de ID van de container waaraan dit IP-adres is toegewezen.

Bij het aanroepen van de host-local IPAM-plug-in worden de volgende gegevens geretourneerd:

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

Beknopt

Kube-controller-manager wijst een podCIDR toe aan elk knooppunt. De peulen van elk knooppunt ontvangen IP-adressen uit de adresruimte in het toegewezen podCIDR-bereik. Omdat de podCIDR's van de knooppunten elkaar niet overlappen, ontvangen alle pods unieke IP-adressen.

De Kubernetes-clusterbeheerder configureert en installeert de kubelet, containerruntime, netwerkprovideragent en kopieert de CNI-plug-ins naar elk knooppunt. Tijdens het opstarten genereert de netwerkprovideragent een CNI-configuratie. Wanneer een pod op een knooppunt is gepland, roept de kubelet de CRI-plug-in aan om deze te maken. Als containerd wordt gebruikt, roept de Containerd CRI-plug-in vervolgens de CNI-plug-in aan die is opgegeven in de CNI-configuratie om het netwerk van de pod te configureren. Als gevolg hiervan ontvangt de pod een IP-adres.

Het kostte me enige tijd om alle subtiliteiten en nuances van al deze interacties te begrijpen. Ik hoop dat deze ervaring je zal helpen beter te begrijpen hoe Kubernetes werkt. Als ik het ergens mis mee heb, neem dan contact met mij op via Twitter of op het adres [e-mail beveiligd]. Neem gerust contact met ons op als u aspecten van dit artikel of iets anders wilt bespreken. Ik zou graag met je willen chatten!

Hoe krijgt een Kubernetes-pod een IP-adres?