Secondo lo studio effettuato nel 2020 da CNCF (Cloud Native Computing Foundation), l'implementazione di Kubernetes è cresciuta dal 78% all'83% lo scorso anno, segnando un incremento nell'uso della containerizzazione del 300% dal 2016. Gartner asserisce che entro il 2022, oltre il 75% delle organizzazioni a livello mondiale utilizzerà applicazioni containerizzate in produzione, una percentuale decisamente superiore rispetto all’attuale 30%.
Si prospetta quindi uno scenario applicativo dove l’utilizzo di Kubernetes sarà sempre più diffuso, in virtù di una serie di vantaggi: ad esempio, la gestione automatizzata dei container in ambienti ibridi e Multi Cloud; l’ottimizzazione delle risorse hardware sottostanti; la possibilità di scalare rapidamente le applicazioni.
POTREBBE INTERESSARTI ANCHE: Perché e come creare applicazioni Cloud Native
Tuttavia, optare per l’orchestratore open source richiede competenze specifiche e un percorso di implementazione strutturato, così da evitare possibili inefficienze. Nell'articolo prenderemo in esame 3 errori piuttosto comuni in cui si incappa adottando Kubernetes.
Secondo l’approccio DevOps, la Continuous Integration (CI) è un metodo che permette di integrare in una build e testare molto frequentemente le modifiche al codice sorgente apportate dai diversi team. L'obiettivo è individuare e correggere tempestivamente gli errori attraverso un rapido ciclo di feedback.
La Continuous Delivery (CD) invece consente di accelerare il rilascio del codice che ha superato il processo CI e successive verifiche, all’interno di un repository centrale, costruendo artefatti production-ready. Il Continuous Deployment è il passo finale, perché automatizza l’implementazione delle app in produzione, attingendo dalla codebase convalidata del repository.
La pipeline CI/CD, insomma, è un processo che permette al team di sviluppo di accelerare le operazioni di modifica, test e release del software, ma richiede competenze specifiche per una corretta esecuzione e controllo. Fortunatamente ci sono molti tool che aiutano i team in questo senso; ecco alcuni esempi: Github Actions, GitLab, Jenkins, Travis, Helm, CircleCI.
Kubernetes permette di automatizzare la gestione dei container, dispensando i team DevOps dalle attività di orchestrazione più ripetitive e a rischio di errore manuale. La complessità è, tuttavia, il rovescio della medaglia degli ambienti containerizzati e l’automazione di Kubernetes toglie al team DevOps la visibilità sui processi. Senza avere maturato conoscenze specializzate sui processi CI/CD e implementato una pipeline efficace, potrebbe diventare molto difficile intervenire manualmente con aggiornamenti e hotfix delle applicazioni.
Implementando Kubernetes, il primo errore importante è quindi riconducibile alla scarsa preparazione sulle pipeline di CI/CD.
Il secondo errore invece riguarda una sottostima delle problematiche legate alla sicurezza. Oggi negli ambienti Kubernetes girano tantissime applicazioni, anche mission-critical, e la tendenza è in crescita. Fondamentale quindi è proteggere le applicazioni implementando una strategia a prova di futuro, che tenga conto di alcuni aspetti fondamentali.
Un errore comune è trascurare l’impostazione del controllo d’accesso basato sui ruoli (RBAC), una funzionalità che permette di definire le policy di utilizzo delle risorse all’interno di ambienti Kubernetes, rendendole disponibili solo a determinati utenti e se strettamente necessario.
Un altro sbaglio è non proteggere adeguatamente le infrastrutture sottostanti. Kubernetes distribuisce dinamicamente i container sui nodi del cluster, occupandosi solamente di allocare i pod fino a quando ci sono risorse disponibili e non prevede strumenti di sicurezza per l’hardware che ospita le applicazioni.
Inoltre Kubernetes non dispone di funzionalità per la messa in sicurezza dei runtime applicativi che girano nei Pod, dunque è importante prestare molta attenzione ad eventuali falle di sicurezza che potrebbero poi far escalation fino all’host. Per ovviare in parte a questi problemi è possibile intervenire usando le Network Policies API ed implementare le policy OPA a livello applicativo.
In caso si decida di delegare l’implementazione, la gestione e la manutenzione dei cluster Kubernetes a terzi, all’interno di un’offerta di Managed Services, un’errore sarebbe non valutare le garanzie di sicurezza fornite, nonché trascurare la protezione dei nodi (le macchine virtuali o fisiche che compongono i cluster) e del sistema master che li controlla.
L’automazione è sempre stata vista come uno strumento per recuperare efficienza operativa e quindi tagliare sui costi. Tuttavia, quando si affronta un progetto per l’adozione di Kubernetes bisognerebbe fare attenzione anche alle successive spese di manutenzione. La piattaforma di orchestrazione ha infatti il merito di nascondere molta complessità, dettagli tecnici e operazioni di gestione delle applicazioni, ma non elimina di fatto le attività di aggiornamento, monitoraggio e provisioning dei nodi che rimangono in capo al team IT.
L’infrastruttura Kubernetes necessita quindi di una manutenzione costante, che ricade solitamente in mano al team di Operations con un surplus di lavoro.
Inoltre, passare a Kubernetes spesso significa dovere affrontare un processo di modernizzazione delle applicazioni. In alcuni casi, infatti, le applicazioni legacy possono essere incorporate all’interno dei container e utilizzate sul Cloud senza necessità di apportare grandi modifiche, ma in altre situazioni si rende necessaria la modernizzazione attraverso le più recenti tecniche di sviluppo perché le applicazioni possano performare al meglio nei nuovi ambienti. Ovviamente il processo richiede tempo, risorse e ulteriori investimenti.
Esistono diversi tool utili per monitorare i costi, come ad esempio:
Insomma, Kubernetes è un potente strumento di efficienza e risparmio, perché automatizza e ottimizza la gestione dei container in ambienti ibridi e multi cloud. Tuttavia, la sua implementazione, configurazione e manutenzione non è sempre facile e richiede competenze specifiche.
Il consiglio principale è di valutare tutti gli aspetti collaterali che ruotano attorno all’adozione di Kubernetes. Innanzitutto bisogna assicurarsi di avere una chiara conoscenza delle pratiche DevOps perché la pipeline CI/CD non venga compromessa ma favorita attraverso l’orchestrazione automatizzata di Kubernetes.
Inoltre, è necessario tenere sempre saldo il controllo sulle infrastrutture sottostanti le applicazioni e andare a coprire tutti gli aspetti di sicurezza che Kubernetes lascia scoperti. Partire da una configurazione puntuale delle funzionalità della piattaforma può rappresentare un ottimo punto di partenza.
Infine, il Total Cost of Ownership, che consideri i costi di manutenzione dell’infrastruttura Kubernetes e di un’eventuale modernizzazione applicativa, deve essere un punto ben chiaro prima di partire con l’adozione. Sarebbe utile iniziare con piccole implementazioni su un numero di applicazioni circoscritto per valutare l’effettiva convenienza di Kubernetes per la propria azienda.
Affidarsi a un partner esperto è ovviamente un consiglio di partenza sempre valido per ottenere i massimi ritorni e ridurre le complicazioni durante il passaggio a Kubernetes.