K8s/Kubernetes: AWS vs. GCP vs. Azure

Kubernetes (deseori stilizat „K8s”) a câștigat bătălia instrumentelor de orchestrare a containerelor cu ani în urmă. Cu toate acestea, există încă multe modalități de a implementa Kubernetes astăzi și de a-l face să funcționeze cu diverse infrastructuri și multe instrumente - unele mai bine întreținute decât altele. Totuși, probabil cea mai interesantă dezvoltare în acest sens este că cei mai buni furnizori de cloud au decis să-și lanseze propriile versiuni Kubernetes gestionate:

• Microsoft Azure oferă serviciul Azure Kubernetes (AKS)
• AWS oferă Amazon Elastic Kubernetes Service (EKS)
• Google Cloud oferă Google Kubernetes Engine (GKE)

Din perspectiva DevOps, ce oferă aceste platforme? Își respectă promisiunile? Cum se compară timpul lor de creare și alte repere? Cât de bine se integrează cu platformele lor respective, în special cu instrumentele CLI? Cum este să întreținem și să lucrezi cu ei? Mai jos, vom aprofunda aceste întrebări și multe altele.

Notă: Pentru cititorii care ar dori să fie explicate conceptele unui cluster Kubernetes înainte de a citi mai departe, Dmitriy Kononov oferă o introducere excelentă.

AKS vs. EKS vs. GKE: Funcții anunțate

Am decis să grupăm diferitele funcții disponibile pentru fiecare versiune Kubernetes gestionată în silozuri:

• Prezentare globală
• Rețele
• Scalabilitate și performanță
• Securitate și monitorizare
• Ecosistem
• Prețuri

Notă: Aceste detalii se pot schimba în timp, deoarece furnizorii de cloud își actualizează în mod regulat produsele.

Prezentare globală

Kubernetes însuși a fost proiectul Google, așa că are sens că au fost primii care au propus o versiune găzduită în 2014.

Dintre cele trei comparate aici, Azure a fost următorul cu AKS și a avut timp să se îmbunătățească: dacă vă amintiți acs-engine, care a fost folosit pentru furnizarea Kubernetes pe Azure cu câțiva ani în urmă, veți aprecia efortul Microsoft pentru înlocuirea acestuia, aks-motor.

AWS a fost ultimul care a lansat propria sa versiune, EKS, așa că uneori poate părea să fie în urmă în ceea ce privește caracteristicile, dar ajung din urmă.

În ceea ce privește prețurile, desigur, lucrurile se mișcă mereu, iar Google a decis să se alăture AWS la prețul său de 0,10 USD/oră, în vigoare din iunie 2020. Azure este străin aici, oferind gratuit serviciul AKS, dar nu este clar cum mult timp care poate dura.

O altă diferență principală constă în caracteristica de actualizare a clusterului. Cele mai automate upgrade-uri sunt în GKE și sunt activate implicit. Totuși, AKS vs. EKS sunt similare unul cu celălalt aici, în sensul că ambele necesită solicitări manuale pentru a putea face upgrade nodurilor master sau worker.

Rețele

În ceea ce privește rețeaua, cei trei furnizori de cloud sunt foarte apropiați unul de celălalt. Toate le permit clienților să implementeze politici de rețea cu Calico, de exemplu. În ceea ce privește echilibrarea sarcinii, toți implementează integrarea lor cu propriile resurse de echilibrare a încărcăturii și oferă inginerilor posibilitatea de a alege ce să folosească.

Principala diferență găsită aici se bazează pe valoarea adăugată a rețelei de servicii. AKS nu acceptă nicio rețea de serviciu imediată (deși inginerii pot instala manual Istio). AWS și-a dezvoltat propria rețea de servicii numită App Mesh. În cele din urmă, Google și-a lansat propria integrare cu Istio (deși încă în versiune beta) pe care clienții o pot adăuga direct atunci când creează clusterul.

Cel mai bun pariu: GKE

Scalabilitate și performanță

În ceea ce privește performanța și scalabilitatea GKE vs. AKS vs. EKS, GKE pare să fie în frunte. Într-adevăr, acceptă cel mai mare număr de noduri (5.000) și oferă o documentație extinsă despre cum să scalați corect un cluster. Toate funcțiile pentru disponibilitate ridicată sunt disponibile și sunt ușor de ajustat. În plus, GKE a lansat recent Anthos, un proiect de creare a unui ecosistem în jurul GKE și a funcționalităților sale; cu Anthos, puteți implementa GKE on-prem.

AWS are totuși un avantaj cheie: este singurul care permite nodurilor bare-metal să ruleze cluster-ul Kubernetes.

Din iunie 2020, AKS nu are o disponibilitate ridicată pentru master, care este un aspect important de luat în considerare. Dar, ca întotdeauna, asta s-ar putea schimba în curând.

Cel mai bun pariu: GKE

Securitate și monitorizare

În ceea ce privește conformitatea, toți cei trei furnizori de cloud sunt echivalenti. Cu toate acestea, în ceea ce privește securitatea, EKS și GKE oferă un alt nivel de securitate cu serviciile lor de gestionare a cheilor încorporate.

În ceea ce privește monitorizarea, Azure și Google Cloud oferă propriul ecosistem de monitorizare în jurul Kubernetes. Este de remarcat faptul că cel de la Google a fost actualizat recent pentru a utiliza Kubernetes Engine Monitoring, care este special conceput pentru Kubernetes.

Azure oferă propriul sistem de monitorizare a containerelor, care a fost creat inițial pentru un ecosistem de containere de bază, non-Kubernetes. Au adăugat monitorizare pentru unele valori și resurse specifice Kubernetes (sănătatea clusterului, implementări) — în modul de previzualizare, începând cu iunie 2020.

AWS oferă monitorizare ușoară pentru planul de control direct în Cloudwatch. Pentru a monitoriza lucrătorii, puteți utiliza Metricurile Kubernetes Container Insights furnizate printr-un agent CloudWatch specific pe care îl puteți instala în cluster.

Cel mai bun pariu: GKE

Ecosistem

În ceea ce privește ecosistemele, cei trei furnizori au puncte forte și atuuri diferite. AKS are acum o documentație foarte completă în jurul platformei sale și este al doilea în ceea ce privește postările pe Stack Overflow. EKS are cel mai mic număr de postări pe Stack Overflow, dar beneficiază de puterea AWS Marketplace. GKE, ca cea mai veche platformă, are cele mai multe postări pe Stack Overflow și un număr decent de aplicații pe piața sa, dar și cea mai cuprinzătoare documentație.

Cele mai bune pariuri: GKE și EKS

Prețuri

În ceea ce privește prețul general, chiar și cu mișcarea GKE de a implementa prețul de 0,10 USD/oră pentru orice cluster, acesta rămâne de departe cel mai ieftin cloud. Acest lucru se datorează ceva specific Google: reduceri de utilizare susținută, care se aplică ori de câte ori utilizarea lunară a resurselor la cerere atinge un anumit minim.

Este important de reținut că rândul de preț exemplu nu ia în considerare traficul către clusterul Kubernetes pentru care furnizorul de cloud îl poate percepe.

Motivul pentru care AWS nu permite utilizarea nivelului lor gratuit pentru a testa un cluster EKS este că EKS necesită mașini mai mari decât nivelul tX.micro, iar prețul orar EKS nu este în nivelul gratuit.

Cu toate acestea, poate fi în continuare economic să testați oricare dintre aceste opțiuni Kubernetes gestionate cu o încărcare decentă folosind nodurile spot/preemptibile ale fiecărui furnizor de cloud - această tactică va economisi cu ușurință 80 până la 90% din prețul final. (Desigur, nu este recomandat să rulați încărcări de producție cu stare pe astfel de mașini!)

Caracteristici promovate și avantajul Google

Când ne uităm la diferitele caracteristici promovate online, se pare că există o corelație între cât timp a fost pe piață versiunea Kubernetes gestionată și numărul de funcții. După cum am menționat, Google a fost inițiatorul proiectului Kubernetes pare a fi un avantaj incontestabil, având ca rezultat o integrare mai bună și mai puternică cu propria sa platformă cloud.

Dar AKS și EKS nu trebuie subestimate pe măsură ce se maturizează; ambele pot profita de caracteristicile lor unice. De exemplu, AWS este singurul care are integrare bare-metal nod și, de asemenea, se mândrește cu cel mai mare număr de aplicații de pe piața sa.

Acum că funcțiile afișate pentru fiecare ofertă Kubernetes sunt clare, haideți să facem o scufundare mai profundă cu câteva teste practice.

Kubernetes: AWS vs. GCP vs. Azure în practică

Publicitatea este un lucru, dar cum se compară diferitele platforme când vine vorba de deservirea sarcinilor de producție? În calitate de inginer cloud, știu importanța cât timp durează pentru a se genera și pentru a elimina un cluster atunci când impun infrastructura ca cod. Dar am vrut, de asemenea, să explorez posibilitățile fiecărui CLI și să comentez cât de ușor (sau nu) fiecare furnizor de cloud face generarea unui cluster.

Experiența utilizatorului în crearea unui cluster

AKS

Pe AKS, generarea unui cluster este similară cu crearea unei instanțe în AWS. Găsiți meniul AKS și parcurgeți o serie de meniuri diferite. Odată validată configurația, clusterul poate fi creat, un proces în doi pași. Este foarte simplu, iar inginerii pot lansa cu ușurință și rapid un cluster cu setările implicite.

EKS

Crearea clusterelor este cu siguranță mai complexă pe EKS vs. AKS. În primul rând, și în mod implicit, AWS necesită o călătorie la IAM pentru a crea un nou rol pentru planul de control Kubernetes și pentru a-i atribui inginerului. De asemenea, este important de menționat că această creare a clusterului nu include crearea nodurilor, așa că atunci când am măsurat 11 minute în medie, aceasta este doar pentru crearea principală. Crearea grupului de noduri este un alt pas pentru administrator, având din nou nevoie de un rol pentru lucrători cu trei politici necesare care trebuie făcute prin panoul de control IAM.

GKE

Pentru mine, experiența de a crea un cluster manual este cea mai plăcută pe GKE. După ce ați găsit Kubernetes Engine în Google Cloud Console, faceți clic pentru a crea un cluster. Diferite categorii de setări apar într-un meniu din stânga. Google va prepopula noul cluster cu un pool de noduri implicit ușor de modificat. Nu în ultimul rând, GKE are cel mai rapid timp de generare a clusterelor, ceea ce ne duce la următorul tabel.

E timpul să dai naștere unui cluster

Am efectuat aceste teste în aceeași regiune (Frankfurt și Europa de Vest pentru AKS) pentru a elimina posibilul impact al acestei diferențe asupra timpului de reproducere. De asemenea, am încercat să selectez aceeași dimensiune pentru nodurile pentru cluster: trei noduri, fiecare având două vCPU-uri și șapte sau opt GB de memorie, o dimensiune standard pentru a rula o încărcare mică pe Kubernetes și a începe experimentarea. Am creat fiecare cluster de trei ori pentru a calcula o medie.

În aceste teste, GKE a rămas mult înainte, cu un timp de generare întotdeauna sub trei minute.

Kubernetes: AWS vs. GCP vs. Azure CLI Prezentare generală

Nu toate CLI-urile sunt create egale, dar în acest caz, toate cele trei CLI-uri sunt de fapt module ale unui CLI mai mare. Cum este să pornești cu lanțul de instrumente CLI al fiecărui furnizor de cloud?

AKS CLI (prin az )

După instalarea instrumentelor az , apoi a modulului AKS (prin az aks install-cli ), inginerii trebuie să autorizeze CLI să comunice cu contul Azure al proiectului. Aceasta este o chestiune de obținere a acreditărilor pentru a actualiza fișierul local kubeconfig printr-un simplu az aks get-credentials --resource-group myResourceGroup --name myAKSCluster .

În mod similar, pentru a crea un cluster: az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI (prin aws sau eksctl )

Pe AWS, găsim o abordare diferită - există două instrumente CLI oficiale diferite pentru a gestiona clusterele EKS. Ca întotdeauna, aws se poate conecta la resursele AWS, în special la clustere. Obținerea acreditărilor într-un kubeconfig local se poate face prin: aws eks update-kubeconfig --name cluster-test .

Cu toate acestea, inginerii pot folosi și eksctl , dezvoltat de Weaveworks și scris în Go, pentru a crea și gestiona cu ușurință un cluster EKS. Un avantaj major pe care EKS îl oferă inginerilor cloud este că îl pot combina cu fișierele de configurare YAML pentru a crea infrastructură-as-code (IaC), deoarece funcționează cu CloudFormation. Este cu siguranță un atu de luat în considerare atunci când integrați un cluster EKS într-o infrastructură mai mare pe AWS.

Crearea unui cluster prin eksctl este la fel de simplă ca eksctl create cluster , fără alți parametri necesari.

GKE CLI (prin gcloud )

Pentru GKE, pașii sunt foarte similari: instalați gcloud , apoi autentificați-vă prin gcloud init . Posibilitățile de acolo: Inginerii pot crea, șterge, descrie, obține acreditări pentru, redimensiona, actualiza sau actualiza un cluster sau pot lista clustere.

Sintaxa pentru a crea un cluster cu gcloud este simplă: gcloud container clusters create myGCloudCluster --num-nodes=1

AKS vs. EKS vs. GKE: rezultate test Drive

În practică, putem vedea că GKE este cu siguranță cel mai rapid pentru a crea un cluster de bază, atât din punct de vedere al simplității consolei, cât și al timpului de generare a clusterului. În ceea ce privește UX, cu butonul de conectare de lângă cluster, ceea ce face și cel mai simplu să se conecteze la un cluster.

În ceea ce privește instrumentele CLI, cei trei furnizori de cloud au implementat funcționalități similare; cu toate acestea, putem pune accent pe instrumentul suplimentar oferit de Weaveworks pentru EKS. eksctl este instrumentul perfect pentru a implementa infrastructura ca cod pe lângă infrastructura AWS preexistentă, combinând alte servicii cu EKS.

Ofertele Kubernetes gestionate Avanză: AWS vs. GCP vs. Azure

Pentru cei care încep în lumea Kubernetes, implementarea de bază pentru mine este GKE, deoarece este cea mai simplă. Este ușor de configurat, are un UX simplu și rapid pentru generare și este bine integrat în ecosistemul Google Cloud Platform.

Chiar dacă AWS a fost ultimul care s-a alăturat cursei, are câteva avantaje incontestabile, cum ar fi noduri metalice goale și simplul fapt că este integrat cu furnizorul cu cea mai mare partajare a minții.

În cele din urmă, AKS a făcut progrese mari de la crearea sa. Paritatea instrumentelor și a caracteristicilor probabil nu va dura mult, lăsând, între timp, spațiu în procesul de inovare. Și ca și în cazul oricărei oferte Kubernetes gestionate, pentru cei care se află deja pe platforma părinte, integrarea va fi un punct de vânzare.

Odată ce o echipă a ales un furnizor de cloud Kubernetes, ar putea fi interesant să analizăm experiențele altor echipe, în special eșecurile. Aceste autopsie sunt o reflectare a cazurilor din lumea reală – întotdeauna un bun punct de plecare pentru dezvoltarea propriilor bune practici de ultimă oră. Aștept cu nerăbdare comentariile voastre de mai jos!