🥇Rook – „Self-Service“-Datenspeicher für Kubernetes

Am 29. Januar hat das technische Komitee der CNCF (Cloud Native Computing Foundation), das für Kubernetes, Prometheus und andere Open-Source-Produkte aus der Welt der Container und cloud-native Technologien verantwortlich ist, gab bekannt das Projekt Rook in seine Reihe aufgenommen. Ein hervorragender Anlass, um diesen „Orchestrierer von verteilten Datenspeichersystemen in Kubernetes“ näher kennenzulernen.

Was ist Rook?

Rook — ist eine in Go geschriebene Software (wird verbreitet unter der offenen Lizenz Apache License 2.0), die dazu dient, Datenspeichern automatisierte Funktionen zu geben, die sie selbstverwaltend, selbstskalierend und sich selbstheilendmachen. Zu diesem Zweck automatisiert Rook (für Datenspeicher, die in Kubernetes-Umgebungen eingesetzt werden): Bereitstellung, Bootstrapping, Konfiguration, Provisionierung, Skalierung, Aktualisierungen, Migrationen, Wiederherstellung nach Ausfällen, Monitoring und Ressourcenmanagement.

Das Projekt befindet sich in der Alpha-Phase und spezialisiert sich auf die Orchestrierung des verteilten Speichersystems Ceph in Kubernetes-Clustern. Die Autoren geben auch Pläne zur Unterstützung anderer Speichersysteme bekannt, jedoch wird dies nicht in den kommenden Versionen geschehen.

Komponenten und technische Struktur

Im Kern der Funktionsweise von Rook innerhalb von Kubernetes steht ein spezieller Operator (mehr zu Kubernetes Operators haben wir in diesem Artikel)beschrieben), der die Konfiguration des Speichers automatisiert und sein Monitoring durchführt.

Also, Der Rook-Operator präsentiert sich als Container, der alles Notwendige für die Bereitstellung und anschließende Wartung des Speichers enthält. Zu den Aufgaben des Operators gehören:

Erstellung eines DaemonSets für die Ceph-Speicherdämonen (ceph-osd) mit einem einfachen RADOS-Cluster;
Erstellung von Pods für das Ceph-Monitoring (mit ceph-mon, die den Zustand des Clusters überwachen; für die Mehrheitsentscheidung werden in der Regel drei Instanzen bereitgestellt, und bei Ausfall einer davon wird eine neue hochgefahren);
Verwaltung von CRDs (Custom Resource Definitions) für den Cluster, speicherpools, Object Stores (Sets von Ressourcen und Diensten zur Bearbeitung von HTTP-Anfragen, die PUT/GET für Objekte ausführen — sie sind mit dem S3- und Swift-API kompatibel), sowie Dateisysteme;
Initialisierung von Pods zum Start aller benötigten Dienste;
Erstellung von Rook-Agenten.

Rook-Agenten werden als eigenständige Pods dargestellt, die auf jedem Kubernetes-Knoten bereitgestellt werden. Die Aufgabe des Agents ist die Konfiguration des Plugins FlexVolume, das die Unterstützung von Speichervolumen in Kubernetes gewährleistet. Der Agent führt den Betrieb des Speichers durch: Er verbindet netzwerkbasierte Speichergeräte, mountet Volumen, formatiert Dateisysteme usw.

Die Position und Rolle der Rook-Komponenten im Gesamtschema des Kubernetes-Clusters

Rook bietet drei Arten von Speicher an:

Blockspeicher (Block, StorageClass) – verbindet den Speicher mit einem einzelnen Pod;
Objektspeicher (Object, ObjectStore) – innerhalb und außerhalb des Kubernetes-Clusters verfügbar (über S3 API);
gemeinsames FS (Shared File System, Dateisystem) – ein Dateisystem, das aus mehreren Pods lesend und schreibend gemountet werden kann.

Die interne Struktur von Rook umfasst:

Mons – Pods zur Überwachung von Ceph (mit bereits erwähnten ceph-mon);
OSDs – Pods mit ceph-osd-Demonen (Object Storage Daemons);
MGR – Pods mit dem Demon ceph-mgr (Ceph Manager), der zusätzliche Überwachungsfunktionen und Schnittstellen für externe Systeme (Überwachung/Management) bereitstellt;
RGW (optional) – Pods mit Objektspeicher;
MDS (optional) – Pods mit gemeinsamem FS.

Alle Rook-Daemons (Mons, OSDs, MGR, RGW, MDS) sind in einem einzigen Binary kompiliert (rook), das in einem Container ausgeführt wird.

Für eine kurze Vorstellung des Rook-Projekts kann auch dieses kleine (12 Folien) Material Präsentation von Bassam Tabbara (CTO bei Quantum Corp) hilfreich sein.

Betrieb von Rook

Der Rook-Operator unterstützt vollständig Kubernetes-Versionen 1.6 und höher (und teilweise die ältere K8s-Version 1.5.2). Seine Installation in einfachstes Szenario sieht so aus:

cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yaml

Darüber hinaus wurde für den Rook-Operator Helm-Diagramm, was die Installation auch folgendermaßen ermöglichen kann:

helm repo add rook-alpha https://charts.rook.io/alpha
helm install rook-alpha/rook

Es gibt eine kleine Anzahl von Konfigurationsoptionen (z.B. kann die Unterstützung von RBAC, wenn diese Funktion in Ihrem Cluster nicht verwendet wird, deaktiviert werden), die über helm install mit dem Parameter --set key=value[,key=value] (oder in einer separaten YAML-Datei speichern und über -f values.yaml).

Nach der Installation des Rook-Operators und dem Start der Pods mit seinen Agenten bleibt es, den Rook-Cluster selbst zu erstellen, dessen einfachste Konfiguration wie folgt aussieht (rook-cluster.yaml):

apiVersion: v1
kind: Namespace
metadata:
  name: rook
---
apiVersion: rook.io/v1alpha1
kind: Cluster
metadata:
  name: rook
  namespace: rook
spec:
  dataDirHostPath: /var/lib/rook
  storage:
    useAllNodes: true
    useAllDevices: false
    storeConfig:
      storeType: bluestore
      databaseSizeMB: 1024
      journalSizeMB: 1024

Hinweis: Besonders zu beachten ist das Attribut dataDirHostPath, dessen korrektes Wert für die Erhaltung des Clusters nach Neustarts notwendig ist. In Fällen, in denen es als permanenter Speicherort für Daten in Rook auf Kubernetes-Hosts verwendet wird, empfehlen die Autoren, in diesem Verzeichnis mindestens 5 GB freien Speicherplatz zu haben.

Es bleibt lediglich, ein Cluster aus der Konfiguration zu erstellen und sicherzustellen, dass die Pods im Cluster erstellt wurden (im Namensraum rook):

kubectl create -f rook-cluster.yaml
kubectl -n rook get pod
NAME                              READY     STATUS    RESTARTS   AGE
rook-api-1511082791-7qs0m         1/1       Running   0          5m
rook-ceph-mgr0-1279756402-wc4vt   1/1       Running   0          5m
rook-ceph-mon0-jflt5              1/1       Running   0          6m
rook-ceph-mon1-wkc8p              1/1       Running   0          6m
rook-ceph-mon2-p31dj              1/1       Running   0          6m
rook-ceph-osd-0h6nb               1/1       Running   0          5m

Upgrade des Rook-Clusters (auf die neue Version) — dies ist ein Verfahren, das in diesem Stadium die schrittweise Aktualisierung aller Komponenten in einer bestimmten Reihenfolge erfordert, und es kann erst begonnen werden, wenn Sie sich vergewissert haben, dass die aktuelle Installation von Rook vollständig „gesund“ ist. Eine ausführliche Schritt-für-Schritt-Anleitung am Beispiel der Aktualisierung von Rook Version 0.5.0 auf 0.5.1 finden Sie in der Projektdokumentation.

Im November letzten Jahres wurde im Rook-Blog veröffentlicht der Vergleich der Leistung mit EBS. Die Ergebnisse sind bemerkenswert und, um es kurz zu machen, sind sie wie folgt:

Aussichten

Der aktuelle Status von Rook ist Alpha, und die letzte große Version, die bisher veröffentlicht wurde, ist Version 0.6, die im November 2017 veröffentlicht wurde (das aktuelle Update — v0.6.2 — wurde am 14. Dezember veröffentlicht). Bereits in der ersten Hälfte des Jahres 2018 werden die Releases reiferer Versionen erwartet: Betas und eine stabile (offiziell bereit für den Einsatz in der Produktion).

Laut Roadmap des Projekts haben die Entwickler eine detaillierte Vision zur Weiterentwicklung von Rook, mindestens in zwei kommenden Releases: 0.7 (seine Fertigstellung wird im GitHub-Tracker mit 60 % eingeschätzt) und 0.8. Zu den erwarteten Änderungen gehören die Umstellung der Unterstützung von Ceph Block und Ceph Object auf den Beta-Status, dynamisches Provisioning von Volumes für CephFS, ein erweitertes Logging-System, automatisierte Cluster-Updates und Unterstützung von Snapshots für Volumes. Die Aufnahme von Rook in die

CNCF-Projekte (zurzeit noch in der frühesten Phase — „Inception-Level“, — gleichauf mit linkerd CoreDNS und CoreDNS) ist eine Art Garantie für das wachsende Interesse an dem Produkt. Wie stabil es sich in der Welt der Cloud-Anwendungen etablieren wird, wird nach der Veröffentlichung stabiler Versionen besser klar werden, die Rook ohne Zweifel neue „Tester“ und Benutzer bringen werden.