Kubernetes, noto anche come "k8s" o "kube", è una piattaforma di orchestrazione di container per pianificare e automatizzare l'implementazione, la gestione e la scalabilità delle applicazioni containerizzate.
Kubernetes è stato inizialmente sviluppato dagli ingegneri di Google prima di diventare open source nel 2014. È un discendente di Borg, una piattaforma di orchestrazione di container utilizzata internamente in Google. Kubernetes deriva dal greco e significa timoniere o pilota, da cui il timone nel logo Kubernetes (link esterno a ibm.com).
Oggi Kubernetes e il più ampio ecosistema di container stanno maturando in una piattaforma ed ecosistema di elaborazione generale che rivaleggia, se non supera, le macchine virtuali (VM) come elemento di base dell'infrastruttura e delle applicazioni cloud moderne. Questo ecosistema consente alle organizzazioni di fornire una Platform-as-a-Service (PaaS) ad alta produttività che gestisce molteplici attività e problemi relativi alle infrastrutture e alle operazioni nello sviluppo cloud-native, in modo che i team di sviluppo possano concentrarsi esclusivamente sulla codifica e sull'innovazione.
Il video seguente fornisce un'ottima introduzione alle nozioni di base di Kubernetes:
Per gli ingegneri di piattaforma e DevOps che cercano di rendere operativa la velocità di immissione sul mercato garantendo al contempo le prestazioni delle applicazioni.
I container sono componenti di applicazioni leggeri ed eseguibili che combinano il codice sorgente delle applicazioni con tutte le librerie e le dipendenze del sistema operativo necessarie per eseguire il codice in qualsiasi ambiente.
I container sfruttano una forma di virtualizzazione del sistema operativo che consente a più applicazioni di condividere una singola istanza di un sistema operativo isolando i processi e controllando la quantità di CPU, memoria e disco a cui tali processi possono accedere . Poiché sono più piccoli, efficienti in termini di risorse e portabili rispetto alle macchine virtuali (VM), i container sono diventati di fatto le unità di calcolo delle moderne applicazioni cloud-native.
In un recente studio IBM, gli utenti hanno segnalato diversi vantaggi tecnici e di business specifici derivanti dall'adozione dei container e delle tecnologie correlate.
Potrebbe essere più semplice o utile considerare i container come l'ultimo punto del continuum dell'automazione e dell'astrazione dell'infrastruttura IT.
Nell'infrastruttura tradizionale, le applicazioni vengono eseguite su un server fisico e sfruttano tutte le risorse disponibili. In questo modo si può scegliere se eseguire più applicazioni su un singolo server e sperare che una di esse non monopolizzi le risorse a scapito delle altre o se dedicare un server a ogni applicazione, sprecando risorse e senza la possibilità di scalare.
Le macchine virtuali (VM) sono server astratti dall'hardware del computer che consentono di eseguire più macchine virtuali su un server fisico o su una singola macchina virtuale che si estende su più di un server fisico. Ogni macchina virtuale esegue la propria istanza del sistema operativo ed è possibile isolare ciascuna applicazione nella propria VM, riducendo la possibilità che le applicazioni in esecuzione sullo stesso hardware fisico sottostante si influenzino a vicenda. Le VM utilizzano meglio le risorse e sono molto più facili ed economiche da scalare rispetto all'infrastruttura tradizionale. Inoltre, sono usa e getta: quando non è più necessario eseguire l'applicazione, si rimuove la VM.
Per maggiori informazioni sulle VM, vedi "Cosa sono le macchine virtuali?"
I container portano questa astrazione a un livello superiore: in particolare, oltre a condividere l'hardware virtualizzato sottostante, condividono anche un kernel OS sottostante virtualizzato. I container offrono lo stesso isolamento, la stessa scalabilità e la stessa disponibilità delle VM, ma poiché non portano con sé il carico utile della propria istanza del sistema operativo, sono più leggeri (cioè occupano meno spazio) delle macchine virtuali. Sono più efficienti in termini di risorse: consentono di eseguire più applicazioni su meno macchine (virtuali e fisiche), con meno istanze del sistema operativo. I container sono più facilmente trasportabili in ambienti desktop, data center e cloud. Inoltre, si adattano perfettamente alle pratiche di sviluppo Agile e DevOps .
"Cosa sono i container?" fornisce una spiegazione completa sui container e la containerizzazione. Inoltre, il post sul blog "Containers vs. VMs: What's the difference?" fornisce una panoramica completa delle differenze.
Docker è lo strumento più utilizzato per creare ed eseguire container Linux®. Mentre le prime forme di container sono state introdotte decenni fa (con tecnologie come FreeBSD Jails e AIX Workload Partitions), i container sono stati democratizzati nel 2013 quando Docker li ha resi disponibili al pubblico con una nuova implementazione intuitiva per gli sviluppatori e adatta al cloud.
Docker è iniziato come progetto open source, ma oggi si riferisce anche a Docker Inc., la società che produce Docker, un toolkit container commerciale che si basa sul progetto open source (e contribuisce con i suoi miglioramenti alla comunità open source).
Docker è stato costruito sulla tradizionale tecnologia Linux container (LXC), ma consente una virtualizzazione più granulare dei processi del kernel Linux e aggiunge funzioni per semplificare la creazione, l'implementazione, la gestione e la protezione dei container per gli sviluppatori.
Sebbene oggi esistano piattaforme container alternative (come Open Container Initiative (OCI), CoreOS e Canonical (Ubuntu) LXD), Docker è così ampiamente preferito rispetto agli altri da essere praticamente sinonimo di container e talvolta viene scambiato come un concorrente di tecnologie complementari come Kubernetes (vedi il video "Kubernetes vs, Docker: It's Not an Either/Or Question" di seguito).
Con il proliferare dei container - oggi un'organizzazione può averne centinaia o migliaia - i team operativi avevano bisogno di pianificare e automatizzare l'implementazione, il networking, la scalabilità e la disponibilità dei container. Così è nato il mercato dell'orchestrazione dei container.
Sebbene altre opzioni di orchestrazione dei container, in particolare Docker Swarm e Apache Mesos, abbiano guadagnato terreno fin dall'inizio, Kubernetes è diventato rapidamente il più adottato (infatti, a un certo punto, è stato il progetto in più rapida crescita nella storia del software open source).
Gli sviluppatori hanno scelto e continuano a scegliere Kubernetes per la sua vasta gamma di funzionalità, il suo vasto e crescente ecosistema di strumenti di supporto open source e il suo supporto e portabilità tra i provider di servizi cloud. Tutti i principali provider di cloud pubblico, tra cui Amazon Web Services (AWS), Google Cloud, IBM Cloud e Microsoft Azure, offrono servizi Kubernetes completamente gestiti.
Kubernetes pianifica e automatizza le attività relative ai container durante l'intero ciclo di vita delle applicazioni, tra cui:
Se hai letto fin qui, avrai già capito che sebbene Kubernetes sia un'alternativa a Docker Swarm, non è (contrariamente a quanto si pensa) un'alternativa o un concorrente di Docker stesso.
Infatti, se hai adottato con entusiasmo Docker e stai creando distribuzioni di container su larga scala basate su Docker, l'orchestrazione di Kubernetes è il passo logico successivo per la gestione di questi workload.
Per maggiori informazioni, guarda “Kubernetes vs. Docker: It’s Not an Either/Or Question”:
I componenti principali dell'architettura Kubernetes includono:
I cluster sono gli elementi costitutivi dell'architettura Kubernetes. I cluster sono costituiti da nodi, ciascuno dei quali rappresenta un singolo host di calcolo (macchina virtuale o fisica).
Ciascun cluster è costituito da un nodo principale che funge da piano di controllo del cluster e da più nodi di lavoro che distribuiscono, eseguono e gestiscono le applicazioni containerizzate. Il nodo principale esegue un servizio di pianificazione che automatizza quando e dove i container vengono distribuiti in base ai requisiti di distribuzione degli sviluppatori e alla capacità di elaborazione disponibile. Ogni nodo di lavoro include lo strumento utilizzato per gestire i container, ad esempio Docker, e un agente software denominato Kubelet che riceve ed esegue gli ordini dal nodo principale.
Gli sviluppatori gestiscono le operazioni del cluster utilizzando kubectl, un'interfaccia a riga di comando (command-line interface, cli) che comunica direttamente con l'API Kubernetes.
Per un'analisi più approfondita dei cluster Kubernetes, leggi: “Kubernetes Clusters: Architecture for Rapid, Controlled Cloud App Delivery".
I pod sono gruppi di container che condividono le stesse risorse di calcolo e la stessa rete. Sono anche l'unità di scalabilità di Kubernetes: se un container in un pod riceve più traffico di quanto possa gestire, Kubernetes replicherà il pod su altri nodi del cluster. Per questo motivo è buona norma mantenere i pod compatti in modo che contengano solo container che devono condividere risorse.
La distribuzione controlla la creazione e lo stato dell'applicazione containerizzata e la mantiene in esecuzione. Specifica quante repliche di un pod devono essere eseguite sul cluster. Se un pod non riesce, la distribuzione ne creerà uno nuovo.
Per maggiori informazioni sulle distribuzioni Kubernetes, guarda “Kubernetes Deployments: Get Started Fast”:
Kubernetes può distribuire e scalare i pod, ma non è in grado di gestire o automatizzare il routing tra di essi e non fornisce strumenti per monitorare, proteggere o eseguire il debug di queste connessioni. Con l'aumentare del numero di container in un cluster, il numero di possibili percorsi di connessione tra di essi aumenta esponenzialmente (ad esempio, due container hanno due connessioni potenziali, ma 10 pod ne hanno 90), rendendo la configurazione e la gestione estremamente complesse.
È qui che interviene Istio, un livello di mesh di servizi open source per cluster Kubernetes. A ogni cluster Kubernetes, Istio aggiunge un container sidecar, essenzialmente invisibile al programmatore e all'amministratore, che configura, monitora e gestisce le interazioni tra gli altri container.
Con Istio, è impossibile impostare un singolo criterio che configura le connessioni tra container in modo da non dover configurare ogni singola connessione. Questo semplifica il debug delle connessioni tra i container.
Istio fornisce anche un dashboard che i team e gli amministratori DevOps possono usare per monitorare la latenza, gli errori di time-in-service e altre caratteristiche delle connessioni tra i container. Inoltre, integra funzioni di sicurezza, in particolare la gestione delle identità che impedisce agli utenti non autorizzati di effettuare una falsa chiamata di servizio tra container, e funzionalità di autenticazione, autorizzazione e controllo (AAA) che i professionisti della sicurezza possono utilizzare per monitorare il cluster.
Knative (pronunciato 'kay-native') è una piattaforma open source che si basa su Kubernetes e offre due importanti classi di vantaggi per lo sviluppo cloud-native:
Il serverless computing è un modo relativamente nuovo di distribuire il codice che rende le applicazioni cloud native più efficienti e convenienti. Anziché distribuire un'istanza continua di codice che rimane inattiva in attesa di richieste, il serverless utilizza il codice secondo le necessità, aumentandolo o riducendolo in base alle fluttuazioni della domanda, e poi lo elimina quando non viene utilizzato. Serverless evita lo spreco di capacità e potenza di elaborazione e riduce i costi perché si paga solo per eseguire il codice quando è effettivamente in esecuzione.
Knative consente agli sviluppatori di creare un container una sola volta ed eseguirlo come servizio software o come funzione serverless. È tutto trasparente per lo sviluppatore: Knative gestisce i dettagli in background e lo sviluppatore può concentrarsi sul codice.
Per gli sviluppatori, la containerizzazione del codice richiede molti passaggi ripetitivi e l'orchestrazione dei container richiede molta configurazione e scripting (come la generazione di file di configurazione, l'installazione di dipendenze, la gestione della registrazione e del tracciamento e la scrittura di script di integrazione continua/distribuzione continua (CI/CD).)
Knative semplifica queste attività automatizzandole attraverso tre componenti:
Build: il componente Build di Knative trasforma automaticamente il codice sorgente in un container o in una funzione cloud-native. Nello specifico, estrae il codice dal repository, installa le dipendenze necessarie, crea l'immagine container e la inserisce in un container registry a disposizione di altri sviluppatori. Gli sviluppatori devono specificare la posizione di questi componenti in modo che Knative possa trovarli, ma una volta fatto ciò, Knative automatizza la creazione.
Serve: il componente Serve esegue i container come servizi scalabili; può scalare fino a migliaia di istanze di container o ridurle a zero (scaling to zero). Inoltre, Serve ha due funzioni molto utili: la configurazione, che salva le versioni di un container (chiamate snapshot) ogni volta che si invia il container in produzione e consente di eseguire tali versioni contemporaneamente; e il routing del servizio, che consente di indirizzare diverse quantità di traffico verso queste versioni. È possibile utilizzare queste funzioni insieme per effettuare il rollout graduale di un container o per eseguire un canary test di un'applicazione containerizzata prima di metterla in produzione a livello globale.
Event: il componente Event consente di attivare servizi o funzioni basate su container a seguito di eventi specificati. Questo aspetto è particolarmente importante per le funzionalità serverless di Knative; qualcosa deve dire al sistema di richiamare una funzione quando necessario. Event consente ai team di esprimere il proprio interesse per i tipi di eventi, quindi si connette automaticamente al produttore di eventi e indirizza gli eventi al container, eliminando la necessità di programmare queste connessioni.
Kubernetes è uno dei progetti open source in più rapida crescita nella storia e la sua crescita sta accelerando. È sempre più adottato dagli sviluppatori e dalle aziende in cui lavorano. Alcuni dati degni di nota:
Se desideri iniziare a lavorare con Kubernetes o migliorare le tue competenze con Kubernetes e gli strumenti dell'ecosistema Kubernetes, prova uno di questi tutorial:
Con Red Hat OpenShift on IBM Cloud, gli sviluppatori OpenShift hanno a disposizione un modo rapido e sicuro per containerizzare e implementare i carichi di lavoro aziendali nei cluster Kubernetes.
Distribuisci ed esegui app in modo coerente negli ambienti on-premise, di edge computing e cloud pubblico di qualsiasi fornitore di cloud, utilizzando un set comune di servizi cloud tra cui toolchain, database e intelligenza artificiale.
IBM Cloud Code Engine, piattaforma serverless completamente gestita, ti consente di eseguire il container, il codice dell'applicazione o il job batch su un runtime del container completamente gestito.
Una nuova ricerca IBM documenta il crescente slancio dell’adozione di container e Kubernetes.
I container fanno parte di una strategia di cloud ibrido che ti consente di creare e gestire i carichi di lavoro ovunque ti trovi.
Il serverless è un modello di sviluppo ed esecuzione di applicazioni cloud che consente agli sviluppatori di creare ed eseguire codice senza gestire server e senza dover pagare per le infrastrutture cloud inattive.
Esplora un esempio di utilizzo di un file YAML in Kubernetes.