🥇Rook — storage dati «self-service» per Kubernetes

Il 29 gennaio, il comitato tecnico dell'organizzazione CNCF (Cloud Native Computing Foundation), che sostiene Kubernetes, Prometheus e altri prodotti Open Source del mondo dei container e cloud native, ha annunciato ha approvato il progetto Rook . Un'ottima occasione per scoprire più da vicino questo «orchestratore di sistemi di archiviazione distribuita in Kubernetes».

Che cos'è Rook?

Rook — è un software scritto in Go (è distribuito con licenza libera Apache License 2.0), progettato per dotare gli archivi di dati di funzioni automatizzate che li rendono auto-gestiti, auto-scalabili e auto-riparabili. A tal fine, Rook automatizza (per gli archivi di dati utilizzati in ambiente Kubernetes): il deployment, bootstrapping, configurazione, provisioning, scalabilità, aggiornamenti, migrazioni, recupero da guasti, monitoraggio e gestione delle risorse.

Il progetto è in fase alpha e si specializza nell'orchestrazione del sistema di archiviazione distribuita Ceph nei cluster Kubernetes. Gli autori annunciano anche piani per supportare altri sistemi di archiviazione, ma ciò non accadrà nei prossimi rilasci.

Componenti e struttura tecnica

Alla base del funzionamento di Rook all'interno di Kubernetes c'è un operatore speciale (ne abbiamo parlato in dettaglio in questo articolo), che automatizza la configurazione dello storage e ne implementa il monitoraggio.

Quindi, L'operatore Rook è un container che contiene tutto il necessario per il deployment e la successiva manutenzione dello storage. Tra i compiti dell'operatore vi sono:

creazione di un DaemonSet per i demoni di archiviazione Ceph (ceph-osd) con un semplice cluster RADOS;
creazione di pod per il monitoraggio di Ceph (con ceph-mon, che controllano lo stato del cluster; per il quorum, di solito vengono implementati tre esemplari, e in caso di caduta di uno di essi ne viene avviato uno nuovo);
gestione delle CRD (Custom Resource Definitions) per il cluster, pool di archiviazione, object stores (set di risorse e servizi per gestire richieste HTTP che eseguono PUT/GET per oggetti, compatibili con S3 e Swift API), e inoltre file systems;
inizializzazione di pod per avviare tutti i servizi necessari;
creazione di agenti Rook.

Gli agenti Rook sono rappresentati da pod separati, che vengono implementati su ciascun nodo Kubernetes. Lo scopo dell'agente è configurare il plugin FlexVolume, che fornisce supporto per i volumi di storage in Kubernetes. L'agente gestisce l'utilizzo dello storage: collega dispositivi di storage di rete, monta i volumi, formatta il file system, ecc.

Posizione e ruolo dei componenti Rook nello schema generale del cluster Kubernetes

Rook offre tre tipi di storage:

a blocchi (Block, StorageClass) — monta lo storage a un singolo pod;
oggetto (Object, ObjectStore) — accessibile all'interno e all'esterno del cluster Kubernetes (tramite API S3);
file system condiviso (Shared File System, Filesystem) — file system che può essere montato in modalità lettura e scrittura da più pod.

Il dispositivo interno di Rook include:

Mons — pod per il monitoraggio di Ceph (con i già menzionati ceph-mon);
OSDs — pod con demoni ceph-osd (Object Storage Daemons);
MGR — pod con il demone ceph-mgr (Ceph Manager), che fornisce funzionalità di monitoraggio aggiuntive e interfacce per sistemi esterni (monitoraggio/gestione);
RGW (opzionale) — pod con storage a oggetti;
MDS (opzionale) — pod con file system condiviso.

Tutti i demoni Rook (Mons, OSDs, MGR, RGW, MDS) sono compilati in un unico binario (rook), eseguito in un contenitore.

Per una rapida introduzione al progetto, può essere utile anche questa breve (12 diapositive) presentazione di Bassam Tabbara (CTO di Quantum Corp).

Operazione Rook

L'operatore Rook supporta completamente le versioni di Kubernetes 1.6 e superiori (e, parzialmente, la versione più vecchia K8s — 1.5.2). La sua installazione in scenari più semplici è il seguente:

cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yaml

Inoltre, per l'operatore Rook è disponibile un Helm chart, grazie al quale l'installazione può avvenire anche in questo modo:

helm repo add rook-alpha https://charts.rook.io/alpha
helm install rook-alpha/rook

Ci sono un numero limitato di opzioni di configurazione (ad esempio, è possibile disabilitare il supporto RBAC, se questa funzionalità non viene utilizzata nel proprio cluster), che vengono transeferite in helm install tramite il parametro --set key=value[,key=value] (o conservare in un file YAML separato e passare — tramite -f values.yaml).

Dopo l'installazione dell'operatore Rook e l'avvio dei pod con i suoi agenti, è necessario creare il cluster Rook stesso, la cui configurazione più semplice appare nel modo seguente (rook-cluster.yaml):

apiVersion: v1
kind: Namespace
metadata:
  name: rook
---
apiVersion: rook.io/v1alpha1
kind: Cluster
metadata:
  name: rook
  namespace: rook
spec:
  dataDirHostPath: /var/lib/rook
  storage:
    useAllNodes: true
    useAllDevices: false
    storeConfig:
      storeType: bluestore
      databaseSizeMB: 1024
      journalSizeMB: 1024

Nota: si deve prestare particolare attenzione all'attributo dataDirHostPath, il cui valore corretto è necessario per mantenere il cluster dopo i riavvii. Per i casi in cui venga utilizzato come luogo di archiviazione permanente dei dati, Rook consiglia di avere almeno 5 GB di spazio libero su disco in questa directory sui nodi Kubernetes.

Rimane da creare effettivamente un cluster dalla configurazione e assicurarsi che i pod siano stati creati nel cluster (nello spazio dei nomi rook):

kubectl create -f rook-cluster.yaml
kubectl -n rook get pod
NAME                              READY     STATUS    RESTARTS   AGE
rook-api-1511082791-7qs0m         1/1       Running   0          5m
rook-ceph-mgr0-1279756402-wc4vt   1/1       Running   0          5m
rook-ceph-mon0-jflt5              1/1       Running   0          6m
rook-ceph-mon1-wkc8p              1/1       Running   0          6m
rook-ceph-mon2-p31dj              1/1       Running   0          6m
rook-ceph-osd-0h6nb               1/1       Running   0          5m

Aggiornamento del cluster Rook (a una nuova versione) — è una procedura che in questa fase richiede l'aggiornamento sequenziale di tutti i suoi componenti in un determinato ordine, e si può iniziare solo dopo aver verificato che l'attuale installazione di Rook sia in uno stato completamente "sano". Una guida dettagliata passo passo per l'aggiornamento esempio da Rook versione 0.5.0 a 0.5.1 può essere trovata in documentazione del progetto.

A novembre dello scorso anno, nel blog di Rook è stato pubblicato un confronto delle prestazioni con EBS. I risultati meritano attenzione e, per riassumere brevemente, sono i seguenti:

Prospettive

Lo stato attuale di Rook è alpha, e l'ultimo grande rilascio fino ad oggi è la versione 0.6, rilasciata a novembre 2017 (la correzione attuale è v0.6.2 — è uscita il 14 dicembre). Già nella prima metà del 2018 sono attesi rilasci di versioni più mature: beta e stabile (ufficialmente pronta per l'uso in produzione).

Secondo la roadmap del progetto, gli sviluppatori hanno una visione dettagliata per lo sviluppo di Rook almeno nei due prossimi rilasci: 0.7 (la sua prontezza nel tracker di GitHub è valutata come 60 %) e 0.8. Tra le modifiche attese ci sono il passaggio del supporto per Ceph Block e Ceph Object a stato beta, provisioning dinamico dei volumi per CephFS, un sistema di logging avanzato, aggiornamenti automatizzati del cluster e supporto per snapshot dei volumi.

L'accettazione di Rook tra i progetti CNCF (finora solo nella fase iniziale - "inception-level", - insieme a linkerd e CoreDNS) è una sorta di garanzia del crescente interesse per il prodotto. Quanto riuscirà a consolidarsi nel mondo delle applicazioni cloud, sarà più chiaro dopo la pubblicazione delle versioni stabili, che porteranno sicuramente Rook nuovi «sperimentatori» e utenti.

Rook — un archivio dati 'self-service' per Kubernetes

Che cos'è Rook?

Componenti e struttura tecnica

Operazione Rook

Prospettive

P.S.