Le nostre mani non sono per la noia: ripristino del cluster Rook in K8s

Noi già parlato, come/perché ci piace Rook: semplifica notevolmente il lavoro con i 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.

Per rendere la lettura più interessante, iniziamo da conseguenze di un ipotetico problema in un cluster.

«Tutto è perduto!»

Immagina di aver configurato e avviato Rook nel tuo cluster K8s, e che funzioni bene, ma in un certo 'bel' momento 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 significa automaticamente che 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ì, non ci sono monitor funzionanti nel cluster. Inoltre, non ci sono neanche pod con OSD o un pod MGR.

Quando è stato avviato il pod : tra le modifiche significative nella release Rook 1.0.0 relative a Ceph, possiamo menzionare il supporto per Ceph Nautilus e la possibilità di utilizzare NFS per i bucket CephFS o RGW. Tra l'altro, è stata raggiunta la fase beta per il supporto di EdgeFS.? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Iniziamo a seguire un percorso più lungo e interessante, conducendo un'indagine approfondita sulle 'internalità' di Rook e il ripristino passo dopo passo dei suoi componenti. Certo, c'è anche un modo più breve e corretto: l'uso dei backup. Come si sa, gli amministratori si dividono in due categorie: quelli che non fanno backup e quelli che li fanno già... Ma ne parleremo dopo l'indagine.

Un po' di pratiche, o La lunga strada

Esploriamo e ripristiniamo i monitor

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 viene distribuito con successo.

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

Per procedere con ulteriori azioni abbiamo bisogno di un riavvio forzato di tutti i server sui quali sono montate le immagini RBD (ls /dev/rbd*). Deve essere eseguito tramite sysrq (o 'a piedi' nel data center). Questo requisito è dovuto alla necessità di smontare le RBD montate, per cui un normale riavvio non andrà bene (cercare di smontarle normalmente sarà inefficace).

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

Rook monta nel pod del monitor le seguenti entità:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (un volume popolato da un ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (un volume popolato da un Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (volume bare host directory)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (volume bare host directory)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

Diamo un'occhiata a cosa c'è nel segreto rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Decodifichiamo e otterremo un normale keyring con diritti per l'amministratore e per 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 diamo un'occhiata al keyring nel segreto rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Cosa c'è dentro?

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

Stesso. Diamo un'altra occhiata... Ecco, per esempio, il segreto rook-ceph-mgr-a-keyring:

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

Alla fine troviamo ancora alcuni 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 iniziale dei keyring, da cui derivano tutti i segreti descritti sopra.

Come si sa (vedi dataDirHostPath in documentazione), Rook memorizza tali dati in due luoghi. Quindi andiamo sui nodi per controllare i keyring che si trovano nelle cartelle montate nei pod con i monitor e OSD. Per farlo, troviamo sui 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 questo segreto si è rivelato diverso — non come nei ConfigMap.

E riguardo al keyring dell'amministratore? Lo abbiamo anche:

# 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 dove si trova il problema. Si è verificato un certo guasto: il cluster è stato ricreato... ma in realtà non è così.

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

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

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

Ripristiniamo l'OSD

Entriamo nel pod rook-operator: la chiamata ceph mon dump mostra che tutti i monitor sono a posto, e ceph -s — il che significa che sono in quorume. Tuttavia, se diamo un'occhiata all'albero OSD (ceph osd tree), vedremo qualcosa di strano: gli OSD stanno iniziando ad apparire, ma sono vuoti. Quindi, anche loro devono essere ripristinati in qualche modo. Ma come?

Nel frattempo, nei ConfigMap sono apparsi i necessari rook-ceph-config e rook-config-override, così come molti altri ConfigMap con nomi del tipo rook-ceph-osd-$nodename-config. Diamo un'occhiata a essi:

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

Non è tutto così semplice, tutto è confuso!

Ridimensioniamo a zero il pod dell'operatore, rimuoviamo i Deployment generati dei pod OSD e correggiamo questi ConfigMap. Ma da dove ottenere la corretta mappa OSD in base ai nodi?

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

Concludiamo che osd0 è l'OSD necessario, quello indicato come /mnt/osd1 nel ConfigMap (poiché stiamo usando directory based osd.)

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

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

Entriamo di nuovo nel pod dell'operatore Rook e verifichiamo la vitalità del cluster… sì, ci siamo sbagliati un po' nelle conclusioni riguardo ai nomi degli OSD su alcuni nodi! Non è un problema: abbiamo nuovamente corretto i ConfigMap, rimosso le directory superflue dei 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 in ordine – il cluster è salvo!

Io sono pigro e faccio backup, o La strada veloce

Se i backup per Rook sono stati effettuati, il processo di ripristino diventa significativamente più semplice e si riduce a quanto segue:

1. Riduciamo a zero il deployment dell'operatore Rook;
2. Rimuoviamo tutti i deployment, escluso l'operatore Rook;
3. Ripristiniamo tutti i secret e ConfigMap dai backup;
4. Ripristiniamo il contenuto delle directory /var/lib/rook/mon-* sui nodi;
5. Ripristiniamo (se per caso persi) i CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Ridimensioniamo nuovamente il deployment dell'operatore Rook a 1.

Suggerimenti utili

Fai dei backup!

E per evitare situazioni in cui sarà necessario ripristinare da essi:

1. Prima di lavori di grande portata con il cluster, che prevedono il riavvio dei server, ridimensionate a zero l'operatore Rook, affinché non faccia niente di superfluo.
2. Aggiungere in anticipo nodeAffinity.
3. Prestate attenzione alla configurazione dei timeout ROOK_MON_HEALTHCHECK_INTERVAL e ROOK_MON_OUT_TIMEOUT.

In conclusion

Non ha senso discutere che Rook, pur essendo un ulteriore "strato" (nella struttura generale dell'organizzazione dello storage in Kubernetes), semplifica molte cose, ma porta anche nuove complessità e potenziali problemi nell'infrastruttura. La questione rimane: fare una scelta ponderata e giustificata tra questi rischi da un lato e i benefici che la soluzione porta nel vostro caso specifico, dall'altro.

A proposito, recentemente nella documentazione di Rook è stata aggiunta la sezione "Adottare un cluster Rook Ceph esistente in un nuovo cluster Kubernetes". Qui viene spiegato in dettaglio cosa fare per trasferire i dati esistenti in un nuovo cluster Kubernetes o per ripristinare il funzionamento di un cluster che si è guastato per un motivo o per l'altro.

P.S.

Leggete anche nel nostro blog:

• «Rook o non Rook: questo è il dilemma»;
• «Rook è uno storage di dati "self-service" per Kubernetes»;
• «Longhorn, uno storage distribuito per K8s di Rancher, è stato trasferito in CNCF».
• «Creiamo uno storage persistente con provisioning in Kubernetes basato su Ceph».

Fonte: habr.com