Kubernetes arhitektura se zasniva na konceptu klijent-server. Kubernetes klaster se sastoji od najmanje jednog glavnog i više radnih čvorišta odnosno takozvanih “nodova”.
Takođe je moguće imati multi-master podešavanje za visoku dostupnost, ali podrazumevano postoji jedan glavni čvor (Master Node) koji deluje i kao kontrolni čvor i tačka kontakta.
U ovom delu, kao i u svim ostalim tekstovima ćemo koristiti za Kubernetes izvorne termine na engleskom, kako bi čitaoci ili oni koji se budu upustili u Kubernetes posao, lakše razumeli tehničke specifikacije i objašnjenja. Tako ćemo koristiti termine poput Master Nodes, Worker Nodes, Slave Nodes itd ..
Svakako ćemo objasniti šta svaki od ovih termina znači i gde se nalazi u arhitekturi.
Sama potreba da našu kompleksnu aplikaciju učinimo visoko dostupnom, skalabilnom, prenosivom i primenljivom u malim modulima nezavisno dovela je do rođenja Kubernetesa
Sada ćemo videti kakva je Kubernetes arhitektura i koje su ključne komponente.
Arhitektura Kubernetes klastera
Osnovna arhitektura Kubernetes klastera ima dva glavna čvora:
- Master Node (glavno čvorište)
- Worker Node ili Slave Node (radna čvorišta i podređena čvorišta)
Ako pogledate zvaničnu dokumentaciju Kubernetesa, postaje prilično teško pohvatati koncepte za njih.
Zato ćemo pokušati da pojednostavimo glavne principe arhitekture od kojih možete početi sa radom.
Hajde da prvo razumemo kako funkcionišu working i slave nodovi (radna i podređena čvorišta) i koje su ključne komponente working nodova (radnih čvorišta).
Worker Node u Kubernetes klasteru:
Bilo da morate da primenite svoju kontejnersku aplikaciju ili da morate da je automatski skalirate, odnosno da uvedete bilo koje novo ažuriranje aplikacije na produkcijskom nivou na serveru, često ćete se susretati sa worker nodovima. Zato je bitno da znate kako rade i koja im je svrha.
Radni čvor (Worker Node) može imati jedan ili više Podova.
Ovi Podovi su apstrakcija vaših kontejnerskih aplikacija. Svaki worker node kao što je prikazano na slici gore, pokreće ova 3 ključna procesa.
- Container Runtime
- kubelet
- kube-proxy
Sada ćemo da vidimo šta oni zapravo rade i koja im je svrha.
Container Runtime:
Svaki mikroservisni modul (mikro-aplikacija) koji primenite je upakovan u jedan Pod koji ima svoje vreme pokretanja kontejnera.
Potrebno je instalirati runtime kontejnera u svaki worker node u klasteru kako bi Pod-ovi mogli da rade.
Neki od primera pokretanja kontejnera su:
kubelet:
kubelet je primarni node-agent radnog čvorišta (worker noda), koji je u interakciji i sa čvorištem i sa kontejnerom u datom radnom čvorištu (worker nodu) .
Dakle, kublet je odgovoran za :
- Održavanje skupa Pod-ova, koje se sastoje od jednog ili više kontejnera, na lokalnom sistemu.
- Registrovanje nodova na Kubernetes klasteru, slanje de[avanja i statusa Pod-ova, i izveštavanje o korišćenju resursa.
Unutar Kubernetes klastera, kubelet prati PodSpecs preko Kubernetes API servera.
PodSpec je YAML ili JSON fajl koji opisuje Pod.
Kubelet uzima skup PodSpecs-a koji se obezbeđuju kroz različite mehanizme (prvenstveno preko API servera) i obezbeđuje da kontejneri opisani u tim PodSpec-ovima nesmetano rade.
Kubelet je primarni i najvažniji kontroler u Kubernetesu. On je odgovoran za pokretanje slojeva za izvršavanje komandi kontejnera, obično Dockera.
kube-proxy:
K8s klaster može imati više worker nodova i svaki node da ima više pokrenutih Pod-ova, tako da ako neko mora da pristupi nekom Pod-u, to može učiniti preko kube-proxy-ja.
kube-proxy je mrežni proxy koji radi na svakom nodu u vašem klasteru, implementirajući tako deo koncepta Kubernetes servisa.
Da biste pristupili modulu preko K8s servisa, postoje određene mrežne politike, koje omogućavaju mrežnu komunikaciju sa vašim Pod-ovima, iz mrežnih sesija unutar ili van vašeg klastera.
Ovim pravilima se rukuje preko kube-proxy-ja.
Što znači, da putem kube-proxy-ja možete nekom na udaljenom mestu poslati vaš rad na Kubernetesu. O ovome ćemo govoriti detaljnije u narednim tekstovima.
Kube-proxy ima inteligentan algoritam za prosleđivanje mrežnog saobraćaja potrebnog za pristup modulu koji minimizira troškove i čini komunikaciju među servisima efikasnijom.
Do sada smo videli da ova 3 procesa moraju biti instalirana i uspešno pokrenuta unutar worker nodova kako bi se efikasno upravljalo kontejnerskom aplikacijom, ali važnija pitanja su …
- Ko upravlja ovim worker nodovima, kako bi se osiguralo da oni uvek rade ?
- Kako K8s klaster zna koji Pod-ovi treba da budu zakazani, a koji treba da budu ugašeni ili ponovo pokrenuti?
- Kako K8s klaster zna zahteve za nivo resursa svake aplikacije kontejnera?
Pa, odgovor leži u konceptu glavnog čvora, odnosno Master Noda, zato hajde da istražimo i to u nastavku…
Master Node
Glavni čvor, odnosno Master Node, je takođe poznat kao kontrolna oblast koja je odgovorna za efikasno upravljanje radnim/podređenim čvorovima (worker/slave nodovima).
Oni stupaju u interakciju sa radnim čvorištem za…
- Zakazivanje Pod-ova
- Nadzor radnih nodova ili Pod-ova
- Pokretanje ili restartovanje Pod-ova
- Upravljanje novim radnim nodovima koji se pridružuju klasteru
Procesi Master Noda:
Svaki Master node u K8s klasteru pokreće sledeće ključne procese.
- kube-apiserver
- kubectl: kube-controller-manager
- kube-scheduler
- etcd
Da vidimo šta je svaki od ovih procesa.
Kube-apiserver:
To je glavni prolaz za pristup k8s klasteru i deluje kao glavni čuvar kapije za autentifikaciju na nivou klijenta ili možemo reći da je kube-apiserver prednji kraj za Kubernetes kontrolnu oblast (control plane)
.
Dakle, šta god želeli da uradite ..
- da rasporedite novu aplikaciju
- da zakažete novi Pod
- kreirate neki novi servis
- postavite novi upit za dostupnost vašeg worker noda
Moraćete da uputite zahtev API serveru glavnog čvora (Master noda) koji zauzvrat potvrđuje vaše zahteve pre nego što dobijete pristup procesima u radnim čvorovima.
Kube-apiserver je dizajniran da skalira horizontalno — tj. skalira se postavljanjem više instanci. Možete pokrenuti nekoliko instanci kube-apiserver-a i balansirati saobraćaj između tih instanci.
——-
kube-scheduler u Kubernetes Master Nodu:
Svaki put kada K8s administrator/programer želi da zakažete novi Pod na radnom čvoru, potrebno je da pošalje zahtev glavnom API serveru koji će zauzvrat uputiti poziv procesu kube-scheduler-a.
Kube-scheduler će ovde pametno odlučiti na koji radni čvor treba da se postavi ovaj Pod.
Dakle, možemo da definišemo kube-scheduler kao:
Ključna komponenta kontrolne oblasti koja prati novostvorene Pod-ove bez dodeljenog radnog čvora i bira radni čvor na kome će biti zakazani i pokrenuti…
Ili kao odluku na koji radni čvor (worker node) treba da se prilagodi novokreirani Pod na osnovu dostupnosti nivoa resursa svakog noda, pa tako kube-scheduler vrši upit na nivou resursa i donosi odluke o planiranju, odnosno zakazivanju.
Pravo izvršenje odluke na nivou zakazivanja se vrši kubelet procesom u datom radnom čvoru
Ključni i odlučujući faktori u vezi sa rasporedom Pod-ova uključuju:
- Individualni i kolektivni zahtevi za resursima
- Ograničenja hardvera, softvera ili politike
- Specifikacije afiniteta čvorova i anti-afiniteta,
- Lokalitet podataka, interferencija između radnih opterećenja i rokova.
Razumećemo ova navedena ograničenja i politike kasnije dok budemo napredovali da detaljnije pokrijemo Kubernetes.
kube-controller-manager(kubectl):
Jedan od kritičnih procesa na Master nodu koji prati status svih grešaka na nivou radnog čvora. Pomno prati događaj kao što je
- Pad ili nedostupnost bilo kog modula u radnom čvoru (Worker Nodu) …
tako da u tom smislu zahteva od kube-scheduler-a da ponovo pokrene ili ponovo zakaže sve pale ili neuspele Pod-ove, nakon što otkrije takav događaj.
Ova komponenta glavnog kontrolnog planera ima sledeće tipove kontrolera:
- Kontroler noda: Odgovoran je da reaguje kada se bilo koji worker node pokvari
- Kontroler replika: obezbeđuje da se uvek vodi računa o zahtevu i da se održi tačan broj replika bilo koje količine Pod-ova
- Kontroler krajnjih tačaka (Endpoint): Popunjava objekat do Entrypoint-a, odnosno pridružuje Servise i Pod-ove
- Servisni nalog i kontroleri tokena: Kreiranje podrazumevanog naloga i API pristupnog tokena za nova pristupna imena kreirana u worker nodu.
Etcd u Kubernetes Master Nodu:
etcd u glavnoj kontrolnoj oblasti je odgovoran za skladištenje svake vrste promena na nivou klastera u obliku parova ključ-vrednost (key-value)
Može se slobodno reći da je kao mozak Kubernetes klastera koji vodi evidenciju o svim detaljima i promenama koje se dešavaju u klasteru.
Na primer, ako se bilo koji Pod sruši u worker nodu i mora se ponovo rasporediti, isti se čuva u etcd kao par ključ-vrednost, a takođe se evidentira i događaj koji se ponovo zakazuje za Pod.
Dakle, podaci se odnose na neka od ključnih pitanja kao što su:
– Koje vrste resursa su dostupne u nodu?
– Da li se stanje klastera promenilo zbog kvara nekog noda?
– Da li je na klasteru sve u redu?
Tako da svi podaci koji se čuvaju ovde se zapravo čuvaju kako bi se osiguralo da je naš Kubernetes klaster “svestan” istog da bi preduzeo bolje radnje u skladu sa izvršnom radnjom.
Beleška!
Podaci na nivou aplikacije kao što je DB se ne čuvaju u etcd-u.
Kubernetes komponente:
Sada kada smo razumeli arhitektonske procese Kubernetes klastera, vreme je da pogledamo neke od ključnih komponenti Kubernetesa koje pomažu u orkestraciji kontejnera na nivou proizvoda.
Ovde ćemo samo navesti te komponente i ući ćemo u detalje svake od njih u drugom delu koji ćemo uskoro pripremiti.
U drugom delu ćemo pričati o ključnim komponentama i konceptima Kubernetesa
Neke od ključnih komponenti K8s su:
Pods:
Services & Ingress:
ConfigMaps:
Secrets:
Volume:
Deployments:
Statefulsets:
Beleška:
Master Node – Glavno čvorište
Node – jedan od glavnih delova Kubernetesa
Worker node – radno čvorište
Worker slave – podređeno čvorište
Pods – najmanje jedinice u Kubernets arhitekturi
etcd – skladištenje podataka u Klasteru
kube-controller-manager – vrste kontrolera
kube-scheduler – zakazivanje i planiranje u Kalsteru
kube-proxy – je mrežni proksi koji radi na svakom čvoru u vašem klasteru
kubelet – je primarni “agent čvora” koji radi na svakom čvoru
Container Runtime – dužina vremena pokretanja kontejenra
šta je kubernetes arhitektura
Napišite komentar