🥇Hoe 'n peul in Kubernetes 'n IP-adres kry

Let wel. vertaal.: Hierdie artikel, geskryf deur 'n SRE-ingenieur by LinkedIn, gee besonderhede oor die "innerlike magie" in Kubernetes - meer presies, die interaksie van CRI, CNI en kube-apiserver - wat gebeur wanneer die volgende pod 'n IP-adres toegeken moet word.

Een van die basiese vereistes Kubernetes-netwerkmodel is dat elke peul sy eie IP-adres moet hê en enige ander peul in die groepie moet dit by daardie adres kan kontak. Daar is baie netwerk "verskaffers" (Flannel, Calico, Canal, ens.) wat help om hierdie netwerkmodel te implementeer.

Toe ek die eerste keer met Kubernetes begin werk het, was dit nie vir my heeltemal duidelik hoe presies peule hul IP-adresse kry nie. Selfs met 'n begrip van hoe die individuele komponente funksioneer, was dit moeilik om te dink dat hulle saamwerk. Ek het byvoorbeeld geweet waarvoor CNI-inproppe was, maar het geen idee gehad hoe hulle presies genoem word nie. Daarom het ek besluit om hierdie artikel te skryf om kennis te deel oor die verskillende netwerkkomponente en hoe hulle saamwerk in 'n Kubernetes-kluster, wat elke pod toelaat om sy eie unieke IP-adres te kry.

Daar is verskeie maniere om netwerke in Kubernetes te organiseer – net soos die verskillende looptydopsies vir houers. Hierdie pos sal gebruik flanel vir netwerk in 'n groepering, en as 'n uitvoerbare omgewing - Containerd. Ek neem ook aan dat jy weet hoe netwerking tussen houers werk, so ek sal dit net kortliks aanraak, suiwer vir konteks.

Sommige basiese konsepte

Houers en netwerk in 'n oogopslag

Daar is 'n hele paar uitstekende plasings op die internet wat verduidelik hoe houers oor die netwerk met mekaar kommunikeer. Daarom sal ek slegs 'n algemene oorsig gee van die basiese konsepte en myself beperk tot een benadering, wat behels die skep van 'n Linux-brug en die inkapseling van pakkette. Besonderhede word weggelaat, aangesien die onderwerp van houernetwerke self 'n aparte artikel verdien. Skakels na sommige besonder insiggewende en insiggewende publikasies sal hieronder verskaf word.

Houers op dieselfde gasheer

Een manier om IP-adreskommunikasie te organiseer tussen houers wat op dieselfde gasheer loop, behels die skep van 'n Linux-brug. Om dit te doen, skep Kubernetes (en Docker) virtuele toestelle veth (virtuele ethernet). Die een kant van die veth toestel koppel aan die houer se netwerk naamruimte, die ander kant koppel aan Linux brug op die gasheernetwerk.

Alle houers op dieselfde gasheer het een kant van veth gekoppel aan 'n brug waardeur hulle met mekaar kan kommunikeer deur IP-adresse. Die Linux-brug het ook 'n IP-adres en dien as 'n poort vir uitgaande (uitgaande) verkeer vanaf peule wat vir ander nodusse bestem is.

Houers op verskillende gashere

Pakkie-inkapseling is een manier waarop houers op verskillende gashere met mekaar kan kommunikeer deur IP-adresse te gebruik. By Flannel is tegnologie wat dit moontlik maak. vxlan, wat die bronpakkie in 'n UDP-pakkie "verpak" en dit dan na sy bestemming stuur.

In 'n Kubernetes-kluster skep Flannel 'n vxlan-toestel en werk die roetetabel op elke nodus dienooreenkomstig op. Elke pakkie wat vir 'n houer op 'n ander gasheer bestem is, gaan deur die vxlan-toestel en is ingekapsuleer in 'n UDP-pakkie. By die bestemming word die geneste pakket herwin en na die korrekte peul herlei.

Let wel: Dit is net een van die maniere om netwerke tussen houers te organiseer.

Wat is CRI?

CRI (Container Runtime Interface) is 'n inprop wat kubelet toelaat om verskillende houerlooptye te gebruik. Die CRI API is in verskeie looptye ingebou sodat gebruikers die looptyd kan kies wat hulle wil hê.

Wat is CNI?

CNI projek is a spesifikasie om 'n universele netwerkoplossing vir Linux-houers te organiseer. Daarbenewens sluit dit in plugins, wat verantwoordelik is vir verskeie funksies wanneer 'n peul se netwerk opgestel word. 'n CNI-inprop is 'n uitvoerbare program wat aan die spesifikasie voldoen (ons sal sommige van die inproppe hieronder bespreek).

Subnetwerk-gashere om IP-adresse aan peule toe te ken

Omdat elke peul in die groep 'n IP-adres moet hê, is dit belangrik om seker te maak dat hierdie adres uniek is. Dit word bereik deur aan elke nodus 'n unieke subnet toe te ken, waaruit die peule op daardie nodus dan IP-adresse toegewys word.

Node IPAM-beheerder

Wanneer nodeipam as 'n vlagparameter deurgegee --controllers kube-beheerder-bestuurder, ken dit elke nodus 'n aparte subnet (podCIDR) toe vanaf die CIDR-groepering (d.w.s. die reeks IP-adresse vir die groepnetwerk). Aangesien hierdie podCIDR's nie oorvleuel nie, word dit moontlik vir elke peul om 'n unieke IP-adres toegeken te word.

'n Kubernetes-nodus word 'n podCIDR toegeken wanneer dit die eerste keer by die groep registreer. Om die podCIDR van nodusse te verander, moet jy hulle de-registreer en dan herregistreer, en maak gepaste veranderinge aan die Kubernetes-beheerlaagkonfigurasie tussenin. U kan die podCIDR van 'n nodus vertoon met die volgende opdrag:

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

Kubelet, houerlooptyd en CNI-inproppe: hoe dit alles werk

Om 'n peul na 'n nodus te skeduleer, behels baie voorbereidingswerk. In hierdie afdeling sal ek net fokus op diegene wat direk verband hou met die opstel van 'n peul se netwerk.

Die skedulering van 'n peul na 'n nodus veroorsaak die volgende reeks gebeure:

Hulp: Containerd CRI Plugin Argitektuur.

Interaksie tussen houerlooptyd en CNI-inproppe

Elke netwerkverskaffer het sy eie CNI-inprop. Die houerlooptyd laat dit hardloop om die netwerk vir die peul op te stel soos dit begin. In die geval van containerd, word die CNI-inprop deur die inprop geloods Containerd C.R.I..

Boonop het elke verskaffer sy eie agent. Dit is in alle Kubernetes-nodusse geïnstalleer en is verantwoordelik vir die netwerkkonfigurasie van peule. Hierdie agent kom óf saam met die CNI-opstelling saam óf skep dit op die nodus self. Die config help die CRI-inprop om te bepaal watter CNI-inprop om te bel.

Die ligging van die CNI-opstelling kan aangepas word; by verstek is dit in /etc/cni/net.d/<config-file>. Klusteradministrateurs is ook verantwoordelik vir die installering van CNI-inproppe op elke klusterknoop. Hul ligging is ook konfigureerbaar; verstek gids - /opt/cni/bin.

Wanneer containerd gebruik word, kan die paaie vir die config en plugin binaries in die afdeling gestel word [plugins.«io.containerd.grpc.v1.cri».cni] в containerd-konfigurasielêer.

Aangesien ons Flannel as ons netwerkverskaffer gebruik, kom ons praat 'n bietjie oor die opstel daarvan:

Flanneld (Flannel se daemon) word gewoonlik in 'n groep geïnstalleer as 'n DaemonSet met install-cni as init houer.
Install-cni skep CNI konfigurasie lêer (/etc/cni/net.d/10-flannel.conflist) by elke nodus.
Flanneld skep 'n vxlan-toestel, haal netwerkmetadata van die API-bediener af en monitor pod-opdaterings. Soos hulle geskep word, versprei dit roetes na alle peule regdeur die groep.
Hierdie roetes laat peule toe om met mekaar te kommunikeer deur IP-adresse.

Vir meer inligting oor die werk van Flannel, beveel ek aan om die skakels aan die einde van die artikel te gebruik.

Hier is die interaksiediagram tussen die Containerd CRI-inprop en die CNI-inprop:

Soos hierbo gesien, roep die kubelet die Containerd CRI-inprop om die peul te skep, wat reeds die CNI-inprop roep om die peul se netwerk op te stel. In hierdie geval roep die netwerkverskaffer se CNI-inprop ander kern-CNI-inproppe om verskeie aspekte van die netwerk op te stel.

Interaksie tussen CNI-inproppe

Daar is verskeie CNI-inproppe, wie se taak is om netwerkkommunikasie tussen houers op die gasheer op te stel. Hierdie artikel sal drie van hulle bespreek.

Flanell CNI-inprop

Wanneer Flannel as 'n netwerkverskaffer gebruik word, roep die Containerd CRI-komponent Flanell CNI-inprop, met behulp van die CNI-instellingslêer /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
      }
    }
  ]
}

Die Flannel CNI-inprop werk saam met Flannel. Tydens opstart haal Flanneld die podCIDR en ander netwerkverwante besonderhede van die API-bediener af en stoor dit in 'n lêer. /run/flannel/subnet.env.

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

Die Flannel CNI-inprop gebruik data van /run/flannel/subnet.env om die brug CNI-inprop op te stel en te bel.

Brug CNI-inprop

Hierdie inprop word genoem met die volgende konfigurasie:

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

Die eerste keer dat dit genoem word, skep dit 'n Linux-brug met «name»: «cni0», wat in die config. Dan word 'n vet-paar vir elke peul geskep. Die een kant koppel aan die houer se netwerknaamruimte, die ander kant koppel aan 'n Linux-brug op die gasheer se netwerk. Brug CNI-inprop koppel alle gasheerhouers aan 'n Linux-brug op die gasheernetwerk.

Wanneer die veth-paar opgestel is, roep die Bridge-inprop die gasheer-plaaslike IPAM CNI-inprop. Die IPAM-inproptipe kan gekonfigureer word in die CNI-opstelling wat die CRI-inprop gebruik om die Flannel CNI-inprop te noem.

Gasheer-plaaslike IPAM CNI-inproppe

Brug CNI oproepe gasheer-plaaslike IPAM CNI-inprop met die volgende konfigurasie:

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

Gasheer-plaaslike IPAM-inprop (IP Abostaande adres Management - IP-adresbestuur) gee die IP-adres vir die houer vanaf die subnet terug en stoor die toegekende IP op die gasheer in die gids gespesifiseer in die afdeling dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Hierdie lêer bevat die ID van die houer waaraan die gegewe IP-adres toegeken is.

Wanneer die gasheer-plaaslike IPAM-inprop gebel word, gee dit die volgende data terug:

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

Opsomming

Kube-beheerder-bestuurder ken 'n podCIDR aan elke nodus toe. Elke nodus se peule kry IP-adresse van die adresruimte in die toegekende podCIDR-reeks. Aangesien die podCIDR's van die nodusse nie oorvleuel nie, kry alle peule unieke IP-adresse.

Die Kubernetes-klusteradministrateur konfigureer en installeer die kubelet, houerlooptyd, netwerkverskafferagent, en kopieer die CNI-inproppe na elke nodus. Tydens opstart genereer die netwerkverskaffersagent 'n CNI-konfigurasie. Wanneer 'n peul na 'n nodus geskeduleer is, roep die kubelet die CRI-inprop om dit te skep. Volgende, as containerd gebruik word, roep die Containerd CRI-inprop die CNI-inprop wat in die CNI-konfigurasie gespesifiseer is om die pod se netwerk op te stel. Gevolglik kry die pod 'n IP-adres.

Dit het my tyd geneem om al die subtiliteite en nuanses van al hierdie interaksies te verstaan. Ek hoop dat die ervaring wat u opgedoen het, u sal help om beter te verstaan hoe Kubernetes werk. As ek verkeerd is oor iets, kontak my asseblief by Twitter of by die adres [e-pos beskerm]. Kontak gerus as jy aspekte van hierdie artikel of enigiets anders wil bespreek. Ek sal bly wees om met jou te gesels!

Hoe 'n peul in Kubernetes 'n IP-adres kry