🥇Vores hænder er ikke til dovenskab: genoprettelse af Rook-kluster i K8s

Vi allerede fortalt, hvordan / hvorfor vi kan lide Rook: det letter i høj grad arbejdet med lagringssystemer i Kubernetes-klynger. Men med denne enkelhed følger der også visse udfordringer. Vi håber, det nye materiale vil hjælpe med at forstå disse udfordringer, inden de melder sig.

Og for at gøre læsningen mere interessant, lad os starte med konsekvenserne af et hypotetisk problem i klyngen.

«Alt er tabt!»

Forestil dig, at du en dag har konfigureret og lanceret Rook i din K8s-klynge. Det har fungeret helt fint, men på et ‘skønt’ tidspunkt sker følgende:

Nye pods kan ikke montere RBD-billeder fra Ceph.
Beskeder som lsblk og df fungerer ikke på Kubernetes-noderne. Dette betyder automatisk: «noget er galt» med de monterede RBD-billeder. De kan ikke læses, hvilket indikerer utilgængelighed af overvågerne...
Ja, der er ingen fungerende overvågere i klyngen. Desuden er der ikke engang nogen pods med OSD eller en pod med MGR.

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

blev startet, lad os tage en mere interessant og længere vej ved at lave en grundig undersøgelse af Rooks «indre dele» og genoprette dens komponenter trin for trin. Selvfølgelig er der også en kortere og mere korrekt vej: brugen af backup. Som det er kendt, deles administratorer op i to typer: dem, der ikke tager backups, og dem, som allerede gør det... Men mere om det efter undersøgelsen.

Lidt praksis, eller Den lange vej

Lad os se os omkring og genoprette overvågerne

Så lad os se på listen over ConfigMaps: der er nødvendige til reservedele rook-ceph-config og rook-config-override. De optræder ved en succesfuld deployment af klyngen.

NB: I de nye versioner, efter vedtagelsen af denne PR, er ConfigMaps ikke længere indikatorer for succes ved deployment af klyngen.

For at udføre de næste handlinger har vi brug for en hård genstart af alle servere, hvor monterede RBD-billeder er til stede (ls /dev/rbd*). Det skal udføres via sysrq (eller ‘til fods’ i datacentret). Dette krav skyldes behovet for at frakoble de monterede RBD, da en normal genstart ikke vil være effektiv (det vil mislykkes at forsøge at afmontere dem korrekt).

Teateret begynder med en knagerække, og Ceph-klyngen begynder med overvågerne. Lad os se på dem.

Rook monterer i monitorpodden sådanne entiteter:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (et volume, der er fyldt med et ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (et volume, der er fyldt med en Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (bare hostdirectory volume)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (bare hostdirectory 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)

Lad os se, hvad der er i hemmeligheden rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

Vi dekoder og får en almindelig keyring med rettigheder til admin og monitorer:

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

Lad os huske det. Og nu skal vi se på keyring i hemmeligheden rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

Hvad er der i den?

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

Den samme. Lad os se lidt mere… Her er for eksempel en hemmelighed rook-ceph-mgr-a-keyring:

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

I sidste ende finder vi nogle flere hemmeligheder i ConfigMap'en rook-ceph-mon:

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

Og dette er den oprindelige liste af keyring'er, hvorfra alle de ovenfor beskrevne hemmeligheder stammer.

Som det er kendt (se dataDirHostPath i dokumentationen), gemmer Rook sådanne data på to steder. Så lad os tage et kig på noderne for at se på keyrings, der ligger i mapperne, som er monteret i pods med monitorer og OSD. For dette finder vi på noderne /var/lib/rook/mon-a/data/keyring og vi ser:

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

Pludselig var denne hemmelighed en anden — ikke som i ConfigMap'ene.

Hvad med admin keyring'en? Den har vi også:

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

Her er problemet. Der er sket en eller anden fejl: clusteren blev genskabt… men i virkeligheden ikke.

Det bliver klart, at der i hemmelighederne opbevares nygenererede keyrings, og de ikke er fra vores gamle cluster. Derfor:

tager vi keyring fra monitoren fra filen /var/lib/rook/mon-a/data/keyring (eller fra backup);
ændrer keyring i hemmeligheden rook-ceph-mons-keyring;
opdaterer keyring fra admin og monitoren i ConfigMap'en rook-ceph-mon;
fjerner controllerne af pods med monitorer.

Miraklet lader ikke vente på sig: monitorerne vil komme og starte. Hurra, starten er sat!

Lad os genoprette OSD

Vi går ind i pod'en rook-operator: kald ceph mon dump viser, at alle monitorer er på plads, og ceph -s — til at de er i quorum. Men hvis vi ser på OSD-træet (ceph osd tree), vil vi se noget underligt: OSD'erne begynder at dukke op, men de er tomme. Så de skal også på en eller anden måde genskabes. Men hvordan?

Imens er de nødvendige ConfigMaps dukket op, rook-ceph-config og rook-config-override, samt mange andre ConfigMaps med navne af typen rook-ceph-osd-$nodename-config. Lad os kigge i dem:

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

Det er ikke rigtigt, alt er forvirret!

Lad os scale pod-operatøren ned til nul, slette de genererede deployment'er af pod'ene med OSD, og rette disse ConfigMaps. Men hvor får vi det rigtige OSD-kort per noden?

Lad os prøve at lede igen i mapperne /mnt/osd[1-2] på noderne — i håbet om, at vi kan finde noget.
I mappen /mnt/osd1 der er 2 undermapper: osd0 og osd16. Den sidste — er det ikke lige den ID, der er angivet i ConfigMap (16)?
Lad os kontrollere størrelserne og se, at osd0 den er meget større osd16.

Vi konkluderer, at osd0 — det er faktisk den OSD, der blev angivet som /mnt/osd1 i ConfigMap (for vi bruger directory based osd.)

Step by step tjekker vi alle noder og retter ConfigMaps. Efter alle anvisninger kan vi starte pod Rook-operatøren og læse dens logs. Og i dem er alt fantastisk:

jeg er cluster-operatør;
jeg har fundet diske på noderne;
jeg har fundet monitorer;
monitorerne er blevet venner, det vil sige, de dannede quorum;
jeg starter OSD-deployments…

Lad os igen gå ind i pod-operatøren Rook og tjekke livligheden af clusteren… ja, vi var lidt forkerte med vores konklusioner om OSD-navne på nogle noder! Ikke et problem: vi har rettet ConfigMaps igen, slettet overflødige mapper fra de nye OSD'er og nåede til den eftertragtede tilstand HEALTH_OK!

Lad os tjekke billederne i puljen:

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

Alt er på plads — clusteren er reddet!

Jeg er doven med at lave backups, eller Den hurtige vej

Hvis backups for Rook blev lavet, så bliver genskabelsesproceduren meget lettere og reduceres til følgende:

Vi skalerer deployment Rook-operatøren ned til nul;
Vi sletter alle deployments undtagen Rook-operatøren;
Vi genskaber alle secrets og ConfigMaps fra backup;
Vi genskaber indholdet af mapperne /var/lib/rook/mon-* på noderne;
Vi genskaber (hvis vi har mistet) CRD'en CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Vi skalerer deployment Rook-operatøren tilbage til 1.

Nyttige tips

Lav backups!

Og for at undgå situationer, hvor genskabelse er nødvendig:

Før store arbejder med clusteren, der involverer genstart af servere, skal du skalerer Rook-operatøren ned til nul, så den ikke laver ekstra arbejde.
Til monitorerne skal du på forhånd tilføje nodeAffinity.
Vær opmærksom på den forudgående timeout-opsætning ROOK_MON_HEALTHCHECK_INTERVAL og ROOK_MON_OUT_TIMEOUT.

Afslutning

Der er ingen mening i at diskutere, at Rook, som en ekstra "lag" (i den overordnede struktur for opbevaring i Kubernetes), både forenkler mange processer, men også kan tilføje nye kompleksiteter og potentielle problemer i infrastrukturen. Spørgsmålet står tilbage for at træffe et afbalanceret og begrundet valg mellem disse risici på den ene side og de fordele, løsningen bringer i dit specifikke tilfælde, på den anden.

Forresten blev der for nylig tilføjet en sektion "Adopt an existing Rook Ceph cluster into a new Kubernetes cluster" i Rook-dokumentationen. Her forklares i detaljer, hvad der skal gøres for at overføre eksisterende data til en ny Kubernetes-kluster eller for at genoprette en kluster, der er brudt sammen af en eller anden grund.