Nel 2014 Google ha donato un proprio progetto dal nome Kubernetes (aka capitano, pilota) a una fondazione costruita appositamente per gestire questa e altre tecnologie emergenti, la Cloud Native Computing Foundation, branca della Linux Foundation. La Cloud Native Computing Foundation ha gestito da allora Kubernetes riuscendo a radunare attorno a sé un enorme numero di aziende e di altri progetti, a partire dai concorrenti di Google Cloud in questo settore, da AWS ad Azure tanto per citare i principali.
In pochi anni Kubernetes si è diffuso nel mercato del cloud diventando velocemente leader di mercato come strumento per l’orchestrazione dei container e spazzando via la concorrenza: oggi è praticamente uno standard di mercato per il cloud e uno strumento utile ed efficace anche on-premise.
Indice degli argomenti
Come nasce Kubernetes e perché
Per capire quali problematiche si possono affrontare con Kubernetes è necessario descrivere l’obiettivo con cui è nato il progetto, ossia, la gestione di un numero elevato di server e di servizi software su questi server.
Aziende come Google, Facebook, Amazon, Microsoft, per offrire i propri servizi hanno dovuto mettere in campo un numero elevato di server, e più aumentano servizi e clienti, più i server diventano necessari.
L’aspetto più comprensibile di questa attività è che con l’aumentare dei server è diventato necessario assumere più personale IT per installare, aggiornare, manutenere e monitorare server e servizi software.
Potremmo dire, semplificando, che lo scopo iniziale con cui nasce Kubernetes è gestire un elevato numero di server riducendo le risorse necessarie per gestirle, ossia il personale IT.
Cosa sono i container gestiti da Kubernetes
Esistono diversi programmi che possono facilitare l’installazione di servizi sui server: Ansible, Puppet, Salt e Chef; tali programmi, spesso sono utilizzati anche per aggiornare i servizi stessi. Servono poi altre soluzioni per monitorare i servizi e per supportare l’attività di manutenzione dei servizi (l’identificazione dei problemi e lo sviluppo di patch). Mentre queste soluzioni sono nate nel mercato delle virtual machine, Kubernetes nasce per la gestione dei container, integrando inizialmente Docker per poi affiancarlo ad altre tecnologie (Cri-O, Containerd, etc).
Ma cosa fanno, di preciso, i container? Essi mettono a disposizione un meccanismo di pacchettizzazione logico, grazie al quale le applicazioni possono essere astratte dall’ambiente in cui sono eseguite. Questo disaccoppiamento consente di eseguire facilmente e in modo coerente il deployment delle applicazioni basate su container, indipendentemente dal fatto che l’ambiente di destinazione sia un data center privato, un cloud pubblico o un computer portatile di uno sviluppatore.
Sempre per semplificare il tema possiamo dire che Kubernetes inizialmente era una soluzione che consentiva di gestire un elevato numero di server e servizi per installare e manutenere questi servizi gestiti tramite container e non più virtual machine, come negli anni precedenti; da un lato ha avuto un grande successo nel settore enterprise, proponendo una soluzione per la gestione dei container nel momento in cui questi si stavano diffondendo grazie a Docker, dall’altro, si è dimostrata una soluzione efficiente anche quando il numero dei server da gestire non sia elevato, riuscendo così, da un lato, a diventare lo standard di mercato per la gestione dei servizi in cloud e, dall’altro, ad attrarre l’interesse anche per i servizi on-premise come veicolo per l’introduzione dei container nelle server farm private.
Kubernetes, terminologia di riferimento
Senza entrare nel dettaglio, gli elementi principali della terminonologia legate a Kubernetes sono i seguenti:
- Master: server utilizzati per controllare il funzionamento del cluster;
- Nodi: server utilizzati per eseguire i propri applicativi;
- Pod: unità minima di gestione di un applicativo, in uno o più container, che consente di definire alcuni requisiti di sicurezza e impostare le sonde di readiness e liveness, rispettivamente “tempo di avvio” e “tempo di attesa” descritti più avanti;
- Deployment: descrittore relativo a un’applicazione che estende il Pod indicando le strategie di aggiornamento, le strategie di installazione e il numero di Pod che devono essere eseguiti;
- Service: semplificando, un insieme di pod che lavorano assieme, come uno strato di una applicazione multi-tier. Il set di pod che costituiscono un servizio sono definiti mediante label e selector. Di default un service è esposto all’interno di un cluster, ma può essere esposto anche all’esterno del cluster;
- Ingress: anche qui semplificando, è il mezzo per esporre un servizio su internet con un hostname e un loadbalancer.
- Label: informazioni di tipo key-value che possono essere aggiunte a qualunque elemento all’interno del sistema, come ad esempio pod e nodi;
I componenti attuali di Kubernetes sono molti di più, ma quelli appena descritti consentono di schematizzare velocemente le attività nella gestione di Kubernetes:
- in fase di installazione del cluster vengono definiti master e nodi
- in fase di utilizzo del cluster si vanno a definire deployment, service e ingress, quindi, i relativi schemi vanno comunicati ai master che provvedono ad assicurarsi che sui nodi venga installato e mantenuto funzionante l’applicativo descritto nel deployment
Self-healing, come mantenere la continuità del servizio
Immaginiamo che la vostra azienda abbia un negozio online che deve funzionare h 24, 7 giorni su 7, ma a un certo punto un server non va o un singolo servizio non funziona; in passato era probabile venissero installate delle sonde per comunicare l’avaria e di seguito il personale IT avrebbe provveduto a riavviare il servizio o i server.
Nel contesto di Kubernetes, le sonde di readiness e liveness controllano se un servizio risponde, dopo di che, quando il servizio non risponde, il master provvede a eliminare il pod e a sostituirlo con uno nuovo; semplificando: se un servizio si guasta viene spento e ne viene avviato uno nuovo. Questo concetto in Kubernetes è definito self-healing, ossia, autoriparazione ed è una delle molte funzionalità di Kubernetes.
I vantaggi di adottare Kubernetes
Da un lato Kubernetes è uno strumento per la gestione di applicativi mediante container, dall’altro, ha diversi servizi per semplificare la gestione degli applicativi stessi, ad esempio, mediante il self-healing. La svolta ulteriore è che crea le condizioni per sviluppare software a microservizi: i microservices sono una tecnica di sviluppo del software che, per quanto già applicabile tramite i server virtuali, è molto più efficiente e semplice da applicare con i container e aiuta nella gestione di applicativi complessi; è un po come lavorare con il Lego, usando piccoli mattoncini, invece che costruire enormi componenti.
Sono, dunque, molti i vantaggi che Kubernetes ha portato, in primo luogo, in ambito Cloud. Questo perché le grandi aziende del settore hanno cominciato a rendere disponibile Kubernetes ai clienti nella forma managed, ossia, gestita. Tra l’altro, questo servizio rispetto alle soluzioni parziali e precedenti ha il vantaggio di essere uno standard de facto, controllato mediante la software conformance che garantisce che il servizio Kubernetes sia lo stesso cambiando fornitore o servizio di installazione e il progetto è integralmente open source e pubblico.
Conclusioni
Come in passato le virtual machine hanno rivoluzionato il settore IT, oggi una nuova rivoluzione è in corso mediante i container e, sulla spinta di questo cambiamento in corso, Kubernetes, è diventato lo strumento principe, che passa ogni anno anche attraverso gli eventi Kubecon organizzati da CNCF in Europa, Asia e in America. Eventi sempre più affollati: basti pensare che dai 1500 visitatori a Berlino nel 2017 si è passati ai 7700 nel 2019 a Barcellona.
