Oggi parliamo di qualcosa di cui quasi tutti hanno sentito parlare ma che nessuno sa spiegare Kubernetes. È fonte di confusione perché risolve un problema che la maggior parte delle persone non vede finché non ci sbatte. Tutti sanno che è importante ma se chiedi cosa faccia riceverai solo sguardi smarriti. Non è un sostituto di Docker né un sistema operativo cloud anche se spesso la gente lo pensa. La confusione è comprensibile dato che Kubernetes risolve un problema di cui non conosci l'esistenza finché non lo offload. È uno strumento che diventa essenziale una volta che hai più di una manciata di container da gestire. Alla fine di questo episodio capirai cos'è davvero Kubernetes, come si integra con i container e perché Azure Kubernetes Service lo rende pratico per i team che non vogliono costruire tutto da zero. Prendi il tuo caffè e iniziamo. Problema prima dei container. Torniamo al problema.

Immagina un'azienda di software di dieci anni fa. Hai alcune applicazioni da seguire quindi compri server, installi sistemi operativi e distribuisci tutto manualmente. Ogni app ottiene la sua macchina e non puoi condividere le risorse tra loro. Se un'app ha bisogno di molta memoria un'altra ne usa malapena ottengono comunque il proprio server ciascuna. I server giravano forse al 20% la capacità ma non potevi consolidare perché le applicazioni entravano in conflitto per le dipendenze. Finivi con una stanza piena di server, ognuno che lavorava malapena consumando energia e raffreddamento e tutti i bisognosi di manutenzione costante. Un'app richiede python 3.8, un'altra richiede python 3.8. La necessità di una libreria più vecchia, un'altra di quella più recente. Non puoi eseguirle sulla stessa macchina senza rompere qualcosa, quindi compri più server e paghi per hardware che rimane per lo più inattivo. Le macchine virtuali hanno aiutato un po' permettendo di dividere un server fisico in pezzi più piccoli, ognuno con il proprio sistema operativo, ma ogni VM è pesante, con un SO completo che occupa spazio su disco e memoria e impiega minuti per avviarsi. E dovevi configurare ognuna separatamente, il che richiedeva molto lavoro. Dovevi ancora gestire tutti quei sistemi operativi, applicare patch, aggiornare e proteggerli. I team avevano bisogno di qualcosa di più leggero e portatile, un modo per pacchettizzare un'applicazione con tutto ciò che serve per funzionare senza il sovraccarico di una macchina virtuale completa che potesse essere spostata facilmente tra le macchie. È qui che sono entrati in gioco i container.

Cosa sono effettivamente i container? Un container è un piccolo pacchetto che include la tua applicazione e tutto ciò che le serve per funzionare. Ciò significa che il codice, il rantame, le librerie e i file di configurazione sono tutti raggruppati in un'unica unità. Immaginalo come un container per il trasporto merci ma per solo. Un container per spedizioni può viaggiare su un camion, un treno o una nave e il container in sé rimane lo stesso. Il tuo software container funziona allo stesso modo. Lo crea una volta e viene eseguito allo stesso modo sul tuo portatile, sul server di test e nell'ambiente di produzione. La differenza chiave tra container e macchine virtuali è la loro efficienza. Una macchina virtuale esegue il proprio sistema operativo completo, quindi ogni VM ha il proprio kernel, file di sistema e tutto il resto. Un container condivide il sistema operativo dell'host. È solo un processo con la propria visione isolata del mondo. Ciò significa che i container si avviano in pochi secondi, non minuti. Usano meno memoria, puoi caricarne molti di più su una singola macchina. Docker ha reso i container popolari, offrendo agli sviluppatori un modo semplice per crearli ed eseguirli con un solo comando. Improvvisamente il problema del suo mio computer funziona ha iniziato a scomparire. Se la tua applicazione gira in un container sul tuo portatile, girerà allo stesso modo sul server. L'ambiente è coerente ovunque, ma i container risolvono un problema e ne creano un altro. Con una manciata di container, la gestione manuale funziona bene. Puoi avviarli, fermarli, tenerli traccia da solo. Ma cosa succede quando non hai centinaia? Devi decidere quale server esegue quale container, riavviare quelli guasti, collegarli tra loro e scalarli quando il traffico aumenta. Questa è una nuova sfida ed è esattamente qui che entra in gioco Kubernetes. Problema dell'orchestrazione. Quindi fatto funzionare i container, hai impacchettato la tua applicazione e gira in modo coerente ovunque, la vita è bella.

Ma solo per un po'. Con 10 o 20 container puoi gestire le cose manualmente. Sai quale server esegue quale container, puoi riavviare qualcosa se si blocca e puoi aggiornare alcune cose qua e là. È gestibile. Ma poi la tua applicazione cresce. Passi ai microservizi. Quindi invece di un'unica grande applicazione ne hai 20 più piccole. Ognuna necessita di più copie in esecuzione per l'affidabilità e ora ti ritrovi con 200 container. La gestione manuale non funziona più. Devi decidere quale server esegue ogni container, riavviare i container quando falliscono e connetterli affinché possano comunicare. Devi anche scalare verso l'alto quando il traffico aumenta. Magari durante una vendita o il lancio di un prodotto è scalare verso il basso quando le cose si calmano. E devi implementare gli aggiornamenti senza tempi di inattività, il che significa sostituire i vecchi container con quelli nuovi uno alla volta con attenzione, senza rompere nulla. Questi sono problemi di orchestrazione ed è esattamente ciò che Kubernetes è stato costruito per risolvere. Kubernetes è una piattaforma open source che automatizza il deployment, lo scaling e la gestione di applicazioni containerizzate. Pensalo come il sistema operativo del tuo datacenter. Proprio come Windows o Linux gestiscono le risorse su un singolo computer come CPU, memoria, disco, Kubernetes gestisce le risorse su tutti i tuoi server.

Clatta tutte le tue macchine come un unico grande pool di potenza di carico. Tu gli dici cosa vuoi eseguire, lui capisce dove metterlo, come mantenerlo attivo e come collegarlo a tutto il resto. Concetti chiave, pod, nodi, cluster. Vediamo come funziona effettivamente Kubernetes. L'unità più piccola in Kubernetes si chiama pod. Un pod racchiude uno più container. I container all'interno dello stesso pod condividono archiviazione e rete, così possono comunicare tra loro tramite localhost. Puoi pensare a un pod come a una singola unità di deployment. Non esegui il deployment dei container direttamente in Kubernetes. Esegui il deployment dei pod. I pod non funzionano da soli, vengono eseguiti sui nodi. Un nodo è un server fisico virtuale che fa parte del tuo cluster Kubernetes. Ogni nodo esegui il software necessario per far girare i pod, oltre ad altre cose che vedremo tra poco. Cluster è l'insieme di tutti i nodi gestiti come un unico sistema unificato. In termini semplici, un pod è la tua applicazione, un nodo dove viene eseguita e il cluster è l'intero ambiente. I pod sono effimeri. Possono essere creati, distrutti o spostati in qualsiasi modo. Progettato così. Se un nodo si guasta, Kubernetes sposta i pod su un altro. Per lo scaling verso l'alto crea nuovi pod. E quando un pod si arresta in modo anomalo, viene sostituito automaticamente. Il sistema considera i pod come temporane. Ma se i pod vanno e vengono, hai bisogno di un modo per comunicare con uno. Invece di parlare direttamente con un pod, parli con un servizio. Un servizio fornisce un indirizzo di rete stabile che è in strada del traffico verso i pod corretti, anche se i pod cambiano. Imagine un hotel. Il numero di telefono dell'hotel è il servizio. Le stanze cambiano ospiti continuamente, ma il numero di telefono rimane lo stesso. Chiami la reception e loro in strada non la tua chiamata alla stanza. Esattamente ciò che fa un servizio in Kubernetes. Ti fornisce un indirizzo fisso che punta sempre ai pod che attualmente eseguono la tua applicazione. Il control plane, il cervello del cluster. Quindi iPod, nodi, on cluster. La domanda è chi decide cosa viene eseguito dove. Questo è il compito del control plane. Ogni cluster Kubernetes ne ha uno ed è il cervello dell'intera operazione. Qui vengono prese tutte le decisioni. Control plane è composta da versi remei. Il primo è l'API server, che funge da porta d'ingresso per il tuo cluster.

Ogni comando è inviato a Kubernetes che provenga dalla riga di comando, da una dashboard o da uno script automatizzato passa attraverso l'API server. Autentica la tua richiesta. Verifica se sei autorizzato a procedere e la trasmette al componente corretto. Nulla accade in Kubernetes senza passare prima dall'API server. Segue lo scheduler che decide su quale nodo eseguire ogni pod. Quando dici voglio che questa applicazione sia in esecuzione, lo scheduler analizza tutti i nodi disponibili, controlla le risorse come CPU, memoria e spazio su disco e sceglie il più adatto e sceglie il più adatto. È come un direttore d'albergo che assegna le camere in base alle esigenze di ogni ospite. Un ospite con molti bagagli riceve una stanza più grande, mentre un'applicazione leggera ottiene un nodo più piccolo con capacità disponibile. Poi c'è il controller manager. Questo componente monitora il cluster e assicura che lo stato effettivo corrisponda a quello dichiarato. Hai richiesto l'esecuzione di tre copie della tua web app. Controller manager verifica che vi siano effettivamente tre copie in esecuzione. Se una si arresta, se ne accorge, ne avvia una sostitutiva. Se qualcuno elimina accidentalmente un pod, ne crea uno nuovo. È il componente che mantiene il tuo cluster coerente. Infine c'è etcd, che è il database del cluster. Archivia tutto, cosa è in esecuzione, dove si trova e come è configurato. È la fonte di verità per l'intero cluster. Se l'API server è la porta d'ingresso, etcd è l'archivio nel retroufficio dove vengono conservati tutti i documenti. Il bello di questo design è che tu descrivi ciò che vuoi e Kubernetes trova il modo di realizzarlo. Non gli dici come fare le cose, gli dici come dovrebbe apparire il risultato finale. Questo è il modello dichiarativo ed è l'idea centrale dietro tutto ciò che fa Kubernetes. Workload, deployment, servizi e scalabilità. Parliamo quindi di come eseguire concretamente le applicazioni su Kubernetes. Non creerai PO direttamente.

Userai invece un oggetto di livello superiore chiamato deployment. Pensa a un deployment come un gestore che indica a Kubernetes quante copie del tuo pod eseguire, quale immagine, container, usare e come aggiornare all'uscita di una nuova versione. È il metodo standard per eseguire applicazioni state. Quando aggiorni un deployment, ad esempio pubblicando una nuova versione della tua app, Kubernetes esegue un rolling update. Sostituisci i pod una alla volta assicurandosi che almeno una copia sia sempre in esecuzione. Ciò significa nessun downtime e nessuna interruzione improvvisa per i tuoi tempi. E se qualcosa va storto con la nuova versione, puoi tornare a quella precedente con un solo comando. È una potente rete di sicurezza, ma i tuoi pod devono comunque essere raggiungibili. È qui che entrano in gioco i servizi. Un servizio fornisce un indirizzo di rete stabile che instrada il traffico verso i pod corretti. Può anche esporre quei pod ad altre parti della tua applicazione o al mondo esterno. Un servizio può essere interno, accessibile solo nel cluster o esterno, con un IP pubblico, raggiungibile da internet. Ecco la questione riguardante la scalabilità. Kubernetes può far crescere o ridurre automaticamente la tua applicazione in base alla domanda. Imposti un obiettivo, ad esempio al 70%, utilizzo CPU e Kubernetes aggiunge pod se supera la soglia e li rimuove quando cala. La tua applicazione scala verso l'alto durante un picco di traffico e si riduce quando le cose si calmano. Nessun intervento manuale necessario. Ma tutto questo potere comporta complessità. Gestire il tuo cluster Kubernetes significa essere responsabile del control plane, aggiornamenti, patch di sicurezza e backup. Serve una profonda competenza per gestire guasti ai nodi, configurazione di rete e scalabilità del cluster. Molti team passano più tempo a gestire il cluster che a creare applicazioni. È qui che entra in gioco il Kubernetes gestito. Kubernetes autogestito contro il Kubernetes gestito. Quindi parliamo della realtà di gestire Kubernetes da soli. Quando crea il tuo cluster sei responsabile di tutto, control plane, aggiornamenti, patch di sicurezza e backup di etcd. Se l'API server va giù, è un tuo problema. Se viene scoperta una vulnerabilità di sicurezza nella versione che usi, devi applicare la patch. Se etcd si corrompe, devi ripristinare dal backup.

Tutto ciò richiede una profonda competenza. Devi capire come falliscono i nodi, come funziona la rete a livello di cluster e come scalare senza rompere nulla. Ecco cosa sorprende a molti team. Molte organizzazioni passano più tempo a gestire il loro cluster Kubernetes che a costruire applicazioni che ci girano sopra. Lottano costantemente con aggiornamenti, risoluzione di problemi di rete e gestione dei guasti ai nodi. Il cluster diventa un lavoro a tempo pieno. Non è questo il motivo per cui è adottato Kubernetes fin dall'inizio. È qui che entrano in gioco i servizi Kubernetes gestiti. Servizi come Azure Kubernetes Service o HS gestiscono il control plane per te. Azure gestisce l'API server e ZTD lo scheduler e controller manager. Non devi preoccuparti di aggiornarli o di mantenerli in funzione. Paghi solo per i worker node, le macchine virtuali che eseguono effettivamente i tuoi carichi di lavoro. Piano di controllo è gratuito. Questo cambia drasticamente l'equazione.

Invece di dedicare tempo alla manutenzione del cluster, il tuo team può concentrarsi su ciò che conta davvero, le applicazioni che stai creando. Per la maggior parte dei team, specialmente quelli agli inizi, Kubernetes gestito è la scelta giusta. Ottieni tutta la potenza di Kubernetes senza il carico operativo. HS Kubernetes è reso semplice sul. Quindi cos'è esattamente HS? È il servizio Kubernetes gestito di Azure che ti offre un cluster completo senza doverlo costruire da zero. Il piano di controllo è gratuito, come abbiamo detto, quindi paghi solo per le macchine virtuali che eseguono i tuoi carichi di lavoro. Ciò significa che puoi iniziare in piccolo, pagare poco e scalare man mano che le tue esigenze crescono. Azure gestisce tutto il lavoro pesante. Aggiornamenti, pace e monitoraggio dello stato del piano di controllo sono tutti gestiti. Non serve un team dedicato di esperti Kubernetes solo per far funzionare le cose. E poiché HS fa parte dell'ecosistema, Azure si integra con gli strumenti che probabilmente stai già usando. Azure Active Directory per l'autenticazione, Azure Monitor per log e metriche e Azure Policy per la governance. Funzionano tutti insieme fin da subito, senza dover aggiungere prezzi separati. Configurare pipeline CIS-TD con GitHub Actions o Azure DevOps richiede solo pochi minuti. Pubblica una modifica nel repository e il sistema crea automaticamente una nuova immagine container, la invia ad Azure Container Registry e aggiorna il deployment su HS. Nessun passaggio manuale, nessun accesso SH e server. È tutto automatizzato.

Per i principianti c'è la modalità automatica di HS pensata per i team che non vogliono prendere ogni singola decisione sulla configurazione del cluster. Fornisci impostazioni predefinite e pronte all'uso per scalabilità, networking, sicurezza e aggiornamenti. Non devi diventare un esperto di Kubernetes per iniziare. Descrivi semplicemente la tua applicazione e HS gestisce Red. Un comando per creare il cluster, un file manifesto per avviare l'applicazione. Le competenze acquisite su HS sono trasferibili a qualsiasi ambiente Kubernetes perché sotto il cofano c'è Kubernetes standard. Non stai imparando un sistema proprietario ma quello reale con Azure che gestisce la complessità operativa. Curai il quadro generale. I container impacchettano le tue applicazioni affinché funzionino in modo coerente ovunque e Kubernetes orchestra quei container su larga scala, gestendo automaticamente deployment, scalabilità e ripristino. HS rende tale orchestrazione gestibile occupandosi del piano di controllo e integrandolo con gli strumenti Azure che già conosci.

Concetto principale è questo. Kubernetes non è solo per le grandi aziende tecnologiche con enormi team di ingegneri. Con servizi gestiti come HS è accessibile a qualsiasi team. I compiti per questa settimana sono semplici. Crea un account Azure gratuito, avvia un cluster HS e distribuisci una semplice applicazione. Richiede pochi minuti e vedrai quanta strada ha fatto la piattaforma. Pronto ad approfondire. Il prossimo episodio tratta di come creare la tua prima immagine di container e caricarla su Azure Container Registry. Iscriviti sulla tua piattaforma podcast preferita e condividi questo episodio con chi sta iniziando il suo percorso con Kubernetes.