Bene e benvenuti su GitBar, anche questa sera, che per noi è sera, una nuova puntata.In questa puntata sarò purtroppo da solo, perché i miei validissimi colleghi, diciamo, che hanno un po' fatto compagnia a Mauro nello sgabuzzino dove sta leggendo i libri dell'apogeo, e quindi, insomma, non ci sono questa sera.ma questa sera ho un bellissimo ospite.Questa era una puntata che stavo aspettando da tantissimo tempo.Diciamo che questa per voi è una puntata di un podcast per me tutto quello che avrei voluto chiedere, ma spesso mi rispondono male.Quindi, insomma, vediamo un po' se riusciamo a non farci rispondere male questa sera.Quindi, signori e signore, benvenuti a Gianluca.Ciao Gianluca, chi sei e che cosa fai? Ciao, piacere, sono contento di essere qui.Io sono un principal engineer a Cisco Systems.Sono stato in California per quasi 20 anni, dal 2004 fino al marzo dell'anno scorso, 2023.e poi sono ritornato praticamente in Italia.Con la nostalgia dell'Italia sono ritornato in Italia.Continuo a lavorare per Cisco.La business unit in cui lavoro è AppDynamics, quindi modelling full stack observability.Però lavoro da diversi anni su Kubernetes.Alcuni mantengo, alcuni open source project che ho iniziato praticamente uno o due anni fa e un altro sei mesi fa.Il primo è un open source project per distribuire applicazioni su un gruppo di cluster, un management cluster.E il secondo è chiamato KDesk Cleaner, che è un open source project per...sempre Kubernetes based, è un controller che praticamente trova delle unused resources o risorse che non sono più healthy e ne fa praticamente il detect.Questo sostanzialmente è il mio background.Ok, no no, allora io ho tantissime domande.se non avete ancora capito dal titolo della puntata o l'avete visto, andremo a parlare di che cos'è un operator, un controller, per coprire, per me non so nemmeno come chiamarlo, insomma, quindi ammetto la mia ignoranza.Ma prima di tutto ora c'ho una domanda, insomma, così che mi sorge veramente spontanea.Come si diventa principal a Cisco in California? questa è proprio...come si fa? No, quando sono andato lì nel 2004, mi ricordo man mano che la data della partenza si avvicinava, la paura cresceva, sarò in grado di fare quello che devo fare oppure no.Però la preparazione che c'è in Italia è veramente una gran bella preparazione.Quando si esce dall'Università degli Anni si è veramente preparati per bene.Io ho fatto l'ingegneria al Poltecnico a Torino, ho fatto sia il corso di laurea master e poi praticamente ho fatto il dottorato di ricerca lì e col dottorato praticamente sono finito poi in Cisco.Come si diventa? La preparazione ce l'abbiamo, poi alla fine veramente costanza e applicazione.La cosa bella degli Stati Uniti è che le opportunità ti vengono date e se le sfrutti per bene ottieni praticamente ciò che meriti.Quindi quella è la cosa bella, veramente, gli Stati Uniti le hanno colpito veramente un sacco.Non che l'Italia comunque, sono tornato in Italia, quindi non è una critica all'Italia, l'Italia mi mancava, sono tornato in Italia.No, no, certo.Ok, ok.No, è interessante comunque, cioè, è quella cosa che dici "minchia", in senso "come si fa?" Ok.Allora, ti faccio subito così una domanda secca.Che cos'è un operator? Si chiama operator, si chiama controller, che cos'è? Perché, ad esempio, ora, per chi ci sta sentendo.In realtà mi va sempre stanno dire sentendo, perché stiamo effettivamente facendo un video, però per chi ci sta sentendo, insomma.Se avete mai utilizzato su QWerner, insomma uno per Etolo, come può essere? Ad esempio, io personalmente ho utilizzato, ne ho utilizzati diversi per Kafka, quindi per gestire tutto un cluster Kafka, ho usato lo Streamsy Operator, in università diverse anche sia per Postgres sia per MySQL, insomma.E li ho sempre visti, diciamo, nel mio essere utente, ma non sviluppatore di questo tool, come uno strumento di coordinazione di più risorse, insomma.Diciamo sì, però in realtà so che c'è molto più.Quindi si chiama o peretro, si chiama controllo, che cosa fa e soprattutto perché nasce? Insomma, è qualche cosa che è nata con Kubernetes stesso o è stata, diciamo, un'estensione fatta perché c'era la necessità? Insomma, mi sto chiedendo per capire anche un po' il senso.Per spiegare, questa è una controlla, perché praticamente l'idea si parte dal...io questo dall'esprimere le intenzioni, questo è quello che vorrei.Tu hai fatto l'esempio praticamente lo Stringy Operator, se non mi sbaglio praticamente, mi hanno usato per gestire praticamente le credenziali e i permessi su Kafka.e quindi l'idea è di dire praticamente questo è quello che vorrei, questo è il mio intento, vorrei praticamente il sistema che sia praticamente in questo stato qua.E quello che fa praticamente l'operator, il controller, è che prende praticamente quell'intento e compie una serie di operazioni per portare il sistema, praticamente fare in modo che il sistema sia nello stato in cui lo user vorrebbe che fosse.E poi magari praticamente quello che fa anche il...ma non finisce lì, perché quello che vorrebbe, quello che succede è che poi magari ci possono essere praticamente dei cambiamenti.Faccio un esempio praticamente con un altro controller, il deployment controller o il replica set controller.Io voglio praticamente, dico che io vorrei avere praticamente un certo numero di pod che siano praticamente attivi, quindi io dico vorrei avere praticamente una replica 3, che significa che vorrei avere tre pods per questo deployment, che siano sempre praticamente up and running.Può succedere che uno di questi pod sia praticamente su un nodo che va giù, quindi il ruolo del controller non è solo creare all'inizio questi tre nodi, questi tre pod e tirarli su, ma continuare a vedere che il sistema non devi dallo stato in cui lo user lo vorrebbe.Quindi nell'esempio del pod, è su un nodo che il nodo va giù, il replica set controller si accorge praticamente che il pod è andato giù, che adesso ci sono soltanto due pod attivi sui tre richiesti e ne tira su praticamente un altro.Quindi continua a fare questa reconciliation in modo tale che praticamente qualunque cosa succeda nel sistema, prova sempre a muovere il sistema verso lo stato in cui lo user vorrebbe praticamente che il sistema fosse.e quindi quella è la bellezza.Non è solo praticamente gestire un gruppo di risorse che aiuta praticamente lo user, perché non devo creare io n risorse, le gestisce, esprimo qual è il mio intento e poi praticamente il controller è capace di fare in modo che il sistema raggiunga quell'intento e sia praticamente nello stato che io voglio che sia.è nato con Kubernetes.In realtà praticamente questo policy based idea c'era anche prima, con Kubernetes è diventato proprio, io ti do la mia policy che è il mio intento, che è continuare a fare praticamente questa reconciliation per portare il sistema in quello stato.Prima di Kubernetes avevo lavorato in Cisco su SEI che è un controller per un set di leafs e nodi.Anche lì praticamente era policy based e anche lì c'era questa idea di cosa succede praticamente se il nodo va giù e bisogna ritirarlo su, viene rimandato tutte le policy giù e praticamente bisogna fare in modo che il sistema ritorni nello stato in cui era.Con Kubernetes praticamente è diventato veramente il modo di fare le cose, è veramente un modo molto pulito e molto ben fatto, sia per lo user che deve esprimere il suo intento in un singolo posto, con una singola configurazione, creando praticamente una risorsa che il controller va a guardare e a riconigliare, e sia anche per il developer, perché questa idea praticamente di scrivere codici alla fine e aiuta anche a scrivere del codice che sia clean, pulito e facile anche da testare e verificare.Ok, quindi alla fine tu prima mi stai facendo l'esempio del deployment controller, del repriaset controller, che sono comunque cose che trovi in una qualsiasi distribuzione di Kubernetes.Quindi possiamo dire che Kubernetes stesso ha diversi layer, insomma, di queste cose, cioè di controller che sono già built-in, che quindi magari vanno ad operare sulla risorsa minima.Ad esempio, se ho il deployment controller, il Red Hat 7 controller, andrà ad operare sul pod che andrà ad operare, diciamo, sul container fisico insomma che c'è sul nodo.E quindi, diciamo, tutto ciò nasce, ora, avendo detto anche il tuo toro, alla fine tutto nasce dal concetto, ad esempio, di risorsa.Ci sono quelle lì di Kubernetes che sono built in, possiamo definirle, come può essere il deployment, il pod oppure l'ingress.E invece abbiamo delle risorse che sono custom, che quindi possiamo creare noi.Quindi è quello, diciamo, da cui parte il controllo.Quindi nel senso, si parte dalla risorsa e poi che cosa succede? Cioè, questa risorsa ad un certo punto diventa uno stato, questo stato dove viene scritto, insomma.come c'è un database? Sì, sostanzialmente si parte, direi che si parte dal...quando si scrive praticamente un controller, si parte dal...questa è la mia esperienza personale.Si parte da un problema.Il mio approccio di solito è praticamente rivedere se quel problema è già stato risolto da qualcun altro perché veramente l'ecosystem attorno a Kubernetes è fantastico.Ci sono tante di quelle soluzioni open source che la gente ha deployed che sono veramente fantastiche, sono messe lì open source per tutti.Quindi il mio approccio è...parto per vedere se c'è qualche soluzione che ha già risolto il problema che ho.Se invece praticamente non trovo niente che sia...che risolva praticamente il problema che ho, l'idea è quando si va a scrivere un controller si parte dal definire una risorsa.La bellezza di Kubernetes, come dicevi tu, è che ci sono praticamente queste risorse che sono già praticamente definite su il deployment, replica set, config map, secret, un sacco praticamente per system volume, un sacco di risorse che vengono praticamente con ogni versione, con ogni Kubernetes cluster sono disponibili.Però Kubernetes è fatto in modo per essere estensibile.Quindi chiunque può definire una nuova risorsa, definire praticamente un nuovo custom resource definition, che è semplicemente una...introdurre un nuovo API in Kubernetes, in cui dice io ho questa nuova risorsa e di solito praticamente quello che succede è che ogni risorsa ha uno spec e uno status.Lo spec è quello che dovrebbe essere, quello che viene configurato dallo user e quindi è dove vorrei che praticamente il sistema fosse.E lo spec è quello praticamente che il controller va a guardare.Quindi io definisco una risorsa, c'è uno spec e uno status, lo user setta lo spec della risorsa, il controller continua praticamente a guardare lo spec, reagisce praticamente ai cambiamenti nello spec e fa praticamente il suo lavoro ed aggiorna praticamente lo status.Prendo un esempio praticamente su un open source che ho fatto, praticamente, Projects Veltos.Quello che volevo fare era essere in un management cluster in avere praticamente una serie di altri cluster in cui volevo facilmente dire queste sono le risorse che voglio praticamente fare il deployment.Non lo so, per esempio voglio metterci un Caverno come admission controller, voglio metterci Prometheus e Grafana, voglio metterci un CNI, CNI Mocalico, e quindi praticamente quello che ho definito una risorsa su cui lo user può venire e dire "questo sono i set di Elmcharts o Yamal JSON che voglio che siano deployed" e c'è un altro field che è praticamente un cluster selector che è semplicemente un plain Kubernetes selector che seleziona un set di cluster in base praticamente alla label che questi cluster hanno e quindi quello che lo user può facilmente dire "seleziona questo set di cluster e queste sono le risorse che io voglio che siano deployed su tutti questi cluster qua.Quella è un'informazione che viene messa nello spec e viene configurata dallo user.Quello che fa il controlle che io ho deployed in questo caso qui, o mantengo in questo caso qui, è andare a vedere questa configurazione allo spec, andare a vedere tutti praticamente i cluster che sono raggiungibili da questo management cluster, andare a vedere quali sono le labels su questi cluster, ogni volta che c'è un nuovo cluster, la label su un cluster viene modificata.Il controller reagisce e va a vedere se questo cluster sta matchando il cluster selector.Se sta matchando il cluster selector, fa il deployment di tutte le risorse che lo user vuole che siano deployed su questo cluster.Dopodiché va ad aggiornare lo status dicendo, "guarda, questo cluster adesso è un match e tutte le risorse sono state deployed".e se qualcosa praticamente cambia, quindi un nuovo cluster viene aggiunto o la label viene cambiata e quindi un cluster prima non era un match per questo cluster select, adesso lo è, il controller reagisce praticamente a questi eventi.Intendenzialmente ci sono sempre queste informazioni che sono metadata, che contiene sostanzialmente il nome della risorsa e il namespace, anche se il namespace non è praticamente su tutte le risorse, perché abbiamo due tipi di risorse in Kubernetes.Namespace resources che invece sono cluster wide, quindi non hanno praticamente un namespace, sono su tutti i cluster.Come sempre il cluster role, quello è un esempio di risorsa che non è limitato al namespace, ma è praticamente su tutti i...per cluster.E poi c'è questa parte spec, che è la parte che lo user va a configurare, poi c'è la parte status che tendenzialmente è la parte che il controller quindi guarda, watch quella risorsa e regisce praticamente a modifiche di quella risorsa lì ma ad aggiornare per riportare lo status e per far sapere praticamente allo user se il sistema è nello status in cui tu volevi oppure praticamente se c'è un errore, non riesco a raggiungere questo cluster, so che c'è questo cluster, è praticamente un match, dovrei fare il deployment di queste risorse qui ma non riesco a farlo perché non riesco praticamente a raggiungerlo.magari praticamente qualunque problema possa esserci, viene riportato praticamente il problema.E continua a fare praticamente le consiglie anche quando fa il...Ok, quindi diciamo che c'è questo loop infinito che guarda una serie di risorse che immagino possono essere sia custom sia non custom.Cioè nel senso, se io voglio guardare una risorsa di Kubernetes che c'è già, nel senso, voglio guardare i pod, perché voglio inviare questo messaggio su Slack, quando il pod sale, lo posso comunque fare, insomma.Ok, che immagino così, un po' detto sì, non so se sto dicendo una cazzata, è anche un po' come funziona il concetto di ingress controller, appunto.Quindi nel senso, c'ho la risorsa ingress, che è una risorsa che, diciamo, è built-in dentro Kubernetes.Io, ad esempio, in Genix, ingress controller, se viene creata una risorsa che ha quella label che dice "ok, questa risorsa è tua", allora faccio il virtual host, eccetera, eccetera.Quindi, diciamo, la magia che c'è dietro è magia nel senso che si guardano questo tipo di risorse e si fa qualcosa.Ecco, questa cosa che mi hai appena raccontato mi ha fatto venire in mente subito una domanda che è spesso qualche cosa che, almeno visto così, non è proprio semplicissima.Quando tu dici l'utente fa un'operazione, quindi nel senso ho installato il mio controller che ha questa custom resource e io che sono, diciamo, utente del cluster, amministratore del cluster, posso fare, apply di questa risorsa in un modo come un altro e quindi questa cosa accade.Come funziona, diciamo, dal punto di vista del cluster, la visibilità di queste risorse? Cioè, se io creo una custom resource, la possono leggere tutti, posso leggere a qualcuno, c'è un sistema di...per...messi giusto per farti proprio il paragone banale.Se ho una unit di Systemd, posso dire che quella unit deve girare con quell'utente che ha alcuni privilegi e può fare alcune cose.Con un controller, come funziona? Tutti i controller girano come se fosse root, hanno un loro ruolo? Come funziona? No, quello è indipendente dal controller e dalle risorse.In Kubernetes ci sono praticamente le RBAC per definire chi può accedere a cosa.Quindi se lasciamo da parte praticamente il cluster admin che ha praticamente permesso, permessi per fare qualunque cosa, tendenzialmente quello che succede è che un controller c'è un service account, quindi un controller alla fine è un pod che gira praticamente nel Kubernetes cluster.Ovviamente viene installato il deployment, non il pod, perché non vogliamo praticamente, vogliamo avere un sistema che se il pod va giù, un altro pod viene su, quindi il nostro controller si separa per l'unico.Però alla fine il controller è uno o più pod che girano praticamente nel cluster.E questi pod sono associati ad un service account.E in Kubernetes il modo in cui viene definito chi può accedere a cose è tramite questi role o cluster role, role binding, cluster role binding.Che essenzialmente un role o cluster...role e cluster role sono esattamente la stessa cosa, solo che praticamente il role è limitato a namespace, mentre cluster role praticamente è definito su tutto il cluster.E quindi nel role cluster role viene detto quali sono praticamente...viene detto cosa può essere fatto su quali risorse.Per esempio io posso andare a dire che sui deployments posso creare un role che dice il deployment può essere fatto un get watch and list, che significa che quel draw list dicendo che questi deployment qui, su questi deployment qui posso andare a vedere quali sono i deployment che esistono in questa namespace, nel namespace del draw e posso fare praticamente una lista o vedere praticamente tutti i deployment in quel namespace.Però ancora non c'è associato nessuno user.Qui semplicemente vi hanno detto quali sono i permessi sulle vari Kubernetes API, perché alla fine praticamente queste risorse sono semplicemente delle API.Il role binding, cluster role binding, invece quello che fa è prendere un role in cui praticamente abbiamo detto, ad esempio, posso fare un get list watch sui deployment, prende uno user o un service account e dice questo service account è associato a questo ruolo, a questo role.Perché praticamente associiamo un service account a quel role? Qualunque operazione permessa da quel role, sarà permessa a quel service account.Quindi quando viene creato un controller, tendenzialmente in Cooperante si va con il least privilege approach.Quindi non dai permessi extra a quelli che ti servono.Se ti serve andare a vedere, se tu sei un controller che vuoi andare semplicemente a guardare lo stato, vuoi vedere quali sono tutte le risorse di un certo tipo.Vuoi vedere praticamente qual è lo status.Lo stato, lo spec, sostanzialmente quello che c'hai, c'hai i permessi per andare a fare get, list, watch dello spec.E poi c'avrai i permessi praticamente per andare a scrivere lo status, perché sostanzialmente quello che ci si aspetta è che il controller, perché sta praticamente riconsigliando queste risorse, vada ad aggiornare lo status.Quindi sostanzialmente i controller ci hanno i...diversi controller ci avranno diversi permessi.e non tutti i controller vanno praticamente accesso a tutte le risorse.Quello è perché, di nuovo, è il modo in cui ti garantisci sostanzialmente che provi a minimizzare i danni, perché se dai delle risorse, dei permessi extra, poi magari ci può essere un bug che ti crea dei problemi perché va a toccare delle risorse che non dovrebbe toccare.Invece praticamente usando questo sistema di airbag che limiti chi può vedere cose, chi può fare cose.Ma non vale solo per i controller, vale in generale anche per gli user.No, no, no, scusami, continua.No, no, no, voglio dire semplicemente che fondenzialmente quando si va a fare l'onboarding di un nuovo user, tendenzialmente, magari se sei soprattutto in un...se sei in un sistema, se il tuo cluster fa un boarding di multi-tenant, tendenzialmente proprio ad evitare che un tenant possa vedere le risorse praticamente dell'altro tenant.Quindi praticamente dai degli R-back, magari sono...ogni tenant ha uno o più namespaces e può vedere solo le risorse in modo tale che due talent diversi non, o non clash con each other.Allora, ti faccio una domanda che sarà sicuramente banale, quindi mi scusi, ma probabilmente non sono l'unico che se lo sta chiedendo tra quelli che ci stanno ascoltando.Che cosa significa che tu dai a un controller un service account? Cioè, come funziona proprio dal dal punto di vista pratico.Se io ho un pod, ho un deployment, che ha quel service account, cosa significa? Che banalmente ciò che gira all'interno di quel pod può chiamare quell'endpoint e Kubernetes capisce a quali risorsi ha? Cioè, come funziona proprio dal punto di vista pratico? So che questa cosa è un po' sulla, dal controllo in generale, però sono effettivamente curioso.Sì, no, è un'ottima domanda perché alla fine praticamente qualunque operazione viene fatta la prima cosa, quello che succede praticamente quando viene chiamata una Kubernetes API si va a vedere, la prima cosa si va a vedere chi è che sta facendo quella chiamata quindi viene fatta praticamente l'authentication.Passata l'authentication c'è la fase in cui si va a fare, si va a vedere se quella è qualcosa che ha autorizzato.Quindi nel caso del...si va a vedere, ok, questo service account sta facendo praticamente questa...ho verificato chi sta facendo questa richiesta di fare una list dei deployment in questo namespace, per fare un esempio.È questo service account.e adesso si va a vedere se quel service account ha il permesso di fare la lista dei deployment su quel namespace.E soltanto se quella richiesta è una richiesta che è autorizzata, poi praticamente va...va praticamente avanti.Altrimenti viene bloccata l'app.Ok, quindi diciamo alla fine il service account al binario controller gli arriva come una variabile d'ambiente, come un volume, è implicito nel fatto che c'è del traffico che sta uscendo da quella cosa lì.Non si mette nel deployment, cioè c'è chi è il service account, altrimenti praticamente diventa il default service account nel namespace, viene messo praticamente chi è quando posti un deployment, c'hai un service account name che ti dice praticamente qual è il service account del tuo deployment.Quando il pod viene creato, vengono creati praticamente in automatico le informazioni necessarie praticamente finché ogni API, ogni API request che il deployment, che il pod va a fare, venga praticamente fatta come questo user.Ok, ok.Quindi...Quindi diciamo, è come se ogni richiesta che parte poi da quello specifico, poi abbia questo token, insomma, non lo so nello specifico che cos'è, però nel senso abbia effettivamente questo token che lo identifica.Ecco, per PIA sta dicendo che va a scrivere nello stato, quindi diciamo che questa custom e ha diversi campi, c'è il campo dei metadati, c'è il campo della spec, e c'è il campo dello stato, insomma.Quindi, diciamo, dal punto di vista dello sviluppatore, è come andare a scrivere, come aggiungere questi field in una struct, insomma, che poi vengono persistiti, dove è persistito tutto il resto, oppure c'è qualche cosa, diciamo, di più particolare? Vorrei solo fare una...aggiungere solo una nota qui, perché tu prima hai fatto praticamente l'esempio del se io sto scrivendo un controller devo per forza definire una nuova custom resource definition, introdurre praticamente una nuova custom resource definition, e la risposta, come hai detto tu, è praticamente no.Senzalmente io potrei anche scrivere un controller per mandarmi una notification quando un pod è in un crash in un back system, giusto? Quindi in quel caso lì sostanzialmente il controller non va a scrivere lo status del port, giusto? Perché il controller sta semplicemente guardando quello che succede e l'output di quel tipo di controller è mandare una Slack notification, una WebEx notification, un'email, qualunque cosa praticamente come risposta.Quindi la risposta del controller in quel caso è mandare, non è aggiornare praticamente lo status, non è controllare la life cycle del pod, la vita del pod, ma è semplicemente guardare quello che succede e mandarlo in notifica.Fatto questa precisione qua.Quando se invece io introduco una custom resource definition e scrivo un controller per quella custom resource definition, tendenzialmente quello che succede è che la spec è praticamente una struttura in cui ci sono dei field che lo user può configurare e in cui essenzialmente lo user dice questo è quello che mi aspetto, lo stato in cui vorrei il mio sistema.Il controller quello che fa, guarda questo spec, continua a fare tutte le operazioni che deve fare per fare in modo che il sistema raggiunga quello expected state e ogni volta che fa delle operazioni continua ad aggiornare lo status.Se andiamo a vedere praticamente il pod, ad esempio lo status del pod, sono diverse informazioni, viene messo praticamente quando è stato scheduled, quando varrà, se c'è praticamente qualunque problema, queste informazioni vengono messe nello status.Nell'esempio che facevo prima io, per la custom resource definition che ho introdotto io, il controller quando si accorge che deve fare una certa operazione, per fare quell'operazione, che può succedere o fallire, in ogni caso praticamente va ad aggiornare lo status, perché è un modo per dire allo user, se lo user fa un keep cut o get quelle risorse per guardare lo status, è un modo per vedere cosa sta succedendo.Quindi va ad aggiornare lo status sia in un caso che nell'altro.Poi ovviamente continua praticamente, se succeeded finisce lì fino a quando non c'è un altro cambiamento nel sistema che trigger di nuovo questa reconciliation.Se invece fail, quello che succede è che continua a provare, riprovare, riprovare fino a quando praticamente va in quello stato lì.Poi la frequenza con cui riprova, quella è praticamente qualcosa di configurabile, dipende praticamente da chi scrive il controller e da come scrive il controller.Quindi sono questi back off per decidere quando riprovare.Quando dici che il controllere si accorge di qualche cosa, è un sistema che è pull o è push? Cioè è il controllere che gira e controlla con una certa frequenza o c'è un modo per cui il controllere venga aggiornato da un'entità mistica che qualcosa è cambiato? No, tendenzialmente il controller fa partire dei watcher, quindi gli dice praticamente "io sono interessato a sapere quando questa risorsa qui viene modificata" e quindi quando praticamente quella risorsa viene modificata il controller riceve praticamente una notifica.Adesso io uso tanto Cube Builder e quindi il modo in cui è fatto praticamente in Cube Builder perché quando si crea un controller si dice io sto creando praticamente un controller per questa risorsa ma sono anche interessato praticamente a queste risorse A, B, C, D.Nel senso quando queste risorse praticamente cambiano a secondo di come cambiano io voglio praticamente andare a riconciliare a far ripartire praticamente il mio reconciliation loop.Scusa se continuo a prendere praticamente i miei esempi è quello che sono praticamente...è...in quel caso lì praticamente lo user dice "voglio che questo set di Elm charts venga deployed su tutti i cluster che hanno questa label".Quindi la prima cosa che ovviamente a cui sono interessato è "c'è un nuovo cluster" o "la label di qualche cluster è cambiata".Quindi io non so solo riconigliando il custom resource, non sto solo creando un controller per riconigliare la custom resource definition che io ho introdotto, ma vado anche a dire voglio praticamente guardare queste altre risorse che sono state praticamente introdotte da altri open source project, nel mio caso da cluster API, per esempio.Quindi vado a guardare questa risorsa che io non è mia, è stata introdotta da cluster API, però so praticamente che questa risorsa è presente Ogni volta che una di queste risorse cambia, o è creata o viene deleted, oppure la label cambia, voglio praticamente saperlo.Quindi faccio partire un watcher su quella risorsa, ci metto un predicate, che alla fine è un predicate, non è altro che dire che operazione è successa, è stato creato una risorsa di questo tipo, è stata deleted una risorsa di questo tipo, o c'è stata una modifica.Se c'è stata una modifica, cosa è cambiato? in modo tale che io possa decidere se devo praticamente partire la mia reconciliation o no.Quindi dicevo queste, non è un controller che continuamente va a dire qualcosa è cambiato, qualcosa è cambiato, il controller va a dire mi interessa sapere se ci sono modifiche di questo tipo e se ci sono modifiche di questo tipo fammelo sapere perché voglio praticamente prendere poi le migrazioni.Ok, ok.Allora, quindi, diciamo, arriviamoci subito.È una figata Sveltos, cioè nel senso quando l'ho visto ho detto "Madonna, che figata".Però a questo punto come funziona? Alla fine hai detto "Ok".Quando magari mi hai creato un nuovo cluster, no? Però il fatto che possa gestire, diciamo, i cluster su infrastrutture diverse, no? Quindi magari ne ho uno su AWS, uno su Google Cloud, uno su digital, uno su delle macchine diverse, ok? Come funziona? Alla fine io vi dico, per accedere a questi cluster, a questi credenziali, quindi è come se avesse tutte le kube config, diciamo, dei vari cluster.Quindi possiamo dire che è un cluster di Kubernetes che crea e gestisce altri cluster.Cioè, come funziona e come fa questa cosa ad essere trasparente al Kubernetes padre? Mi sto spiegando malissimo.Però, insomma, giusto così per rendere idea.significa che le API degli altri cluster sono esposte e raggiungibili, c'è una VPN, come funziona? C'è un...Ci sono diversi modi, io porto praticamente da dove sono partito io.La bellezza di Kubernetes è che praticamente puoi usare Kubernetes per creare altri Kubernetes cluster.e c'è questo progetto che è fantastico, che si chiama Cluster API.Quindi immagina di avere un tuo cluster che viene chiamato praticamente Management Cluster e su questo Management Cluster tu ci metti Cluster API.L'idea di Cluster API è di, da questo Management Cluster, di creare praticamente altri cluster.Quindi tu come user crei una Kubernetes resource che è un cluster API cluster in cui dici voglio un cluster su AWS con questa Kubernetes version, questo numero di control plane nodes, questo numero di worker nodes.Se nel tuo management cluster hai installato cluster API ed hai installato AWS come infrastructure provider per cluster API, quello che succede è che nel momento in cui tu crei questa cluster resource Cluster API controller, quindi le AWS controller, infrastructure provider AWS controller, reagiscono a te che hai creato questo, hai richiesto questo cluster, raggiungono praticamente il tuo AWS account, a quel punto tu hai, quando hai installato le AWS cluster API con le AWS infrastructure provider hai dato praticamente le tue credenziali, non dai tuo username password, ma dai dei token in modo tale che possono raggiungere, possono usare le AWS API e creare praticamente questo cluster.Quindi il cluster viene creato per te e a quel punto là tu hai un...dal management cluster hai creato quest'altro cluster, programmaticamente.Quindi usando Kubernetes hai creato quest'altro cluster.Adesso usando la bellezza di cluster API è che magari tu dici "ma io voglio un cluster in AWS, voglio un cluster in GCP e voglio un cluster on-prem".Allora quello che fai è che tu installi Cluster API e installi tre diversi tipi di infrastructure provider, le AWS infrastructure provider, il GCP infrastructure provider e magari ci metti OpenStack, perché ce l'hai per gestire il tuo on-prem.E quindi da questo management cluster a quel punto puoi creare cluster su AWS, cluster su GCP, cluster on-prem.Li hai creati dal tuo management cluster.E qui praticamente che arriva Sveltos, a questo punto, perché tu hai creato praticamente questi cluster.Però alla fine, nel momento in cui tu crei cluster, poi ci vuoi mettere le tue applicazioni, ci vuoi mettere praticamente i tuoi admission controller, ci vuoi mettere praticamente i CNI.È lì che praticamente arriva Sveltos.Sveltos quello che fa è che dice "ok, nel management cluster mettici anche Sveltos".Adesso tu hai creato tutti questi cluster, ognuno di questi cluster praticamente è rappresentato da un'instanza nel management cluster, da una cluster instance nel management cluster.Quindi mettici le label su questi cluster instances.Una volta che ci hai messo delle label, usa Sveltos per dire, questo è il mio cluster selector, quindi ad esempio voglio prendere tutti i cluster che sono in production, o tutti i cluster che sono in pre-production, o tutti i cluster che sono in AWS in una certa zone.Purché tu abbia messo praticamente le right setup label sui tuoi cluster, a quel punto praticamente puoi selezionare questa risorsa, perché alla fine non è altro che dire "voglio tutti i pod" e la stessa cosa è dire "voglio tutti i pod con lo label environment production".Quindi ti seleziona queste risorse e poi dici "queste sono praticamente la serie di mCharts, YAML, Customize, qualunque cosa che tu puoi installare su questi cluster e voglio che si deploy su questi cluster" e Sveltos lo va a fare.Il modo in cui lo fa è che sostanzialmente quando tu usi Cluster API e crei un cluster, la kube config di questi cluster è in una secret nel management cluster.Quindi se tu hai tre cluster, uno su AWS, uno su GCP, uno on-prem, alla fine nel tuo management cluster hai tre secret, una che contiene la kube config per avere praticamente accesso alle AWS cluster, l'altra che ha il kube config per avere accesso al tuo GCP cluster, e l'altra che ha il kube config per avere accesso al tuo on-prem cluster.e questa kube config qui praticamente è tied al cluster admin user, quindi puoi fare praticamente quello che vuoi.E quindi a quel punto lì praticamente Svelto sprende questo kube config perché sa dove si trovano queste secret per i vari cluster e va praticamente a crearsi un client per accedere a questi vari cluster.Quindi si deve installare Caverno sulle AWS cluster, si va a prendere la kube config, la secret che contiene le kube config delle AWS cluster, si crea un client con quel kubeconfig e poi praticamente usa le Kubernetes API per fare praticamente il deployment del caverno e l'insearch su quel cluster.Poi Sveltos non è limitato solo praticamente a cluster API, nel senso che è partito come un'estensione di cluster API, ma a questo punto tu potresti dire "io ho un altro cluster che ho creato out of band, non con cluster API, ce l'avevo già, però voglio che sia dal punto di vista degli application elements managed by Sveltos nel management cluster.Quindi semplicemente l'unica cosa che devi fare è prendere il kube config di questo cluster qua che tu hai e andarlo a registrare, creare praticamente una Sveltos cluster nel management cluster in cui dici "questa è la kube config per accedere a questo cluster, questo cluster lo chiamo con un nome che praticamente così sai quale cluster ti stai riferendo" E dopodiché praticamente Sveltos può fare il management di quel cluster.Degli add-on e application su quel cluster, anche.E quindi diciamo che alla fine il management cluster, che è quello su cui è installato, diciamo, l'operator di Sveltos, è come se fosse un po', diciamo, il terraform degli altri cluster.Cioè ha lui dentro lo stato di cosa è deployato e delle specifiche del cluster.Quindi, non lo so, per dire, se voglio aggiungere un nodo ad un cluster che ho creato, diciamo, con Sveltos, lo posso fare tramite Sveltos.Quindi, nel senso, oppure è una cosa che si limita solamente alle applicazioni.E poi, come funziona in questo ultimo caso? Penso che è anche molto molto interessante.Se io ho un cluster che magari sta girando da anni, e quindi ha le sue applicazioni, ha i suoi secret, ha tutto.Quello, come fa Sveltos a riconciliare verso quello stato? Cioè, tipo, importa lo stato del cluster e poi nel processo di riconciliazione, che cosa succede se questo stato diverge? Perché magari Sveltos mi ha deployato A, B e C, però io vado a mano con la kube config a mettere D.Che cosa succede? Provo a rispondere in ordine.Sul nodo, se tu vuoi aggiungere praticamente più nodi, quella è qualcosa che non viene fatta svelto.In quel caso lì, praticamente, se tu hai creato il cluster con cluster API, vai praticamente a cambiare, c'hai la tua configurazione lì, a dire voglio un nodo in più o voglio un nodo in meno.e Cluster API automaticamente fa tutto quello che è necessario fare.E quella è veramente la bellezza, perché tu come user è come se c'avessi...vai semplicemente a cambiare questa spec in cui dici "ma il numero di nodi ne avevo tre, adesso ne voglio cinque", e cambi praticamente quel field da tre a cinque e i Cluster API Controllers automaticamente fanno questa magia di scalarti up il numero di nodi che c'è su quel cluster.Ho un'altra operazione che è veramente pesante, fare l'upgrade del cluster.Non è un'operazione semplice, però se lo fai con cluster API, sostanzialmente quello che fai è dire "oh, io ho un cluster che ha questa versione di Kubernetes 1.29.0, voglio passarla a 1.30.0", cambi semplicemente quel field, e cluster API ti fa praticamente tutto il lavoro di fare l'upgrade del cluster.Quello che fa Sveltos è gestire, quindi cluster API ti gestisce la life cycle del cluster, quindi creazione del cluster, upgrade del cluster, aumento o diminuzione dei nodi in un cluster e delete del cluster.Quello che fa Svelto è gestire applicazioni e add-ons che sono deployed su questi cluster.Supponi, l'altro esempio di questo succede praticamente se tu vai a modificare dei cluster.Ad esempio, se tu dal management cluster vai a dire "io voglio che il caverno admission controller sia deployed sul mio on-prem cluster".E poi magari hai dato anche il cluster admin, c'è un altro user che ha anche cluster admin accesso per questo on-prem cluster, e lui va a fare praticamente un kubectl delete del namespace caverno, quindi tutto viene deleted.Quello che succede è che praticamente a questo punto lo stato del tuo manage cluster è diverso da quello che tu ti aspettavi, perché nel management cluster hai detto "io voglio caverno", ma qualcuno è andato nel manage cluster e va fatto il delete di caverno.Quello che fa Sveltos è che si accorge che c'è un drift della configurazione, qualcosa è praticamente stato delete.Sveltos lo fa praticamente tramite Dave Watcher, quindi lui c'ha un agent nel manage cluster che sa quali sono le risorse che Sveltos vuole gestire, in questo caso caverno, ha visto che una di queste risorse qui è stata deleted, il caverno namespace, quindi gli altri caverni e risorse, manda una notifica al management cluster e gli dice "guarda che c'è stato un drift, questa risorsa che tu volevi non c'è più, oppure questa risorsa che tu volevi è stata modificata".E quindi Sveltos riconcilia Beck e rimette praticamente Gaverno Beck nel manage cluster.Perché l'idea è che sostanzialmente siccome stai usando Kubernetes quindi dovrebbe essere proprio esattamente come Kubernetes vuole essere, indipendentemente dal fatto che questi siano cluster diversi.però tu stai sempre usando Kubernetes per dire questo è lo stato che io vorrei.Quindi io vorrei caverno sul mio on-prem cluster.Quindi se qualcosa cambia, la versione viene cambiata, viene deleted, non sei più in sync con quello che era il tuo intent che è stato espresso nel management cluster, quindi Svelto se ne accorge e fa praticamente la riconciliazione.E la stessa cosa se sostanzialmente qualcuno va nel manage cluster che fa praticamente un...rimuove uno dei nodi.Cluster API praticamente si accorge che uno dei nodi non c'è più o che è andato giù e quindi fa la riconciliazione e quindi praticamente ritorna ad avere il numero di nodi che tu volevi.Quella è veramente la bellezza di Kubernetes.Se ci pensi come user, delle operazioni che sono complesse stanno diventando praticamente delle semplici operazioni in cui tu dici questo è lo stato che voglio.Tu sai come fare, praticamente, tu controller sai come fare per fare in modo che lo status sia quello.Ok, ok, ok.Prima hai menzionato Cube Builder, no? Che comunque, a quanto ho capito, parlo un po' fuori da questa cosa, è de facto uno degli standard, diciamo, per creare questo tipo di app, di app, di app, di app.Quindi che cosa è QBuild alla fine e quali anche sono le alternative a QBuild.Quindi magari, come mai qualcuno dovrebbe scegliere questo invece che l'altro, insomma.Perché poi immagino che alla fine si appoggino entrambi, immagino, su un set di dipendenze base che sono comuni, credo.Io in realtà praticamente non ho usato l'operator SDK, quindi non posso fare un confronto tra i due, perché ho sempre praticamente iniziato a usare QBuilder, mi sono trovato veramente bene con QBuilder.In realtà praticamente quando...Io sono stato anche per un anno a Tagheera, che è la startup che c'è dietro Calico, e lì sostanzialmente loro avevano iniziato prima che tutti questi tool fossero available.Quindi quando io ero praticamente in Taghera, sostanzialmente le cose si scrivevano praticamente from scratch.Quindi non c'era ai tempi nessun tool.Poi loro hanno iniziato in Taghera quando io stavo per andare via, avevano iniziato questo progetto, usavano praticamente l'operator SDK per scrivere il tagger operator, che alla fine si occupa di fare, installare calico e fare in modo che tutto sia funzionante.Semplicemente lo user deve postare il tagger operator.Con QBuilder è un tool che è veramente facile iniziare.C'è veramente un Cube Builder Book e seguendo le istruzioni di quel Cube Builder Book si può scrivere praticamente un controller seguendo le istruzioni, un controller base, sostanzialmente, però per iniziare, per capire praticamente, per giocare, per capire, per imparare, veramente in un paio d'ore.Poi è molto semplice sostanzialmente creare delle API, perché c'è praticamente questo QBuilder Create API in cui tu dici questo è il mio dominio, questo è il nome della custom resource definition che voglio introdurre, e ti va a chiedere praticamente vuoi introdurre solo la risorsa, vuoi introdurre la risorsa più il controller, e quindi ti genera praticamente un sacco di boilerplate code, quindi la tua vita diventa molto più semplice perché adesso vai a riempire un paio di funzioni e c'hai già praticamente un controller base.Ci sono poi delle librerie come la controller on time che sono praticamente, ti danno veramente la possibilità di fare cose super complicate in modo abbastanza semplice.Ad esempio, quello che dicevo io prima, che io voglio, quando tu vuoi far partire un watcher e vuoi far partire un watcher, però vuoi, su una certa risorsa, però vuoi reagire soltanto quando c'è praticamente una create o una delete, non ti interessa degli update, oppure praticamente vuoi reagire agli update soltanto se qualcosa è successo.Il modo in cui puoi farlo è veramente semplice, perché ti dice, definisci il tuo predicate, quindi quali sono le operazioni, create, delete, update, quindi quando...il predicate funziona in questo modo qui.Quindi tu dici voglio vedere, voglio fare un watcher su un cluster.Quindi ogni volta che un cluster cambia ti arriva questa notifica, che il cluster è cambiato, quindi va sul tuo predicate.Quindi qual'era l'operazione? Era una create.Quindi tu c'hai la possibilità di andare a vedere quale risorsa è stata creata e dire se quella è qualcosa che ti interessa oppure no.Quindi se ti interessa tu semplicemente dici, restituisci una boolean true, significa voglio andare avanti.Se non ti interessa restituisci false, quindi quella notifica viene droppata lì praticamente 9 volte.e qui c'è la possibilità di farlo per una create, delete, update.Quando fai l'update puoi anche andare a vedere praticamente cosa è cambiato sulla vecchia risorsa e la nuova risorsa.E supponiamo che tu a questo punto, praticamente con il tuo predicate, dici "questo è qualcosa che mi interessa", perché se qualcosa viene droppato, dici "non mi interessa", viene droppato lì, non succede nient'altro.Però se tu dici "questo è qualcosa che mi interessa", a quel punto viene da chiamare una funzione che viene chiamata praticamente "transformation function" sostanzialmente.L'idea di questa transformation function è che tu stai praticamente guardando dei cluster, una risorsa.Però il tuo controller è su un diverso kind, su una risorsa diversa.Quindi c'hai la possibilità in questa transformation function di dire siccome questa risorsa qui è stata praticamente modificata, quali sono le risorse che io gestisco, di cui voglio andare a fare la reconciliation.Nel mio caso, ad esempio, la label di un cluster è cambiata.Quali risorse voglio andare a fare reconciliation? Voglio andare a fare la reconciliation di tutte le risorse che lo user ha creato in cui questo cluster prima non era un match, adesso è un match, oppure prima era un match, adesso non è più un match, perché in un caso devo andare a fare il deployment dei nuovi, di tutti gli ad-ons che lo user vuole su quel cluster, e nell'altro caso devo andare a togliere queste risorse, perché il cluster non è più un match e lo user non vuole che queste risorse siano più deployed su quel cluster quindi lo deve andare a togliere.Però se praticamente invece quello che è cambiato è perché è cambiato il numero di nodi.Istanzialmente quello è un evento che a me non interessa perché se ci siano tre nodi, cinque o sette, quelle risorse dovevo fare il deployment e quelle risorse ho fatto il deployment e quindi quelle modifichano che non mi interessa e che posso droppare nel mio pre-req.Mamma mia, ho un sacco di domande, scusami.No, ma allora, la prima domanda è una domanda un po' del cazzo, nel senso che è polemichetta spicciola.Secondo te, anche avendo visto la tua esperienza con Kubernetes e col mondo cloud native, perché tutto l'ecosistema gira tanto intorno a Go? Quando ho visto il source code dello Streamsy, sono un attimino rimasto, perché non è l'operator classico, l'ho scritto in Go, l'ho rifatto in un certo modo.Perché secondo te Go, secondo te, ha senso se avessi l'equivalente di Kubuilder magari in un altro linguaggio, ti farebbe piacere? No? Così.Il perché, credo, la risposta sia sul numero di librerie che sono disponibili in Go e quindi sostanzialmente riduce la quantità di lavoro che tu devi fare.Ad esempio, se tu vuoi mandare praticamente un...vuoi avere un controller che manda una Slack notification, uno Slack message quando succede qualcosa, c'è una libreria praticamente in cui usi quella libreria e in cinque minuti praticamente riesci a mandare, riesci a scrivere del codice che manda uno Slack message.Lo stesso per WebEx, lo stesso per Discord, lo stesso praticamente, quindi è l'ecosystem.La quantità di libraries che sono available in Go e quindi che tu puoi praticamente, open source, che tu puoi importare ed usare, e credo che quella sia praticamente la differenza.Quello che fa vincere proprio Go rispetto, in questo caso, rispetto ad altri linguaggi di programmazione.Io, prima di Kubernetes, ero un C/C++ developer.Quindi ho sempre praticamente fatto C/C++.Fino al 2018, quando ho iniziato poi con Kubernetes.e il vantaggio di Go secondo me è la semplicità.Ad esempio, io mi sono fermato a C++17 e una cosa praticamente che non mi piaceva tanto era la complessità di definire certe cose in C++.Era veramente...c'è uno delle...scriverci quanti caratteri per definire praticamente qualcosa.Quindi era...la complessità stava diventando...è un linguaggio fortissimo, però la complessità stava diventando memorizzare tutte quelle syntax lì, era veramente tanto.L'altra cosa che mi piace di Go è è Go applied a Kubernetes e il testing.Sostanzialmente io scrivo il...una library in Go e testo la library in Go ed è praticamente nello stesso repo.E applied a Kubernetes c'è praticamente un altro step in più.Perché io non posso...non faccio semplicemente unit test del codice che scrivo, però faccio anche quello che viene chiamato functional verification.sostanzialmente veramente semplice, è su Mac, un laptop, crearsi praticamente un Cluster Locally.Quindi ti crei praticamente, come parte di tutti gli open source che ciò, come parte della CI/CD pipeline, c'è il linting, c'è unit test, e poi c'è questo functional verification.Questo functional verification non è altro che Creare una Docker image del mio controller, creare un kind cluster, quindi un local sulla mia macchina, praticamente con GitHub Action, installarci il controller e poi usare Jinco per testare il controller.quindi magari io so che praticamente il mio controller deve fare questa operazione se lo stato è questo deve portare praticamente ad andare a portare il sistema in quest'altro stato e praticamente creo quelle risorse e poi vado semplicemente a verificare che il controller abbia fatto praticamente il suo ruolo ed è praticamente in quello stato lì.Quindi la quantità, il livello cui riesci a testare il codice con Go, GoAppLite e Kubernetes Mi dà una confidenza, per cui praticamente se scrivo "enough unit testing and enough functional verification code", se la CI/CD sta passando, sono tranquillo, praticamente che nel 95% dei casi praticamente non ho bacchi e non ho introdotto, non ho rotto niente, non ho introdotto...No, no, no, in realtà hai risposto anche alla mia domanda su che sia appunto come si questa roba.Questo è interessante, il fatto di poterlo testare, poterlo diciamo osservare con un cluster reale in una maniera semplice, cioè effettivamente è una cosa figa, insomma.E poi, una volta che tu hai scritto l'operato, ecco come si rilascia l'operato.Cioè, alla alla fine QBuilder ti genera anche, ad esempio, gli AMOL per la custom resource, ad esempio, ok? Quindi significa che tu ad un certo punto vuoi impacchettare il tuo periodo.Quindi di che cosa hai bisogno, come lo fai e come si rilascia, insomma? Rilascio quella cosa un po', la lascio come seconda parte.Quando inizi a usare, praticamente, QBuilder ti genera un sacco di boilerplate com, ti genera anche un sacco di makefile target.E tra questi, praticamente, makefile target, essenzialmente, c'hai anche quello che ti genera tutto lo YAML che è necessario che va dalle tue custom resource definition al tuo deployment, al tuo service, è tutto praticamente lì, quindi c'è questo make target che tu vuoi fare.Internamente usa praticamente customize, quindi devi essere un pochettino, se vuoi cambiare qualcosa, devi essere un pochettino familiar con customize, nel senso che devi sapere praticamente quali file andare a toccare, però sostanzialmente se non ti interessa cambiare nulla.Si attiva bene l'output di QBuilder, che nella maggior parte dei casi non è così, perché almeno il prefisso dei nomi o il namespace in cui lo vuoi sono cose che vuoi cambiare.Però il resto, lui ti crea tutti questi customize, questa structure di file in cui tu puoi fare un customize build e ti viene fuori l'output.In realtà con il Customize Build c'è anche un Mac File Target che ti permette di fare quello.Quindi QBuilder ti aiuta anche in quello.Poi ovviamente devi essere un pochettino familiar con Customize perché ci sono delle cose che vuoi cambiare, vuoi fare leggermente, magari ci vuoi aggiungere dei default arguments al tuo deployment o vuoi aggiungere qualche altra risorsa extra e quindi devi sapere praticamente quali file andare a cambiare.però QBuilder ti genera tutto questo.Quindi alla fine hai questo YAML che è quello che ti serve per postare.Per fare la release del controller, quello la vedo come una cosa diversa, nel senso che a quel punto, quando tu hai iniziato a scrivere il controller, poi inizi a metterci feature o bug fixing e poi decidi tu quando è il momento di fare una nuova release, oppure no.Ad esempio l'approccio che c'ho io con gli open source che mantengo è che uso diversi branch, uso praticamente il dev branch come development, quindi continuo praticamente a pushare PR, a fare il merge di PR su questo development branch.Nel momento in cui decido che è tempo di fare una nuova release, creo praticamente la nuova release da quel DevBranch e poi faccio il sync di Dev sul main in modo tale che il main è sempre stable e c'è una nuova release.Quindi non so se quella era praticamente la tua domanda, se la tua domanda sul...- No, no, no, questo sì.Diciamo la mia domanda era più su come lo rilasci al pubblico, cioè nel senso, alla fine con questi YAML preferisci metterlo in un hand chart, hai l'immagine docker, l'immagine del controllo che devi comunque buildare, pushare, diciamo preferisci farlo con un customize o buttare gli email così.No, ti...Sì sì, no, scusa, l'ho capito male io.No, no, vabbè, ma nel senso ti voglio dare anche un po' di contesto su questa domanda e te ne faccio anche un altro, perché secondo me l'opinione tua è quella cosa che mi può un po' svoltare, da questo punto di vista.Io non faccio DevOps.Io non ho mai fatto DevOps, insomma, mi occupo e conosco, diciamo, l'amministrazione standard di una macchina.Io dal punto di vista di Kubernetes sono un application developer, non sono un amministratore.Ok, giusto così per fare questo contesto qui.Tra i vari tool, insomma, diciamo un po', un po' per scherzo, un po', no, con alcuni colleghi, con alcuni amici, insomma, si dice spesso che i tool per l'operation sono veramente più brutti rispetto a quelli per i developer, insomma.Nel senso, anche diciamo ergonomicamente, no? Ok.E spesso quando dobbiamo metter mano a un Elm chart è una sofferenza incredibile.Cioè, nel senso proprio il templating di Go è veramente, probabilmente, è abitudine bassa, proprio mi vorrei strappare gli occhi, insomma, piuttosto che farlo.A te piace, quindi preferisci rilasciarlo come un Elan Chart? È una cosa che ti piace, Elma? Oppure no? Questa è proprio una domanda all'atere.La prima domanda praticamente è quello, io lo rilascio sia come YAML sia come Unchart che come Customize perché quello praticamente che ho visto è che diverse persone hanno diverse preferenze e quindi riesci a raggiungere più users se offri tutte le possibilità, Quindi, sì, praticamente chi vuole usare, chi vuole postare direttamente lo YAML, c'è il link che contiene tutto lo YAML, prendi quello, lo posti e, boh, funziona.C'è l'earnchart, se vuoi usare l'earnchart, o c'è praticamente il customize, se vuoi usare praticamente il customize.Perché veramente ho visto che sono persone che sono veramente super expert su un tool verso un altro e hanno veramente delle preferenze super, "io voglio usare questo, se non c'è questo non lo considero neanche".E quindi io ce ne ho tutte e tre.Lascio scegliere a livello di user, preferenza di user.La mia preferenza.Non sono esperto con customize.Nel senso, quello che ho imparato l'ho imparato perché mi serviva poter imparare dove andare a fare le modifiche, Usando più build devo andare a fare le modifiche per quello che volevo io.Tra Yamal e Helm? Dipende sostanzialmente perché Helm, onestamente, se c'è un sacco di risorse che devi gestire, forse viene gestito, ti aiuta da quel punto di vista.No, no, sostanzialmente dipende, perché a volte una delle cose su cui Sveltos ti aiuta che a volte praticamente tu hai un elm chart e vorresti cambiare qualcosa che però non è esposto nei values che tu puoi andare a configurare.E allora lì praticamente, sostanzialmente, la soluzione che tanti hanno è "vado a farmi il fork di quell'elm chart e poi praticamente me lo modifico io", però poi te lo devi anche mantenere.Una cosa praticamente, ad esempio, che Svelto si permette di fare di fare queste post-patch, in cui ti dici, praticamente, "queste sono le unici arti che vorrei fare".Non c'è il modo di cambiare questa...l'image registry, for instance.Però io so, praticamente, che voglio cambiare l'image registry perché ho scaricato l'immagine e l'ho messa, praticamente, nel mio local registry.Quello, praticamente, svelto se permetti di farlo con le post-patch.Però se non ti piace, praticamente, il...il go-templating, forse questo post page perché Jason non ti piace neanche quello.Però dipende, senzalemente dipende dal gusto.Ho visto praticamente che c'è gente veramente esperta con Customize, che mi hanno aiutato, c'è uno user di Sveltos che lui è super expert con Customize e mi ha dato delle dritte e mi ha aiutato praticamente a mettere su, praticamente a permettere che Sveltos possa essere installato con Customize as well.Quindi mi suggerimento quello che vedo è se hai possibilità mettergli tutte le possibili opzioni hai possibilità allo user di scegliere.Ok, e invece Kubernetes Cleaner, perché nel senso è anche l'altro gesto, avviene prima o dopo Sveltos? Immagino così, a Nato, che abbiamo anche due livelli di complessità diversi, ad esempio.Sì, sono complessità diversi, cleaner è praticamente su un single cluster, quindi non sta lì nel cluster.L'idea di cleaner è venuta perché, sensualmente, spesso e volentieri ti ritrovi a dover eliminare delle risorse che sono lì nel cluster e che per qualche motivo sono lì.Un esempio è se tu si customize con il config map generator ogni volta che l'esce il config map cambia, ti crea una nuova config map ma non ti fa il delete della old, che dal loro punto di vista capisco perché ho fatto in quel modo lì, la cancelli tu nel momento in cui la vuoi cancellare, io ti creo la nuova e quella vecchia la cancelli tu.Però alla fine praticamente se il numero di risorse va a crescere.E ci sono dei tool che ti permettono di trovare queste risorse unused con fitmap, per esempio.Ci sono dei tool che ti permettono di farlo.Quello che mi piaceva di questi tool è che c'è la loro definizione di cos'è unused o cos'è unhealthy, che però magari non è la tua definizione.Per me magari una config map è unused soltanto se nessun pod la sta montando e è più vecchia di tre settimane.E l'init cluster va già da tre settimane.Quella è la mia definizione, è leggermente diversa da questo altro tool.Quindi io volevo con KTAS Cleaner un tool in cui lo user possa definire cos'è unused.Quindi KTaskCleaner ha una library abbastanza grande di definizioni, così non use config map, così non use persistent volume, così è praticamente un NLP deployment.Però ti dà la possibilità, se nessuna di queste definizioni è quella che serve a te, ti dà la possibilità programmaticamente di definire, usando praticamente l'UA, di definire qual è la tua definizione.Quindi tu puoi dire guarda le config map, i pod, i secret e vai a trovare praticamente una risorsa che è in questo modo qui.Quindi tu puoi definire esattamente che cos'è.E quella è la differenza di KDEscrive.E il motivo per cui l'avevo fatta è perché tipo al lavoro continuavamo ad avere questi use case dove una settimana dovevi trovare qualcuno C'era questo cluster che è condiviso praticamente da tanti ingegneri, qualcuno una settimana diceva "questo deve essere rimosso, questo deve essere rimosso, questo deve essere rimosso" e alla fine praticamente c'era questa tendenza a scrivere script su script su script per trovare queste risorse e farne il delete.Allora lì mi sono detto veramente "non mi piace questo approccio, Voglio un approccio che sia programmato in assoluto, voglio praticamente...quello che ti dà Kitescreen è la possibilità di generare un report.Tu crei la tua definizione e gli dici "genero un report, non fare nulla, semplicemente fammi vedere quali sono le risorse che matchano la mia definizione di unused on LT" e ti genera questo report.Magari ti manda praticamente la Slack notification perché te lo vuoi vedere e lo vuoi vedere su Slack, o ti manda la WebEx notification per vederlo su WebEx se lo vuoi vedere praticamente creato una risorsa sul cluster direttamente, ti crea praticamente la risorsa sul cluster direttamente, quindi riesci a vederla.E poi puoi dirgli praticamente cosa devi fare.Ma la differenza non è soltanto praticamente che trovo queste risorse, che ti fa anche il delete, ma la differenza è che anche ti permette di trasformare, di fare un update di queste risorse.Ad esempio, tu puoi dire c'è un deployment che è in continuo CrashLoopBack, ok? Ed è in continuo CrashLoopBack che sta usando un tag di un image che è alt.L'abbiamo praticamente...c'era un bucco, l'abbiamo fissato e tutti i deployment che stanno usando praticamente questo tag muovili su quest'altro tag.E allora praticamente quello puoi dirlo a Keras Cleaner.Gli puoi dare praticamente...creare una Cleaner instance, che è un altro che è una Kubernetes resource, in cui gli dice "trovo questi deployment, sono un match, ma non voglio che ne fai un delete, voglio semplicemente che cambi il tag dell'image e lui ti fa l'update di tutti questi deployment che hai trovato, ti fa praticamente l'update del tag dell'image questo sono semplicemente degli esempi banali, ma sostanzialmente puoi dare la tua configurazione puoi dire esattamente quello che vuoi che faccia poi un altro esempio, puoi dire a cleaner "alle 8 di sera tutti i deployment devono andare a replica 0" perché questi sono testing cluster che nessuno usa più, vogliamo risparmiare risorse, tirerli giù e la mattina, alle 8 di mattina, riportali praticamente al numero di replicas che c'avevano e lui praticamente lo fa.Ed è, di nuovo, gli passi semplicemente una configurazione e lui lo fa programmaticamente.È una roba finissima, nel senso nella sua...io mi eccito tra le lette, ho tantissimo entusiasmo per delle cose del genere, perché sono quegli use case in cui mi ritrovo, cioè nel senso di script e di alias per la shell, per trovare coi selector, ne ho scritti un sacco, quindi nel senso che questo è uno use case dove mi ritrovo.Allora, ci stiamo avvicinando verso la fine della puntata, purtroppo, perché in realtà io c'avrei un sacco di cose da dire, è da chiedere più che altro, e quindi diciamo noi abbiamo in queste puntate un momento che si chiama il momento del Paese dei Balocchi, che è sostanzialmente un momento in cui l'ospite, se vuole condividerci qualcosa con la community GitBar, che sia attinente, diciamo, a ciò di cui abbiamo parlato, ma anche che non lo sia...Io, nella puntata precedente, mi sembra di poi che ho portato una sedia, notte con uno spray miagrumi, cioè nel senso non è proprio necessario che sia strettamente attinente con quello di cui stiamo parlando.C'è qualcosa che vuoi condividere, insomma, oltre a Sveltos e Cleaner, che saranno sicuramente anche i miei balocchi, perché sono delle robe veramente fighe.Grazie, no, grazie.Tipo esperienze personali al lavoro, cose di differenza? personali, libri, blog, articoli, spremi agrumi, quello che ho insomma, qualche cosa che ti piacerebbe lasciare alla community.La cosa più...sembrerà strano, ma uno dei motivi...sono sempre stato praticamente...io ero parte di Insieme, che era praticamente una start-up che poi è andata a essere acquisita da Cisco Uno dei benefit che mi piaceva di più di Insieme era avere la macchinetta del caffè super professionale, quella tipo che hai al bar, che arrivi lì la mattina e ti fai il caffè.E anche ogni volta praticamente che vado negli Stati Uniti, perché adesso anche quando sono tornato in Italia l'ultimo anno sono già andato praticamente alcune volte, La cosa bella è che adesso è diventata una cosa comune, cioè che vai in ufficio, se sei una compagnia come Cisco, vai nell'ufficio e c'è la macchinetta del caffè col barista che ti fa l'espresso.Quindi si è passati dal bere il caffè americano, che sono gusti personali, ma non mi è mai piaciuto ad avere l'espresso che puoi bere al lavoro e c'è il barista che ti fa...quindi è veramente come se andassi al bar a prendere il caffè.È una cosa che mi è piaciuta sempre.Era una cosa praticamente alla fine, guarda, sembrerà strano, ma chiedevo praticamente anche quando facevo dei colloqui per cambiare lavoro, chiedevo praticamente quando andavi in ufficio poi per fare l'on-site interview, quella è una cosa che chiedevo, ma avete una macchinetta per l'espresso? No, no, è vero.Allora, guarda, questa cosa qui… Non è ovviamente la discriminante su cui sceglievi… No, no, no, assolutamente.Vabbè, da questo punto di vista sono assolutamente d'accordo.Io non si vede perché è tutto quanto blerrato, ma io ho la macchiata per l'espresso che vedo tre, quattro moche, la French Press, insomma, nel senso anche io sono un appassionato di caffè, insomma, quindi da quel punto di vista assolutamente d'accordo.Non ho mai lavorato in un posto dove ci fosse il barista, però ho sempre lavorato fortunatamente in uffici dove c'era la macchietta del caffè, quella proprio, quella bella, quella che tu e tu gli dici "questa cosa costa tanto e fa un buon caffè".Era quella discriminante.Negli uffici di Suse a Norimberga non c'è il barista, a meno che lo sappia quando ci sono andato io, ma c'è questa macchietta del caffè bellissima con il taschino, questa temperatura programmabile al decimo di grado, era una roba bellissima.- Cioè, quando bevi il caffè, solo quando metti lì davanti...- Sì, metti davanti e dici "ah, bello".E mi ricordo che un mio collega mi disse "ma sai che bello se gli metti sto firmware custom, sai perché c'erano alcune limitazioni della macchinetta, tipo la temperatura, e così, è figo".dal punto ottimo, Balocco, perché nel senso è fondamentale.In realtà, io come Balocco, vorrei portare sicuramente i tuoi progetti, ma anche il tuo tutorial sul Kubernetes Controller, che è il motivo, diciamo che è il modo in cui ti ho praticamente scoperto.Perché in una spasmodica ricerca su Google, sono andato su sto repository.Cioè, nel senso, era proprio di aspetta, fai vedere.Con delle bellissime grafiche, come le hai fatte? Cioè, tipo, quelle animate sono bellissime.Grazie, non solo grazie.Sì, no, uso Droid.io e ti permette praticamente di fare soprattutto la parte sketch, quando devo fare tipo una sketch, quella è veramente carina, la parte animata poi devi fare praticamente le animazioni, devi fare il recording delle animazioni perché non ti permette di fare l'export, ti permette di fare l'export come un PNG ma non ti permette di fare l'export come un...con le animazioni però ci metti praticamente, ci fai il 5-6 secondi di recording, cioè puoi fare le animazioni lì ma le puoi esportare quindi fai praticamente faccio un recording sopra.Ci saranno praticamente ancora, ci sono ancora delle altre cose che voglio coprire in quel tutorial, quindi sono come gestire, come fare multiple version del same CRD, quella verrà a breve, come testarlo, praticamente quella è una sezione che voglio ancora coprire in un accoperto.Non fa pensiere che, insomma...No, no, è assolutamente utile.Personalmente penso che quello che c'è, anche se non è coperto tutto, e che arriverà sia estremamente più conciso e fruibile rispetto a tanta altra documentazione.Anche la stessa di CubeBuilder, bellissimo, il libro, bello.però diciamo ci sono alcuni concetti che sono espressi in una maniera molto più fruibile a che ci mette le mani per la prima volta rispetto magari al resto del lato documentazione.Quindi sì.Ok.Sì, siamo ad un'ora e ventiquattro minuti.non voglio tediare di più anche Gianluca che l'ho tassato di domande, mi dispiace, insomma, nel senso che purtroppo sono così, no, specialmente questo punto è dove sono solo, spesso ci sono i miei colleghi che mi fermano molto, dicono "ma basta", insomma, nel senso che purtroppo quando sono da solo effettivamente è un'rota libera, quindi a a tutti quelli che ci stanno ascoltando per la prima volta o quelli che ci ascoltano già, vi ricordo i nostri contatti.Info@github.it se ci volete inviare una tradizionalissima mail, @brainrepo su Twitter, ma soprattutto il nostro gruppo Telegram.Nel gruppo Telegram siamo, ve lo dico live, più di 1500 persone.È una community superattiva.Insomma, se ci volete passare a trovare, noi siamo lì.Faccio un po' le veci di Mauro, che non c'è questa sera, ma ciò che a noi ci piace di dire qui su Gitbar è che da questo momento, Gianluca, Gitbar è anche casa tua, quindi se vuoi venirci a trovare in futuro per parlare di qualcos'altro o farci conoscere ciò su cui stai lavorando, noi saremo felici di riaverti qui.Quindi un ringraziamento a voi che ci avete ascoltato finora, ci vediamo alla prossima puntata, ma soprattutto grazie Gianluca per essere stato con noi.Grazie a te, grazie a voi.Contento di essere qui.Benissimo.Ciao, ciao a tutti.[Musica] (Silenzio) (Sottotitoli a cura di QTSS)
