🥇Kuidas pod Kuberneteses IP-aadressi saab

Märkus tõlke kohta.: see artikkel, mille on kirjutanud LinkedIn'i SRE-insener, selgitab põhjalikult Kubernetesi „sisemist maagiat“ — täpsemalt CRI, CNI ja kube-apiserveri koostööd, — mis juhtub, kui uuele pod'ile on vajalik IP-aadress.

Üks põhivajadustest Kubernetesi võrgu mudel on, et igal pod'il peab olema oma IP-aadress ja iga teine pod klastri sees peab saama temaga selle adressi kaudu ühendust võtta. On palju võrgu „pakkujaid“ (näiteks Flannel, Calico, Canal jne), mis aitavad selle võrgu mudeli rakendamisel.

Kui ma alles alustasin Kubernetesi töötamist, siis ei olnud mul päris selge, kuidas pod'id oma IP-aadreseid saavad. Isegi kui ma mõistsin, kuidas eraldi komponendid toimivad, oli nende koostöö visualiseerimine keeruline. Näiteks teadsin ma, miks on CNI pistikud vajalikud, kuid ei suutnud ette kujutada, kuidas nad justkui käivitatakse. Seetõttu otsustasin kirjutada selle artikli, et jagada teadmisi erinevate võrgu komponentide ja nende koostööst Kubernetesi klastri sees, mis võimaldavad igal pod'il saada oma unikaalse IP-aadressi.

Kubernetesis on erinevaid viise võrgusuhete korraldamiseks — sarnaselt erinevatele konteinerite käituskeskkondade (runtime) variantidele. Käesolevas publikatsioonis kasutatakse Flannel võrgu korraldamiseks klastris ja käituskeskkonnana — Containerd. Samuti lähtun ma eeldusest, et teate, kuidas konteinerite vahel võrguühendus töötab, seega vaid lühidalt käsitlen seda, ainult konteksti jaoks.

Mõned põhikontseptsioonid

Konteinerid ja võrk: lühike ülevaade

Internetis on piisavalt suurepäraseid publikatsioone, mis selgitavad, kuidas konteinerid omavahel võrgu kaudu ühenduvad. Seetõttu teen vaid üldise ülevaate peamistest mõisted ja piirdun ühe lähenemisega, mis hõlmab Linux'i silda loomist ja pakettide kapseldamist. Üksikasjad on vahele jäetud, kuna konteinerite võrgusuhete teema väärib eraldi artiklit. Allpool lisatakse linke mõningatele eriti sisulistele ja harivatele publikatsioonidele.

Konteinerid ühel hostil

Üks meetod IP-aadresside kaudu ühenduse loomise korraldamiseks konteinerite vahel, mis töötavad samal hostil, hõlmab Linux-silla loomist. Selleks luuakse Kuberneteses (ja Dockeris) virtuaalsed seadmed veth (virtuaalne ethernet). Üks ots veth-seadmest on ühendatud konteineri võrgu nimekirjaga, teine - Linux-silla hosti võrgus.

Kogu hosti konteineritel on üks veth-ots ühendatud sillaga, mille kaudu nad saavad omavahel IP-aadresside kaudu suhelda. Linux-sillal on ka IP-aadress ja see toimib sildina väljamineva (egress) liikluse jaoks pod'idest, mis on suunatud teistele sõlmedele.

Konteinerid erinevates hostides

Pakettide kapseldamine on üks meetodeid, mis võimaldab konteineritel erinevates sõlmedes omavahel IP-aadresside kaudu suhelda. Flannelis vastutab selle võimaluse eest tehnoloogia vxlan, mis "pakendab" algse paketi UDP-paketisse ja saadab selle sihtkohta.

Kuberneteses luuakse Flanneli klastris vxlan-seade ja Vastavalt täiendatakse igas sõlmes marsruutide tabelit. Iga pakett, mis on suunatud teise hosti konteinerile, läbib vxlan-seadmest ja kapseldatakse UDP-paketisse. Sihtkohas eemaldatakse sissepakendatud pakett ja suunatakse vajalikku pod'i.

Märkus: See on vaid üks viis konteinerite vahelise võrgu suhtluse korraldamiseks.

Mis on CRI?

CRI (Container Runtime Interface) on plugin, mis võimaldab kubelet'il kasutada erinevaid konteinerite täitmise keskkondi. CRI API on integreeritud erinevatesse täitmise keskkondadesse, nii et kasutajad saavad oma soovile vastava runtime'i valida.

Mis on CNI?

CNI projekt on spetsifikatsiooni universaalse võrgu lahenduse loomiseks Linuxi konteineritele. Lisaks sisaldab see pluginad, mis vastutavad erinevate funktsioonide eest pod'i võrgu seadistamisel. CNI plugin on käivitatav fail, mis vastab spetsifikatsioonidele (mõned pluginaid arutame allpool).

Alaahelate määramine sõlmedele pod'ide IP-aadresside määramiseks

Kuna igal klastris asuval pod'il peab olema IP-aadress, on oluline tagada, et see aadress oleks ainulaadne. See saavutatakse, määrates igale sõlmele ainulaadne alajaotus, millest määratakse pod'idele IP-aadresse sellel sõlmel.

Sõlme IPAM kontrollija

Kui nodeipam edastatakse lipuflagingu parameetrina --controllers kube-controller-manager'i, ta jagab igale sõlmele eraldi alamvõrgu (podCIDR) klastrite CIDR-st (st IP-aadresside vahemik klastrite jaoks). Kuna need podCIDR'id ei katke, on võimalik igale pod'ile määrata ainulaadne IP-aadress.

Kubernetes sõlmale määratakse podCIDR selle algse registreerimise ajal klastrisse. Sõlmede podCIDR'i muutmiseks tuleb need deregistreerida ja siis uuesti registreerida, vahepeal muudatustega Kubernetes'i juhtkihi konfigureerimises. Sõlme podCIDR'i saab välja tuua järgmise käsuga:

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

Kubelet, konteineri käivituskeskkond ja CNI pluginad: kuidas see kõik töötab

Pod'i planeerimine sõlmele on seotud paljude ettevalmistavate toimingute täitmisega. Selles osas keskendun ainult nendele, mis on otseselt seotud pod'i võrgu seadistamisega.

Pod'i planeerimine mõne sõlme käivitab järgmise sündmuste ahela:

Abi: Containerd CRI pluginite arhitektuur.

Konteinerite käivituskeskkonna ja CNI pluginite koostoime

Igal võrgu pakkujal on oma CNI plugin. Konteineri käivituskeskkond käivitab selle pod'i võrguelementide seadistamiseks käivitamise ajal. Containerd puhul vastutab CNI plugina käivitamise eest plugin Containerd CRI.

Igal pakkujal on ka oma agent. See installitakse kõikidele Kubernetes'i sõlmedele ja vastutab pod'ide võrgu seadistamise eest. See agent tuleb kas koos CNI konfiguraatoriga või loob selle ise sõlmes. Konfiguratsioon aitab CRI plugin'il määrata, millist CNI plugina kutsuda.

CNI konfiguratsiooni asukohta saab seadistada; vaikimisi asub see /etc/cni/net.d/<config-file>. Klastri administraatorid vastutavad ka CNI pluginite installimise eest igale klastrisõlmele. Nende asukohta saab samuti kohandada; vaikimisi kaust on /opt/cni/bin.

Kuna kasutame containerd, saame CNI konfiguratsiooni ja binaaride teed määrata jaotises [plugins."io.containerd.grpc.v1.cri".cni] ja containerd konfiguratsioonifailis.

Kuna kasutame Flannel'i võrgu pakkujana, räägime nüüd veidi selle seadistamisest:

Flanneld (Flannel'i deemon) installitakse tavaliselt klastrisse DaemonSet'i kujul koos install-cni vaikimisi init-konteineriga.
Install-cni loo CNI konfiguratsioonifail (/etc/cni/net.d/10-flannel.conflist) igal sõlmel.
Flanneld loob vxlan seadet, tõmbab võrgu metaandmeid API serverist ning jälgib pod'de uuendusi. Nende loomise käigus jagab ta marsreid kogu klastri ulatuses.
Need marsreed võimaldavad pod'del omavahel IP-aadresside kaudu suhelda.

Flanneli toimimise kohta lähemat teavet leiate artikli lõpus olevatest linkidest.

Siin on skeem Containerd CRI plugina ja CNI pluginade vahelisest interaktsioonist:

Nagu ülal nähtud, kutsub kubelet Containerd CRI plugina, et luua pod, ja seejärel kutsub CNI plugina pod'i võrgu seadistamiseks. Samal ajal kutsub võrgu pakkuja CNI plugin teisi põhitaotlusi CNI erinevate võrguelementide seadistamiseks.

CNI pluginade interaktsioon

On olemas erinevaid CNI pluginaid, mis aitavad seadistada võrgu suhtlust konteinerite vahel hostis. Selles artiklis räägitakse kolmest neist.

CNI plugin Flannel

Flanneli kasutamisel võrgu pakkujana kutsub Containerd CRI komponent CNI plugin Flannel, kasutades CNI konfiguratsioonifaili /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 töötab koos Flanneldiga. Flanneld alustades tõmbab ta podCIDR ja teised võrgu seotud detailid API serverist ning salvestab need faili /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 kasutab andmeid /run/flannel/subnet.env CNI bridge plugina seadistamiseks ja kutsumiseks.

CNI plugin Bridge

Seda pluginat kutsutakse järgmise konfiguratsiooniga:

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

Esimese kutsumise korral loob ta Linuxi silla "name": "cni0", nagu on määratud konfiguratsioonis. Seejärel luuakse iga pod'i jaoks veth paari. Üks ots on ühendatud konteineri võrgunimeala, teine ots jõuab Linuxi silla hulka hosti võrgus. CNI plugin Bridge ühendab kõik hosti konteinerid Linuxi sillaga hosti võrgus.

Pärast veth paari seadistamist kutsub Bridge plugin kohalikule hosti (host-local) CNI plugin IPAM-i. IPAM plugina tüüpi saab seadistada CNI konfiguratsioonis, mida CRI plugin kasutab Flanneli CNI plugina kutsumiseks.

Kohalikud hosti IPAM pluginad CNI

Bridge CNI kutsub kohaliku IPAM plugina CNI järgmise konfiguratsiooniga:

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

Host-local IPAM-plugin (IP Aaadress Mhaldamine — IP-aadresside haldamine) tagastab konteinerile IP-aadressi alamvõrgust ja salvestab määratud IP-aadressi hostis kaustas, mille asukoht on määratud jaotis dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Selles failis on konteineri ID, kellele on antud see IP-aadress.

Kutsudes host-local IPAM-pluginit, tagastab ta järgmised andmed:

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

Elulookirjeldus

Kube-controller-manager määrab igale sõlmele podCIDR. Iga sõlme pod’id saavad IP-aadresse määratud podCIDR-i aadressiruumi. Kuna sõlmede podCIDR-id ei kattu, siis saavad kõik pod’id unikaalsed IP-aadressid.

Kubernetes klastrihaldur seadistab ja installib kubeleti, konteinerite käivituskeskkonna, võrgu-ettevõtja agendi ja kopeerib CNI-pluginid igale sõlmele. Käivitamise ajal genereerib võrgu-ettevõtja agent CNI-konfiguratsiooni. Kui pod on planeeritud sõlmele, kutsub kubelet selle loomiseks välja CRI-plugin. Edasi, kui kasutatakse containerd-d, kutsub Containerd CRI-plugin esile CNI-plugin, mis on määratud CNI-konfiguratsioonis, et seadistada pod’i võrku. Tulemuseks on, et pod saab IP-aadressi.

Mul kulus aega, et mõista kõiki neid interaktsioone ja nüansse. Loodan, et saadud kogemus aitab ka teil paremini mõista, kuidas Kubernetes töötab. Kui leian, et olen millegi osas vale, palun võtke minuga ühendust Twitteris või aadressil hello@ronaknathani.com. Ärge kartke ühendust võtta, kui soovite arutada selle artikli aspekte või midagi muud. Ma oleksin rõõmus teiega suhelda!