🥇A kezünk nem unalomra való: A Rook klaszter helyreállítása K8s-ben

Mi korábban beszéltünk, hogyan/miért szeretjük a Rook-ot: jelentősen megkönnyíti a Kubernetes klaszterek tárolóival való munkát. Azonban ezzel a könnyedséggel bizonyos nehézségek is járnak. Reméljük, az új anyag segít jobban megérteni ezeket a nehézségeket, mielőtt még jelentkeznének.

Amiért érdekesebb legyen olvasni, kezdjük a következményekkel egy hipotetikus probléma a klaszterben.

«Minden elveszett!»

Képzelje el, hogy egyszer beállította és elindította a Rook-ot a K8s klaszterében, és örömmel tapasztalta a működését, azonban egy „szép” napon a következő történik:

Az új pod-ok nem tudják csatlakoztatni az RBD-képeket a Ceph-ből.
Az olyan parancsok, mint a lsblk és df nem működnek a Kubernetes csomópontokon. Ez automatikusan azt jelenti: „valami nincs rendben” a csomópontokra csatlakoztatott RBD-képekkel. Nem lehet őket elérni, ami a monitorok elérhetetlenségére utal...
Igen, a klaszterben nincsenek működő monitorok. Sőt — még OSD pod-ok vagy MGR pod sem található.

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

Kezdetnek egy hosszabb, érdekesebb úton fogunk elindulni, alapos nyomozást végezve a Rook „belső” összetevőiről és lépésről lépésre helyreállítva azok elemeit. Természetesen létezik egy rövidebb, helyes út is: a biztonsági mentések használata. Mint tudjuk, az adminisztrátorokat két típusra oszthatjuk: azok, akik nem készítenek biztonsági mentéseket, és azok, akik már készítenek... De erről a nyomozás után beszélünk.

Egy kis gyakorlat, avagy A hosszú út

Nézzük meg és állítsuk helyre a monitorokat

Tehát nézzük meg a ConfigMap-ok listáját: ott vannak a szükségesek a biztonsági mentésekhez rook-ceph-config és rook-config-override. Ezek akkor jelennek meg, amikor a klaszter sikeresen telepítve van.

NB: Az új verziókban, miután elfogadták ezt a PR-t, a ConfigMap-ok már nem azok a mutatók, amelyek a klaszter sikeres telepítését jelzik.

A következő lépések végrehajtásához szükség van az összes szerver kemény újraindítására, ahol csatlakoztatott RBD-képek találhatók (ls /dev/rbd*). Ezt a sysrq telefonálásával (vagy „gyalog” a datacenterbe) kell végrehajtani. Ez a követelmény abból adódik, hogy le kell választani a csatlakoztatott RBD-ket, amire a normál újraindítás nem lesz elegendő (nem fog sikerülni őket normál módon lecsatlakoztatni).

A színház a fogasnál kezdődik, a Ceph klaszter pedig a monitoroknál. Nézzük meg őket.

A Rook ilyen entitásokat csatlakoztat a monitor pod-jához:

Térfogatok:
 rook-ceph-config:
   Típus:      ConfigMap (egy volume, amelyet ConfigMap tölt be)
   Név:      rook-ceph-config
 rook-ceph-mons-keyring:
   Típus:        Secret (egy volume, amelyet Secret tölt be)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Típus:          HostPath (közvetlen host könyvtár volumen)
   Útvonal:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Típus:          HostPath (közvetlen host könyvtár volumen)
   Útvonal:          /var/lib/rook/mon-a/data
Kötések:
  /etc/ceph a rook-ceph-config-ból (ro)
  /etc/ceph/keyring-store/ a rook-ceph-mons-keyring-ból (ro)
  /var/lib/ceph/mon/ceph-a a ceph-daemon-data-ból (rw)
  /var/log/ceph a rook-ceph-log-ból (rw)

Nézzük meg, mi van a titokban rook-ceph-mons-keyring:

típus: Secret
data:
 keyring: LongBase64EncodedString=

Dekódoljuk, és megkapjuk a a normál keyring-et admin és monitor jogosultságokkal:

[mon.]
       kulcs = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       jogosultságok mon = "allow *"
[client.admin]
       kulcs = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       jogosultságok mds = "allow *"
       jogosultságok mon = "allow *"
       jogosultságok osd = "allow *"
       jogosultságok mgr = "allow *"

Emlékezzünk. Most nézzük meg a keyring-et a titokban rook-ceph-admin-keyring:

típus: Secret
data:
 keyring: anotherBase64EncodedString=

Mi van benne?

[client.admin]
       kulcs = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       jogosultságok mds = "allow *"
       jogosultságok mon = "allow *"
       jogosultságok osd = "allow *"
       jogosultságok mgr = "allow *"

Ugyanaz. Nézzük meg tovább… Íme, például egy titok rook-ceph-mgr-a-keyring:

[mgr.a]
       kulcs = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       jogosultságok mon = "allow *"
       jogosultságok mds = "allow *"
       jogosultságok osd = "allow *"

Végül több titkot is találunk a ConfigMap-ben rook-ceph-mon:

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

Ez az eredeti lista a keyring-ekről, ahonnan minden fent említett titok származik.

Köztudott (lásd dataDirHostPath be. dokumentáció), hogy a Rook ezeket az adatokat két helyen tárolja. Tehát nézzünk el a csomópontokhoz, hogy megvizsgáljuk a keyring-eket a mappákban, amelyek a monitorok és OSD pod-okhoz vannak csatolva. Ehhez keressük meg a csomópontokban /var/lib/rook/mon-a/data/keyring és látni fogjuk:

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

Hirtelen itt a titok más — mint a ConfigMap-kban.

Mi a helyzet az admin keyring-gel? Az is megvan:

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

Itt van a probléma. Valami hiba történt: a klaszter újra lett hozva… de valójában nem.

Kiderül, hogy a titkokban újra generált keyring-eket tárolnak, és ezek nem a régi klaszterünkből származnak. Tehát:

fogjuk a keyring-et a monitortól a fájlból /var/lib/rook/mon-a/data/keyring (vagy visszaállításból);
módosítjuk a keyring-et a titokban rook-ceph-mons-keyring;
megadjuk a keyring-et az admin és monitor számára a ConfigMap-ben rook-ceph-mon;
eltávolítjuk a monitorok pod-vezérlőit.

A csoda nem várat sokáig: a monitorok meg fognak jelenni és elindulnak. Hurrá, a kezdet megtörtént!

Helyreállítjuk az OSD-t

Belépünk a pod-ba rook-operator: a behívás ceph mon dump megmutatja, hogy minden monitor a helyén van, és ceph -s — arról, hogy a kvórumban vannak. Azonban, ha megvizsgáljuk az OSD fáját (ceph osd tree), valami furcsát látunk: OSD-k kezdtek megjelenni, de üresek. Tehát ezeket is valahogyan vissza kell állítani. De hogyan?

Közben a ConfigMap-okban megjelentek a számunkra szükséges rook-ceph-config és rook-config-override, valamint sok más ConfigMap, amelyek nevei a következő formát öltötték: rook-ceph-osd-$nodename-config. Nézzük meg őket:

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

Minden nem úgy van, ahogy kellene, minden össze van keveredve!

Átállítjuk a pod operátort nullára, eltávolítjuk az OSD-k pod-jaival generált Deployment-eket és kijavítjuk ezeket a ConfigMap-okat. De honnan szerezzük be a helyes OSD térképet a csomópontok alapján?

Próbáljunk újra ásni a könyvtárakban /mnt/osd[1-2] a csomópontokon — remélve, hogy találunk valami fogódzót.
A mappa /mnt/osd1 van 2 alkönyvtár: osd0 és osd16. Az utóbbi éppen az az azonosító, ami a ConfigMap-ban szerepel (16)?
Ellenőrizzük a méreteket, és meglátjuk, hogy osd0 jóval nagyobb osd16.

Arra a következtetésre jutottunk, hogy osd0 — ez a szükséges OSD, amely a ConfigMap-ban szerepel, hiszen mi /mnt/osd1 directory based osd-t használunk Lépésről lépésre ellenőrizzük az összes csomópontot és javítjuk a ConfigMap-okat. Minden utasítás után elindíthatjuk a Rook operátort és elolvashatjuk a naplóit. A naplókban mindent rendben találunk:.)

én vagyok a klaszter operátora;

megtaláltam a lemezeket a csomópontokon;
megtaláltam a monitorokat;
a monitorok összebarátkoztak, tehát kialakult a kvórum;
elindítom az OSD-k telepítését...
Újra belépünk a Rook operátor pod-ba és ellenőrizzük a klaszter állapotát... igen, egy kicsit tévedtünk az OSD nevek kibocsátásával kapcsolatban néhány csomóponton! Nem gond: újra javítottuk a ConfigMap-okat, eltávolítottuk a felesleges könyvtárakat az új OSD-k miatt, és eljutottunk a régóta várt állapothoz

HEALTH_OK Ellenőrizzük a képeket a tárolóban:!

Minden a helyén — a klaszter megmenekült!

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

Lusta vagyok biztonsági másolatokat készíteni, vagy Gyors mód

Ha a Rook számára biztonsági másolatok készültek, akkor a helyreállítási eljárás jelentősen egyszerűsödik, és a következőre csökken:

Nullára állítjuk a Rook operátor telepítést;

Eltávolítjuk az összes telepítést, kivéve a Rook operátort;
Visszaállítjuk a biztonsági másolatból az összes titkosítást és ConfigMap-ot;
Visszaállítjuk a könyvtárak tartalmát
a csomópontokon; /var/lib/rook/mon-* Visszaállítjuk (ha esetleg elvesztettük) a CRD-t
CephCluster CephFilesystem, CephBlockPool, CephNFS, CephObjectStore, Visszamozdítjuk a Rook operátor telepítést 1-re.;
Készítsetek biztonsági másolatokat!

Hasznos tippek

Hogy elkerüljük az olyan helyzeteket, amikor szükség lesz rá:

Nagyobb munkák előtt a klaszterrel, amelyek szerver újraindításokat igényelnek, állítsuk nullára a Rook operátort, hogy ne végezzen felesleges műveleteket.

A monitorokhoz előre
adjuk hozzá a nodeAffinity adjunk nodeAffinity-t.
Figyeljen a beállítási idők előkészítésére az időzítők beállítására ROOK_MON_HEALTHCHECK_INTERVAL és ROOK_MON_OUT_TIMEOUT.

Összegzésként

Nincs értelme vitatkozni azon, hogy a Rook, mint egy kiegészítő „réteg” (a Kubernetes tárolásának általános rendszereiben) sok minden egyszerűsít, ugyanakkor új bonyodalmakat és potenciális problémákat is ad az infrastruktúrához. A döntés az „apró” dolgon áll: mérlegelni kell a kockázatokat és az előnyöket, amelyet a megoldás hoz az adott esetében.

Mellesleg, nemrégiben a Rook dokumentációjába hozzáadták az „Egy meglévő Rook Ceph klasztert bevinni egy új Kubernetes klaszterbe” szakaszt. Itt részletesebben kifejtik, mit kell tenni ahhoz, hogy az existing data-t áttelepíthessük egy új Kubernetes klaszterbe, vagy helyreállíthassuk a megbomlott klaszter működését.