Kubernetes
From Wikipedia, the free encyclopedia
Remove ads
Kubernetes ( /ˌ k ( j ) uː b ər ˈ n ɛ t ɪ s ,zakonisht i shkurtuar K8s [2] ) është një sistem orkestrimi i kontejnerëve me burim të hapur për automatizimin e vendosjes, shkallëzimit dhe menaxhimit të softuerit . [3] [4] Projektuar fillimisht nga Google, projekti tani mirëmbahet nga Cloud Native Computing Foundation .
Emri Kubernetes e ka origjinën nga greqishtja e lashtë, që do të thotë 'timonier' ose 'pilot'. Kubernetes shpesh shkurtohet si K8, duke qënë se ka 8 shkronja midis K dhe s (një numeronim ). [5]
Kubernetes punon me kontejner dhe CRI-O . [6] Përshtatshmëria e tij për ekzekutim dhe menaxhim të ngarkesave të mëdha të punës në cloud ka çuar në adoptimin e gjerë të tij në qendrat e të dhënave. Ka shpërndarje të shumta të kësaj platforme – nga ISV-të, si dhe ofertat e pritura në cloud nga të gjithë shitësit kryesorë publikë të cloud-it.
Remove ads
Konceptet
Kubernetes përcakton një grup blloqesh ndërtuese ("primitivë") që ofrojnë bashkarisht mekanizma që zbarkojnë, mirëmbajnë dhe shkallëzojnë aplikacionet bazuar në CPU, kujtesë[7] ose metrika të personalizuara. [8] Kubernetes është i lidhur lirshëm dhe i aftë të shtrihet për të përmbushur ngarkesa të ndryshme pune. Përbërësit e brendshëm, si dhe shtesat dhe kontejnerët që funksionojnë në Kubernetes mbështeten në API Kubernetes. [9] Platforma ushtron kontrollin e saj mbi burimet e llogaritjes dhe ruajtjes duke përcaktuar burimet si Objekte, të cilat më pas mund të menaxhohen si të tilla.
Kubernetes ndjek arkitekturën parësore/kopje . Komponentët e Kubernetes mund të ndahen në ato që menaxhojnë një nyje të vetme dhe ato që janë pjesë e planit të kontrollit. [9] [10]
Plani i kontrollit
Nyja master e Kubernetes trajton rrafshin e kontrollit të grupimit, duke menaxhuar ngarkesën e tij të punës dhe duke drejtuar komunikimin në të gjithë sistemin. Plani i kontrollit Kubernetes përbëhet nga komponentë të ndryshëm, secili proces më vete, që mund të ekzekutohet si në një nyje të vetme kryesore, ashtu edhe në masters të shumtë që mbështesin grupe me gatishmëri të lartë . [10] Komponentët e ndryshëm të planit të kontrollit Kubernetes janë si më poshtë:
- etcd [11] është një ruajtës i përhershëm, i lehtë, i shpërndarë i të dhënave çelës-vlerë që CoreOS ka zhvilluar. Ai ruan në mënyrë të besueshme të dhënat e konfigurimit të klasterit, duke përfaqësuar gjendjen e përgjithshme të klasterit në çdo moment të caktuar kohor. etcd favorizon konsistencën mbi gatishmërinë në rast të ndarjes së rrjetit (shih teoremën CAP ). Konsistenca është thelbësore për planifikimin e saktë dhe funksionimin e shërbimeve.
- Serveri API i shërben Kubernetes API duke përdorur JSON mbi HTTP, i cili siguron ndërfaqen e brendshme dhe të jashtme për Kubernetes. [9] [12] Serveri API përpunon dhe vërteton kërkesat REST dhe përditëson gjendjen e objekteve API në etcd, duke lejuar kështu klientët të konfigurojnë ngarkesat e punës dhe kontejnerët nëpër nyjet punëtore. [13] Serveri API përdor API-në e mbikqyrjes së etcd për të monitoruar grupin, për të nxjerrë ndryshime kritike të konfigurimit ose për të ndrequr çdo divergjencë të gjendjes së klasterit në atë që deklaroi zbarkuesi. Si shembull, zbarkuesi mund të specifikojë se duhet të ekzekutohen tre raste të një "pod" të veçantë (shih më poshtë). etcd ruan këtë fakt. Nëse kontrolluesi i zbarkimit gjen se vetëm dy instanca janë duke u ekzekutuar (në konflikt me deklaratën e etcd), [14] ai planifikon krijimin e një shembulli shtesë të atij pod. [10]
- Planshtruesi (ang. scheduler) është komponenti i shtrijshëm që zgjedh se në cilën nyje funksionon një pod i paplanshtruar (entiteti bazë i menaxhuar nga planshtruesi), bazuar në gatishmërinë e burimeve. Planshtruesi gjurmon përdorimin e burimeve në secilën nyje për të siguruar që ngarkesa e punës të mos jetë e planifikuar më tepër se burimet e gatshme. Për këtë qëllim, ai duhet të dijë kërkesat e burimeve, gatishmërinë e burimeve dhe kufizimet e tjera të ofruara nga përdoruesi ose direktivat e politikave, të tilla si cilësia e shërbimit, kërkesat e afërsisë vs kundër-afërsisë dhe vendosja e të dhënave. Roli i planshtruesit është të përputhë "furnizimin" e burimeve me "kërkesën" e ngarkesës së punës. [15]
- Një kontrollues është një lak rakordimi që drejton gjendjen aktuale të klasterit drejt gjendjes së dëshiruar, duke komunikuar me serverin API për të krijuar, përditësuar dhe fshirë burimet që ai menaxhon (p.sh. podet ose pikat fundore të shërbimit). [16] [12] Një lloj kontrolluesi është një kontrollues i përsëritjes, i cili trajton replikimin dhe shkallëzimin duke ekzekutuar një numër të caktuar kopjesh të një podi nëpër grup. Ai gjithashtu trajton krijimin e podeve zëvendësuese nëse nyja themelore dështon. [16] Kontrollues të tjerë që janë pjesë e sistemit bazë Kubernetes përfshijnë një kontrollues DaemonSet për ekzekutimin saktësisht të një podi në çdo makinë (ose një nëngrupi makinerish) dhe një kontrollues pune për ekzekutimin e podeve që funksionojnë deri në përfundim (p.sh., si pjesë e një pune grupi ). [17] Përzgjedhësit e etiketave që janë pjesë e përkufizimit të kontrolluesit specifikojnë bashësinë e podeve që menaxhon një kontrollues. [18]
- Menaxheri i kontrolluesit është një proces që menaxhon një grup kontrolluesish bazë Kubernetes.
Nyjet
Një nyje, e njohur gjithashtu si një punëtor ose një minion, është një makinë ku vendosen/zbarkohen kontejnerët (ngarkesat e punës). Çdo nyje në klastër duhet të ekzekutojë një kohez të kontejnerit, si p.sh. containerd, si dhe komponentët e përmendur më poshtë, për komunikim me parësorin për konfigurimin e rrjetit të këtyre kontejnerëve.
- Kubelet është përgjegjës për gjendjen e funksionimit të çdo nyje, duke siguruar që të gjithë kontejnerët në nyje të jenë të shëndetshëm. Ai kujdeset për fillimin, ndalimin dhe mirëmbajtjen e kontejnerëve të aplikacionit të organizuar në pode, siç udhëzohet nga plani i kontrollit. [9] [19] Kubelet monitoron gjendjen e një podi, dhe nëse nuk është në gjendjen e dëshiruar, podi ri-vendoset në të njëjtën nyje. Statusi i nyjës transmetohet çdo disa sekonda nëpërmjet mesazheve të rrahjeve të zemrës në parësor. Pasi parësori zbulon një dështim të nyjes, Kontrolluesi i Replikimit vëzhgon këtë ndryshim të gjendjes dhe lëshon podsa në nyje të tjera të shëndetshme. [20]
- Kube-proxy është një implementim i një ndërmjetësi të rrjetit dhe një balancuesi të ngarkesës, dhe mbështet abstraksionin e shërbimit së bashku me veprimet e tjera të rrjetit. [9] Ai është përgjegjës për drejtimin e trafikut në kontejnerin e duhur bazuar në IP dhe numrin e portit të kërkesës në hyrje.
- Një kontejner qëndron brenda një bishti. Kontejneri është niveli më i ulët i një mikro-shërbimi, i cili mban aplikacionin në punë, libraritë dhe varësitë e tyre. Kontejnerët mund t'i ekspozohen botës përmes një adrese IP të jashtme. Kubernetes ka pranuar kontejnerët Docker që nga versioni i tij i parë. Në korrik 2016 u shtua motori i kontejnerëve rkt . [21]
Hapësirat e emrave (Namespaces)
Në Kubernetes, hapësirat e emrave (ang. Namespaces) përdoren për të ndarë burimet që ai trajton në bashkësi të dallueshme dhe joprerëse [22] Ato janë të destinuara për përdorim në mjedise me shumë përdorues të shpërndarë nëpër ekipe të shumta, ose projekte, apo edhe mjedise të ndara si zhvillimi, testimi dhe prodhimi.
Podsat/Podet
Njësia bazë e planifikimit në Kubernetes është një pod, [23] i cili përbëhet nga një ose më shumë kontejnerë që garantohen të jenë të bashkëvendosur në të njëjtën nyje. [9] Çdo podi në Kubernetes i është caktuar një adresë IP unike brenda grupit, duke i lejuar aplikacionet të përdorin portat pa rrezikun e konfliktit. [24] Brenda podit, të gjithë kontejnerët mund t'i referohen njëri-tjetrit.
DaemonSets
Në mënyrë tipike, detyra e përcaktimit të nyjës në të cilën duhet të funksionojë një pod i delegohet Planshtruesit të Kubernetes. Megjithatë, në disa skenarë, mund të jetë e nevojshme të vendoset një pod në çdo nyje në klastër, gjë që është veçanërisht e dobishme për rastet e përdorimit që përfshijnë mbledhjen e logut, kontrolluesit ingress dhe shërbimet e ruajtjes. Ky lloj specifik i planifikimit të podit mund të arrihet duke përdorur DaemonSets. [25]
ReplicaSets
Qëllimi i një ReplicaSet është të mbajë një bashkësi të qëndrueshëm të grupeve të kopjeve që funksionojnë në çdo kohë të caktuar. Si i tillë, shpesh përdoret për të garantuar gatishmërinë e një numri të caktuar të Pods identike. [26]
Shërbimet
Një shërbim Kubernetes është një grup pods që punojnë së bashku, si p.sh. një nivel i një aplikacioni me shumë nivele . Grupi i pods që përbëjnë një shërbim përcaktohen nga një përzgjedhës etiketë. [9] Si parazgjedhje, një shërbim është i ekspozuar brenda një grupi (p.sh. pod- et e pasme mund të grupohen në një shërbim, me kërkesat nga pod-et e përparme të balancuara në ngarkesë midis tyre), por një shërbim mund të ekspozohet edhe jashtë një grupi (p.sh. që klientët të arrijnë në podet e përparme). [27]
Vëllimet
Sistemet e skedarëve në kontejnerët Kubernetes ofrojnë ruajtje kalimtare (efemerale), si parazgjedhje. Kjo do të thotë që një rinisje e podit do të fshijë çdo të dhënë në kontejnerë, dhe për këtë arsye, kjo formë ruajtjeje është mjaft e kufizuar në çdo gjë, përveçse në aplikacione të parëndësishme. Një vëllim Kubernetes [28] siguron ruajtje të vazhdueshme që ekziston për gjithë jetën e vetë podit. Kjo hapësirë ruajtëse mund të përdoret gjithashtu si hapësirë e përbashkët e diskut për kontejnerët brenda pod. Vëllimet janë montuar në pika të veçanta montimi brenda kontejnerit, të cilat përcaktohen nga konfigurimi i podit.
KonfigHartat dhe sekretet
eNjë sfidë e zakonshme e aplikacionit është vendosja se ku të ruhen dhe menaxhohen informacionet e konfigurimit, disa prej të cilave mund të përmbajnë të dhëna të ndjeshme. Kubernetes ofron dy mekanizma të lidhur ngushtë për t'iu përgjigjur këtyre nevojave: "configmaps" dhe "secrets", të cilat lejojnë që ndryshimet e konfigurimit të bëhen pa kërkuar një rindërtim aplikacioni. Të dhënat nga konfighartat dhe sekretet do të vihen në gatishmëri për çdo rast të aplikacionit me të cilin janë lidhur këto objekte nëpërmjet zbarkimeve. Një sekret dhe/ose një konfigurim i dërgohet një nyje vetëm nëse një pod në atë nyje e kërkon atë. Kubernetes do ta mbajë atë në kujtesë në atë nyje. Pasi të fshihet podi që varet nga sekreti ose harta e konfigurimit, fshihet gjithashtu kopja në kujtesë e të gjitha sekreteve të lidhura dhe hartave të konfigurimit. Të dhënat janë të qasshme në pod nëpërmjet një prej dy mënyrave:
- si ndryshore të mjedisit (të cilat do të krijohen nga Kubernetes kur të fillojë podi);
- e gatshme në sistemin e skedarëve të kontejnerit që është i dukshëm vetëm nga brenda podit.
StatefulSets
Shkallëzimi i aplikacioneve pa gjendje është vetëm një çështje e shtimit të më shumë podeve. Ngarkesat me gjëndje janë më të vështira, sepse gjendja duhet të ruhet nëse një pod riniset. Nëse aplikacioni shkallëzohet lart ose poshtë, gjendja mund të ketë nevojë të rishpërndahet. Bazat e të dhënave janë një shembull i ngarkesave me gjëndje. Kur ekzekutohen në mënyrën e gatishmërisë së lartë, shumë baza të të dhënave vijnë me nocionin e një shembulli parësor dhe të instancave dytësore. Në këtë rast, nocioni i renditjes së instancave është i rëndësishëm. Kështu StatefulSets zgjedhin një pod si masterin dhe të tjerët si node. Me anën e përditësimeve të herëpashershme arrihet njëkohësia e podeve.
Remove ads
Përdorimet
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads