Englische Version 

Bereits Ende 2018 habe ich einen kompakten Ceph-Cluster mit ODROID-Boards und Ubuntu 18.04 umgesetzt. Das war praktisch, lehrreich, etwas anfällig und äußerst befriedigend.

Im Jahr 2025 nahm ich diese Konfiguration außer Betrieb und übertrug die gleichen Speicherkonzepte mithilfe von Rook in ein Kubernetes-natives Modell. Dieser Beitrag behandelt rückblickend, wie die ursprüngliche Konfiguration aussah und wie sich das Betriebsmodell veränderte, nachdem die Orchestrierung auf Kubernetes umgestellt wurde.

2018: Die ursprüngliche ODROID-Ceph-Anleitung

Der alte Cluster war bewusst explizit und manuell aufgebaut:

• 4 ODROID-HC1-Knoten für OSD-intensive Aufgaben
• 1 ODROID-C2 für Monitor-, MDS- und Manager-Aufgaben
• Überall minimale Ubuntu 18.04-Images
• Statische IPs und /etc/hosts-Einträge auf jedem Knoten
• cephuser, passwortloses sudo, SSH-Schlüsselverteilung, NTP-Einrichtung
• Manuelle Festplattenvorbereitung (parted, mkfs.xfs, ceph-deploy disk zap)
• Cluster-Bootstrap mit ceph-deploy

Der Ablauf sah wie folgt aus:

1. Jedes Board vorbereiten und Hostnamen/Netzwerkkonfiguration abstimmen.
2. Vertrauenspfade erstellen (ssh-keyscan, ssh-copy-id) von ceph-admin.
3. Manuelles Formatieren der /dev/sda-Geräte auf allen OSD-Knoten.
4. Ausführen von ceph-deploy new, Bearbeiten von ceph.conf, Installieren der Daemons.
5. Erstellen von Monitor, OSDs, MDS und Manager.
6. Überprüfen Sie den Zustand (ceph -s) und mounten Sie CephFS auf einem Client.

Es hat funktioniert. Ich habe viel dabei gelernt. Außerdem fühlte sich jeder Neuaufbau wie ein Ritual an.

Die Schwachstellen des Setups

Für einen Cluster im Home-Lab-Maßstab war die Konfiguration in Ordnung. Mit der Zeit dominierten jedoch folgende Schwachstellen:

• Der Lebenszyklus der Knoten bestand größtenteils aus imperativen Shell-Befehlen.
• Abweichungen auf Host-Ebene traten leicht auf (Pakete, Konfigurationen, SSH-Vertrauen, Uhrensynchronisation).
• Wiederherstellungsschritte befanden sich im Gedächtnis und in alten Notizen.
• Die Betriebsabsicht war nicht deklarativ; der Zustand musste rekonstruiert werden.
• Das Cluster-Management blieb von der Anwendungsplanung getrennt.

Das Cluster war stabil, aber nicht flexibel genug.

Weshalb Rook und Kubernetes die passende Lösung wurden

Rook verwandelte Ceph-Operationen in Kubernetes-Ressourcen:

• Der gewünschte Zustand wurde in YAML übertragen (CephCluster, CephBlockPool, CephFilesystem, StorageClass).
• Die Abgleichung ersetzte einmalige Befehlsausführungen.
• Day-2-Ops wurden in dieselbe Steuerungsebene wie die Workloads integriert.
• Speichernutzer (PVCs) wurden zu First-Class-Komponenten und selbstverwaltbar.
• Upgrades und die Platzierung von Komponenten wurden übersichtlicher.

Kurz gesagt: von handgefertigten „Haustieren“ zu deklarativen „Nutzvieh“, unter Beibehaltung der Speichersemantik von Ceph.

Die Verbindung zwischen alter und neuer Architektur

Am einfachsten lässt sich die Transformation anhand eines Vergleichs erklären:

• ceph-deploy new mon1 -> CephCluster CR auf den Cluster angewendet
• Manuelle Platzierung von Monitor/Manager -> mon.count, Platzierungsregeln im CR
• ceph-deploy osd create ... --data /dev/sda -> storage.nodes[].devices[] in der Rook-Konfiguration
• ceph -s über SSH -> kubectl -n rook-ceph get cephcluster + Toolbox-Prüfungen
• Manueller CephFS-Mount-Befehl -> PVC, gestützt durch CephFS StorageClass

Das mentale Modell änderte sich von „Führe diesen Befehl auf diesem Knoten aus“ zu „Lege fest, wie der Cluster aussehen soll, und führe dann die Abstimmung durch.“

Ein praktischer Migrationsbogen (was bei mir funktioniert hat)

Ich habe den alten Cluster nicht „in situ konvertiert“. Ich habe es als kontrollierten Austausch behandelt:

1. Kubernetes auf ODROID-fähigen Knoten einrichten.
2. Rook-Ceph-Operator und eine neue Ceph-Clusterdefinition bereitstellen.
3. Neue Pools/Dateisysteme und entsprechende StorageClass-Objekte erstellen.
4. Migration von Workloads und Daten schrittweise (Anwendung für Anwendung).
5. Überprüfung der Beständigkeit und Leistung unter normalen Bedingungen und im Fehlerfall.
6. Stilllegung des alten Clusters aus dem Jahr 2018 Mitte 2025.

Dies reduzierte das Risiko und ermöglichte es mir, jede Anwendung mit expliziten Rollback-Punkten zu testen.

Beispielkonfiguration für einen kleinen Rook-Ceph-Cluster

So sieht die neue Welt aus, die seitenlange Host-Vorbereitungen ersetzt:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v19. 2.1
  mon:
    count: 3
  storage:
    useAllNodes: false
    nodes:
      - name: odroid-1
        Geräte:
          - Name: /dev/sda
      - Name: odroid-2
        Geräte:
          - Name: /dev/sda
      - Name: odroid-3
        Geräte:
          - Name: /dev/sda

Selbst diese minimale Deklaration vermittelt mehr operative Absicht als es Ad-hoc-Shell-Schritte jemals taten.

Rückblick

Der ODROID-Ceph-Cluster von 2018 war eine großartige Ära: reines Linux, direkte Kontrolle und hart erarbeitetes Verständnis von Monitoren, OSDs und den Interna von CephFS.

Die Rook/Kubernetes-Ära tauschte einen Teil dieser direkten Kontrolle gegen Konsistenz, Wiederholbarkeit und übersichtlichere Abläufe ein. Für mich war das der richtige Tausch, insbesondere als der Cluster zur Infrastruktur für andere Systeme wurde, anstatt das Hauptexperiment selbst zu sein.

Ich habe das alte How-to-PDF immer noch griffbereit. Nicht mehr als Runbook, sondern als Momentaufnahme davon, wie viel praktisches Wissen über Speichertechnik ich mir angeeignet habe, bevor ich die Steuerung den Controllern überlassen habe.

Wenn Sie eine Speicher-Engine für Ihre Kubernetes-Plattform einrichten und die üblichen Fallstricke vermeiden möchten, können wir Ihnen helfen, diese richtig zu entwerfen und bereitzustellen.

Kontakt

Benötigen Sie Hilfe bei der Konzeption oder dem Betrieb von Kubernetes-Speicher mit Rook und Ceph?

Kontaktieren Sie uns, um Ihre Architektur zu planen, die Zuverlässigkeit zu validieren und die Einführung sicher durchzuführen.