Volume in Kubernetes

La persistenza è una problematica estremamente centrale in ogni tipo di applicazione e per quelle basate su reti di container esistono alcuni punti che meritano particolare attenzione. In Kubernetes, esistono diverse soluzioni in questo ambito ed un loro studio prende piede tipicamente dai Volume.

Uno degli aspetti di rilievo che si riscontrano ben presto riguarda la collocazione ed il tempo di vita dei dati prodotti all'interno dei container. Infatti i dati sono generalmente racchiusi in essi e, al momento della rimozione del container di appartenenza, di norma andrebbero persi. Per questo motivo esistono i Volume in Docker e tale pratica è stata importata anche in Kubernetes.

In Kubernetes i Volume contribuiscono a dirimere due questioni principali:

• permettono di separare la vita dei container da quella dei dati. Pertanto, si avrà la possibilità di far sopravvivere i dati ai container;
• permettono lo scambio di dati tra container. Un Volume creato con questa finalità rimane una sorta di zona condivisa tra container. Quello che verrà inserito all'interno di un Volume condiviso tra più container sarà pertanto disponibile a tutti.

Tipologie di Volume

Prima di vedere come possiamo creare Volume all'interno di Kubernetes è interessante verificare quali tipologie esistano: come vedremo ne esistono diverse data la grande adattabilità di Kubernetes dai contesti on-premise al Cloud ma noteremo che alcuni sono ormai deprecati, segno dell'evoluzione continua che caratterizza questa piattaforma. Ecco alcuni tipi di Volume:

• emptyDir: nasce non appena il Pod è assegnato al nodo ed esiste finché questo è in esecuzione. Consiste essenzialmente nella creazione di una directory vuota che, ad esempio, può essere utilizzata per lo scambio di dati tra più container;
• hostPath: consiste nella mappatura di un file o di una directory presente nel nodo su una posizione interna al container. Si tratta di una soluzione che per motivi di sicurezza non è sempre consigliata pertanto sarebbe ideale utilizzarla solo nei casi strettamente necessari, ben consapevoli delle sue controindicazioni, limitandone l'uso esclusivamente a file e directory necessari e possibilmente in sola lettura;
• nfs: consiste nel montaggio di un Volume NFS (Network File System) e, a differenza di altre soluzioni come emptyDir, nel momento in cui il Pod viene distrutto i dati non sono cancellati ma sopravvivono. Ciò permette di mettere a disposizione delle risorse presenti in rete su NFS e di avere pertanto dei dati precaricati all'interno del Pod;
• cephfs: è una delle tipologie di Volume dedicate ad uno specifico filesystem. A differenza di emptyDir e come nfs, alla distruzione del Pod i dati salvati in un Volume cephfs persistono;
• nel tempo, considerato lo strettissimo legame tra Kubernetes ed il Cloud, sono nati tipi di Volume legati ai principali provider di questo tipo di soluzioni come awsElasticBlockStore, azureDisk e gcePersistentDisk le quali tuttavia sono al giorno d'oggi deprecate dalle versioni 1.17 di Kubernetes (la prima e la terza) e dalla 1.19 la seconda.

Esempio di utilizzo di Volume

Come esempio di utilizzo dei Volume proponiamo una situazione che potremmo definire piuttosto didattica visto che rende bene l'idea e può essere espansa, per esercizio, impiegando altre immagini container, magari create da noi stessi. Supponiamo di avere un Pod con due container dei quali uno dei due offre un server Web, l'altro si occupa di generare l'home page per il primo. Quello di cui avranno bisogno sarà condividere una cartella (in questo caso utilizzeremo emptyDir) che sarà mappata nel primo container al percorso /usr/local/apache2/htdocs dove Apache Web Server reperisce le pagine da fornire agli utenti:

apiVersion: v1
kind: Pod
metadata:
  name: esempio-emptydir
spec:
  volumes:
    - name: homedir
      emptyDir: {}
  containers:
    - name: webserver
      image: httpd:2.4
      volumeMounts:
        - name: homedir
          mountPath: /usr/local/apache2/htdocs
    - name: generatore-homepage
      image: alpine
      volumeMounts:
        - name: homedir
          mountPath: /output
      command: ["/bin/sh"]
      args: ["-c", "echo '<h1>Benvenuti sul nostro sito!</h1>' > /output/index.html"]

Denominando il file esempio-emptydir.yaml, potremo avviare il Pod con kubectl apply -f esempio-emptydir.yaml tenendo in considerazione che solo il container long-running con Apache Web Server rimarrà in esecuzione. La sua home page dovrebbe solo mostrare il contenuto <h1>Benvenuti sul nostro sito!</h1> e potremo verificarlo con un semplice port-forward eseguendo poi un’interrogazione con curl o mediante browser:

$ kubectl port-forward esempio-emptydir 8888:80 &
[2] 23567
Forwarding from 127.0.0.1:8888 -> 80
$ curl localhost:8888
Handling connection for 8888
<h1>Benvenuti sul nostro sito!</h1>

Come vediamo l'homepage del server Web è stata impostata in quanto esso legge nella stessa cartella in cui ha scritto il secondo container.

Poniamo bene attenzione alla sintassi con cui il Volume è stato creato: nel nostro esempio abbiamo usato emptyDir ma per altri tipi di Volume la struttura non cambierà molto. Nella sezione spec abbiamo un blocco volumes che definisce il Volume che vogliamo usare: al suo interno troviamo il nome con cui lo riconosceremo, homedir e la sua tipologia. I container definiti più in basso avranno la proprietà volumeMounts che specificherà il nome del volume da montare (richiamerà qui homedir) ed il percorso interno al container su cui questo dovrà essere montato.