
Am 29. Januar hat der technische Ausschuss der CNCF (Cloud Native Computing Foundation), die hinter Kubernetes, Prometheus und anderen Open Source-Produkten aus der Welt der Container und Cloud-native Technologien steht, ein Projekt Rook in seine Reihen aufgenommen. Eine hervorragende Gelegenheit, diesen „Orchestrator für verteilte Datenspeicherung in Kubernetes“ näher kennenzulernen.
Was ist Rook?
— es ist eine in Go geschriebene Software ( unter der Open Source-Lizenz Apache License 2.0), die dazu dient, Datenspeicher mit automatisierten Funktionen auszustatten, die sie selbstverwaltend, selbstskalierend und selbstheilend. Dafür automatisiert Rook (für Datenspeicher, die in einer Kubernetes-Umgebung verwendet werden): Bereitstellung, Bootstrapping, Konfiguration, Provisionierung, Skalierung, Updates, Migrationen, Wiederherstellung nach Ausfällen, Monitoring und Ressourcenmanagement.
Das Projekt befindet sich in der Alpha-Phase und spezialisiert sich auf die Orchestrierung von verteilten Speichersystemen Ceph in Kubernetes-Clustern. Die Entwickler äußern auch Pläne zur Unterstützung anderer Speichersysteme, aber dies wird nicht in nahen Releases geschehen.
Komponenten und technische Details
Die Funktionsweise von Rook innerhalb von Kubernetes basiert auf einem speziellen Operator (mehr zu Kubernetes-Operatoren haben wir geschrieben in ), der die Konfiguration des Speichers automatisiert und dessen Überwachung implementiert.
Also, Der Rook-Operator liegt in Form eines Containers vor, 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 Ceph-Speicherdemonen () mit einem einfachen RADOS-Cluster;
- Erstellung von Pods für die Ceph-Überwachung (mit , die den Zustand des Clusters überprüfen; für ein Quorum werden in der Regel drei Instanzen bereitgestellt, und bei Ausfall einer dieser Instanzen wird eine neue gestartet);
- Verwaltung von CRDs () für den eigentlichen , , (Sammlungen von Ressourcen und Diensten zur Bearbeitung von HTTP-Anfragen, die PUT/GET für Objekte durchführen – diese sind mit S3- und Swift-APIs kompatibel), sowie ;
- Initialisierung von Pods zum Start aller erforderlichen Dienste;
- Erstellung von Rook-Agenten.
Rook-Agenten werden als separate Pods dargestellt, die auf jedem Kubernetes-Knoten bereitgestellt werden. Die Aufgabe des Agenten besteht darin, das FlexVolume-Plugin zu konfigurieren. , der die Unterstützung von Speichervolumen in Kubernetes ermöglicht. Der Agent implementiert die Speicherung: er verbindet die Speicher-Netzwerkgeräte, bindet Volumes ein, formatiert das Dateisystem usw.

Position und Rolle der Rook-Komponenten im Gesamtbild des Kubernetes-Clusters
Rook bietet drei Arten von Speicher an:
- (Block,
StorageClass) — bindet den Speicher an einen einzelnen Pod; - (Object,
ObjectStore) — innerhalb und außerhalb des Kubernetes-Clusters verfügbar (über die S3-API); - (Shared File System,
Dateisystem) — ein Dateisystem, das von mehreren Pods im Lese- und Schreibmodus eingebunden werden kann.
Die interne Architektur von Rook umfasst:
- Mons — Pods zur Überwachung von Ceph (mit den bereits erwähnten ceph-mon);
- OSDs — Pods mit den ceph-osd-Daemons (Object Storage Daemons);
- MGR — Pods mit dem Daemon (Ceph Manager), der zusätzliche Überwachungsfunktionen und Schnittstellen für externe Systeme (Überwachung/Management) bereitstellt;
- RGW (optional) — Pods mit objektbasiertem Speicher;
- MDS (optional) — Pods mit dem Shared File System.

Alle Rook-Daemons (Mons, OSDs, MGR, RGW, MDS) sind in ein einziges Binary (rook), das in einem Container ausgeführt wird, kompiliert.
Für eine kurze Vorstellung des Rook-Projekts kann auch diese kleine (12 Folien) von Bassam Tabbara (CTO bei Quantum Corp).
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 sieht so aus:
cd cluster/examples/kubernetes
kubectl create -f rook-operator.yaml
kubectl create -f rook-cluster.yamlDarüber hinaus ist für den Rook-Operator vorbereitet , sodass die Installation auch so durchgeführt werden kann:
helm repo add rook-alpha https://charts.rook.io/alpha
helm install rook-alpha/rook Es gibt eine kleine Anzahl von (zum Beispiel kann die Unterstützung für , wenn diese Funktion in Ihrem Cluster nicht verwendet wird, deaktiviert werden), die in helm install über das 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 Starten 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: 1024Hinweis: besondere Aufmerksamkeit sollte auf das Attribut dataDirHostPath, dessen korrekte Größe notwendig ist, um das Cluster nach Neustarts aufrechtzuerhalten. Für den Fall, dass es als permanenter Speicherort für Daten verwendet wird, empfehlen die Autoren von Rook auf Kubernetes-Hosts, in diesem Verzeichnis mindestens 5 GB freien Speicherplatz zu haben.
Jetzt bleibt nur noch, das Cluster aus der Konfiguration zu erstellen und sicherzustellen, dass die Pods im Cluster (im Namensraum) erstellt wurden. 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 5mUpgrade Das Aktualisieren des Rook-Clusters (bis zur neuen Version) ist ein Prozess, der momentan eine schrittweise Aktualisierung aller Komponenten in einer bestimmten Reihenfolge erfordert. Man kann damit erst anfangen, nachdem man sichergestellt hat, dass die aktuelle Rook-Installation vollständig «gesund» ist. Eine detaillierte Schritt-für-Schritt-Anleitung, am Beispiel des Updates von Rook Version 0.5.0 auf 0.5.1, finden Sie in .
Im November letzten Jahres im Rook-Blog Vergleich Leistung. mit EBS. Die Ergebnisse sind bemerkenswert, und ganz kurz gesagt sind sie folgende:


Perspektiven
Aktueller Status von Rook — Alpha, und die letzte große Veröffentlichung bis heute ist die , die im November 2017 veröffentlicht wurde (aktuelle Korrektur — — veröffentlicht am 14. Dezember). Bereits in der ersten Hälfte des Jahres 2018 werden Veröffentlichungen reiferer Versionen erwartet: Betas und eine stabile (offiziell bereit für die Nutzung in der Produktion).
Laut des Projekts, die Entwickler haben eine detaillierte Vision für die Weiterentwicklung von Rook für mindestens zwei kommende Releases: 0.7 (seine Bereitschaft im GitHub-Tracker bei 60 %) und 0.8. Zu den erwarteten Änderungen gehören die Umstellung der Unterstützung für Ceph Block und Ceph Object auf Beta-Status, dynamisches Provisioning von Volumes für CephFS, ein erweitertes Protokollierungssystem, automatisierte Cluster-Updates und Unterstützung für Snapshots von Volumes.
Die Aufnahme von Rook in die (bis jetzt auf der frühesten Stufe — 'Inception-Level', — neben und ) ist eine Art Garantie für das wachsende Interesse an dem Produkt. Wie stark es sich in der Welt der Cloud-Anwendungen etablieren wird, wird nach der Veröffentlichung stabiler Versionen besser erkennbar sein, die Rook zweifellos neue „Tester“ und Benutzer bringen werden.
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
