🥇Nola lortzen duen Kubernetes pod batek IP helbide bat

Ohar. itzul.: LinkedIn-eko SRE ingeniari batek idatzitako artikulu honek Kubernetes-en barneko magiari buruz sakontzen du - zehatzago esanda, CRI, CNI eta kube-apiserver-en elkarrekintza - hurrengo podari IP helbide bat esleitu behar zaionean gertatzen dena.

Oinarrizko eskakizunetako bat Kubernetes sare eredua hau da, pod bakoitzak bere IP helbidea izan behar duela eta klusterreko beste edozein podak helbide horretan jarri behar duela harremanetan. Sareko “hornitzaile” asko daude (Flannel, Calico, Canal, etab.) sare eredu hau ezartzen laguntzen dutenak.

Kubernetes-ekin lanean hasi nintzenean, ez nuen guztiz argi podek nola lortzen dituzten IP helbideak. Osagai indibidualak nola funtzionatzen zuten ulertuta ere, zaila zen elkarrekin lanean imajinatzea. Adibidez, banekien zertarako ziren CNI pluginak, baina ez nekien nola deitzen ziren zehazki. Hori dela eta, artikulu hau idaztea erabaki nuen sareko osagaiei buruzko ezagutza partekatzeko eta Kubernetes kluster batean elkarrekin nola funtzionatzen duten, eta horri esker, pod bakoitzak bere IP helbide bakarra lor dezake.

Kubernetes-en sareak antolatzeko modu desberdinak daude, edukiontzientzako exekuzio-aukera desberdinak dauden bezala. Argitalpen honek erabiliko du flannel sare bat kluster batean antolatzeko eta ingurune exekutagarri gisa - Ontzia. Edukiontzien arteko sareak nola funtzionatzen duen badakizula uste dut, beraz, labur-labur ukituko dut, testuingururako soilik.

Oinarrizko kontzeptu batzuk

Ontziak eta sarea: ikuspegi labur bat

Sarean edukiontziak elkarren artean nola komunikatzen diren azaltzen duten argitalpen bikain ugari daude sarean. Hori dela eta, oinarrizko kontzeptuen ikuspegi orokorra baino ez dut emango eta ikuspegi batera mugatuko naiz, hau da, Linux zubi bat sortzea eta paketeak enkapsulatzea. Xehetasunak alde batera uzten dira, edukiontzien sarearen gaiak berak aparteko artikulu bat merezi baitu. Argitalpen bereziki argigarri eta didaktiko batzuen estekak behean emango dira.

Ontziak ostalari batean

Ostalari berean exekutatzen diren edukiontzien arteko komunikazioa IP helbideen bidez antolatzeko modu bat Linux zubi bat sortzea da. Horretarako, gailu birtualak sortzen dira Kubernetes-en (eta Docker) veth (ethernet birtuala). Veth gailuaren mutur bat edukiontziaren sareko izen-espaziora konektatzen da, eta bestea Linux zubia ostalari sarean.

Ostalari bereko edukiontzi guztiek beth-aren mutur bat dute zubi batera konektatuta, IP helbideen bidez elkarren artean komunikatzeko. Linux zubiak IP helbide bat ere badu eta beste nodo batzuetara zuzendutako podetatik irteteko trafikoaren atebide gisa funtzionatzen du.

Ostalari ezberdinetan edukiontziak

Paketeen kapsulatzea nodo ezberdinetako edukiontziak elkarrekin komunikatzeko aukera ematen duen metodo bat da, IP helbideak erabiliz. Flannel-en, teknologia da aukera honen arduraduna. vxlan, jatorrizko paketea UDP pakete batean "paketatzen" duena eta gero bere helmugara bidaltzen duena.

Kubernetes kluster batean, Flannel-ek vxlan gailu bat sortzen du eta horren arabera eguneratzen du nodo bakoitzeko ibilbide-taula. Ostalari ezberdin bateko edukiontzi baterako destinatutako pakete bakoitza vxlan gailutik pasatzen da eta UDP pakete batean kapsulatzen da. Helmugan, habiaraturiko paketea ateratzen da eta nahi den ontzira birbidaltzen da.

Oharra: edukiontzien arteko sareko komunikazioa antolatzeko modu bat besterik ez da.

Zer da CRI?

CRI (Container Runtime Interface) kubelet-ek edukiontzien exekuzio-ingurune desberdinak erabiltzeko aukera ematen duen plugina da. CRI APIa hainbat exekuzio-denboratan eraikita dago, erabiltzaileek nahi duten exekuzio-denbora hauta dezaten.

Zer da CNI?

CNI proiektua da zehaztapena Linux edukiontzietarako sareko irtenbide unibertsal bat antolatzea. Horrez gain, barne hartzen du pluginak, hainbat funtzioz arduratzen den pod-sarea konfiguratzean. CNI plugin-a zehaztapenarekin bat datorren fitxategi exekutagarria da (behean plugin batzuk eztabaidatuko ditugu).

Azpisareen esleipena nodoei IP helbideak podei esleitzeko

Kluster bateko pod bakoitzak IP helbide bat izan behar duenez, garrantzitsua da helbide hori bakarra dela ziurtatzea. Hori nodo bakoitzari azpisare bakarra esleituz lortzen da, eta hortik nodo horretako podei IP helbideak esleitzen zaizkie.

Host IPAM kontrolatzailea

Noiz nodeipam bandera parametro gisa pasatu da --controllers kube-kontrolatzaile-kudeatzailea, azpisare bereizi bat (podCIDR) esleitzen dio kluster CIDRko nodo bakoitzari (hau da, kluster sarearen IP helbideen barrutia). PodCIDR hauek gainjartzen ez direnez, posible da pod bakoitzari IP helbide bakarra esleitzea.

Kubernetes nodo bati podCIDR bat esleitzen zaio hasiera batean klusterean erregistratzen denean. Nodoen podCIDRa aldatzeko, erregistroa kendu eta berriro erregistratu behar dituzu, tartean Kubernetes kontrol-geruzaren konfigurazioan aldaketa egokiak eginez. Nodo baten podCIDRa bistaratu dezakezu komando hau erabiliz:

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

Kubelet, edukiontzien exekuzioa eta CNI pluginak: nola funtzionatzen duen

Nodo bakoitzeko pod bat programatzeak prestatzeko urrats asko dakartza. Atal honetan, pod-sare bat konfiguratzearekin zerikusi zuzena dutenetan bakarrik zentratuko naiz.

Pod bat nodo jakin batera programatzeak hurrengo gertaera-katea abiarazten du:

Laguntza: Containerd CRI pluginen arkitektura.

Edukiontzien exekuzio-denboraren eta CNI pluginen arteko elkarrekintza

Sare-hornitzaile bakoitzak bere CNI plugina du. Edukiontziaren exekuzio-denborak exekutatzen du pod-aren sarea konfiguratzeko abiaraztean. Containerd-en kasuan, CNI plugina pluginak abiarazten du CRI edukiontzia.

Gainera, hornitzaile bakoitzak bere agentea du. Kubernetes nodo guztietan instalatuta dago eta poden sarearen konfigurazioaz arduratzen da. Agente hau CNI konfigurazioarekin sartzen da edo modu independentean sortzen du nodoan. Konfigurazioak CRI pluginari zein CNI plugin deitu behar duen ezartzen laguntzen du.

CNI konfigurazioaren kokapena pertsonalizatu daiteke; lehenetsita dago /etc/cni/net.d/<config-file>. Kluster-administratzaileak ere arduratzen dira CNI pluginak kluster-nodo bakoitzean instalatzeaz. Haien kokapena ere pertsonalizagarria da; direktorioa lehenetsia - /opt/cni/bin.

Containerd erabiltzean, pluginaren konfigurazioaren eta bitarren bideak ezar daitezke atalean [plugins.«io.containerd.grpc.v1.cri».cni] в containerd konfigurazio fitxategia.

Flannel gure sare-hornitzaile gisa erabiltzen ari garenez, hitz egin dezagun pixka bat konfiguratzeari buruz:

Flanneld (Flannel-en deabrua) normalean kluster batean instalatzen da DaemonSet gisa. install-cni gisa init edukiontzia.
Install-cni sortzen du CNI konfigurazio fitxategia (/etc/cni/net.d/10-flannel.conflist) nodo bakoitzean.
Flanneldek vxlan gailu bat sortzen du, sareko metadatuak API zerbitzaritik lortzen ditu eta poden eguneraketak kontrolatzen ditu. Sortzen diren heinean, ibilbideak banatzen ditu kluster osoko pod guztietara.
Ibilbide hauei esker, pods-ek elkarrekin komunikatzeko aukera dute IP helbideen bidez.

Flannel-en lanari buruzko informazio zehatzagoa lortzeko, artikuluaren amaierako estekak erabiltzea gomendatzen dut.

Hona hemen Containerd CRI pluginaren eta CNI pluginen arteko elkarrekintzaren diagrama bat:

Goian ikus dezakezun bezala, kubelet-ek Containerd CRI pluginari deitzen dio poda sortzeko, eta gero CNI pluginari deitzen dio podaren sarea konfiguratzeko. Horrela, sare-hornitzailearen CNI pluginak beste CNI plugin-ak deitzen ditu sarearen hainbat alderdi konfiguratzeko.

CNI pluginen arteko elkarrekintza

Hainbat CNI plugin daude, haien lana ostalariaren edukiontzien arteko sareko komunikazioa konfiguratzen laguntzea da. Artikulu honetan horietako hiru eztabaidatuko dira.

CNI plugina Flannel

Flannel sare-hornitzaile gisa erabiltzean, Containerd CRI osagaiak dei egiten du CNI plugina FlannelCNI konfigurazio fitxategia erabiliz /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
      }
    }
  ]
}

Flannel CNI pluginak Flanneld-ekin batera funtzionatzen du. Abiaraztean, Flanneldek podCIDR eta sarearekin lotutako beste xehetasun batzuk lortzen ditu API zerbitzaritik eta fitxategi batean gordetzen ditu. /run/flannel/subnet.env.

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

Flannel CNI pluginak eko datuak erabiltzen ditu /run/flannel/subnet.env CNI zubiaren plugina konfiguratzeko eta deitzeko.

CNI plugina Zubia

Plugin hau konfigurazio honekin deitzen da:

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

Lehen aldiz deitzen denean, Linux zubi bat sortzen du «name»: «cni0», konfigurazioan adierazten dena. Ondoren, veth bikote bat sortzen da leka bakoitzeko. Bere mutur bat edukiontziaren sareko izen-espaziora konektatuta dago, bestea ostalari sareko Linux zubian sartzen da. CNI plugina Zubia ostalariaren edukiontzi guztiak ostalari sareko Linux zubi batera konektatzen ditu.

Veth bikotea konfiguratzen amaitu ondoren, Bridge pluginak ostalari lokaleko IPAM CNI pluginari deitzen dio. IPAM plugin mota CRI pluginak Flannel CNI plugina deitzeko erabiltzen duen CNI konfigurazioan konfigura daiteke.

Ostalari lokaleko IPAM CNI pluginak

Zubia CNI deiak host-local IPAM plugin CNI konfigurazio honekin:

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

Ostalari lokaleko IPAM plugina (IP Address Mkudeaketa - IP helbidearen kudeaketa) azpisaretik edukiontziaren IP helbidea itzultzen du eta esleitutako IP ostalarian gordetzen du atalean zehaztutako direktorioan dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Fitxategi honek IP helbide hori esleitu zaion edukiontziaren IDa du.

Ostalari lokaleko IPAM pluginari deitzean, datu hauek itzultzen ditu:

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

Laburpena

Kube-controller-manager-ek podCIDR bat esleitzen dio nodo bakoitzari. Nodo bakoitzaren podek esleitutako podCIDR barrutian dagoen helbide-espaziotik IP helbideak jasotzen dituzte. Nodoen podCIDRak gainjartzen ez direnez, pod guztiek IP helbide bakarrak jasotzen dituzte.

Kubernetes klusterreko administratzaileak kubelet, edukiontzien exekuzio-denbora, sare hornitzailearen agentea konfiguratzen eta instalatzen ditu eta CNI pluginak kopiatzen ditu nodo bakoitzean. Abiaraztean, sare hornitzailearen agenteak CNI konfigurazio bat sortzen du. Pod bat nodo batean programatzen denean, kubelet-ek CRI pluginari deitzen dio hura sortzeko. Ondoren, containerd erabiltzen bada, Containerd CRI pluginak CNI konfigurazioan zehaztutako CNI pluginari deitzen dio pod-aren sarea konfiguratzeko. Ondorioz, podak IP helbide bat jasotzen du.

Denbora pixka bat behar izan nuen elkarrekintza horien guztien ñabardura eta ñabardura guztiak ulertzeko. Espero dut esperientzia honek Kubernetes-ek nola funtzionatzen duen hobeto ulertzen lagunduko dizula. Edozertan oker nago, mesedez jarri nirekin harremanetan Twitter edo helbidean [posta elektroniko bidez babestua]. Jar zaitez libreki artikulu honen edo beste edozerren inguruko alderdiak eztabaidatu nahi badituzu. Zurekin berriketan aritzea gustatuko litzaidake!

Erreferentziak

Ontziak eta sarea

Nola funtzionatzen du Flannelak?

CRI eta CNI

PS itzultzailetik

Irakurri ere gure blogean:

«Kubernetes-en sarerako Calico: aurkezpena eta esperientzia txiki bat»;
"Kubernetes-en sareak egiteko gida ilustratua": 1. eta 2. zatiak (sare-eredua, gainjarritako sareak), 3. zatia (zerbitzuak eta trafikoaren tratamendua);
«Container Networking Interface (CNI) - sareko interfazea eta estandarra Linux edukiontzietarako'.

Iturria: www.habr.com

Nola lortzen du Kubernetes pod batek IP helbidea?