News

Idee und Vorteile des CSI

Container-Setups bieten eine Reihe von Vorteilen. Über eine Container-Orchestrierung wie Kubernetes kann dabei u.a. sichergestellt werden, dass zu jeder Zeit die erforderlichen Container gestartet sind. Verlässt dann ein Node den Verbund (sei es für Wartungsarbeiten oder aus einem anderen Grund), kann Kubernetes die betroffenen Container anderswo im Cluster neu starten und so den Soll-Zustand wiederherstellen. Dank dem CSI stehen in so einem Fall auch die persistenten Volumes (PVs) sofort wieder zur Verfügung: via passenden CSI-Treiber werden die benötigten Volumes nicht nur initial auf der darunterliegenden Cloud-Infrastruktur bereitgestellt, sondern auch danach immer am richtigen Node angeschlossen, so dass der Container auf das Volume und dessen Daten zugreifen kann.

Damit ein Container den Speicherplatz eines PV überhaupt nutzen kann, formatiert unser CSI-Treiber das Volume beim Erstellen normalerweise mit ext4 und mountet es dann im Dateisystem des Nodes, von wo aus es dem Container zur Verfügung gestellt wird. Einige Workloads können ihre Daten jedoch nicht in einem Dateisystem speichern, sondern nur auf ganzen Block Devices. Ein solches Beispiel ist Rook: Das Projekt der Cloud Native Computing Foundation kann in einer Kubernetes-Umgebung u.a. einen Storage-Cluster mit Ceph installieren und so einen Speicher-Service für andere Anwendungen bereitstellen. Bei einem Betrieb auf physischer Hardware würde Ceph für die eigentliche Datenablage direkt auf die Festplatten schreiben und statt Partitionen und Dateisystemen sein eigenes, optimiertes Format namens "BlueStore" benutzen. In einer Kubernetes-Umgebung werden die physischen Disks durch PVs ersetzt, die als Raw Block Volumes zur Verfügung stehen müssen.

CSI mit Raw Block Volumes nutzen

Offiziell unterstützt werden Raw Block Volumes in Kubernetes ab Version 1.18; in unserem CSI-Treiber haben wir diese Möglichkeit mit Version 3.1.0 eingeführt. Um ein Raw Block Volume zu erstellen, ergänzen Sie im Persistent Volume Claim (PVC) einfach volumeMode: Block (ansonsten greift der Default von Filesystem) wie im folgenden Beispiel:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pod-pvc-raw-block
spec:
  volumeMode: Block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: cloudscale-volume-ssd

In der Pod-Definition wiederum geben Sie mittels volumeDevices den gewünschten Device Path an (anstelle des Mountpoints mit volumeMounts):

apiVersion: v1
kind: Pod
metadata:
  name: my-csi-app-raw-block
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeDevices:
        - devicePath: /dev/xvda
          name: my-cloudscale-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-cloudscale-volume
      persistentVolumeClaim:
        claimName: csi-pod-pvc-raw-block

Das Volume, das so auf unserer Cloud-Infrastruktur erstellt wird und auch in unserem Cloud Control Panel oder via API sichtbar ist, wird "eins zu eins" an den jeweiligen Pod durchgereicht und steht diesem vom ersten bis zum letzten Byte zur Verfügung. Damit ist es selbstverständlich auch möglich, innerhalb des Pods eine Verschlüsselung solcher Volumes zu realisieren, z.B. mit LUKS.

Wie alle Volumes bei cloudscale.ch können auch Raw Block Volumes entweder auf NVMe SSDs oder auf unserem Bulk Storage angelegt werden. Und wie gewohnt können Sie auch solche Volumes im laufenden Betrieb vergrössern. Beachten Sie dabei jedoch, dass via CSI-Treiber lediglich die Grösse des Block Device erhöht wird; die Anpassung allfälliger Partitionen und Dateisysteme muss durch den jeweiligen Pod vorgenommen werden.

Verschiedene Use Cases, verschiedene Ansätze

Mit der Unterstützung von Raw Block Volumes eignet sich ein Kubernetes-/CSI-Setup nun auch für Anwendungsfälle, die nicht mit einem rein Datei-basierten persistenten Speicher auskommen. Falls Sie sich für Ceph interessieren und erste Gehversuche damit machen möchten, ist das oben erwähnte Rook ein solches Beispiel. Selbstverständlich gibt es aber auch Gründe, Rook mit Ceph produktiv einzusetzen, z.B. wenn Sie für eine andere Anwendung ein CephFS-Backend benötigen. Achten Sie in diesem Fall darauf, mögliche Single Points of Failure zu vermeiden: Dort wo mehrere Pods (bei Ceph z.B. "mon" oder "osd") eine Redundanz sicherstellen, platzieren Sie diese auf Kubernetes-Nodes, die zueinander in Anti-Affinity stehen – so sind im Fall eines isolierten Hardware-Issues auf einem der physischen Compute-Server nicht mehrere dieser Pods gleichzeitig betroffen.

Ceph wird oft mit einem Replikations-Faktor von 3 eingesetzt, so auch bei unseren eigenen Ceph-Clustern, auf denen die NVMe-SSD- und Bulk-Volumes sowie unser Object Storage basieren. Betreiben Sie auf dieser Infrastruktur Ihr eigenes Ceph-Setup, so bedeutet dies typischerweise, dass jedes darin abgelegte Datenfragment physisch 9-fach gespeichert wird. Wägen Sie für Ihren Use Case individuell ab, wieviel (zusätzliche) Redundanz Sie benötigen bzw. wieviel Overhead Sie in Kauf nehmen möchten. Allenfalls könnte sich z.B. auch ein eigener NFS- oder Datenbank-Server oder alternativ unser Object Storage als zentrale Datenablage für Ihre Applikationen eignen.

Cloud-Infrastruktur und Container-Setups sind das Mittel der Wahl für immer mehr Anwendungsfälle, bieten sie doch ein Maximum an Flexibilität und Skalierbarkeit. Sei es für einen kurzen Test oder für ein produktives HA-Setup: dank der Unterstützung für Raw Block Volumes in unserem CSI-Treiber können Sie diese Vorteile nun noch vielseitiger nutzen. Haben Sie Feedback oder Verbesserungsvorschläge? Wir freuen uns auf Ihre Anregungen via GitHub oder direkt an uns!

Fixfertig formatiert oder roh: Volumes nach Ihrem Geschmack!
Ihr cloudscale.ch-Team