Getty Images

Anwendungsspeicher mit Kubernetes und CSI-Treibern verwalten

Container-Storage-Interface-Treiber bieten IT-Teams mehr Autonomie und Flexibilität bei der Bereitstellung und Verwaltung von persistentem Speicher auf Kubernetes-Clustern.

Die Abkehr von dedizierten Workload-Infrastrukturen bringt viele Vorteile mit sich, darunter modernisierte Anwendungen und schnellere Entwicklungszyklen, kann aber auch die Komplexität erhöhen. Das Container Storage Interface (CSI) bietet IT-Teams die dringend benötigte Flexibilität bei der Arbeit mit Container-Umgebungen.

Container beschleunigen und rationalisieren den Entwicklungsprozess und bieten einen leichtgewichtigen Ansatz für die Virtualisierung von Ressourcen und den Aufbau stabiler Leistungsumgebungen. Kubernetes und ähnliche Container-Orchestratoren können diese Bereitstellungen skalieren, einen Lastausgleich vornehmen und Rollouts und Rollbacks automatisieren.

Bei der Verwaltung von Container-Umgebungen verlassen sich DevOps- und IT-Teams auf Container Storage Interface (CSI)-Treiber, die mehr Autonomie, Flexibilität und Kompatibilität mit einer Vielzahl von Speichergeräten bieten. Heute sind mehr als 60 CSI-Treiber für eine Vielzahl von Datei-, Block- und Objektspeicherarten in Hardware- und Cloud-Formaten verfügbar. Mit einem CSI-Treiber können IT-Administratoren den von ihnen bevorzugten Typ von persistentem Speicher bereitstellen und dies unabhängig vom gewählten Orchestrator, I/O und damit verbundenen Funktionen wie Snapshots und Klonen.

Persistentes Storage, Kubernetes und CSI

Kubernetes ist ein Nachkomme von Borg, einem internen Container-Orchestrator, der von Google-Ingenieuren entwickelt wurde und 2014 den Weg für das Open-Sourcing von Kubernetes ebnete. Diese portable, erweiterbare Plattform folgt einer Client-Server-Architektur, die aus einer Steuerungsebene und Clustern von Knoten besteht, auf denen containerisierte Aufgaben ausgeführt werden. Kubernetes orchestriert Arbeitslasten, indem es Container in Pods platziert und diese auf virtuellen oder physischen Knoten ausführt.

Für Speicheranbieter war die frühe Unterstützung der Kubernetes-Integration mit erheblichem Aufwand verbunden, da die Plattform In-Tree-Volume-Plug-ins verwendete, die direkt in die Kubernetes-Binärdatei integriert waren. Dieser Ansatz brachte Hindernisse mit sich: Das Hinzufügen von neuem Anwendungsspeicher erforderte beispielsweise das Einchecken von Code in das Kubernetes-Kern-Repository und stellte Herausforderungen in Bezug auf die Komplexität der Integration und Speicherbeschränkungen dar.

Neben diesen praktischen Hürden für die Plug-in-Integration schränkte der In-Tree-Ansatz die Möglichkeiten für Fehlerbehebungen und Workarounds ein. Außerdem erhöhte sich dadurch die Möglichkeit der Einführung von Code-basierten Fehlern, die die Kubernetes-Plattform destabilisieren könnten.

Letztlich schränkten die Komplexität der Integration und das Fehlen einheitlicher Standards den Funktionsumfang von Kubernetes ein. Die Nutzer brauchten die Möglichkeit, Plug-ins auf der Grundlage vereinfachter Spezifikationen zu entwickeln, die nicht auf den Kubernetes-Lebenszyklus angewiesen waren. Aus diesem Grund führte Google das CSI ein, um Benutzern die Möglichkeit zu geben, neue Speichersysteme zu entwickeln, ohne den Kubernetes-Kerncode anfassen zu müssen.

Bewertung von CSI-Treiberimplementierungen für Kubernetes

Heute verwenden Storage-Anbieter CSI, um ihre Plug-ins zu schreiben. Durch die Verwendung einfacher Spezifikationen können sie die Abhängigkeit vom Kubernetes-Versionszyklus eliminieren und ihre Treiber jederzeit aktualisieren.

Diese CSI-Treiber bieten drei Hauptdienste:

  • spezifische Plug-ins und Fähigkeiten zu identifizieren
  • Steuerung von Cluster-Operationen für externe Prozesse zu ermöglichen
  • Knoten- und Containeroperationen zu definieren

CSI dient in erster Linie der Speicherabstraktion, sodass Administratoren damit mit den PersistentVolumeClaims (PVCs), PersistentVolumes (PVs) und Speicherklassen von Kubernetes arbeiten können.

Das PVC-Framework bezeichnet Speicheranforderungen von Benutzern und definiert die spezifischen Speicheranforderungen für einen Pod, wie zum Beispiel die Kapazität oder die gemeinsame Nutzung von Daten. Um einen Pod auszuführen, installieren Entwickler einen Knotenagenten, ein so genanntes Kubelet, das Pods innerhalb dieses Knotens starten und verwalten kann.

Administratoren weisen dann eine Speicherklasse zu, die den externen Speicher angibt, und verwenden CSI-Treiber zur Bereitstellung für diese Speicherklasse. Nachdem eine Speicherklasse festgelegt wurde, löst der PVC die dynamische Bereitstellung aus. Externer Speicher stützt sich auf den CSI-Treiber, um die Volume-Erstellung aufzurufen. Dieses spezifische PV wird dann an den PVC gebunden.

Das Kommunikationsprotokoll zwischen dem Orchestrator und den Plug-ins, das all diese Prozesse ausführt, ist gRPC, ein Open-Source-Framework für Remote Procedure Calls. Der CSI-Controller steuert Low-Level-Funktionen, wie beispielsweise die Bereitstellung von Speicherplatz auf definierter Hardware und die Erstellung von Volume-Snapshots.

So erstellen Sie einen CSI-Treiber für Kubernetes

Entwickler können das Controller-Plug-in auf einem beliebigen Knoten innerhalb eines Clusters entweder als Deployment (Kubernetes‘ Versionierungssystem für Rollbacks und Rollouts) oder als StatefulSet für die Pod-Skalierung einbinden.

Das Plug-in interagiert mit Kubernetes-Objekten wie ein Sidecar-Container. Es ruft den CSI-Controller-Dienst auf und führt dann alle Operationen über die Kubernetes-API und die externe Steuerungsebene des angegebenen Clusters aus. Diese Art des automatischen Austauschs hilft den Entwicklern, sich auf die Programmierung zu konzentrieren, anstatt die Komplexität der Speicherung zu lösen.

Abbildung 1 erklärt wie Microservices und Sidecars zusammenarbeiten.
Abbildung 1 erklärt wie Microservices und Sidecars zusammenarbeiten.

Für IT-Teams bietet die Kubernetes-Plattform Empfehlungen zur Vereinfachung der Bereitstellung von containerisierten CSI-Treibern. Es ist jedoch zu beachten, dass die Treiberinstallation bei jedem Anbieter anders ist, insbesondere bei Cloud-Bereitstellungen mit Amazon Elastic Kubernetes Service, Azure Kubernetes Service oder Google Kubernetes Engine. Sobald sich ein Team für einen Ansatz entschieden hat, ist es wichtig, die Struktur der Hosting-Umgebung genau zu verstehen.

In Bezug auf Cloud-Bereitstellungen können Entwickler ihre Vergleiche auf die am besten geeignete Plattform für die zu erledigenden Aufgaben stützen. Im Allgemeinen bleibt die Art und Weise, wie Entwicklungsteams CSI-Treiber verwenden, über alle Bereitstellungen hinweg einheitlich - zum Beispiel durch die Erstellung einer StorageClass innerhalb eines Kubernetes-Clusters, die auf die CSI verweist.

Erfahren Sie mehr über Backup-Lösungen und Tools

ComputerWeekly.de
Close