Kubernetes

De la Wikipedia, enciclopedia liberă
Jump to navigation Jump to search
Kubernetes
Autor inițialGoogle
DezvoltatorCloud Native Computing Foundation
Versiune inițială07 iunie 2014; acum 5 ani (2014-06-07)[1]
Ultima versiune1.14[2] (25 martie 2019; acum 8 luni (2019-03-25))
Scris înGo
Sistem de operareMultiplatformă  Modificați la Wikidata
TipCluster management software
LicențăApache License 2.0
Prezență online
kubernetes.io

Kubernetes (în mod obișnuit prescurtat ca k8s [3] ) este un sistem de gestionare a containerelor open source pentru automatizarea implementării, scalării și distribuirii aplicațiilor . [4] Acesta a fost inițial proiectat de Google și este acum un proiect întreținut de Cloud Native Computing Foundation . Scopul său este de a oferi o "platformă de automatizare a implementării, scalării și operării containerelor de aplicații în grupuri de computere". [3] Funcționează cu o gamă largă de unelte pentru containerizare, inclusiv cu [[Docker]] . [5] Multe servicii cloud oferă o platformă sau infrastructură bazate pe Kubernetes ca serviciu ( PaaS sau IaaS ). Pe aceasta Kubernetes poate fi implementat ca serviciu de furnizare de platforme (?). Mulți furnizori oferă, de asemenea, propriile distribuții Kubernetes.

Istorie[modificare | modificare sursă]

Prezentare despre Google Container Engine la Google Cloud Summit

Kubernetes ( κυβερνήτης , termen grecesc pentru "guvernator", " cârmaci " sau "căpitan") [3] a fost fondat de o echipă formată de Joe Beda, Brendan Burns și Craig MCLUCKIE, [6] , la care s - au alăturat rapid de alți ingineri Google , inclusiv Brian Grant și Tim Hockin , și a fost prezentat pentru prima dată de Google la mijlocul anului 2014. [7] Dezvoltarea și designul său sunt puternic influențate de sistemul Google Borg [8] [9] și mulți dintre cei mai importanți colaboratori la proiectul anterior lucrau pe Borg. Numele de cod original pentru Kubernetes în Google a fost Project Seven, o referință la personajul Star Trek "Seven of Nine", care este un Borg "mai prietenos". [10] Cele șapte spițe de pe roata siglei Kubernetes sunt o referință la codul respectiv. Proiectul original Borg a fost scris în întregime în C ++ [8] , dar sistemul Kubernetes rescris este implementat în limbajul Go .

Kubernetes v1.0 a fost lansat pe 21 iulie 2015. [11] Alături de versiunea Kubernetes v1.0, Google a colaborat cu Fundația Linux pentru a forma Cloud Native Computing Foundation (CNCF) [12] și a oferit Kubernetes ca tehnologie de plecare. La 6 martie 2018, proiectul Kubernetes a ajuns pe locul al nouălea în comitetele de la GitHub, și pe locul al al doilea între autorii și problemele legate de kernel-ul Linux . [13]

Obiectele Kubernetes[modificare | modificare sursă]

Kubernetes definește un set de blocuri de construcție ("primitivele" bazate pe CPU, memorie [14] sau resurse specifice. [15]), care impreună oferă un mecanism ce implementează, mențin și scalează aplicațiile, Kubernetes este considerat "[[loosely coupled]]" și este extensibil pentru a satisface diferite sarcini de lucru. Această extensibilitate este furnizată în mare parte de API-ul Kubernetes, care este utilizat de componentele interne, precum și de extensiile și containerele care rulează pe Kubernetes. [16] . Platforma își exercită controlul asupra resurselor de calcul și de stocare prin definirea resurselor ca Obiecte, care apoi pot fi gestionate ca atare. Obiectele complexe sunt numite:

Pods (ar trebui tradus: Păstăile)[modificare | modificare sursă]

Pentru a gestiona similar mai multe resurse asemănătoare, Kubernets definește conceptul de bază numit pod . [17] (Imaginati-vă o păstaie cu mai multe boabe prelucrate similar). Acestă "păstaie", (fiind un container abstract de containere concrete) permite un nivel mai ridicat de abstractizare, realizat practic prin gruparea in acelasi pod a componentelor containerizate. Un pod constă, deci, dintr-unul sau mai multe containere care sunt garantate a fi co-localizate pe mașina gazdă și pot partaja resurse. [16]

Fiecare pod din Kubernetes beneficiază de o adresă unică (dar temporară pe durata rularii fara reboot) de IP de Pod în interiorul cluster-ului, care permite aplicațiilor să utilizeze porturile cu servicii fără riscul de a le încurca pe durata unei sesiuni de lucru. [18] În interiorul pod-ului, toate containerele se pot accesa unele pe altele pe acelasi localhost, dar un container aflat într-un anumit pod nu are nici un mod de adresare directă a unui alt container dintr-un alt pod decat al său; pentru aceasta, trebuie să utilizeze adresa IP a interfetei externe a Pod-ului vizat. Un dezvoltator de aplicații nu ar trebui să folosească niciodată o adresa IP de Pod, pentru a face o referire / o invocare a unei functii dintr-un anume alt pod, deoarece aceste adresele IP de Pod sunt temporare - acea adresa poate ajunge sa fie a unui cu totul alt Pod dupa o repornire a sistemului. În schimb, dezvoltatorii ar trebui să utilizeze o referință la un serviciu , care conține ea o adresa IP specifică pod-ului cautat.

Un pod poate include o unitate de stocare, cum ar fi un director de disc local sau un disc de rețea, și îl ofera la dispozitia tuturor containerelor din acel pod. [19] Pod-urile pot fi gestionate manual prin API-ul Kubernetes sau administrarea lor poate fi delegată unui [[controller]]. [16] In Kubernetes astfel de unitati de stocare sunt, de asemenea unitati elementare ale sistemului de gestiune a drepturilor asupra configuratiei, numit ConfigMaps and Secrets. Kubernets permite alocarea de drepturi de acces la aceste volume sau unitat de stocare date (oarecum asemanator cu drepturile de acces la serverele Novell sau volumele Unix) astfel incat numai cei autorizati sau serviciile soft autorizate sa poata accesa aceste unitati de stocare.

Serviciile[modificare | modificare sursă]

Afișare simplificată care arată modul în care serviciile interacționează cu complexele de tip Pod într-un cluster Kubernetes

Un serviciu Kubernetes este compus dintr-un set de pod-uri care funcționează împreună, cam ca la un nivel dintr-o API de aplicație multi-nivel . Setul de pod-uri care constituie un serviciu este gasit,este referit, prin cautarea pe baza (unui ID special), a unei etichete. [16] Kubernetes oferă două moduri de descoperire a serviciului , folosind variabile de mediu sau utilizând un serviciu de nume: Kubernetes DNS. [20] Ca urmare a unei cereri catre Kubernets DNS, atunci cand se cauta un serviciu,obtinem o adresă IP stabilă și un nume DNS al serviciului. Kubernets asigura o incarcare echilibrata a retelei cu un algoritm round-robin, care parcurge circular mai multe pod-uri marcate cu aceeasi eticheta (ID), in mod transparent relativ la mutarea pod-ului de pe o masina de calcul pe alta (chiar dacă un eveniment determină mutarea pod-ului cautat de la o mașină la alta mașină !). [18] În mod traditional, un serviciu este oferit în interiorul unui cluster (de exemplu, modulele din [[backend]], pot fi grupate într-un serviciu, iar cererile din partea front-end-urilor sunt echilibrate între ele), dar un serviciu poate fi furnizat și în afara unui cluster astfel clientii accesand direct pod-urile care ofera servicii directe utilizatorilor, acele pod-uri din frontend). [21]

Unitatile de stocare (eng. volumele)[modificare | modificare sursă]

Sistemele de fișiere din containerul Kubernetes asigură stocarea temporară, în mod implicit. Aceasta înseamnă că o repornire a containerului va șterge orice date și, prin urmare, această formă de stocare este destul de limitantă în orice aplicații decât cele triviale. Un volum Kubernetes oferă o stocare persistentă care există pentru întreaga viață a pod-ului. Acest spațiu de stocare poate fi, de asemenea, utilizat ca spațiu de stocare pe disc de catre /pentru (?) containerele din interiorul podului. Volumele sunt montate in anumite puncte de montare din container, care sunt definite de configurația de pod, și unde nu se pot monta alte volume sau nu se leagă, nu se pot face link-uri la alte volume. Același volum poate fi montat în diferite puncte din arborele sistemului de fișiere dar de catre containere diferite.

Spații de nume[modificare | modificare sursă]

Kubernetes oferă o împărțire a resurselor pe care le gestionează în seturi care nu se suprapun, numite spații de nume. Acestea sunt destinate utilizării în medii cu mulți utilizatori răspândiți în mai multe echipe sau proiecte, sau chiar separând medii precum dezvoltarea, testarea și producția.

Gestionarea obiectelor Kubernetes[modificare | modificare sursă]

Kubernetes oferă câteva mecanisme care vă permit să-i gestionați, să selectați sau să manipulați obiectele.

Etichete și selectori[modificare | modificare sursă]

Kubernetes permite clienților (utilizatori sau componente interne) să atașeze perechi cheie-valoare numite "etichete" la orice obiect API din sistem, cum ar fi pod-uri și noduri .

În mod corespunzător, "selectorii de etichete" sunt interogări care prezinta etichete pentru a afla pe baza lor care sunt obiectele cautate. [16]

Când este definit un serviciu, se pot defini selectorii de etichete care vor fi utilizați de routerul de serviciu / balancer-ul de încărcare pentru a selecta cazurile în care va fi direcționat traficul. Astfel, schimbarea pur și simplu a etichetelor de pe pod-uri sau schimbarea selectorilor de etichete în cadrul serviciului pot fi folosite pentru a controla traficul, pentru a decide care dintre pod-uri primeste apelul si care nu, care pot fi folosite pentru a participa la diverse modele de deployment , cum ar fi metoda "albastru-verde" sau testarea A-B . Această capacitate de a controla dinamic modul în care serviciile utilizează resursele, oferă asa zisa cuplare "loose", flexibila, cu infrastructura.

De exemplu, dacă pod-urile unei aplicații au etichete pentru un tier sistem (cu valori cum ar fi front-end , back-end , de exemplu) și un release_track (cu valori cum ar fi canary , production , de exemplu) din nodurile back-end și canary pot utiliza un selector de etichete, cum ar fi: [22]

tier=back-end AND release_track=canary

Selectori de câmp[modificare | modificare sursă]

La fel ca etichetele, selectorii de câmp vă permit de asemenea să selectați resursele Kubernetes. Spre deosebire de etichete, selecția se bazează pe valorile atributului inerent resurselor selectate, mai degrabă decât pe categorii definite de utilizator. metadata.name și metadata.namespace sunt selectori de câmpuri care vor fi prezenți pe toate obiectele Kubernetes. Alți selectori care pot fi utilizați depind de tipul obiectului / resursei.

Arhitectură[modificare | modificare sursă]

Kubernetes: diagramă de arhitectură

Kubernetes foloseste o arhitectura master-slave . Componentele Kubernetes pot fi împărțite în cele care gestionează un nod individual și cele care fac parte din panoul de control. [16] [23]

Panoul de control Kubernetes (master)[modificare | modificare sursă]

Masterul Kubernetes este principala unitate de control a grupului, gestionând incarcarea și direcționând comunicarea în sistem. Panoul de comandă Kubernetes constă din diferite componente, fiecare fiind propriu proces, care poate funcționa atât pe un singur nod principal, cât și pe mai mulți master-i care susțin clusterele cu disponibilitate ridicată . [23] Diferitele componente ale planului de control Kubernetes sunt următoarele:

  • etc.d: etcd [24] este un magazin de date durabil, ușor, distribuit, cu valoare cheie, dezvoltat de CoreOS, care stochează în mod fiabil datele de configurare ale clusterului, reprezentând starea globală a clusterului în orice moment dat. La fel ca Apache ZooKeeper , etc.d este un sistem care favorizează Coerența față de Disponibilitate în cazul unei partiții de rețea (vezi teorema CAP ). Această coerență este esențială pentru planificarea corectă și pentru funcționarea serviciilor. Serverul API Kubernetes folosește API-ul ceasului pentru a monitoriza clusterul și a lansa modificări de configurare critice sau a restabili pur și simplu orice divergențe ale stării cluster-ului, înapoi la ceea ce a fost declarat de către deployer. De exemplu, dacă deployerul a specificat că trei instanțe ale unui pod particular trebuie să fie difuzate, acest fapt este stocat în etcd. Dacă se constată că doar două instanțe sunt difuzate, aceasta diferenta va fi detectata prin comparație cu datele etc.d, iar Kubernetes va folosi acest lucru pentru a programa crearea unei instanțe suplimentare a acestui pod. [23]
  • Server API: Serverul API este o componentă cheie și servește API-ul Kubernetes utilizând JSON over HTTP , care oferă servicii atât pe interfața internă, cât și cea externă a Kubernetes. [16] [25] Serverul API procesează și validează cererile REST și actualizează starea obiectelor API în etcd , permițând astfel clienților să configureze încărcările de lucru și containerele în nodurile Worker. [26]
  • Planificator: Planificatorul este componenta care selectează pe care nod se execută un pod neprogramat (entitatea de bază gestionată de programator), pe baza disponibilității resurselor. Programatorul urmărește utilizarea resurselor pe fiecare nod pentru a se asigura că incarcarea nu este programata în exces față de resursele disponibile. În acest scop, planificatorul trebuie să cunoască cerințele de resurse, disponibilitatea resurselor și alte constrângeri și directive de politică furnizate de utilizator, cum ar fi cerințele de calitate a serviciului, cerințele de afinitate / afinitate, localizarea datelor și așa mai departe. În esență, rolul planificatorului este acela de a potrivi resursa cu "cererea" de procesare. [27]
  • Manager de controlere: Un controler este o buclă de feedback care conduce starea actuală a cluster-ului către starea de cluster dorită. [28] Aceasta face acest lucru prin gestionarea unui set de controleri. Un tip aparte de controler este un controler de replicare, care gestionează replicarea și scalarea, executând un anumit număr de copii ale unui pod peste cluster. De asemenea, se ocupă de crearea de pod-uri de înlocuire dacă nodul de bază nu reușește. [28] Alți controlori care fac parte din sistemul central Kubernetes includ un "DaemonSet Controller" pentru a rula exact câte un pod pe fiecare mașină (sau un anumit subset de mașini) și un "Job Controller" pentru rularea modulelor care rulează până la finalizare, de exemplu ca parte dintr-o activitate batch. [29] Setul de pod-uri pe care un controler le gestionează este determinat de selectorii de etichete care fac parte din definiția controlerului. [22]
Managerul de controler este un proces care execută controale Kubernetes de bază, cum ar fi DaemonSet Controller și Controllere de replicare (Replication Controller.). Controlerii comunică cu serverul API pentru a crea, actualiza și șterge resursele pe care le administrează (pod-uri, puncte finale de serviciu etc. ). [25]

Nodul Kubernetes[modificare | modificare sursă]

Nodul, cunoscut și sub numele de Worker sau Minion, este o mașină în care se desfășoară containere (încărcări de lucru). Fiecare nod din cluster trebuie să ruleze un runtime de container, cum ar fi Docker , precum și componentele mai sus menționate, pentru a comunica cu master-ul despre sau in scopul configurarii rețelei acestor containere.

  • Kubelet: Kubelet este responsabil pentru starea de funcționare a fiecărui nod, asigurându-se că toate containerele din nod sunt functionale. El are grijă de pornirea, oprirea și menținerea containerelor de aplicație organizate în pod-uri, conform instrucțiunilor din panoul (planul ?) de control. [16] [30]
Kubelet monitorizează starea unui pod, iar dacă nu este în starea dorită, podul se re-implementează la același nod. Starea nodului este transmisă la fiecare câteva secunde prin mesaje periodice comandantului. Odată ce comandantul detectează un eșec al nodului, controlerul de replicare observă această schimbare de stare și lansează pod-uri pe alte noduri functionale.  
  • Kube-proxy: proxy-ul Kube este o implementare a proxy-ului de rețea și a unui echilibrator de sarcină și susține abstractizarea serviciului împreună cu alte operațiuni de rețea. [16] Acesta este responsabil pentru rutarea traficului la containerul corespunzător, pe baza numărului de IP și de port al cererii de intrare.
  • Runtime-ul unui container: un container se află în interiorul unui pod. Conteinerul este nivelul cel mai de jos al unui microserviciu care ține aplicația afalat în execuție, bibliotecile și dependențele lor. Containerele pot fi expuse lumii printr-o adresă IP externă. Kubernetes permite folosirea containerelor Docker încă de la prima versiune, iar în iulie 2016 a fost adăugat motorul de containere rkt . [31]

Add-on - uri[modificare | modificare sursă]

Add-on-urile funcționează la fel ca orice altă aplicație care rulează în cluster: acestea sunt implementate prin intermediul pod-urilor și serviciilor și sunt diferite numai prin faptul că implementează caracteristici ale clusterului Kubernetes. Pod-urile pot fi gestionate de Deployments, ReplicationControllers și așa mai departe. Există multe add-on-uri, iar lista este în creștere. Unele dintre cele mai importante sunt:

  • DNS: toate grupurile Kubernetes ar trebui să aibă DNS de cluster; este o caracteristică obligatorie. Cluster DNS este un server DNS, pe lângă celelalte servere DNS din mediul dvs., care servește înregistrări DNS pentru serviciile Kubernetes. Containerele inițiate de Kubernetes includ automat acest server DNS în căutările DNS.
  • Web UI: Acesta are un scop genera: interfață web pentru clustere Kubernetes. Acesta permite utilizatorilor să gestioneze și să depaneze aplicațiile care rulează în cluster, precum și clusterul propriu-zis.
  • Container Resource Monitoring: asigurarea unei durate de execuție fiabile a aplicațiilor și posibilitatea de a le scala în sus sau în jos ca răspuns la încărcările de lucru înseamnă a fi în măsură să monitorizeze continuu și performanța încărcării cu lucru. Container Resource Monitoring oferă această capacitate prin înregistrarea de valori privind containerele într-o bază de date centrală și oferă o interfață utilizator pentru aceste date. CAdvisor este o componentă a unui nod slave care oferă o capacitate limitată de monitorizare a metricilor. Există și metrici complete, cum ar fi Prometheus, care pot satisface cele mai multe nevoi de monitorizare.
  • Logarea la nivel de cluster: jurnalul trebuie să aibă o stocare in locatie separată și un ciclu de viață independent de noduri, păstăi sau recipiente. În caz contrar, defecțiunile de nod sau de pod pot duce la pierderea datelor despre evenimente. Abilitatea de a face acest lucru se numește logging la nivel de cluster și astfel de mecanisme sunt responsabile pentru salvarea jurnalelor de la containere într-o baza de date centrala cu jurnal si cu interfață de căutare / navigare. Kubernetes nu oferă o soluție de stocare nativă pentru datele din jurnale, dar se pot integra multe soluții de logare existente în clusterul Kubernetes.

Microservicii[modificare | modificare sursă]

Kubernetes este frecvent utilizat ca o modalitate de a găzdui o implementare bazată pe microservicii, deoarece aceasta și ecosistemul asociat de instrumente oferă toate capabilitățile necesare pentru a aborda preocupările cheie ale oricărei arhitecturi de microserviciu .

Vezi si[modificare | modificare sursă]

  • OpenShift
  • Jenkins

Referințe[modificare | modificare sursă]

  1. ^ „First GitHub commit for Kubernetes”. github.com. . Arhivat din originalul de la . 
  2. ^ „GitHub Releases page”. github.com. . 
  3. ^ a b c „What is Kubernetes?”. Kubernetes. Accesat în . 
  4. ^ „kubernetes/kubernetes”. GitHub (în engleză). Arhivat din original la . Accesat în . 
  5. ^ https://kubernetes.io/blog/2018/10/10/kubernetes-v1.12-introducing-runtimeclass/
  6. ^ „Google Made Its Secret Blueprint Public to Boost Its Cloud” (în engleză). Arhivat din original la . Accesat în . 
  7. ^ „Google Open Sources Its Secret Weapon in Cloud Computing”. Wired. Arhivat din original la . Accesat în . 
  8. ^ a b Abhishek Verma; Luis Pedrosa; Madhukar R. Korupolu; David Oppenheimer; Eric Tune; John Wilkes (). „Large-scale cluster management at Google with Borg”. Proceedings of the European Conference on Computer Systems (EuroSys). Arhivat din original la . 
  9. ^ „Borg, Omega, and Kubernetes - ACM Queue”. queue.acm.org. Arhivat din original la . Accesat în . 
  10. ^ „Early Stage Startup Heptio Aims to Make Kubernetes Friendly”. Accesat în . 
  11. ^ „As Kubernetes Hits 1.0, Google Donates Technology To Newly Formed Cloud Native Computing Foundation”. TechCrunch. Arhivat din original la . Accesat în . 
  12. ^ „Cloud Native Computing Foundation”. Arhivat din original la . 
  13. ^ Conway, Sarah. „Kubernetes Is First CNCF Project To Graduate”. Cloud Native Computing Foundation (în engleză). Arhivat din original (html) la . Accesat în . Compared to the 1.5 million projects on GitHub, Kubernetes is No. 9 for commits and No. 2 for authors/issues, second only to Linux. 
  14. ^ Sharma, Priyanka (). „Autoscaling based on CPU/Memory in Kubernetes—Part II”. Powerupcloud Tech Blog. Medium. Accesat în . 
  15. ^ „Configure Kubernetes Autoscaling With Custom Metrics”. Bitnami. BitRock. . Accesat în . 
  16. ^ a b c d e f g h i „An Introduction to Kubernetes”. DigitalOcean. Arhivat din original la . Accesat în . 
  17. ^ https://kubernetes.io/docs/concepts/workloads/pods/pod/
  18. ^ a b Langemak, Jon (). „Kubernetes 101 – Networking”. Das Blinken Lichten. Arhivat din original la . Accesat în . 
  19. ^ Strachan, James (). „Kubernetes for Developers”. Medium (publishing platform). Arhivat din original la . Accesat în . 
  20. ^ https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
  21. ^ Langemak, Jon (). „Kubernetes 101 – External Access Into The Cluster”. Das Blinken Lichten. Arhivat din original la . Accesat în . 
  22. ^ a b „Intro: Docker and Kubernetes training - Day 2”. Red Hat. . Arhivat din original la . Accesat în . 
  23. ^ a b c „Kubernetes Infrastructure”. OpenShift Community Documentation. OpenShift. Arhivat din original la . Accesat în . 
  24. ^ Container Linux de către CoreOS: Infrastructură Cluster
  25. ^ a b Marhubi, Kamal (). „Kubernetes from the ground up: API server”. kamalmarhubi.com. Arhivat din original la . Accesat în . 
  26. ^ Ellingwood, Justin (). „An Introduction to Kubernetes”. DigitalOcean (în engleză). Arhivat din original la . Accesat în . One of the most important master 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. 
  27. ^ „The Three Pillars of Kubernetes Container Orchestration - Rancher Labs”. rancher.com. . Arhivat din original la . Accesat în . 
  28. ^ a b „Overview of a Replication Controller”. Documentation. CoreOS. Arhivat din original la . Accesat în . 
  29. ^ Sanders, Jake (). „Kubernetes: Exciting Experimental Features”. Livewyer. Arhivat din original la . Accesat în . 
  30. ^ Marhubi, Kamal (). „What [..] is a Kubelet?”. kamalmarhubi.com. Arhivat din original la . Accesat în . 
  31. ^ https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/

linkuri externe[modificare | modificare sursă]