Se hai appena iniziato ad utilizzare Kubernetes o vorresti introdurlo nella tua azienda, questo articolo potrebbe fare al caso tuo: oltre ad una definizione dettagliata di che cos’è e di come ha cambiato il modo di lavorare nel mondo IT, parleremo di come è nato, della sua architettura e dei vantaggi che una sua implementazione comporta.
Per una panoramica dei topic che andremo ad affrontare, ecco l’elenco degli argomenti di questo post (clicca una sezione per leggere direttamente ciò che più ti interessa):
- Cos'è Kubernetes
- La storia
- L’architettura
- Cosa non è Kubernetes
- Perché utilizzare Kubernetes
- Le alternative
- Il passaggio verso l’approccio cloud native
Che cos’è Kubernetes
La definizione la riporta direttamente il sito ufficiale Kubernetes.io: Kubernetes è una piattaforma portabile, estensibile, open-source per la gestione di servizi e carichi di lavoro containerizzati che facilita sia l’automazione che la configurazione dichiarativa.
Andiamo nel dettaglio:
- cosa significa portabile: è la capacità di spostare i carichi di lavoro da un cloud all’altro con l’obiettivo di evitare un lock-in infrastrutturale e ottenere dei costi minori;
- cosa significa estensibile: la capacità della piattaforma di supportare la portabilità del sistema, di favorire l’autonomia tra applicazioni e la scalabilità dei progetti. Ma non è solo questo, è anche la capacità di integrarsi facilmente con soluzioni di terze parti;
- cosa si intende per open-source: inizialmente la piattaforma è stata sviluppata da un team di esperti in Google e successivamente è stata donata alla Cloud Native Computing Foundation (CNCF). Questo ha fatto in modo che il codice fosse pubblico, visibile, auditabile e riutilizzabile da chiunque volesse accedervi.
E ha permesso ad un maggior numero di aziende di adottare Kubernetes e al pubblico di sviluppatori mondale di modificare e di avere un accesso completo al suo design garantendo innumerevoli vantaggi, tra cui la minimizzazione del rischio di codice non compatibile, upgrade mancati e obsolescenza del sistema; - cosa si intende per servizi e carichi di lavoro containerizzati: grazie a Kubernetes è possibile pacchettizzare le applicazioni in modo che siano astratte dall’ambiente in cui sono eseguite;
- cosa significa configurazione dichiarativa: la piattaforma consente agli sviluppatori di descrivere lo stato desiderato (a runtime) delle applicazioni.
La storia
Kubernetes viene lanciata nella sua prima versione nel 2015, ma per comprendere veramente la sua origine, dobbiamo fare un salto indietro a dieci anni prima: Google mette a disposizione di tutti Gmail e YouTube gratuitamente e deve trovare un modo per gestire il traffico generato da milioni di utenti che utilizzano contemporaneamente i prodotti.
Viene lanciata così la prima sfida: ripensare l’infrastruttura a disposizione (commodity hardware) e riprogettare l’architettura delle applicazioni. Nasce Borg (e poi successivamente il suo upgrade Omega, il sistema di cluster che gestisce i carichi di lavoro che a loro volta supportano le azioni compiute dagli utenti sui servizi Google.
Nel 2014, a seguito del successo sempre più crescente dei container e di Docker che per primo ha proposto una soluzione scalabile e portabile, Google decide di prendere tutta l’esperienza accumulata in dieci anni e di costruire una versione di Borg esterna all’ambiente Google e di renderla accessibile a tutti.
Viene lanciato così, in collaborazione con la Linux Foundation, Kubernetes, il quale diventa il progetto open-source più significativo e di successo al mondo che ha in seguito generato una numerosa community (CNCF) che sponsorizza progetti cloud.
L'architettura
Architettura Kubernetes
Kubernetes si compone principalmente di:
- Un control plane che include un sistema di archiviazione distribuito per mantenere consistente lo stato dei cluster (etcd). È un sistema che tiene traccia di tutti gli oggetti Kubernetes e gestisce lo stato di quest’ultimi tenendo d’occhio i cambiamenti che avvengono all’interno dei cluster. È inoltre il sistema che trasforma lo stato attuale di un oggetto in quello desiderato. Un piano di controllo è formato da tre componenti:
- Scheduler, che si occupa della programmazione dei container attraverso i nodi presenti nel cluster. Per garantire un lavoro ottimale, il server tiene conto di limitazioni e vincoli collegati alle risorse presenti.
- Controller Manager, lo strumento che si occupa di veicolare lo stato attuale degli oggetti a quello desiderato. Il suo compito è quello di eseguire i loop di controllo core, tenere sotto controllo lo stato dei cluster ed effettuare i giusti cambiamenti per raggiungere lo stato richiesto.
- Server API, il quale si occupa dell’orchestrazione del ciclo di vita (dagli aggiornamenti, alla scalabilità, ecc) dei diversi tipi di applicazioni presenti nel sistema. Fornisce anche da via d’accesso al cluster da parte di client esterni che effettuato l’autenticazione tramite il server API e lo utilizzano come proxy per giungere ai nodi e ai pod. - Nodi (Kubelets), o cluster, sono macchine che gestiscono i container.
Kubelet è il controller primario e il più importante di Kubernetes, responsabile della guida del livello di esecuzione dei container.
Il Pod è la parte fondamentale su cui si basa l’architettura di Kubernetes ed è la struttura con cui gli sviluppatori interagiscono maggiormente.
Esso raccoglie al suo interno un’unica applicazione, la quale può essere formata a sua volta da diversi container e volumi di archiviazione. I pod possono essere utilizzati anche per ospitare uno stack applicativo verticalmente integrato. La loro principale caratteristica è quella di essere effimero e di avere un ciclo di vita limitato: nel momento in cui un’applicazione subisce un upgrade o un downgrade, infatti, il pod decade.
Cosa NON è Kubernetes
Kubernetes ha molti vantaggi e si presenta come una piattaforma che va oltre l’orchestrazione di container, qualità che lo rende un sistema più semplice da utilizzare, più potente, robusto, resiliente ed estensibile.
Tuttavia, anche Kubernetes presenta dei limiti, o meglio, non si propone come piattaforma in cui è possibile gestire in modo universale ogni aspetto di un container.
Kubernetes:
- Non containerizza automaticamente l’applicazione, ma richiede che essa lo sia già prima che possa essere eseguita all’interno di Kubernetes.
- Non è un archivio per la gestione di immagini. Nativamente, Kubernetes non si propone come magazzino per la gestione e la raccolta di immagini, ma si integra perfettamente con strumenti di terze parti.
- Non è fatto per gestire il server su cui vengono eseguiti i carichi di lavoro.
- Fornisce una linea di sicurezza legata all’accesso role-based e offre una polizza di sicurezza sui pod con cui limita l’accesso non autorizzato alle risorse, ma si ferma qui. Per un livello più avanzato, e consigliato, di sicurezza, sono necessarie delle integrazioni apposite.
Perché utilizzare Kubernetes
L’utilizzo dei container ha definitivamente cambiato il mondo del cloud computing portando le aziende a migrare la propria infrastruttura e architettura IT ad un ambiente cloud-native.
Non si parla, quindi, solo di un mero passaggio da un tool ad un altro, ma l’utilizzo di Kubernetes richiede di ripensare la propria infrastruttura in ottica cloud.
Perché un’azienda dovrebbe compiere un passo così importante? È presto detto:
- Perché non ha limiti: le applicazioni odierne devono essere sviluppate in modo da poter essere eseguite in diversi ambienti operativi, dal server dedicato on-prem ai cloud pubblici e privati. Ciò consente di svincolare l’applicazione dall’infrastruttura sottostante e di scegliere il migliore host in base alle proprie esigenze. Kubernetes è costruito appositamente per poter funzionare in qualsiasi ambiente con maggiore flessibilità e sicurezza, evitando il vendor lock-in.
- Perché la gestione è facilitata dalla modularità: grazie ai contenitori, è possibile ridurre le applicazioni in parti più piccole con distinte competenze. Un approccio modulare di questo tipo consente di abilitare uno sviluppo più veloce dove ogni team di sviluppo si concentra su uno specifico container, ma anche di isolare le dipendenze tra le diverse competenze.
Ai contenitori deve però essere affiancato un sistema di integrazione e orchestrazione dei singoli moduli, funzione che viene fornita da Kubernetes tramite i pod. - Perché sviluppo e update sono più veloci e riducono il time-to-market: grazie a Kubernetes, è possibile gestire il ciclo di vita delle applicazioni garantendo:
- maggiore scalabilità: orizzontale, con la possibilità di aggiungere o rimuovere nuovi server, automatica o manuale
- maggiore visibilità: attraverso query per il riconoscimento delle distribuzioni completate, in-process oppure non riuscite
- minor tempo di sviluppo: il quale consente al team devops di focalizzare la propria attenzione sullo sviluppo di prodotti invece di dedicarsi agli aspetti più ripetitivi.
- maggior controllo sulle versioni: con cui è possibile eseguire l’update di un pod tramite l’utilizzo di versioni di immagini più recenti e di ritornare alla versione precedente nel caso di instabilità.
Le alternative
Kubernetes è forse la piattaforma più famosa attraverso cui gestire le proprie applicazioni, ma non è l’unica.
Definire quale sia la soluzione migliore è un compito difficile, soprattutto senza aver prima effettuato uno studio delle esigenze specifiche aziendali. Ciò che possiamo fare, però, è definire gli aspetti principali di ogni piattaforma per poter almeno farci un’idea generale su dove ricadrà la nostra decisione.
Tra le alternative più conosciute a Kubernetes abbiamo:
- ECS (Amazon Elastic Container Service). ECS è un servizio di Amazon per l’orchestrazione dei container completamente gestito. Come Kubernetes, è una soluzione veloce e scalabile. Si integra perfettamente con tutti i servizi AWS, tra cui Elastic Load Balancing, CloudWatch, CloudFormation e IAM. Consente di lavorare sui container senza dover gestire la macchina virtuale sottostante ed è uno strumento sicuro che esegue i container su cloud privato virtuale.
Nonostante gli aspetti che hanno in comune, Kubernetes gode del vantaggio di poter essere installato sulla varietà di cloud pubblici e privati presenti sul mercato (come Google Cloud, Azure a AWS stesso) e on-prem, inoltre ha a disposizione una grande quantità di soluzioni open-source a cui attingere per integrare la piattaforma - Docker Swarm, strumento utilizzato per il clustering e la pianificazione dei container Docker con cui è possibile gestire facilmente un cluster di nodi in un unico sistema virtuale.
La sua architettura si basa su microservizi e può rivelarsi la scelta ideale per un’azienda alla ricerca di una configurazione rapida e automatizzata e una curva di apprendimento graduale.
Kubernetes, invece, presenta un apprendimento più rigido, ma è l’ideale per lo sviluppo di applicazioni complesse e utilizzato in migliaia di container. Tra i due servizi, quest’ultimo è certamente dedicato a chi necessita di funzionalità avanzate e di una personalizzazione avanzata. - Nomad, tool di orchestrazione, prodotto da HashiCorp, che permette di sviluppare ed eseguire diversi tipi di applicazioni, contianerizzate, legacy e microservizi.
Si può considerare uno strumento per la pianificazione delle attività e l'esecuzione della gestione dei cluster e si integra perfettamente con gli altri strumenti dello stack HashiCorp, tra cui Consul e Vault.
Kubernetes, dalla sua, può avvalersi del fatto di essere un software di gestione dei cluster molto più completo, con a disposizione moltissime integrazioni.
Il passaggio verso l'approccio cloud native
Abbiamo parlato di Kubernetes e di come questa piattaforma sia il sistema ideale per l’orchestrazione e la gestione di applicazioni sviluppate in cloud. Abbiamo, poi, accennato al fatto che utilizzare uno strumento di questo tipo non può essere definito un semplice passaggio da un tool all’altro perché richiede di ripensare il proprio approccio verso l’infrastruttura IT e rivederlo in ottica cloud native.
Con cloud native intendiamo una combinazione di tecnologie e tecniche che permettono di creare sistemi resilienti e monitorabili, con l’obiettivo di sviluppare e distribuire applicativi di qualità e ottenere cicli di vita del software più brevi guidati da continuous feedback degli utenti.
In poche parole, questo approccio, supportato da uno stack tecnologico adeguato, è l’ideale per un’azienda che vuole innovare, sviluppare, erogare e testare nuove idee velocemente, senza sacrificare la qualità.