K8s/Kubernetes: AWS vs GCP vs Azure

Kubernetes (spesso stilizzati "K8") ha vinto la battaglia degli strumenti di orchestrazione dei container anni fa. Tuttavia, ci sono ancora molti modi per implementare Kubernetes oggi e farlo funzionare con varie infrastrutture e molti strumenti, alcuni mantenuti meglio di altri. Forse lo sviluppo più interessante su questo fronte, tuttavia, è che i principali fornitori di servizi cloud hanno deciso di rilasciare le proprie versioni di Kubernetes gestite:

• Microsoft Azure offre il servizio Azure Kubernetes (AKS)
• AWS offre Amazon Elastic Kubernetes Service (EKS)
• Google Cloud offre Google Kubernetes Engine (GKE)

Dal punto di vista DevOps, cosa offrono queste piattaforme? Mantengono le loro promesse? Come si confrontano il loro tempo di creazione e altri benchmark? Quanto bene si integrano con le rispettive piattaforme, in particolare con i loro strumenti CLI? Com'è mantenerli e lavorare con loro? Di seguito, approfondiremo queste domande e altro ancora.

Nota: per i lettori che desiderano spiegare i concetti di un cluster Kubernetes prima di continuare a leggere, Dmitriy Kononov offre un'eccellente introduzione.

AKS vs. EKS vs. GKE: funzionalità pubblicizzate

Abbiamo deciso di raggruppare in silos le diverse funzionalità disponibili per ciascuna versione di Kubernetes gestita:

• Panoramica globale
• Rete
• Scalabilità e prestazioni
• Sicurezza e monitoraggio
• Ecosistema
• Prezzo

Nota: questi dettagli possono cambiare nel tempo poiché i fornitori di servizi cloud aggiornano regolarmente i loro prodotti.

Panoramica globale

Kubernetes stesso era il progetto di Google, quindi ha senso che siano stati i primi a proporre una versione ospitata nel 2014.

Dei tre confrontati qui, Azure è stato il successivo con AKS e ha avuto del tempo per migliorare: se ricordi acs-engine, che era stato utilizzato per eseguire il provisioning di Kubernetes su Azure alcuni anni fa, apprezzerai lo sforzo di Microsoft per la sua sostituzione, aks-motore.

AWS è stato l'ultimo a lanciare la propria versione, EKS, quindi a volte può sembrare in ritardo sul fronte delle funzionalità, ma stanno recuperando terreno.

In termini di prezzi, ovviamente, le cose sono sempre in movimento e Google ha deciso di aderire ad AWS al suo prezzo di $ 0,10/ora, a partire da giugno 2020. Azure è l'outsider qui distribuendo gratuitamente il servizio AKS, ma non è chiaro come a lungo che possa durare.

Un'altra differenza principale risiede nella funzionalità di aggiornamento del cluster. Gli aggiornamenti più automatizzati sono in GKE e sono attivati ​​per impostazione predefinita. Tuttavia, AKS e EKS sono simili tra loro, nel senso che entrambi richiedono richieste manuali per poter aggiornare i nodi master o di lavoro.

Rete

Dal punto di vista della rete, i tre fornitori di servizi cloud sono molto vicini tra loro. Tutti consentono ai clienti di implementare politiche di rete con Calico, ad esempio. Per quanto riguarda il bilanciamento del carico, tutti implementano la propria integrazione con le proprie risorse di bilanciamento del carico e danno agli ingegneri la possibilità di scegliere cosa utilizzare.

La principale differenza qui trovata si basa sul valore aggiunto della rete di servizi. AKS non supporta alcuna rete di servizi pronta all'uso (sebbene gli ingegneri possano installare manualmente Istio). AWS ha sviluppato la propria rete di servizi chiamata App Mesh. Infine, Google ha rilasciato la propria integrazione con Istio (sebbene ancora in versione beta) che i clienti possono aggiungere direttamente durante la creazione del cluster.

La migliore scommessa: GKE

Scalabilità e prestazioni

Per quanto riguarda le prestazioni e la scalabilità di GKE rispetto a AKS rispetto a EKS, GKE sembra essere in vantaggio. In effetti, supporta il maggior numero di nodi (5.000) e offre un'ampia documentazione su come ridimensionare correttamente un cluster. Tutte le funzionalità per l'alta disponibilità sono disponibili e sono facili da mettere a punto. Inoltre, GKE ha recentemente rilasciato Anthos, un progetto per creare un ecosistema attorno a GKE e alle sue funzionalità; con Anthos, puoi distribuire GKE in locale.

Tuttavia, AWS ha un vantaggio fondamentale: è l'unico a consentire ai nodi bare-metal di eseguire il tuo cluster Kubernetes.

A partire da giugno 2020, AKS non dispone di un'elevata disponibilità per il master, che è un aspetto importante da considerare. Ma, come sempre, le cose potrebbero presto cambiare.

La migliore scommessa: GKE

Sicurezza e monitoraggio

In termini di conformità, tutti e tre i fornitori di servizi cloud sono equivalenti. Tuttavia, in termini di sicurezza, EKS e GKE forniscono un altro livello di sicurezza con i loro servizi di gestione delle chiavi incorporati.

Per quanto riguarda il monitoraggio, Azure e Google Cloud forniscono il proprio ecosistema di monitoraggio attorno a Kubernetes. Vale la pena notare che quello di Google è stato recentemente aggiornato per utilizzare Kubernetes Engine Monitoring, progettato specificamente per Kubernetes.

Azure fornisce il proprio sistema di monitoraggio dei contenitori, originariamente creato per un ecosistema di contenitori di base non Kubernetes. Hanno aggiunto il monitoraggio per alcune metriche e risorse specifiche di Kubernetes (stato del cluster, distribuzioni) in modalità di anteprima, a partire da giugno 2020.

AWS offre un monitoraggio leggero per il piano di controllo direttamente in Cloudwatch. Per monitorare i lavoratori, puoi utilizzare Kubernetes Container Insights Metrics fornito tramite un agente CloudWatch specifico che puoi installare nel cluster.

La migliore scommessa: GKE

Ecosistema

In termini di ecosistemi, i tre fornitori hanno punti di forza e risorse diversi. AKS ora ha una documentazione molto completa sulla sua piattaforma ed è il secondo in termini di post su Stack Overflow. EKS ha il minor numero di post su Stack Overflow, ma beneficia della forza di AWS Marketplace. GKE, in quanto piattaforma più antica, ha il maggior numero di post su Stack Overflow e un numero decente di app sul suo mercato, ma anche la documentazione più completa.

Le migliori scommesse: GKE e EKS

Prezzo

Per quanto riguarda il prezzo complessivo, anche con la mossa di GKE di implementare il prezzo di $ 0,10/ora per qualsiasi cluster, rimane di gran lunga il cloud più economico. Questo grazie a qualcosa di specifico di Google: sconti sull'uso sostenuto, che vengono applicati ogni volta che l'utilizzo mensile delle risorse on demand raggiunge un determinato minimo.

È importante notare che la riga del prezzo di esempio non tiene conto del traffico verso il cluster Kubernetes che il provider di servizi cloud può addebitare.

Il motivo per cui AWS non consente l'uso del loro livello gratuito per testare un cluster EKS è che EKS richiede macchine più grandi del livello tX.micro e il prezzo orario di EKS non è nel livello gratuito.

Tuttavia, può essere comunque economico testare una di queste opzioni Kubernetes gestite con un carico decente utilizzando i nodi spot/prerilasciabili di ciascun provider cloud: questa tattica farà risparmiare facilmente dall'80 al 90 percento sul prezzo finale. (Ovviamente, non è consigliabile eseguire carichi di produzione con stato su tali macchine!)

Funzionalità pubblicizzate e vantaggio di Google

Osservando le diverse funzionalità pubblicizzate online, sembra che ci sia una correlazione tra da quanto tempo la versione gestita di Kubernetes è sul mercato e il numero di funzionalità. Come accennato, il fatto che Google sia stato l'iniziatore del progetto Kubernetes sembra essere un innegabile vantaggio, che si traduce in una migliore e più forte integrazione con la propria piattaforma cloud.

Ma AKS ed EKS non sono da sottovalutare man mano che maturano; entrambi possono sfruttare le loro caratteristiche uniche. Ad esempio, AWS è l'unico ad avere l'integrazione di nodi bare-metal e vanta anche il maggior numero di applicazioni nel suo mercato.

Ora che le funzionalità pubblicizzate per ciascuna offerta Kubernetes sono chiare, facciamo un tuffo più profondo con alcuni test pratici.

Kubernetes: AWS vs GCP vs Azure in pratica

La pubblicità è una cosa, ma come si confrontano le diverse piattaforme quando si tratta di servire carichi di produzione? In qualità di ingegnere del cloud, conosco l'importanza del tempo necessario per la generazione e l'eliminazione di un cluster durante l'applicazione dell'infrastruttura come codice. Ma volevo anche esplorare le possibilità di ciascuna CLI e commentare quanto sia facile (o meno) ogni provider di cloud rende generare un cluster.

Esperienza utente per la creazione di cluster

AKS

In AKS, la generazione di un cluster è simile alla creazione di un'istanza in AWS. Basta trovare il menu AKS e passare attraverso una successione di menu diversi. Una volta convalidata la configurazione, è possibile creare il cluster, un processo in due fasi. È molto semplice e gli ingegneri possono avviare facilmente e rapidamente un cluster con le impostazioni predefinite.

EKS

La creazione di cluster è decisamente più complessa su EKS rispetto a AKS. Prima di tutto, e per impostazione predefinita, AWS richiede prima un viaggio a IAM per creare un nuovo ruolo per il piano di controllo Kubernetes e assegnargli l'ingegnere. È anche importante notare che questa creazione del cluster non include la creazione dei nodi, quindi quando ho misurato in media 11 minuti, questo è solo per la creazione del master. La creazione del gruppo di nodi è un altro passaggio per l'amministratore, che necessita ancora una volta di un ruolo per i lavoratori con tre policy necessarie da realizzare tramite il pannello di controllo IAM.

GKE

Per me, l'esperienza di creare un cluster manualmente è molto piacevole su GKE. Dopo aver trovato Kubernetes Engine in Google Cloud Console, fai clic per creare un cluster. Diverse categorie di impostazioni vengono visualizzate in un menu a sinistra. Google precompilerà il nuovo cluster con un pool di nodi predefinito facilmente modificabile. Ultimo ma non meno importante, GKE ha il tempo di spawn dei cluster più veloce, il che ci porta al tavolo successivo.

È ora di generare un cluster

Ho eseguito questi test nella stessa regione (Francoforte e Europa occidentale per AKS) per rimuovere il possibile impatto di questa differenza sul tempo di spawn. Ho anche provato a selezionare la stessa dimensione per i nodi per il cluster: tre nodi, ciascuno con due vCPU e sette o otto GB di memoria, una dimensione standard per eseguire un piccolo carico su Kubernetes e iniziare a sperimentare. Ho creato ogni cluster tre volte per calcolare una media.

In questi test, GKE è rimasto molto avanti con un tempo di deposizione delle uova sempre inferiore ai tre minuti.

Kubernetes: Panoramica di AWS e GCP e dell'interfaccia a riga di comando di Azure

Non tutte le CLI sono uguali, ma in questo caso tutte e tre le CLI sono in realtà moduli di una CLI più grande. Com'è essere operativi con la toolchain CLI di ciascun provider cloud?

AKS CLI (via az )

Dopo aver installato az tooling, quindi il modulo AKS (tramite az aks install-cli ), gli ingegneri devono autorizzare l'interfaccia della riga di comando a comunicare con l'account Azure del progetto. Si tratta di ottenere le credenziali per aggiornare il file kubeconfig locale tramite un semplice az aks get-credentials --resource-group myResourceGroup --name myAKSCluster .

Allo stesso modo, per creare un cluster: az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI (tramite aws o eksctl )

Su AWS, troviamo un approccio diverso: esistono due diversi strumenti CLI ufficiali per gestire i cluster EKS. Come sempre, aws può connettersi alle risorse AWS, in particolare ai cluster. È possibile ottenere le credenziali in un kubeconfig locale tramite: aws eks update-kubeconfig --name cluster-test .

Tuttavia, gli ingegneri possono anche utilizzare eksctl , sviluppato da Weaveworks e scritto in Go, per creare e gestire facilmente un cluster EKS. Un grande vantaggio offerto da EKS agli ingegneri del cloud è che possono combinarlo con i file di configurazione YAML per creare l'infrastruttura come codice (IaC) poiché funziona con CloudFormation. È sicuramente una risorsa da considerare quando si integra un cluster EKS in un'infrastruttura più ampia su AWS.

Creare un cluster tramite eksctl è facile come eksctl create cluster , non sono richiesti altri parametri.

CLI GKE (tramite gcloud )

Per GKE, i passaggi sono molto simili: installa gcloud , quindi autenticati tramite gcloud init . Le possibilità da lì: gli ingegneri possono creare, eliminare, descrivere, ottenere credenziali, ridimensionare, aggiornare o aggiornare un cluster o elencare i cluster.

La sintassi per creare un cluster con gcloud è semplice: gcloud container clusters create myGCloudCluster --num-nodes=1

AKS vs. EKS vs. GKE: risultati del test drive

In pratica, possiamo vedere che GKE è sicuramente il più veloce per creare un cluster di base, sia in termini di semplicità della console che di tempo di spawn del cluster. Dal punto di vista UX, con il pulsante di connessione accanto al cluster, che rende anche la connessione più semplice a un cluster.

In termini di strumenti CLI, i tre fornitori di cloud hanno implementato funzionalità simili; tuttavia, possiamo porre l'accento sullo strumento aggiuntivo fornito da Weaveworks per EKS. eksctl è lo strumento perfetto per implementare l'infrastruttura come codice sulla tua infrastruttura AWS preesistente, combinando altri servizi con EKS.

Le offerte gestite di Kubernetes vanno avanti: AWS vs GCP vs Azure

Per coloro che hanno appena iniziato nel mondo di Kubernetes, l'implementazione di riferimento per me è GKE, poiché è la più semplice. È facile da configurare, ha un'esperienza utente semplice e veloce per lo spawn ed è ben integrato nell'ecosistema di Google Cloud Platform.

Anche se AWS è stato l'ultimo a unirsi alla gara, ha alcuni vantaggi innegabili, come i nodi bare metal e il semplice fatto che è integrato con il provider con la più grande condivisione mentale.

Infine, AKS ha fatto grandi progressi dalla sua creazione. Probabilmente la parità degli strumenti e delle funzionalità non richiederà molto tempo, lasciando nel frattempo spazio al processo per l'innovazione. E come per qualsiasi offerta Kubernetes gestita, per chi è già sulla piattaforma principale, l'integrazione sarà un punto di forza.

Una volta che un team ha scelto un provider cloud Kubernetes, potrebbe essere interessante esaminare le esperienze degli altri team, in particolare i fallimenti. Questi post mortem sono un riflesso di casi del mondo reale, sempre un buon punto di partenza per sviluppare le proprie best practice all'avanguardia. Aspetto i tuoi commenti qui sotto!