Huomautus. käännös: Tämä artikkeli, jonka on kirjoittanut LinkedInin SRE-insinööri, käsittelee yksityiskohtaisesti Kubernetesin sisäistä magiaa - tarkemmin sanottuna CRI:n, CNI:n ja kube-apiserverin vuorovaikutusta -, joka tapahtuu, kun seuraavalle podille on määritettävä IP-osoite.
Yksi perusvaatimuksista on, että jokaisella podilla on oltava oma IP-osoite ja minkä tahansa muun klusterin pod on voitava ottaa siihen yhteyttä kyseisessä osoitteessa. On olemassa monia verkon "palveluntarjoajia" (Flanel, Calico, Canal jne.), jotka auttavat tämän verkkomallin toteuttamisessa.
Kun aloin työskennellä Kubernetesin kanssa, minulle ei ollut täysin selvää, kuinka podit saavat IP-osoitteensa. Vaikka ymmärsimmekin yksittäisten komponenttien toiminnan, oli vaikea kuvitella niiden toimivan yhdessä. Tiesin esimerkiksi, mitä varten CNI-laajennukset olivat, mutta minulla ei ollut aavistustakaan kuinka niitä tarkalleen kutsutaan. Siksi päätin kirjoittaa tämän artikkelin jakaakseni tietoa eri verkkokomponenteista ja siitä, kuinka ne toimivat yhdessä Kubernetes-klusterissa, jonka avulla jokainen pod voi saada oman ainutlaatuisen IP-osoitteensa.
Kubernetesissa on erilaisia tapoja järjestää verkottumista, samoin kuin säilöille on olemassa erilaisia ajonaikaisia vaihtoehtoja. Tämä julkaisu käyttää järjestää verkon klusteriin ja suoritettavana ympäristönä - . Teen myös oletuksen, että tiedät kuinka konttien välinen verkostoituminen toimii, joten käsittelen sitä vain lyhyesti kontekstin vuoksi.
Muutamia peruskäsitteitä
Kontit ja verkko: lyhyt katsaus
Internetissä on paljon erinomaisia julkaisuja, jotka selittävät, kuinka kontit kommunikoivat keskenään verkon kautta. Siksi annan vain yleiskatsauksen peruskäsitteistä ja rajoitan yhteen lähestymistapaan, joka sisältää Linux-sillan luomisen ja pakettien kapseloinnin. Yksityiskohdat jätetään pois, koska konttiverkottamisen aihe itsessään ansaitsee erillisen artikkelin. Alla on linkkejä joihinkin erityisen oivaltaviin ja opettavaisiin julkaisuihin.
Säiliöt yhdellä isännällä
Yksi tapa järjestää viestintää IP-osoitteiden kautta samalla isännällä toimivien säiliöiden välillä on Linux-sillan luominen. Tätä tarkoitusta varten Kubernetesissa (ja Dockerissa) luodaan virtuaalisia laitteita. . Veth-laitteen toinen pää muodostaa yhteyden säilön verkon nimiavaruuteen ja toinen päähän isäntäverkossa.
Kaikilla saman isäntäkoneen konteilla on yksi pää, joka on yhdistetty sillalle, jonka kautta ne voivat kommunikoida keskenään IP-osoitteiden kautta. Linux-sillalla on myös IP-osoite ja se toimii yhdyskäytävänä muille solmuille tarkoitetuista podista tulevalle liikenteelle.
Kontit eri isännillä
Pakettien kapselointi on yksi menetelmä, jonka avulla eri solmuissa olevat säiliöt voivat kommunikoida toistensa kanssa IP-osoitteiden avulla. Flannelilla teknologia on vastuussa tästä mahdollisuudesta. , joka "pakkaa" alkuperäisen paketin UDP-paketiksi ja lähettää sen sitten määränpäähänsä.
Kubernetes-klusterissa Flannel luo vxlan-laitteen ja päivittää kunkin solmun reittitaulukon vastaavasti. Jokainen paketti, joka on tarkoitettu eri isännässä olevaan säiliöön, kulkee vxlan-laitteen läpi ja on kapseloitu UDP-pakettiin. Kohteessa sisäkkäinen paketti puretaan ja välitetään haluttuun koteloon.
Huomautus: Tämä on vain yksi tapa järjestää verkkoliikennettä säilöjen välillä.
Mikä on CRI?
on laajennus, jonka avulla kubelet voi käyttää erilaisia säilön ajonaikaisia ympäristöjä. CRI API on sisäänrakennettu useisiin ajoaikoihin, joten käyttäjät voivat valita haluamansa suoritusajan.
Mikä on CNI?
on a järjestää yleisen verkkoratkaisun Linux-säiliöille. Lisäksi se sisältää , joka vastaa erilaisista toiminnoista pod-verkkoa määritettäessä. CNI-laajennus on suoritettava tiedosto, joka on määrityksen mukainen (käsittelemme joitakin laajennuksia alla).
Aliverkkojen allokointi solmuille IP-osoitteiden määrittämiseksi podille
Koska jokaisella klusterin ryhmällä on oltava IP-osoite, on tärkeää varmistaa, että tämä osoite on yksilöllinen. Tämä saavutetaan määrittämällä jokaiselle solmulle yksilöllinen aliverkko, josta kyseisen solmun podille määritetään sitten IP-osoitteet.
Solmun IPAM-ohjain
Kun nodeipam välitetty lippuparametrina --controllers , se varaa erillisen aliverkon (podCIDR) jokaiselle klusterin CIDR:n solmulle (eli klusteriverkon IP-osoitteiden alueelle). Koska nämä podCIDR:t eivät mene päällekkäin, jokaiselle podille voidaan antaa yksilöllinen IP-osoite.
Kubernetes-solmulle määritetään podCIDR, kun se rekisteröidään alun perin klusteriin. Jos haluat muuttaa solmujen podCIDR:ää, sinun on poistettava niiden rekisteröinti ja rekisteröitävä ne uudelleen tekemällä tarvittavat muutokset Kubernetes-ohjauskerroksen kokoonpanoon välillä. Voit näyttää solmun podCIDR:n käyttämällä seuraavaa komentoa:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, säiliön suoritusaika ja CNI-laajennukset: miten se kaikki toimii
Podin ajoittaminen solmukohtaisesti sisältää monia valmisteluvaiheita. Tässä osiossa keskityn vain niihin, jotka liittyvät suoraan pod-verkon perustamiseen.
Pod:n ajoittaminen tiettyyn solmuun laukaisee seuraavan tapahtumaketjun:
Ohje: .
Säilön suoritusajan ja CNI-laajennusten välinen vuorovaikutus
Jokaisella verkkopalveluntarjoajalla on oma CNI-laajennus. Säilön suoritusaika suorittaa sen konfiguroidakseen podin verkon sen käynnistyessä. Säilön tapauksessa CNI-laajennuksen käynnistää laajennus .
Lisäksi jokaisella palveluntarjoajalla on oma agenttinsa. Se on asennettu kaikkiin Kubernetes-solmuihin ja vastaa podien verkkomäärityksestä. Tämä agentti joko sisältyy CNI-konfiguraatioon tai luo sen itsenäisesti solmuun. Config auttaa CRI-laajennusta määrittämään, mitä CNI-laajennusta kutsutaan.
CNI-kokoonpanon sijainti voidaan mukauttaa; oletuksena se on sisällä /etc/cni/net.d/<config-file>. Klusterin ylläpitäjät ovat myös vastuussa CNI-laajennusten asentamisesta kuhunkin klusterin solmuun. Niiden sijainti on myös muokattavissa; oletushakemisto - /opt/cni/bin.
Säiliötä käytettäessä liitännäisen konfiguroinnin ja binäärien polut voidaan asettaa osiossa [plugins.«io.containerd.grpc.v1.cri».cni] в .
Koska käytämme Flanelia verkkopalveluntarjoajanamme, puhutaanpa hieman sen määrittämisestä:
- Flaneld (Flanelin demoni) asennetaan yleensä klusteriin DaemonSet-muodossa.
install-cnikuin . Install-cniluo (/etc/cni/net.d/10-flannel.conflist) jokaisessa solmussa.- Flaneld luo vxlan-laitteen, hakee verkon metatiedot API-palvelimelta ja tarkkailee pod-päivityksiä. Kun niitä luodaan, se jakaa reitit kaikkiin klusteriin.
- Nämä reitit sallivat podien kommunikoida keskenään IP-osoitteiden kautta.
Tarkempia tietoja Flannelin työstä suosittelen käyttämään artikkelin lopussa olevia linkkejä.
Tässä on kaavio Containerd CRI -laajennuksen ja CNI-laajennusten välisestä vuorovaikutuksesta:
Kuten yllä näkyy, kubelet kutsuu Containerd CRI -laajennusta podin luomiseksi, joka sitten kutsuu CNI-laajennusta podin verkon määrittämiseksi. Näin tehdessään verkkopalveluntarjoajan CNI-laajennus kutsuu muita CNI-ydinlaajennuksia määrittääkseen verkon eri osa-alueita.
Vuorovaikutus CNI-laajennusten välillä
On olemassa useita CNI-laajennuksia, joiden tehtävänä on auttaa verkkoyhteyden muodostamisessa isäntäkoneen säiliöiden välillä. Tässä artikkelissa käsitellään kolmea niistä.
CNI-laajennus Flanel
Käytettäessä Flannelia verkkopalveluntarjoajana Containerd CRI -komponentti kutsuu käyttämällä CNI-määritystiedostoa /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 -laajennus toimii yhdessä Flanneldin kanssa. Käynnistyksen aikana Flaneld hakee podCIDR:n ja muut verkkoon liittyvät tiedot API-palvelimelta ja tallentaa ne tiedostoon /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 -laajennus käyttää tietoja kohteesta /run/flannel/subnet.env määrittääksesi ja kutsuaksesi CNI-siltalaajennusta.
CNI-laajennus Bridge
Tätä laajennusta kutsutaan seuraavalla kokoonpanolla:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Kun sitä kutsutaan ensimmäisen kerran, se luo Linux-sillan «name»: «cni0», joka on ilmoitettu konfiguraatiossa. Sitten kullekin palolle luodaan veth-pari. Sen toinen pää on kytketty säilön verkon nimiavaruuteen, toinen on isäntäverkon Linux-sillassa. yhdistää kaikki isäntäsäiliöt isäntäverkon Linux-sillalle.
Kun veth-parin määrittäminen on valmis, Bridge-laajennus kutsuu isäntäpaikallista IPAM CNI -laajennusta. IPAM-laajennuksen tyyppi voidaan määrittää CNI-konfiguraatiossa, jota CRI-laajennus käyttää kutsuessaan Flannel CNI -laajennusta.
Isäntäpaikalliset IPAM CNI -laajennukset
Bridge CNI -puhelut seuraavalla kokoonpanolla:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Isäntäpaikallinen IPAM-laajennus (IP AO SOITE Management - IP-osoitteiden hallinta) palauttaa kontin IP-osoitteen aliverkosta ja tallentaa allokoidun IP-osoitteen isännälle kohdassa määritettyyn hakemistoon dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Tämä tiedosto sisältää sen säilön tunnuksen, jolle tämä IP-osoite on määritetty.
Kutsuttaessa isäntäpaikallista IPAM-laajennusta, se palauttaa seuraavat tiedot:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Yhteenveto
Kube-controller-manager määrittää podCIDR:n jokaiselle solmulle. Jokaisen solmun podit vastaanottavat IP-osoitteet osoiteavaruudesta varatulla podCIDR-alueella. Koska solmujen podCIDR:t eivät mene päällekkäin, kaikki podit saavat yksilölliset IP-osoitteet.
Kubernetes-klusterin järjestelmänvalvoja määrittää ja asentaa kubeletin, säilön suoritusajan, verkkopalveluntarjoajan agentin ja kopioi CNI-laajennukset jokaiseen solmuun. Käynnistyksen aikana verkontarjoajan agentti luo CNI-määrityksen. Kun pod on ajoitettu solmuun, kubelet kutsuu CRI-laajennusta luodakseen sen. Seuraavaksi, jos Containerd CRI -laajennus on käytössä, Containerd CRI -laajennus kutsuu CNI-määrityksessä määritettyä CNI-laajennusta konfiguroidakseen podin verkon. Tämän seurauksena pod saa IP-osoitteen.
Kesti jonkin aikaa ymmärtääkseni kaikkien näiden vuorovaikutusten kaikki hienoudet ja vivahteet. Toivon, että tämä kokemus auttaa sinua ymmärtämään paremmin, miten Kubernetes toimii. Jos olen jossain asiassa väärässä, ota yhteyttä osoitteeseen tai osoitteessa . Ota rohkeasti yhteyttä, jos haluat keskustella tämän artikkelin näkökohdista tai jostain muusta. Haluaisin keskustella kanssasi!
viittaukset
Kontit ja verkko
Miten flanelli toimii?
CRI ja CNI
PS kääntäjältä
Lue myös blogistamme:
- «";
- "Kubernetesin kuvitettu opas verkostoitumiseen": , ;
- «'.
Lähde: will.com