Un’applicazione funziona. Poi arriva un aggiornamento, un server si guasta oppure più reparti richiedono maggiore capacità contemporaneamente. Kubernetes organizza dove vengono eseguiti i container e come ripristinare lo stato operativo concordato. Che questo renda l’applicazione più affidabile dipende dall’architettura nel suo insieme.
Pensiamo a un portale interno per gli ordini: il personale inserisce gli ordini, un’interfaccia li trasferisce al gestionale di magazzino e un processo in background crea i documenti. Questi compiti possono essere svolti da container separati. Chi li avvia singolarmente deve coordinare anche aggiornamenti, riavvii e assegnazione alle macchine. Qui entra in gioco l’orchestrazione.
Lo stato desiderato diventa la base dell’esercizio
In Kubernetes si può indicare, per esempio, che due istanze di un’applicazione web devono eseguire una determinata versione del software. La piattaforma confronta continuamente questo stato desiderato con quello effettivo. Un Deployment descrive la distribuzione dell’applicazione e utilizza un controller ReplicaSet per gestirne i Pod. Se manca un’istanza, il sistema di controllo cerca di predisporne una sostitutiva.
Questo è utile anche per gli aggiornamenti: una nuova versione può essere distribuita gradualmente. Risorse, comportamento all’avvio e strategia di aggiornamento devono consentirlo. Un rollout tecnicamente riuscito non dimostra che un ordine sia stato elaborato correttamente. Questa verifica rimane compito dell’applicazione e dei suoi test.
I termini principali spiegati attraverso il portale ordini
- Immagine del container
- La base confezionata per un’applicazione, con i file e i componenti runtime necessari. Da questa immagine vengono avviati i container eseguibili.
- Pod
- La più piccola unità distribuibile in Kubernetes. Di solito contiene un container applicativo; container strettamente correlati possono condividere un Pod e, tra le altre cose, il suo namespace di rete. Due copie dell’applicazione web corrispondono normalmente a due Pod.
- Nodo
- Una macchina che esegue i Pod. Un nodo può essere una macchina virtuale oppure un server fisico. Kubernetes può quindi affiancare un livello di virtualizzazione senza necessariamente sostituirlo.
- Cluster e piano di controllo
- Il cluster collega il sistema di controllo ai nodi che eseguono i workload. Il piano di controllo comprende server API, database dello stato, scheduler e controller. Sui nodi, kubelet e runtime per container si occupano dell’esecuzione.
- Service
- Un punto di accesso logico stabile per un gruppo di Pod. I loro indirizzi possono cambiare quando vengono sostituiti. Il Service separa l’accesso dalle singole istanze di breve durata.
Che cosa succede realmente in caso di guasto
Se un nodo si guasta, i Pod gestiti possono essere distribuiti nuovamente su altri nodi adatti. Occorrono rilevamento del guasto, capacità residua sufficiente e accesso ai dati necessari. Una seconda istanza sullo stesso host fisico non protegge dal guasto di quell’host. Anche più server nello stesso dominio elettrico o di rete possono condividere un punto di guasto.
Per il nostro portale ordini significa che l’interfaccia web può essere sostituita rapidamente. Un’attività documentale già avviata deve però essere progettata affinché la ripetizione non produca una fattura o un ordine duplicato. Le sessioni non devono andare perse in modo incontrollato quando viene sostituita un’istanza. Queste proprietà dipendono dall’architettura software e dai sistemi collegati.
Avere tre server, da solo, non costituisce quindi un piano di disponibilità. Controllo, applicazioni, rete, storage e capacità residua dopo un guasto devono essere valutati insieme. Vale anche nel cloud o con un servizio Kubernetes gestito: l’effettivo perimetro del servizio stabilisce quali responsabilità spettano al fornitore e quali rimangono all’azienda.
I dati persistenti richiedono un piano dedicato
I Pod sono sostituibili. I dati aziendali non devono quindi esistere soltanto nel filesystem scrivibile di un container. Kubernetes può collegare storage persistente mediante Persistent Volume e le relative richieste, chiamate Persistent Volume Claim. Una StorageClass descrive come rendere disponibile uno storage adatto.
Questi oggetti non rendono automaticamente resiliente lo storage sottostante. Un disco locale rimane legato alla propria infrastruttura; un servizio di storage esterno ha caratteristiche proprie di prestazioni e guasto. Anche un database esterno al cluster può essere la soluzione corretta. Sono determinanti il supporto dell’applicazione, la coerenza dei dati, i percorsi di accesso e il processo di ripristino concordato.
Per il portale definiamo quindi separatamente per quanto tempo possa essere indisponibile, quale perdita di dati sia accettabile e come verificare il ripristino. Un cluster che replica correttamente una cancellazione accidentale su tutte le istanze non sostituisce un backup. Approfondisci backup e ripristino.
Quando conviene l’architettura aggiuntiva
Kubernetes diventa interessante quando più applicazioni vengono aggiornate regolarmente, servono deployment ripetibili oppure occorre assegnare in modo mirato workload e macchine disponibili. Introduce però anche attività per aggiornamenti della piattaforma, gestione degli accessi, rete, storage e monitoraggio.
Per una singola applicazione stabile può essere economicamente più adatto un server ben mantenuto con Docker Compose oppure una macchina virtuale convenzionale. La scelta dovrebbe partire dal comportamento operativo richiesto: quali interruzioni sono ammissibili? Quanto spesso cambiano le cose? Chi sa comprendere l’ambiente e ripristinarlo in caso di problema?
Un progetto pilota utile ha obiettivi verificabili
- Provare un processo aziendale rappresentativo con volumi di dati realistici e senza dati produttivi dei clienti.
- Simulare un aggiornamento, compreso il percorso di ritorno previsto. Valutare separatamente le modifiche allo schema del database.
- Provare in condizioni controllate il guasto di un’istanza e di un componente infrastrutturale previsto.
- Ripristinare un backup in un ambiente di test separato e aprire i dati per verificarne l’utilizzabilità aziendale.
- Assegnare responsabilità precise per segnalazioni, manutenzione della piattaforma e applicazione.
DAXS aiuta a valutare l’applicazione e a scegliere un’infrastruttura adatta occupandosi inoltre dell’implementazione e dell’esercizio concordato. Una prima valutazione con un caso d’uso concreto e criteri di accettazione chiari è un punto di partenza pratico.
Fonti: Kubernetes: ruolo e limiti della piattaforma · Componenti del cluster · Pod e relativo ciclo di vita · Deployment e aggiornamenti · Service · Storage persistente · Pianificare gli ambienti di produzione
