Cos'è lo storage persistente per container?

Essenziali per lo sviluppo di applicazioni cloud-native, i container sono unità software leggere e portatili che impacchettano un'applicazione e le sue dipendenze, rendendoli semplici da distribuire nell'infrastruttura IT moderna.

I container sono intrinsecamente effimeri. Sono pensati per essere temporanei, avviabili e disattivabili secondo necessità. Sebbene questa flessibilità li renda estremamente flessibili e scalabili, tutti i dati del container generati vengono persi quando il container smette di funzionare. Lo storage persistente risolve questo problema mantenendo i dati disponibili indipendentemente da qualsiasi singolo container.

Senza lo storage persistente, i sistemi critici fallirebbero. Ad esempio, il database delle transazioni di una banca in esecuzione in container perderebbe i saldi dei conti dei clienti durante gli aggiornamenti di routine o una piattaforma di e-commerce perderebbe i carrelli della spesa a ogni riavvio.

Man mano che le organizzazioni continuano a orientarsi verso architetture di microservizi e cloud-native, i container sono diventati centrali per la distribuzione e la gestione delle app, rendendo lo storage persistente per container essenziale per eseguire applicazioni stateful su larga scala. Secondo un recente rapporto di Strategic Market Research, nel 2024 il mercato globale dei container di applicazioni è stato valutato a circa 2,1 miliardi di dollari. Si prevede che raggiungerà i 6,9 miliardi di dollari entro il 2030, con un tasso di crescita annuo composto (CAGR) del 21,1%.¹

Negli ambienti aziendali, lo storage persistente si presenta sotto forma di file storage, block storage e object storage, ciascuno adatto a workload differenti. Le organizzazioni tipicamente forniscono queste soluzioni di storage attraverso una combinazione di sistemi hardware e piattaforme di Software-Defined Storage (SDS) progettate per supportare ambienti hybrid cloud e cloud distribuiti.

La containerizzazione consiste nel confezionare codice software utilizzando solo le librerie e le dipendenze del sistema operativo (OS) – tipicamente basate su Linux – necessarie per farlo funzionare. Questo processo crea una singola unità leggera, come un container, che può essere eseguita in modo coerente su qualsiasi infrastruttura.

Con il passaggio delle organizzazioni dalle macchine virtuali (VM) ai container, la necessità di gestire workload containerizzati su larga scala è cresciuta. Docker, introdotto nel 2013, ha reso i container ampiamente accessibili offrendo agli sviluppatori un metodo standardizzato per crearli e condividerli. Ma orchestrare centinaia o migliaia di container in ambienti multicloud ibridi richiede un modo per gestire la complessità. Pertanto, Kubernetes è stato sviluppato per automatizzare la distribuzione, la scalabilità e la gestione delle applicazioni containerizzate.

Creato da Google nel 2014, Kubernetes è una piattaforma open source mantenuta dalla Cloud Native Computing Foundation (CNCF). I principali provider di cloud come AWS, Microsoft Azure, Google Cloud e IBM Cloud supportano la piattaforma.

Kubernetes gestisce container in pod, che vengono distribuiti tra i nodi in un cluster Kubernetes. Gestisce la configurazione e la comunicazione tra i componenti tramite application programming interface (API), supportando l'orchestrazione automatizzata tra diversi sistemi. Oggi, Kubernetes è lo standard de facto per l'orchestrazione dei container.

In relazione al data storage, un aspetto importante del funzionamento di Kubernetes è la comprensione della distinzione tra applicazioni stateless e stateful. Le applicazioni stateless (ad esempio, i server web che gestiscono le richieste API) gestiscono ogni richiesta in modo indipendente. Di conseguenza, non conservano i dati tra le sessioni. Al contrario, le applicazioni stateful (ad esempio, i database) conservano i dati e dipendono dalle informazioni delle interazioni precedenti per funzionare correttamente.

Inoltre, i container e i pod in Kubernetes sono effimeri e possono essere interrotti, riavviati o riprogrammati in qualsiasi momento. Per le applicazioni stateless, questo comportamento non è un problema. Tuttavia, nelle applicazioni stateful, quando un container si ferma, qualsiasi dato memorizzato al suo interno viene perso. È qui che lo storage persistente gioca un ruolo essenziale nelle impostazioni containerizzate, separando i dati dal ciclo di vita del container.

Oltre alle applicazioni tradizionali che passano ai container, i workload ad alta intensità di dati come database, intelligenza artificiale (AI) e machine learning (ML) sono sempre più basati sul cloud. Questi workload richiedono uno storage persistente per garantire che i dati sopravvivano alla terminazione del container, mantengano lo stato all'interno dei sistemi distribuiti e forniscano le prestazioni ad alto rendimento e bassa latenza richieste dall'addestramento dei modelli.

Lo storage persistente per container è basato su un set di componenti che lavorano insieme per separare i dati dai container. In Kubernetes, gli amministratori configurano l'infrastruttura di storage, mentre gli sviluppatori e le applicazioni vi accedono attraverso semplici richieste.

Questi componenti sono:

• Volumi e bind mount
• PersistentVolume (PV)
• PersistentVolumeClaim (PVC)
• Classi di storage
• Container Storage Interface (CSI)

Ci sono due modi principali per collegare lo storage ai container: bind mount e volumi nominati (ad esempio, volumi Docker).

• I bind mount collegano un file o una directory specifici della macchina host direttamente a un container.

• I volumi acquisiscono flessibilità perché Kubernetes li gestisce tra diversi storage.

Un volume è una posizione di storage accessibile ai container in un pod. A differenza dello storage effimero all'interno di un container, che scompare quando il container si ferma, un volume persiste per tutta la vita del pod. Ciò significa che se un contenitore fallisce e si riavvia all'interno dello stesso pod, i dati nel volume rimangono disponibili.

I volumi possono connettersi a diversi tipi di dispositivi di storage, inclusi dischi locali, network-attached storage tramite protocolli come Network File System (NFS) o servizi di storage basato su cloud.

Un PersistentVolume fornisce storage all'interno del cluster e viene creato manualmente o automaticamente.

La differenza fondamentale tra un volume normale e un PersistentVolume è la durata della vita. Un PersistentVolume esiste indipendentemente da qualsiasi pod. Questa impostazione significa che lo storage persiste anche se il pod che vi accede viene cancellato o spostato su un'altra macchina.

I PersistentVolume hanno un proprio ciclo di vita separato dai pod che li utilizzano. Gli amministratori possono configurarli con capacità di storage specifica, permessi di accesso di lettura/scrittura (ad esempio, ReadWriteOnce per l'accesso a singolo pod o ReadWriteMany per l'accesso condiviso).

Una PersistentVolumeClaim è una richiesta di storage effettuata da un'applicazione o da un utente. Anziché connettersi direttamente a un PersistentVolume, un pod utilizza un PersistentVolumeClaim come livello intermedio. La richiesta specifica la capacità di storage e la modalità di accesso richieste. Kubernetes la associa quindi a un PersistentVolume disponibile. Questa separazione significa che gli sviluppatori possono richiedere lo storage senza dover comprendere l'infrastruttura di storage sottostante.

Quando una richiesta è collegata a un PersistentVolume, il pod può leggere e scrivere dati proprio come farebbe con qualsiasi file system. Se il pod viene spostato o riavviato, può comunque accedere alla stessa richiesta e agli stessi dati persistenti.

Negli ambienti aziendali, creare manualmente volumi di storage per ogni applicazione diventa complesso e ingestibile. Kubernetes risolve questa sfida tramite StorageClass, che definiscono diversi tipi di storage (ad esempio, solid-state drive ad alte prestazioni) e utilizzano un provisioner per creare automaticamente volumi dati su richiesta.

Quando un'applicazione richiede lo storage e fa riferimento a una StorageClass, Kubernetes fornisce il volume appropriato senza necessità di configurazione manuale. Questa funzione semplifica la gestione complessiva dello storage.

La Container Storage Interface (CSI) è un'API standardizzata e indipendente dal fornitore che consente a Kubernetes di interagire con vari sistemi di storage.

La CSI consente alle piattaforme dei provider di storage (ad esempio, IBM Storage Fusion, NetApp) di sviluppare e aggiornare i propri plug-in in modo indipendente. Questi plug-in gestiscono l'intero ciclo di vita dello storage: creazione, collegamento, provisioning e rimozione dei volumi secondo le necessità.

Lo storage persistente per container consente alle organizzazioni di eseguire applicazioni con stato in ambienti container, offrendo i seguenti benefici:

• Durabilità e resilienza dei dati: i dati scritti su ogni volume persistente sopravvivono ai guasti, ai riavvii e alla riprogrammazione dei container, prevenendo la perdita di dati e garantendo che le applicazioni stateful rimangano resilienti anche se l'infrastruttura dei container sottostante cambia.

• Operazioni semplificate: il provisioning dinamico e la gestione automatizzata dello storage riducono il workload manuale. I team della piattaforma definiscono le politiche di storage una sola volta, permettendo alle applicazioni di consumare lo storage come risorsa self-service all'interno del loro namespace.

• Alte prestazioni e scalabilità: lo storage persistente per container offre la capacità di throughput, bassa latenza e scalabilità necessarie per workload ad alta intensità di dati, come l'addestramento di AI/ML e i real-time analytics.

• Flessibilità e portabilità: i volumi persistenti di Kubernetes e i driver CSI astraggono lo storage, consentendo alle organizzazioni di eseguire applicazioni su infrastrutture on-premise, ambienti di cloud privato e cloud pubblico, supportando strategie di hybrid cloud.

• Sicurezza e conformità: i volumi persistenti supportati da sistemi di storage aziendali offrono funzionalità di protezione dei dati, tra cui crittografia, replica e backup, necessarie per soddisfare i requisiti normativi e di conformità.

• Efficienza dei costi: il provisioning dinamico aumenta o diminuisce lo storage in base alla domanda, mentre il tiering automatizzato dei dati sposta i dati utilizzati di rado verso livelli di storage convenienti, aiutando le organizzazioni a ottimizzare i costi.

• Accesso condiviso: lo storage persistente per container consente a più pod di leggere e scrivere contemporaneamente gli stessi dati, supportando workflow collaborativi senza duplicare le risorse di storage.

Le organizzazioni possono accedere allo storage persistente per container attraverso una gamma di strumenti e soluzioni:

• Piattaforme di orchestrazione dei container
• Soluzioni di storage aziendali
• Provider di cloud pubblico 

Le piattaforme di orchestrazione dei container (ad esempio, Red Hat OpenShift) forniscono una gestione integrata dello storage persistente con supporto integrato per i driver CSI e il provisioning dinamico dello storage.

Queste piattaforme semplificano la distribuzione e le operazioni per le organizzazioni che eseguono workload containerizzati su larga scala.

Le piattaforme di storage aziendali (ad esempio, IBM Storage Fusion) offrono soluzioni di storage container-native con servizi dati avanzati, inclusi snapshot, clonazione, replicazione e disaster recovery.

Queste piattaforme si integrano direttamente con Kubernetes tramite driver CSI, fornendo sicurezza, funzionalità di conformità e controlli di accesso condivisi per applicazioni stateful.

I fornitori di cloud pubblico, tra cui AWS, Microsoft Azure, Google Cloud e IBM Cloud, offrono servizi Kubernetes gestiti con opzioni native di storage persistente, come Amazon Elastic Block Store (EBS) e IBM Cloud Block Storage.

Lo storage persistente per container supporta i seguenti casi d'uso aziendali:

• Database e gestione dei dati
• Workload AI
• DevOps e CI/CD
• Backup e disaster recovery (BDR)