5 tipi di volumi Kubernetes e come lavorare con essi

Cosa sono i volumi Kubernetes?

Un volume Kubernetes è una directory contenente dati, a cui possono accedere i container in un pod Kubernetes. La posizione della directory, il supporto di storage che la ospita e il suo contenuto dipendono dal tipo specifico di volume utilizzato.

I processi in esecuzione all'interno dei container in un pod visualizzano una vista del file system composta da:

• Un file system root che corrisponde al contenuto dell'immagine del container.
• Volumi montati sul container (se definito). Ogni volume viene montato su un percorso specifico all'interno del file system del container.

I volumi sono definiti nel campo .spec.containers[*].volumeMounts del modello di pod. Per ogni pod e per ogni immagine container all'interno del pod, è necessario specificare quali volumi verranno montati e su quali percorsi (i percorsi possono essere diversi per ogni container).

Esistono alcuni tipi di volumi in Kubernetes. I più importanti sono i volumi temporanei, che vengono archiviati localmente sul nodo Kubernetes e vengono eliminati al riavvio di un pod, e volumi persistenti Kubernetes (PV) che conservano i dati anche dopo l'arresto di un pod.

In questo articolo:

• Tipi di volumi Kubernetes
  • Volumi persistenti
  • Volumi effimeri
  • Volumi EmptyDir
  • Volumi Kubernetes hostPath
  • Volumi Kubernetes ConfigMap
• Plugin per l'archiviazione di volumi Kubernetes
  • NFS
  • CSI
• Cosa sono i volumeMounts di Kubernetes?
• Creazione di un volume Kubernetes distribuendo pod
• Gestione dei volumi Kubernetes con NetApp Cloud Volumes ONTAP

5 tipi di volumi Kubernetes

Kubernetes supporta vari volumi, consentendo a ogni pod di utilizzare diversi tipi di volume contemporaneamente. I volumi effimeri sono legati al ciclo di vita del pod, mentre i volumi persistenti possono persistere oltre il ciclo di vita del pod. Ciò significa che Kubernetes distrugge i volumi effimeri una volta che il loro pod non esiste più, mantenendo i dati dei volumi persistenti.

Volumi persistenti

Kubernetes fornisce un sottosistema PersistentVolume con un'API che astrae il provisioning dello storage e il consumo. Funziona con due risorse API—PersistentVolume (PV) e PersistentVolumeClaim (PVC).

PersistentVolume (PV)
Un PV è una risorsa di storage situata nel cluster. Gli amministratori possono eseguire il provisioning manuale dei PV e Kubernetes può utilizzare le classi di storage per eseguire il provisioning dinamico dei PV. Come i volumi, i PV sono plugin, ma il loro ciclo di vita è indipendente da qualsiasi pod che utilizza il PV.

Un PV funziona come un oggetto API che acquisisce i dettagli dell'implementazione dello storage, inclusi iSCSI, NFS e i sistemi di storage dei cloud provider. Funziona in modo simile a un nodo, ma offre risorse di storage anziché di calcolo.

PersistentVolumeClaim (PVC)
Un PVC è una richiesta di storage effettuata da un utente. Funziona in modo simile a un pod ma consuma risorse PV anziché risorse di nodo. Un PVC può richiedere risorse di storage specifiche, specificando modalità di accesso come ReadWriteOnce, ReadWriteMany e ReadOnlyMany.

I PVC consentono agli utenti di consumare risorse di storage astratte, ma gli utenti in genere necessitano di PV con proprietà variabili per problemi diversi. Questo è il motivo per cui gli amministratori di cluster devono spesso offrire PV variabili che differiscono non solo per dimensioni e modalità di accesso. Possono farlo senza esporre gli utenti ai dettagli di implementazione tramite risorse StorageClass.

Contenuto correlato: Leggi la nostra guida a Kubernetes PVC

Volumi effimeri

I volumi temporanei non memorizzano i dati in modo persistente tra i riavvii. Questi volumi sono legati alla durata del pod, il che significa che vengono creati ed eliminati insieme al pod. Consente di arrestare e riavviare i pod senza limitarli alla disponibilità di volume persistente.

I volumi temporanei sono semplici da implementare e gestire. Puoi specificarli inline nella pod spec. I volumi temporanei sono ideali per le applicazioni che non richiedono storage persistente, come i servizi di caching.

Volumi EmptyDir

Un volume emptyDir viene creato quando Kubernetes assegna un pod a un nodo. La durata di questo volume è legata al ciclo di vita di un pod esistente su quel nodo specifico. Un volume emptyDir viene ricreato quando i container si riavviano o si arrestano in modo anomalo. Tuttavia, i dati in questo volume vengono eliminati e persi quando il pod viene rimosso dal nodo, si arresta in modo anomalo o muore.

Dopo aver creato un volume emptyDir, puoi dichiarare il nome del tipo di volume come campo nel file manifesto del pod. Viene visualizzato nella sezione delle proprietà del volume con parentesi graffe{} come valore. I volumi EmptyDir sono adatti principalmente per l'archiviazione temporanea dei dati. Ad esempio, puoi usarlo per uno spazio temporaneo, come una fusione basata su disco.

È possibile archiviare i volumi emptyDir sul supporto che sostiene il nodo. Ad esempio, puoi utilizzare storage di rete o SSD. In alternativa, puoi impostare "memory" nel campo emptyDir.medium e Kubernetes monterà un file system supportato da RAM (tmpfs). Nota che Kubernetes cancella tmpfs al riavvio del nodo.

Volumi Kubernetes hostPath

Un volume hostPath monta una directory o un file dal filesystem del nodo host nel tuo pod.

Di seguito sono riportati i principali casi d'utilizzo per i volumi hostPath:

• Utilizzare /var/lib/dockerhostPath—per eseguire un container che richiede l'accesso agli elementi interni di Docker.
• Usa un /sys hostPath—per eseguire cAdvisor in un container.
• Consentire a un pod di specificare un hostPath—per definire se un determinato hostPath deve esistere prima che il pod inizi a funzionare e se deve essere creato.
• Specificare un tipo per un volume hostPath—è possibile impostarlo in aggiunta alla proprietà path richiesta.

HostPath volumes sicurezza
HostPath volumes comportano molti rischi per la sicurezza. Evita di utilizzarli ogni volta che è possibile. Se devi utilizzare un HostPath volume, dovresti limitarlo solo alla directory o al file richiesto e montarlo come ReadOnly.

Ecco i principali rischi per la sicurezza:

• Credenziali esposte—HostPaths possono esporre credenziali di sistema privilegiate o API privilegiate. Gli autori delle minacce possono usarlo per attaccare altre parti del cluster o per sfuggire ai container.
• Privilegi root—tutte le directory o i file creati sugli host sottostanti sono scrivibili solo da root. Se vuoi scrivere su un volume hostPath, devi modificare i permessi dei file sull'host o eseguire il processo come root all'interno di un container privilegiato.

È possibile utilizzare AdmissionPolicy per limitare l'accesso HostPath a determinate directory. Tuttavia, il criterio è efficace solo se si richiede a volumeMounts di utilizzare montaggi readOnly.

Volumi Kubernetes ConfigMap

Un ConfigMap consente di inserire dati di configurazione nei pod. I dati archiviati all'interno di un ConfigMap possono essere referenziati in un volume di tipo configMap e quindi utilizzati dalle applicazioni containerizzate che vengono eseguite in un pod. È necessario fornire il nome del ConfigMap nel volume quando si fa riferimento a un ConfigMap. Kubernetes consente di personalizzare il percorso per una voce specifica nel ConfigMap.

Plugin per l'archiviazione dei volumi Kubernetes

Kubernetes fornisce diversi plug-in di storage che forniscono accesso ai dispositivi di storage distribuiti in un cluster Kubernetes. Questi sono implementati utilizzando l'oggetto StorageClass.

Alcuni dei principali plug-in attualmente supportati da Kubernetes sono GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS e iSCSI. Per ulteriori dettagli su questi plug-in, consulta la documentazione StorageClass.

Esaminiamo due notevoli plugin di storage in modo più dettagliato.

NFS

Network File System (NFS) è un protocollo standard per il montaggio di dispositivi di archiviazione come unità locali. Kubernetes consente di montare un volume NFS come unità locale in un container. Poiché il codice legacy accede spesso ai dati tramite NFS, questo plugin è molto utile per migrare i carichi di lavoro legacy su Kubernetes.

Esistono due modi per accedere ai dati tramite NFS e Kubernetes:

• Volumi NFS effimeri—possono essere collegati allo storage NFS esistente.
• PersistentVolumes con NFS— consente di configurare risorse gestite su un cluster a cui si accede tramite NFS.

CSI

La Container Storage Interface (CSI) è un'interfaccia standard che consente agli orchestratori di container di esporre i sistemi di storage ai container che gestiscono. CSI consente ai fornitori di storage di creare plugin che sono “out of tree”, il che significa che non devono essere archiviati nel repository di codice Kubernetes e non vengono forniti con Kubernetes.

Esistono molti plug-in out of tree basati su CSI che sono offerti direttamente dai fornitori di storage. L'avvento di CSI ha reso molto più facile per le tecnologie di storage supportare Kubernetes.

Contenuto correlato: Leggi la nostra guida a Container Storage Interface

Cosa sono i volumeMounts di Kubernetes?

Ci sono due passaggi coinvolti nella creazione di un volume e nel renderlo accessibile a un pod:

• Dichiarandolo nella proprietà spec:volumes del modello di pod e quindi distribuendo il pod su alcuni nodi
• Montaggio del volume su un container specifico utilizzando la proprietà spec:containers::volumeMounts

Questi passaggi vanno di pari passo. Quando si crea un volume, è necessario anche montarlo in un container e non è possibile montare un volume senza dichiararlo nel pod template.

Ecco un esempio che mostra sia la creazione che il montaggio di un volume in una configurazione YAML del template di pod:

spec: containers: —name: my-app image: nginx volumeMounts: —name: my-volume mountPath: /app/config volumes: —name: my-volume 

In questo codice:

• volumes (in basso) crea un volume denominato my-volume e lo collega al pod
• volumeMounts definisce come il volume viene montato, incluso il percorso del file tramite il quale il volume sarà disponibile dall'interno del container
• È essenziale che lo stesso nome di volume venga utilizzato in entrambe le posizioni: la dichiarazione del volume e la proprietà volumeMounts.

Creazione di un volume Kubernetes distribuendo pod

Per creare un volume Kubernetes, distribuisci uno o più pod che dichiarano il volume. Un modo comune per farlo è tramite un oggetto Deployment. Ecco un esempio di manifesto Deployment che fa quanto segue:

• Implementa tre pod, ciascuno con un container NGINX
• Dichiara un volume emptyDir
• Monta il volume su ciascuno dei tre container alla radice

apiVersion: apps/v1 kind: Deployment metadata: name: pods-with-volumes spec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: —name: my-container image: nginx:1.14.2 volumeMounts: —mountPath: / name: my-volume volumes: —name: my-volume emptyDir: {} 

Si noti che il nome di questa Deployment è definito in pods-with-volumes—questo è il modo in cui ci si riferisce ad essa nell'ambiente Kubernetes.

Come abbiamo visto nella sezione precedente, questo oggetto Deployment esegue le due azioni necessarie per creare un volume:

• La proprietà spec:template:volumes dichiara il volume.
• La proprietà spec:containers::volumeMounts monta il volume nei container.

Supponiamo che questo file YAML sia salvato con il nome my-deployment.yaml. Puoi creare il Deployment nel tuo cluster Kubernetes usando questo comando:

kubectl apply -f my-deployment.yaml

Per verificare che la Deployment sia in esecuzione correttamente con i volumi previsti, eseguire questo comando:

kubectl describe pods pods-with-volumes

Se tutto ha funzionato correttamente, l'output mostrerà che ogni pod ha un container chiamato my-container con il punto di montaggio richiesto:

Mounts: / da my-volume (rw)

L'output mostrerà anche il volume in esecuzione sotto ogni pod:

Volumi: my-volume: Tipo: EmptyDir (una directory temporanea che condivide la durata di un pod)

Gestione dei volumi Kubernetes con NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, la soluzione leader nella gestione dello storage enterprise, fornisce 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 per i carichi di lavoro containerizzati.

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.