L’ascesa dei container ha ridisegnato il modo in cui le persone pensano allo sviluppo, all’implementazione e alla manutenzione del software. Attingendo alle funzionalità di isolamento nativo dei moderni sistemi operativi, i container supportano la separazione dei problemi in stile VM, ma con un sovraccarico molto inferiore e una flessibilità di distribuzione molto maggiore rispetto alle macchine virtuali basate su hypervisor.

I container sono così leggeri e flessibili che hanno dato vita a nuove architetture applicative. Il nuovo approccio consiste nel raggruppare i diversi servizi che costituiscono un’applicazione in container separati e nel distribuire tali container attraverso un cluster di macchine fisiche o virtuali. Ciò ha portato alla necessità di orchestrazione dei container, ovvero di uno strumento che automatizzi la distribuzione, la gestione, il ridimensionamento, il networking e la disponibilità di applicazioni basate su container.

Leggi anche: Tutorial Kubernetes: cos’è e come inziare a usarlo

Kubernetes è un progetto open source realizzato da Google che automatizza il processo di distribuzione e gestione di applicazioni multi-container su vasta scala. Sebbene Kubernetes funzioni principalmente con Docker, può funzionare anche con qualsiasi sistema di container conforme agli standard OCI (Open Container Initiative) per i formati di immagine e i runtime dei container. E poiché Kubernetes è open source, con relativamente poche restrizioni su come può essere utilizzato, chiunque voglia ricorrere ai container lo può usare.

Kubernetes vs Docker

Precisiamo che Kubernetes non è un rimpiazzo per Docker. Tuttavia, Kubernetes sostituisce alcune delle tecnologie di livello superiore emerse in Docker. Una di queste tecnologie è Docker Swarm, un orchestratore in bundle con Docker. È ancora possibile utilizzare Swarm anziché Kubernetes, ma Docker Inc. ha scelto di rendere Kubernetes parte delle edizioni Docker Community e Docker Enterprise in futuro.

Non che Kubernetes sia un sostituto di Swarm. Kubernetes è significativamente più complesso di Swarm e richiede più lavoro per la sua implementazione, ma questo sforzo iniziale è destinato a fornire un grande profitto nel lungo periodo (essenzialmente un’infrastruttura applicativa più gestibile e resiliente). Per lavori di sviluppo e cluster di container più piccoli, Docker Swarm rappresenta ancora una scelta più semplice da implementare.

Cosa fa Kubernetes per i container?

Kubernetes fornisce astrazioni di alto livello per la gestione di gruppi di container che consentono agli utenti di concentrarsi sul modo in cui desiderano eseguire le applicazioni, piuttosto che preoccuparsi dei dettagli specifici dell’implementazione. Ecco alcuni dei compiti che Kubernetes può automatizzare e semplificare.

  • Distribuire applicazioni multi-container. Molte applicazioni non risiedono in un solo container, ma sono costituite da diversi container (un database, un front-end web, forse un server cache). Anche i microservizi sono costruiti in questo modo, tipicamente basandosi su database separati per ciascun servizio e su protocolli web e API per legare insieme i servizi. Anche se ci sono vantaggi a lungo termine nella creazione di app come microservizi, nel breve termine il lavoro da compiere è notevole.
  • Kubernetes riduce la quantità di lavoro necessaria per implementare tali applicazioni. Dite a Kubernetes come comporre un’app partendo da un set di container e Kubernetes si occuperà del “lavoro pesante” che serve per mantenerli in esecuzione e mantenere sincronizzati i componenti l’uno con l’altro.
  • Scalare le app in container. Le app devono essere in grado di crescere e decrescere per soddisfare la domanda, bilanciare il carico in entrata e utilizzare meglio le risorse fisiche. Kubernetes ha precise disposizioni per fare tutte queste cose e per farle in modo automatico e senza complicazioni.
  • Distribuire nuove versioni di app senza tempi di inattività. Parte dell’attrattiva di un flusso di lavoro per lo sviluppo di applicazioni basato su container è consentire la continuità dell’integrazione e della consegna. Kubernetes ha meccanismi tali da consentire aggiornamenti alle nuove versioni delle immagini del container, compresi i rollback se qualcosa non va come previsto.
  • Fornire networking, individuazione dei servizi e archiviazione. Kubernetes gestisce molti altri dettagli pratici di app basate su container. Fare in modo che i container parlino tra loro, gestire l’individuazione dei servizi e fornire spazio di archiviazione persistente al container sono tutte operazioni gestite tramite Kubernetes e le sue API.
  • Fare tutto questo nella maggior parte degli ambienti. Kubernetes non è legato a uno specifico ambiente o tecnologia cloud. Può essere eseguito ovunque ci sia il supporto per i container, il che significa che cloud pubblici, cloud privati, hardware virtuale e fisico e un laptop per singolo sviluppatore sono tutti ambienti in cui è possibile utilizzare Kubernetes. I cluster di Kubernetes possono anche funzionare con qualsiasi combinazione di questi ambienti (compreso ad esempio un mix di sistemi Windows e Linux).

Come funziona Kubernetes

L’architettura di Kubernetes utilizza vari concetti. Alcuni di questi sono variazioni su nozioni familiari e già note, ma altri sono specifici di Kubernetes. L’astrazione di Kubernetes di livello più alto (il cluster) fa riferimento al gruppo di macchine che eseguono Kubernetes (a sua volta un’applicazione in cluster) e ai container gestiti da esso. Un cluster Kubernetes deve avere un master, ovvero il sistema che comanda e controlla tutte le altre macchine Kubernetes nel cluster. Un cluster Kubernetes altamente disponibile replica le strutture del master su più macchine.

Leggi anche: Red Hat CodeReady Workspaces è il primo IDE nativo per Kubernetes

Ogni cluster contiene nodi Kubernetes. I nodi potrebbero essere macchine fisiche o VM. Ancora una volta, l’idea è l’astrazione: qualunque sia l’applicazione in esecuzione, Kubernetes gestisce la distribuzione su quel substrato. È anche possibile garantire che determinati container vengano eseguiti solo su macchine virtuali o solo su macchine fisiche.

I nodi eseguono pod, gli elementi più basilari di Kubernetes che possono essere creati o gestiti. Ogni pod rappresenta una singola istanza di un’applicazione o un processo in esecuzione in Kubernetes ed è formato da uno o più container. Kubernetes avvia, arresta e replica tutti i container in un pod come gruppo. I pod dirigono l’attenzione dell’utente sull’applicazione, piuttosto che sui container stessi. I dettagli su come Kubernetes deve essere configurato, dallo stato dei pod in su, sono conservati nello store distribuito Etcd.

I pod vengono creati e distrutti sui nodi in base alle esigenze per conformarsi allo stato specificato dall’utente nella definizione del pod. Kubernetes fornisce un’astrazione chiamata controller per gestire la modalità con la quale i pod vengono fatti girare. I controller sono disponibili in diversi tipi a seconda del tipo di applicazione gestita. Ad esempio, il controller StatefulSet introdotto di recente viene utilizzato per gestire le applicazioni che richiedono uno stato permanente. Un altro tipo di controller (deployment) viene utilizzato per ridimensionare un’app verso l’alto o verso il basso, aggiornare un’app a una nuova versione o ripristinare un’applicazione a una versione precedente nel caso sorgessero problemi con la nuova release.

Poiché i pod vivono e muoiono a seconda delle esigenze, c’è bisogno di un’astrazione diversa per affrontare il ciclo di vita delle applicazioni. Un’applicazione dovrebbe essere un’entità persistente anche quando i pod che eseguono i container che compongono l’applicazione non sono essi stessi persistenti. A tal fine Kubernetes offre un’astrazione chiamata service.

Un service descrive il modo in cui un determinato gruppo di pod (o altri oggetti di Kubernetes) è accessibile tramite la rete. Come si legge nella documentazione di Kubernetes, i pod che costituiscono il back-end di un’applicazione potrebbero cambiare, ma il front-end non dovrebbe saperlo. I service rendono ciò possibile.

Alcuni altri componenti interni a Kubernetes completano lo scenario. Lo scheduler distribuisce i carichi di lavoro ai nodi in modo che siano bilanciati tra le risorse e in modo che le distribuzioni soddisfino i requisiti delle definizioni dell’applicazione. Il controller manager garantisce invece che lo stato del sistema (applicazioni, carichi di lavoro) corrisponda allo stato definito nelle impostazioni di configurazione Etcd.

È importante tenere presente che nessuno dei meccanismi di basso livello utilizzati dai container, come Docker stesso, viene sostituito da Kubernetes. Piuttosto, Kubernetes fornisce un set più ampio di astrazioni per il loro utilizzo al fine di mantenere le app in esecuzione su larga scala.

Come Kubernetes semplifica le app in container

Poiché Kubernetes introduce nuove astrazioni e concetti e poiché la curva di apprendimento per Kubernetes è elevata, è normale chiedersi quali siano i profitti a lungo termine nell’utilizzo di Kubernetes. Ecco alcuni dei modi specifici in cui Kubernetes facilità l’esecuzione delle app.

  • Kubernetes gestisce l’integrità delle app, la replica, il bilanciamento del carico e l’allocazione delle risorse hardware.Uno dei compiti fondamentali di Kubernetes è il lavoro per mantenere un’applicazione, farla funzionare e rispondere alle richieste degli utenti. Le app che diventano “malsane”, o non conformi alla definizione di salute che avete deciso per loro, possono essere automaticamente sanate. Un altro vantaggio offerto da Kubernetes è la massimizzazione dell’uso di risorse hardware tra cui memoria, archiviazione e larghezza di banda della rete. Le applicazioni possono avere limiti più o meno stringenti per quanto riguarda l’utilizzo delle risorse. Molte app che utilizzano risorse minime possono essere raggruppate insieme sullo stesso hardware, mentre le app che devono crescere possono invece essere collocate in sistemi in cui hanno spazio sufficiente per evolvere. Anche distribuire gli aggiornamenti attraverso un cluster o eseguire il rollback se gli update si rivelano problematici sono tutte azioni che possono essere automatizzate.
  • I grafici Helm di Kubernetes facilitano la distribuzione di applicazioni preconfigurate. I gestori di pacchetti come l’APT di Debian Linux e il Pip di Python risparmiano agli utenti il peso di installare e configurare manualmente un’applicazione. Ciò è particolarmente utile quando un’applicazione ha più dipendenze esterne. Helm è una sorta di gestore di pacchetti per Kubernetes. Molte applicazioni software devono essere eseguite come contenitori multipli e raggruppati in Kubernetes. Helm fornisce un meccanismo di definizione (un grafico) che descrive come un dato pezzo di software può essere eseguito come un gruppo di container all’interno di Kubernetes. È possibile creare da soli i propri grafici Helm e potrebbe essere necessario farlo se si sta costruendo un’app personalizzata da distribuire internamente. Ma se state usando un’applicazione popolare con un modello di distribuzione comune, c’è una buona probabilità che qualcuno abbia già composto un grafico Helm per esso e lo abbia pubblicato su Kubeapps.com.
  • Kubernetes semplifica la gestione dello storage e di altre risorse relative alle applicazioni. I container sono pensati per essere immutabili; qualunque cosa mettiate al loro interno infatti non dovrebbe mai cambiare. Ma le applicazioni hanno bisogno di un modo affidabile per gestire i volumi di archiviazione esterni. Ciò è reso ancora più complicato dal modo in cui i container vivono, muoiono e rinascono per tutta la durata di un’app. Kubernetes dispone di astrazioni per consentire a container e app di gestire lo spazio di archiviazione nello stesso modo disaccoppiato di altre risorse. È possibile accedere a molti tipi comuni di storage, dai volumi Amazon EBS alle semplici condivisioni NFS, tramite i driver di archiviazione Kubernetes, detti volumi. Normalmente, i volumi sono associati a un pod specifico, ma un sottotipo di volume chiamato Persistent Volume può essere utilizzato per i dati che devono vivere indipendentemente da qualsiasi pod. I container spesso hanno bisogno di lavorare con i cosiddetti secrets (credenziali come le chiavi API o le password di servizio). Mentre per questo sono disponibili soluzioni di terze parti, come Docker secrets e HashiCorp Vault, Kubernetes ha il proprio meccanismo per la gestione nativa dei secrets, sebbene debba essere configurato con attenzione. Ad esempio, Etcd deve essere configurato per utilizzare SSL/TLS quando si inviano informazioni che includono dei secrets tra i nodi.
  • Le app di Kubernetes possono essere eseguite in ambienti ibridi e multi-cloud. Uno degli obiettivi più ambiziosi e agognati del cloud computing è la possibilità di eseguire qualsiasi app in qualsiasi ambiente cloud o qualsiasi combinazione di cloud pubblici o privati. Questo non solo per evitare il lock-in del fornitore, ma anche per sfruttare le funzionalità specifiche dei singoli cloud. Kubernetes fornisce un set di primitive, noto come federation, per mantenere sincronizzati più cluster tra più regioni e cloud. Ad esempio, una determinata distribuzione dell’app può essere mantenuta coerente tra più cluster, e cluster diversi possono condividere l’individuazione del servizio in modo che sia possibile accedere a una risorsa back-end da qualsiasi cluster. La federation può anche essere utilizzata per creare distribuzioni Kubernetes ad alta disponibilità o fault-tolerant, indipendentemente dal fatto che ci si stia muovendo in più ambienti cloud. La federation è ancora un aspetto relativamente nuovo per Kubernetes. Non tutte le risorse API sono supportate su istanze federate e gli aggiornamenti non dispongono ancora di un’infrastruttura di test automatica, ma queste carenze sono destinate a essere superate nelle versioni future di Kubernetes.

Dove trovare Kubernetes

Kubernetes è disponibile in una così vasta gamma di ambienti e con così tanti meccanismi di consegna, che il modo migliore per capire dove ottenerlo è a seconda dei vari casi d’uso.

  • Se volete fare tutto da soli: il codice sorgente può essere scaricato dal repository GitHub per Kubernetes.
  • Se state usando Docker Community o Docker Enterprise: le edizioni più recenti di Docker sono fornite con Kubernetes in forma di pacchetto. Questo è il modo più semplice per ottenere Kubernetes, dal momento che è associato a un prodotto con cui quasi sicuramente avete già una certa familiarità.
  • Se siete in un ambiente on-premise o in un cloud privato: è probabile che l’infrastruttura che state utilizzando per il vostro cloud privato o per i vostri sistemi in-house abbia incorporato Kubernetes. Ad esempio, CoreOS Tectonic utilizza una distribuzione Linux incentrata sui container con Kubernetes, fornendo un modo automatico per configurare e distribuire Kubernetes sul proprio hardware. Anche Red Hat Enterprise Linux Atomic Host e Mirantis Cloud Platform (una distribuzione di OpenStack) forniscono Kubernetes.
  • Se siete in un ambiente cloud pubblico: i tre principali fornitori di cloud pubblico ora offrono Kubernetes come servizio. Google Cloud Platform offre Google Kubernetes Engine, Microsoft Azure offre Azure Container Service, con Kubernetes come una delle numerose possibili scelte di orchestrazione. Amazon infine ha annunciato recentemente il supporto per Kubernetes in concomitanza con il suo attuale Elastic Container Service, ora disponibile in versione preview e atteso in forma definitiva entro fine anno.