🥇Kubernetes: open source versus vendor

Bună, mă numesc Dmitri Krasnov. Deja de mai bine de cinci ani mă ocup cu administrarea clusterelor Kubernetes și construirea unor arhitecturi complexe de microservicii. La începutul acestui an, am lansat un serviciu pentru gestionarea clusterelor Kubernetes pe baza Containerum. Profit de ocazie să explic ce reprezintă acest Kubernetes și cum se deosebește integrarea cu un furnizor de open source.

Pentru început, ce este Kubernetes. Este un sistem pentru gestionarea containerelor pe un număr mare de gazde. În greacă, de altfel, se traduce ca "pilot" sau "căpitan". A fost dezvoltat inițial de Google, după care, ca o contribuție tehnologică, a fost transferat Cloud Native Computing Foundation, o organizație internațională non-profit care reunește cei mai importanți dezvoltatori din lume, utilizatori finali și furnizori de tehnologii pentru containere.

A conduce un număr mare de containere

Acum să înțelegem ce sunt aceste containere. Este o aplicație cu tot mediu său — în principal, bibliotecile de care depinde funcționarea programului. Toate acestea sunt împachetate în arhive și prezentate sub formă de imagini care pot fi rulate indiferent de sistemul de operare, testate și nu numai. Dar există o problemă — este foarte dificil să gestionezi containere pe un număr mare de gazde. De aceea a fost creat Kubernetes.

Imaginea unui container reprezintă aplicația plus dependențele sale. Aplicația, dependențele sale și imaginea sistemului de fișiere OS sunt plasate în părți diferite ale imaginii, denumite straturi. Straturile pot fi reutilizate pentru diferite containere. De exemplu, pentru toate aplicațiile din companie poate fi utilizat un strat de bază Ubuntu. La pornirea containerelor, nu este nevoie să se păstreze pe gazdă multiple copii ale aceluiași strat de bază. Acest lucru permite optimizarea stocării și livrării imaginilor.

Când dorim să lansăm o aplicație dintr-un container, straturile necesare se suprapun, formând un sistem de fișiere overlay. Deasupra se suprapune un strat de scriere, care, la oprirea containerului, este șters. Aceasta garantează că, la lansarea containerului, aplicația va avea întotdeauna același mediu, care nu poate fi modificat. Aceasta asigură reproducibilitatea mediului pe diferite sisteme de operare gazdă. Fie că este vorba de Ubuntu sau CentOS, mediul va fi întotdeauna identic. În plus, containerul este izolat de gazdă prin mecanismele încorporate în nucleul Linux. Aplicațiile din container nu pot vedea fișierele, procesele gazdei și ale containerelor vecine. Această izolare a aplicațiilor de sistemul de operare gazdă oferă un strat suplimentar de securitate.

Pentru gestionarea containerelor pe gazdă există numeroase instrumente. Cel mai popular dintre ele este Docker. Acesta permite asigurarea întregului ciclu de viață al containerelor. Cu toate acestea, funcționează doar pe un singur gazdă. Atunci când este necesară gestionarea containerelor pe mai multe gazde, Docker poate transforma viața inginerilor într-un iad. De aceea a fost creat Kubernetes.

Cererea pentru Kubernetes este determinată exact de capacitatea de a manevra grupuri de containere pe mai multe gazde ca și cum ar fi entități unice. Popularitatea sistemului asigură posibilitatea de a construi DevOps sau Development Operations, în care Kubernetes este folosit pentru a lansa procesele acestui DevOps.

Figura 1. Reprezentare schematică a principiului de funcționare a Kubernetes

Automatizare completă

DevOps, în principiu, reprezintă automatizarea procesului de dezvoltare. Pe scurt, dezvoltatorii scriu cod, care este încărcat în depozit. Apoi, acest cod poate fi automat compilat direct într-un container cu toate bibliotecile, testat și "descărcat" la următoarea etapă – Staging, iar apoi imediat în Production.

Împreună cu Kubernetes, DevOps permite automatizarea acestui proces, astfel încât acesta să decurgă aproape fără implicarea dezvoltatorilor. Datorită acestui lucru, compilarea se accelerează semnificativ, deoarece dezvoltatorul nu trebuie să se ocupe de asta pe computerul său – pur și simplu scrie o bucată de cod, face push în repository, după care se lansează un pipeline, care poate include procesul de compilare, testare și implementare. Așa se întâmplă cu fiecare commit, astfel încât testarea este continuă.

În același timp, utilizarea containerului permite să fii sigur că întregul mediu al acestei aplicații va ajunge în producție exact în forma în care a fost testat. Adică, nu vor apărea probleme de genul „în mediu de testare au fost alte versiuni, în producție sunt altele, iar când s-a lansat – totul a căzut”. Și deoarece astăzi avem tendința spre arhitectura de microservicii, când în loc de o aplicație imensă există sute de aplicații mici, pentru a le administra manual ar fi necesar un număr uriaș de angajați. De aceea, folosim Kubernetes.

Avantaje, avantaje, avantaje

Dacă vorbim despre avantajele Kubernetes ca platformă, acesta are avantaje semnificative în ceea ce privește gestionarea arhitecturii de microservicii.

Gestionarea multiplelor replici. Cel mai important este că gestionează containere pe mai multe gazde. Și mai important, gestionează numeroase replici ale aplicațiilor în containere ca o entitate unică. Datorită acestui fapt, inginerii nu trebuie să se ocupe de fiecare container în parte. Dacă unul dintre containere se prăbușește, Kubernetes va observa acest lucru și îl va reporni.
Rețeaua cluster-ului. De asemenea, Kubernetes dispune de așa-numita rețea de cluster cu propriul spațiu de adresare. Datorită acestui fapt, fiecare pod are propria adresă. Podul este considerată unitatea structurală minimă a cluster-ului, în care sunt lansate direct containerele. În plus, Kubernetes are funcționalitatea de a combina un echilibrator de sarcină și descoperirea serviciilor. Aceasta permite eliminarea gestionării manuale a adreselor IP și transferarea acestei sarcini către Kubernetes. Iar verificările automate de sănătate ajută la detectarea problemelor și la redirecționarea traficului către podurile funcționale.
Gestionarea configurațiilor. Când gestionăm un număr mare de aplicații, devine dificil să administrăm configurația acestora. Pentru aceasta, Kubernetes dispune de resurse speciale numite ConfigMap-uri. Acestea permit stocarea centralizată a configurațiilor și înlocuirea lor în poduri la lansarea aplicațiilor. Acest mecanism garantează coerența configurației, fie că avem zece sau o sută de replici ale aplicațiilor.
Volume persistente. Containerele sunt prin natura lor imutabile, iar la oprirea unui container, toate datele scrise în sistemul de fișiere vor fi distruse. Însă anumite aplicații stochează date direct pe disc. Pentru a rezolva această problemă, Kubernetes are funcționalitatea de gestionare a stocării pe disc — Volume persistente. Acest mecanism folosește un stoc extern pentru date, care poate oferi stocare permanentă în containere, fie bloc sau fișier. Această soluție permite păstrarea datelor separat de muncitorii (workers), protejându-le în cazul defectării acestora.
Balansor de încărcare. Deși în Kubernetes gestionăm entități abstracte precum Deployment, StatefulSet etc., în cele din urmă containerele sunt lansate pe servere obișnuite virtuálne mašini sau fizice. Acestea nu sunt perfecte și pot cădea în orice moment. Kubernetes va observa acest lucru și va redirecționa traficul intern către alte replici. Dar ce facem cu traficul care vine din exterior? Dacă direcționăm traficul către unul dintre muncitori și acesta pică, serviciul devine indisponibil. Pentru a rezolva această problemă, Kubernetes are servicii de tip Load Balancer. Acestea sunt concepute pentru a configura automat un balansor de sarcină extern pentru toți muncitorii din cluster. Acest balansor extern direcționează traficul extern către muncitori și monitorizează statusul acestora. Dacă unul sau mai mulți muncitori devin indisponibili, traficul este redirecționat către altele. Aceasta permite crearea de servicii de înaltă disponibilitate cu ajutorul Kubernetes.

Kubernetes se dovedește cel mai eficient atunci când rulează arhitecturi de microservicii. Implementarea sistemului într-o arhitectură clasică este posibilă, dar lipsită de sens. Dacă o aplicație nu poate funcționa în mai multe replici, care este diferența - fie în Kubernetes sau nu?

Kubernetes open source

Kubernetes open source – o alegere excelentă: l-ai instalat și funcționează. Poate fi implementat pe serverele tale fizice, pe propria infrastructură, instalând un master și workerii pe care vor rula toate aplicațiile. Și cel mai important – totul este gratuit. Cu toate acestea, există nuanțe.

Primul – cerințele de cunoștințe și experiență ale administratorilor și inginerilor care vor implementa și întreține totul. Deoarece clientul are o libertate totală de acțiune în cluster, responsabilitatea pentru funcționarea acestuia îi revine lui. Și este foarte simplu să strici totul aici.
Al doilea – lipsa integrărilor. Dacă lansezi Kubernetes fără a avea vreo platformă de virtualizare populară, nu vei obține toate avantajele programului. Cum ar fi utilizarea Persistent Volumes și a serviciilor Load balancer.

Figura 2. Arhitectura k8s

Kubernetes de la vendor

Integrarea cu un furnizor de cloud oferă două posibilități:

În primul rând, o persoană poate pur și simplu să apese butonul „creează cluster” și să primească un cluster deja configurat și gata de utilizare.
În al doilea rând, vendorul instalează singur clusterul și configurează integrarea cu cloudul.

Cum se întâmplă asta la noi. Inginerul care lansează clusterul specifică câți worker-i are nevoie și cu ce parametrii (de exemplu, 5 worker-i, fiecare cu 10 CPU-uri, 16 GB RAM și, să zicem, 100 GB disk). După care primește acces la clusterul deja format. În acest timp, worker-ii pe care se va rula sarcina se predau complet clientului, dar întregul management plane rămâne în responsabilitatea vendorului (în cazul în care serviciul este oferit pe modelul de managed service).

Cu toate acestea, această schemă are dezavantajele sale. Din cauza faptului că management plane rămâne la vendor, acesta nu oferă acces complet clientului, ceea ce reduce flexibilitatea în lucrul cu Kubernetes. Uneori se întâmplă ca clientul să dorească să adauge un anumit fel de funcționalitate specifică la Kubernetes, de exemplu, autentificarea prin LDAP, dar configurația management plane nu permite acest lucru.

Figura 3. Exemplu de cluster Kubernetes de la un furnizor de cloud

Ce să alegi: open source sau de la vendor

Deci, Kubernetes open source sau vendor? Dacă alegi Kubernetes open source, utilizatorul poate face ce vrea cu el. Dar este mare riscul de a-și împușca singur în picior. Cu cel vendor este mai complicat, deoarece totul este gândit și configurat de companie. Cel mai mare dezavantaj al Kubernetes open source este cerința de specialiști. Cu cel vendor, compania este scutită de această problemă, dar va trebui să decide: să plătească specialistii proprii sau vânditorului.

Ei bine, avantajele sunt evidente, dezavantajele sunt de asemenea cunoscute. Un lucru rămâne constant: Kubernetes rezolvă o mulțime de probleme, automatizând gestionarea mai multor containere. Și pe care să-l alegi, open source sau vendor, fiecare decide singur.