Ce este arhitectura Kubernetes? Importanță + Cele mai bune practici

Kubernetes a cunoscut o creștere extraordinară în ceea ce privește adoptarea sa din 2014. Inspirat de soluția internă de gestionare a clusterelor de la Google, Borg, Kubernetes simplifică implementarea și administrarea aplicațiilor dvs. La fel ca toate programele de orchestrare a containerelor , Kubernetes devine popular printre profesioniștii IT, deoarece este sigur și simplu. Cu toate acestea, ca în cazul oricărui instrument, recunoașterea modului în care arhitectura acestuia vă ajută să îl utilizați mai eficient.

Să învățăm despre bazele arhitecturii Kubernetes, începând cu ce este, ce face și de ce este semnificativă.

Google a creat sistemul adaptabil de gestionare a containerelor Kubernetes, care gestionează aplicațiile containerizate în mai multe setări. Ajută la automatizarea implementării aplicațiilor containerizate, la efectuarea modificărilor și la scalarea sus și în jos a acestor aplicații.

Totuși, Kubernetes nu este doar un orchestrator de containere . În același mod, aplicațiile desktop funcționează pe MacOS, Windows sau Linux; este sistemul de operare pentru aplicațiile native din cloud, deoarece servește drept platformă cloud pentru acele programe.

Ce este un container?

Containerele sunt o abordare standard pentru ambalarea aplicațiilor și a dependențelor acestora, astfel încât aplicațiile să poată fi executate cu ușurință în medii de rulare. Folosind containere, puteți lua măsuri esențiale pentru reducerea timpului de implementare și creșterea fiabilității aplicației, împachetând codul, dependențele și configurațiile unei aplicații într-un singur bloc de construcție ușor de utilizat.

Numărul de containere din aplicațiile corporative poate deveni imposibil de gestionat. Pentru a profita la maximum de containerele dvs., Kubernetes vă ajută să le orchestrați.

Pentru ce este folosit Kubernetes?

Kubernetes este o platformă incredibil de adaptabilă și extensibilă pentru rularea încărcăturilor de lucru ale containerelor. Platforma Kubernetes nu oferă doar mediul pentru a crea aplicații native în cloud, dar ajută și la gestionarea și automatizarea implementărilor acestora.

Acesta își propune să scutească operatorii de aplicații și dezvoltatorii de efortul de coordonare a infrastructurii de calcul, de rețea și de stocare de bază, permițându-le să se concentreze exclusiv pe procesele centrate pe container pentru operarea cu autoservire. Dezvoltatorii pot crea, de asemenea, proceduri specializate de implementare și gestionare, împreună cu niveluri superioare de automatizare pentru aplicațiile formate din mai multe containere.

Kubernetes poate gestiona toate sarcinile de lucru backend semnificative, inclusiv aplicații monolitice, programe fără stat sau cu stare, microservicii, servicii, joburi batch și tot ce se află între ele.

Kubernetes este adesea ales pentru următoarele beneficii.

• Infrastructura Kubernetes este superioară celei a multor tehnologii DevOps.
• Kubernetes descompune containerele în componente mai mici pentru un management precis.
• Kubernetes implementează actualizări de software rapid și regulat.
• Kubernetes oferă o platformă pentru dezvoltarea de aplicații cloud-native.

Arhitectura și componentele Kubernetes

Arhitectura de bază Kubernetes cuprinde multe componente, cunoscute și sub denumirea de componente K8s, așa că înainte de a trece direct, este important să ne amintim următoarele concepte.

• Arhitectura de bază Kubernetes constă dintr-un plan de control care gestionează noduri și noduri de lucru care execută aplicații containerizate.
• În timp ce planul de control gestionează execuția și comunicarea, nodurile de lucru rulează de fapt aceste containere.
• Un cluster Kubernetes este un grup de noduri, iar fiecare cluster are cel puțin un nod de lucru.

Diagrama arhitecturii Kubernetes

Planul de control Kubernetes

Planul de control este centrul sistemului nervos central al designului clusterului Kubernetes, adăpostind componentele de control ale clusterului. De asemenea, înregistrează configurația și starea tuturor obiectelor Kubernetes din cluster.

Planul de control Kubernetes menține o comunicare regulată cu unitățile de calcul pentru a se asigura că clusterul funcționează conform așteptărilor. Controllerele supraveghează stările obiectelor și fac obiectele sistemului fizic, starea observată sau starea curentă pentru a se potrivi stării sau specificațiilor dorite ca răspuns la modificările clusterului.

Planul de control este alcătuit din mai multe elemente esențiale, inclusiv serverul de interfață de programare a aplicației (API), planificatorul, managerul controlerului și etc. Aceste componente fundamentale Kubernetes garantează că containerele rulează cu resurse adecvate. Toate aceste componente pot funcționa pe un singur nod primar, dar multe companii le dublează pe mai multe noduri pentru o disponibilitate ridicată.

1. Server API Kubernetes

Serverul API Kubernetes este partea frontală a planului de control Kubernetes. Facilitează actualizările, scalarea, configurarea datelor și alte tipuri de orchestrare a ciclului de viață, oferind management API pentru diverse aplicații. Deoarece serverul API este gateway-ul, utilizatorii trebuie să-l poată accesa din afara clusterului. În acest caz, serverul API este un tunel către poduri, servicii și noduri. Utilizatorii se autentifică prin serverul API.

2. Programator Kubernetes

Kube-scheduler înregistrează statisticile de utilizare a resurselor pentru fiecare nod de calcul, evaluează dacă un cluster este sănătos și decide dacă și unde ar trebui să fie implementate containere noi. Planificatorul evaluează starea generală de sănătate a clusterului și cerințele de resurse ale podului, cum ar fi unitatea centrală de procesare (CPU) sau memoria. Apoi alege un nod de calcul adecvat și programează sarcina, podul sau serviciul, luând în considerare constrângerile sau asigurările de resurse, localitatea datelor, cerințele de calitate a serviciului, standardele anti-afinitate sau afinitate.

3. Manager de controler Kubernetes

Într-un mediu Kubernetes, mai multe controlere guvernează stările punctelor finale (pod-uri și servicii), token-urile și conturile de serviciu (spații de nume), nodurile și replicarea (autoscaling). Managerul kube-controller, adesea cunoscut sub numele de manager de controler cloud sau doar controler, este un demon care gestionează cluster-ul Kubernetes prin îndeplinirea diferitelor sarcini de controler.

Controlerul monitorizează obiectele din cluster în timp ce rulează buclele de control de bază Kubernetes. Îi monitorizează pentru stările dorite și existente prin serverul API. Dacă stările curente și cele dorite ale obiectelor gestionate nu se potrivesc, controlerul ia măsuri corective pentru a muta starea obiectului mai aproape de starea dorită. Controlerul Kubernetes se ocupă și de sarcinile esențiale ale ciclului de viață.

4. etcd

etcd este o bază de date de stocare cheie-valoare distribuită, tolerantă la erori, care păstrează datele de configurare și informațiile despre starea clusterului. Deși etcd poate fi configurat independent, adesea servește ca parte a planului de control Kubernetes.

Algoritmul de consens de plută este utilizat pentru a menține starea clusterului în etcd. Acest lucru ajută la rezolvarea unei probleme tipice în contextul mașinilor de stat replicate și necesită ca multe servere să convină asupra valorilor. Raft stabilește trei roluri: lider, candidat și adept și creează consens prin votul pentru un lider.

Drept urmare, etcd este sursa unică de adevăr (SSOT) pentru toate componentele clusterului Kubernetes, răspunzând la interogările planului de control și colectând diferite informații despre starea containerelor, nodurilor și podurilor. etcd este, de asemenea, folosit pentru a stoca informații de configurare, cum ar fi ConfigMaps, subrețele, secrete și datele de stare ale clusterului.

Nodurile de lucru Kubernetes

Nodurile de lucru sunt sisteme care rulează containere pe care le gestionează planul de control. Kubelet – controlerul de bază Kubernetes – rulează pe fiecare nod ca agent pentru interacțiunea cu planul de control. În plus, fiecare nod rulează un motor de rulare a containerului, cum ar fi Docker sau rkt. Alte componente pentru monitorizare, înregistrare în jurnal, descoperire de servicii și accesorii opționale sunt, de asemenea, rulate pe nod.

Unele componente cheie ale arhitecturii cluster Kubernetes sunt următoarele.

Noduri

Un cluster Kubernetes trebuie să aibă cel puțin un nod de calcul, dar poate avea mult mai multe, în funcție de cerințele de capacitate. Deoarece pod-urile sunt coordonate și programate să se execute pe noduri, sunt necesare noduri suplimentare pentru a crește capacitatea clusterului. Nodurile fac munca unui cluster Kubernetes. Acestea leagă aplicațiile, precum și resursele de rețea, de calcul și de stocare.

Nodurile din centrele de date pot fi mașini virtuale (VM) native din cloud sau servere bare metal.

Motor de rulare a containerului

Fiecare nod de calcul folosește un motor de rulare a containerului pentru a opera și gestiona ciclurile de viață ale containerului. Kubernetes acceptă timpi de execuție conforme cu inițiativa containerului deschis, cum ar fi Docker, CRI-O și rkt.

Serviciul Kubelet

Un kubelet este inclus pe fiecare nod de calcul. Este un agent care comunică cu planul de control pentru a garanta că containerele dintr-un pod funcționează. Când planul de control solicită ca o anumită acțiune să fie efectuată într-un nod, kubelet-ul primește specificațiile podului prin serverul API și funcționează. Apoi se asigură că containerele aferente sunt în stare bună de funcționare.

Serviciul Kube-proxy

Fiecare nod de calcul are un proxy de rețea cunoscut sub numele de kube-proxy, care ajută serviciile de rețea Kubernetes. Pentru a gestiona conexiunile de rețea în interiorul și în afara clusterului, kube-proxy fie redirecționează traficul, fie depinde de stratul de filtrare a pachetelor al sistemului de operare.

Procesul kube-proxy operează pe fiecare nod pentru a se asigura că serviciile sunt disponibile pentru alte părți și pentru a face față unei anumite subrețele gazdă. Acesta acționează ca un proxy de rețea și echilibrator de sarcină a serviciului pe nodul său, gestionând rutarea rețelei pentru protocolul de datagramă utilizator (UDP) și protocolul de control al transmisiei (TCP). Kube-proxy, în realitate, direcționează traficul pentru toate punctele finale de serviciu.

Păstăi

Până acum, am acoperit idei interne și legate de infrastructură. Cu toate acestea, podurile sunt esențiale pentru Kubernetes, deoarece sunt principalele componente orientate spre exterior cu care interacționează dezvoltatorii.

Un pod este cea mai simplă unitate din modelul containerului Kubernetes, reprezentând o singură instanță a unei aplicații. Fiecare pod cuprinde un container sau mai multe containere strâns legate care se potrivesc logic și îndeplinesc regulile care guvernează funcția containerului.

Podurile au o durată de viață limitată și mor în cele din urmă după ce au fost modernizate sau reduse. Deși efemere, ele execută aplicații cu stare prin conectarea la stocarea persistentă.

Podurile se pot scala și pe orizontală, ceea ce înseamnă că pot crește sau reduce numărul de instanțe care funcționează. Ei sunt, de asemenea, capabili să facă actualizări progresive și implementări Canary.

Pod-urile funcționează împreună pe noduri, astfel încât partajează conținut și stocare și pot comunica cu alte pod-uri prin localhost. Containerele pot cuprinde mai multe computere, la fel și podurile. Un singur nod poate opera mai multe poduri, fiecare colectând numeroase containere.

Podul este unitatea centrală de management din ecosistemul Kubernetes, servind drept graniță logică pentru containerele care împart resurse și context. Metoda de grupare a podului, care permite mai multor procese dependente să funcționeze concomitent, atenuează diferențele dintre virtualizare și containerizare.

Alte componente ale arhitecturii Kubernetes

Kubernetes menține containerele unei aplicații, dar poate gestiona și datele aplicației asociate într-un cluster. Utilizatorii Kubernetes pot solicita resurse de stocare fără a înțelege infrastructura de stocare de bază.

Un volum Kubernetes este un director în care un pod poate accesa și stoca date. Tipul de volum determină conținutul volumului, cum a apărut și suportul media care îl acceptă. Volumele persistente (PV) sunt resurse de stocare specifice clusterului furnizate adesea de un administrator. De asemenea, PV-urile pot supraviețui unui anumit pod.

Kubernetes depinde de imaginile containerului , care sunt stocate într-un registru de containere . Poate fi un registru al unei terțe părți sau unul creat de organizație.

Spațiile de nume sunt clustere virtuale care există într-un cluster fizic. Sunt concepute pentru a crea medii de lucru independente pentru numeroși utilizatori și echipe. De asemenea, împiedică echipele să interfereze între ele prin restricţionarea obiectelor Kubernetes pe care le pot accesa. Containerele Kubernetes dintr-un pod pot comunica cu alte poduri prin localhost și pot partaja adrese IP și spații de nume de rețea.

Kubernetes vs. Docker Swarm

Atât Kubernetes, cât și Docker sunt platforme care asigură managementul containerelor și scalarea aplicațiilor. Kubernetes oferă o soluție eficientă de gestionare a containerelor, ideală pentru aplicațiile cu cerere mare, cu o configurare complicată. În schimb, Docker Swarm este construit pentru simplitate, făcându-l o alegere excelentă pentru aplicațiile esențiale care sunt rapid de implementat și întreținut.

• Docker Swarm este mai ușor de implementat și configurat decât Kubernetes.
• Kubernetes oferă scalabilitate all-in-one bazată pe trafic, în timp ce Docker Swarm prioritizează scalarea rapidă.
• Echilibrarea automată a sarcinii este disponibilă în Docker Swarm, dar nu și în Kubernetes. Cu toate acestea, soluțiile terță parte pot conecta un echilibrator de încărcare extern la Kubernetes.

Cerințele companiei dumneavoastră determină instrumentul potrivit.

Soluții de orchestrare a containerelor

Sistemele de orchestrare a containerelor le permit dezvoltatorilor să lanseze mai multe containere pentru implementarea aplicațiilor. Managerii IT pot folosi aceste platforme pentru a automatiza administrarea instanțelor, aprovizionarea gazdelor și conectarea containerelor.

Următoarele sunt unele dintre cele mai bune instrumente de orchestrare a containerelor care facilitează implementarea, identifică implementările de containere eșuate și gestionează configurațiile aplicațiilor.

Cele mai bune practici de arhitectură Kubernetes și principii de proiectare

Implementarea unei strategii de platformă care să ia în considerare securitatea, guvernanța, monitorizarea, stocarea, rețea, managementul ciclului de viață al containerului și orchestrarea este esențială. Cu toate acestea, Kubernetes este o provocare pe scară largă de adoptat și scalat, în special pentru companiile care gestionează atât infrastructura locală, cât și cea publică de cloud. Pentru a simplifica, sunt discutate mai jos câteva dintre cele mai bune practici care trebuie luate în considerare atunci când se construiesc clustere kubernetes.

• Asigurați-vă că aveți întotdeauna cea mai recentă versiune de Kubernetes.
• Investește în formarea echipelor de dezvoltare și operaționale.
• Stabiliți guvernanța la nivel de companie . Asigurați-vă că instrumentele și furnizorii dvs. sunt compatibile cu orchestrarea Kubernetes.
• Creșteți securitatea prin includerea tehnicilor de scanare a imaginilor în fluxul dvs. de lucru de integrare și livrare continuă (CI/CD). Codul open source descărcat dintr-un depozit GitHub trebuie tratat întotdeauna cu prudență.
• Implementați controlul accesului bazat pe rol (RBAC) în întregul cluster. Modelele bazate pe cel mai mic privilegiu și încredere zero ar trebui să fie norma.
• Utilizați numai utilizatori non-root și faceți sistemul de fișiere doar în citire pentru a proteja mai mult containerele.
• Evitați valorile implicite, deoarece declarațiile simple sunt mai puțin predispuse la erori și comunică mai bine scopul.
• Când utilizați imagini de bază Docker Hub, fiți precaut, deoarece acestea pot include programe malware sau pot fi umflate cu cod inutil. Începeți cu un cod lean, clean și mergeți în sus. Imaginile mai mici cresc mai repede, ocupă mai puțin spațiu de stocare și extrage imagini mai rapid.
• Păstrați recipientele cât mai simple posibil. Un proces per container permite orchestratorului să raporteze dacă acel proces este sau nu sănătos.
• Prăbușire când aveți îndoieli. Nu reporniți în caz de defecțiune, deoarece Kubernetes va reporni un container defect.
• Fii descriptiv . Etichetele descriptive beneficiază dezvoltatorii prezenti și viitori.
• Când vine vorba de microservicii, nu fi prea specific . Fiecare funcție dintr-o componentă de cod logic nu trebuie să fie microserviciu.
• Acolo unde este posibil, automatizați . Puteți sări peste implementările manuale Kubernetes prin automatizarea fluxului de lucru CI/CD.
• Utilizați sondele de viabilitate și pregătire pentru a ajuta la gestionarea ciclurilor de viață ale podului ; în caz contrar, podurile pot fi terminate în timpul inițializării sau primirii solicitărilor utilizatorilor înainte ca acestea să fie gata.

Luați în considerare containerele dvs

Kubernetes, software-ul de management centrat pe container, a devenit standardul de facto pentru implementarea și operarea aplicațiilor containerizate datorită utilizării pe scară largă a containerelor în cadrul întreprinderilor. Arhitectura Kubernetes este simplă și intuitivă. Deși oferă managerilor IT un control mai mare asupra infrastructurii și performanței aplicațiilor lor, există multe de învățat pentru a profita la maximum de tehnologie.

Ești intrigat să explorezi mai mult subiectul? Aflați despre relevanța tot mai mare a containerizării în cloud computing!