🥇Gure eskuak ez daude asperdurarako: Rook multzo bat leheneratzen K8etan

Dugu dagoeneko kontatua, nola/zergatik gustatzen zaigu Rook: nabarmen errazten du Kubernetes klusterretan biltegiratzearekin lan egitea. Hala ere, sinpletasun honekin zenbait zailtasun etortzen dira. Espero dugu material berriak horrelako konplexutasunak hobeto ulertzen lagunduko gaituela agertu aurretik.

Irakurtzeko interesgarriagoa izan dadin, has gaitezen ondorioak kluster batean arazo hipotetikoa.

"Dena galduta dago!"

Imajinatu behin Rook zure K8s klusterrean konfiguratu eta abiarazi duzula, bere lanarekin gustura geratu zinela, baina une "zoragarri" batean honako hau gertatzen da:

Pod berriek ezin dituzte Ceph-eko RBD irudiak muntatu.
Gustatzen diren taldeak lsblk и df ez exekutatu Kubernetes nodoetan. Horrek automatikoki esan nahi du: "zerbait gaizki dago" nodoetan muntatutako RBD irudiekin. Ezin ditut irakurri, eta horrek adierazten du monitoreak ez daudela erabilgarri...
Bai, ez dago klusterrean funtzionatzen duen monitorerik. Gainera, ez dago OSD edo MGR podekin ere.

Noiz jarri zen martxan poda? rook-ceph-operator? Duela ez hainbeste zabaldu zuten. Zergatik? Rook-operatoreak kluster berri bat egitea erabaki zuen... Nola berreskura ditzakegu orain klusterraren funtzionamendua eta bertan dauden datuak?

Lehenik eta behin, egin dezagun ibilbide luzeago eta interesgarri bat Rook-en "barrualdea"ri buruzko ikerketa sakon bat eginez eta bere osagaiak urratsez urrats zaharberrituz. Jakina, badago bide zuzen laburragoa: babeskopiak erabiltzea. Dakizuenez, administratzaileak bi motatan banatzen dira: babeskopiak egiten ez dituztenak, eta dagoeneko egiten dituztenak... Baina ikerketaren ostean gehiago.

Praktika pixka bat, edo bide luzea

Eman diezaiogun begirada inguruari eta berreskura ditzagun monitoreak

Beraz, ikus ditzagun ConfigMaps zerrenda: erreserba egiteko beharrezkoak daude rook-ceph-config и rook-config-override. Klusterra arrakastaz zabaltzean agertzen dira.

NB: Bertsio berrietan, onartu ondoren PR hau, ConfigMaps jada ez dira kluster inplementazioaren arrakastaren adierazle.

Ekintza gehiago egiteko, RBD irudiak muntatu dituzten zerbitzari guztiak gogor berrabiarazi behar ditugu (ls /dev/rbd*). Sysrq bidez egin behar da (edo "oinez" datu-zentrora). Baldintza hau muntatutako RBDak desmuntatzeko zereginak eragiten du, eta, horretarako, berrabiarazi estandarrak ez du funtzionatuko (normalean desmuntatzen saiatuko da arrakastarik gabe).

Antzerkia esekigailu batekin hasten da, eta Ceph klusterra monitoreekin hasten da. Ikus ditzagun.

Rook-ek entitate hauek muntatzen ditu monitore-ontzian:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (a volume populated by a ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (a volume populated by a Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

Ikus dezagun zer den sekretua rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Administratzaile eta monitoreentzako eskubideekin deskodetzen dugu eta ohiko giltza bat lortzen dugu:

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

Gogora dezagun. Ikus dezagun orain giltza-erraza isilpean rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Zer dago bertan?

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

Berdin. Ikus dezagun gehiago... Hona hemen, adibidez, sekretu bat rook-ceph-mgr-a-keyring:

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

ConfigMap-en sekretu batzuk aurkitzen ditugu azkenean rook-ceph-mon:

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

Eta hau da giltzadunen hasierako zerrenda, nondik datoz goian deskribatutako sekretu guztiak.

Jakina denez (ikus dataDirHostPath в dokumentazioa), Rook-ek bi lekutan gordetzen ditu halako datuak. Hori dela eta, goazen nodoetara monitoreak eta OSDak dituzten podetan muntatzen diren direktorioetan kokatutako giltza-ertzak aztertzeko. Horretarako, nodoetan aurkituko dugu /var/lib/rook/mon-a/data/keyring eta ikusiko dugu:

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

Bat-batean hemen sekretua ezberdina izan zen, ez ConfigMap-en bezala.

Zer gertatzen da administratzaileen giltzarria? Guk ere badugu:

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

Hor dago arazoa. Nolabaiteko akats bat gertatu zen: klusterra birsortu zen... baina errealitatean ez zen hala izan.

Argi geratzen da sortu berri diren giltza-giltzak sekretuetan gordetzen direla, eta haiek ez gure multzo zaharretik. Horregatik:

hartu monitorearen giltza-ertza fitxategitik /var/lib/rook/mon-a/data/keyring (edo babeskopiatik);
ezkutuan aldatu giltza-ertza rook-ceph-mons-keyring;
erregistratu giltza-erraza administratzailearengandik eta monitorizatu ConfigMap-en rook-ceph-mon;
kendu pod kontrolagailuak monitoreekin.

Miraria ez da luzatuko: monitoreak agertu eta martxan jarriko dira. Aupa, hasi da!

Berrezarri dezagun OSDa

Goazen podra rook-operator: erronka ceph mon dump monitore guztiak jarrita daudela erakusten du, eta ceph -s - quorumean daudela. Hala ere, OSD zuhaitzari begiratuz gero (ceph osd tree), zerbait arraroa ikusiko dugu bertan: OSDak agertzen hasi ziren, baina hutsik daude. Ematen du nolabait ere zaharberritu egin behar direla. Baina nola?

Bitartean, ConfigMaps-ek hainbeste behar ditugunak dauzkate orain rook-ceph-config и rook-config-override, baita beste hainbat ConfigMaps bezalako izenak dituztenak ere rook-ceph-osd-$nodename-config. Ikus ditzagun:

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

Dena gaizki dago, dena nahastuta!

Eskala ditzagun operadorearen poda zerora, ezaba ditzagun sortutako Deployment podak OSDtik eta zuzendu ConfigMaps hauek. Baina non lortu? zuzena OSD mapa nodoka?

Saia gaitezen berriro direktorioetan sakontzen /mnt/osd[1-2] korapiloetan - han zerbait harrapatzeko itxaropenarekin.
Katalogoan /mnt/osd1 2 azpidirektorio daude: osd0 и osd16. Azkena, zehazki, ConfigMap-en (16) adierazten den IDa da?
Ikus ditzagun neurriak eta ikus ditzagun osd0 askoz gehiago osd16.

Ondoriora gatoz osd0 - hau da beharrezkoa den OSDa, honela adierazi zena /mnt/osd1 ConfigMap-en (azken finean, erabiltzen dugu direktorioa oinarritutako osd.)

Pausoz pauso nodo guztiak egiaztatu eta ConfigMaps editatzen ditugu. Argibide guztien ondoren, pod Rook operadorea abiarazi eta bere erregistroak irakur ditzakezu. Eta horiei buruzko guztia zoragarria da:

Cluster operadorea naiz;
Nodoetan diskoak aurkitu ditut;
Monitoreak aurkitu ditut;
monitoreak lagun egin dira, hau da. quoruma osatu zuen;
OSD inplementazioak abiarazten ditut...

Sar gaitezen berriro Rook operadorearen podan eta egiaztatu klusterraren bizitasuna... bai, apur bat oker geunden nodo batzuetan OSD izenei buruzko ondorioekin! Arazorik ez: ConfigMaps-ak berriro zuzendu ditugu, OSD berrietatik alferrikako direktorioak kendu eta aspaldi itxarotako egoerara iritsi gara. HEALTH_OK!

Ikus ditzagun igerilekuko irudiak:

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

Dena dago lekuan - klusterra gordeta dago!

Alferra naiz eta babeskopiak egiten ditut, edo modu azkar batean

Rook-en babeskopiak egin badira, berreskuratze-prozedura askoz errazagoa izango da eta honela geratzen da:

Inplementazioaren Rook operadorea zerora eskalatzen dugu;
Inplementazio guztiak kentzen ditugu Rook operadorea izan ezik;
Babeskopiatik sekretu guztiak eta ConfigMaps berreskuratzen ditugu;
Direktorioen edukia leheneratzea /var/lib/rook/mon-* nodoetan;
CRD berreskuratzen dugu (bat-batean galdu baduzu). CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Eskala dezagun inplementazioko Rook operadorea 1era.

Baliagarria aholkuak

Egin babeskopiak!

Eta horietatik berreskuratu behar dituzun egoerak saihesteko:

Zerbitzariak berrabiaraztea dakarren kluster-ekin lan handia egin aurretik, eskalatu Rook operadorea zerora, beharrezkoak ez diren gauzarik egin ez dezan.
Monitoreei aldez aurretik gehitu nodeAffinity.
Erreparatu aurretiazkoari denbora-muga ezartzea ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

Horren ordez Ondorio baten

Rook-ek, "geruza" gehigarri bat izanik (Kubernetesen biltegiratzea antolatzeko eskema orokorrean), asko sinplifikatzen duela eta azpiegituran konplexutasun berriak eta arazo potentzialak gehitzen dituela ez du argudiatzeak. Egiteko gauza bakarra da arrisku horien artean, batetik, eta erabakiak zure kasuan ekartzen dituen onuren artean, bestetik, aukera orekatu eta informatua egitea.

Bide batez, duela gutxi Rook dokumentazioan gehitu zen atalean "Hartu lehendik dagoen Rook Ceph kluster bat Kubernetes kluster berri batean". Xehetasun handiagoz deskribatzen du zer egin behar den lehendik dauden datuak Kubernetes kluster berri batera eramateko edo arrazoi bategatik edo besteagatik kolapsatu den kluster baten funtzionamendua leheneratzeko.