Kubernetes & Helm Fundamentals

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Kubernetes e Helm, episodio 1 di 10. Per anni, Google ha gestito la sua infrastruttura globale di ricerca e posta elettronica usando un sistema super segreto che prendeva il nome dai cattivi più terrificanti di Star Trek. Hanno dovuto inventarlo perché il server management esistente semplicemente non reggeva alla loro scala. Oggi vediamo le origini da Borg a Kubernetes, e perché le aziende moderne ci fanno affidamento. Per capire perché esiste Kubernetes, devi guardare a come si è evoluto il deployment delle applicazioni. Nell'era del deployment tradizionale, facevi girare le applicazioni su server fisici. Non c'era modo di definire i limiti delle risorse. Se un'applicazione occupava gran parte della memoria, le altre applicazioni su quel server fisico ne risentivano. Potevi comprare una macchina fisica separata per ogni app, ma questo significava avere hardware costoso e sottoutilizzato. Poi è arrivata l'era del deployment virtualizzato. Facevi girare più Virtual Machine sulla CPU di un singolo server fisico. Le VM isolavano le applicazioni e fornivano un certo livello di sicurezza, ma ogni VM richiedeva comunque un sistema operativo completo e pesante. Infine, siamo arrivati all'era del deployment a container. I container sono simili alle VM, ma condividono il sistema operativo sottostante tra le applicazioni. Essendo disaccoppiati dall'hardware sottostante, sono leggeri, veloci da avviare e portabili su diversi cloud e distribuzioni di sistemi operativi. Ma i container hanno introdotto un nuovo problema. Se fai girare un'applicazione enterprise globale, non hai un solo container. Ne hai migliaia. Se un container va giù, un altro deve partire immediatamente. Se c'è un picco di traffico, devi fare spin up di altri container e distribuire il load di rete in modo uniforme. Non puoi gestirlo manualmente su centinaia di macchine. Google ha affrontato questo stesso problema molto prima del resto dell'industria. Hanno creato un container cluster manager interno chiamato Borg per automatizzare l'orchestrazione di centinaia di migliaia di job. Quando è diventato chiaro che il resto del mondo del software aveva bisogno di questa stessa funzionalità, gli ingegneri di Google hanno avviato un progetto open-source basato sulle lezioni imparate da Borg. Gli hanno dato un riferimento a Star Trek, chiamandolo originariamente Project Seven of Nine, un omaggio a un drone Borg fuggito dal collettivo. Quel progetto alla fine è stato lanciato come Kubernetes. Il logo a forma di timone che vedi oggi ha sette razze, un piccolo omaggio a quel nome originale del progetto. Questa è la parte importante. Kubernetes ti fornisce un framework per far girare sistemi distribuiti in modo resiliente. Si occupa dello scaling e del failover per la tua applicazione. Se un container crasha, Kubernetes lo sostituisce. Se un node fallisce, fa il reschedule dei container su node sani. Gestisce la service discovery, il che significa che un container può essere trovato usando un nome DNS o il suo indirizzo IP, e bilancia il load in modo che nessun singolo container venga sovraccaricato. Gestisce anche la storage orchestration, permettendoti di montare automaticamente storage locale o cloud provider, e automatizza rollout e rollback. Descrivi lo stato desiderato dei tuoi container deployati, e Kubernetes cambia lo stato effettivo nello stato desiderato a una velocità controllata. Non scrivi script per gestire lo stato del server; dichiari quello che vuoi, e il sistema lo fa accadere. Il concetto chiave qui è che Kubernetes non è solo un ambiente di hosting, è un control loop che confronta costantemente la realtà con le tue aspettative e corregge la differenza. Prima di chiudere, se vuoi aiutarci a continuare a fare questi episodi, cerca DevStoriesEU su Patreon — apprezziamo il supporto. Questo è tutto per questa puntata. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Kubernetes e Helm, episodio 2 di 10. Hai decine di server che fanno girare centinaia di container. Quando una macchina si guasta all'improvviso, qualcosa deve decidere dove andranno a finire quei workload orfani. Un'orchestra senza direttore è solo rumore, e una flotta di container senza un cervello centralizzato è un caos ingestibile. Quel cervello centralizzato, insieme alle macchine che fanno il lavoro vero e proprio, forma l'architettura del cluster Kubernetes. Un cluster Kubernetes è diviso in due metà distinte. Hai il Control Plane, che fa da cervello, e hai i Worker Node, che fanno da braccio. Il Control Plane prende tutte le decisioni globali, come lo scheduling dei workload, e rileva e risponde agli eventi del cluster. I Worker Node ospitano le tue applicazioni ed eseguono le istruzioni inviate dal Control Plane. Ogni cluster deve avere almeno un worker node per far girare le applicazioni. Guardiamo prima il Control Plane. Il suo componente principale è il kube-apiserver. A volte chi ascolta sente API server e si immagina un classico web server che gestisce richieste HTTP per un'applicazione. Ma non è questo il caso. Il kube-apiserver è il sistema nervoso centrale dell'intero cluster. È il front end del Control Plane. Ogni singola comunicazione, che arrivi da un operatore umano, da un worker node o da un componente interno, passa attraverso questo API server. Dato che l'API server è completamente stateless, il cluster ha bisogno di una memoria. Quella memoria è etcd. Si tratta di un key-value store coerente e ad alta disponibilità che contiene tutti i dati del cluster. Ogni volta che viene creata una configurazione o che lo stato del sistema cambia, il vero record di quella modifica vive in etcd. Poi c'è il kube-scheduler. Quando chiedi al cluster di far girare un nuovo workload container, inizialmente quel workload non ha nessuna macchina assegnata. Lo scheduler nota questo workload non assegnato. Valuta i requisiti di risorse, i vincoli hardware e le regole delle policy, e poi assegna il workload al worker node più appropriato. Infine, hai il kube-controller-manager. Questo componente esegue dei loop continui in background chiamati controller. Questi controller osservano costantemente lo stato attuale del cluster tramite l'API server e lavorano attivamente per spingere quello stato attuale verso il tuo stato desiderato. Se un worker node va in crash, il controller manager nota la macchina mancante e innesca la risposta per rimpiazzare i workload persi. Questo per quanto riguarda il cervello. Ora guardiamo i worker node che eseguono i task. I componenti del nodo girano su ogni singola macchina worker per mantenere l'ambiente di runtime. Il componente più critico qui è il kubelet. È un agent che gira su ogni nodo e comunica direttamente con il Control Plane. Il kubelet prende istruzioni dall'API server e si assicura che i container richiesti siano effettivamente in esecuzione e funzionanti sulla sua macchina specifica. Il kubelet non avvia i container da solo. Delega questo task al Container Runtime. Il runtime è il software vero e proprio, come containerd, responsabile di fare il pull delle immagini dei container da un registry e di avviare i processi sul sistema operativo. Infine, c'è il kube-proxy. È un proxy di rete che gira su ogni nodo. Mantiene le regole di rete locali che permettono alle comunicazioni di rete di raggiungere i tuoi container dall'interno o dall'esterno del cluster. Ecco il punto chiave. Il Control Plane detta cosa dovrebbe succedere, ma non esegue mai il codice dell'applicazione. I worker node eseguono il codice dell'applicazione, ma si affidano completamente al Control Plane per sapere cosa far girare. Questa rigida separazione tra processo decisionale ed esecuzione è ciò che permette a Kubernetes di scalare orizzontalmente e di riprendersi automaticamente dai guasti hardware. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Kubernetes e Helm, episodio 3 di 10. Costruisci un container, lo testi in locale e lo passi a Kubernetes per farlo girare. Ma Kubernetes si rifiuta categoricamente di gestire direttamente il tuo container. Al contrario, pretende che tu lo incapsuli prima in un'astrazione completamente diversa. Oggi demistifichiamo i Pod, la vera unità di lavoro in questo ecosistema. Se i container sono le balene solitarie del mondo tradizionale della containerizzazione, i Pod sono i gruppi coesi in cui nuotano insieme. Un Pod è l'oggetto deployable più piccolo e basilare che puoi creare e gestire in Kubernetes. Rappresenta una singola istanza di un processo in esecuzione nel tuo cluster. Ti potresti chiedere perché Kubernetes introduca questo layer aggiuntivo invece di gestire semplicemente i container in modo diretto. La risposta sta nell'astrazione e nel contesto condiviso. Kubernetes ha bisogno di un modo uniforme per gestire networking, storage e scheduling, indipendentemente dallo specifico container runtime sottostante che utilizzi. Incapsulando i container in un Pod, Kubernetes tratta il Pod come un host logico. Ecco il punto chiave. Un Pod non si limita a incapsulare un singolo container; stabilisce un ambiente di esecuzione condiviso. Anche se spesso un Pod contiene un solo container, può ospitare container multipli che devono lavorare a stretto contatto. Quando più container vengono messi nello stesso Pod, hai la garanzia che vengano schedulati sull'esatta stessa macchina fisica o virtuale. Cosa ancora più importante, questi container condividono lo stesso network namespace. Ogni container all'interno di un singolo Pod condivide un unico indirizzo IP e un unico port space. Dato che esistono nello stesso contesto di rete, possono comunicare tra loro semplicemente usando localhost. Non c'è bisogno di DNS lookup interni o di un complesso service routing solo per far parlare due processi locali. Se il container A fa il bind sulla porta ottomila, il container B nello stesso Pod può raggiungerlo su localhost alla porta ottomila. Questo contesto condiviso si estende allo storage. Puoi definire degli storage volume condivisi a livello di Pod. Una volta definiti, qualsiasi container all'interno di quel Pod può montare questi shared volume nel proprio file system. Questo permette a container strettamente accoppiati di leggere e scrivere esattamente gli stessi file senza problemi. Prendi ad esempio un container web server primario. Il suo compito è servire traffico HTTP, ma scrive anche i raw access log in una directory locale. Vuoi inviare questi log a un sistema di monitoraggio centrale, ma non vuoi appesantire la tua web server image con logging agent e file di configurazione. Invece, crei un secondo container, una logging utility leggera. Fai il deploy sia del web server che del logging container all'interno dell'esatto stesso Pod. Il web server scrive i suoi log su uno storage volume condiviso. Il logging container, agendo da sidecar, monta quello stesso volume, legge i file di log in arrivo e fa lo stream verso il tuo sistema di monitoraggio. Operano come un'unica unità integrata, condividendo le risorse senza confondere le loro singole responsabilità. Quando decidi se due container appartengono allo stesso Pod, chiediti se hanno intrinsecamente bisogno di finire sull'esatta stessa macchina e condividere un lifecycle identico. Se non hanno assoluta necessità di fare il deploy, avviarsi e morire insieme, appartengono a Pod separati. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a costruire!

Ciao, sono Alex di DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, episodio 4 di 10. Stai dormendo. Alle tre del mattino, un memory leak manda in crash il tuo application server principale. In un setup tradizionale, scatta un alert e ti svegli per riavviare manualmente il processo. In Kubernetes, il sistema gestisce il turno di notte al posto tuo. Questo è il potere della gestione dello state con i Deployment. Un Deployment fornisce aggiornamenti dichiarativi per le tue applicazioni. Invece di scrivere script che dicono al sistema passo dopo passo come eseguire il tuo software, descrivi esattamente come dovrebbe essere il quadro finale. Passi questo state desiderato al Deployment controller, e lui modifica lo state effettivo per farlo corrispondere, a una velocità controllata. Per capire come ci riesce, devi conoscere la gerarchia. Raramente crei singoli Pod direttamente. Piuttosto, crei un Deployment. Il Deployment a sua volta crea un oggetto secondario chiamato ReplicaSet. Il ReplicaSet è il meccanismo che ha il compito preciso di garantire che l'esatto numero specificato di repliche dei Pod sia in esecuzione in qualsiasi momento. Se un nodo server fallisce, o un Pod va in crash a causa di quel memory leak, il ReplicaSet nota che i numeri sono scesi sotto il tuo state desiderato. Tira subito su un nuovo Pod per sostituire quello perso. Questo è il tuo meccanismo di self-healing. Non devi mai intervenire. La stessa logica si applica allo scaling. Se c'è un picco di traffico, aggiorni il tuo file di Deployment per chiedere cinque repliche invece di tre. Il controller vede la discrepanza tra la tua richiesta e la realtà, e ordina al ReplicaSet di lanciare altri due Pod. Questo approccio dichiarativo è cruciale soprattutto durante gli aggiornamenti dell'applicazione. Mettiamo che tu abbia tre Pod che fanno girare un'immagine Nginx alla versione 1.14. Devi fare l'upgrade alla versione 1.16 senza perdere traffico degli utenti. Ti basta semplicemente aggiornare la versione dell'immagine nella configurazione del tuo Deployment. Il Deployment non termina tutti i tuoi vecchi Pod in una volta sola. Al contrario, crea un ReplicaSet nuovo di zecca appositamente per la versione 1.16. Poi, inizia un rolling update. Avvia un nuovo Pod nel nuovo ReplicaSet. Una volta che quel nuovo Pod è healthy, fa lo scale down del vecchio ReplicaSet terminando un Pod della versione 1.14. Ripete questo processo accurato e graduale finché tutti e tre i vecchi Pod non vengono eliminati e tre nuovi Pod sono in esecuzione. La transizione avviene completamente senza interruzioni. Ora, cosa succede se l'update è rotto? Ecco il punto chiave. Dato che il Deployment controller orchestra questi ReplicaSet, ti offre una rete di sicurezza integrata. Se per errore digiti il nome dell'immagine come Nginx 1.16-typo, i nuovi Pod andranno in crash allo startup. Il Deployment rileva il fallimento e blocca immediatamente il rollout. Lascia in esecuzione i tuoi vecchi Pod rimanenti, così la tua applicazione resta online. Una volta individuato l'errore, puoi lanciare un comando di rollback. Il Deployment fa semplicemente lo scale up del vecchio ReplicaSet sicuramente funzionante, e fa lo scale down a zero di quello rotto. La vera forza di un Deployment non è solo lanciare container, ma il suo loop continuo e incessante in cui confronta quello che hai chiesto con ciò che esiste effettivamente, costringendo la realtà a corrispondere. Vorrei prendermi un momento per ringraziarti per l'ascolto: ci aiuta tantissimo. Buona giornata!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Kubernetes e Helm, episodio 5 di 10. I Pod sono mortali. Vanno in crash, fanno scale down, vengono evicted e, quando vengono sostituiti, ottengono un indirizzo IP completamente nuovo. Se hai un'applicazione che cerca di comunicare con loro, stai costantemente sparando a un bersaglio in movimento. I Service di Kubernetes risolvono esattamente questo problema. Pensa a una tipica applicazione web. Hai un deployment frontend e un database backend. Se il Pod del tuo database si riavvia, il control plane del cluster avvia un nuovo Pod per sostituirlo. A questo nuovo Pod viene assegnato un indirizzo IP completamente diverso sulla rete del cluster. Se il tuo frontend era configurato per parlare direttamente con il vecchio IP, la connessione cade e la tua applicazione si rompe. Non puoi fare affidamento sugli IP dei singoli Pod per nulla di permanente. Un Service di Kubernetes è un'astrazione che fornisce un'identità di rete stabile e duratura per un gruppo dinamico di Pod. Quando crei un Service, gli viene assegnato un indirizzo IP che non cambierà mai finché il Service esiste. La tua applicazione frontend non ha bisogno di tenere traccia di quali Pod del database siano attivi in un dato istante. Invia semplicemente il traffico all'IP del Service. Inoltre, il cluster assegna un nome DNS stabile al Service. Il codice del tuo frontend può semplicemente connettersi a un semplice hostname, e il cluster lo risolve automaticamente nell'indirizzo IP corretto. Dietro le quinte, il Service funge da load balancer interno. Si basa su un componente chiamato kube-proxy, in esecuzione su ogni nodo, per implementare le vere e proprie regole di routing. Quando il traffico arriva al Service, viene inoltrato a uno dei Pod sani che ci stanno dietro. Per collegare un Service ai Pod giusti, usi label e selector. Potresti configurare il Service con un selector che cerca la label che indica un'applicazione database. Il Service osserva costantemente il cluster. Se un Pod del database muore, il suo IP viene rimosso dal pool attivo. Quando il Pod sostitutivo si avvia, il suo nuovo IP viene aggiunto. L'applicazione frontend rimane completamente all'oscuro del fatto che la topologia di rete sottostante è appena cambiata. Ci sono alcuni modi per esporre un Service, a seconda da dove ha origine il traffico. Il tipo di default è ClusterIP. Un Service ClusterIP ottiene un indirizzo IP interno raggiungibile solo dall'interno del cluster. Questa è la scelta giusta per il tuo database backend, mantenendolo isolato in modo sicuro dal mondo esterno. Ma il tuo frontend ha bisogno di ricevere traffico da utenti esterni. Per questo, cambi il tipo di Service in LoadBalancer. Quando crei un Service LoadBalancer, Kubernetes comunica con il tuo cloud provider per fare il provisioning di un load balancer esterno standard. Il traffico internet esterno colpisce quella risorsa cloud, che inoltra la connessione all'interno del tuo cluster, passandola attraverso il Service e infine ai tuoi Pod frontend. Ecco il concetto chiave. I Service disaccoppiano l'identità indirizzabile della tua applicazione dai workload fisici che eseguono effettivamente la logica. Smetti di fare routing verso istanze specifiche e fragili e inizi a fare routing verso un concetto resiliente e persistente. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, episodio 6 di 10. Vuoi fare il deploy di una singola applicazione, ma finisci per gestire centinaia di righe di YAML statico tra deployment, service e ingress. Quando devi portare quella stessa applicazione in un ambiente di staging, copi quei file in una nuova directory e sostituisci manualmente gli image tag e gli hostname. È fragile, altamente ripetitivo e impossibile da mantenere man mano che la tua infrastruttura cresce. Questo è esattamente il problema che Helm è nato per risolvere. Helm è il package manager per Kubernetes. Puoi pensarlo come apt, yum o Homebrew, ma progettato specificamente per le risorse Kubernetes. Invece di trattare la tua applicazione come una raccolta disordinata di manifest YAML indipendenti, Helm li raggruppa in un'unica unità coesa. Questo formato di packaging si chiama Chart. Un Chart è essenzialmente una directory che contiene file che descrivono un set correlato di risorse Kubernetes. Contiene tutte le definizioni di cui la tua applicazione ha bisogno per funzionare. Il meccanismo principale che rende utile un Chart è il templating. I manifest Kubernetes raw sono completamente statici. Un Helm Chart, al contrario, sostituisce i dettagli hardcoded dell'infrastruttura con delle variabili di template. Invece di scrivere un replica count specifico, un image tag fisso per il container o una variabile d'ambiente distinta direttamente in un file di deployment, definisci dei placeholder. Al momento del deploy, Helm unisce questi template con un file separato che contiene i tuoi valori specifici. Questa architettura significa che mantieni sempre e solo un singolo Chart per la tua applicazione. Gli passi semplicemente parametri di configurazione diversi a seconda che tu stia facendo il deploy in locale, in staging o in produzione. Quando prendi un Chart, lo combini con i tuoi valori di configurazione specifici e ne fai il deploy su un cluster Kubernetes, crei quella che Helm chiama una Release. Ed è qui che la cosa si fa interessante. Un Chart è solo il blueprint generico. Una Release è l'istanza deployata che gira nel tuo cluster. Grazie a questa netta separazione tra il blueprint e l'istanza, puoi installare l'esatto stesso Chart più volte nell'esatto stesso cluster. Se hai bisogno di tre istanze separate di un caching server, non duplichi lo YAML. Installi il chart di caching tre volte. Helm traccia ogni installazione come una Release distinta, con il suo nome univoco, i suoi valori di configurazione e il suo lifecycle isolato. Helm traccia anche lo stato e la history di queste Release all'interno del cluster. Quando aggiorni un'applicazione fornendo un nuovo image tag o modificando un'impostazione, Helm valuta le differenze e crea una nuova revision di quella specifica Release. Applica solo le modifiche necessarie alle risorse Kubernetes sottostanti. Se un aggiornamento fallisce o un'applicazione inizia a comportarsi in modo anomalo, puoi dire a Helm di fare un rollback a una revision precedente. Helm sa esattamente quali risorse Kubernetes appartengono a quale versione della tua applicazione, gestendo la creazione, la modifica e l'eliminazione di quelle risorse come un'unica operazione. Il cambiamento fondamentale con Helm è l'astrazione. Smetti di gestire file di testo indipendenti che rappresentano pod, service e volume disconnessi, e inizi a fare il deploy, configurare e aggiornare applicazioni complete. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, episodio 7 di 10. Devi aggiornare la password di un database, ma le credenziali sono hardcoded in quindici file YAML diversi. Basta un file mancante e l'intero deployment fallisce. Hardcodare la configurazione direttamente nella struttura del tuo deployment è un approccio fragile. La soluzione è comprendere l'anatomia di un Helm chart. Un Helm chart è un pacchetto standardizzato che contiene tutte le definizioni delle risorse necessarie per eseguire un'applicazione, un tool o un servizio all'interno di un cluster Kubernetes. L'intero sistema si basa su una filosofia fondamentale: una rigorosa separazione tra definizione strutturale e configurazione specifica dell'ambiente. Definisci la forma del tuo deployment una sola volta e inietti i dettagli specifici quando è il momento di fare il deploy. Quando guardi all'interno di un Helm chart, trovi una struttura di directory specifica. La cartella principale prende sempre il nome dal chart stesso. All'interno di questa cartella, tre componenti principali guidano il sistema di packaging. Il primo è un file chiamato Chart punto yaml. Questo è l'hub dei metadati. Dice a Helm esattamente cos'è il pacchetto. Contiene la versione delle API per lo standard del chart, il nome del chart, una descrizione e i numeri di versione. Cosa fondamentale, tiene traccia sia della versione del chart stesso, sia della app version, ovvero la versione del software che stai effettivamente deployando. Potresti anche trovare una directory charts lì accanto, che contiene eventuali subchart da cui dipende la tua applicazione, ma il file dei metadati è l'identificatore principale. Il secondo componente fondamentale è la directory templates. È qui che risiede la definizione strutturale. Al suo interno, inserisci i tuoi file manifest standard di Kubernetes, come deployment e service. Tuttavia, invece di scrivere YAML statico, questi file contengono la logica dei template Go. Invece di hardcodare un replica count a tre, o di incollare una password specifica per il database, scrivi una direttiva template. Questa direttiva dice a Helm di recuperare dinamicamente il valore richiesto durante il deploy. Il terzo componente risponde a queste ricerche dinamiche. È un file chiamato values punto yaml, che si trova nella root della directory del chart, accanto al file dei metadati. Questo file contiene i setting di configurazione di default. Quando un template richiede un image repository, un numero di porta o una password, il file values fornisce la risposta di base. Ecco il punto chiave. I template dettano l'architettura della tua applicazione, mentre i values dettano come quell'architettura si comporta in un ambiente specifico. Quando esegui un comando di install, Helm prende i template grezzi, fa il merge con il file values, e renderizza dei manifest Kubernetes finali e validi. Poi invia questi manifest renderizzati alle API di Kubernetes. Questa separazione è ciò che rende i chart altamente riutilizzabili. Considera uno scenario in cui devi fare il deploy della stessa identica applicazione sia in un ambiente di staging che in un ambiente di produzione. Non copi e modifichi il chart. Usi la stessa identica struttura di directory e gli stessi identici template. Per il deploy in staging, passi a Helm un file values custom durante il comando di install. Questo file fa l'override dei default, specificando una pod replica, l'URL di un database di test locale e un logging a livello di debug. Quando fai il deploy in produzione, passi un file values completamente diverso. Questo file di produzione specifica dieci repliche, l'URL di un database gestito e rigidi vincoli sulle risorse. Helm fa il merge del singolo set di template con i rispettivi file values custom, producendo due profili di deployment completamente diversi. La potenza di un Helm chart non sta nello YAML che contiene, ma nei confini che crea. Blocca l'architettura dell'infrastruttura nei template, mantenendo i dettagli operativi completamente fluidi nei values. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Kubernetes e Helm, episodio 8 di 10. Il fatto che tu possa usare i template per ogni singola riga di un manifest Kubernetes, non significa che tu debba farlo. Quando cerchi di rendere configurabile ogni campo, finisci per avere un chart che nessuno riesce a leggere, figuriamoci a mantenere. Questo episodio tratta le best practice dei chart Helm, le regole che impediscono alle tue configurazioni di collassare sotto il loro stesso peso. La trappola più grande nella creazione di chart è l'over-templating. Molti sviluppatori trattano i template Helm come un semplice script di text replacement. È un malinteso comune. Helm esegue un template engine Go per produrre YAML strutturato e valido. Se butti una variabile in un file senza gestire con attenzione l'indentazione e i data type, lo YAML generato si romperà del tutto. Per questo motivo, dovresti usare i template solo per i valori che cambiano davvero tra gli environment. Pensa agli image tag, alle replica, ai resource limit o alle regole di ingress. Lascia i campi strutturali principali hardcoded. Se un utente non ha mai bisogno di modificare uno specifico security context o un volume mount, non esporlo come variabile. Il file values punto yaml funge da API pubblica per il tuo chart. Quando organizzi questo file, devi bilanciare struttura e usabilità. La raccomandazione ufficiale è di mantenere la gerarchia il più piatta possibile. Anche se dovresti raggruppare i parametri correlati, evita il nesting profondo. Pensa all'utente che passa degli override da riga di comando. Costringerlo a digitare un path separato da punti profondo cinque livelli solo per cambiare un numero di porta crea inutili attriti. Se hai la configurazione di un web server, metti le property sotto un'unica chiave server, ma mantieni piatte le property interne. Quando dai il nome a queste variabili, usa sempre il camel case. Inizia con una lettera minuscola e metti in maiuscolo la prima lettera di ogni parola successiva. Non usare trattini o underscore nel tuo file values. Potresti creare una variabile chiamata externalPort, anziché external trattino port. Un camel case coerente previene errori di parsing durante il rendering del template e rispetta gli standard più ampi dell'ecosistema Kubernetes. Inoltre, mantieni una rigorosa type consistency. Se un parametro è un integer in Kubernetes, come un numero di porta, lascialo come integer nel tuo file values. Non racchiuderlo tra virgolette per trasformarlo in una string. Questa coerenza si applica direttamente a come tagghi le risorse generate dal tuo chart. Ogni oggetto ha bisogno di label standard. Le best practice di Helm impongono di usare le app label ufficiali di Kubernetes. Nello specifico, usa il prefisso app punto kubernetes punto io. La label name dovrebbe mappare il nome del chart, mentre la label instance dovrebbe mappare il nome della release. Includi anche la label version, e specifica che la risorsa è gestita da Helm. Applicare queste esatte label a ogni deployment, pod, service e config map assicura che i tool di monitoraggio esterni e i service mesh possano scoprire e raggruppare automaticamente i componenti della tua applicazione senza configurazione manuale. Ecco il punto chiave. Il miglior chart Helm non è quello con più opzioni di configurazione. È quello che richiede il minor numero di override per funzionare correttamente out of the box. Se vuoi aiutarci a portare avanti lo show, cerca DevStoriesEU su Patreon: apprezziamo davvero il supporto. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Fondamenti di Kubernetes e Helm, episodio 9 di 10. Costruire un cluster da zero è un ottimo esercizio per imparare, ma quando scali a centinaia di microservizi, non vuoi gestire il control plane da solo. Vuoi che il cloud provider faccia il lavoro pesante, così i tuoi ingegneri possono concentrarsi sul rilasciare codice. Questo è esattamente l'aspetto di un'implementazione enterprise di Kubernetes e Helm su Azure. In un'architettura Kubernetes standard, hai un control plane che prende decisioni globali e dei worker node che le eseguono. Mantenere quel control plane in alta affidabilità è notoriamente difficile. Un cliente enterprise che fa deploy su Azure in genere utilizza Azure Kubernetes Service, o AKS. AKS astrae il control plane. Azure gestisce l'API server, lo scheduler e il key-value data store. Il tuo team operations è responsabile solo dei worker node che fanno effettivamente girare le tue applicazioni. Quindi, come fa un'applicazione ad arrivare dalla macchina di uno sviluppatore a quei worker node? È qui che Helm entra nel workflow. Un'applicazione enterprise raramente è composta da un singolo container. Di solito è un insieme di microservizi, ognuno dei quali ha bisogno dei propri deployment, service e configurazioni. Invece di gestire decine di file YAML statici, gli sviluppatori pacchettizzano queste risorse in un Helm chart. Un chart funziona come un singolo blueprint versionato per un microservizio. Dato che Helm usa i template, gli sviluppatori possono scrivere la logica strutturale una volta sola e iniettare valori di configurazione diversi a seconda che stiano facendo deploy su un cluster di development, staging o production. Prima che qualsiasi cosa venga eseguita, il codice dell'applicazione viene buildato in container image. Queste immagini vengono pushate in uno storage sicuro, come un container registry. Anche gli stessi Helm chart possono essere pacchettizzati e pushati su un registry, il che permette ai team enterprise di trattare le definizioni della loro infrastruttura esattamente come il codice compilato dell'applicazione. Ecco il punto chiave. Quando una release pipeline triggera un deployment, Helm valuta i suoi template con i valori specifici dell'environment e invia i manifest finali all'API server di AKS. Il control plane di AKS legge questo desired state e inizia a schedulare i Pod sui tuoi worker node. I nodi contattano il container registry, si autenticano in modo sicuro, fanno il pull delle versioni specifiche delle immagini e tirano su i container. Kubernetes monitora costantemente questo stato. Se un worker node crasha, il control plane rischedula immediatamente i suoi Pod su nodi sani per mantenere il replica count definito nell'Helm chart. Una volta che i Pod sono in esecuzione, devono ricevere traffico. Un Helm chart includerà tipicamente la definizione di un service per esporre l'applicazione. Quando questo viene deployato su AKS, Kubernetes parla direttamente con l'infrastruttura Azure sottostante. Se il service richiede un entry point pubblico, AKS fa automaticamente il provisioning di un Azure Load Balancer. Questo load balancer prende il traffico esterno in entrata e ne fa il routing in modo sicuro nel cluster, distribuendolo tra i Pod sani. I tuoi sviluppatori non hanno mai dovuto toccare il portale di Azure o scrivere regole di routing cloud specifiche. Hanno semplicemente definito un service Kubernetes standard nel loro Helm chart, e la piattaforma gestita si è occupata del provisioning della rete fisica. La vera potenza di questa architettura enterprise è la netta separation of concerns. Helm standardizza come l'applicazione viene definita nei vari environment, il registry mette al sicuro gli artifact versionati, e la piattaforma cloud gestita assicura che l'infrastruttura sottostante rimanga effettivamente viva per farla girare. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, episodio 10 di 10. Hai la teoria e gli strumenti. Ma quando guardi un terminale vuoto, il divario tra l'enorme infrastruttura cloud e il tuo laptop sembra incredibilmente ampio. Colmare questo divario è esattamente il senso di iniziare a usare Minikube. Un cluster Kubernetes di produzione prevede diverse macchine che fungono da control plane e worker nodes. Fare il provisioning di tutto ciò nel cloud costa soldi, richiede tempo e una complessa configurazione di rete. Se sei uno sviluppatore singolo o un piccolo team che progetta un'architettura day-one, hai bisogno di un ambiente locale che si comporti esattamente come la produzione senza l'overhead. Minikube è un'implementazione leggera di Kubernetes che crea una macchina virtuale o un container direttamente sul tuo laptop. All'interno di quell'ambiente isolato, esegue il deploy di un semplice cluster single-node. Solitamente, Kubernetes separa il control plane, che gestisce lo stato del cluster, dai worker nodes, che eseguono i container della tua applicazione. Minikube li unisce. La tua macchina locale esegue un nodo che gestisce sia la logica di management che i veri e propri workloads dell'applicazione. Non è pensato per servire traffico di produzione. Esiste unicamente per consentirti di testare in sicurezza l'orchestrazione dei container. Ecco il punto chiave. L'interfaccia che utilizzi per interagire con Minikube è identica a quella che usi per un enorme cluster in cloud. Usi il tool da riga di comando chiamato kubectl. Quando esegui un comando kubectl, questo comunica direttamente con il control plane di Minikube tramite la sua API. Non c'è nessuna sintassi speciale da imparare per lo sviluppo locale. Il workflow corrisponde perfettamente al tutorial ufficiale di base di Kubernetes. Avvii il cluster con un semplice comando start. Minikube fa il provisioning dell'ambiente e configura automaticamente kubectl per puntare alla tua nuova istanza locale. Da lì, usi kubectl per creare un deployment. Dici al control plane di fare il pull di una specifica container image e di eseguirla. Una volta deployata, la tua applicazione è in esecuzione all'interno di un pod su quel singolo nodo. Tuttavia, è isolata dalla tua host network. Per accedervi dal browser del tuo laptop, devi esporla creando un service. Un service instrada il traffico da una porta specifica sulla tua macchina locale verso la porta corretta sul pod in esecuzione all'interno di Minikube. A questo punto, puoi esercitarti con tutte le funzioni principali di Kubernetes. Puoi scalare la tua applicazione dicendo a kubectl di aumentare il replica count. Minikube avvierà pod aggiuntivi accanto al primo. Puoi esercitarti con i rolling updates modificando la versione della container image nel tuo deployment. Minikube terminerà in modo graceful i vecchi pod e ne avvierà di nuovi, simulando un deployment zero-downtime. Dato che Minikube espone un'API Kubernetes standard, il tuo tooling esterno si integra perfettamente. Helm funziona immediatamente. Puoi installare database complessi, ingress controllers o message queues usando gli Helm charts esattamente come faresti in un ambiente live. Minikube include anche degli addons integrati, come una web dashboard locale, che ti permette di ispezionare visivamente lo stato del cluster, leggere i logs e monitorare l'utilizzo delle risorse. Il vero potere di un cluster locale è la parità. Quando scrivi una configurazione di deployment o un Helm chart che funziona correttamente su Minikube, hai già scritto l'esatta configurazione che verrà eseguita nel cloud. Prenditi del tempo per esplorare la documentazione ufficiale di Kubernetes e prova questi comandi hands-on. Se hai suggerimenti su argomenti che dovremmo trattare nella nostra prossima serie, visita devstories dot eu e faccelo sapere. Per oggi è tutto. Grazie per l'ascolto, vai a creare qualcosa di figo.