Kubernetes CSI: nozioni di base sui volumi CSI e come creare un driver CSI

Che cos'è Kubernetes CSI?

Kubernetes CSI è un'implementazione specifica di Kubernetes della Container Storage Interface (CSI). La specifica CSI fornisce uno standard che abilita la connettività tra sistemi storage e piattaforme di orchestrazione dei container (CO). È la base della gestione dello storage Kubernetes.

Lo standard CSI determina come blocchi arbitrari e sistemi di file storage vengono esposti ai carichi di lavoro su sistemi di containerizzazione come Kubernetes. I vendor di storage di terze parti possono utilizzare CSI per creare plugin e implementarli per consentire a Kubernetes di funzionare con nuovi sistemi di storage, senza dover modificare il codice principale di Kubernetes.

In questo articolo:

• La necessità di CSI
• Come utilizzare un volume CSI?
  • Provisioning dinamico
  • Provisioning manuale
  • Collegamento e montaggio dei volumi
• Creazione di un proprio driver CSI per Kubernetes
  • Implementazione
  • Abilitazione dei pod privilegiati
  • Abilitazione della propagazione del mount
• Storage Kubernetes con NetApp Cloud Volumes ONTAP

La necessità di CSI

Prima della Container Storage Interface, Kubernetes supportava solo l'utilizzo di plugin di volume k8s in-tree, che dovevano essere scritti e implementati utilizzando i binari principali di Kubernetes. Ciò significava che i provider di storage dovevano inserire nel core codebase dei loro plugin k8s il supporto per nuovi sistemi storage.

Flex-volume, una soluzione basata su plug-in, ha tentato di risolvere questo problema esponendo l'API basata su eseguibili a plug-in di terze parti. Mentre questa soluzione funzionava secondo un principio simile a CSI in termini di distacco dai binari k8s, c'erano una serie di problemi con questo approccio. In primo luogo, richiedeva access root al file system master e host per abilitare la distribuzione dei file driver. In secondo luogo, comportava un carico significativo di dipendenze e prerequisiti del sistema operativo che si presumeva fossero disponibili dall'host.

CSI affronta tali problemi utilizzando la containerizzazione e sfruttando le primitive di storage k8s. CSI è diventata la soluzione onnipresente per abilitare l'uso di plug-in di storage out-of-tree. Consente ai provider di storage di distribuire plug-in tramite primitive k8s standard come classi di storage, PersistentVolumes (PV) e PersistentVolumeClaims (PVC).

L'obiettivo principale di CSI è standardizzare il meccanismo per esporre tutti i tipi di storage system su ogni orchestrator di container.

Contenuto correlato: Leggi la nostra guida a Kubernetes Persistent Volumes

Come utilizzare un volume CSI?

È possibile utilizzare un volume CSI per eseguire il provisioning delle risorse PersistentVolume, che possono essere consumate dai carichi di lavoro Kubernetes. È possibile eseguire il provisioning delle PersistentVolumes in modo dinamico (quando vengono richieste da un carico di lavoro) o manualmente.

Provisioning dinamico

È possibile creare un StorageClass che fa riferimento a un plug-in di storage CSI. Ciò consente ai carichi di lavoro Kubernetes di creare dinamicamente PersistentVolumes. I dati salvati in tali PersistentVolumes vengono conservati nell'apparecchiatura di storage definita nel plug-in CSI.

Ad esempio, il seguente StorageClass abilita il provisioning di volumi di storage di tipo "fast-storage", utilizzando un plugin CSI chiamato "csi-driver.example.com". (Questo e gli altri esempi seguenti sono stati condivisi nel post del blog ufficiale Kubernetes CSI )

Quando un'entità Kubernetes crea un oggetto PersistentVolumeClaim che richiede questo StorageClass, un PersistentVolume appartenente allo StorageClass viene eseguito il provisioning in modo dinamico. L'immagine seguente contiene un esempio di un PVC che fa riferimento allo StorageClass fast-storage.

Si noti che nella definizione di StorageClass sopra sono presenti tre parametri: type e due segreti chiamati mysecret e mynamespace. Quando il PVC viene dichiarato, ecco cosa succede dietro le quinte:

1. La StorageClass esegue una chiamata CreateVolume sul plug-in CSI (csi-driver.example.com), passando i parametri, inclusi i segreti, che consentono l'accesso al dispositivo di storage.
2. Kubernetes crea automaticamente un oggetto PersistentVolume, che rappresenta un volume di storage fisicamente archiviato sul dispositivo CSI plugin.
3. Kubernetes associa l'oggetto PersistentVolume (PV) al relativo PersistentVolumeClaim (PVC).
4. Da questo punto in poi, i pod o i container che hanno effettuato la richiesta possono utilizzare il volume di storage.

Leggi il nostro post del blog: Provisioning dinamico dei volumi persistenti di Kubernetes con NetApp Trident e Cloud Volumes ONTAP

Provisioning manuale

Puoi eseguire manualmente il provisioning di un volume in Kubernetes e renderlo disponibile ai carichi di lavoro senza utilizzare il meccanismo PVC. L'immagine seguente fornisce un esempio di oggetto PV che consente ai carichi di lavoro di utilizzare un volume di storage chiamato “existingVolumeName”. Come sopra, il volume CSI fa riferimento al storage plugin csi-driver.example.com.

Collegamento e montaggio dei volumi

L'immagine seguente fornisce un esempio che mostra come un template di pod Kubernetes può fare riferimento a un PVC per accedere a un volume CSI.

Quando un PersistenVolumeClaim appare nel modello di pod, ogni volta che il pod viene pianificato, Kubernetes attiva diverse operazioni sul plug-in CSI, tra cui ControllerPublishVolume, NodeStageVolume e NodePublishVolume. Questo crea un volume di storage, lo monta e lo rende disponibile per l'uso da parte dei container in esecuzione nel pod.

Creazione del proprio driver CSI per Kubernetes

Componenti del driver CSI

I driver CSI in Kubernetes sono generalmente distribuiti con componenti controller e per nodo.

Componente controller
Il plug-in del controller viene distribuito come Deployment o come StatefulSet e può essere montato su qualsiasi nodo all'interno del cluster. Comprende un driver CSI che implementa un servizio CSI Controller e anche un container sidecar (o più container). Un container sidecar del controller di solito interagisce con oggetti Kubernetes ed effettua anche chiamate al servizio CSI Controller.

Il controller non richiede l'accesso diretto a un host: può eseguire tutte le operazioni tramite servizi del control-plane esterni e l'API Kubernetes. È possibile distribuire più copie di un componente controller per l'alta disponibilità (HA), ma è necessario implementare l'elezione del leader per assicurarsi che solo un controller sia attivo in un dato momento.

Tra i sidecar del controller ci sono un external-provisioner, un external-attacher, un external-snapshotter e un external-resizer. L'inclusione di alcuni sidecar in una distribuzione può essere facoltativa, a seconda delle specifiche dettagliate nella pagina sidecar.

Il controller comunica con i container sidecar che hanno il compito di gestire gli eventi Kubernetes. Il controller invia quindi le chiamate pertinenti al driver CSI. Un socket di dominio UNIX viene condiviso tramite un emptyDir volume, abilitando le chiamate tra sidecar e il driver.

I sidecar dei controller usano regole di controllo degli accessi in base al ruolo (RBAC) per governare la loro interazione con gli oggetti Kubernetes. I repository dei sidecar forniscono esempi di configurazioni RBAC che puoi incorporare nelle tue policy RBAC.

Componente per nodo
Il plug-in del nodo deve essere distribuito in tutti i nodi di un cluster, tramite un DaemonSet. Comprende il driver CSI che implementa il servizio nodo CSI e il container sidecar che funge da registrar del driver di nodo.

Il componente nodo comunica con il kubelet, che viene eseguito in tutti i nodi e gestisce le chiamate per il servizio CSI Node. Le chiamate possono montare o smontare volumi di storage da un sistema storage e renderli disponibili per il pod da utilizzare. Il kubelet usa un socket di dominio UNIX, che è condiviso tramite un volume HostPath sull'host, per effettuare chiamate al driver CSI. Un ulteriore socket di dominio UNIX viene utilizzato dal node-driver-registrar per registrare il driver nel kubelet.

Il plug-in del nodo richiede l'accesso diretto a un host per montare i volumi driver. Per rendere disponibili i mount del file system e i dispositivi di blocco al kubelet, il driver CSI deve usare un punto di mount bidirezionale che consenta al kubelet di vedere i mount creati dal container del driver.

Implementazione

Kubernetes non determina la creazione di pacchetti di un driver di volume CSI, ma fornisce raccomandazioni per semplificare la distribuzione di driver CSI containerizzati su Kubernetes.

Si consiglia ai vendor di storage di eseguire i seguenti passaggi quando distribuiscono un driver di volume CSI containerizzato:

• Creare un container per implementare il comportamento del volume plugin ed esporre un'interfaccia gRPC tramite un socket di dominio UNIX. Il container deve essere etichettato come “CSI volume driver” e configurato secondo le specifiche CSI (con controller, node e identity services).
• Raggruppa il container del driver del volume con container aggiuntivi forniti dal team di Kubernetes, come external-attacher, external-provisioner, cluster-driver-registrar, node-driver-registrar, external-resizer, external-snapshotter e livenessprobe. Questi container facilitano l'interazione del container driver con Kubernetes.
• Indirizzare gli amministratori del cluster a implementare i relativi DaemonSet e StatefulSet e ad aggiungere il supporto per il sistema storage del vendor nel cluster Kubernetes.

Un'altra opzione per una potenziale implementazione più semplice consiste nell'avere tutti i componenti in un unico DaemonSet, inclusi l'external-provisioner e l'external-attacher. Tuttavia, questa strategia consuma più risorse e richiede l'uso di un protocollo di elezione del leader (come https://git.k8s.io/contrib/election) per i componenti external-attacher ed external-provisioner.

Abilitazione dei pod privilegiati

Il cluster Kubernetes deve abilitare i pod con privilegi per consentire l'utilizzo dei driver CSI. Ad esempio, è necessario impostare il flag --allow-privileged su true per il kubelet e l'API server—in alcuni ambienti, come kubeadm, GCE e GKE, questa è l'impostazione predefinita.

Il server API deve essere avviato con i seguenti flag privilegiati:

$ ./kube-apiserver ... --allow-privileged=true ... $ ./kubelet ... --allow-privileged=true ...

Abilitazione della propagazione del montaggio

La Container Storage Interface richiede una funzionalità di propagazione del montaggio che consente la condivisione dei volumi montati tra container all'interno dello stesso nodo o pod. Il daemon Docker per un cluster deve consentire la condivisione del montaggio per abilitare la propagazione del montaggio.

Kubernetes CSI con NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, la soluzione leader nella gestione dello storage enterprise, offre servizi di gestione dello storage sicuri e comprovati su AWS, Azure e Google Cloud. La capacità di Cloud Volumes ONTAP può scalare nell'ordine dei petabyte e supporta vari casi d'utilizzo come file services, database, DevOps o qualsiasi altro carico di lavoro aziendale, con un solido set di funzionalità tra cui high availability, data protection, storage efficiencies, integrazione con Kubernetes e altro ancora.

In particolare, Cloud Volumes ONTAP supporta il provisioning e la gestione dei volumi persistenti di Kubernetes richiesti dai carichi di lavoro containerizzati.

Scopri di più su Kubernetes NFS Provisioning File Services con Cloud Volumes ONTAP e Trident.

Scopri di più su come Cloud Volumes ONTAP aiuta ad affrontare le sfide delle applicazioni containerizzate in questi Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.