Infrastructure as Code: Die Ceph-Verwaltung mit GitOps automatisieren

Die gesamte Ceph-Konfiguration in einem Versionskontrollsystem zu speichern ist unüblich. Dabei lassen sich die Vorteile von GitOps auch ohne Kubernetes nutzen.

Artikel verschenken
In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Lesezeit: 19 Min.
Von
  • Torsten Gosch
Inhaltsverzeichnis

Das Gespann aus Kubernetes und Ceph hat in der jungen Geschichte von Kubernetes eine vergleichsweise lange Tradition hinter sich. Zumindest on Premises war Ceph neben GlusterFS schon immer Vorreiter für die Containerpersistenz in Kubernetes. Bereits vor der Veröffentlichung der frühen Kubernetes-Version 0.20 im Jahr 2015 war es prinzipiell möglich, Ceph dafür zu verwenden. Damals beschrieb ein Blogartikel, der auch dem Autor bei seinen ersten Gehversuchen half, den steinigen Weg, Cephs RADOS Block Devices (RBD) in Kubernetes zu konsumieren.

Nicht nur die Tatsache, dass die Entwickler des CNCF-Projekts Rook zuerst auf Ceph setzten, sondern auch, dass das Container Storage Interface (CSI) inzwischen die meisten Features von Ceph wie RBD Snapshots beherrscht, zeugt von der Bedeutung von Ceph im Kubernetes-Umfeld. Auch Kubernetes-Marktführer Red Hat verkauft seinen Kunden mittlerweile bevorzugt Ceph für seine hauseigene Kubernetes-Plattform OpenShift als darunterliegenden Speicher und nicht mehr GlusterFS.

Mehr zum Thema Ceph

Aus diesem Grund fiel auch bei der HanseMerkur die Wahl für die neue Kubernetes-on-Premises-Plattform auf Ceph. Dafür sprach auch, dass Ceph bereits im ersten Entwurf der hauseigenen Kubernetes-Plattform die Basis bildete. Damals – zu Zeiten von Ceph v0.94 alias Hammer – wurde das Deployment mit ceph-deploy und Puppet erledigt.