Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori ormai come ben sapete l'estate è più che inoltrata, noi stiamo registrando questo episodio nella seconda settimana di luglio, probabilmente ve lo starete già ascoltando verso agosto quando diciamo le vostre carnagioni avranno già assunto un colore più più scuro, però vacanze a parte il mio compito in questo momento è quello di ricordarvi rapidamente i nostri contatti info@gitbar.it @brainrepo su twitter sono i modi canonici per contattarci esiste però il nostro gruppo telegram che è un po' il luogo fisico dove ci incontriamo fisico virtuale dove ci incontriamo è appunto la sala centrale del nostro GitBar se non l'avete ancora fatto mi raccomando iscrivetevi, io sono in vacanza ormai ho dimenticato come si parla.Il gruppo lo trovate direttamente sul vostro client telegram cercando semplicemente gitbar e unitevi a noi se non l'avete ancora fatto.Detto questo io direi che possiamo iniziare.Cosa stavo dimenticando? Nulla! No, stavo dimenticando di ricordarvi una cosa importantissima.Questo episodio è in collaborazione con Code Emotion, è stato registrato in collaborazione con Code Emotion Infatti l'output di questo episodio non sarà solamente l'audio che state sentendo quindi la puntata vera e propria ma diciamo che basata su questa puntata ci sarà anche una card collezionabile che potrete trovare durante appunto l'evento di Code Emotion e potrete collezionare.Le card sono 10 e quella dell'episodio di oggi sarà una delle 10 card.Oggi parliamo di un argomento particolare, cioè almeno è un argomento ormai mainstream da un po', però voglio introdurlo e quindi introdurre la nostra ospite parlandovi un secondo di come mi ci sono avvicinato perché detto così sembra una cosa strana ma è un po' un pattern che ho ho riconosciuto.Parliamo di Kubernetes.La prima volta che ho visto Kubernetes non ci ho capito praticamente nulla.Io già utilizzavo Docker, però Kubernetes introduceva tanti concetti nuovi per cui mi sono avvicinato, ho letto un po' e mi sono allontanato.E sono rimasto parecchio tempo abbastanza lontano da Kubernetes, per poi riavvicinarmi in un secondo momento e scalfire un po' la superficie e scendere un pelino più a fondo in una specie di percorso d'apprendimento che io chiamo a orbite, quindi mi avvicino e mi allontano, mi avvicino e mi allontano.Questo pattern di apprendimento, diciamo ritorna spesso quando quando quando deve apprendere qualcosa e non so se anche a voi vi è mai capitato di utilizzare questo approccio.Oggi parliamo di Kubernetes perché in realtà in quest'ultimo periodo ho ricevuto un paio di vostri messaggi che chiedevano "Mauro per favore puoi fare step back e possiamo vedere in un episodio alcuni dei concetti principali e fondamentali di Kubernetes? Allora chi sono io per dire di no? Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente [Musica] Quindi ho organizzato questo episodio con la grandissima Serena Sensini, Enterprise architect presso Daedalus SPA ha anche scritto da abbastanza poco un libro in italiano che si intitola "Kubernetes guida per orchestrare i container" e anche autrice del blog del RedPod.Ciao Serena grazie per essere venuta.Ciao grazie a te! Ti ho già stordito con una valanga di parole vero? No, devo dire che la presentazione è stata veramente carina e soprattutto quando hai detto quando mi sono approcciato per la prima volta a Kubernetes non ci ho capito niente perché è la stessa identica sensazione che ho provato io la prima volta collaborato con Docker, dicevo "questa roba non servirà a nulla" e invece poi ci ho scritto un libro e quindi mi sono ricreduta tantissimo ovviamente.Ti voglio fare una domanda proprio perché hai citato a Docker, io sono arrivato a Docker in tempi ormai veramente antichi venendo da Vagrant e il mondo delle macchine virtuali, a Vagrant usavo Ansible per fare il provisioning e poi Docker e dopo diciamo la prima o la seconda settimana di Docker ho detto "caspita sta cosa è veramente non mi devo scrivere i miei ansibol perché è pienissimo di ricette già pronte.Diciamocelo, no, la pigrizia è il driver principale.Però una cosa più complessa è stato il passaggio, in termini proprio di presa di consapevolezza, tra Docker come concetto, quindi con tenerizzazione in genere e Kubernetes.Come è stato il tuo passaggio tra Docker e Kubernetes a livello di apprendimento? A livello di apprendimento è sicuramente un bel salto, lo definirei più o meno l'equivalente del salto dal dall'università al mondo del lavoro.Quello che fai all'università è tutto teorico, richiede un sacco di studio per gli esamini prepari, ci passi magari le ore e dopodiché quando inizi il tuo primo giorno di lavoro dici ok tutto quello che ho fatto negli ultimi 3/4/5 anni quello che è, era forse la punta dell'iceberg di quello che effettivamente mi serve.Con docker e kubernetes è più o meno la stessa cosa, nel senso che docker per sé fornisce sicuramente una base super utile per tutte le persone che sviluppano per permettergli di rendere il proprio lavoro portatile una frase che io cito sempre è "con Docker si smette di dire sul mio PC funziona, sul tuo non so perché non funzioni" perché Docker risolve per molti aspetti questo problema con Kubernetes dici "ok, ho sviluppato la mia applicazione, funziona adesso devo metterla a disposizione degli utenti e magari sperare che la mia applicazione, faccio anche il botto, abbia un bel successo e quindi ci sia bisogno di un'architettura che regga questo carico di lavoro e qui entra in un gioco Kubernetes dove ovviamente ti devi porre tutta una serie di problemi che prima non ti eri assolutamente posto Sicuramente il fatto di aver iniziato a lavorare come Enterprise Architect ma in realtà anche prima, mi ha fatto capire che questa è una tecnologia che è molto mainstream, però ti fa avere una visione a 360 gradi di come funziona il software da inizio alla fine.Non so se ho risposto un pochino alla tua domanda.Sì, è stata chiarissima.Infatti, partendo dalla tua risposta, mi è venuta in mente un'altra domanda, cioè almeno un'altra situazione da condividere.Sai, uno dei problemi che ho avuto io quando ho avuto il primo incontro con Kubernetes si basa molto sul mio metodo di apprendimento, che è per imparare qualcosa penso a un ipotetico side project, uno dei diecimila, e provo a basare il mio apprendimento nel percorso di realizzazione di questo ipotetico side project che non vedrà mai la luce.Uno dei problemi che ho avuto con Kubernetes e sta nel fatto che in realtà di per sé è un mastodonte come insieme di concetti, è molto difficile portarlo nel side project.Vero è che ti puoi installare il minicube sul tuo computer e provare a giocare di lì, però se per sbaglio vuoi andare in produzione, per quanto becera possa essere, allora ecco che, per esempio, banalità, i costi per deploiare lo stupido sitino con Kubernetes non sono gli stessi che buttarlo su Netlify, su Vercel, su Heroku della situazione.La complessità è altrettanto difficile e soprattutto gli ambienti che tu puoi ricostruire in locale divergono parecchio da quelli che sono gli ambienti standard, chiamiamoli standard anche se è sbagliato il termine, però gli ambienti più comuni, come dove gira Kubernetes.Ecco, la mia domanda è, tu hai mai vissuto questo tipo di attrito? E se sì, come si può limare? In realtà questa è posta diversamente, è una domanda che mi viene fatta spesso e nonostante questo sicuramente non faccia bene a me che ho pubblicato questo libro, io sono solita dire che non per forza si deve utilizzare Kubernetes, proprio perché è una tecnologia che negli ultimi tempi anche a molti professionisti del settore ha un po' stufato, perché se ne sente parlare in continuazione, non è la panacea, non risolve tutti i problemi.Uno tra i tanti svantaggi nell'utilizzare una tecnologia del genere è quello che dicevi tu, sicuramente la complessità anche in termini di costo non è così semplice, quindi per un progetto di un certo tipo come può essere un side project e pensare di immaginarlo all'interno di un'infrastruttura così grande è un po' un po' pleonastico, un po' esagerato.Dici "ma questa roba mi serve sul serio, siamo sicuri?" In realtà diciamo secondo me il modo migliore per proiettarsi a a Kubernetes è pensare in grande, dire "ok ho un sogno, ho la mia piccola applicazione che può essere un sito web, un'applicazione di qualunque tipo, ad oggi la usano in 10 persone ma il mio sogno è che domani siano un milione e allora so per certo che quel milione io non lo posso gestire dal mio laptop" e quindi ti inizi a fare tutta una serie di domande del tipo appunto come come gestisco questo flusso di utenti come come faccio a rendere la mia architettura resiliente che è un'altra di quelle parole che si sente tantissimo e via dicendo e in Kubernetes troviamo molte di queste risposte poi se ti dovessi dire anche da Enterprise Architect che Kubernetes ti serve, dipende, è sicuramente una tecnologia che, come dicevo anche prima, ti richiede una conoscenza del software ma anche del design del software e delle architetture in generale che è abbastanza complessa perché mentre docker tu lo installi, vai sul sito, ti scarichi docker desktop, fai due click e praticamente sei pronto per lavorare, kubernetes ti richiede che anche tu capisca che cosa sta succedendo dietro perché ci sono tantissimi componenti che fanno parte del contesto dove ognuno ha un ruolo ben preciso.Fermo restando che come Redes da un paio d'anni è installabile sempre tramite Docker Desktop, quindi sotto questo punto di vista abbiamo un po' semplificato anche l'approccio iniziale.È chiaro che è completamente diverso e serve per fare una serie di test, per fare una serie di demo in locale per chi magari ci vuole prendere confidenza.Però è chiaro che dal punto di vista architetturale manutenerlo e gestirlo è diverso e non a caso esistono dei ruoli specifici.Per chi lo deve utilizzare, diciamo, lato sviluppo ma anche lato DevOps, è un altro contesto ancora.Quindi è una tecnologia che, secondo me, riunisce diversi ruoli professionali che devono avere punti di vista completamente diversi.Sì, in realtà sono apparse al mainstream perché magari hanno figure già presenti, ruoli come l'SRI o altri che c'erano già ma sono apparsi nel panorama in modo imponente.Quindi alla fine ci ritroviamo ad affrontare un elemento enorme, difficilmente possiamo utilizzarlo nei nostri site project, però il mercato ormai è oline.Io ricordo di aver fatto un po' di anni fa un paio di workshop su DCOS, tutti i competitor sono spariti.Secondo te perché? DL: Mi piace pensare, me lo sono chiesto tante volte, in realtà anche nella letteratura online non mi è mai capitato di trovare una risposta univoca, però mi piace pensare che sia uno di quei progetti che è partito da persone estremamente entusiaste che l'hanno portato avanti nonostante il mercato in quel momento fosse già saturo di una serie di tecnologie non dico più o meno simili però che già si stavano approcciando a questa modalità di pensare e che siano riusciti a venderla molto molto bene.Un po' come docker ha rivoluzionato il modo di rilasciare il software eliminando tutta una serie di problemi dovuti alla configurazione, la diversità di sistemi operativi, di infrastrutture in generale.Kubernetes è un prodotto che si è affermato tantissimo soprattutto grazie anche al lavoro delle community e questo trovo che sia una cosa bellissima perché sicuramente è nato all'interno dei laboratori Google che quindi diciamo hanno contribuito in maniera importante anche alla crescita di questo progetto.Però poi hanno trovato talmente tanto appoggio da parte delle community, anche di aziende che fanno open source da tantissimo tempo, che ne hanno permesso il decollo.Ad oggi, come dicevi tu, è una delle tecnologie che anche avendo delle alternative rimane comunque leader.C'è da poco Alberto Massida diceva una cosa interessante sulle tecnologie, lui parlava di Linux, lui diceva guarda con Linux molto semplice c'è stata la sfida dei sistemi operativi poi ne uscito uno, che comunque in termini di qualità superava gli altri, non era perfetto in ogni sua componente, però superava gli altri a livello di community, a livello di qualità, a livello anche di fama e alla fine si è attestato, ci si è fermati, non fermati, che è diventato una pietra miliare, ecco quello che diceva lui.Io potrei, mi verrebbe da dire lo stesso per Kubernetes, però aggiungerei un ragionamento e correggimi se sbaglio, uno dei motivi del successo di Kubernetes, o almeno quello che ho percepito io, è la sua estendibilità.Una API così potente, tutto il mondo degli operator, che poi magari ne parleremo un attimo e proveremo a chiarire di cosa si tratta.Secondo me sono stati quegli elementi che hanno detto "ok, questa base è una base, non ha tutto, ma è una base ed è abbastanza solida per costruirci tutto sopra, ok, spostiamo l'effort da costruire un orchestratore a aggiungere funzionalità a un orchestratore.Questa è un po' la mia visione magari sbagliata.No, no, in realtà è una visione molto interessante perché sicuramente Kubernetes rispecchia molto quello che io chiamo, che io non l'ho inventato io, ma nasce anche grazie tra l'altro a un libro super interessante che con l'IT ha a che fare poco però è interessante per capire come funziona in generale il mondo anche delle start up che è pretotype it.ComonEdites viene rilasciato come pretotipo quindi non era ancora un prototipo funzionante, siamo ancora uno step prima, ma era un progetto su cui delle persone iniziano a pensare, iniziano a buttare giù una serie di idee e a vedere se funzionano.Una volta che viene lanciato il primo prototipo, probabilmente sono così intelligenti da organizzare una Qubecon a solo un anno di distanza dal primo rilascio.Immagina un progetto che viene rilasciato per la prima volta, ha la sua prima release in assoluto, in realtà lo usano all'interno dei laboratori Google, ma non è così diffuso ancora, organizzano una conferenza internazionale per parlare solo di quella tecnologia e questo raccoglie un bacino di utenti tale che sicuramente ne permette anche una maggior diffusione.Secondo me anche questa è una chiave importante di lettura di un progetto che ha avuto un enorme successo sul mercato, perché il fatto di poterlo presentare al pubblico, di poterne parlare, di farne parlare ha fatto sì che siamo qui adesso a raccontarlo.Tra l'altro ti ringrazio per averci dato l'ultima puntata perché a parte averla ascoltata tra le altre varie puntate, l'ho ascoltata con un sacco di interesse perché tu devi sapere che coincidenza vuole che Alberto Massidda sia stato il mio professore di Linux all'università e sia stata una di quelle persone che fin da subito mi ha sostenuto tantissimo nella mia carriera nell'ambito IT, buttandomi in un contesto di cui io non sapevo assolutamente nulla perché al primo anno di università ero un po' così spaisata di Linux, si sapevo qualcosa ma sicuramente non avevo le competenze che poteva avere lui in quel momento, ma figuriamoci adesso e grazie a lui, grazie anche al lavoro di altri colleghi, mi sono buttata in questo mondo, letteralmente buttata ed è stata un'esperienza bellissima.Io tutte le volte che ripenso a come ho iniziato questa carriera, ripenso a tutte le settimane che lui in modo assolutamente volontario veniva all'università a tenere questi corsi di Linux, ma in realtà anche di altro perché ha tenuto anche un sacco di seminari che io seguivo con un'attenzione incredibile sempre in prima fila insieme ai miei colleghi.Infatti abbiamo tra l'altro con i miei colleghi ereditato gran parte del lavoro che aveva portato avanti lui all'interno del contesto universitario e da lì è partito un po' tutto.Quindi tutte le volte che mi capita anche di incontrarlo mi fa super piacere perché è una persona da cui veramente ho imparato tanto e diciamo che mi fa piacere in generale riprendere anche come mentor della mia carriera.Io ho perso un pezzettino di quello che dicevi, scusa, qua è crollato tutto.Volevo farti a questo punto una domanda.Proviamo a scalfire la superficie di Kubernetes è a provare a ragionare sull'architettura di Kubernetes stesso.Quali sono le componenti dell'orchestratore? Se lo vediamo da un punto di vista architetturale, quindi ci mettiamo un attimo il cappello di architetto praticamente ci dobbiamo attestare su due concetti principali all'interno di un orchestratore è necessario avere tutta una serie di macchine io le chiamo macchine perché server non fa pensare a per esempio istanze che sono in cloud e non fa pensare neanche a macchine virtuali, ma all'interno del contesto di Kubernetes, dove questo giri importa poco, quindi qualunque tipo di macchina abbia della RAM e della CPU, con una serie di requisiti minimi chiaramente va bene.In questo contesto ci sono una serie di macchine con diversi ruoli, i ruoli principali sono due, uno è quello di gestione e controllo, o coordinamento se vogliamo, è quello delle macchine che si chiamano Control Plane.Nella letteratura in realtà si potrebbe trovare anche come alternativa Master Notes, anche se adesso diciamo anche per direttiva Red Hat si cerca di utilizzare dei termini che siano più accessibili, quindi Master, richiamando un po' il concetto di Master Slave, è stato ribattezzato in Control però è chiaro che su alcune parti della documentazione questa sostituzione non è ancora avvenuta.Dall'altra parte abbiamo quelli che eseguono il carico di lavoro, e che quindi mettono in pratica quanto richiesto da questi gestori, che sono i nodi computazionali, se vogliamo dirlo in italiano, altrimenti sono i worker nodes o compute nodes.Quindi noi diciamo all'interno di un'architettura possiamo immaginarci che ci sia al minimo sindacale un control plane e un worker node che si coordinano tra loro.Se dobbiamo prendere la nostra applicazione, il nostro side project, quando andremo a deploiare, quindi quando andremo a installare il nostro container all'interno del cluster Kubernetes sarà il nodo Control Plane a gestirne l'esecuzione e la resilienza attraverso tutta una serie di meccanismi che ne controllano lo stato di esecuzione sul nodo computazionale.Domanda, tu hai parlato di più nodi che possono agire da Control Plane.Come funziona l'organizzazione di questi nodi? Agiscono tutti contemporaneamente? Come funziona condividere in qualche modo lo stato, le informazioni sullo stato del cluster? Come funziona proprio questa parte? Allora all'interno di un'architettura dove ci sono più nodi master o più nodi control plane, e più no, diciamo, esecutivi, normalmente abbiamo detto che appunto la parte di gestione è delegata ai control plane.Questi si coordinano tramite una serie di componenti, primo tra tutti cioè sicuramente tcd, che praticamente è il database che conserva lo stato di tutto ciò che è stato rilasciato e installato all'interno del cluster.Tutte le configurazioni, tutti i cambiamenti, le modifiche, gli aggiornamenti tramite questo database enorme e replicato, ok? Noi conserviamo lo stato del cluster, di modo che se uno dei nodi computazionali per qualche motivo avesse un errore, ci sarà sempre una sorta di registro delle informazioni a cui fare affidamento per ripristinare queste applicazioni.Tenendo conto che la replicazione dei nodi master, quindi il fatto di avere più nodi che gestiscano questa parte di lavoro, serve anche a permettere una maggiore resilienza.Possiamo pensare che per esempio, come dicevo prima con Docker Desktop, quando noi andiamo ad installare il nostro cluster, avremo in pratica un'architettura dove avendo a disposizione solo il nostro laptop, master e worker o control plane e compute coincidono.Quindi se il nostro laptop per qualche motivo ci abbandonasse, ovviamente cadrebbe tutta l'infrastruttura.Ma all'interno di un'architettura più complessa, è sicuramente necessario che questi gestori siano numerosi.Di modo che, stiamo parlando sempre di stanze, di macchine che potrebbero subire qualunque tipo di guasto, ci sia qualcuno pronto a rispondere.Tramite alcuni algoritmi di sostituzione, questi sono in grado di prendere il posto l'uno o dell'altro, avendo anche tutte le informazioni di cui devono risporre attraverso questo database, nel caso in cui uno dei nodi che gestisce l'infrastruttura cada.Perché per quanto il nostro cluster possa affidarsi a provider, per esempio in cloud, che garantiscono il 99,9% di corretto avvio e esecuzione delle istanze, può sempre succedere qualcosa.in questo senso avere una replicazione sia dei nodi che gestiscono ma anche dei nodi che eseguono è estremamente importante e si coordinano tra loro.Come ti dicevo, tramite una serie di algoritmi ma tramite anche per esempio dei componenti che fanno parte di questi nodi, ne cito giusto qualcuno, comunque sicuramente c'è il Cube Controller Manager per esempio che si occupa di gestire una parte del lavoro e TCD memorizza tutto lo status delle varie risorse, c'è lo scheduler che per esempio è quel componente che si occupa di dire ad un container, mi tengo sul concetto di container che forse in questo momento è più semplice, di andare a lavorare su un nodo computazionale piuttosto che un altro, a seconda delle risorse richieste.Quindi ci sono tutta una serie di attori di cui ognuno ha la sua responsabilità e riesce a gestire complessivamente le soluzioni che sono sono deployate al suo interno.Per cui quando io devo fare qualunque cosa nel mio cluster Kubernetes devo parlare col control plane giusto? Tu normalmente parli con il control plane tramite l'API.Ok perfetto.Poi magari andiamo a vedere un po' anche il mondo dei template no? quindi passiamo rapidamente a vedere Helm.Per quanto riguarda invece il worker, quali sono le componenti del nodo che fa lo sporco lavoro? Quello che si occupa praticamente della parte pratica diciamo.Ci sono anche qui diversi componenti.Come abbiamo detto, dovendosi occupare del lavoro sporco, i componenti sono diversi.Il primo sicuramente è il container runtime, quindi l'ambiente che si occupa di eseguire effettivamente il container, che a seconda delle installazioni può cambiare.Normalmente ci sono diverse tecnologie che fanno parte di quello che si chiama interfaccia di esecuzione dei container, in inglese container runtime interface, i quali diciamo permettono l'esecuzione dei container all'interno di un ambiente come questo.Kubelet sfrutta quindi questo componente per poter mettere in esecuzione effettivamente le applicazioni tramite container all'interno del node worker.Dopodiché sempre, scusami, stavo dicendo, no, questo è il container runtime Kubelet, di cui non ho accennato, però kubelet è invece il punto di contatto più importante all'interno del cluster perché è un agente che viene eseguito su tutti i nodi worker che permette di eseguire effettivamente le applicazioni.Abbiamo detto prima che il punto di contatto tra l'utente che usa kubernetes e il cluster sono le API, allo stesso modo il punto di contatto tra i nodi Control Plane e Worker, sono sempre le API e Kubelet quando deve andare ad eseguire qualcosa riceve queste informazioni sempre tramite le API.Quindi ci sarà un nodo Control Plane a cui è stato ordinato tramite l'utente di deployare un container X, lo prende in carico dopo che lo scheduler ha deciso qual è il nodo su cui questo effettivamente deve essere eseguito perché alle risorse sufficienti tramite i kubelet questo viene avviato.Questi sono i due concetti principali, in realtà ce ne sarebbero altri come per esempio kube-proxy che è quel componente che si occupa di gestire la parte di rete per far sì che i diversi oggetti siano in grado anche di parlarsi, di comunicare proprio a livello di rete.Ok? Anche se c'è da dire che purtroppo Kubernetes, rispetto ad altre soluzioni che sono presenti sul mercato, non fornisce una soluzione di gestione di rete di base, ma richiede un pochino più di lavoro.Quindi con uno strumento come Docker Desktop dove andiamo a installare Kubernetes, Riusciamo a far sì che diversi container si parlino tramite delle interfacce di rete interne ma è un plus che viene aggiunto grazie a una struttura come Docker Desktop.Mi tengo su questo ma in realtà appunto di soluzioni per far funzionare Kubernetes ce ne sono tantissime.E questo sicuramente è una delle cose che la community ha criticato tanto perché comunque, come dicevi anche tu prima, ti fornisce lo strumento di base ma poi tutta una serie di sua strutture devono essere aggiunte e non sempre è semplice capire quando e come.Sì esatto, sta là la complessità.Però mi immagino che per esempio per i provider questa possa essere una panacea perché a quel punto loro possono sviluppare parte della struttura basandosi sulle proprie architetture immagino sulle proprie infrastrutture, scusami non architetture, sulle proprie infrastrutture.Quando si approccia a Kubernetes però entrano in gioco una serie di concetti nuovi al di là proprio dell'architettura di Kubernetes stesso, pod, replica set, stateful set, config, map, è a quel punto quando la confusione aumenta, il mauro della prima iterazione si avvicina e dice "eh sì".Per esempio parliamo di pod, noi siamo abituati a sviluppare in container, perché i pod? Perché iPod? Allora ti posso rispondere in questo modo, noi siamo abituati effettivamente a ragionare per container immaginando che la nostra applicazione possa essere messa all'interno di un singolo container anche se spesso e volentieri sappiamo che la nostra applicazione dovrà parlare con qualche altro oggetto ok? Se dovrà comunicare con qualche altro oggetto potremmo affidarci ad con altri container, quindi possiamo già fare una sorta di separazione dei ruoli che questi oggetti hanno.La definizione di pod in realtà è abbastanza chiara anche nella letteratura, perché il pod è letteralmente definito un insieme di uno o più container.E già mi rendo conto che a volte su questa definizione un po' ci si tende a perdere, perché si potrebbe dire perché uno più container? Uno più container perché fondamentalmente sappiamo benissimo che all'interno di un contesto applicativo è facile parlare di microservizi ma è anche altrettanto facile che spesso e volentieri la nostra applicazione abbia qualcosa di dipendente.io faccio sempre questo esempio che secondo me è molto semplice ma anche molto efficace penso per esempio a un web server che deve esporre un'applicazione web qualsiasi un web server può essere quello che vuoi, un nginx, un tomcat, qualunque cosa questo chiaramente funziona da solo, è indipendente perché l'unico compito che ha è quello di esporre questa applicazione se però avessimo bisogno, per esempio, di andare a misurare le performance di questo web server attraverso un qualunque strumento, mi viene in mente PHP, FPM, ma ce ne sono anche qui una varietà infinita, comunque voglio andare a studiare le metriche del server, se sta performando bene, se ci sono delle request che sono più lenti di altre, in questo caso io avrò bisogno di un un altro container che sarà specializzato in questa attività e che però sarà strettamente dipendente da questo primo perché chiaramente se non è attivo il web server non c'è niente da misurare e in questo contesto praticamente si va a creare quello che nel design architetturale del software si chiama accompiamento forte, perché sono due componenti che sono che sono strettamente legati tra loro e che non, diciamo, l'uno non sussiste senza l'altro.In questo caso chiaramente è univoco, diciamo, univoca la direzione di dipendenza, ma comunque la dipendenza c'è.In questo contesto il pod fa sì che io possa inglobare all'interno di questa sovrastruttura, chiamiamola così, entrambi i container.Questo è il contesto in cui parliamo, no, di sidecar application la possiamo definire un po' come vogliamo tu dici perché il pod? perché abbiamo bisogno di questo di questo wrapper? il pod è nato per essere appunto una sorta di aggregatore ok? non a caso la parola pod significa branco ed è stata stata scelta appositamente da coloro che hanno lavorato al progetto di Kubernetes perché volevano rappresentare anche questa possibilità di coniugare dei contesti in cui più container lavorassero a stretto contatto per portare a termine un tipo di lavoro.Branco sta diciamo anche a richiamare un po' Docker come tecnologia perché sappiamo sappiamo abbastanza bene che il logo dei docker rappresenta una balena, che si porta normalmente sulla schiena una serie di container, loro volevano richiamare un po' il concetto di un branco di balene, dove anche in natura una balena da per sé rappresenta già un branco a sé stante.Il fatto che possano essere più di uno e che questi siano guidati all'interno di un'unica entità rappresentata al concetto di pod.Un altro elemento super interessante invece è il replica set, replica set che viene quasi sempre insieme al deployment.Possiamo provare a inquadrare questi due elementi? sì allora cerco di essere cerco di farla facile il pod di per sé è il componente che si occupa meramente di eseguire la nostra applicazione il container il pod è però un'entità stateless che vuol dire vuol dire che praticamente se la nostra applicazione se il nostro container va in errore, il pod muore e non si ritirerà su, perché non c'è nessun meccanismo di per sé che dica al pod che cosa fare se qualcosa va storto.In questo contesto è necessario pensare invece ad un'entità che magari gestisce queste informazioni, gestisce per esempio le polisi di riavvio di un pod, le polisi che vanno a verificare se il pod sta funzionando correttamente, se è in esecuzione, e se risponde.E tutta un'altra serie di informazioni.Questo è il caso di tutti quei controller tra cui rientra anche il deployment.Ok? Il replica set, se lo immaginiamo un po' come una matrioska, è quello che si frappone tra il deployment e il pod.Mentre il pod è la parte core, e il deployment è quello che contiene la nostra matrioska iniziale, il replica set è la matrioska d'intermedia.perché è praticamente un componente il cui unico compito è quello di verificare che il numero di pod desiderati sia esattamente uguale al numero di pod attualmente in esecuzione.Niente di più, niente di meno.Per cui quando io devo pubblicare la mia applicazione nel mio cluster Kubernetes scrivo un file che descriva come deve essere il mio deployment, ne indichi il numero delle repliche e il pod che deve lanciare, giusto? Esatto, esattamente.A questo punto però io lo devo esporre, la mia applicazione, e là arriva un altro elemento di complessità perché hai un ODPort, un ingress controller, un altro ventaglio di opportunità.Come ci si orienta? [Risata] [Giulia] Guarda, questo sicuramente ti posso dire in tutta franchezza che è stato per anni uno degli argomenti peggiori che io ho dovuto affrontare anche all'università, è stato un un po' il mio drago, perché le redditi di calcolatori, come si chiamavano all'università, le redditi di calcolatori praticamente sono ostiche per tutti, non è semplice entrare in questo, un po' come la matematica al liceo.In un contesto come Qbernet, capire quali sono i meccanismi con cui io ho messo a disposizione la mia applicazione all'utente finale sembra una specie di mostro attraverso il test.Il concetto principale è questo Kubernetes mette a disposizione una risorsa che si chiama service dove di base noi abbiamo nella sua forma base perché poi ce ne sono diverse tipologie abbiamo questo service che accoglie le richieste le request in ingresso e poi le distribuisce ai pod applicativi Questo che cosa vuol dire? Vuol dire che sapendo che il nostro pod è stateless, quindi potrebbe essere riavviato a caso di un errore, potrebbe essere aggiornato perché chi sviluppa ha fatto una modifica, il pod non solo cambia il nome, ma viene anche cambiato l'indirizzo IP che è associato in maniera totalmente dinamica dal cluster.Quindi non possiamo fare affidamento sul concetto per esempio di indirizzo IP per far parlare le applicazioni.Ma c'è bisogno di creare un livello ulteriore di attrazione, che sia però persistente, che sia stateful.In questo caso il service è qualcosa di stateful, perché è una sorta di livello che sta sempre lì e che fa un po' da schermo rispetto a quello che c'è dietro.Quindi il fatto che ci possa essere un pod, 20 pod oppure nessun pod, fa sì abbiamo questa sorta di fronte che risponde in ogni caso alle richieste che arrivano e fa un po' da schermo, come ti dicevo nella sua forma base il service è anche una sorta di bilanciatore quindi è un oggetto che al di là del fatto che dietro ci possano essere uno o o 100 pod è in grado di ricevere le richieste e poi redirigerle.In realtà, come accennavi anche tu, ne esistono mille tipologie, però ne esistono diverse tipologie che richiedono sicuramente l'uso almeno di una mano a seconda del tipo di contesto e non sono complesse, molto diverse le une dalle altre.Quella che ti ho descritto io è sicuramente quella più semplice, esiste proprio il load balancer che si occupa solo di fare da bilanciatore, tu hai citato anche il concetto di ingress che in realtà non entra proprio nel contesto del service, ma è un componente ancora aggiuntivo.Prima di parlare dell'ingresso, direi di parlare del node port, che è un altro tipo di service che, per esempio, permette di uscire dal cluster.Che cosa intendo per uscire? Anche qui ci stendo proprio due parole.I service sono appunto dei componenti che ci permettono di far comunicare diversi port dall'interno del cluster.Come faccio ad aggiungere un'applicazione che all'interno dei cluster va fuori? Lo posso fare attraverso un non-port.Tutto il complesso sistema di rede che c'è all'interno dei cluster fa sì che io possa esporre più container sulla stessa porta.Più container, per esempio Tomcat, che espongono la porta 8080, non andranno in conflitto perché ognuno di essi avrà un proprio service che ha un suo indirizzo IP.Nel momento in cui dall'esterno volessi raggiungere una di queste applicazioni potrei aver bisogno di un oggetto come un NodePort che mette a disposizione una porta del cluster effettiva che io posso utilizzare per parlare con il cluster Quindi ogni tipo di service ha il suo ruolo sempre all'interno della comunicazione intra-cluster dovremmo a un certo punto uscire il nostro utente dovrà raggiungere la nostra applicazione in questo caso entra in gioco l'ingresso l'ingresso è in pratica il punto di contatto tra l'utente esterno e il cluster perché comunicando attraverso un service è in grado di far raggiungere le request di far arrivare le request direttamente all'applicazione sono tanti i concetti Ti posso dire, e su questo forse mi do una pacca sulla spalla, alla me di vent'anni che all'università non capiva assolutamente una massa di questi concetti, che anche all'interno del libro io ho cercato di fare tantissimi schemi, molti dei quali hanno aiutato me durante la mia carriera anche a capire e a comprendere veramente a fondo questi concetti.quindi spero che possano essere anche d'aiuto perché effettivamente ci si deve approcciare.LM: Riuscire a rappresentare questi concetti che sono comunque… siamo partiti da tool come OCU dove tutta questa parte di complessità è astratta, per cui riuscire a rappresentarli in modo schematico e diciamo quello che ti permette di costruire i moduli mentali poi riutilizzi in modo quasi automatico.Vedo che comunque il tempo sta volando però c'è un argomento che è un'altra spina sul fianco quando si usa Kubernetes perché lo sappiamo, l'hai detto più di una volta oggi, i container di per sé sono dentro Kubernetes per come sono pensati i pod, il concetto di stateful è sempre presente.Cosa succede se io devo, anche perché possono morire da un momento all'altro.Cosa succede se io devo invece deployare qualcosa che fa grande uso dello stato? Mi immagino un'istanza di Postgre? In questo caso ovviamente abbiamo un altro tipo di controller a disposizione che è fatto ad hoc per per questo che è lo Statefulset ci sono in realtà anche altri tipi di componenti comunque diciamo di base tramite delle soluzioni di storage abbiamo ovviamente la possibilità di persistere queste informazioni quindi non dobbiamo pensare che con queste tecnologie i nostri dati vengano persi per sempre e che non c'è modo di persisterle tramite diverse soluzioni di storage abbiamo la possibilità di installare soluzioni come un database, che richiedono persistenza, e di salvare questi dati.Lo storage è un'altra spina nel fianco, perché Kubernetes non fornisce una soluzione di default per lo storage, ma ci mette a disposizione tutta una serie di provider e di soluzioni che sono pronte a uso.poi dipende, stanno in base all'infrastruttura, scegliere quella che più adatta.In questo caso non si è potuto fare uso di una sovrastruttura, perché chiaramente a seconda del tipo di macchina che utilizziamo, il tipo di file system piuttosto che i driver e le interfacce cambiano notevolmente, quindi non è possibile fornire una soluzione unica che funzioni per tutto.Kubernetes mette a disposizione una serie di interfacce che funzionano bene con uno più provider e a seconda del tipo di infrastruttura che abbiamo chiaramente possiamo affidarci a queste.Per fare un esempio se noi utilizzassimo un servizio come quello di AWS per deployare il nostro cluster, questo mette a disposizione diversi prodotti, diversi servizi di storage a blocchi o a file che sono perfettamente compatibili con Kubernetes.Quindi una volta specificato il modo in cui questi due si devono parlare, attraverso una sorta di comunicatore dello spazio richiesto da parte dell'applicazione X, Kubernetes in grado di allocare questo spazio per gestire lo stato delle nostre applicazioni.Che poi è una della, secondo me, la bellezza di Kubernetes, cioè il fatto che alla fine è uno strumento quasi agnostico di quella che è l'infrastruttura che sta sotto.Io l'ho visto, che ne so, con il Digital Ocean della situazione, ma anche con l'Azure situazione che se tu vai a creare un load balancer, tu stai andando a creare sotto il cofano un load balancer nell'infrastruttura, nel caso di Digital Ocean, di Digital Ocean.Quindi trovi l'entità load balancer direttamente dentro il pannello Digital Ocean anche se tu l'avevi creato all'interno del tuo cluster col tuo yammerlino super bellino.Secondo me questo è un altro elemento veramente del successo di Kubernetes.Altra cosa, e con questo poi ci avviciniamo alla chiusura.Istruire il mio control plane per fare delle cose lo si può fare in modi diversi, uno di questi attraverso i famosi file YAML che sono croce e delizia, penso che è stato credo uno dei modi per portare alla visibilità di tutti il formato YAML ma dopo un po' sei anche iniziato a odiarlo, no? E sono apparsi tutta una serie di tool che avevano come compito quello di semplificare il rilascio, più che il deploy, la definizione di quello che doveva a succedere dentro i cluster.Uno di questi è Elm, cosa mi puoi dire di Elm? Raccontare Elm in poco tempo è difficile, quello che posso dire è che quando si ha l'esigenza di deployare diverse risorse all'interno di un contesto come Kubernetes abbiamo bisogno di una sorta di strumento che faccia un po' da cartella di lavoro, che sia pronta ad eseguire tutto quello che ci serve per mettere in esecuzione la nostra applicazione.Fino adesso abbiamo parlato di pods, abbiamo parlato di deployments, abbiamo anche citato service, abbiamo parlato dello storage.Ognuno di questi ha un suo oggetto, una sua tipologica all'interno del contesto Kubernetes.Deployarli manualmente in maniera singola è chiaramente possibile, però avere una sorta di classe o di pacchetto che in qualche modo raggruppi tutte queste entità costituendo la soluzione al suo complesso è sicuramente utile.Elm in questo senso ha sposato un po' il concetto di pacchettizzazione attraverso il chart che rappresenta il modo in cui noi possiamo descrivere tutte le risorse che ci servono per deployare la nostra ma anche parametrizzarle.Quindi, sapendo che la nostra applicazione per esempio è composta da un deployment, un service che ne permette la comunicazione un persistent volume che ne permette la persistenza se vogliamo poter ripetere la nostra installazione magari in ambienti diversi, attraverso un chart possiamo specificare valori che cambiano a seconda del contesto e questo è fatto anche tramite tutta una serie di file molto ordinati con cui prendere confidenza sicuramente, come dicevi, non è facile perché YAML, come linguaggio di markup, è estremamente semplice ma è estremamente stringente, quindi ha fondamentalmente due strutture dati ma con le due strutture dati ti permettono di descrivere tutto.Sbagliarne una finta si significa perdere probabilmente un sacco di tempo a capire dove è l'errore.Però attraverso uno strumento così potente come Elm ad oggi sono installabili tantissime soluzioni di uso comune su cluster Kubernetes senza dover riscrivere o reinventare la ruota.se pensi anche a tutte le soluzioni database, gestione delle code, soluzioni che permettono per esempio di fare sia ICD, esiste un helm chart per tutto che dobbiamo solo deployare con un comando senza doverci preoccupare di scrivere ogni singolo pezzo ma qualcuno l'ha già fatto per noi e anche questo è estremamente potente LM: Sì ci sono poi degli helm chart la cui complessità è spaventosa per il numero di configurazioni e cose che si possono fare.Mi verrebbe una curiosità, magari se non capite cosa sto per chiedere schippate questo pezzettino, però ho una curiosità da chiederti Serena.Elma nel passaggio da 2 a 3 ha ammazzato Tiller e Tiller faceva un sacco di cose utili, loro hanno avuto i loro buoni motivi, Tiller sapeva troppo.Ti manca? Un po', è stato un bel passaggio e sicuramente non molto condiviso dalla community, o meglio si è creato un po' una sorta di faccionamento tra chi ha approvato questa scelta e chi no.Io personalmente credo che, come hai detto anche tu, se hanno fatto questa scelta e c'è un team di persone che ci lavorano, che sicuramente hanno competenze molto più alte delle mie, l'hanno fatta con una ragione d'essere.Per cui mi aspetto che queste motivazioni mi convincano sempre di più ad adottare la versione che abbiamo oggi senza dover rimpiangere quella che c'era ieri.La voglio pensare in questo modo.Certo, ormai abbiamo quasi toccato l'ora, quindi ultima domanda.Il mondo Kubernetes non è solo le sue entità base, ma è tutto un mondo di tool e di sistemi che poi rendono Kubernetes utilizzabile davvero in produzione.Mi viene in mente Unistio, mi viene in mente Unargo.Qual è il percorso che tu suggerisci per, una volta studiate le basi, che di risorse ce n'è tante, il tuo libro è uno di questi, ma come ci si può orientare nel gozzillardo di offerta che poi c'è attorno di elementi che danno i superpoteri al nostro cluster.Tu dici come faccio ad orientarmi tra le mille componenti che Kubernetes mi mette a disposizione, come faccio a capire da dove partire ma anche qual è lo step successivo? L'idea è, una volta che io ho capito le componenti base di Kubernetes, che conosco Kubernetes, poi come mi oriento nell'ecosistema che invece è enorme? Guarda, ti posso dire che probabilmente l'approccio migliore in questo senso è intanto partire da chi sviluppa, quindi da persona che sviluppa e capire quali sono le componenti così come l'abbiamo anche un po' raccontate prima.Una volta che riesco anche a far funzionare il mio piccolo progetto, quantomeno a incastonarlo nelle diverse risorse che Bernardo ci ha messo a disposizione, passare al lato architetturale, quindi cambiare un attimo il cappello e cercare di immaginarvi un'ottica, come dicevamo anche all'inizio, un po' più grande, come questo deve funzionare.Non a caso anche a livello di manuale io l'ho pensato proprio con questo approccio, perché tutto ciò che scrivo solitamente lo scrivo pensando che chi sta dall'altra parte non sa niente.Non sa niente in maniera voluta, mettere delle basi che siano solide è fondamentale per poter poi approcciarsi a concetti molto più ostici.Ho scritto allo stesso modo il libro sul docker perché ho pensato anche alla mia universitaria che diceva io da dove devo partire per poter capire queste tecnologie e allo stesso modo ho detto ok immaginiamo che una persona decide di approcciarsi a kubernetes perché è curiosa professionalmente, perché lo deve fare per lavoro per forza, perché questa tecnologia verrà adottata, fa e allo stesso modo il percorso è stato immaginato in questo modo.Si parte da Kubernetes per lo sviluppo, quindi dal mio prodotto locale cerco di capire in che contesto metterlo all'interno di un cluster e poi cerco di capire anche quella che è l'architettura in un contesto più grande, in un contesto più enterprise, attraverso tutta una serie di domande che probabilmente fino a a quel momento non mi ero posto.Quindi l'approccio è cercare di usare quello che io chiamo prodotto minimo possibile, la mia applicazione su Kubernetes funziona, ok adesso penso in grande, che cosa devo fare dopo? E quindi penso in un contesto di più alto livello, dove ovviamente dell'architettura ha un grosso enorme impatto.Chiarissimo.Serena, io ti ringrazio tantissimo di aver dedicato questa oretta a noi.Prima di lasciarti però c'è il momento tipico e topico del nostro podcast, il momento nel quale sia i nostri guest che i nostri host condividono con noi un libro, un talk, un video, qualunque cosa abbia catturato la loro attenzione e pensino sia utile condividere con la nostra community.Quindi la mia domanda a diritto è hai qualcosa da condividere con noi? Ricordi come il paese dei balocchi.Ah il paese dei balocchi.Ho qualcosa da condividere, allora io leggo tantissimo e seguo molto anche al di là dei dei podcast come Gitbar, anche molto le conferenze TEDx, perché le trovo di ispirazione su tanti fronti, su tanti punti di vista.In realtà non solo dal punto di vista tecnologico, ma anche dal punto di vista proprio umano mi rendo conto che sono tutte cose che fanno crescere moltissimo che ti permettono anche di analizzare degli aspetti che magari non avevi pensato prima.In particolare ce n'è una che mi viene in mente, è un TedEx di qualche tempo fa, se non mi ricordo male, parliamo di qualche anno che vi ero anche salvata, che parlava di come gestire lo stress al lavoro, come gestire il burnout.Il titolo adesso non me lo ricordo, comunque era una CEO di un'azienda, di un social management, che parlava dell'effetto post pandemia e di come questo abbia impattato moltissimo la vita privata, ma anche professionale delle persone, che spesso si sono trovate a fondere un po' troppo i due mondi, magari non avendo lo spazio necessario a casa per poter lavorare in periodi in cui eravamo tutti chiusi in pandemia e quindi confondendo orari, ma anche un po' ruoli e separazione anche mentale di ciò che aveva fatto.e lei apriva questo podcast, scusami, questo, questa intervento dicendo "tu non sei il tuo lavoro" e questa cosa un po' mi ha spiazzato perché ho detto "wow, io amo il mio lavoro, faccio una cosa che mi piace tantissimo" però effettivamente è vero, io prima di essere un enterprise architect e i vari job title sono una persona e questa volta ce lo dimentichiamo È stato un concetto molto semplice ma anche molto forte che mi ha fatto riflettere tantissimo.Sì, guarda, non sai quanto ti capisco perché alla fine quando davvero ami il tuo lavoro fai all in su quello e arrivi a un certo punto dove non riesci a distinguere se sei una persona o sei… esci fuori con gli amici, amici che magari trattano di altre tematiche e non riesci più a parlare con loro dei topic più disparati perché ti viene da spiegare il Qbernet, se no… Allora vai allo spiegone del Qbernet, a me è capitato il periodo che studiavo programmazione funzionale, vai allo spiegone funzionale al mio amico che studiava lettere che dopo 15 minuti mi ha detto "va bene Mauro bevi un'altra birra e torna a casa".È sufficiente.Io ho un balocco, ve l'ho accennato prima, è il libro di Serena "Kubernetes guida per gestire e orchestrare i container, lo trovate nelle note dell'episodio.La cosa interessante e soprattutto può tornare utile perché è completamente in italiano.Avere risorse di quel livello in italiano non è semplice, per chi avesse dei problemi con la lingua è utilissimissimo averlo quindi se vi fa piacere nel prossimo episodio trovate il link.Serena io ti ringrazio infinitamente per esserci venuta a trovare grazie grazie davvero grazie a te grazie a te per la chiascherata Come dico sempre e non è detto solo per dire, da oggi Gitbar è anche un po' casa tua.Vedi Gitbar come il circolo del dopolavoro ferroviario postale degli anni '70, dove una volta che entri e ti fa piacere condividere qualcosa, ritorni al circolo perché c'è sempre una birra, una coca, quello che ti pare fresco per te.Nel nostro caso è virtuale, però è un buono anche casa tua da oggi.Assolutamente ti ringrazio, mi son sentita a casa.Ringraziamo nuovamente Serena, vi ricordo che questo episodio prenderà forma non solo in una puntata di Gitbar ma anche in una card collezionabile che potrete trovare durante appunto Code Motion di quest'anno e detto questo io ringraziano nuovamente Serena vi do appuntamento alla prossima settimana.Ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
