🥇Kubernetes: open source contro fornito

Ciao, mi chiamo Dmitry Krasnov. Da oltre cinque anni mi occupo di amministrazione di cluster Kubernetes e costruzione di architetture complesse a microservizi. All'inizio di quest'anno abbiamo lanciato un servizio per la gestione di cluster Kubernetes basato su Containerum. Colgo l'occasione per spiegare cosa sia esattamente Kubernetes e in che modo l'integrazione con il fornitore differisca dall'open source.

Per iniziare, che cos'è Kubernetes. È un sistema per la gestione di container su un gran numero di host. In greco, tra l'altro, si traduce come ‘pilota’ o ‘timoniere’. È stato originariamente sviluppato da Google, dopo di che è stato trasferito come contributo tecnologico alla Cloud Native Computing Foundation, un'organizzazione internazionale senza scopo di lucro che riunisce i principali sviluppatori, utenti finali e fornitori di tecnologie per container.

Gestire un gran numero di container

Adesso analizziamo cosa siano effettivamente questi container. Si tratta di un'applicazione con tutto il suo ambiente, principalmente le librerie di cui dipende il funzionamento del programma. Tutto questo è impacchettato in archivi e presentato come un'immagine, che può essere avviata indipendentemente dal sistema operativo, testata e altro ancora. Ma c'è un problema: gestire i container su un gran numero di host è molto complicato. Per questo è stato creato Kubernetes.

Un'immagine del container rappresenta un'applicazione più le sue dipendenze. L'applicazione, le sue dipendenze e l'immagine del file system del sistema operativo sono collocate in parti diverse dell'immagine, chiamate strati. Gli strati possono essere riutilizzati per diversi container. Ad esempio, per tutte le applicazioni in azienda, si potrebbe usare uno strato di base Ubuntu. Quando si avviano i container, non è necessario conservare su host molteplici copie di uno stesso strato di base. Questo consente di ottimizzare memorizzazione e distribuzione delle immagini.

Quando vogliamo avviare un'applicazione da un container, gli strati necessari si sovrappongono l'uno all'altro e si forma un file system sovrapposto. Sopra di esso si sovrappone uno strato per la scrittura, che, al momento dell'arresto del container, viene eliminato. Questo garantisce che l'applicazione all'interno del container abbia sempre lo stesso ambiente, che non può essere modificato. Questo assicura la riproducibilità dell'ambiente su diversi sistemi operativi host. Che si tratti di Ubuntu o CentOS, l'ambiente sarà sempre lo stesso. Inoltre, il container è isolato dall'host tramite meccanismi integrati nel kernel di Linux. Le applicazioni nel container non vedono i file, i processi dell'host e dei container vicini. Tale isolamento delle applicazioni dall'OS host fornisce un ulteriore strato di sicurezza.

Per gestire i container su un host ci sono molti strumenti. Il più popolare è Docker. Permette di garantire l'intero ciclo di vita dei container. Tuttavia, funziona solo su un singolo host. Quando è necessario gestire container su più host, Docker può trasformare la vita degli ingegneri in un inferno. Per questo è stato creato Kubernetes.

La domanda di Kubernetes è stata determinata dalla possibilità di gestire gruppi di container su più host come se fossero un'unica entità. La popolarità del sistema consente di costruire DevOps o Development Operations, nei quali Kubernetes è impiegato per avviare i processi di DevOps.

Figura 1. Rappresentazione schematica del principio di funzionamento di Kubernetes

Automazione completa

Il DevOps, in linea di massima, rappresenta l'automazione del processo di sviluppo. In soldoni, gli sviluppatori scrivono codice, che viene caricato in un repository. Poi questo codice può essere automaticamente assemblato in un container con tutte le librerie, testato e ‘distribuito’ alla fase successiva – Staging, e poi immediatamente su Production.

Insieme a Kubernetes, il DevOps consente di automatizzare questo processo, in modo che avvenga praticamente senza coinvolgimento diretto degli sviluppatori. Ciò accelera significativamente l'assemblaggio, poiché allo sviluppatore non è richiesto di farlo sul proprio computer: scrive semplicemente del codice, carica il codice nel repository, al termine del quale si avvia la pipeline, che può includere i processi di assemblaggio, test e distribuzione. E così succede con ogni commit, quindi il testing è continuo.

L'utilizzo di un container garantisce che l'intero ambiente di questa applicazione venga messo in produzione esattamente nella forma in cui è stato testato. Non ci saranno problemi del tipo «in test c'erano versioni diverse, in produzione – altre, e una volta implementato, tutto è crollato». Con la crescente tendenza verso l'architettura a microservizi, dove invece di un'unica grande applicazione ci sono centinaia di piccole, l'amministrazione manuale richiede un enorme numero di personale. Ecco perché utilizziamo Kubernetes.

Vantaggi, vantaggi, vantaggi

Parlando dei punti di forza di Kubernetes come piattaforma, ha vantaggi significativi in termini di gestione dell'architettura a microservizi.

Gestione di molteplici repliche. La cosa più importante è la gestione dei container su più host. E ciò che conta di più è gestire molteplici repliche delle applicazioni all'interno dei container come un'unica entità. Grazie a questo, gli ingegneri non devono preoccuparsi di ciascun container singolarmente. Se uno dei container si arresta, Kubernetes lo rileva e lo riavvia.
Rete di cluster. Inoltre, Kubernetes dispone di una rete di cluster con uno spazio indirizzabile proprio. In questo modo, ogni pod ha il proprio indirizzo. Per pod si intende l'unità strutturale minima del cluster in cui vengono eseguiti i container. Inoltre, Kubernetes offre funzionalità che combinano un bilanciatore di carico e Service Discovery. Questo elimina la necessità di gestire manualmente gli indirizzi IP, delegando questo compito a Kubernetes. I controlli automatici sull'affidabilità aiutano a rilevare problemi e a reindirizzare il traffico verso i pod attivi.
Gestione delle configurazioni. Gestire un gran numero di applicazioni rende difficile la gestione della loro configurazione. Per questo, Kubernetes prevede risorse speciali chiamate ConfigMap. Queste consentono di archiviare centralmente le configurazioni e inserirle nei pod al momento dell'avvio delle applicazioni. Questo meccanismo garantisce coerenza della configurazione, sia che ci siano dieci o cento repliche delle applicazioni.
Volume persistenti. I container sono intrinsecamente immutabili e quando un container si arresta, tutti i dati scritti nel file system vengono distrutti. Ma alcune applicazioni memorizzano i dati direttamente sul disco. Per affrontare questo problema, Kubernetes offre funzionalità di gestione dello storage – i Volume Persistenti. Questo meccanismo utilizza uno storage esterno per i dati e può fornire ai container uno storage persistente, a livello block o file. Questo approccio consente di mantenere i dati separati dai worker, proteggendoli in caso di guasto dei worker stessi.
Bilanciatore di carico. Sebbene in Kubernetes gestiamo entità astratte come Deployment, StatefulSet, ecc., alla fine i container vengono eseguiti su normali macchine virtuali o server fisici. Questi non sono perfetti e possono guastarsi in qualsiasi momento. Kubernetes lo rileva e reindirizza il traffico interno ad altre repliche. Ma cosa fare con il traffico che proviene dall'esterno? Se indirizziamo semplicemente il traffico a uno dei worker, cosa succede se si guasta, rendendo il servizio non disponibile? Per risolvere questo problema, Kubernetes offre servizi come il Load Balancer. Questi sono progettati per configurare automaticamente un bilanciatore di carico cloud esterno per tutti i worker nel cluster. Questo bilanciatore esterno dirige il traffico esterno verso i worker e monitora il loro stato. Se uno o più worker diventano non disponibili, il traffico viene reindirizzato verso altri. Questo consente di creare servizi ad alta disponibilità utilizzando Kubernetes.

Kubernetes si esprime al meglio proprio nell'esecuzione di architetture a microservizi. Implementare il sistema in un'architettura classica è possibile, ma privo di senso. Se un'applicazione non può funzionare in più repliche, qual è la differenza tra usarlo o meno?

Kubernetes open source

Kubernetes open source è un'ottima cosa: lo installi e funziona. Puoi implementarlo sui tuoi server fisici, sulla tua infrastruttura, impostare un master e worker sui quali verranno eseguite tutte le applicazioni. E la cosa più importante è che tutto ciò è gratuito. Tuttavia, ci sono alcune considerazioni.

Primo: la necessità di conoscenze ed esperienze da parte degli amministratori e degli ingegneri che gestiranno e supporteranno tutto questo. Poiché il cliente ha piena libertà di azione nel cluster, la responsabilità per il funzionamento del cluster ricade su di lui. E qui è facilissimo causare guasti.
Secondo: l'assenza di integrazioni. Se avvii Kubernetes senza una piattaforma di virtualizzazione popolare, non otterrai tutti i vantaggi del programma, come l'utilizzo di Volume Persistenti e servizi di Load Balancer.

Figura 2. Architettura k8s

Kubernetes del fornitore

L'integrazione con il fornitore cloud offre due possibilità:

In primo luogo, l'utente può semplicemente premere il pulsante 'crea cluster' e ottenere un cluster già configurato e pronto per l'uso.
In secondo luogo, il fornitore installa il cluster e configura l'integrazione con il cloud.

Ecco come funziona da noi. L'ingegnere che avvia il cluster specifica quanti worker sono necessari e con quali parametri (ad esempio, 5 worker, ognuno con 10 CPU, 16 GB di RAM e, diciamo, 100 GB di disco). Dopodiché ottiene accesso al cluster già formato. In questo caso, i worker su cui viene eseguito il carico di lavoro sono totalmente a disposizione del cliente, ma tutto il management plane rimane sotto la responsabilità del fornitore (nel caso in cui il servizio sia fornito secondo il modello di servizio gestito).

Tuttavia, questo schema presenta i suoi svantaggi. Poiché il management plane rimane presso il fornitore, quest'ultimo non fornisce accesso completo al cliente, riducendo così la flessibilità nella gestione di Kubernetes. A volte capita che il cliente voglia integrare qualche funzionalità specifica in Kubernetes, ad esempio, l'autenticazione tramite LDAP, ma la configurazione del management plane non lo consente.

Figura 3. Esempio di cluster Kubernetes fornito da un fornitore cloud

Cosa scegliere: open source o fornito?

Quindi, Kubernetes open source o fornito? Se si opta per Kubernetes open source, l'utente può fare ciò che vuole. Ma c'è un alto rischio di danneggiarsi. Con il fornitore è più complesso, poiché tutto è stato ben progettato e configurato. Il maggiore svantaggio di Kubernetes open source è la richiesta di specialisti. Con il fornitore, l'azienda si libera di questo problema, ma dovrà decidere: pagare specialisti interni o al fornitore.

Bene, i vantaggi sono ovvi, anche gli svantaggi sono noti. Una cosa è certa: Kubernetes risolve molti problemi automatizzando la gestione di molti container. Quale scegliere, open source o fornito, è una decisione personale.