Rook — ein „Self-Service“-Datenspeicher für Kubernetes

Rook — ein „Self-Service“-Datenspeicher für Kubernetes

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, hat ein Projekt Rook in seine Reihen aufgenommen. Eine hervorragende Gelegenheit, diesen „Orchestrator für verteilte Datenspeicherung in Kubernetes“ näher kennenzulernen.

Was ist Rook?

Rook — es ist eine in Go geschriebene Software (wird unter der GPLv3-Lizenz bereitgestellt. 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 in diesem Artikel), 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 (ceph-osd) mit einem einfachen RADOS-Cluster;
  • Erstellung von Pods für die Ceph-Überwachung (mit ceph-mon, 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 (Custom Resource Definitions) für den eigentlichen Cluster, Speicherkapazitäten, Objektspeicher (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 Dateisysteme;
  • 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. FlexVolume, 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.

Rook — ein „Self-Service“-Datenspeicher für Kubernetes
Position und Rolle der Rook-Komponenten im Gesamtbild des Kubernetes-Clusters

Rook bietet drei Arten von Speicher an:

  1. Block (Block, StorageClass) — bindet den Speicher an einen einzelnen Pod;
  2. Objekt (Object, ObjectStore) — innerhalb und außerhalb des Kubernetes-Clusters verfügbar (über die S3-API);
  3. Gemeinsames FS (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-mgr (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.

Rook — ein „Self-Service“-Datenspeicher für Kubernetes

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) Präsentation nützlich sein. 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 im einfachsten Szenario sieht so aus:

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

Darüber hinaus ist für den Rook-Operator vorbereitet Helm-Chart, 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 Konfigurationsoptionen (zum Beispiel kann die Unterstützung für RBAC, 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: 1024

Hinweis: 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          5m

Upgrade 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 in der Projektdokumentation..

Im November letzten Jahres im Rook-Blog wurde veröffentlicht Vergleich Leistung. mit EBS. Die Ergebnisse sind bemerkenswert, und ganz kurz gesagt sind sie folgende:

Rook — ein „Self-Service“-Datenspeicher für Kubernetes
Rook — ein „Self-Service“-Datenspeicher für Kubernetes

Perspektiven

Aktueller Status von Rook — Alpha, und die letzte große Veröffentlichung bis heute ist die Version 0.6, die im November 2017 veröffentlicht wurde (aktuelle Korrektur — v0.6.2 — 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 Roadmap 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 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 CNCF-Projekte (bis jetzt auf der frühesten Stufe — 'Inception-Level', — neben linkerd und CoreDNS) 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

Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server 🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server | ProHoster