Nella lingua greca antica Kubernetes significa “timoniere” o “pilota”. Quando, nel 2014, Google scelse questo nome per indicare la piattaforma open source per l’orchestrazione e la gestione di container, si optò per un logo in cui un timone stilizzato richiamasse la citazione aulica. Contemporaneamente, i sette raggi del timone facevano riferimento al progetto Seven of Nine che era all’origine di Kubernetes come ulteriore sviluppo di Borg, il cluster manager adoperato internamente dagli ingegneri di Mountain View. In questo caso, l’allusione semantica non era all’antichità classica, ma all’universo più recente di Star Trek e al tipo di relazione nella catena di comando che uno dei protagonisti (Seven of Nine, appunto) aveva con il collettivo di droni Borg. Nel 2015 Google, in seguito a un’alleanza con la Linux Foundation, decise di donare Kubernetes alla neonata Cloud Native Computing Foundation (CNCF) a cui oggi aderiscono i colossi mondiali del public cloud insieme a un centinaio di startup.
Le origini, ovvero perché è nato Kubernetes
La genesi del progetto è stata raccontata più volte da Craig McLuckie, cofondatore di Kubernetes insieme a Joe Beda negli anni in cui entrambi lavoravano a Google Compute Engine, l’infrastruttura alla base di servizi online come Google Search, Gmail e YouTube. In una di queste occasioni, McLuckie riporta uno degli spunti da cui “l’open-sourcing Kubernetes” ha preso il via, e cioè il sottoutilizzo delle CPU in rapporto alle macchine virtuali (VM) da parte di clienti che dovevano sobbarcarsi comunque i costi relativi. “Sapevamo di avere una soluzione interna per questo problema – scrive l’attuale vice presidente R&D di VMware -. E, per di più, sapevamo che i container erano il futuro dell’informatica: sono scalabili, portatili e più efficienti. Il sistema container Docker era già in funzione e pensavamo che fosse fantastico. Ma il trucco, che conoscevamo attraverso anni di tentativi ed errori all’interno di Google, era un grande sistema di gestione dei container. Questo è ciò che volevamo costruire”.
Container vs macchine virtuali a confronto
Il vantaggio dei container rispetto alle VM risiede nella virtualizzazione delle applicazioni software e non, come avviene nelle macchine virtuali, dell’intera infrastruttura informatica. Poiché i container sfruttano il sistema operativo dell’host, invece del proprio, ne consegue che necessitano di risorse di elaborazione minime, oltre a essere più semplici da installare. Gli sviluppatori, in sostanza, non devono intervenire per modificare tutta l’infrastruttura, ma su ciascun singolo componente applicativo. Da qui l’esigenza di un modello per governare automaticamente l’orchestrazione dei container distribuiti in cluster e su più server host. Il risultato è oggi un movimento globale che vede Kubernetes (abbreviato anche in “K8s” o “Kube”) come uno dei principali tool a tale scopo, con una velocità di adozione che, a detta dello stesso McLuckie, nemmeno “gli obiettivi più selvaggi” dei suoi fondatori avevano previsto. Nel 2019, infatti, poteva contare su più di 2.300 contributor e su una diffusione capillare tra le imprese più innovative del mondo in settori economici disparati.
Come funziona l’architettura di Kubernetes
Per comprendere le ragioni del suo successo, analizziamo anzitutto l’architettura e gli elementi chiave di Kubernetes, che sono i seguenti: master, nodi, kubelet, pod.
Master
Si tratta della macchina che controlla i nodi e consente di eseguire un servizio di schedulazione in grado di automatizzare la distribuzione dei container in base ai requisiti impostati dallo sviluppatore e alla capacità di calcolo disponibile.
Nodi
I cluster sono costituiti da nodi, ognuno dei quali rappresenta un singolo host di calcolo, cioè di macchina virtuale o fisica. I nodi eseguono le attività loro affidate sotto la guida del nodo master che li controlla.
Kubelet
È l’agente software che riceve ed esegue gli ordini dal nodo master, facendo in modo che i container definiti siano avviati ed eseguiti.
Pod
I pod sono gruppi di container che condividono le stesse risorse di calcolo e la stessa rete. Rappresentano anche l’unità di scalabilità di Kubernetes e, quindi, se un container in un pod riceve più traffico di quello che può gestire, Kubernetes replica il pod su altri nodi del cluster.
I vantaggi nell’utilizzo della piattaforma K8s
Il crescente apprezzamento di cui gode Kubernetes tra la comunità degli sviluppatori deriva dalla sua ampiezza di funzionalità, dal suo vasto ecosistema di strumenti di supporto open source e dalla portabilità attraverso i principali cloud provider, alcuni dei quali offrono i servizi K8s in maniera completamente gestita. Soprattutto negli scenari odierni, dominati da un numero elevato di container e dalla conseguente necessità di garantirne la sicurezza, Kubernetes è in grado di integrare i vari livelli di security con la stessa modalità con cui riesce a orchestrare carichi di lavoro, reti, storage ecc. mettendo a disposizione un’architettura di container completa. Un vantaggio che si riflette anche nell’abbattimento del rischio di downtime, visto che l’architettura ridondante della piattaforma assicura livelli di continuità del servizio con percentuali vicine al 100%. È per questo che Kubernetes viene annoverato tra le soluzioni in alta affidabilità (HA) che contemplano le perfomance SLA (Service Level Agreement) più elevate.
Ascolta “Cloud e hybrid IT: la vera sfida della trasformazione è ora” su Spreaker.
Alcuni esempi pratici di come eseguire Kubernetes
Sebbene Kubernetes sia nato per gestire container Linux, può essere eseguito anche in Windows o macOS. Se si sceglie una VM, qualsiasi macchina virtuale può fungere allo scopo: da Google Compute Engine a OpenStack, da Azure Virtual Machines a EC2 di Amazon e così via. Inoltre, esistono più di 90 offerte certificate CNCF che attestano la conformità del software affinché ogni fornitore supporti le API richieste e l’interoperabilità da un’installazione Kubernetes all’altra. Alcune di queste offerte, come Canonical, Red Hat OpenShift e Suse CaaS Platform, solo per citare le più note, poiché prevedono Kubernetes in abbinamento a una distribuzione Linux, non richiedono il download e l’installazione su un determinato sistema operativo. Il che solleva dall’onere di dover configurare manualmente il sistema, visto che Kubernetes è proposto come orchestratore nativo. Anche in cloud, per esempio in Google Cloud Platform, è disponibile come funzione nativa. Se, invece, si vuole eseguire Kubernetes in locale come macchina di sviluppo, il tool Minikube è quello maggiormente suggerito dagli sviluppatori.
La Federation v2 e il futuro nell’orchestrazione dei container
Il futuro di Kubernetes è la piena sincronizzazione delle app su più cluster, più regioni e in ambienti multi-cloud. È un’ambizione portata avanti dalla Federation, giunta alla versione 2 come il più grande sotto-progetto open source all’ombra del timone. Tra i suoi scopi, la Federation v2 persegue:
- una distribuzione ottimale del carico di lavoro su tutti i cluster grazie alla configurazione automatica dei server DNS e dei bilanciatori di carico;
- la possibilità di evitare il lock-in dei cloud provider, semplificando la migrazione delle applicazioni attraverso i cluster e promuovendo l’hybrid cloud;
- la bassa latenza grazie a una suddivisione dei cluster in più regioni in maniera tale che siano quanto più prossimi agli utenti;
- la capacità di isolare i guasti, facilitata per esempio da cluster multipli di piccole dimensioni piuttosto che da un singolo grande cluster.
Il progetto Federation v2 è relativamente recente e si sta occupando dei problemi elencati sopra. Una volta risolti, se già adesso Kubernetes è il principale sistema di orchestrazione automatica dei container, diventerà praticamente la piattaforma senza rivali in questo ambito.
