Kubernetes, noto anche come "k8s" o "kube", è una piattaforma di orchestrazione di container per la pianificazione e l'automazione dell'implementazione, gestione e scalabilità delle applicazioni containerizzate.
Kubernetes è stato sviluppato inizialmente dagli ingegneri di Google, prima di diventare open source nel 2014. Deriva da Borg, una piattaforma di orchestrazione di container utilizzata internamente da Google. Kubernetes è il termine greco per timoniere oppure pilota, perciò il logo Kubernetes contiene un timone (link esterno a ibm.com).
.Oggi, Kubernetes e il più ampio ecosistema di container si stanno evolvendo in una piattaforma di calcolo e in un ecosistema per uso generale che compete - o addirittura supera- le VM come elementi costitutivi di base delle moderne infrastrutture e applicazioni cloud. Questo ecosistema consente alle organizzazioni di fornire una PaaS (Platform-as-a-Service) a elevata produttività che affronta molteplici attività e problemi correlati alle infrastrutture e alle operazioni collegate allo sviluppo nativo del cloud in modo che i team di sviluppo possano concentrarsi esclusivamente sulla codifica e sull'innovazione.
Il seguente video fornisce un'ottima introduzione alle nozioni di base di Kubernetes:
I container sono componenti applicativi leggeri ed eseguibili che combinano il codice sorgente dell'applicazione con tutte le librerie del sistema operativo e le dipendenze necessarie per eseguire il codice in qualsiasi ambiente.
I container si avvalgono di 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. Perché sono più piccoli, più efficienti in termini di risorse e più portabili delle VM, i container sono diventati di fatto l'unità di calcolo delle moderne applicazioni native del cloud.
In un recente studio di IBM (PDF, 1,4 MB), gli utenti hanno segnalato diversi vantaggi tecnici e di business specifici derivanti dall'adozione dei container e delle tecnologie correlate.
Può essere più facile o più utile considerare i container come l'ultima fase del processo di automazione e astrazione dell'infrastruttura IT.
Nelle infrastrutture tradizionali, le applicazioni vengono eseguite su un server fisico e utilizzano tutte le risorse che riescono a ottenere. Ciò ti lascia la scelta di eseguire più applicazioni su un singolo server, sperando che un'applicazione non utilizzi risorse a discapito delle altre, o di dedicare un server per ogni applicazioni, il che però comporta una condizione di spreco di risorse e assenza di scalabilità.
Le VM sono server astratti dall'hardware del computer effettivo, consentendoti di eseguire più VM su un unico server fisico o una singola VM che si estende su più di un server fisico. Ogni VM esegue la propria istanza del sistema operativo e puoi isolare ciascuna applicazione in una propria VM, riducendo la possibilità che le applicazioni in esecuzione sullo stesso hardware fisico sottostante si influenzino a vicenda. Le VM fanno un uso migliore delle risorse e sono molto più facili ed economicamente convenienti da scalare rispetto all'infrastruttura tradizionale. E sono eliminabili - quando non hai più bisogno di eseguire l'applicazione, disattivi la VM.
Per ulteriori informazioni sulle VM, consulta "Cosa sono le VM?"
I container portano questa astrazione a un livello superiore e, nello specifico, oltre a condividere l'hardware virtualizzato sottostante, condividono anche un kernel del sistema operativo virtualizzato sottostante. I container offrono lo stesso isolamento, la stessa scalabilità e la stessa eliminabilità delle VM, ma poiché non portano il payload di una loro istanza del sistema operativo, sono più leggeri (cioè occupano meno spazio) rispetto alle VM. Sono più efficienti in termini di risorse e consentono di eseguire più applicazioni su meno macchine (virtuali e fisiche), con meno istanze del sistema operativo. I container sono più facilmente portabili tra desktop, data center e ambienti cloud. Sono la soluzione ideale per i metodi di sviluppo Agile e DevOps.
"Cosa sono i container?" fornisce una spiegazione completa di container e containerizzazione. E il post del blog "Container vs VM: What's the difference?" fornisce un resoconto completo delle differenze.
Docker è lo strumento più utilizzato per la creazione e l'esecuzione di container Linux®. Mentre le forme iniziali di container sono state introdotte decenni fa (con tecnologie quali FreeBSD Jails e le partizioni del carico di lavoro di AIX), i container sono diventati di dominio pubblico nel 2013 quando Docker li ha resi comunemente disponibili con una nuova implementazione adatta a sviluppatori e cloud.
Docker è iniziato come progetto open source, ma oggi è di proprietà di Docker Inc., la società che produce Docker, un toolkit di container commerciale basato sul progetto open source (e sui contributi e i miglioramenti della community open source).
Docker è basato sulla tecnologia LXC (Linux Container) tradizionale, ma assicura una virtualizzazione maggiormente granulare dei processi del kernel Linux e aggiunge funzioni per consentire agli sviluppatori di eseguire attività di creazione, implementazione, gestione e protezione più facilmente.
Nonostante oggi esistano piattaforme di container alternative (quali OCI (Open Container Initiative), CoreOS e Canonical (Ubuntu) LXD), Docker è così ampiamente preferito che è praticamente diventato sinonimo di container e a volte viene scambiato per un concorrente di tecnologie gratuite come Kubernetes (guarda il video "Kubernetes vs, Docker: It's Not an Either/Or Question").
Poiché i container proliferavano - oggi, un'organizzazione potrebbe averne a centinaia o migliaia - i team operativi hanno dovuto pianificarne e automatizzarne l'implementazione, il collegamento di rete, la scalabilità e la disponibilità. Così è nato il mercato dell'orchestrazione dei container.
Mentre altre opzioni di orchestrazione dei container - in particolare Docker Swarm e Apache Mesos - hanno ottenuto un certo consenso nella fase iniziale, Kubernetes è diventata rapidamente la piattaforma più adottata (infatti, a un certo punto, è stato il progetto in più rapida crescita nella storia del software open source).
Gli sviluppatori hanno scelto di continuare a preferire Kubernetes per la sua ampiezza di funzionalità, il suo vasto e crescente ecosistema di strumenti di supporto open source e il suo supporto e la sua portabilità tra i provider di servizi cloud . Tutti i principali provider di cloud pubblico - inclusi AWS (Amazon Web Services), Google Cloud, IBM Cloud e Microsoft Azure - offrono servizi Kubernetes completamente gestiti.
Kubernetes pianifica e automatizza attività correlate ai container in tutto il ciclo di vita dell'applicazione , tra cui:
Se hai letto questo documento fino a questo punto, hai già capito che mentre Kubernetes è un'alternativa al Docker Swarm, non è (contrariamente al persistente malinteso comune) un'alternativa o un concorrente di Docker stesso.
Infatti, se hai scelto con entusiasmo Docker e stai creando implementazioni di container su larga scala basate su Docker, l'orchestrazione di Kubernetes è un passo logico successivo per la gestione di questi carichi di lavoro.
Per ulteriori 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 composti da nodi, ognuno dei quali rappresenta un singolo host di calcolo (macchina virtuale o fisica).
Ogni cluster è costituito da un nodo master che funge da piano di controllo per il cluster, e da molteplici nodi di lavoro che implementano, eseguono e gestiscono applicazioni containerizzate. Il nodo master esegue un servizio di programma di pianificazione che automatizza quando e dove i container vengono implementati in base ai requisiti di implementazione impostati dagli sviluppatori e alla capacità di calcolo disponibile. Ciascun nodo di lavoro include lo strumento che viene utilizzato per gestire i container - come ad esempio Docker - e un agent software denominato Kubelet che riceve ed esegue ordini dal nodo master.
Gli sviluppatori gestiscono le operazioni cluster utilizzando kubectl, un'interfaccia di riga comandi (cli) che comunica direttamente con l'API Kubernetes.
Per un ulteriore approfondimento sui 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à in Kubernetes: se un container in un pod sta ricevendo più traffico di quanto ne possa gestire, Kubernetes replicherà il pod su altri nodi nel cluster. Per questo motivo si consiglia di mantenere compatti i pod, in modo che contengano solo i container che devono condividere le risorse.
L'implementazione controlla la creazione e lo stato dell'applicazione containerizzata e la mantiene in esecuzione. Specifica quante repliche di un pod devono essere gestite sul cluster. Se si verifica un malfunzionamento di un pod, l'implementazione ne creerà uno nuovo.
Per ulteriori informazioni sulle implementazioni Kubernetes, guarda "Kubernetes Deployments: Get Started Fast":
Kubernetes può implementare e scalare i pod, ma non può gestire o automatizzare l'instradamento tra i pod e non fornisce strumenti per monitorare, proteggere o eseguire il debug di queste connessioni. Con il crescere del numero di container in un cluster, aumenta in modo esponenziale il numero di possibili percorsi di connessione tra di essi (ad esempio, due container hanno due connessioni potenziali, ma 10 pod ne hanno 90), creando potenzialmente una configurazione e gestione da incubo.
Entra qui in gioco Istio, un livello di mesh di servizi open source per i cluster Kubernetes. Ad ogni cluster Kubernetes, Istio aggiunge un container sidecar - sostanzialmente invisibile al programmatore e all'amministratore - che configura, monitora e gestisce le interazioni tra gli altri container.
Con Istio, puoi impostare una singola politica che configura le connessioni tra i container, in modo da non dover configurare ogni connessione singolarmente. Ciò semplifica il debug delle connessioni tra i container.
Istio fornisce anche un dashboard che i team e gli amministratori DevOps possono utilizzare per monitorare la latenza, gli errori time-in-service e altre caratteristiche delle connessioni tra i container. E integra la sicurezza - nello specifico, la gestione dell'identità che non consente agli utenti non autorizzati di effettuare lo spoofing di una chiamata di servizio tra container - e funzionalità di autenticazione, autorizzazione e controllo (authentication, authorization and auditing, AAA) che i professionisti della sicurezza possono utilizzare per monitorare il cluster.
Knative (pronunciato "Kay-NAY-tive") è una piattaforma open source sviluppata su Kubernetes e fornisce due importanti classi di vantaggi per lo sviluppo nativo del cloud:
Il serverless computing è un modo relativamente nuovo per implementare il codice che rende le applicazioni native del cloud più efficienti ed economicamente convenienti. Invece di implementare un'istanza continua del codice che resta inattiva in attesa di richieste, il serverless attiva il codice come necessario, eseguendone la scalabilità incrementale o decrementale in base alle fluttuazioni della domanda, e lo disattiva quando non è in uso. Il serverless previene lo spreco di capacità e potenza di calcolo e riduce i costi, poiché paghi per l'esecuzione del codice solo quando è effettivamente in esecuzione.
Knative consente agli sviluppatori di progettare un container una volta e di 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 passi ripetitivi e l'orchestrazione dei container richiede molta configurazione e creazione di script (come ad esempio la generazione di file di configurazione, installazione delle dipendenze, gestione della registrazione dei log e del tracciamento e la creazione di script CI/CD (continuous integration/continuous deployment).
Knative rende queste attività più facili, automatizzandole tramite tre componenti:
Build: il componente Build di Knative trasforma automaticamente il codice sorgente in una funzione o un container nativo del cloud. Nello specifico, esegue il pull del codice dal repository, installa le dipendenze richieste, crea l'immagine del container e la trasferisce in un registro dei container per essere utilizzata da altri sviluppatori. Gli sviluppatori devono specificare l'ubicazione di questi componenti in modo che Knative possa trovarli ma, una volta fatto, Knative automatizza la build.
Serve: il componente Serve gestisce i container come servizi scalabili; può eseguire una scalabilità incrementale fino a migliaia di istanze di container o una scalabilità decrementale fino a nessuna (detta scalabilità a zero) Inoltre, Serve ha due funzioni molto utili: la configurazione, che salva le versioni di un container (dette istantanee) ogni volta che esegui il push del container in produzione e ti consente di eseguire tali versioni contemporaneamente, e l'instradamento del servizio, che ti consente di indirizzare diverse quantità di traffico verso queste versioni. Puoi utilizzare queste funzioni insieme per introdurre gradualmente un container o per effettuare un canary test di un'applicazione containerizzata prima di metterla in produzione globale.
Event: Event consente agli eventi specificati di attivare servizi o funzioni basati sui container. Ciò è parte integrante soprattutto delle funzionalità serverless di Knative: è necessario che qualcosa indichi al sistema di attivare una funzione quando necessario. Event consente ai team di esprimere "interesse" in alcuni tipi di eventi e quindi si connette automaticamente all'autore dell'evento ed esegue gli eventi nel container, eliminando la necessità di programmare queste connessioni.
Kubernetes è uno dei progetti open source in più rapida crescita della storia, e la sua crescita è in accelerazione. Gli sviluppatori e le aziende lo utilizzano sempre di più. È importante tenere presente alcuni punti cardine:
Se sei pronto a iniziare a lavorare con Kubernetes o stai cercando di sviluppare 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.
Implementa ed esegui le applicazioni in modo coerente in ambienti on-premise, di edge computing e di cloud pubblico da qualsiasi provider di servizi cloud, utilizzando un set comune di servizi cloud, compresi toolchain, database e AI.
IBM Cloud Code Engine è una piattaforma serverless completamente gestita che ti consente di eseguire il tuo container, codice applicativo o lavoro batch su un runtime del container completamente gestito.
Una nuova ricerca IBM documenta lo slancio crescente di adozione di container e Kubernetes.
I container fanno parte di una strategia cloud ibrida che ti consente di creare e gestire i carichi di lavoro da qualsiasi ubicazione.
Serverless è un modello di sviluppo ed esecuzione di applicazioni cloud che consente agli sviluppatori di compilare ed eseguire codice senza gestire dei server o pagare per un'infrastruttura cloud inattiva.