🥇Naše ruce nejsou na nic: obnova clusteru Rook v K8s

Jsme už mluvili, jak/proč se nám líbí Rook: významně usnadňuje práci se storages v clusterech Kubernetes. S touto jednoduchostí však přicházejí i určité složitosti. Doufáme, že nový materiál pomůže lépe se orientovat v těchto složitostech ještě předtím, než se projeví.

Abychom to učinili zajímavějším, začneme s následky hypotetického problému v clusteru.

„Všechno je ztraceno!“

Představte si, že jste jednou nastavili a spustili Rook ve svém K8s clusteru, byl jste potěšeni jeho výkonem, ale v nějaký „ krásný“ okamžik se stalo následující:

Nové pod’y nemohou připojit RBD obrazy z Ceph.
Příkazy jako lsblk a df nefungují na uzlech Kubernetes. To automaticky znamená: „něco není v pořádku“ s připojenými na uzly RBD obrazy. Nelze je přečíst, což naznačuje nedostupnost monitorů...
Ano, v clusteru nejsou žádné pracovní monitory. Navíc — nejsou ani žádné pod’y s OSD, ani pod MGR.

Když byl spuštěn pod rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Na začátek pojďme zajít zajímavější delší cestou, provedeme důkladné vyšetřování „vnitřností“ Rook a krok po kroku obnovíme jeho komponenty. Samozřejmě existuje i kratší správná cesta: využití záloh. Jak je známo, administrátoři se dělí na dva typy: na ty, kdo nedělají zálohy, a na ty, kdo je už dělají... Ale k tomu se dostaneme po vyšetřování.

Trochu praxe, nebo Dlouhá cesta

Podíváme se kolem a obnovíme monitory

Takže se podívejme na seznam ConfigMap’ů: tam jsou potřebné pro rezervaci rook-ceph-config a rook-config-override. Ty se objevují při úspěšném nasazení clusteru.

NB: V nových verzích, po přijetí tohoto PR, ConfigMap’y přestaly být ukazatelem úspěšnosti nasazení clusteru.

Pro další kroky potřebujeme tvrdý restart všech serverů, na kterých jsou připojené RBD obrazy (ls /dev/rbd*). Musí se provést přes sysrq (nebo „pěšky“ do datového centra). Tento požadavek vychází z potřeby odpojit připojené RBD, pro což obvyklý restart nebude vyhovovat (pokusy o normální odpojení nebudou úspěšné).

Divadlo začíná u věšáku, a Ceph cluster — u monitorů. Podívejme se na ně.

Rook připojuje do pod monitoru takové entity:

Objemy:
 rook-ceph-config:
   Typ:      ConfigMap (objem naplněný ConfigMap)
   Název:      rook-ceph-config
 rook-ceph-mons-keyring:
   Typ:        Secret (objem naplněný tajemstvím)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Typ:          HostPath (objem z místní složky)
   Cesta:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Typ:          HostPath (objem z místní složky)
   Cesta:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph z rook-ceph-config (ro)
  /etc/ceph/keyring-store/ z rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a z ceph-daemon-data (rw)
  /var/log/ceph z rook-ceph-log (rw)

Podíváme se, co je v tajemství rook-ceph-mons-keyring:

typ: Secret
data:
 keyring: LongBase64EncodedString=

Dekódujeme a získáme běžný keyring s právy pro administrátora a monitory:

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

Pamatujme si. A teď se podíváme na keyring v tajemství rook-ceph-admin-keyring:

typ: Secret
data:
 keyring: anotherBase64EncodedString=

Co je v něm?

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

Ten samý. Podíváme se dál… Tady, například, tajemství rook-ceph-mgr-a-keyring:

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

Nakonec nacházíme ještě několik tajemství v ConfigMapě rook-ceph-mon:

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

A toto je původní seznam s keyringy, odkud pocházejí všechna výše uvedená tajemství.

Jak je známo (viz dataDirHostPath v dokumentaci), Rook ukládá takové údaje na dvou místech. Takže pojďme na uzly, abychom se podívali na keyringy, které leží v adresářích, jež jsou namontovány v podech s monitory a OSD. K tomu najdeme na uzlech /var/lib/rook/mon-a/data/keyring a uvidíme:

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

Najednou se ukázalo, že tajemství je jiné — nez jak v ConfigMapách.

A co adiministrátorský keyring? Ten máme také:

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

Tady je problém. Došlo k nějaké chybě: klastr byl znovu vytvořen… ale ve skutečnosti ne.

Stává se jasným, že v tajemstvích jsou uloženy znovu vygenerované keyringy, a ty ne jsou z našeho starého klastru. Proto:

vezmeme keyring z monitoru z souboru /var/lib/rook/mon-a/data/keyring (nebo z zálohy);
změníme keyring v tajemství rook-ceph-mons-keyring;
zapíšeme keyring pro administrátora a monitor do ConfigMapy rook-ceph-mon;
odstraníme controllery podů s monitory.

Zázrak nenechá na sebe dlouho čekat: monitory se objeví a spustí. Hurá, začátek je položen!

Obnovíme OSD

Vstoupíme do podu rook-operator: vyvolání ceph mon dump ukazuje, že všechny monitory jsou na místě, a ceph -s — na to, že jsou v kvóru. Pokud se ale podíváme na strukturu OSD (ceph osd tree), uvidíme v ní něco zvláštního: OSD začaly přibývat, ale jsou prázdné. Takže je také potřeba je nějak obnovit. Ale jak?

Mezitím se v ConfigMapách objevily tak potřebné rook-ceph-config a rook-config-override, stejně jako mnoho dalších ConfigMapů s názvy jako rook-ceph-osd-$nodename-config. Podíváme se do nich:

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

Všechno je jinak, všechno je pomíchané!

Snížíme na nulu pod operátora, odstraníme vygenerované Deploymenty podů s OSD a opravíme tyto ConfigMapy. Ale odkud vzít správnou mapu OSD podle uzlů?

Zkusíme se znovu podívat do adresářů /mnt/osd[1-2] na uzlech — s nadějí, že se nám tam něco povede najít.
V adresáři /mnt/osd1 existují 2 podadresáře: osd0 a osd16. Ten poslední — to je přece ten ID, který je uveden v ConfigMap (16)?
Zkontrolujeme podle velikostí a uvidíme, že osd0 je mnohem větší osd16.

Dospíváme k závěru, že osd0 — to je ten správný OSD, který byl zmiňován jako /mnt/osd1 v ConfigMap (přece používáme directory based osd.)

Krok za krokem kontrolujeme všechny uzly a opravujeme ConfigMapy. Po všech pokynech můžeme spustit pod Rook operátora a přečíst si jeho logy. A v nich je všechno skvělé:

já operátor clusteru;
našel jsem disky na uzlech;
našel jsem monitory;
monitory se spojily, tj. vytvořily kvórum;
spouštím nasazení OSD…

Znovu se podíváme do podu operátora Rook a zkontrolujeme stav clusteru… ano, trochu jsme se spletli s názvy OSD na některých uzlech! Nic se neděje: znovu jsme upravili ConfigMapy, odstranili nadbytečné adresáře od nových OSD a dostali se do dlouho očekávaného stavu HEALTH_OK!

Zkontrolujeme obrazy v poolu:

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

Všechno je na svém místě — cluster je zachráněn!

Jsem líný dělat zálohy, nebo Rychlá cesta

Pokud se zálohy pro Rook dělaly, pak je postup obnovy výrazně jednodušší a spočívá v následujícím:

Snížíme nasazení Rook operátora na nulu;
Odstraníme všechny deploymenty kromě Rook operátora;
Obnovíme ze zálohy všechny tajné klíče a ConfigMapy;
Obnovíme obsah adresářů /var/lib/rook/mon-* na uzlech;
Obnovíme (pokud jsme náhodou ztratili) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Opět zvětšíme nasazení Rook operátora na 1.

Užitečné tipy

Dělejte zálohy!

Abychom se vyhnuli situacím, kdy bude potřeba obnovit z nich:

Před rozsáhlými pracemi s clusterem, které zahrnují restartování serverů, snižte Rook operátora na nulu, aby nedělal zbytečnou práci.
Na monitory předem přidejte nodeAffinity.
Věnujte pozornost předběžným nastavení timeoutů ROOK_MON_HEALTHCHECK_INTERVAL a ROOK_MON_OUT_TIMEOUT.

Na závěr

Není důvod se hádat, že Rook, jakožto další "vrstva" (v celkové schématu organizace úložišť v Kubernetes), přináší jak zjednodušení, tak také nové složitosti a potenciální problémy v infrastruktuře. Je třeba učinit uváženou, zdůvodněnou volbu mezi těmito riziky na jedné straně a užitkem, který řešení přináší ve vašem konkrétním případě, na straně druhé.

Mimochodem, nedávno byla do dokumentace Rook přidána sekce „Adopt an existing Rook Ceph cluster into a new Kubernetes cluster“. Podrobněji zde popisuje, co je potřeba udělat, abyste migrovali stávající data do nového Kubernetes clusteru nebo obnovili fungování clusteru, který se z nějakého důvodu rozpadl.