🥇Mikono yetu si ya kuchosha: kurejesha kundi la Rook katika K8s

Sisi tayari aliiambia, vipi/kwa nini tunapenda Rook: hurahisisha sana kufanya kazi na hifadhi katika makundi ya Kubernetes. Walakini, kwa unyenyekevu huu huja shida fulani. Tunatumahi kuwa nyenzo mpya itatusaidia kuelewa vyema ugumu kama huo kabla ya kujidhihirisha.

Ili kuifanya iwe ya kuvutia zaidi kusoma, wacha tuanze na matokeo tatizo la dhahania katika nguzo.

"Kila kitu kimepotea!"

Fikiria kuwa uliwahi kusanidi na kuzindua Rook katika nguzo yako ya K8s, ilikufurahisha na kazi yake, lakini kwa wakati fulani "wa ajabu" yafuatayo hutokea:

Maganda mapya hayawezi kupachika picha za RBD kutoka Ceph.
Timu kama lsblk и df usikimbie kwenye nodi za Kubernetes. Hii inamaanisha kiotomatiki: "kuna kitu kibaya" na picha za RBD zilizowekwa kwenye nodi. Siwezi kuzisoma, ambayo inaonyesha kuwa wachunguzi hawapatikani ...
Ndio, hakuna wachunguzi wanaofanya kazi kwenye nguzo. Zaidi ya hayo, hakuna hata maganda yenye ganda la OSD au MGR.

Jengo lilizinduliwa lini? rook-ceph-operator? Si muda mrefu uliopita alitumwa. Kwa nini? Rook-operator aliamua kutengeneza nguzo mpya... Tunawezaje sasa kurejesha utendakazi wa nguzo na data iliyomo?

Kwanza, hebu tuchukue njia ndefu, ya kuvutia kwa kufanya uchunguzi wa kufikiri juu ya "insides" ya Rook na urejesho wa hatua kwa hatua wa vipengele vyake. Bila shaka, kuna njia fupi sahihi: kutumia chelezo. Kama unavyojua, wasimamizi wamegawanywa katika aina mbili: wale ambao hawafanyi nakala rudufu, na wale ambao tayari wanafanya ... Lakini zaidi juu ya hili baada ya uchunguzi.

Mazoezi kidogo, au njia ndefu

Hebu tuangalie karibu na kurejesha wachunguzi

Kwa hivyo, hebu tuangalie orodha ya ConfigMaps: kuna zile zinazohitajika kwa uhifadhi rook-ceph-config и rook-config-override. Wanaonekana baada ya kusambaza kwa mafanikio kwa nguzo.

NB: Katika matoleo mapya, baada ya kukubalika hii PR, ConfigMaps sio kiashirio tena cha mafanikio ya uwekaji wa nguzo.

Ili kufanya vitendo zaidi, tunahitaji kuwasha upya kwa bidii seva zote ambazo zimepachika picha za RBD (ls /dev/rbd*) Lazima ifanyike kupitia sysrq (au "kwa miguu" hadi kituo cha data). Mahitaji haya yanasababishwa na kazi ya kuteremsha RBD zilizowekwa, ambazo kuwasha upya kwa kawaida haitafanya kazi (itajaribu bila mafanikio kuzishusha kawaida).

Ukumbi wa michezo huanza na hanger, na nguzo ya Ceph huanza na wachunguzi. Hebu tuwaangalie.

Rook huweka huluki zifuatazo kwenye ganda la ufuatiliaji:

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)

Wacha tuone ni siri gani rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Tunasimbua na kupata ufunguo wa kawaida wenye haki za msimamizi na wachunguzi:

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

Hebu tukumbuke. Sasa hebu tuangalie ufunguo kwa siri rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Kuna nini ndani yake?

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

Sawa. Hebu tuone zaidi ... Hapa, kwa mfano, ni siri rook-ceph-mgr-a-keyring:

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

Tunaishia kupata siri chache zaidi kwenye ConfigMap rook-ceph-mon:

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

Na hii ndiyo orodha ya awali na keyrings, ambapo siri zote zilizoelezwa hapo juu zinatoka.

Kama inavyojulikana (tazama dataDirHostPath в nyaraka), Rook huhifadhi data kama hizo katika sehemu mbili. Kwa hivyo, hebu tuende kwenye nodi ili tuangalie vitufe vilivyo kwenye saraka ambazo zimewekwa kwenye maganda na wachunguzi na OSD. Ili kufanya hivyo, tunapata kwenye nodes /var/lib/rook/mon-a/data/keyring na tutaona:

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

Ghafla hapa siri iligeuka kuwa tofauti - sio kama kwenye ConfigMap's.

Vipi kuhusu ufunguo wa msimamizi? Pia tunayo:

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

Hapa ndipo penye tatizo. Aina fulani ya hitilafu ilitokea: nguzo iliundwa upya... lakini kwa kweli haikuwa hivyo.

Inakuwa wazi kwamba keyrings wapya yanayotokana ni kuhifadhiwa katika siri, na wao hakuna kutoka kwa nguzo yetu ya zamani. Ndiyo maana:

kuchukua keyring kutoka kufuatilia kutoka faili /var/lib/rook/mon-a/data/keyring (au kutoka kwa chelezo);
badilisha ufunguo kwa siri rook-ceph-mons-keyring;
sajili ufunguo kutoka kwa msimamizi na ufuatiliaji katika ConfigMap rook-ceph-mon;
ondoa vidhibiti vya pod na wachunguzi.

Muujiza hautachukua muda mrefu kuja: wachunguzi wataonekana na kuanza. Hurray, mwanzo umefanywa!

Wacha turudishe OSD

Twende kwenye ganda rook-operator: changamoto ceph mon dump inaonyesha kuwa wachunguzi wote wapo, na ceph -s - kwamba wako katika akidi. Walakini, ukiangalia mti wa OSD (ceph osd tree), tutaona kitu cha ajabu ndani yake: OSD zilianza kuonekana, lakini ni tupu. Inatokea kwamba pia wanahitaji kurejeshwa kwa namna fulani. Lakini jinsi gani?

Wakati huo huo, ConfigMaps sasa ina zile tunazohitaji sana rook-ceph-config и rook-config-override, pamoja na ConfigMaps nyingine nyingi zilizo na majina kama rook-ceph-osd-$nodename-config. Hebu tuwaangalie:

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

Kila kitu kibaya, kila kitu kimechanganywa!

Hebu tuongeze maganda ya waendeshaji hadi sufuri, tufute maganda ya Usambazaji yaliyozalishwa kutoka kwa OSD na kurekebisha ConfigMaps hizi. Lakini wapi kupata? sahihi Ramani ya OSD kwa nodi?

Wacha tujaribu kuchimba tena saraka /mnt/osd[1-2] kwenye mafundo - kwa matumaini kwamba tunaweza kupata kitu hapo.
Katika orodha /mnt/osd1 kuna saraka ndogo 2: osd0 и osd16. Cha mwisho ndicho kitambulisho ambacho kimeonyeshwa katika ConfigMap (16)?
Wacha tuangalie saizi na tuone osd0 mengi zaidi osd16.

Tunafikia hitimisho kwamba osd0 - hii ndiyo OSD inayohitajika, ambayo ilionyeshwa kama /mnt/osd1 katika ConfigMap (baada ya yote, tunatumia saraka kulingana na osd.)

Hatua kwa hatua tunaangalia nodi zote na kuhariri ConfigMaps. Baada ya maagizo yote, unaweza kuzindua operator wa pod Rook na kusoma kumbukumbu zake. Na kila kitu juu yao ni nzuri:

Mimi ni mwendeshaji wa nguzo;
Nilipata diski kwenye nodi;
Nilipata wachunguzi;
wachunguzi wamekuwa marafiki, i.e. aliunda akidi;
Ninazindua uwekaji wa OSD...

Hebu tuingie kwenye ganda la waendeshaji wa Rook tena na tuangalie uhai wa nguzo... ndiyo, tulikosea kidogo na hitimisho kuhusu majina ya OSD kwenye baadhi ya nodi! Hakuna tatizo: tulisahihisha ConfigMaps tena, tukaondoa saraka zisizo za lazima kutoka kwa OSD mpya na kufika katika hali iliyosubiriwa kwa muda mrefu. HEALTH_OK!

Wacha tuangalie picha kwenye bwawa:

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

Kila kitu kiko mahali - nguzo imehifadhiwa!

Mimi ni mvivu na kutengeneza chelezo, au njia ya haraka

Ikiwa nakala rudufu zimetengenezwa kwa Rook, basi utaratibu wa urejeshaji unakuwa rahisi zaidi na unapita kwa zifuatazo:

Tunapunguza opereta wa Rook ya kupeleka hadi sifuri;
Tunaondoa upelekaji wote isipokuwa opereta wa Rook;
Tunarejesha siri zote na ConfigMaps kutoka kwa nakala rudufu;
Kurejesha yaliyomo kwenye saraka /var/lib/rook/mon-* kwenye nodes;
Tunarejesha (ikiwa umepoteza ghafla) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Wacha tupunguze nyuma kiendeshaji cha Rook hadi 1.

Useful Tips

Tengeneza chelezo!

Na ili kuzuia hali wakati unahitaji kurejesha kutoka kwao:

Kabla ya kufanya kazi kwa kiwango kikubwa na nguzo, ambayo inahusisha kuwasha upya seva, ongeza opereta wa Rook hadi sifuri ili isifanye mambo yasiyo ya lazima.
Kwa wachunguzi mapema ongeza nodeAffinity.
Makini na utangulizi kuweka muda ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

Badala ya hitimisho

Hakuna maana ya kubishana kwamba Rook, kuwa "safu" ya ziada (katika mpango wa jumla wa kuandaa uhifadhi huko Kubernetes), zote hurahisisha sana na kuongeza ugumu mpya na shida zinazowezekana katika miundombinu. Kitu pekee kilichosalia kufanya ni kufanya uchaguzi wenye usawaziko, wenye ujuzi kati ya hatari hizi, kwa upande mmoja, na faida ambazo uamuzi huleta katika kesi yako, kwa upande mwingine.

Kwa njia, hivi karibuni katika nyaraka za Rook iliongezwa sehemu ya "Pitisha nguzo iliyopo ya Rook Ceph kwenye nguzo mpya ya Kubernetes". Inaelezea kwa undani zaidi kile kinachohitajika kufanywa ili kuhamisha data iliyopo hadi kwenye kikundi kipya cha Kubernetes au kurejesha utendakazi wa nguzo ambayo imeporomoka kwa sababu moja au nyingine.