Bună, numele meu este Dmitri Krasnov. De mai bine de cinci ani am administrat clustere Kubernetes și am construit arhitecturi complexe de microservicii. La începutul acestui an, am lansat un serviciu de gestionare a clusterelor Kubernetes bazat pe Containerum. Profitând de această ocazie, vă voi spune ce este Kubernetes și cum diferă integrarea cu un furnizor de open source.
Pentru început, ce este . Acesta este un sistem de gestionare a containerelor pe un număr mare de gazde. Din greacă, apropo, este tradus ca „pilot” sau „timonier”. Dezvoltat inițial de Google și apoi donat ca contribuție tehnologică Cloud Native Computing Foundation, o organizație internațională non-profit care reunește cei mai importanți dezvoltatori, utilizatori finali și furnizori de tehnologie pentru containere.
Gestionați un număr mare de containere
Acum să ne dăm seama ce fel de containere sunt acestea. Aceasta este o aplicație cu întregul său mediu - în principal bibliotecile de care depinde programul. Toate acestea sunt ambalate în arhive și prezentate sub forma unei imagini care poate fi rulată indiferent de sistemul de operare, testată și nu numai. Dar există o problemă - gestionarea containerelor pe un număr mare de gazde este foarte dificilă. De aceea a fost creat Kubernetes.
O imagine container reprezintă o aplicație plus dependențele acesteia. Aplicația, dependențele sale și imaginea sistemului de fișiere ale sistemului de operare sunt situate în diferite părți ale imaginii, așa-numitele straturi. Straturile pot fi refolosite pentru diferite containere. De exemplu, toate aplicațiile dintr-o companie ar putea folosi stratul de bază Ubuntu. Când rulați containere, nu este nevoie să stocați mai multe copii ale unui singur strat de bază pe gazdă. Acest lucru vă permite să optimizați stocarea și livrarea imaginilor.
Atunci când dorim să rulăm o aplicație dintr-un container, straturile necesare sunt suprapuse unele peste altele și se formează un sistem de fișiere suprapus. Un strat de înregistrare este plasat deasupra, care este îndepărtat când containerul se oprește. Acest lucru asigură că atunci când containerul rulează, aplicația va avea întotdeauna același mediu, care nu poate fi schimbat. Acest lucru garantează reproductibilitatea mediului pe diferite sisteme de operare gazdă. Indiferent dacă este Ubuntu sau CentOS, mediul va fi întotdeauna același. În plus, containerul este izolat de gazdă folosind mecanisme încorporate în nucleul Linux. Aplicațiile dintr-un container nu văd fișierele, procesele gazdei și containerele învecinate. Această izolare a aplicațiilor de sistemul de operare gazdă oferă un nivel suplimentar de securitate.
Există multe instrumente disponibile pentru a gestiona containerele pe o gazdă. Cel mai popular dintre ele este Docker. Vă permite să oferiți întregul ciclu de viață al containerelor. Cu toate acestea, funcționează doar pe o singură gazdă. Dacă trebuie să gestionați containerele pe mai multe gazde, Docker poate face viața un iad pentru ingineri. De aceea a fost creat Kubernetes.
Cererea pentru Kubernetes se datorează tocmai capacității de a gestiona grupuri de containere pe mai multe gazde ca un fel de entitate unică. Popularitatea sistemului oferă posibilitatea de a construi DevOps sau Operațiuni de dezvoltare, în care Kubernetes este folosit pentru a rula procesele acestui DevOps.
Figura 1. Reprezentare schematică a modului în care funcționează Kubernetes
Automatizare completă
DevOps este practic automatizarea procesului de dezvoltare. În linii mari, dezvoltatorii scriu cod care este încărcat în depozit. Apoi, acest cod poate fi colectat automat imediat într-un container cu toate bibliotecile, testat și „rulat” la următoarea etapă - Staging, și apoi imediat la producție.
Împreună cu Kubernetes, DevOps vă permite să automatizați acest proces, astfel încât să aibă loc practic fără participarea dezvoltatorilor înșiși. Din acest motiv, construirea este semnificativ mai rapidă, deoarece dezvoltatorul nu trebuie să facă acest lucru pe computerul său - pur și simplu scrie o bucată de cod, împinge codul în depozit, după care este lansată pipeline, care poate include procesul de construire, testare și lansare. Și asta se întâmplă cu fiecare comitere, deci testarea are loc continuu.
În același timp, utilizarea unui container vă permite să fiți sigur că întregul mediu al acestui program va fi lansat în producție exact în forma în care a fost testat. Adică nu vor fi probleme de genul „au fost unele versiuni în test, altele în producție, dar când le-am instalat, totul a căzut”. Și din moment ce astăzi avem o tendință către arhitectura de microservicii, când în loc de o aplicație uriașă sunt sute de aplicații mici, pentru a le administra manual, va fi nevoie de un personal imens de angajați. De aceea folosim Kubernetes.
Pro, pro, pro
Dacă vorbim despre avantajele Kubernetes ca platformă, atunci are avantaje semnificative din punctul de vedere al gestionării unei arhitecturi de microservicii.
- Gestionarea mai multor replici. Cel mai important lucru este gestionarea containerelor pe mai multe gazde. Mai important, gestionați mai multe replici ale aplicațiilor în containere ca o singură entitate. Datorită acestui fapt, inginerii nu trebuie să-și facă griji pentru fiecare container în parte. Dacă unul dintre containere se blochează, Kubernetes va vedea acest lucru și îl va reporni din nou.
- Rețea de clustere. Kubernetes are, de asemenea, o așa-numită rețea de cluster cu propriul spațiu de adrese. Datorită acestui fapt, fiecare pod are propria sa adresă. Un subpod este înțeles ca unitatea structurală minimă a unui cluster în care containerele sunt lansate direct. În plus, Kubernetes are o funcționalitate care combină un echilibrator de încărcare și Service Discovery. Acest lucru vă permite să scăpați de gestionarea manuală a adreselor IP și să delegați această sarcină lui Kubernetes. Iar verificările automate de sănătate vor ajuta la detectarea problemelor și la redirecționarea traficului către podurile funcționale.
- Managementul configurației. Când gestionați un număr mare de aplicații, devine dificil să gestionați configurația aplicației. În acest scop, Kubernetes are resurse speciale ConfigMap. Acestea vă permit să stocați central configurațiile și să le expuneți la poduri atunci când rulați aplicații. Acest mecanism ne permite să garantăm consistența configurației în cel puțin zece sau o sută de replici ale aplicației.
- Volume persistente. Containerele sunt inerent imuabile și atunci când containerul este oprit, toate datele scrise în sistemul de fișiere vor fi distruse. Dar unele aplicații stochează date direct pe disc. Pentru a rezolva această problemă, Kubernetes are o funcționalitate de gestionare a stocării pe disc - Persistent Volumes. Acest mecanism folosește stocarea externă pentru date și poate transfera stocare persistentă, bloc sau fișier, în containere. Această soluție vă permite să stocați datele separat de lucrători, ceea ce le salvează dacă acești lucrători se defectează.
- Echilibrarea greutății. Chiar dacă în Kubernetes gestionăm entități abstracte precum Deployment, StatefulSet etc., în cele din urmă containerele rulează pe mașini virtuale obișnuite sau pe servere hardware. Nu sunt perfecte și pot cădea oricând. Kubernetes va vedea acest lucru și va redirecționa traficul intern către alte replici. Dar ce să faci cu traficul care vine din afară? Dacă pur și simplu direcționați traficul către unul dintre lucrători, dacă acesta se blochează, serviciul va deveni indisponibil. Pentru a rezolva această problemă, Kubernetes are servicii precum Load Balancer. Acestea sunt concepute pentru a configura automat un echilibrator cloud extern pentru toți lucrătorii din cluster. Acest echilibrator extern direcționează traficul extern către lucrători și le monitorizează însuși starea. Dacă unul sau mai mulți lucrători devin indisponibili, traficul este redirecționat către alții. Acest lucru vă permite să creați servicii foarte disponibile folosind Kubernetes.
Kubernetes funcționează cel mai bine atunci când rulează arhitecturi de microservicii. Este posibil să se implementeze sistemul în arhitectura clasică, dar este inutil. Dacă o aplicație nu poate rula pe mai multe replici, atunci ce diferență are - în Kubernetes sau nu?
Kubernetes cu sursă deschisă
Kubernetes cu sursă deschisă este un lucru grozav: l-am instalat și funcționează. Îl puteți implementa pe propriile servere hardware, pe propria infrastructură, puteți instala master și lucrători pe care vor rula toate aplicațiile. Și cel mai important, toate acestea sunt gratuite. Cu toate acestea, există nuanțe.
- Prima este cererea de cunoștințe și experiență a administratorilor și inginerilor care vor implementa și vor sprijini toate acestea. Deoarece clientul primește libertate completă de acțiune în cluster, el însuși este responsabil pentru performanța clusterului. Și este foarte ușor să spargi totul aici.
- A doua este lipsa integrărilor. Dacă rulați Kubernetes fără o platformă de virtualizare populară, nu veți beneficia de toate beneficiile programului. Cum ar fi utilizarea volumelor persistente și a serviciilor de echilibrare a sarcinii.
Figura 2. arhitectura k8s
Kubernetes de la furnizor
Integrarea cu un furnizor de cloud oferă două opțiuni:
- În primul rând, o persoană poate pur și simplu să facă clic pe butonul „creează cluster” și să obțină un cluster deja configurat și gata de utilizare.
- În al doilea rând, vânzătorul însuși instalează cluster-ul și stabilește integrarea cu cloud-ul.
Cum se întâmplă aici. Inginerul care pornește clusterul specifică de câți lucrători are nevoie și cu ce parametri (de exemplu, 5 lucrători, fiecare cu 10 CPU-uri, 16 GB RAM și, să zicem, 100 GB disc). După care obține acces la clusterul deja format. În acest caz, lucrătorii pe care este lansată sarcina sunt transferați complet către client, dar întregul plan de management rămâne în responsabilitatea vânzătorului (dacă serviciul este furnizat conform modelului de servicii gestionate).
Cu toate acestea, această schemă are dezavantajele sale. Datorită faptului că planul de management rămâne la furnizor, acesta nu oferă acces deplin clientului, iar acest lucru reduce flexibilitatea în lucrul cu Kubernetes. Uneori se întâmplă ca un client să dorească să adauge anumite funcționalități specifice la Kubernetes, de exemplu, autentificarea prin LDAP, dar configurația planului de management nu permite acest lucru.
Figura 3. Exemplu de cluster Kubernetes de la un furnizor de cloud
Ce să alegeți: sursă deschisă sau furnizor
Deci, este Kubernetes open source sau specific furnizorului? Dacă luăm Kubernetes open source, atunci utilizatorul face ce vrea cu el. Dar există șanse mari să te împuști în picior. Cu vânzătorul este mai dificil, deoarece totul este gândit și configurat pentru companie. Cel mai mare dezavantaj al open source Kubernetes este cerința de specialiști. Cu o opțiune de vânzător, compania este eliberată de această bataie de cap, dar va trebui să decidă dacă își plătește specialiștii sau vânzătorul.
Ei bine, avantajele sunt evidente, se cunosc și contra. Un lucru este constant: Kubernetes rezolvă o mulțime de probleme prin automatizarea gestionării multor containere. Și pe care să o alegeți, open source sau furnizor - fiecare ia propria decizie.
Articolul a fost pregătit de Dmitri Krasnov, arhitect principal al serviciului Containerum al furnizorului #CloudMTS
Sursa: www.habr.com