Kubernetes: architetture a microservizi

In questo articolo parleremo di Kubernetes, delle sue caratteristiche principali e di una delle architetture applicative più utilizzate su questo strumento. Diamo un’occhiata alla ragione per cui Kubernetes è così utile facendo un piccolo salto indietro nel tempo.

L'era del deployment tradizionale

All’inizio, le organizzazioni eseguivano applicazioni su server fisici. Non c’era modo di definire i limiti delle risorse per le applicazioni in un server fisico e questo ha causato non pochi problemi di allocazione delle risorse.

Ad esempio, se più applicazioni vengono eseguite sullo stesso server fisico, si possono verificare casi in cui un’applicazione assorbe la maggior parte delle risorse e, di conseguenza, le altre applicazioni non forniscono le prestazioni attese.

Una soluzione sarebbe quella di eseguire ogni applicazione su un server fisico diverso, ma questa non è affatto una soluzione ideale. Dal momento che le risorse vengono sottoutilizzate, inoltre, questa pratica risulta essere costosa per le organizzazioni, le quali si troverebbero a mantenere numerosi server fisici.

A4 2

L'era del deployment virtualizzato

A5 5

Come soluzione venne introdotta la virtualizzazione.

Essa consente di eseguire più macchine virtuali (VM) su una singola CPU fisica. La virtualizzazione consente di isolare le applicazioni in più macchine virtuali e fornisce un livello di sicurezza superiore, dal momento che le informazioni di un’applicazione non sono liberamente accessibili da un’altra applicazione.

La virtualizzazione consente un migliore utilizzo delle risorse riducendo i costi per l’hardware, permette una migliore scalabilità, dato che un’applicazione può essere aggiunta o aggiornata facilmente, e ha molti altri vantaggi.

Ogni VM è una macchina completa che esegue tutti i componenti, compreso il proprio sistema operativo, sopra all’hardware virtualizzato.

L'era del deployment in container

I container sono simili alle macchine virtuali, ma presentano un modello di isolamento più leggero, condividendo il sistema operativo (OS) tra le applicazioni. Pertanto, i container sono considerati più leggeri. Analogamente a una macchina virtuale, un container dispone di una segregazione di filesystem, CPU, memoria, PID e altro ancora. Poiché sono disaccoppiati dall’infrastruttura sottostante, risultano portabili tra differenti cloud e diverse distribuzioni.

BKG to remove

Caratteristiche di un ambiente “Containerizzato”

Il termine “Containerizzato” è un’espressione puramente italiana per indicare un’infrastruttura informatica basata su containers, quindi differente rispetto ad ambienti più tradizionali come server fisici (bare-metal) o macchine virtuali (VMs).

I container sono diventati popolari grazie ai molteplici vantaggi che offrono, ad esempio:

  • Creazione e distribuzione di applicazioni in modalità Agile: maggiore facilità ed efficienza nella creazione di immagini container rispetto all’uso di immagini VM.
  • Adozione di pratiche per lo sviluppo/test/rilascio continuativo: consente la frequente creazione e la distribuzione di container image affidabili, dando la possibilità di fare rollback rapidi e semplici (grazie all’immutabilità dell’immagine stessa).
  • Separazione delle fasi di Dev e Ops: le container image vengono prodotte al momento della compilazione dell’applicativo piuttosto che nel momento del rilascio, permettendo così di disaccoppiare le applicazioni dall’infrastruttura sottostante.
  • L’osservabilità non riguarda solo le informazioni e le metriche del sistema operativo, ma anche lo stato di salute e altri segnali dalle applicazioni.
  • Coerenza di ambiente tra sviluppo, test e produzione: i container funzionano allo stesso modo su un computer portatile come nel cloud.
  • Portabilità tra cloud e sistemi operativi differenti: lo stesso container funziona su Ubuntu, RHEL, CoreOS, on-premise, nei più grandi cloud pubblici e da qualsiasi altra parte.
  • Gestione incentrata sulle applicazioni: Aumenta il livello di astrazione dall’esecuzione di un sistema operativo su hardware virtualizzato all’esecuzione di un’applicazione su un sistema operativo utilizzando risorse logiche.
  • Microservizi liberamente combinabili, distribuiti, ad alta scalabilità: le applicazioni sono suddivise in pezzi più piccoli e indipendenti che possono essere distribuite e gestite dinamicamente – niente stack monolitici che girano su una singola grande macchina.
  • Isolamento delle risorse: le prestazioni delle applicazioni sono prevedibili.
  • Utilizzo delle risorse: alta efficienza e densità.

Caratteristiche principali di Kubernetes

In questo paragrafo andiamo ad evidenziare le principali caratteristiche che il nostro caro amico Kubernetes porta sul piatto. Kubernetes ti fornisce:

  • Discovery dei servizi e bilanciamento del carico: Kubernetes può esporre un container usando un nome DNS o il suo indirizzo IP. Se il traffico verso un container è alto, Kubernetes è in grado di distribuire il traffico su più container in modo che il servizio rimanga stabile.
  • Orchestrazione dello storage Kubernetes: ti permette di montare automaticamente un sistema di archiviazione di vostra scelta, come per esempio storage locale, dischi forniti da cloud pubblici, e altro ancora.
  • Rollout e rollback automatizzati: Puoi utilizzare Kubernetes per descrivere lo stato desiderato per i propri container, e Kubernetes si occuperà di cambiare lo stato attuale per raggiungere quello desiderato ad una velocità controllata. Per esempio, puoi automatizzare Kubernetes per creare nuovi container per il tuo servizio, rimuovere i container esistenti e adattare le loro risorse a quelle richieste dal nuovo container.
  • Ottimizzazione dei carichi: Fornisci a Kubernetes un cluster di nodi per eseguire i container. Puoi istruire Kubernetes su quanta CPU e memoria (RAM) ha bisogno ogni singolo container. Kubernetes allocherà i container sui nodi per massimizzare l’uso delle risorse a disposizione.
  • Self-healing: Kubernetes riavvia i container che si bloccano, sostituisce container, termina i container che non rispondono agli health checks, e evita di far arrivare traffico ai container che non sono ancora pronti per rispondere correttamente.
  • Gestione di informazioni sensibili e delle configurazioni:  Kubernetes consente di memorizzare e gestire informazioni sensibili, come le password, i token OAuth e le chiavi SSH. Puoi distribuire e aggiornare le informazioni sensibili e la configurazione dell’applicazione senza dover ricostruire le immagini dei container e senza svelare le informazioni sensibili nella configurazione del tuo sistema.

Architettura a microservizi

Nelle architetture monolitiche tutti i processi sono strettamente collegati tra loro e vengono eseguiti come un singolo servizio. Ciò significa che se un processo dell’applicazione sperimenta un picco nella richiesta, è necessario ridimensionare l’intera architettura. Aggiungere o migliorare una funzionalità dell’applicazione monolitica diventa più complesso, in quanto sarà necessario aumentare la base di codice. Tale complessità limita la sperimentazione e rende più difficile implementare nuove idee. Le architetture monolitiche rappresentano un ulteriore rischio per la disponibilità dell’applicazione, poiché la presenza di numerosi processi dipendenti e strettamente collegati aumenta l’impatto di un errore in un singolo processo.

Monolite vs microservizi 1

Con un’architettura basata su microservizi, un’applicazione è realizzata da componenti indipendenti che eseguono ciascun processo applicativo come un servizio. Tali servizi comunicano attraverso un’interfaccia ben definita che utilizza API leggere. I servizi sono realizzati per le funzioni aziendali e ogni servizio esegue una sola funzione. Poiché eseguito in modo indipendente, ciascun servizio può essere aggiornato, distribuito e ridimensionato per rispondere alla richiesta di funzioni specifiche di un’applicazione.

Caratteristiche e vantaggi dei microservizi

Caratteristiche:

  • Autonomi: ogni microservizio ha un suo ciclo di vita del software; è scritto in un linguaggio di programmazione che può tranquillamente differire da altri microservizi. E’ come se fosse un mini-applicativo che fa parte, però, di un ecosistema più grande.
  • Specializzati: ogni microservizio è progettato per fornire delle specifiche funzioni all’interno dell’architettura applicativa. Infatti, l’applicazione finale sarà l’insieme di 2 o più microservizi.

Vantaggi:

  • Agilità: gli sviluppatori lavorano sul singolo microservizio in un contesto molto ridotto proprio perché il microservizio rappresenta una piccola parte (che fornisce determinate funzionalità) dell’applicazione finale. Questo riduce notevolmente i tempi di sviluppo, garantendo maggiore flessibilità e indipendenza al team.
  • Scalabilità: ogni microservizio è indipendente ed fornisce determinate funzionalità applicative, e può essere ridimensionato manualmente o automaticamente da Kubernetes in base alle proprie esigenze.
  • Codice riutilizzabile: Dividendo l’applicazione finale in più parti, ci sono più probabilità di scriveri moduli e pezzi di codice che possono essere riutilizzati per altri scopi o per altre applicazioni.
  • Resilienza: Grazie all’indipendenza dei microservizi, si ha un alto livello di resilienza. In caso di errori in un determinato microservizio vengono meno solo determinate funzionalità esposte dal microservizio in questione e non l’intero applicativo.
  • Semplicità di distruzione: grazie all’integrazione di tool CI/CD, è possibile agevolare notevolmente il processo di test o messa in produzione di aggiornamenti su determinati microservizi.

Non ci sono reali svantaggi, ma come ogni cosa… nulla è perfetto. Bisogna fare particolare attenzione ad alcuni dettagli quando decidiamo di lavorare con un’architettura a microservizi:

  • se nelle altre architetture era buona norma automatizzare la fase di build e deploy, in un architettura a microservizi diventa un requisito obbligatorio se non volete far impazzire il team di operation (ex sistemisti)
  • Poiché ogni servizio gira su processo separato, sono necessari strumenti di monitoraggio e gestione  per ciascun processo.

La comunicazione inter process tra i microservizi del tuo software influisce negativamente sulle prestazioni del tuo software e sul carico della rete. Meccanismi di caching diventano fondamentali per  migliorare le prestazioni.

Conclusione e considerazioni

Valutate bene quindi che strada prendere in base, anche, a quello che è stato affrontato in questo articolo.

Se arrivate alla conclusione che le architetture a microservizi sono quello che stavate cercando….allora Kubernetes è l’orchestratore di containers che fa al caso vostro.

Kubernetes Everywhere

Condividi l’articolo!!


Scopri i nostri corsi!

Formazione Cloud-Native in presenza o da remoto
Picture of Francesco Grimaldi

Francesco Grimaldi

VMware Certified Instructor | Kubernetes Instructor | DAI | LFAI | SCI | CKA + CKAD
Team Leader, docente e consulente IT su tecnologie verticalizzate al mondo datacenter e Cloud-Native, attento ai dettagli, cerco di essere il più preciso possibile e non mi fermo finché non risolvo il problema.
Nel 2022 ho ricevuto da VMware il premio come “VMware Instructor of Excellence” in tutta EMEA. Quando spiego mi piace essere chiaro e diretto, senza dare nulla per scontato. Adoro trasmettere le mie conoscenze ad altri!

Find me on Linkedin