🥇Duar tona nuk janë për të pritur: rikthimi i klasës Rook në K8s

Ne më parë kemi folur, si/pse na pëlqen Rook: në një masë të konsiderueshme, ai e lehtëson punën me ruajtjet në klasteret Kubernetes. Megjithatë, me këtë lehtësi vijnë edhe disa vështirësi. Shpresojmë që materiali i ri do të ndihmojë në kuptimin më të mirë të këtyre vështirësive para se ato të shfaqen.

Dhe për ta bërë leximin më interesant, le të fillojmë me pasojat e një problemi hipotetik në klaster.

«E gjithë prishur!»

Imagjinoni se një ditë keni konfiguruar dhe aktivizuar Rook në klasterin tuaj K8s, ai ju ka kënaqur me funksionimin e tij, por në ndonjë moment të «bukur» ndodh e siguiente:

Pod-et e reja nuk mund të montojnë imazhet RBD nga Ceph.
Komandat si lsblk dhe df nuk funksionojnë në nyjat Kubernetes. Kjo automatikisht do të thotë: «diçka nuk është në rregull» me imazhet RBD të montuara në nyja. Nuk mund t'i lexoni ato, që tregon për mungesën e monitorëve...
Po, në klaster nuk ka monitorë funksionalë. Për më tepër – nuk ka asnjë pod me OSD, as një pod MGR.

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

Fillimisht, le të ndjekim një rrugë më të gjatë dhe interesante, duke kryer një hetim të thellë mbi «aparatet» e Rook dhe rikuperimin hap pas hapi të komponentëve të tij. Sigurisht, ka dhe një rrugë më të shkurtër të duhur: përdorimi i backup-eve. Siç dihet, administratorët ndahen në dy lloje: ata që nuk bëjnë backup-e dhe ata që tashmë i bëjnë... Por për këtë – pas hetimit.

Pak praktikë, ose Rruga e Gjatë

Të shqyrtojmë dhe të rikuperojmë monitorët

Pra, le të shohim listën e ConfigMap-eve: aty janë ato të nevojshme për rezervim rook-ceph-config dhe rook-config-override. Ato shfaqen pas një deploy të suksesshëm të klasterit.

NB: Në versionet e reja, pas miratimit të këtij PR, ConfigMap-et nuk janë më tregues të suksesit të deploy të klasterit.

Për të vazhduar më tej, kemi nevojë për një ribut të fortë të të gjithë serverëve ku janë montuar imazhet RBD (ls /dev/rbd*). Kjo duhet të bëhet përmes sysrq (ose «me këmbë» në DC). Ky kërkesë është shkaktuar nga nevoja për të shkëputur imazhet RBD të montuara, për arsye se ributi standard nuk do të funksionojë (do të përpiqet të shkëputë normalisht pa sukses).

Teatri fillon me varëse, ndërsa klasteri Ceph fillon me monitorët. Le të shohim ata.

Rook monte në pod-in e monitorit këto entitete:

Vëllimet:
 rook-ceph-config:
   Lloji:      ConfigMap (një vëllim i populluar nga një ConfigMap)
   Emri:      rook-ceph-config
 rook-ceph-mons-keyring:
   Lloji:        Sekret (një vëllim i populluar nga një sekret)
   EmriSekret:  rook-ceph-mons-keyring
 rook-ceph-log:
   Lloji:          HostPath (vëllim i drejtpërdrejtë nga dosja e hostit)
   Rruga:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Lloji:          HostPath (vëllim i drejtpërdrejtë nga dosja e hostit)
   Rruga:          /var/lib/rook/mon-a/data
Mundësitë:
  /etc/ceph nga rook-ceph-config (ro)
  /etc/ceph/keyring-store/ nga rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a nga ceph-daemon-data (rw)
  /var/log/ceph nga rook-ceph-log (rw)

Le të shohim çfarë ka në sekret rook-ceph-mons-keyring:

lloji: Sekret
data:
 keyring: LongBase64EncodedString=

Dekodojmë dhe marrim një keyring të zakonshëm me të drejta për administratorin dhe monitorët:

[mon.]
       çelësi = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       kapacitetet mon = "lejo *"
[client.admin]
       çelësi = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       kapacitetet mds = "lejo *"
       kapacitetet mon = "lejo *"
       kapacitetet osd = "lejo *"
       kapacitetet mgr = "lejo *"

Le të mbajmë mend. Tani le të shohim keyring në sekretin rook-ceph-admin-keyring:

lloji: Sekret
data:
 keyring: anotherBase64EncodedString=

Çfarë ka në të?

[client.admin]
       çelësi = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       kapacitetet mds = "lejo *"
       kapacitetet mon = "lejo *"
       kapacitetet osd = "lejo *"
       kapacitetet mgr = "lejo *"

I njëjti. Shikojmë më shumë… Ja, për shembull, sekret rook-ceph-mgr-a-keyring:

[mgr.a]
       çelësi = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       kapacitetet mon = "lejo *"
       kapacitetet mds = "lejo *"
       kapacitetet osd = "lejo *"

Në përfundim, ne gjejmë disa sekrete të tjera në ConfigMap rook-ceph-mon:

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

Dhe kjo është lista fillestare me keyring, nga ku e marrin të gjitha sekretet e përmendura më parë.

Siç dihet (shih dataDirHostPath në dokumentacionin), Rook ruan këto të dhëna në dy vende. Prandaj, le të shkojmë në nodet për të parë keyring që ndodhen në katalogët, të cilët janë montuar në pod-et me monitorët dhe OSD. Për këtë, le të kërkojmë në nodet /var/lib/rook/mon-a/data/keyring dhe të shohim:

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

Papritur këtu sekreti ishte ndryshe — ndryshe nga ConfigMap-et.

Po çfarë ndodh me keyring-in administrativ? E kemi edhe atë:

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

Ja këtu është problemi. Ka ndodhur një dështim: klasteri u rindërtua… por në të vërtetë nuk është.

Bëhet e qartë se në sekrete ruhen keyring të rinj të gjeneruar, dhe ata jo nga klasteri ynë i vjetër. Prandaj:

marrim keyring nga monitori nga skedari /var/lib/rook/mon-a/data/keyring (ose nga backup);
ndryshojmë keyring në sekret rook-ceph-mons-keyring;
shkruajmë keyring-in e administratorit dhe monitorit në ConfigMap rook-ceph-mon;
fshijmë kontrollorët e pod-eve me monitorët.

Mrekulli nuk do të vonojë: monitorët do të shfaqen dhe do të nisin. Hurra, fillimi është bërë!

Do të rikthejmë OSD

Hymë në pod rook-operator: thirrja ceph mon dump tregon se të gjithë monitorët janë në vend, dhe ceph -s — për faktin se ata janë në kuorum. Megjithatë, nëse shohim pemën OSD (ceph osd tree), do të shohim diçka të çuditshme: OSD-të filluan të shfaqen, por ato janë bosh. Kjo do të thotë se duhet t'i rikuperojmë ndonjëherë. Por si?

Ndërkohë, në ConfigMap janë shfaqur ato që na duhen rook-ceph-config dhe rook-config-override, si dhe një sërë ConfigMap-esh me emra të tillë si rook-ceph-osd-$nodename-config. Le të shohim në to:

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

Çdo gjë nuk është siç duhet, çdo gjë është e përzier!

Do të rikthejmë në zero pod-in e operatorit, do të fshijmë Deployment-et e gjeneruara të pod-eve me OSD dhe do ta rregullojmë këtë ConfigMap. Por nga e marrim hartën e saktë të OSD-së sipas nyjeve?

Le t'i hedhim një tjetër shikim drejtimeve /mnt/osd[1-2] në nyjet — me shpresën se do të gjejmë diçka.
Në katalog /mnt/osd1 ka 2 nënkatalogë: osd0 dhe osd16. I fundit — a nuk është ky ID që është cituar në ConfigMap (16)?
Le të kontrollojmë sipas madhësive dhe do të shohim që osd0 është shumë më shumë osd16.

Arrijmë në përfundimin se osd0 ky është OSD që na duheshin, siç ishte e cituar si /mnt/osd1 në ConfigMap (pasi ne përdorim directory based osd.)

Hapa pas hapi kontrollojmë të gjitha nyjet dhe rregullojmë ConfigMap-të. Pas të gjitha udhëzimeve, mund të nisim pod-in e Rook-operatorit dhe të lexojmë log-et e tij. Dhe aty është gjithçka në rregull:

unë jam operatori i klasterit;
kam gjetur diskët në nyje;
kam gjetur monitorët;
monitorët u lidhën, dmth. formuan kuorum;
po nis zbatimet e OSD…

Përsëri le të hyjmë në pod-in e operatorit Rook dhe të kontrollojmë gjallërinë e klasterit… po, kemi bërë disa gabime në përfundimet për emrat e OSD në disa nyje! Nuk ka të bëjë: sërish rregulluam ConfigMap-et, fshijmë katalogët e tepërt të OSD të rinj dhe arritëm në gjendjen e shumëpritur HEALTH_OK!

Le të kontrollojmë imazhet në 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
…

Çdo gjë është në vend — klasteri është shpëtuar!

Unë jam lenxhues në bëjen e backup-eve, ose rruga e shpejtë

Nëse backup-e për Rook janë bërë, procedura e rikuperimit bëhet ndjeshëm më e thjeshtë dhe reduktohet në këtë:

Shkallojmë në zero deployment-in e Rook-operatorit;
Fshijmë të gjitha zbatimet përveç Rook-operatorit;
Rikuperojmë të gjitha secret-ët dhe ConfigMap-ët nga backup-i;
Rikuperojmë përmbajtjen e drejtimeve /var/lib/rook/mon-* në nyje;
Rikuperojmë (nëse ndodhi që i humbëm) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Rikthejmë në rritje deployment-in e Rook-operatorit në 1.

Këshilla të dobishme

Bëni backup-e!

Dhe për të shmangur situatat kur do të nevojitet rikuperimi nga ato:

Para punëve masive me klasterin, përfshirë rilodhjet e serverëve, rritni në zero Rook-operatorët, në mënyrë që të mos bëjnë tepër.
Për monitorët paraprakisht shtoni nodeAffinity.
Dëni vëmendje konfigurimit të avancuar të kohëzgjatjeve ROOK_MON_HEALTHCHECK_INTERVAL dhe ROOK_MON_OUT_TIMEOUT.

Në përfundim

Nuk ka kuptim të diskutosh se Rook, si një "shtresë" shtesë (në strukturën e organizimit të ruajtjeve në Kubernetes), sa e thjeshton kaq shumë, ka gjithashtu edhe disa komplekse dhe probleme potenciale në infrastrukturë. Çështja mbetet te "e vogla": të bëni një zgjedhje të balancuar dhe të arsyeshme mes këtyre rreziqeve nga njëra anë dhe përfitimeve që ky zgjidhje sjell në rastin tuaj të veçantë, nga ana tjetër.

Për më tepër, së fundmi në dokumentacionin e Rook u shtua seksioni "Adopt an existing Rook Ceph cluster into a new Kubernetes cluster". Aty përshkruhet më hollësisht se çfarë duhet bërë për të migruar të dhënat ekzistuese në një klasë të re Kubernetes ose për të rikthyer funksionimin e një klase të shkërmoqur për ndonjë arsye.