La Container Storage Interface permette a Kubernetes di operare con un’ampia varietà di storage ma, prima di poterla utilizzare, è fondamentale capire esattamente perché e come implementarla.
Gli amministratori possono utilizzare la Container Storage Interface (CSI) con i PV (Persistent Volume) di Kubernetes, con i PVC (Persistent Volume Claim) e con le classi di archiviazione (Storage Classe), e i suoi driver funzionano anche con altri strumenti di orchestrazione di container diversi da Kubernetes.
Principali utilizzi della Container Storage Interface in Kubernetes
La Container Storage Interface viene principalmente impiegata per permette ai fornitori di storage di esporre i loro prodotti alle applicazioni containerizzate come storage persistente. Grazie a questa interfaccia, Kubernetes può collegarsi con qualsiasi storage per cui risulti disponibile un driver che, risiedendo al di fuori del codice Kubernetes, è in grado di renderlo più stabile e affidabile. E’ uno dei motivi principali per cui oggi il vecchio sistema dei plugin è stato sostituito dai driver CSI.
Perché preferire una CSI ai plugin in-tree
È la semplicità il principale vantaggio della Container Storage Interface. Prima che Kubernetes rendesse l’interfaccia disponibile nella versione 1.13, lo storage era esposto attraverso plugin “in-tree” integrati direttamente nei componenti di Kubernetes ma il loro utilizzo presentava almeno tre grandi sfide.
Prima di tutto se un fornitore desiderava far funzionare il suo storage con Kubernetes si ritrovava a dover gestire vari passaggi burocratici per integrare il suo plugin con il software Kubernetes. In secondo luogo, non era affatto semplice correggere i bug o implementare miglioramenti sui loro plugin essendo essi stessi parte del codice principale di Kubernetes. Terza e più importante criticità, quella relativa a eventuali plugin scritti male, in grado potenzialmente di destabilizzare l’intera piattaforma Kubernetes.
Ora, al posto di questi plug “in-tree”, i fornitori di storage possono utilizzare un’API per creare un driver Container Storage Interface che permetta al loro hardware di lavorare con Kubernetes. In questo modo non hanno più il problema di cercare di ottenere il supporto di Kubernetes per l’integrazione e possono creare driver di interfaccia in qualsiasi momento, offrendone anche nuove versioni.
Le migliori modalità di implementazione di una CSI
Ogni driver CSI può essere stato creato in modo diverso dagli altri e può potenzialmente contenere dei bug, per questo è essenziale testarli uno a uno accuratamente prima di utilizzarli in un ambiente di produzione.
I driver includono diversi sottocomponenti tra cui il Container Storage Interface Controller che indica a Kubernetes come eseguire varie funzioni ad un basso livello. Il controller, ad esempio, potrebbe includere istruzioni specifiche dell’hardware per effettuare il provisioning di un volume, per attribuirne uno ad un nodo Kubernetes o per crearne uno snapshot. Kubernetes, a sua volta, sarà in grado di eseguire solo le funzioni a livello hardware identificate all’interno del controller. E’ possibile che la prima versione del driver includa solo funzionalità di base mentre le successive ne conterranno di aggiuntive: saranno i test a identificare quelle mancanti.
Nell’implementare una CSI è importante anche utilizzare solo versioni aggiornate del suo driver, tenendo conto che i vendor di hardware ne forniscono alcune ma la community in seguito ne può sviluppare delle altre. I siti web che ospitano progetti di sviluppo della community spesso riportano la versione attualmente stabile del codice, ma spesso rendono disponibili anche una o più versioni pre-release che potrebbero però contenere bug significativi. Meglio non usarle mai in ambienti di produzione, anche se offrono funzionalità aggiuntive.
