🥇Kā pod Kubernetes iegūst IP adresi

Piezīme:: Šis raksts, ko uzrakstījis SRE inženieris no LinkedIn, detalizēti stāsta par to "iekšējo maģiju" Kubernetes — precīzāk, par CRI, CNI un kube-apiserver mijiedarbību, — kas notiek, kad nākamajam pod'ām ir nepieciešams piešķirt IP adresi.

Viens no pamata prasībām Kubernetes tīkla modelim ir tāds, ka katram podam jābūt savai IP adresei, un jebkuram citam podam klasterī jābūt iespējai sazināties ar to, izmantojot šo adresi. Ir daudzi tīkla "nodrošinātāji" (Flannel, Calico, Canal utt.), kas palīdz īstenot šo tīkla modeli.

Kad es tikko sāku strādāt ar Kubernetes, man nebija pilnīgas skaidrības par to, kā pod'ām tiek piešķirtas IP adreses. Pat saprotot, kā darbojas atsevišķas sastāvdaļas, bija grūti iedomāties to sadarbību. Piemēram, es zināju, kādēļ nepieciešami CNI spraudņi, bet man nebija skaidrs, kā tie precīzi tiek izsaukti. Tāpēc es nolēmu uzrakstīt šo rakstu, lai dalītos ar zināšanām par dažādajiem tīkla komponentiem un to sadarbību Kubernetes klasterī, kas ļauj katram podam iegūt savu unikālo IP adresi.

Kubernetes tīkla mijiedarbības organizēšanai ir dažādas metodes — līdzīgi kā ir arī dažādi izpildes vidē (runtime) konteineriem. Šajā publikācijā tiks izmantots Flannel tīkla organizēšanai klasterī, savukārt izpildes vide būs Containerd. Tāpat es pieņemu, ka jums ir zināšanas par to, kā notiek tīkla mijiedarbība starp konteineriem, tāpēc es tikai īsi to apskatīšu, lai sniegtu kontekstu.

Daži pamata jēdzieni

Konteineri un tīkls: īss pārskats

Internetā ir pietiekami daudz lielisku publikāciju, kas izskaidro, kā konteineri saistās savā starpā tīklā. Tāpēc es sniegšu tikai vispārēju pārskatu par pamata jēdzieniem un ierobežošos ar vienu pieeju, kas ietver Linux tilta izveidi un pakešu iepakošanu. Detalizētas informācijas ir izslēgtas, jo pati tēma par konteineru tīkla mijiedarbību ir pelnījusi atsevišķu rakstu. Zemāk tiks iekļautas saites uz dažām it īpaši saturīgām un izzinošām publikācijām.

Konteineri vienā hostā

Viens no veidiem, kā organizēt IP adreses saziņu starp konteineriem, kas darbojas uz viena hosta, ietver Linux tilta izveidi. Tam Kubernetes (un Docker) izveido virtuālus ierīces. veth (virtuālais Ethernet). Viens gals veth ierīcei ir savienots ar konteinera tīkla nosacījumu, otrs – ar Linux tiltu uz hosta tīkla.

Visiem konteineriem uz viena hosta viens no veth galiem ir savienots ar tiltu, caur kuru tie var savstarpēji sazināties pa IP adresēm. Linux tiltam arī ir IP adrese, un tas kalpo kā vārti iznākamajam (egress) trafikam no pod’iem, kas domāti citiem mezgliem.

Konteineri uz dažādiem hostiem

Ieplūdes paketēšana ir viens no veidiem, kas ļauj konteineriem uz dažādiem mezgliem savstarpēji sazināties pa IP adresēm. Flannel par šo iespēju atbild tehnoloģija vxlan, kas "iepako" izejošo paketi UDP paketē un pēc tam nosūta uz galamērķi.

Kubernetes kopā Flannel izveido vxlan ierīci un attiecīgi papildina maršrutu tabulu katram mezglam. Katra pakete, kas domāta konteneram uz cita hosta, iziet cauri vxlan ierīcei un tiek iepakota UDP paketē. Galamērķī iesaiņotā pakete tiek izņemta un pārsūtīta uz attiecīgo pod.

Piezīme: Tas ir tikai viens no veidiem, kā organizēt tīkla mijiedarbību starp konteineriem.

Kas ir CRI?

CRI (Container Runtime Interface) ir spraudnis, kas ļauj kubelet'iem izmantot dažādas konteineru izpildes vides. CRI API ir iebūvēts dažādās izpildes vides, tāpēc lietotāji var izvēlēties izpildes vidi pēc saviem ieskatiem.

Kas ir CNI?

CNI projekts ir specifikāciju ir izstrādāts universāla tīkla risinājuma izveidei Linux konteineriem. Turklāt tajā ir iekļauti spraudņi, kas atbild par dažādām funkcijām pod tīkla iestatīšanā. CNI spraudnis ir izpildes fails, kas atbilst specifikācijai (dažus spraudņus mēs apspriedīsim tālāk).

Apakštīklu piešķiršana mezgliem, lai piešķirtu IP adreses pod’iem

Ņemot vērā, ka katram klastera podam jābūt IP adresei, ir svarīgi pārliecināties, ka šī adrese ir unikāla. To panāk, piešķirot katram mezglam unikālu apakštīklu, no kura pēc tam pod’iem šajā mezglā tiek piešķirtas IP adreses.

IPAM kontrolieris mezglam

Kad nodeipam tiek nodots kā parametra karogs --controllers kube-controller-manager’ā, katram mezglam tiek piešķirta atsevišķa apakštīkla (podCIDR) no klastera CIDR (t.i., IP adrešu diapazons klastera tīkliem). Tā kā šie podCIDR nav pretrunā, katram podam ir iespējams piešķirt unikālu IP adresi.

Kubernetes mezglam podCIDR tiek piešķirts tā sākotnējās reģistrācijas brīdī klasterī. Lai mainītu podCIDR mezglos, tie ir jāatsakās un jāreģistrē atkārtoti, starplaikā veicot atbilstošas izmaiņas Kubernetes pārvaldības slāņa konfigurācijā. Mezglu podCIDR var izsist ar sekojošu komandu:

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

Kubelet, konteinera palaišanas vide un CNI spraudņi: kā tas viss darbojas

Pod plānošana mezglā ir saistīta ar daudziem sagatavošanās darbiem. Šajā sadaļā es pievērsīšos tikai tiem, kuri tieši saistīti ar pod tīklu iestatīšanu.

Pod plānošana uz konkrētu mezglu sāks nākamo notikumu ķēdi:

Palīdzība: CRI spraudņu arhitektūra Containerd.

Konteineru palaišanas vides un CNI spraudņu mijiedarbība

Katram tīkla pakalpojumu sniedzējam ir savs CNI spraudnis. Konteinera palaišanas vide to palaiž, lai konfigurētu tīklu podam tā palaišanas procesā. Ja runājam par containerd, CNI spraudņa palaišanu nodrošina spraudnis Containerd CRI.

Tajā katram pakalpojumu sniedzējam ir savs aģents. Tas tiek uzstādīts visos Kubernetes mezglos un ir atbildīgs par pod tīklu iestatīšanu. Šis aģents nāk vai nu kopā ar CNI konfigurāciju, vai arī pats to izveido uz mezgla. Konfigurācija palīdz CRI spraudnim noteikt, kuru CNI spraudni izsist.

CNI konfigurācijas atrašanās vietu var iestatīt; pēc noklusējuma tā atrodas /etc/cni/net.d/<config-file>. Klastera administratoriem arī jāatbild par CNI spraudņu uzstādīšanu katrā klastera mezglā. To atrašanās vieta arī tiek iestatīta; noklusējuma direktorija ir /opt/cni/bin.

Izmantojot containerd, ceļi uz konfigurāciju un spraudņu izpildfailiem tiek noteikti sadaļā [plugins."io.containerd.grpc.v1.cri".cni] par containerd konfigurācijas failā.

Tā kā mēs izmantojam Flannel kā tīkla pakalpojumu sniedzēju, ļaujiet mazliet runāt par tā konfigurāciju:

Flanneld (Flannel demons) parasti tiek uzstādīts klasterī kā DaemonSet ar install-cni kā init konteineru.
Install-cni izveido CNI konfigurācijas failu (/etc/cni/net.d/10-flannel.conflist) katrā mezglā.
Flanneld izveido vxlan ierīci, izvelk tīkla metadatus no API servera un seko podu atjauninājumiem. Tā radot, tas izplata maršrutus visiem podiem visā klasterī.
Šie maršruti ļauj podiem sazināties savā starpā, izmantojot IP adreses.

Lai iegūtu sīkāku informāciju par Flannel darbību, ieteicams izmantot saites raksta beigās.

Šeit ir shēma, kas parāda mijiedarbību starp Containerd CRI spraudni un CNI spraudņiem:

Kā redzams iepriekš, kubelet aicina Containerd CRI spraudni, lai izveidotu podu, un tas jau aicina CNI spraudni, lai konfigurētu podu tīklu. Šajā procesā CNI tīkla pakalpojumu sniedzēja spraudnis aicina citus pamata CNI spraudņus, lai konfigurētu dažādus tīkla aspektus.

Mijiedarbība starp CNI spraudņiem

Ir dažādi CNI spraudņi, kuru uzdevums ir palīdzēt konfigurēt tīkla mijiedarbību starp konteineriem uz hosta. Šajā rakstā tiks apskatīti trīs no tiem.

CNI spraudnis Flannel

Izmantojot Flannel kā tīkla pakalpojumu sniedzēju, Containerd CRI komponents aicina CNI spraudnis Flannel, izmantojot CNI konfigurācijas failu. /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 spraudnis Flannel darbojas kopā ar Flanneld. To palaižot, Flanneld iegūst podCIDR un citus ar tīklu saistītus datus no API servera un saglabā tos failā /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 spraudnis Flannel izmanto datus no /run/flannel/subnet.env lai konfigurētu un izsauktu bridge CNI spraudni.

CNI spraudnis Bridge

Šis spraudnis tiek izsaukts ar šādu konfigurāciju:

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

Pirmajā izsaukumā tiek izveidots Linux tilts ar "name": "cni0", kas norādīts konfigurācijā. Pēc tam katram podam tiek izveidota pāra veth. Viena tās gals tiek pieslēgta konteineru nosaukumu telpai, otra ieiet Linux tiltā hosta tīklā. CNI spraudnis Bridge pievieno visus hosta konteinerus Linux tiltā hosta tīklā.

Pabeidzot veth pāra konfigurāciju, Bridge spraudnis izsauc lokālo hosta (host-local) CNI spraudni IPAM. IPAM spraudņa veidu var konfigurēt CNI konfigurācijas failā, kuru CRI spraudnis izmanto, lai izsauktu Flannel CNI spraudni.

Lokālie hosta IPAM spraudņi CNI

Bridge CNI izsauc lokālo IPAM spraudni CNI ar sekojošo konfigurāciju:

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

Vietējais IPAM spraudnis (IP AAdrese MPārvaldība — IP adresu pārvaldība) atgriež IP adresi konteineram no apakštīkla un saglabā piešķirto IP uz saimniekdatora norādītajā direktorijā dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Šajā failā ir konteineru ID, kuriem ir piešķirta attiecīgā IP adrese.

Izsaucot vietējā IPAM spraudni, tas atgriež sekojošus datus:

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

CV

Kube-controller-manager katram mezglam piešķir podCIDR. Katru mezglu pod’i saņem IP adreses no adresu telpas noteiktajā podCIDR intervalā. Tā kā mezglu podCIDR nav pārklāšanās, visiem pod’iem ir unikālas IP adreses.

Kubernetes klastera administrators konfigurē un instalē kubelet, konteineru palaišanas vidi, tīkla pakalpojumu aģentu un kopē CNI spraudņus uz katru mezglu. Sākoties tīkla pakalpojumu aģentam, tiek ģenerēta CNI konfigurācija. Kad pod tiek ieplānots uz mezglu, kubelet izsauc CRI spraudni tā izveidei. Tad, ja tiek izmantots containerd, Containerd CRI spraudnis izsauc CNI spraudni, norādītu CNI konfigurācijā, lai konfigurētu pod tīklu. Rezultātā pod saņem IP adresi.

Man prasīja zināmu laiku, lai noskaidrotu visas šīs mijiedarbības nianses un smalkumus. Ceru, ka iegūtā pieredze palīdzēs arī jums labāk saprast, kā darbojas Kubernetes. Ja es kaut kur kļūdos, lūdzu, sazinieties ar mani Twitter vai pa e-pastu hello@ronaknathani.com. Nevilcinieties sazināties, ja vēlaties apspriest šīs raksta aspektus vai kaut ko citu. Es labprāt parunāšu ar jums!