Kubernetes è un bicchiere mezzo vuoto o mezzo pieno? Beh, dipende da come lo si guarda! I meccanismi delle sue funzionalità di orchestrazione sono piuttosto complessi (a mio parere) e non è raro, anche per i professionisti più esperti, sbattere la testa contro il muro per questo motivo. Allo stesso tempo, l'ho spesso consigliato agli utenti alle prime armi e anche ai casi aziendali in cui la capacità di accumulare debiti tecnici è più limitata, allo scopo di lavorare in modo più intelligente, non più difficile. Sto svolgendo un secondo lavoro part-time come freelance, occupandomi della manutenzione di un sistema per una piccola organizzazione no-profit. Quindi, quando non ho 8 ore al giorno per fare da babysitter, più lavoro pesante posso scaricare su K8, più la vita è migliore per tutti noi. Ancora meglio, se lavoro per una grande azienda dove sono pagato 8 ore al giorno per fare il baby-sitter, preferisco comunque sfruttare la potenza di K8s per fare la maggior parte di questo lavoro al posto mio. Questa è la prospettiva del bicchiere mezzo pieno: considerare K8s come un alleato che vi semplifica la vita. Dichiarate ciò che volete e lasciate che faccia ciò che sa fare meglio.
Poiché questo approccio può sembrare eccessivamente semplicistico, sottolineerò anche la nostra tendenza a rendere le cose eccessivamente complesse. Ad esempio, quando progettiamo in modo eccessivo una soluzione per un "futuro a prova di bomba" che non è ancora all'orizzonte, o quando reinventiamo la ruota invece di utilizzare strumenti collaudati e già costruiti appositamente per il compito. L'immersione nell'ingegneria della piattaforma non fa eccezione, ma ne parleremo in un prossimo articolo.
K8s è un organismo potente e complesso, ma ricordate che molti dei nostri colleghi del settore hanno dedicato ore e ore a renderlo qualcosa che "funziona e basta" e, come per imparare a guidare un'auto, il modo migliore per imparare è quello di toccare con mano.
Sono stato introdotto per la prima volta a Kubernetes nel 2019, in prima linea nel team di assistenza clienti di Linode, quando abbiamo rilasciato Linode Kubernetes Engine (LKE). Si trattava di un momento in cui non potevamo evitare di affondare o nuotare, perché la domanda degli utenti era semplicemente troppo grande. Dovevamo supportare questo prodotto, il che significa che dovevamo impararlo e ancora meglio... risolverlo! Sebbene a volte frustranti, queste sono state alcune delle esperienze più preziose della mia carriera.
In questo articolo esploreremo alcune strategie per imparare e gestire Kubernetes, basate su esperienze reali come la mia.
Imparare facendo
Il modo migliore per comprendere veramente la piattaforma è quello di costruire e rompere cose. Combinare documentazione ed esercitazioni è un ottimo modo per mettere le mani su un cluster funzionante. Gettate i vostri manifesti in un repo Git e avrete un modello a cui fare riferimento per sempre. Poi, trovate un modo interessante per romperlo. Questo potrebbe essere lasciare che un amico o un collega ci provi, in modo da non avere idea dell'origine del problema finché non si inizia la diagnosi. Un altro metodo che ho utilizzato è quello di fare qualcosa di più complesso di quello che viene mostrato nella guida. Ad esempio, se state seguendo il corso CKAD della Linux Foundation. Il corso potrebbe istruirvi a costruire un cluster semplificato con un solo piano di controllo e un nodo worker. Provate invece ad avviare con successo un cluster con tre nodi del piano di controllo per l'alta disponibilità e tre nodi worker. Se questo non fosse abbastanza impegnativo, provate a implementare un VPC e a personalizzare l'indirizzamento di rete del cluster per evitare collisioni nello spazio IP. Anche se dopo qualche tempo vi sentirete frustrati e getterete la spugna, avrete imparato molto di più di quanto avreste fatto altrimenti. Questi sono solo due esempi tratti dalla mia esperienza personale. Il cielo è il limite.
Inoltre, strumenti come Minikube o Kind possono essere molto utili per la sperimentazione localizzata prima di toccare qualsiasi cosa nel cloud. Indipendentemente dal modo in cui si procede alla rottura, alla risoluzione dei problemi e alla riparazione del cluster, assicurarsi di lasciare una traccia di documentazione. L'atto di scrivere serve alla vostra memoria, in quanto vi obbliga ad articolare i passaggi e le soluzioni. Se avete il tempo di renderla pubblica, non solo potrete sfoggiare la vostra eccellente metodologia di risoluzione dei problemi, ma aiuterete anche i vostri colleghi.
La risoluzione dei problemi come percorso di apprendimento
Per quanto riguarda la metodologia di risoluzione dei problemi, non esiste una "pratica migliore" in sé, ma solo la "vostra pratica", ovvero dovete trovare il prurito che funziona meglio per voi, qualunque esso sia. L'importante è che vi impegnate a costruire questo muscolo e che con il tempo diventi più facile. I migliori risolutori di problemi che ho conosciuto sono diventati tali grazie ad anni di lavoro in questo senso e, di conseguenza, posso mettere davanti a loro qualsiasi cosa. Di conseguenza, sono anche quelli che imparano più facilmente.
Ecco alcune tecniche che funzionano meglio per me:
- Dividere e conquistare: tagliare il problema a metà ed eliminare sistematicamente le cause potenziali. Mentre per alcuni è più facile scalare sistematicamente la pila, io di solito ho successo saltando subito a ciò che posso escludere per primo. Questo è in contrasto con i consigli di altri? È possibile! Ma a me interessa di più quello che funziona per me.
- Monitoring e l'osservabilità sono vostri amici, così come gli errori: Metriche, log e tracce possono fornire una visione olistica del sistema e, meglio ancora, una visione olistica del problema! Prometheus e Grafana sono gli strumenti di fatto per il monitoraggio e sono di buon auspicio per la scelta degli strumenti di aggregazione dei log e di tracciamento. Nel mondo reale, tuttavia, non sempre si ha a disposizione uno stack di osservabilità completo: a volte il massimo che si può ottenere sono Prometheus e Grafana con alcuni target remoti da analizzare. Fortunatamente, nella maggior parte dei casi questo è ancora molto utile e, con o senza, i messaggi di errore devono essere trattati come amici! Certo, alcuni sono più utili di altri, ma si tratta comunque di un feedback del sistema che informa che qualcosa è andato storto.
- Ricreare il problema: per quanto possibile, ricreare il problema in un ambiente separato. In questo modo si possono ottenere numerose informazioni sulla causa, che aprono le porte alla soluzione. Ciò significa anche che si dispone di un ambiente di prova con il quale si può sperimentare in tutta sicurezza. Uno dei tanti motivi per cui è buona norma sfruttare la potenza dell'infrastruttura come codice (IaC) è la possibilità di ricreare o distruggere rapidamente questo ambiente, se necessario. Anche se questo significa scriverlo da soli, in situazioni in cui l'ambiente non è stato precedentemente codificato, dedicare un po' di tempo in più a questo aspetto può far risparmiare un sacco di tempo in seguito.
- Tenere un registro di risoluzione dei problemi: Forse conoscete il concetto di registro delle decisioni sull'architettura. Cosa vi impedisce di applicare un concetto simile alla risoluzione dei problemi? Niente! E non ha bisogno di alcuna formattazione o convenzione speciale. È sufficiente registrare le fasi di risoluzione dei problemi man mano che si procede. Questo può essere utile se avete bisogno di fare marcia indietro o di riaffermare le cose che avete già escluso. Inoltre, è possibile rivederlo in un secondo momento per documentare la soluzione e spiegare come ci si è arrivati. La capacità di articolare i passaggi e la logica che li sottende può lasciare tracce più durature nella vostra memoria. Inoltre, sarà utile a chiunque legga la vostra documentazione. Un buon candidato per questa documentazione è una piattaforma interna di knowledge-base, o anche un blog pubblico per insegnare agli altri.
Quando si affrontano problemi particolarmente difficili, abbracciare la risoluzione dei problemi come opportunità di apprendimento può portare a miglioramenti a lungo termine nelle capacità di risoluzione dei problemi e contribuire a migliorare il modo in cui si gestisce l'infrastruttura. I team che perfezionano e iterano i processi di debug si troveranno meglio equipaggiati per sfruttare le potenzialità di Kubernetes.
Utilizzo di tecnologie semplici e affidabili
L'ecosistema cloud native (e il panorama del cloud in generale) offre una pletora di strumenti e framework da cucire insieme. Le possibilità di costruzione sono pressoché infinite! Tuttavia, questa nozione può spesso portare ad alcune grandi insidie: troppi strumenti, troppa complessità e troppi debiti tecnici. Fortunatamente, questa è una trappola facile da evitare con un po' di disciplina e una mentalità: meno è meglio. La tecnologia migliore è quella più manutenibile e più stabile, e scoprirete che i vostri utenti tendono ad essere d'accordo. Se aveste bisogno di salire su una scala per salire sul tetto di una casa, non la vorreste così sovraingegnerizzata da farvi venire il dubbio che la stiate usando correttamente. Sarebbe spaventoso!
Non c'è orgoglio nel mantenere una base di codice così complicata che nessuno può leggerla. Non c'è medaglia d'oro o trofeo per aver costruito un sistema così complesso che quasi nessuno può usarlo. Vogliamo cose che funzionino, che siano stabili e che possiamo usare correttamente in modo affidabile senza accumulare altra fatica. La semplicità è la vostra amica. Inoltre, ricordate che un modello di progettazione cloud native è un modello che abbraccia il rapido cambiamento. L'architettura dell'applicazione diventerà naturalmente più complessa nel corso dell'evoluzione, quindi non è necessario forzare la mano. Con un approccio minimalista in aggiunta a un design cloud-native modulare, i team possono avere sistemi più snelli e sicuri e semplificare le distribuzioni, la manutenzione e la risoluzione dei problemi.
Inoltre, la semplicità contribuisce a ridurre il rischio di configurazioni errate che ostacolano le prestazioni e/o aumentano la superficie di attacco per le falle di sicurezza.
Kubernetes stesso è un'astrazione. Non potremmo chiamarlo "cloud native" se non lo fosse, ma tenere a bada la quantità di astrazioni non necessarie significa che gli ingegneri passano meno tempo a gestire la complessità sottostante e più tempo a concentrarsi sulla creazione di valore. Sono del parere che non sia un approccio "all you can eat", perché le innovazioni più avanzate che ho visto nel corso della mia carriera provengono da aziende che incarnano l'approccio della "dieta rigorosa": quelle che si sono concentrate sulla padronanza delle basi, in modo da poter costruire in modo sicuro e affidabile prodotti all'avanguardia che risolvono problemi molto complessi.
Continuare a padroneggiare Kubernetes
Una combinazione di esperienza pratica, una solida metodologia di risoluzione dei problemi e un approccio ponderato agli strumenti può rendere Kubernetes molto più facile da padroneggiare. Imparare facendo (piuttosto che leggendo) aiuta ad acquisire capacità di risoluzione dei problemi che sono fondamentali nelle operazioni del mondo reale. La risoluzione dei problemi non si limita a riparare ciò che è rotto, ma è un'opportunità per affinare la comprensione, migliorare la documentazione e sviluppare un approccio sistematico che renda più facile risolvere le sfide future. Inoltre, semplificare lo stack Kubernetes riducendo al minimo le astrazioni non necessarie riduce l'overhead cognitivo, rendendo più facile la gestione nel tempo.
Come molti professionisti esperti hanno imparato, un cluster snello e ben strutturato è più facile da mantenere e scalare rispetto a uno sovraccarico di strumenti che aggiungono complessità senza fornire chiari vantaggi. In definitiva, il successo con Kubernetes non consiste nell'utilizzare tutti i nuovi strumenti presenti sul mercato, ma nel sapere quali aggiungono un valore reale a lungo termine.
Se volete saperne di più su Kubernetes, ne parlo in modo più dettagliato nel podcast di KubeFM, che potete guardare su YouTube o qui sotto.
Commenti