🥇Mâinile noastre nu sunt pentru plictiseală: restaurarea clusterului Rook în K8s

Noi a povestit deja, cum/pentru ce ne place Rook: în mod evident, simplifică lucru cu stocările în clusterele Kubernetes. Dar această simplificare vine la pachet cu anumite dificultăți. Sperăm că materialul nou va ajuta să navigăm mai bine aceste dificultăți înainte de a se manifesta.

Și pentru a face citirea mai interesantă, să începem cu consecințele unei probleme ipotetice în cluster.

«Totul este pierdut!»

Imaginați-vă că într-o zi ați configurat și lansat Rook în clusterul dvs. K8s, acesta funcționa bine, însă într-un moment «minunat» se întâmplă următoarele:

Noile pod-uri nu pot monta imaginile RBD din Ceph.
Comenzi precum lsblk și df nu funcționează pe nodurile Kubernetes. Aceasta înseamnă automat: «ceva nu este în regulă» cu imaginile RBD montate pe noduri. Nu se pot citi, ceea ce indică o indisponibilitate a monitorilor...
Da, în cluster nu există monitoare funcționale. Mai mult, nu există nici pod-uri OSD, nici pod MGR.

Când a fost lansat pod-ul rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Pentru început, să urmăm o cale mai lungă și mai interesantă, efectuând o investigație detaliată a «interiorului» Rook și o restaurare pas cu pas a componentelor sale. Desigur, există și o cale mai scurtă și corectă: utilizarea de backup-uri. Așa cum se știe, administratorii sunt împărțiți în două tipuri: cei care nu fac backup-uri și cei care deja le fac... Dar despre asta - după investigație.

Puțină practică, sau Calea lungă

Să ne uităm și să restaurăm monitoarele

Deci, să ne uităm la lista ConfigMap-urilor: acolo sunt necesare pentru rezervare rook-ceph-config și rook-config-override. Acestea apar la un deploy reușit al cluster-ului.

NB: În versiunile noi, după acceptarea acestui PR, ConfigMap-urile nu mai sunt un indicator al succesului deploy-ului cluster-ului.

Pentru a continua, avem nevoie de un reboot forțat al tuturor serverelor pe care se află imaginile RBD montate (ls /dev/rbd*). Acesta trebuie efectuat prin sysrq (sau «pe jos» în data center). Această cerință este datorată necesității de a deconecta imaginile RBD montate, pentru care un reboot standard nu va funcționa (va încerca fără succes să le de-monteze în mod normal).

Teatrul începe cu cuierul, iar clusterul Ceph - cu monitoarele. Să ne uităm la ele.

Rook montează în pod-ul monitorului astfel de entități:

Volume:
 rook-ceph-config:
   Tip:      ConfigMap (un volum populat de un ConfigMap)
   Nume:      rook-ceph-config
 rook-ceph-mons-keyring:
   Tip:        Secret (un volum populat de un Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Tip:          HostPath (volum de director gazdă)
   Cale:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Tip:          HostPath (volum de director gazdă)
   Cale:          /var/lib/rook/mon-a/data
Montări:
  /etc/ceph de la rook-ceph-config (ro)
  /etc/ceph/keyring-store/ de la rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a de la ceph-daemon-data (rw)
  /var/log/ceph de la rook-ceph-log (rw)

Să vedem ce este în secret rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Decodificăm și obținem un keyring obișnuit cu drepturi pentru admin și monitoare:

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

Să ne amintim. Și acum să vedem keyring-ul din secret rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Ce este în el?

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

Același lucru. Să mai vedem… Iată, de exemplu, secretul rook-ceph-mgr-a-keyring:

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

În cele din urmă, găsim încă câteva secrete în ConfigMap. rook-ceph-mon:

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

Și aceasta este lista inițială cu keyring-uri, din care provin toate secretele descrise mai sus.

După cum se știe (vezi dataDirHostPath în documentation), Rook stochează aceste date în două locuri. Așadar, să mergem pe noduri pentru a verifica keyring-urile care se află în directoarele ce sunt montate în pod-urile cu monitoare și OSD. Pentru aceasta, să căutăm pe noduri /var/lib/rook/mon-a/data/keyring și să vedem:

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

Pe neașteptate secretul s-a dovedit a fi diferit - nu ca în ConfigMap-uri.

Dar ce este cu keyring-ul admin? Îl avem și pe acesta:

# 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 *"

Aici este problema. A avut loc o eroare: cluster-ul a fost recreat… dar în realitate nu este.

Devine clar că secretele conțin keyring-uri regenerate, și ele nu sunt de la cluster-ul nostru vechi. Așadar:

luăm keyring-ul de la monitor din fișier /var/lib/rook/mon-a/data/keyring (sau din backup);
modificăm keyring-ul din secret rook-ceph-mons-keyring;
introducem keyring-ul admin și monitor în ConfigMap rook-ceph-mon;
eliminăm controlerele pod-urilor cu monitoare.

Minunea nu va întârzia: monitoarele vor apărea și se vor porni. Ura, începutul a fost făcut!

Vom restaura OSD

Intrăm în pod rook-operator: apel ceph mon dump arată că toate monitoarele sunt pe loc, iar ceph -s — că ele sunt în cvorum. Cu toate acestea, dacă ne uităm la arborele OSD (ceph osd tree) vom observa ceva ciudat: apar OSD-uri, dar sunt goale. Așadar, și acestea trebuie somehow recuperate. Dar cum?

Între timp, în ConfigMap-uri au apărut atât de necesarele noastre rook-ceph-config și rook-config-override, precum și multe alte ConfigMap-uri cu nume de tipul rook-ceph-osd-$nodename-config. Să ne uităm în ele:

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

Nu este deloc bine, totul este amestecat!

Să scapăm pod-ul operatorului, să ștergem Deployment-urile generate ale pod-urilor cu OSD și să corectăm aceste ConfigMap-uri. Dar de unde să luăm harta corectă OSD pe noduri?

Să încercăm din nou să căutăm în directoare /mnt/osd[1-2] de pe noduri — cu speranța că ne putem lega de ceva acolo.
În directorul /mnt/osd1 sunt 2 subdirectoare: osd0 și osd16. Ultimul este exact ID-ul care este indicat în ConfigMap (16)?
Să verificăm dimensiunile și vom observa că osd0 este mult mai mare osd16.

Ajungem la concluzia că osd0 — acesta este OSD-ul necesar, care a fost indicat ca /mnt/osd1 în ConfigMap (deoarece folosim directory based osd.)

Pas cu pas, verificăm toate nodurile și corectăm ConfigMap-urile. După toate indicațiile, putem lansa pod-ul Rook-operatorului și să citim jurnalele sale. Iar în ele totul este minunat:

eu sunt operatorul cluster-ului;
eu am găsit discurile pe noduri;
eu am găsit monitoarele;
monitoarele s-au unit, adică au format cvorumul;
lansăm deployment-urile OSD…

Din nou, să intrăm în pod-ul operatorului Rook și să verificăm starea cluster-ului… da, am greșit puțin în concluziile despre numele OSD-urilor de pe unele noduri! Nu-i nimic: am corectat din nou ConfigMap-urile, am șters directoarele în plus de la noile OSD și am ajuns la starea dorită HEALTH_OK!

Să verificăm imaginile din 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
…

Totul este la locul său — cluster-ul este salvat!

Sunt leneș să fac backup-uri, sau Calea rapidă

Dacă au fost realizate backup-uri pentru Rook, procedura de recuperare devine semnificativ mai simplă și se rezumă la următoarele:

Scalăm în zero deployment-ul Rook-operatorului;
Ștergem toate deployment-urile, cu excepția Rook-operatorului;
Recuperăm toate secret-urile și ConfigMap-urile din backup;
Recuperăm conținutul directoarelor /var/lib/rook/mon-* de pe noduri;
Recuperăm (dacă cumva le-am pierdut) CRD-uri CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Scalăm din nou deployment-ul Rook-operatorului la 1.

Sfaturi utile

Realizați backup-uri!

Și pentru a evita situațiile în care va fi necesară recuperarea din acestea:

Înainte de lucrările pe scară largă cu clusterul, care implică repornirea serverelor, scalează în zero Rook-operatorul pentru a nu face lucruri inutile.
Pe monitoare din timp adăugați nodeAffinity.
Acordați atenție configurării preliminare a timpilor de așteptare ROOK_MON_HEALTHCHECK_INTERVAL și ROOK_MON_OUT_TIMEOUT.

În concluzie

Nu are sens să contesti că Rook, fiind un „strat” suplimentar (în schema generală a organizării stocării în Kubernetes), simplifică multe lucruri, dar adaugă și noi complexități și probleme potențiale în infrastructură. Rămâne la alegerea „mică”: să faceți o alegere echilibrată și justificată între aceste riscuri de o parte și beneficiile pe care soluția le aduce în cazul dumneavoastră particular, de alta.

Apropo, recent în documentația Rook a fost adăugat un capitol intitulat „Adoptă un cluster Rook Ceph existent într-un nou cluster Kubernetes”. Acolo este detaliat despre ce trebuie să faceți pentru a migra datele existente în noul cluster Kubernetes sau pentru a restaura funcționarea unui cluster care s-a prăbușit din diverse motive.