🥇Kako pod u Kubernetesu dobija IP adresu

Napomena za prijevod.: ovaj članak, koji je napisao SRE inženjer iz LinkedIna, detaljno objašnjava onu "unutarnju magiju" u Kubernetesu — točnije, interakciju CRI-a, CNI-a i kube-apiservera, — što se događa kada se novom podu dodjeljuje IP adresa.

Jedan od osnovnih zahtjeva mrežnog modela Kubernetes je da svaki pod mora imati svoju vlastitu IP adresu i da se bilo koji drugi pod u klasteru može povezati s njom. Postoji mnogo mrežnih "provajdera" (Flannel, Calico, Canal itd.) koji pomažu u implementaciji ovog mrežnog modela.

Kada sam tek počeo raditi s Kubernetesom, nije mi bilo sasvim jasno kako podovi dobivaju svoje IP adrese. Čak i s razumijevanjem kako rade pojedinačne komponente, bilo je teško zamisliti njihovu međusobnu suradnju. Na primjer, znao sam zašto su potrebni CNI dodaci, ali nisam znao kako se oni točno pozivaju. Zato sam odlučio napisati ovaj članak kako bih podijelio svoja saznanja o različitim mrežnim komponentama i njihovoj međusobnoj suradnji u Kubernetes klasteru, koje omogućuju svakom podu da dobije svoju jedinstvenu IP adresu.

Postoje različiti načini organiziranja mrežne interakcije u Kubernetesu — slično kao što postoje različite verzije izvršnih okruženja (runtime) za kontejnere. U ovoj će se publikaciji koristiti Flannel za organizaciju mreže u klasteru, a kao izvršno okruženje — Containerd. Također pretpostavljam da znate kako je uređena mrežna interakcija između kontejnera, pa ću je samo ukratko spomenuti, isključivo za kontekst.

Osnovni pojmovi

Kontejneri i mreža: kratak pregled

Na internetu postoji mnogo izvrsnih publikacija koje objašnjavaju kako se kontejneri međusobno povezuju putem mreže. Stoga ću dati samo opći pregled osnovnih pojmova i ograničiti se na jedan pristup, koji podrazumijeva stvaranje Linux mosta i inkapsulaciju paketa. Detalji su izostavljeni jer sama tema mrežne interakcije kontejnera zaslužuje poseban članak. Linkovi na neke osobito sadržajne i poučne publikacije bit će navedeni u nastavku.

Kontejneri na jednom hostu

Jedan od načina organizacije veze putem IP adresa između kontejnera koji rade na istom hostu podrazumijeva stvaranje Linux mosta. Za to se u Kubernetesu (i Dockeru) stvaraju virtualne jedinice veth (virtualna ethernetska veza). Jedan kraj veth uređaja povezan je s mrežnim imenskim prostorom kontejnera, dok je drugi povezan s Linux mostom u mreži hosta.

Svi kontejneri na istom hostu imaju jedan kraj veth povezan s mostom, kroz koji mogu komunicirati jedni s drugima putem IP adresa. Linux most također ima IP adresu i djeluje kao prolaz za izlazni (egress) promet iz podova koji su namijenjeni drugim čvorovima.

Kontejneri na različitim hostovima

Enkapsulacija paketa jedan je od načina koji omogućava kontejnerima na različitim čvorovima da komuniciraju jedni s drugima putem IP adresa. U Flannelu ovu mogućnost omogućava tehnologija vxlan, koja 'upakuje' izvorni paket unutar UDP paketa i zatim ga šalje na odredište.

U Kubernetes klasteru, Flannel stvara vxlan uređaj i odgovarajuće nadopunjava tablicu ruta na svakom od čvorova. Svaki paket koji je namijenjen kontejneru na drugom hostu prolazi kroz vxlan uređaj i enkapsulira se u UDP paket. Na odredištu se ugniježdeni paket izvadi i proslijedi na željeni pod.

Napomena: Ovo je samo jedan od načina organizacije mrežne komunikacije između kontejnera.

Što je CRI?

CRI (Container Runtime Interface) je dodatak koji omogućuje kubelet-u korištenje različitih izvršnih okruženja kontejnera. CRI API je ugrađen u različita izvršna okruženja, tako da korisnici mogu birati runtime po svojoj želji.

Što je CNI?

CNI projekt predstavlja specifikaciju za organizaciju univerzalnog mrežnog rješenja za Linux kontejnere. Osim toga, uključuje dodatke, koji su odgovorni za različite funkcije tijekom postavljanja mreže pod-a. CNI dodatak je izvršna datoteka koja se pridržava specifikacije (neke od dodataka ćemo raspraviti u nastavku).

Dodjeljivanje podmreža čvorovima za dodjelu IP adresa pod-ovima

Budući da svaki pod u klasteru mora imati IP adresu, važno je osigurati da ta adresa bude jedinstvena. To se postiže dodjeljivanjem svakoj čvoru jedinstvene podmreže iz koje se zatim dodjeljuju IP adrese pod-ovima na tom čvoru.

Kontroler IPAM čvora

Kada nodeipam proslijeđuje kao parametar zastavice --kontroleri kube-controller-manager-a, dodjeljuje svakoj čvoru zasebnu podmrežu (podCIDR) iz CIDR klastera (tj. raspona IP adresa za mrežu klastera). Budući da se ti podCIDR-ovi ne preklapaju, moguće je svakom pod-u dodijeliti jedinstvenu IP adresu.

Kubernetes čvoru dodjeljuje se podCIDR u trenutku njegove početne registracije u klasteru. Da biste promijenili podCIDR kod čvorova, potrebno ih je deregistrirati, a zatim ponovno registrirati, između toga napraviti odgovarajuće izmjene u konfiguraciji upravljačkog sloja Kubernetes-a. PodCIDR čvora može se ispisati pomoću sljedeće naredbe:

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

Kubelet, okruženje za pokretanje kontejnera i CNI dodaci: kako to sve funkcionira

Planiranje pod-a na čvoru uključuje izvršavanje niza pripremnih radnji. U ovom odjeljku ću se usredotočiti samo na one koje su izravno povezane s konfiguracijom mreže pod-a.

Planiranje pod-a na određeni čvor pokreće sljedeći niz događaja:

Pomoć: Arhitektura CRI dodataka Containerd.

Interakcija okruženja za pokretanje kontejnera i CNI dodataka

Svaki mrežni pružatelj ima svoj CNI dodatak. Kontejnersko okruženje pokreće ga kako bi konfiguriralo mrežu za pod tijekom njegovog pokretanja. U slučaju containerd, pokretanje CNI dodatka obavlja dodatak Containerd CRI.

Pri tome svaki pružatelj ima svog agenta. On se instalira na sve čvorove Kubernetes-a i odgovoran je za mrežnu konfiguraciju pod-ova. Ovaj agent dolazi ili u kompletu s CNI konfiguracijom ili samostalno stvara na čvoru. Konfiguracija pomaže CRI dodatku da odredi koji CNI dodatak pozvati.

Lokacija CNI konfiguracije može se postaviti; zadano se nalazi u /etc/cni/net.d/<config-file>. Administratori klastera također su odgovorni za instalaciju CNI dodataka na svaki čvor klastera. Njihova lokacija također se podešava; zadani direktorij je /opt/cni/bin.

Pri korištenju containerd, putanje za konfiguraciju i binarne datoteke dodatka mogu se odrediti u odjeljku [plugins."io.containerd.grpc.v1.cri".cni] u datoteka konfiguracije containerd.

Budući da koristimo Flannel kao mrežnog pružatelja, razgovarajmo malo o njegovoj konfiguraciji:

Flanneld (Flannel demon) obično se instalira u klaster kao DaemonSet s install-cni kao init-kontejnerom.
Install-cni stvara CNI konfiguracijsku datoteku (/etc/cni/net.d/10-flannel.conflist) na svakom čvoru.
Flanneld kreira vxlan uređaj, izvlači mrežne metapodatke s API poslužitelja i prati ažuriranja podova. Kada se oni kreiraju, širi rute za sve podove diljem klastera.
Te rute omogućuju podovima da komuniciraju jedni s drugima putem IP adresa.

Za više informacija o radu Flannela preporučujem upotrebu poveznica na kraju članka.

Evo sheme interakcije između Containerd CRI dodatka i CNI dodataka:

Kao što se može vidjeti iznad, kubelet poziva Containerd CRI dodatak za stvaranje poda, a on već poziva CNI dodatak za postavljanje mreže poda. U tom procesu CNI dodatak mrežnog dobavljača poziva druge osnovne CNI dodatke za konfiguriranje različitih aspekata mreže.

Interakcija između CNI dodataka

Postoje različiti CNI dodaci, čija je zadaća pomoći u postavljanju mrežne komunikacije između kontejnera na hostu. U ovom članku govorit ćemo o tri od njih.

CNI dodatak Flannel

Kada se Flannel koristi kao mrežni dobavljač, komponenta Containerd CRI poziva CNI dodatak Flannel, koristeći konfiguracijski datoteku CNI /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 dodatak Flannel radi zajedno s Flannelom. Tijekom pokretanja Flanneld izvlači podCIDR i druge povezane mrežne podatke iz API poslužitelja i sprema ih u datoteku /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 dodatak Flannel koristi podatke iz /run/flannel/subnet.env za postavljanje i pozivanje CNI dodatka mosta (bridge).

CNI dodatak Bridge

Ovaj dodatak se poziva s sljedećom konfiguracijom:

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

Prilikom prvog poziva stvara Linux most s "name": "cni0", što se navodi u konfiguraciji. Tada se za svaki pod stvara par veth. Jedan kraj se priključuje na mrežni prostor imena kontejnera, a drugi ulazi u Linux most u mreži hosta. CNI dodatak Bridge priključuje sve kontejnere hosta na Linux most u mreži hosta.

Kada dovrši postavku para veth, Bridge dodatak poziva lokalni za host (host-local) CNI dodatak IPAM. Tip IPAM dodatka može se postaviti u CNI konfiguraciji, koju CRI dodatak koristi za pozivanje CNI dodatka Flannel.

Lokalni za host IPAM dodaci CNI

Bridge CNI poziva lokalni IPAM dodatak CNI s sljedećom konfiguracijom:

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

Host-local IPAM dodatak (IP Aaddr Management — upravljanje IP adresama) vraća IP adresu za kontejner iz podmreže i čuva dodeljenu IP adresu na hostu u direktoriju navedenom u odeljku dataDir — /var/lib/cni/networks/<network-name=cni0>/<ip>. Ovaj fajl sadrži ID kontejnera kojem je dodeljena ova IP adresa.

Pri pozivanju host-local IPAM dodatka vraća se sledeći podaci:

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

Sažetak

Kube-controller-manager svakom čvoru dodeljuje podCIDR. Podovi svakog čvora dobijaju IP adrese iz adresnog prostora u dodeljenom opsegu podCIDR. Pošto se podCIDR-ovi čvorova ne preklapaju, svi podovi dobijaju jedinstvene IP adrese.

Administrator Kubernetes klastera postavlja i instalira kubelet, okruženje za pokretanje kontejnera, agenta mrežnog provajdera i kopira CNI dodatke na svaki čvor. Tokom pokretanja, agent mrežnog provajdera generiše CNI konfiguraciju. Kada se pod planira na čvor, kubelet poziva CRI dodatak za njegovo kreiranje. Dalje, ako se koristi containerd, plugin Containerd CRI poziva CNI dodatak naveden u CNI konfiguraciji za podešavanje mreže poda. Kao rezultat, pod dobija IP adresu.

Potrebno mi je vreme da razumem sve nijanse i detalje svih ovih interakcija. Nadam se da će iskustvo koje sam stekao pomoći i vama da bolje razumete kako Kubernetes funkcioniše. Ako sam negde napravio grešku, slobodno me kontaktirajte na Twitter ili na adresu hello@ronaknathani.com. Ne ustručavajte se da se javite ako želite da razgovarate o aspektima ovog članka ili bilo čemu drugom. Rado ću popričati s vama!