🥇Le nostre mani non sono per annoiarsi: ripristino del cluster Rook in K8s

Noi ha già raccontato, come/perché ci piace Rook: in misura notevole semplifica il lavoro con gli storage nei cluster Kubernetes. Tuttavia, con questa semplicità arrivano anche alcune complessità. Speriamo che questo nuovo materiale aiuti a comprendere meglio tali complessità prima che si manifestino.

E per rendere la lettura più interessante, iniziamo con le conseguenze di un ipotetico problema nel cluster.

«È tutto perduto!»

Immaginate di aver configurato e avviato una volta Rook nel vostro cluster K8s, che funzionava bene, ma a un certo punto «magnifico» succede quanto segue:

I nuovi pod non riescono a montare le immagini RBD da Ceph.
Comandi come lsblk e df non funzionano sui nodi Kubernetes. Questo implica automaticamente: «c'è qualcosa che non va» con le immagini RBD montate sui nodi. Non riescono a essere lette, il che indica l'inaccessibilità dei monitor...
Sì, nel cluster non ci sono monitor funzionanti. Inoltre, non ci sono nemmeno pod con OSD, né pod MGR.

Quando è stato avviato il pod rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Per iniziare, prendiamo una strada più lunga e interessante, conducendo un'indagine approfondita sulle «entità» di Rook e un ripristino passo passo dei suoi componenti. Ovviamente, c'è anche un modo più breve e corretto: utilizzare i backup. Come è noto, gli amministratori si dividono in due tipi: quelli che non fanno backup e quelli che li fanno già... Ma di questo parleremo dopo l'indagine.

Un po' di pratica, o La strada lunga

Esaminiamo e ripristiniamo i monitor

Quindi, diamo un'occhiata all'elenco dei ConfigMap: ci sono quelli necessari per il backup rook-ceph-config e rook-config-override. Appaiono quando il cluster è stato distribuito con successo.

NB: Nelle nuove versioni, dopo l'accettazione di questo PR, i ConfigMap non sono più un indicatore di successo della distribuzione del cluster.

Per eseguire ulteriori azioni abbiamo bisogno di un riavvio forzato di tutti i server su cui sono presenti le immagini RBD montate (ls /dev/rbd*). Deve essere eseguito tramite sysrq (o «a piedi» nel Data Center). Questa esigenza è dovuta all'obiettivo di disconnettere le RBD montate, per cui il riavvio standard non è adatto (si tenterà senza successo di smontarle normalmente).

Il teatro inizia con il guardaroba, e un cluster Ceph inizia con i monitor. Diamo un'occhiata a loro.

Rook monta nel pod del monitor queste entità:

Volumi:
 rook-ceph-config:
   Tipo:      ConfigMap (un volume popolato da un ConfigMap)
   Nome:      rook-ceph-config
 rook-ceph-mons-keyring:
   Tipo:        Secret (un volume popolato da un Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Tipo:          HostPath (volume di directory host nuda)
   Percorso:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Tipo:          HostPath (volume di directory host nuda)
   Percorso:          /var/lib/rook/mon-a/data
Montaggi:
  /etc/ceph da rook-ceph-config (ro)
  /etc/ceph/keyring-store/ da rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a da ceph-daemon-data (rw)
  /var/log/ceph da rook-ceph-log (rw)

Vediamo cosa contiene il segreto rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Decodifichiamo e otterremo un normale keyring con diritti per l'amministratore e i monitor:

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Ricordiamolo. Ora vediamo il keyring nel segreto rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Cosa contiene?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Identico. Vediamo ancora... Ecco, ad esempio, un segreto rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

Alla fine troviamo altri segreti nel ConfigMap rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

E questo è l'elenco originale con i keyring, da cui provengono tutti i segreti descritti sopra.

Come sappiamo (vedi dataDirHostPath in documentazione), Rook memorizza tali dati in due posti. Quindi andiamo nei nodi per vedere i keyring nelle directory che sono montate nei pod dei monitor e degli OSD. Per fare questo cerchiamo nei nodi /var/lib/rook/mon-a/data/keyring e vediamo:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

Improvvisamente qui il segreto si è rivelato diverso — non come nei ConfigMap.

E riguardo al keyring dell'amministratore? Ce l'abbiamo anche noi:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Ecco il problema. Si è verificato un certo malfunzionamento: il cluster è stato ricreato... ma in realtà no.

Diventa chiaro che nei segreti sono memorizzati keyring rigenerati, e loro non provengono dal nostro vecchio cluster. Pertanto:

prendiamo il keyring dal monitor dal file /var/lib/rook/mon-a/data/keyring (o da un backup);
modifichiamo il keyring nel segreto rook-ceph-mons-keyring;
scriviamo il keyring dell'amministratore e del monitor nel ConfigMap rook-ceph-mon;
rimuoviamo i controller dei pod con i monitor.

Un miracolo non tarderà ad arrivare: i monitor appariranno e si avvieranno. Evviva, è stato fatto il primo passo!

Ripristiniamo OSD

Entriamo nel pod rook-operator: invocazione ceph mon dump mostra che tutti i monitor sono al loro posto, e ceph -s — riguardo al fatto che siano in quorum. Tuttavia, se guardiamo all'albero OSD (ceph osd tree), vediamo qualcosa di strano: gli OSD hanno cominciato ad apparire, ma sono vuoti. Quindi, devono essere ripristinati in qualche modo. Ma come?

Nel frattempo, nei ConfigMap sono comparsi i tanto necessari rook-ceph-config e rook-config-override, così come molti altri ConfigMap con nomi del tipo rook-ceph-osd-$nodename-config. Vediamo al loro interno:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

Non va niente, è tutto confuso!

Azzeriamo il pod dell'operatore, eliminiamo i Deployment dei pod con OSD generati e sistemiamo questi ConfigMap. Ma da dove prendere la giusta mappa OSD per i nodi?

Proviamo a scavare di nuovo nelle directory /mnt/osd[1-2] sui nodi, sperando di trovare qualcosa a cui aggrapparci.
Nella directory /mnt/osd1 ci sono 2 sottocartelle: osd0 e osd16. L'ultima è proprio quell'ID che è indicato nel ConfigMap (16)?
Controlliamo le dimensioni e vediamo che osd0 è molto più grande osd16.

Arriviamo alla conclusione che osd0 è l'OSD necessario, che era indicato come /mnt/osd1 nel ConfigMap (dopotutto stiamo usando directory based osd.)

Controlliamo passo dopo passo tutti i nodi e correggiamo i ConfigMap. Dopo tutte le indicazioni possiamo avviare il pod dell'operatore Rook e leggere i suoi log. E in essi tutto è meraviglioso:

io sono l'operatore del cluster;
ho trovato i dischi nei nodi;
ho trovato i monitor;
i monitor si sono messi d'accordo, cioè hanno formato un quorum;
sto avviando i deployment OSD…

Rientriamo nel pod dell'operatore Rook e controlliamo la vitalità del cluster… sì, ci siamo un po' sbagliati nelle conclusioni riguardo ai nomi degli OSD su alcuni nodi! Non fa niente: abbiamo corretto di nuovo i ConfigMap, eliminato le directory in eccesso dai nuovi OSD e siamo arrivati allo stato tanto atteso HEALTH_OK!

Controlliamo le immagini nel pool:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

Tutto è a posto: il cluster è salvato!

Faccio backup in modo pigro, o la via rapida

Se i backup per Rook venivano eseguiti, la procedura di ripristino diventa notevolmente più semplice e si riduce a quanto segue:

Scaliamo a zero il deployment dell'operatore Rook;
Eliminiamo tutti i deployment, tranne l'operatore Rook;
Ripristiniamo tutti i secret e i ConfigMap dai backup;
Ripristiniamo il contenuto delle directory /var/lib/rook/mon-* sui nodi;
Ripristiniamo (se mai persi) i CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Ridimensioniamo di nuovo il deployment dell'operatore Rook a 1.

Consigli utili

Fate i backup!

E per evitare situazioni in cui sarà necessario ripristinarli:

Prima di lavori su larga scala con il cluster, che comportano riavvii dei server, ridimensiona a zero l'operatore Rook, affinché non faccia nulla di superfluo.
Aggiungi in anticipo nodeAffinity ai monitor.
Prestate attenzione alla configurazione dei timeout ROOK_MON_HEALTHCHECK_INTERVAL e ROOK_MON_OUT_TIMEOUT.

In conclusione

Non ha senso discutere del fatto che Rook, essendo un ulteriore "strato" (nello schema generale di organizzazione dello storage in Kubernetes), sia in grado di semplificare molte cose, ma allo stesso tempo introduce nuove complessità e potenziali problemi nell'infrastruttura. La questione rimane "piccola": prendere una decisione ponderata e giustificata tra questi rischi da un lato e il beneficio che la soluzione porta nel vostro caso specifico, dall'altro.

A proposito, recentemente nella documentazione di Rook è stata aggiunta una sezione intitolata "Adotta un cluster Rook Ceph esistente in un nuovo cluster Kubernetes". In essa è spiegato più dettagliatamente cosa è necessario fare per trasferire i dati esistenti in un nuovo cluster Kubernetes o per ripristinare il funzionamento di un cluster che si è distrutto per vari motivi.