🥇Naše ruke nisu za dosadu: obnova Rook klastera u K8s

Mi že smo že govorili, zakaj se Rook zdi tako privlačen: močno poenostavi delo s shrambo v Kubernetes grozdih. Vendar pa ta enostavnost prinaša tudi določene zaplete. Upamo, da bo ta nova vsebina pomagala bolje razumeti te zaplete, preden se sploh pojavijo.

Da bo branje zanimivejše, začnimo z posledicami hipotetičnega problema v grozdu.

„Vse je izgubljeno!“

Predstavljajte si, da ste enkrat nastavili in zagnali Rook v svojem K8s grozdu, ki vas je razveseljeval s svojim delovanjem, toda v nekem „čudovitem“ trenutku se zgodi naslednje:

Novi podi ne morejo pritrditi RBD slik iz Ceph-a.
Ukazi, kot so lsblk in df , ne delujejo na Kubernetes vozliščih. To samodejno pomeni: „nič ni v redu“ s pritrjenimi RBD slikami na vozlišča. Ne moremo jih prebrati, kar kaže na nedostopnost monitorjev...
Da, v grozdu ni delujočih monitorjev. Poleg tega ni niti podov z OSD-ji, niti pod MGR.

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

Začnimo z bolj dolgim in zanimivim postopkom, kjer bomo temeljito raziskovali „notranjost“ Rook-a in korak za korakom obnovili njegove komponente. Seveda obstaja tudi krajša in pravilna pot: uporaba varnostnih kopij. Kot je znano, se administratorji delijo na dva tipa: tiste, ki ne delajo varnostnih kopij, in tiste, ki to že počnejo... Ampak o tem bomo govorili po raziskavi.

Malce prakse ali Dolga pot

Poglejmo in obnovimo monitorje

Torej, poglejmo seznam ConfigMap-ov: tam so potrebni za rezervacijo rook-ceph-config in rook-config-override. Pojavijo se ob uspešnem namestitvi grozda.

NB: V novih različicah, po sprejetju tega PR, ConfigMap-i niso več kazalnik uspeha namestitve grozda.

Za nadaljnje ukrepe potrebujemo trdo restartiranje vseh strežnikov, na katerih so pritrjene RBD slike (ls /dev/rbd*). To je potrebno izvesti preko sysrq (ali „peš“ v podatkovnem centru). Ta zahteva izhaja iz potrebe po odklopu pritrjenih RBD, zato običajno ponovno zagon ne bo deloval (poskušalo se bo neuspešno odklopiti na običajen način).

Teater se začne z obešalnikom, Ceph grozd pa z monitorji. Oglejmo si jih.

Rook montira v monitor podu takšne entitete:

Volumni:
 rook-ceph-config:
   Tip:      ConfigMap (volumn, ki se napolnjuje z ConfigMap)
   Ime:      rook-ceph-config
 rook-ceph-mons-keyring:
   Tip:        Secret (volumn, ki se napolnjuje z Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Tip:          HostPath (gol gostiteljski direktorij)
   Pot:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Tip:          HostPath (gol gostiteljski direktorij)
   Pot:          /var/lib/rook/mon-a/data
Montaže:
  /etc/ceph iz rook-ceph-config (ro)
  /etc/ceph/keyring-store/ iz rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a iz ceph-daemon-data (rw)
  /var/log/ceph iz rook-ceph-log (rw)

Poglejmo, kaj je v skrivnosti rook-ceph-mons-keyring:

vrsta: Secret
data:
 keyring: LongBase64EncodedString=

Dekodiramo in dobimo običajen keyring z dovoljenji za administratorja in monitorje:

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

Zapomnimo. Zdaj poglejmo keyring v skrivnosti rook-ceph-admin-keyring:

vrsta: Secret
data:
 keyring: anotherBase64EncodedString=

Kaj je v njem?

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

Enak. Poglejmo še… Evo, na primer, skrivnost rook-ceph-mgr-a-keyring:

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

Na koncu najdemo še nekaj skrivnosti v ConfigMap-u rook-ceph-mon:

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

In to je prvotni seznam z keyring-i, od koder izvira vse zgoraj opisane skrivnosti.

Kot je znano (glej dataDirHostPath u dokumenti), Rook shranjuje te podatke na dveh mestih. Zato se odpravimo na vozlišča, da pogledamo na keyring-e, ki so v imenikih, ki so pritrjeni v pod-e z monitorji in OSD. Za to bomo poiskali na vozliščih /var/lib/rook/mon-a/data/keyring in videli:

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

Presenetljivo je bila ta skrivnost drugačna — ne kot v ConfigMap-ih.

Kaj pa admin keyring? Ta imamo tudi:

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

Tu je težava. Prišlo je do nekega napaka: klaster se je znova ustvaril… ampak v resnici ne.

Postaja jasno, da so v skrivnostih shranjeni znova generirani keyring-i, in so ne iz našega starega klasterja. Zato:

vzeti keyring iz monitorja iz datoteke /var/lib/rook/mon-a/data/keyring (ali iz varnostne kopije);
spremeniti keyring v skrivnosti rook-ceph-mons-keyring;
vpisati keyring administratorja in monitorja v ConfigMap-u rook-ceph-mon;
izbrisati kontrolerje pod-ov z monitorji.

Čudež ne bo dolgo čakal: monitorji se bodo pojavili in zagnali. Hura, začetek je nared!

Obnovimo OSD

Vstopimo v pod rook-operator: klic ceph mon dump prikazuje, da so vsi monitorji na mestu, in ceph -s — na to, da so v quorum. Vendar pa, če pogledamo drevo OSD (ceph osd tree), bomo videli nekaj nenavadnega: OSD-ji so začeli nastajati, vendar so prazni. Izkazalo se je, da jih je potrebno nekako obnoviti. A kako?

Medtem so se v ConfigMap-ih pojavili tako potrebni rook-ceph-config in rook-config-override, kot tudi številne druge ConfigMap-e z imeni v obliki rook-ceph-osd-$nodename-config. Poglejmo jih:

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

Vse ni tako, vse je zmedeno!

Zmanjšamo pod operaterja na nič, odstranimo ustvarjene Deployment-e pod-ov z OSD in popravimo te ConfigMap-e. A od kod vzeti pravilno mapo OSD po vozliščih?

Poskusimo ponovno preiskati imenike /mnt/osd[1-2] na vozliščih — v upanju, da se bomo tam lahko za nekaj prijeli.
V imeniku /mnt/osd1 so 2 podimeniki: osd0 in osd16. Zadnji je namreč ID, ki je naveden v ConfigMap (16)?
Preverimo po velikostih in videli bomo, da osd0 je precej večji osd16.

Pridemo do zaključka, da osd0 je ta OSD tisti, ki je bil naveden kot /mnt/osd1 v ConfigMap (saj uporabljamo directory based osd.)

Korak za korakom preverimo vsa vozlišča in popravimo ConfigMap-e. Po vseh navodilih lahko zagnamo pod Rook-operaterja in preberemo njegova logi. In tam je vse odlično:

sem operater grozda;
našel sem diske na vozliščih;
našel sem monitorje;
monitorji so se povezali, tj. ustvarili so quorum;
zagonim OSD-jev…

Spet se bomo vrnili v pod operaterja Rook in preverili živost grozda… ja, nekoliko smo se zmotili pri zaključkih o imenih OSD na nekaterih vozliščih! Nič hudega: ponovno smo popravili ConfigMap-e, odstranili odvečne imenike novih OSD in prišli do dolgotrajno pričakovanega stanja HEALTH_OK!

Preverimo slike v bazenu:

# 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
…

Vse je na mestu — grozd je rešeno!

Sem len pri delanju varnostnih kopij, oziroma Hiter način

Če so varnostne kopije za Rook bile narejene, potem se postopek obnovitve znatno poenostavi in se zmanjša na naslednje:

Zmanjšamo deployment Rook-operaterja na nič;
Odstranimo vse deployment-e, razen Rook-operaterja;
Obnovimo vse secret-e in ConfigMap-e iz varnostne kopije;
Obnovimo vsebino imenikov /var/lib/rook/mon-* na vozliščih;
Obnovimo (če smo slučajno izgubili) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Nazaj povečamo deployment Rook-operaterja na 1.

Koristni nasveti

Delajte varnostne kopije!

Da bi se izognili situacijam, ko bo potrebno obnoviti iz njih:

Pred obsežnimi deli z grozdom, ki vključujejo ponovno zagon strežnikov, zmanjšajte Rook-operaterja na nič, da ne bo delal nepotrebne.
Na monitorje vnaprej dodajte nodeAffinity.
Obratite pažnju na preliminarne postavke vremena čekanja ROOK_MON_HEALTHCHECK_INTERVAL in ROOK_MON_OUT_TIMEOUT.

Namesto zaključka

Nema smisla raspravljati o tome da Rook, kao dodatni 'sloj' (u općoj shemi organizacije skladišta u Kubernetesu), koliko pojednostavljuje, toliko i dodaje nove složenosti i potencijalne probleme u infrastrukturi. Ostaje nam 'malo': donijeti promišljen, opravdan izbor između těch rizika s jedne strane i koristi koju rješenje donosi u vašem specifičnom slučaju, s druge strane.

Usput, nedavno je u dokumentaciju Rook dodana sekcija 'Usvoji postojeći Rook Ceph klaster u novi Kubernetes klaster'. U njoj se detaljnije opisuje što treba učiniti da biste preselili postojeće podatke u novi Kubernetes klaster ili obnovili rad klastera koji se raspao iz raznih razloga.