Unsere Hände sind nicht zum Ausruhen: Wiederherstellung des Rook-Clusters in K8s

Wir bereits berichtet haben, warum wir Rook mögen: Es vereinfacht erheblich die Arbeit mit Speicherlösungen in Kubernetes-Clustern. Doch mit dieser Einfachheit kommen auch bestimmte Herausforderungen. Wir hoffen, dass das neue Material hilft, solche Herausforderungen besser zu verstehen, bevor sie auftreten.

Um das Lesen interessanter zu gestalten, beginnen wir mit den Folgen eines hypothetischen Problems im Cluster.

„Alles ist verloren!“

Stellen Sie sich vor, Sie haben einmal Rook in Ihrem K8s-Cluster eingerichtet und gestartet, und es hat zuverlässig funktioniert. Doch in einem „herrlichen“ Moment geschieht Folgendes:

• Neue Pods können RBD-Images aus Ceph nicht einbinden.
• Befehle wie lsblk und df funktionieren nicht auf den Kubernetes-Knoten. Das bedeutet automatisch: „Etwas stimmt nicht“ mit den RBD-Images, die auf die Knoten gemountet sind. Sie können nicht gelesen werden, was auf die Unerreichbarkeit der Monitore hinweist…
• Ja, im Cluster gibt es keine funktionierenden Monitore. Darüber hinaus gibt es weder Pods mit OSD noch einen Pod mit MGR.

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

Lassen Sie uns zunächst einen interessanteren, längeren Weg gehen und eine gründliche Untersuchung der «Innereien» von Rook durchführen, gefolgt von einer schrittweisen Wiederherstellung seiner Komponenten. Natürlich gibt es auch den kürzeren, richtigen Weg: die Verwendung von Backups. Wie bekannt ist, gibt es zwei Arten von Admins: die, die keine Backups machen, und die, die bereits welche machen… Aber darüber sprechen wir nach der Untersuchung.

Ein wenig Praxis, oder der lange Weg

Lassen Sie uns umsehen und die Monitore wiederherstellen

Schauen wir uns also die Liste der ConfigMaps an: Es gibt notwendige für die Sicherung rook-ceph-config und rook-config-override. Diese erscheinen bei erfolgreichem Deployment des Clusters.

NB: In neuen Versionen, nach Annahme dieser PR, sind die ConfigMaps kein Indikator mehr für den Erfolg des Deployments des Clusters.

Für die weiteren Schritte benötigen wir einen kompletten Neustart aller Server, auf denen gemountete RBD-Images vorhanden sind (ls /dev/rbd*). Dies muss über sysrq (oder „per Hand“ im Rechenzentrum) durchgeführt werden. Diese Anforderung ergibt sich aus der Notwendigkeit, die gemounteten RBD zu trennen, da ein regulärer Neustart nicht ausreicht (es wird erfolglos versucht, sie normal zu demontieren).

Das Theater beginnt mit der Garderobe, und der Ceph-Cluster beginnt mit den Monitoren. Lassen Sie uns einen Blick darauf werfen.

Rook montiert im Pod-Überwachungsdienst folgende Entitäten:

Volumes:
 rook-ceph-config:
   Typ:      ConfigMap (ein Volume, das durch eine ConfigMap gefüllt wird)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Typ:        Secret (ein Volume, das durch ein Secret gefüllt wird)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Typ:          HostPath (rohes Hostverzeichnis-Volume)
   Pfad:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Typ:          HostPath (rohes Hostverzeichnis-Volume)
   Pfad:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph von rook-ceph-config (ro)
  /etc/ceph/keyring-store/ von rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a von ceph-daemon-data (rw)
  /var/log/ceph von rook-ceph-log (rw)

Lassen Sie uns ansehen, was im Secret ist rook-ceph-mons-keyring:

art: Secret
daten:
 keyring: LongBase64EncodedString=

Dekodieren wir es, um den normalen Keyring mit Rechten für Admin und Monitore zu erhalten:

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

Das merken wir uns. Schauen wir uns jetzt den Keyring im Secret an rook-ceph-admin-keyring:

art: Secret
daten:
 keyring: anotherBase64EncodedString=

Was ist darin?

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

Der gleiche. Lassen Sie uns noch einmal nachsehen… Hier ist zum Beispiel das Secret rook-ceph-mgr-a-keyring:

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

Schließlich entdecken wir noch ein paar Geheimnisse im ConfigMap. rook-ceph-mon:

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

Und das ist die ursprüngliche Liste der Keyrings, aus denen alle oben beschriebenen Geheimnisse stammen.

Wie bekannt (siehe dataDirHostPath in Dokumentation.), speichert Rook solche Daten an zwei Orten. Lassen Sie uns also zu den Knoten gehen, um die Keyrings in den Verzeichnissen zu sehen, die in die Pods mit Monitoren und OSDs eingebunden sind. Dazu suchen wir auf den Knoten /var/lib/rook/mon-a/data/keyring und sehen:

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

Plötzlich stellt sich heraus, dass dieses Geheimnis anders ist als in den ConfigMaps.

Wie sieht es mit dem Admin-Keyring aus? Den haben wir auch:

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

Hier liegt das Problem. Es gab einen Ausfall: der Cluster wurde neu erstellt… aber in Wirklichkeit nicht.

Es wird klar, dass in den Geheimnissen neu generierte Keyrings gespeichert sind, und sie nicht stammen aus unserem alten Cluster. Daher:

• nehmen wir den Keyring vom Monitor aus der Datei /var/lib/rook/mon-a/data/keyring (oder aus einem Backup);
• ändern wir den Keyring im Geheimnis rook-ceph-mons-keyring;
• tragen wir den Keyring vom Admin und Monitor in das ConfigMap ein rook-ceph-mon;
• löschen wir die Controller der Pods mit Monitoren.

Das Wunder lässt nicht lange auf sich warten: Die Monitore erscheinen und starten. Hurra, der Anfang ist gemacht!

Wir stellen das OSD wieder her.

Gehen wir zum Pod rook-operator: Aufruf ceph mon dump zeigt, dass alle Monitore vorhanden sind, und ceph -s — dass sie im Quorum sind. Wenn wir uns jedoch den OSD-Baum ansehen (ceph osd tree), sehen wir etwas Seltsames: OSDs fangen an, zu erscheinen, sind aber leer. Es scheint, dass auch sie irgendwie wiederhergestellt werden müssen. Aber wie?

Inzwischen sind in den ConfigMaps die benötigten rook-ceph-config und rook-config-override, sowie zahlreiche andere ConfigMaps mit Namen wie rook-ceph-osd-$nodename-config. Schauen wir uns diese an:

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

Alles ist durcheinander!

Wir skalieren den Operator-Pod auf null, löschen die generierten Deployments der OSD-Pods und korrigieren diese ConfigMaps. Aber woher bekommen wir die richtige OSD-Karte nach Knoten?

• Lass uns erneut in die Verzeichnisse /mnt/osd[1-2] auf den Knoten stöbern — in der Hoffnung, dort etwas zu finden.
• Im Verzeichnis /mnt/osd1 es gibt 2 Unterverzeichnisse: osd0 und osd16. Letzteres ist doch genau die ID, die in der ConfigMap (16) angegeben ist?
• Lass uns die Größen überprüfen und sehen, dass osd0 es viel größer ist osd16.

Wir kommen zu dem Schluss, dass osd0 dies der benötigte OSD ist, der in der ConfigMap als /mnt/osd1 angegeben wurde (wir verwenden directory based osd.)

Schritt für Schritt überprüfen wir alle Knoten und korrigieren die ConfigMaps. Nach allen Änderungen kann der Rook-Operator-Pod gestartet und die Logs gelesen werden. Und darin ist alles hervorragend:

• ich bin der Cluster-Operator;
• Ich habe die Festplatten an den Knoten gefunden;
• Ich habe die Monitore gefunden;
• Die Monitore haben sich verbunden, das heißt, sie haben ein Quorum gebildet;
• Ich starte die OSD-Deployments…

Lass uns wieder in den Pod des Rook-Betreibers gehen und die Gesundheit des Clusters überprüfen… ja, wir haben ein wenig bei den Namen der OSD auf einigen Knoten irrtümlich geschlussfolgert! Keine Sorge: Wir haben die ConfigMaps erneut angepasst, überflüssige Verzeichnisse für die neuen OSDs entfernt und den sehnlichst erwarteten Zustand erreicht. HEALTH_OK!

Überprüfen wir die Images im 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
…

Alles ist an Ort und Stelle – der Cluster ist gerettet!

Ich bin faul, wenn es um Backups geht, oder der schnelle Weg

Wenn Backups für Rook erstellt wurden, wird der Wiederherstellungsprozess deutlich einfacher und beschränkt sich auf Folgendes:

1. Skalieren Sie das Deployment des Rook-Betreibers auf null;
2. Löschen Sie alle Deployments, außer dem Rook-Betreiber;
3. Stellen Sie alle Secrets und ConfigMaps aus dem Backup wieder her;
4. Stellen Sie den Inhalt der Verzeichnisse /var/lib/rook/mon-* an den Knoten wieder her;
5. Stellen Sie (falls verloren) CRDs wieder her CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Skalieren Sie das Deployment des Rook-Betreibers zurück auf 1.

Nützliche Tipps

Machen Sie Backups!

Und um Situationen zu vermeiden, in denen eine Wiederherstellung erforderlich wird:

1. Skalieren Sie vor umfangreichen Arbeiten am Cluster, die Neustarts von Servern beinhalten, den Rook-Betreiber auf null, damit er nichts Unnötiges tut.
2. Monitor vorab hinzufügen Fügen Sie nodeAffinity hinzu.
3. Achten Sie auf die vorherige Einstellung von Timeouts ROOK_MON_HEALTHCHECK_INTERVAL und ROOK_MON_OUT_TIMEOUT.

Abschließend

Es ist unbestreitbar, dass Rook, als zusätzliche "Schicht" (im Gesamtkonzept der Speicherorganisation in Kubernetes), zwar vieles vereinfacht, aber auch neue Komplikationen und potenzielle Probleme in der Infrastruktur schafft. Es bleibt die "kleine" Aufgabe, eine fundierte und gut abgewogene Entscheidung zwischen diesen Risiken auf der einen und den Vorteilen, die die Lösung in Ihrem spezifischen Fall bringt, auf der anderen Seite zu treffen.

Übrigens wurde kürzlich die Rook-Dokumentation um einen Abschnitt "Einen vorhandenen Rook Ceph-Cluster in einen neuen Kubernetes-Cluster übernehmen". Darin wird detaillierter beschrieben, was zu tun ist, um mit bestehenden Daten in einen neuen Kubernetes-Cluster umzuziehen oder den Betrieb eines Clusters wiederherzustellen, das aus verschiedenen Gründen ausgefallen ist.

P.S.

Lesen Sie auch in unserem Blog:

• «Rook oder nicht Rook — das ist hier die Frage»;
• «Rook ist ein „Self-Service“-Speicher für Kubernetes.»;
• «Longhorn, ein verteiltes Speicher-System für K8s von Rancher, wurde an die CNCF übergeben».
• «Wir erstellen persistenten Speicher mit Provisioning in Kubernetes auf Basis von Ceph.».

Quelle: habr.com