Docker e Kubernetes: passato, presente e futuro dei container
I container sono presenti nel panorama informatico delle aziende da parecchi anni e sono diventati, in molti casi, una tecnologia essenziale. La loro popolarità deriva dalla loro facilità di installazione, sicurezza e scalabilità, consentendo alle aziende di gestire i carichi di lavoro in modo altamente efficiente. Aiutano a semplificare, accelerare e orchestrare lo sviluppo e la distribuzione delle applicazioni.
I container sono inoltre un elemento chiave per favorire l’implementazione del framework DevOps all’interno dell’azienda: aiutano infatti a ridurre gli attriti tra sviluppatori e i team di operazioni IT, separando chiaramente le diverse aree di responsabilità. Gli sviluppatori possono in questo modo concentrarsi su applicazioni e software, mentre il team “Ops” gestisce l’infrastruttura.
Possiamo considerare i container come un’alternativa per distribuire ed eseguire le applicazioni, concettualmente simili a una grande cartella .zip che contiene tutti gli elementi necessari per l’installazione ed esecuzione dell’applicazione. Ad esempio, sullo smartphone, le applicazioni possono essere considerate come pacchetti di software indipendenti che contengono tutti gli elementi necessari per essere eseguiti su qualsiasi ambiente. In altre parole, i container sono unità software autonome che contengono tutto ciò di cui un’applicazione ha bisogno per essere eseguita, inclusi il codice, le librerie, le variabili di ambiente e le dipendenze. Possono quindi essere avviati e interrotti in modo rapido, affidabile e flessibile, gestendo anche le risorse in modo migliore e ottimizzando le prestazioni.
Ma che cosa riserva il futuro per i container? Che cosa sono e come si collocano Docker e Kubernetes nell’evoluzione dei container?
“Container are chroot with a marketing budget”
(fonte)
Che cos’è Docker
Nonostante il concetto di container nasceva già nel 1979 con lo sviluppo di Chroot, fu Docker a renderlo popolare con il suo debutto nel 2013. Docker si è presentato con un’interfaccia utente facile da usare e la capacità di “impacchettare”, distribuire ed eseguire i container: permetteva a diverse applicazioni con requisiti di sistema operativo diversi di essere eseguite sullo stesso kernel tramite i container. Dopo un mese dal primo rilascio, Docker divenne il parco giochi di 10mila sviluppatori. Quando nel 2014, fu rilasciato Docker 1.0, il software era già stato scaricato 2.75 milioni di volte, che divennero 100 milioni un anno dopo.
Docker crea i container: come accennato in precedenza , permette infatti di “impacchettare” un’applicazione insieme a tutte le sue dipendenze in un contenitore virtuale, che può essere eseguito su qualsiasi sistema operativo compatibile. Questo rende le applicazioni altamente portatili e riduce le differenze tra ambienti di sviluppo, test e produzione.
Per la seconda svolta nella tecnologia di containerizzazione dobbiamo però aspettare il 2017 quando aziende del calibro di AWS, Pivotal e persino Docker stesso cambiarono marcia per supportare Kubernetes, rendendolo di fatto la tecnologia standard per l’orchestrazione dei container.
Dal 2022 in poi, però, il ruolo di Docker dentro i cluster Kubernetes è cambiato in modo netto: lo vedremo nel dettaglio più avanti. Oggi Docker resta lo strumento con cui si costruiscono le immagini, ma raramente è ciò che le esegue in produzione.
Fun Fact: sapevi che la balena del logo di Docker si chiama Moby Dock?
Che cos’è Kubernetes
Facciamo un passo indietro in un mondo senza container. In quel contesto, un’applicazione veniva installata su una macchina attraverso un software, il quale richiedeva il download di file, librerie e dipendenze aggiuntive. Questo approccio presentava problemi evidenti, come il tempo richiesto per l’installazione, che dipendeva dalla dimensione del software e dal numero di macchine coinvolte. Inoltre, c’era la sfida della compatibilità del software con diverse macchine. Anche se era possibile ridurre l’effort grazie a script di automazione o grazie a strumenti come Ansible, i problemi di base rimanevano irrisolti.
Poi arrivarono i container e dopo poco gli strumenti di orchestrazione, rivoluzionando la situazione: permettevano, infatti, la gestione, la scalabilità e la manutenzione dei container stessi. Riprendendo l’analogia del container come un grosso file .zip, lo strumento di orchestrazione si occupa di prendere il file e di eseguirlo su una serie di macchine per renderlo funzionale, scalabile e accessibile. Proprio come un direttore d’orchestra, che conosce le sequenze musicali dei vari strumenti e le gestisce nella sequenza appropriata, per creare una sinfonia armoniosa.
Kubernetes (anche conosciuto come K8s) è lo standard de facto per l’orchestrazione dei container. È una piattaforma molto complessa, con numerose responsabilità e altrettanti vantaggi. Vediamone qualcuno:
- Semplifica il deployment delle applicazioni: grazie all’automazione dell’orchestrazione, gli sviluppatori possono concentrarsi solo sul far funzionare l’applicazione all’interno del container.
- Self healing e replicazione: k8s permette di specificare quante repliche dei pod devono essere configurate nel cluster. (un pod è il contenitore del container: tipicamente ogni container ha il suo pod, ma è possibile che un pod ospiti più container). Se un pod smette di funzionare, k8s lo sostituisce con una sua replica, garantendo la continuità operativa.
- Scalabilità automatica: Kubernetes supporta il bilanciamento dei carichi tra differenti istanze dell’applicazione containerizzata. È possibile definire le istanze iniziali e le regole di scalabilità, cioè i criteri secondo i quali devono essere forniti più o meno pod o nodi (un nodo è il componente hardware più piccolo di Kubernetes). Avere più pod aiuta a distribuire equamente le richieste tra i pod disponibili, consentendo un bilanciamento del carico efficiente.
- Utilizzo ottimale delle risorse hardware: è possibile definire quante macchine virtuali supportano il cluster kubernetes (i nodi mettono insieme le proprie risorse per formare una macchina più potente: il cluster). Kubernetes si occupa quindi di distribuire automaticamente il carico di lavoro tra i nodi, garantendo un utilizzo efficiente delle risorse.
> Scopri il corso di gestione dei container con Kubernetes
Kubernetes come piattaforma per l’intelligenza artificiale
Un cambiamento che nel 2023 era solo all’inizio, e che nel 2026 è ormai un dato di fatto, è l’uso di Kubernetes come piattaforma di riferimento anche per l’intelligenza artificiale: non solo per applicazioni web o gestionali, ma per addestrare e far girare modelli di machine learning su larga scala.
Il motivo è pratico: allenare un modello richiede spesso decine o centinaia di GPU che lavorano in coordinamento, e servire quel modello agli utenti richiede di scalare rapidamente in base alla domanda. Sono esattamente i due problemi che Kubernetes sa già risolvere per le applicazioni tradizionali applicati ora al mondo AI, con strumenti dedicati (come Kubeflow, KServe o Ray) che si appoggiano sull’orchestrazione di Kubernetes senza reinventarla.
Un progresso interessante riguarda proprio le GPU, che sono hardware costoso e spesso sottoutilizzato: oggi è possibile condividere la stessa scheda grafica tra più applicazioni contemporaneamente, invece di assegnarla in blocco a un solo carico di lavoro anche quando non la sfrutta del tutto.
> Leggi anche: “Monitorare i container: strumenti open source e best practices”
Docker vs containerd: chi esegue i container
Dal 2022 in poi, un cambiamento importante ha ridefinito il modo in cui Kubernetes esegue i container: il collegamento diretto che il cluster aveva con Docker è stato eliminato e oggi Kubernetes si appoggia a un motore più snello chiamato containerd, nato a sua volta da un progetto di Docker, poi donato alla comunità open source.
Per chi usa i container tutti i giorni cambia poco: le immagini si continuano a costruire con Docker, con gli stessi comandi di sempre. Cambia solo chi le fa girare una volta arrivate in produzione.
- Docker resta lo strumento con cui gli sviluppatori costruiscono le immagini e lavorano in locale: pratico, con un’interfaccia amichevole, presente nella maggior parte delle pipeline di sviluppo.
- containerd è il motore, più leggero ed essenziale, che i cluster Kubernetes usano oggi per eseguire quelle stesse immagini, sia nei cluster gestiti internamente, sia in quelli dei grandi cloud provider (AWS, Google Cloud, Azure).
> Sfoglia il catalogo “Cloud Native & Container Management”
Focus: stato della sicurezza dei container
Nonostante i numerosi vantaggi offerti dai container e da Kubernetes, la prima preoccupazione della comunità IT sembra essere la sicurezza: se prima dell’adozione di Kubernetes si esitava a causa della condivisione del kernel del sistema operativo e dalla mancanza di persistenza dei dati, i report più recenti mostrano un panorama quantomeno preoccupante.
- Il “2022 Cloud-Native Security and Usage Report” di Sysdig ha rilevato che il 75% dei partecipanti stava eseguendo container con vulnerabilità elevate o critiche, mentre il 76% aveva container in esecuzione con privilegi di root, mettendo così in pericolo la sicurezza dell’ecosistema IT. (fonte)
- Il “2022 State of Kubernetes Security Report” di Red Hat mostra che il 93% degli intervistati ha subito almeno un incidente di sicurezza legato a Kubernetes negli ultimi 12 mesi e che il 31% di questi ha subito una perdita in termini di clienti o fatturato a seguito di tali incidenti. (fonte)
- Nel rapporto “The State of Kubernetes 2022″ di VMWare, il 36% dei partecipanti ha affermato che la sicurezza, la protezione e la crittografia dei dati sono gli strumenti e le capacità più importanti per l’utilizzo di Kubernetes in produzione. Quasi tutti gli intervistati (97%) hanno mostrato preoccupazioni riguardo alla sicurezza di Kubernetes, in particolare per le implementazioni multi-cluster e multi-cloud.
Da allora, il progetto Kubernetes ha lavorato proprio su questi punti. Una delle novità più concrete è la possibilità di isolare meglio i privilegi “root” dentro un container: prima, un container compromesso che girava con privilegi elevati poteva rappresentare un rischio anche per la macchina che lo ospitava. Le versioni più recenti di Kubernetes permettono di separare i due livelli, così che i privilegi dentro il container restino confinati al container stesso. È diventato anche più semplice, per chi amministra un cluster, scrivere regole di sicurezza personalizzate senza dover sviluppare software su misura per ogni singola policy.
Container: che cosa aspettarsi dal futuro
Kubernetes è diventato la piattaforma di riferimento anche per i workload AI, containerd ha sostituito Docker Engine come runtime di produzione, e WebAssembly è entrato nei cluster come opzione concreta per casi specifici.
> Leggi anche: “WebAssembly: che cos’è e quali sono i vantaggi”
Lo scenario più realistico per i prossimi anni non è la sostituzione di una tecnologia con l’altra, ma la loro coesistenza dentro lo stesso cluster: container tradizionali e moduli WebAssembly gestiti fianco a fianco dallo stesso Kubernetes. Per un’azienda questo significa poter scegliere lo strumento giusto per ogni carico di lavoro senza dover gestire piattaforme separate.
Rimangono invariate le due sfide di fondo: sicurezza e complessità operativa. I miglioramenti arrivati con le versioni più recenti di Kubernetes aiutano sul primo fronte, ma non lo risolvono da soli: servono comunque processi, competenze e strumenti di monitoraggio adeguati. Su questo, molte aziende continuano a scegliere servizi Kubernetes as a Service, che offrono gestione della sicurezza e strumenti di monitoraggio senza doverli costruire internamente da zero.
La tecnologia container e l’orchestrazione con Kubernetes hanno cambiato il modo in cui le applicazioni vengono sviluppate, distribuite e gestite. Lo scenario si fa sempre più complesso, ma il punto di fondo non è cambiato: usare bene queste tecnologie richiede pianificazione e competenze specializzate, non solo scegliere gli strumenti giusti. Affidarsi a servizi gestiti resta, per molte aziende, il modo più diretto per concentrarsi sullo sviluppo delle applicazioni invece che sulla gestione dell’infrastruttura sottostante.
