Kubernetes

Kubernetes
Autor inițial	Google
Dezvoltator	Cloud Native Computing Foundation
Versiune inițială	iunie 7, 2014 (2014-06-07)
Ultima versiune	1.14 (martie 25, 2019 (2019-03-25))
Repo	github.com/kubernetes/kubernetes
Scris în	Go
Sistem de operare	Linux Microsoft Windows macOS
Tip	Cluster management software
Licență	Apache License 2.0
Prezență online
kubernetes.io

Kubernetes (în mod obișnuit prescurtat ca k8s ) este un sistem de gestionare a containerelor open source pentru automatizarea implementării, scalării și distribuirii aplicațiilor. 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". Funcționează cu o gamă largă de unelte pentru containerizare, inclusiv cu [[Docker]] . 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

Prezentare despre Google Container Engine la Google Cloud Summit

Kubernetes ( κυβερνήτης , termen grecesc pentru "guvernator", "cârmaci" sau "căpitan") a fost fondat de o echipă formată de Joe Beda, Brendan Burns și Craig MCLUCKIE, , la care s-au alăturat rapid alți ingineri Google, inclusiv Brian Grant și Tim Hockin, și a fost prezentat pentru prima dată de Google la mijlocul anului 2014. Dezvoltarea și designul său sunt puternic influențate de sistemul Google Borg ș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". 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 ++ , dar sistemul Kubernetes rescris este implementat în limbajul Go .

Kubernetes v1.0 a fost lansat pe 21 iulie 2015. Alături de versiunea Kubernetes v1.0, Google a colaborat cu Fundația Linux pentru a forma Cloud Native Computing Foundation (CNCF) ș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 doilea între autorii și problemele legate de kernel-ul Linux .

Obiectele Kubernetes

Kubernetes definește un set de blocuri de construcție ("primitivele" bazate pe CPU, memorie sau resurse specifice. ), care oferă împreună 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. . 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)

Pentru a gestiona similar mai multe resurse asemănătoare, Kubernets definește conceptul de bază numit pod. (Imaginați-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 în același pod a componentelor containerizate. Deci, un pod constă dintr-unul sau mai multe containere care sunt garantate a fi co-localizate pe mașina gazdă și pot partaja resurse.

Fiecare pod din Kubernetes beneficiază de o adresă unică (dar temporară pe durata rulării fără 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. În interiorul pod-ului, toate containerele se pot accesa unele pe altele pe același 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 decât al său; pentru aceasta, trebuie să utilizeze adresa IP a interfeței 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 funcții dintr-un anume alt pod, deoarece aceste adrese IP de Pod sunt temporare - acea adresa poate ajunge să fie a unui cu totul alt Pod după 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 căutat.

Un pod poate include o unitate de stocare, cum ar fi un director de disc local sau un disc de rețea, și îl oferă la dispoziția tuturor containerelor din acel pod. Pod-urile pot fi gestionate manual prin API-ul Kubernetes sau administrarea lor poate fi delegată unui [[controller]]. În Kubernetes astfel de unități de stocare sunt, de asemenea unități elementare ale sistemului de gestiune a drepturilor asupra configurației, numit ConfigMaps and Secrets. Kubernets permite alocarea de drepturi de acces la aceste volume sau unități de stocare date (oarecum asemănător cu drepturile de acces la serverele Novell sau volumele Unix) astfel încât numai cei autorizați sau serviciile soft autorizate să poată accesa aceste unități de stocare.

Serviciile

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 găsit/ este referit, prin căutarea pe baza (unui ID special), a unei etichete. Kubernetes oferă două moduri de descoperire a serviciului, folosind variabile de mediu sau utilizând un serviciu de nume: Kubernetes DNS. Ca urmare a unei cereri către Kubernets DNS, atunci când se caută un serviciu, obținem o adresă IP stabilă și un nume DNS al serviciului. Kubernets asigură o încărcare echilibrată a rețelei cu un algoritm round-robin, care parcurge circular mai multe pod-uri marcate cu aceeași etichetă (ID), în mod transparent relativ la mutarea pod-ului de pe o mașină de calcul pe alta (chiar dacă un eveniment determină mutarea pod-ului căutat de la o mașină la altă mașină!). În mod tradițional, 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 clienții accesând direct pod-urile care oferă servicii directe utilizatorilor, acele pod-uri din frontend).

Unitatile de stocare (eng. volumele)

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 limitativă în orice alte 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 către /pentru (?) containerele din interiorul podului. Volumele sunt montate în 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 către containere diferite.

Spații de nume

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

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

Etichete și selectori

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 prezintă etichete pentru a afla pe baza lor care sunt obiectele căutate.

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 primește apelul și 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ă așa-zisa cuplare "loose", flexibilă, 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:

tier=back-end AND release_track=canary

Selectori de câmp

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ă

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.

Panoul de control Kubernetes (master)

Masterul Kubernetes este principala unitate de control a grupului, gestionând încărcarea și direcționând comunicarea în sistem. Panoul de comandă Kubernetes constă din diferite componente, fiecare fiind propriul 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ă. Diferitele componente ale planului de control Kubernetes sunt următoarele:

• etc.d: etcd 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 pentru 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 diferență va fi detectată prin comparație cu datele etc.d, iar Kubernetes va folosi acest lucru pentru a programa crearea unei instanțe suplimentare a acestui pod.

• 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. 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.

• 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ă încărcarea nu este programată î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.

• Manager de controlere: Un controler este o buclă de feedback care conduce starea actuală a cluster-ului către starea de cluster dorită. Aceasta face acest lucru prin gestionarea unui set de controlori. 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. 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. Setul de pod-uri pe care un controler le gestionează este determinat de selectorii de etichete care fac parte din definiția controlerului.

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.).

Nodul Kubernetes

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 în scopul configurării 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 funcționale. 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.

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 funcționale.  

• 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. 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 aflată î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.

Add-on - uri

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 general: interfață web pentru clustere Kubernetes. El 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

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

• OpenShift
• Jenkins

Legături externe

• Site web oficial
• Codul sursă pe GitHub