La storia di Kubernetes

2 novembre 2023

Tempo di lettura: 7 minuti

Quando si parla di infrastruttura IT moderna, il ruolo di Kubernetes, la piattaforma di orchestrazione di container open source che automatizza l'implementazione, la gestione e il ridimensionamento di applicazioni (app) e servizi software containerizzati, non può essere sottovalutato.

Secondo un report di Cloud Native Computing Foundation (CNCF) (link esterno a ibm.com), Kubernetes è il secondo progetto open-source più grande del mondo dopo Linux, e il principale strumento di orchestrazione dei container per il 71% delle aziende Fortune 100. Per comprendere come Kubernetes sia arrivato a dominare il mercato del cloud computing e dei microservizi, dobbiamo esaminarne la storia.

L'evoluzione di Kubernetes

La storia di Kubernetes, il cui nome deriva dal greco antico e significa "pilota" o "timoniere" (la persona al timone che guida la nave), viene spesso fatta risalire al 2013, quando un trio di ingegneri di Google (Craig McLuckie, Joe Beda e Brendan Burns) propose l'idea di creare un sistema di gestione dei container open source. Questi pionieri della tecnologia stavano cercando modi per portare le competenze infrastrutturali interne di Google nel campo del cloud computing su larga scala e consentire anche a Google di competere con Amazon Web Services (AWS), il leader indiscusso tra i provider di cloud all'epoca.

Confronto fra infrastruttura IT tradizionale e infrastruttura IT virtuale

 

Ma per comprendere veramente la storia di Kubernetes, spesso chiamato anche «Kube» o «K8s», un «numeronimo» (link esterno a ibm.com), dobbiamo esaminare i container nel contesto dell'infrastruttura IT tradizionale rispetto all'infrastruttura IT virtuale.

In passato, le organizzazioni eseguivano le proprie app esclusivamente su server fisici (noti anche come Bare Metal Server). Tuttavia, per queste app era impossibile rispettare i limiti delle risorse di sistema. Ad esempio, quando un server fisico eseguiva più applicazioni, una di queste poteva consumare tutta la potenza di elaborazione, la memoria, lo spazio di archiviazione o altre risorse del server. Per evitare che ciò accadesse, le aziende eseguivano ogni applicazione su un server fisico diverso. Ma questo tipo di separazione crea risorse sottoutilizzate e rende impossibile la scalabilità. Inoltre, avere molte macchine fisiche occupa spazio ed è costoso.

Virtualizzazione

 

Poi è arrivata la virtualizzazione, il processo che costituisce la base del cloud computing. Sebbene la tecnologia di virtualizzazione risalga alla fine degli anni '60, non è stata ampiamente adottata fino all'inizio degli anni 2000.

La virtualizzazione si basa su un software noto come hypervisor, una forma leggera di software che consente l'esecuzione di più virtual machines (VM) su un'unità di elaborazione centrale (CPU) di un singolo server fisico. Ogni macchina virtuale è dotata di un sistema operativo guest (OS), una copia virtuale dell'hardware necessario per l'esecuzione del sistema operativo e un'applicazione con le relative librerie e dipendenze. 

Sebbene le macchine virtuali creino un uso più efficiente delle risorse hardware per eseguire le applicazioni rispetto ai server fisici, occupano comunque una grande quantità di risorse di sistema. Ciò è particolarmente vero quando sullo stesso server fisico vengono eseguite numerose macchine virtuali (VM), ciascuna con il proprio sistema operativo guest.

Contenitori

 

Entra in gioco la tecnologia dei container. Una pietra miliare storica nello sviluppo dei container si è verificata nel 1979 con lo sviluppo di chroot (link esterno a ibm.com), parte del sistema operativo Unix versione 7. Chroot ha introdotto il concetto di isolamento dei processi limitando l'accesso ai file di un'applicazione a una directory specifica (root) e alle sue directory secondarie (o sottoprocessi).

I container di oggi sono unità eseguibili di software in cui il codice dell'applicazione è impacchettato insieme alle relative librerie e dipendenze. Ciò consente alle applicazioni di funzionare rapidamente in qualsiasi ambiente, sia on-premise che off-premise, da un desktop, da un data center privato o da un cloud pubblico.

Invece di virtualizzare l'hardware sottostante come le macchine virtuali, i container virtualizzano il sistema operativo (di solito come Linux o Windows). La mancanza del sistema operativo guest è ciò che rende i container leggeri, nonché più veloci e portatili delle VM.

Borg: il predecessore di Kubernetes

All'inizio degli anni 2000, Google aveva bisogno di un modo per ottenere le migliori prestazioni dai suoi server virtuali per supportare la sua infrastruttura in crescita e fornire la sua piattaforma cloud pubblica. Questo ha portato alla creazione di Borg, il primo sistema unificato di gestione dei container. Sviluppato tra il 2003 e il 2004, il sistema Borg prende il nome da un gruppo di alieni di Star Trek, i Borg, organismi cibernetici che funzionano condividendo una mente alveare (coscienza collettiva) chiamata "Collettivo".

Il nome Borg si adatta bene al progetto Google. Il sistema di gestione dei cluster su larga scala di Borg funge essenzialmente da cervello centrale per l'esecuzione di workload containerizzati nei suoi data center. Progettato per funzionare insieme al motore di ricerca di Google, Borg è stato utilizzato per costruire i servizi internet di Google, tra cui Gmail, Google Docs, Google Search, Google Maps e YouTube.

Borg ha permesso a Google di eseguire centinaia di migliaia di lavori da molte applicazioni diverse su più macchine. Ciò ha consentito a Google di ottenere un elevato utilizzo delle risorse, tolleranza ai guasti e scalabilità per i suoi carichi di lavoro su larga scala. Borg viene ancora oggi utilizzato da Google come principale sistema di gestione dei container interni dell'azienda.

Nel 2013, Google ha introdotto Omega, il suo sistema di gestione dei container di seconda generazione. Omega ha portato l'ecosistema Borg ancora più avanti, fornendo una soluzione di pianificazione flessibile e scalabile per cluster di computer su larga scala. Nel 2013 è entrato in anche in scena Docker, un attore chiave nella storia di Kubernetes.

Docker inaugura la containerizzazione open source

Sviluppato da dotCloud, una società tecnologica Platform-as-a-Service (PaaS), Docker è stato rilasciato nel 2013 come strumento software open source che consentiva agli sviluppatori di software online di creare, distribuire e gestire applicazioni containerizzate.

La tecnologia dei container Docker utilizza il kernel Linux (il componente di base del sistema operativo) e le caratteristiche del kernel per separare i processi in modo che possano essere eseguiti in modo indipendente. Per chiarire ogni confusione, l'omonimo Docker si riferisce anche a Docker, Inc. (precedentemente dotCloud, link esterno a ibm.com), che sviluppa strumenti di produttività per la sua piattaforma di containerizzazione open source, nonché per  l'ecosistema e la community open source Docker (link esterno a ibm.com).

Popolarizzando un runtime di container leggero e fornendo un modo semplice per impacchettare, distribuire e distribuire applicazioni su una macchina, Docker è stato l'ispirazione per i fondatori di Kubernetes. Quando è arrivato sulla scena, infatti, i Googler Craig McLuckie, Joe Beda e Brendan Burns sono stati entusiasti della capacità di Docker di costruire container individuali ed eseguirli su macchine individuali.

Tuttavia, benché Docker avesse cambiato le regole del gioco per l'infrastruttura nativa del cloud, aveva dei limiti perché era stato creato per funzionare su un singolo nodo, il che rendeva impossibile l'automazione. Ad esempio, poiché le app venivano create per migliaia di container separati, la loro gestione in vari ambienti era diventata un'attività complessa in cui ogni singolo sviluppo doveva essere impacchettato manualmente. Il team di Google ha individuato la necessità e l'opportunità di un orchestratore di container in grado di implementare e gestire più container su più macchine. Così è nato Kubernetes, il sistema di gestione dei container di terza generazione di Google.

La nascita di Kubernetes

Molti sviluppatori di Kubernetes avevano lavorato per sviluppare Borg e volevano creare un orchestratore di container che incorporasse tutto ciò che avevano appreso attraverso la progettazione e lo sviluppo dei sistemi Borg e Omega con l'obiettivo di produrre uno strumento open source meno complesso con un'interfaccia (UI) intuitiva. Come ode ai Borg, l'hanno chiamato Project Seven of Nine, come un personaggio di Star Trek: Voyager che è un ex drone Borg. Sebbene il nome originale del progetto non rimanesse, è stato commemorato dai sette punti sul logo Kubernetes (link esterno a ibm.com).

All'interno di un cluster Kubernetes

L'architettura Kubernetes si basa cluster in esecuzione che consentono l'esecuzione di container su più computer e ambienti. Ogni cluster è in genere costituito da due classi di nodi:

  • Nodi di lavoro, che eseguono le applicazioni containerizzate.
  • Nodi di controllo, che controllano il cluster.

Il piano di controllo agisce essenzialmente come orchestratore del cluster Kubernetes e include diversi componenti, come il server API (che gestisce tutte le interazioni con Kubernetes), il Control Manager (che gestisce tutti i processi di controllo), il Cloud Controller Manager (l'interfaccia con l'API del provider di cloud) e così via. I nodi di lavoro eseguono i container utilizzando runtime dei container come Docker. I pod, le unità implementabili più piccole in un cluster, contengono uno o più container di app e condividono risorse, ad esempio informazioni di storage e rete.

Kubernetes diventa pubblico

Nel 2014, Kubernetes ha fatto il suo debutto come versione open source di Borg, e Microsoft, RedHat, IBM e Docker che hanno aderito come primi membri della comunità Kubernetes. Lo strumento software includeva funzionalità di base per l'orchestrazione dei container, tra cui:

  • Replica per distribuire istanze multiple di un'applicazione
  • Bilanciamento del carico e scoperta dei servizi
  • Controllo e riparazione di base dello stato di salute
  • Pianificazione per raggruppare molte macchine insieme e distribuire il lavoro su di esse

Nel 2015, alla O'Reilly Open Source Convention (OSCON) (link esterno a ibm.com) , i fondatori di Kubernetes hanno presentato una versione ampliata e raffinata di Kubernetes: Kubernetes 1.0. Subito dopo, gli sviluppatori del team Red Hat OpenShift si sono uniti al team di Google, prestando la loro esperienza ingegneristica ed aziendale al progetto.

La storia di Kubernetes e della Cloud Native Computing Foundation

In concomitanza con il rilascio di Kubernetes 1.0 nel 2015, Google ha donato Kubernetes alla Cloud Native Computing Foundation (CNCF) (link esterno a ibm.com), parte della Linux Foundation senza scopo di lucro. La CNCF è stata creata congiuntamente da numerosi membri delle principali società informatiche mondiali, tra cui Docker, Google, Microsoft, IBM e Red Hat. La missione (link esterno a ibm.com) della CNCF è "rendere onnipresente il computing cloud native".

Nel 2016, Kubernetes è diventato il primo progetto ospitato della CNCF e nel 2018 è stato il primo progetto della CNCF a laurearsi. Il numero di aziende che hanno contribuito attivamente è salito rapidamente a oltre 700 e Kubernetes è diventato rapidamente uno dei progetti open source in più rapida crescita della storia. Nel 2017, aveva superato concorrenti come Docker Swarm e Apache Mesos, diventando lo standard di settore per l'orchestrazione dei container.

Kubernetes e applicazioni cloud-native

Prima del cloud, le applicazioni software erano collegate ai server hardware su cui venivano eseguite. Ma nel 2018, quando Kubernetes e i container sono diventati lo standard di gestione per le organizzazioni che fornivano cloud, il concetto di applicazioni cloud-native ha iniziato a prendere piede. Ciò ha aperto le porte alla ricerca e allo sviluppo di software basati sul cloud.

Kubernetes aiuta a sviluppare programmi cloud-native basati su microservizi e consente la containerizzazione delle app esistenti, contribuendo così a uno sviluppo più rapido delle app. Kubernetes offre anche l'automazione e l'osservabilità necessarie per gestire in modo efficiente più applicazioni in contemporanea. L'infrastruttura dichiarativa basata sulle API di Kubernetes consente ai team di sviluppo cloud-native di operare in modo indipendente e aumentare la propria produttività.

L'impatto continuo di Kubernetes

La storia di Kubernetes e del suo ruolo come piattaforma portatile, estensibile e open source per la gestione di workload containerizzati e microservizi, continua.

Da quando Kubernetes è entrato a far parte del CNCF nel 2016, il numero di collaboratori è cresciuto fino a 8.012, con un aumento del 996% (link esterno a ibm.com). La conferenza globale di punta del CNCF, KubeCon + CloudNativeCon (link esterno a ibm.com), attira migliaia di partecipanti e fornisce un forum annuale che raccoglie informazioni e insight di sviluppatori e utenti su Kubernetes e altre tendenze DevOps.

Sul fronte della trasformazione del cloud e della modernizzazione delle applicazioni, l'adozione di Kubernetes non accenna a rallentare. Secondo un rapporto di Gartner, The CTO's Guide to Containers and Kubernetes (link esterno a ibm.com), più del 90% delle organizzazioni mondiali eseguirà applicazioni containerizzate in produzione entro il 2027.

IBM e Kubernetes

Nel 2014, IBM è stata una delle prime grandi aziende a unire le forze con la comunità open source di Kubernetes e a portare l'orchestrazione dei container in azienda. Oggi, IBM aiuta le aziende ad affrontare i loro continui percorsi verso il cloud con l'implementazione dell'orchestrazione dei container Kubernetes e di altre soluzioni di gestione basate sul cloud.

Che il tuo obiettivo sia lo sviluppo di applicazioni native per il cloud, l'implementazione di app su larga scala o la gestione di microservizi, possiamo aiutarti a sfruttare Kubernetes e i suoi numerosi casi d'uso.

Red Hat OpenShift on IBM Cloud offre agli sviluppatori OpenShift un modo rapido e sicuro per containerizzare e implementare i workload aziendali nei cluster Kubernetes.

IBM Cloud Code Engine, una piattaforma serverless completamente gestita, ti consente di eseguire il tuo container, il codice dell'applicazione o il lavoro in batch su un runtime del container completamente gestito.

 

Autore

Stephanie Susnjara

IBM Think Content Contributor