Skip to content

Cos’è esattamente Kubernetes?

Cos’è esattamente Kubernetes?

Impariamo tutti i segreti che riguardano questo mondo fantastico. In questo articolo voglio raccontarvi attraverso la mia esperienza cos’è Kubernetes e perché è importante inserirlo nel paniere delle soluzioni quando parte un progetto.

Come ho conosciuto Kubernetes

Ho scoperto Docker e Kubernetes nella calda primavera del 2018, ovviamente nel peggiore dei modi. Stava partendo un grosso progetto che volevamo realizzare in cloud ed il nostro CTO ha optato per la soluzione Kubernetes. Come tutti gli sviluppatori che hanno iniziato questo mestiere venti anni fa, avevo sempre lavorato con macchine virtuali e la mia conoscenza sui container era limitata al comando “docker run”. 

Fortunatamente non mi stanco mai di imparare, quindi mi sono buttato a capofitto dentro questa nuova avventura. La prima cosa che ho capito è che dovevo imparare docker per bene. E già questo passaggio è stato fondamentale per capire che non avevo di fronte una nuova tecnologia, ma una vera e propria rivoluzione nel processo di sviluppo. Grazie a Docker ero riuscito a lavorare in ambiente locale con la stessa configurazione di produzione e questo mi ha veramente illuminato.

Col senno di poi, chissà quanti problemi avrei evitato lavorando direttamente così. Se poi pensiamo che tutta la configurazione del singolo container (consideriamola una macchina virtuale per semplificare) sta su un unico file di configurazione… è davvero una svolta epocale. In pratica ero riuscito ad astrarre e sistematizzare tutta una serie di configurazioni manuali e procedure difficili da replicare che mi portavano via tanto tempo. Fantastico!

Il passaggio successivo verso Kubernetes è stato ancora più profondo. Da un lato mi sono trovato stordito dalla miriade di attenzioni da porre nella configurazione, ma quando ho capito che semplicemente compilando dei files avrei potuto descrivere e manutenere un intera infrastruttura IT il paragone con la vecchia architettura basata solo su macchine virtuali non ha retto più il confronto. Se poi ci mettiamo anche che la parte di DevOps si è semplificata enormemente, capiamo perché sono qui a raccontarvi della mia esperienza.

Cos’è Docker

Prima di parlare di kubernetes, dobbiamo velocemente soffermarci su cosa è docker: docker è una soluzione che rende possibile “containerizzare” le applicazioni. Per containerizzare si intende la possibilità di creare dei contenitori (idealmente macchine virtuali) sulle quali fare girare la nostra applicazione. Questa soluzione funziona indipendentemente dal sistema operativo, quindi può essere utilizzata su windows, linux e mac.

Docker può essere installato gratuitamente anche sulla propria macchina locale. E’ basato su un hypervisor che fornisce una virtualizzazione della macchina non-nativa. Per esempio, su windows, attraverso l’hypervisor Hyper-V, docker può utilizzare una macchina virtuale linux per poter ospitare container con sistema operativo linux. Questo vuol dire che tutte le parti del codice sorgente possono essere portate su vari sistemi operativi, e molti dei problemi tecnici possono essere risolti attraverso il processo di scrittura del software.

Cos’è Kubernetes

Ho già parlato molto bene a proposito dei containers e spero sia chiaro che sono un buon supporto per eseguire la nostra applicazione. Di solito in un ambiente di produzione abbiamo molti requisiti, prima di tutto, si desidera fare il deploy senza downtime o scalare quando aumenta il carico.

Partendo dalle cose semplici, nel momento in cui voglio sostituire un container con la versione nuova desidero che, quando il vecchio container va giù, un altro riparta contemporaneamente. Tutti questi obiettivi vengono gratis con Kubernetes. Dobbiamo pensare a Kubernetes come ad un framework che esegue in modo elastico i sistemi distribuiti. Si occupa dei requisiti di scalabilità, di failover, dei modelli di distribuzione, e altro ancora. 

Le caratteristiche che Kubernetes fornisce sono:

  • Service discovery and load balancing: Kubernetes fornisce l’ “ingress controller”, un componente  estendibile che può essere gestito da diversi componenti aggiuntivi, in sostanza, espone i container della rete usando il DNS o l’indirizzo IP. Questo è importante perché se il traffico è elevato, Kubernetes lo bilancerà e lo distribuirà. Inoltre, questo può implementare il meccanismo da HTTPS a HTTP, in questo modo i container interni possono comunicare in HTTP senza preoccuparsi dei certificati di trasporto all’interno di ogni container. Se si vuole, si può anche eseguire una sorta di riscrittura dell’URL per ospitare più applicazioni in un singolo dominio, ovvero si può avere una single page application angular su www.mysite.com e un’applicazione REST API su  www.mysite.com/api/.
  • Storage orchestration: se vi ricordate come funzionano i volumi in un container docker, il concetto è lo stesso ma un po’ più evoluto. Si può collegare lo storage al cluster di Kubernetes, poi basta richiamare i volumi dai container. La cosa interessante è che a questo punto il volume è astratto: potrà essere un disco o una qualsiasi risorsa esterna di storage. 
  • Automated rollouts and rollbacks: si può automatizzare la creazione dei containers semplicemente aggiungendo alcuni file YAML. Si può descrivere come la piattaforma deve essere distribuita e come interagisce con i containers.
  • Automatic bin packing: alla fine anche Kubernetes ha bisogno di risorse fisiche per funzionare. Questo significa che si ha ancora bisogno di inserire CPU, RAM e disco per permettere al container di funzionare. La buona notizia è che per ogni container si può specificare la quantità di risorse richieste. Questo aiuterà Kubernetes a prendere delle decisioni migliori riguardo alla scalabilità dei servizi.
  • Self-healing: Kubernetes è la babysitter dei container. Si prende cura di tutto. Se un container fallisce, cerca di rimpiazzarlo. Se un container non risponde, lo interrompe e così via.
  • Secret and configuration management: un altra cosa bella a proposito di Kubernetes è che è possibile disaccoppiare la configurazione dai containers. È qualcosa come le variabili di ambiente di Docker, ma più potente. Ogni configurazione può essere gestita globalmente ed è legata a uno o più container. Inoltre, alcune variabili, chiamate “secrets” vengono criptate per garantire la sicurezza. Questo è molto utile per le informazioni sensibili, come le password, i token di autenticazione o le chiavi ssh.
Cosa non è Kubernetes

Kubernetes è un sacco di cose, spero di essere stato chiaro nell’esporre tutti i suoi benefici. Il problema principale dell’uso di Kubernetes è dovuto al fatto che non è un sistema PaaS (Platform as a Service) come era supposto.

Kubernetes è un sacco di cose ma non è un servizio “all included”. È un ottimo strumento, perché riduce la quantità di lavoro, specialmente per l’amministratore di sistema, ma non offre nulla a parte l’infrastruttura.

La maggior parte delle cose che si cercano in un sistema completamente gestito sono: i deployment semplificati, la scalabilità, il bilanciamento del carico, il logging, e il monitoraggio. Di solito, si ottiene una configurazione standard dall’hosting ma teoricamente se si vuole si può anche personalizzarla.

I limiti di Kubernetes:

  • Non c’è un limite sui tipi di applicazioni supportate. Tutto viene scritto nel container così che ogni sua applicazione, indipendentemente dalla tecnologia, può essere eseguita. La controparte è che si può ancora definire il container a mano.
  • Non offre un deployment automatico. Ma è possibile caricare gli artefatti derivati dalla build all’intero di una immagine binaria sul repository pubblico di docker, cosi da averla disponibile durante la fase di pubblicazione (DevOps). Questo procedimento è abbastanza semplice se si ha già lavorato ad un progetto con la Continuous Integration, Delivery, e Deployment (CI/CD), altrimenti è difficile comprenderlo.
  • Non fornisce alcun servizio a livello di applicazione, ma solo di infrastrutture. Se si ha bisogno di un database, si deve comprare un servizio o eseguirlo in un container dedicato. Ovviamente tenendo il controllo dei backup e così via.
  • La maggior parte delle interazioni con il sistema avvengono da linea di comando, che espone tutte le API di kubernates. Questo è ottimo perché permette di automatizzare ogni settaggio. La sintassi dei comandi è molto semplice, ma se si cerca un sistema che è gestito pienamente da una UI allora si sta cercando nel posto sbagliato.
Come funziona Kubernetes

Iniziamo a vedere un po’ più a fondo la parte tecnica. Questo non è il momento per fare una panoramica completa dei componenti e non voglio spaccare il capello in quattro. Il mio intento è quello di descrivere i componenti più importanti e fare chiarezza su tutto quello che verrà spiegato nell’articolo. Certamente, se state pianificando di imparare Kubernetes da soli, allora è importante iniziare a sapere come muoversi.

Pods

Pensate ad un Pod come ad un’astrazione ad alto livello di un container. In questa astrazione, il pod può essere un’istanza di un singolo container o di un gruppo. Un Pod è formato da uno o più containers che condividono le risorse e sono disponibili nella macchina virtuale. Ad ogni pod è assegnato un unico indirizzo IP, ciò significa che un pod può comunicare con gli altri pod come un semplice container in un ambiente docker. Ogni container dentro al pod può raggiungere tutti gli altri pod in una rete virtuale, ma non può raggiungere un altro container in un altro pod.

Questo è importante per garantire l’astrazione del pod: nessuno deve sapere come sono composti internamente i pod. Inoltre, l’IP assegnato è volatile in questo modo si è obbligati ad usare sempre il nome del servizio (risolto direttamente nell’IP giusto). Come anche nei docker container, un pod può definire i volumi che possono essere comparati con le unità di rete condivise. Questo è utile per la conservazione dei dati o per condivisione dei file tra i pod.  

I Pod si possono gestire tramite il client, utilizzando le API di kubernates, come già detto, oppure scrivendo dei comandi dalla shell.

Services

Il nome “service” in informatica viene utilizzato in modo eccessivo. Nell’ambito di Kubernetes si può pensare ad un service come qualcosa che vuoi servire. Un service di Kubernetes implica un insieme di pod e può offrire una funzionalità complessa o esporre un singolo pod con un singolo container. Quindi si può avere un service che fornisce una funzionalità CMS, con un database e un web server all’interno, oppure due services distinti, uno per il database e uno per il web server. Questo dipende da cosa si vuole fare.

Ingress controller

Il service è il componente che si può esporre all’esterno. Per fare questo c’è bisogno di un ingress controller che fa qualcosa di simile ad un bilanciatore di carico, ovvero inoltra virtualmente il traffico dall’esterno ai servizi. Durante questo passaggio, in base all’implementazione di ingresso scelta, è possibile aggiungere la crittografia HTTPS, instradare il traffico in base all’hostname o all’URL. Il servizio può essere collegato all’ingress controller, non ai pods.

Volumes

Lo storage del pod di default è volatile, perchè insiste nel pod stesso, ciò significa che al primo restart si perderà tutto. I volumes di Kubernetes consentono di mappare una parte del disco rigido dei containers in un luogo sicuro, il quale può essere condiviso tra i containers. Il punto di montaggio può essere qualsiasi parte del  filesystem del container, ma un volume non può essere montato in un altro volume interno al container stesso.

Namespaces

Si pensi al namespace come alla funzionalità che rende Kubernetes multitenant. Il namespace è il livello del tenant. Ogni namespace può partizionare le risorse per isolare i servizi, gli ingress e molte altre cose. Questa funzionalità è utile per avere una giusta separazione tra le applicazioni, ovvero delegare in modo sicuro a team diversi e avere ambienti separati in una singola infrastruttura.

Secrets and configurations

La configurazione può essere effettuata a livello globale tramite mappe di configurazione. Questo meccanismo funziona nel seguente modo. Prima di tutto, con il fatto che si possono avere uno o più config inventory, si devono collegare le variabili di ambiente del container alla variabile globale. I vantaggi sono evidenti, infatti se una variabile cambia, la si deve cambiare una volta sola. Inoltre, per quanto riguarda le informazioni sensibili, esiste un buon metodo chiamato “secrets”. Le variabili segrete vengono salvate criptate in un sistema a cui nessuno può far accesso. Infine, i secrets sono inviati solamente ai pods che lo richiedono.

Kubernetes come un servizio

Come tutti i non-amministratori di sistema, odio indossare il cappello da amministratore di sistema. O meglio… tutto è divertente fino a quando le cose non si rompono. Forse sto esagerando, o questa è solo invidia, ma dobbiamo rispettare la sacralità del fatto che non è giusto fare il lavoro degli altri. Oggi ci sono così tanti servizi che ti danno Kubernetes gratis che risulta stupido non usarli. Non stiamo parlando della marmellata fatta in casa, questo è un programma. 

Se potete, imparate dai migliori. Google, Amazon, Microsoft, IBM… tutti questi hanno i loro servizi Kubernetes e tutto funziona con lo stesso modello di prezzo: indipendentemente dal cloud che deciderai di usare, il servizio Kubernetes sarà gratis, pagherai solo per le risorse che userai.

Molti venditori ti danno una periodo gratis di prova con credito, in questo modo è semplice iniziare ad utilizzarlo. Ho scelto Azure per questo articolo per alcune semplificazioni durante l’integrazione del codice sorgente, avendo questo sulla stesso cloud, ma la maggior parte delle cose che imparerete in questa serie di articoli potrete applicarla a qualsiasi altra situazione. Un altro concetto importante che riguarda Kubernetes come servizio è che non richiede che l’applicazione sia accoppiata con il cloud.

Poiché l’applicazione è solo un container grezzo ed è organizzata in alcuni file di configurazione conformi con Kubernetes, sarai in grado di passare da Azure a Google e viceversa senza problemi (per lo meno senza cambiare il codice sorgente).

Quindi, il servizio di Kubernetes è gratis e si paga solamente l’hardware, ovvero la macchina virtuale usata da Kubernetes.

Cosa portare a casa

Kubernetes è un’ottima piattaforma per uscire sani e salvi dallo scudo della macchina virtuale e passare al cloud. È un sistema che porta dinamismo, riduce i costi dell’amministratore del sistema e alza il livello di qualità del servizio, il quale sarebbe difficile da garantire senza. Molti problemi ricorrenti come il networking e la protezione dei dati possono essere superati dalla configurazione avanzata di Kubernetes stesso.

Non posso dire che Kubernetes sia la scelta giusta per tutti i progetti ma credetemi se vi dico che dovete prenderlo in considerazione per tutti i vostri futuri progetti.

Riferimenti

Quest’articolo è bastato sul lavoro del collega Daniele Fontani che mi ha ispirato e che potete trovare  in questi articoli: 

Altre pagine utili:

 

CONTATTACI PER AVERE MAGGIORI INFORMAZIONI

 

Questo articolo è stato utile
Siamo felicissimi di questo 🙂
Grazie per il tuo feedback!
Siamo veramente dispiaciuti 🙁
Grazie per il tuo feedback!