Jump to content

Kubernetes

Nga Wikipedia, enciklopedia e lirë
Kubernetes
Autorët origjinalë Google
Zhvilluesit Cloud Native Computing Foundation
Dalja fillestare 0.2[1] / 9 Shtator 2014 (2014-09-09)
Dalja e qëndrueshme
1.27.2Edit this on Wikidata / 17 Maj 2023;  (17 May 2023)
Repo
Shkruar me Go
Tipi Softuer menaxhues klasterash
Licensa Apache License 2.0
Website kubernetes.io

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.

Konceptet

[Redakto | Redakto nëpërmjet kodit]
Diagrami i arkitekturës Kubernetes

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

[Redakto | Redakto nëpërmjet kodit]

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

[Redakto | Redakto nëpërmjet kodit]

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)

[Redakto | Redakto nëpërmjet kodit]

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

[Redakto | Redakto nëpërmjet kodit]

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

[Redakto | Redakto nëpërmjet kodit]

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

[Redakto | Redakto nëpërmjet kodit]

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

[Redakto | Redakto nëpërmjet kodit]
Pamje e thjeshtuar që tregon se si Shërbimet ndërveprojnë me rrjetin e Pod-it në një grupim Kubernetes

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

[Redakto | Redakto nëpërmjet kodit]

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

[Redakto | Redakto nëpërmjet kodit]

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:

  1. si ndryshore të mjedisit (të cilat do të krijohen nga Kubernetes kur të fillojë podi);
  2. e gatshme në sistemin e skedarëve të kontejnerit që është i dukshëm vetëm nga brenda podit.

StatefulSets

[Redakto | Redakto nëpërmjet kodit]

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.

Përdorimet

[Redakto | Redakto nëpërmjet kodit]

Kubernetes përdoret zakonisht si një mënyrë për të bujtur një zbatim të bazuar në mikroshërbime, sepse ai dhe ekosistemi i mjeteve të lidhura me të ofrojnë të gjitha aftësitë e nevojshme për të adresuar shqetësimet kryesore të çdo arkitekture të mikroshërbimeve . Vjen në tre forma: me burim të hapur, komercial dhe të menaxhuar. Shpërndarjet me burim të hapur përfshijnë Kubernetes origjinale, Amazon EKS-D, Red Hat OpenShift, VMware Tanzu, Mirantis Kubernetes Engine dhe D2iQ Kubernetes Platform. Ofertat e menaxhuara përfshijnë GKE, Microsoft Azure Kubernetes Services, Oracle Container Engine për Kubernetes, Amazon Elastic Kubernetes Service, IBM Kubernetes Service dhe Platform9 Managed Kubernetes. [29]

  1. ^ "v0.2". github.com. 2014-09-09.{{cite web}}: CS1 maint: url-status (link)
  2. ^ "Kubernetes GitHub Repository". GitHub. 22 janar 2021. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  3. ^ "kubernetes/kubernetes". GitHub (në anglisht). Arkivuar nga origjinali më 2017-04-21. Marrë më 2017-03-28.
  4. ^ "What is Kubernetes?". Kubernetes. Marrë më 2017-03-31. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  5. ^ "Overview Kubernetes". Kubernetes (në anglisht). Arkivuar nga origjinali më 2023-01-08. Marrë më 2022-01-04.
  6. ^ "Container runtimes". Kubernetes (në anglisht). Marrë më 2021-11-14.
  7. ^ Sharma, Priyanka (13 prill 2017). "Autoscaling based on CPU/Memory in Kubernetes—Part II". Powerupcloud Tech Blog. Medium. Arkivuar nga origjinali më 17 tetor 2019. Marrë më 27 dhjetor 2018. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  8. ^ "Configure Kubernetes Autoscaling With Custom Metrics". Bitnami. BitRock. 15 nëntor 2018. Arkivuar nga origjinali më 27 mars 2019. Marrë më 27 dhjetor 2018. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  9. ^ a b c d e f g "An Introduction to Kubernetes". DigitalOcean. Arkivuar nga origjinali më 1 tetor 2015. Marrë më 24 shtator 2015. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  10. ^ a b c "Kubernetes Infrastructure". OpenShift Community Documentation. OpenShift. Arkivuar nga origjinali më 6 korrik 2015. Marrë më 24 shtator 2015. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  11. ^ Container Linux by CoreOS: Cluster infrastructure
  12. ^ a b Marhubi, Kamal (2015-09-26). "Kubernetes from the ground up: API server". kamalmarhubi.com. Arkivuar nga origjinali më 2015-10-29. Marrë më 2015-11-02. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  13. ^ Ellingwood, Justin (2 maj 2018). "An Introduction to Kubernetes". DigitalOcean (në anglisht). Arkivuar nga origjinali më 5 korrik 2018. Marrë më 20 korrik 2018. One of the most important primary services is an API server. This is the main management point of the entire cluster as it allows a user to configure Kubernetes' workloads and organizational units. It is also responsible for making sure that the etcd store and the service details of deployed containers are in agreement. It acts as the bridge between various components to maintain cluster health and disseminate information and commands.
  14. ^ "Deployments". Kubernetes (në anglisht). Marrë më 2022-02-27.
  15. ^ "The Three Pillars of Kubernetes Container Orchestration - Rancher Labs". rancher.com. 18 maj 2017. Arkivuar nga origjinali më 24 qershor 2017. Marrë më 22 maj 2017. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  16. ^ a b "Overview of a Replication Controller". Documentation. CoreOS. Arkivuar nga origjinali më 2015-09-22. Marrë më 2015-11-02. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  17. ^ Sanders, Jake (2015-10-02). "Kubernetes: Exciting Experimental Features". Livewyer. Arkivuar nga origjinali më 2015-10-20. Marrë më 2015-11-02. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  18. ^ "Intro: Docker and Kubernetes training - Day 2". Red Hat. 2015-10-20. Arkivuar nga origjinali më 2015-10-29. Marrë më 2015-11-02. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  19. ^ Marhubi, Kamal (2015-08-27). "What [..] is a Kubelet?". kamalmarhubi.com. Arkivuar nga origjinali më 2015-11-13. Marrë më 2015-11-02. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  20. ^ "Kubernetes Security | Issues and Best Practices | Snyk". snyk.io (në anglishte amerikane). 26 korrik 2020. Marrë më 2021-05-16.
  21. ^ "rktnetes brings rkt container engine to Kubernetes". kubernetes.io. 11 korrik 2016. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  22. ^ "Namespaces". kubernetes.io. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  23. ^ "Pods". kubernetes.io. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  24. ^ Langemak, Jon (2015-02-11). "Kubernetes 101 – Networking". Das Blinken Lichten. Arkivuar nga origjinali më 2015-10-25. Marrë më 2015-11-02. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  25. ^ "DaemonSet". kubernetes.io. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  26. ^ "ReplicaSet". kubernetes.io (në anglisht). Marrë më 2020-03-03.
  27. ^ Langemak, Jon (2015-02-15). "Kubernetes 101 – External Access Into The Cluster". Das Blinken Lichten. Arkivuar nga origjinali më 2015-10-26. Marrë më 2015-11-02. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  28. ^ "Volumes". kubernetes.io. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  29. ^ "5 Cloud Native Trends to Watch out for in 2022". The New Stack (në anglishte amerikane). 2022-01-03. Marrë më 2022-02-03.
Marrë nga "https://sq.wikipedia.org/w/index.php?title=Kubernetes&oldid=2585535"