Container Storage Interface unterstützt Kubernetes-Einsatz

Wichtigste Einsatzfelder für CSI und Kubernetes

Der Haupteinsatzzweck von CSI die Abstraktion des Storage. Kubernetes kann durch CSI mit jedem Storage-System kooperieren, für das es einen Schnittstellentreiber gibt.

Diese Treiber stabilisieren nebenbei Kubernetes und erhöhen seine Verlässlichkeit, da sie außerhalb des Kern-Codes von Kubernetes liegen. CSI-Treiber haben das alte System aus vielen Plug-ins ersetzt.

CSI-Vorteile gegenüber Plug-ins in den Kerncode

Der wichtigste Vorteil von CSI ist seine Einfachheit. Bevor Kubernetes diese Schnittstelle mit Version 1.13 allgemein verfügbar machte, kommunizierte Kubernetes mit dem Storage über sogenannte „In-Tree“ Plug-ins, die sich direkt in die Binärdateien von Kubernetes integrierten. Obwohl diese Plug-ins arbeiteten, stellten sie Administratoren vor mindestens drei Herausforderungen:

• Erstens bedeutete es Bürokratie auf mehreren Ebenen, wenn ein Storage-Produkt mit Kubernetes zusammenarbeiten sollte und dafür seine Plug-ins mit der Kubernetes-Software integriert werden sollten.
• Zweitens konnten Anbieter nur schwer Fehler in ihren Plug-ins beseitigen oder Verbesserungen hinzufügen, da beide ein Teil des Kubernetes-Kern-Codes waren.
• Drittens, und dies ist der wichtigste Punkt, konnte ein schlecht geschriebenes Plug-in praktisch den gesamten Kubernetes-Code destabilisieren.

Nun können Anwender statt dieser Plug-ins eine API verwenden, um ein CSI zu erstellen, über das ihre Hardware mit Kubernetes zusammenarbeitet. Storage-Hersteller brauchen keinen externen Support mehr für eine Kubernetes-Integration. Sie können selbst jederzeit Schnittstellentreiber schreiben und neue Versionen dieser Treiber bereitstellen.

So funktioniert die Implementierung

CSI-Treiber sollten gründlich getestet werden, bevor man sie in einer Produktionsumgebung einsetzt. Das Testen vermeidet den Einsatz fehlerhafter Treiber und macht auf durchaus mögliche Unterschiede zwischen den Treibern aufmerksam.

Denn Treiber können diverse Subkomponenten umfassen. Eine von ihnen ist der CSI-Controller. Er informiert Kubernetes darüber, wie die Funktionen auf einer niedrigen Abstraktionsebene ausgeführt werden müssen.

Beispielsweise kann ein solcher Controller hardwarespezifische Befehle enthalten, um ein Volume bereitzustellen, ein Volume an einen Kubernetes-Knoten anzuschließen oder einen Volume-Snapshot zu erstellen. Kubernetes kann nur solche Funktionen auf Hardwareebene ausführen, die im Controller identifiziert wurden.

Frühe Releases solcher Treiber umfassen möglicherweise nur wenige Funktionen, doch meist werden dann weitere Funktionen in späteren Releases ergänzt. Tests zeigen genau, welche Funktionen fehlen.

Man sollte nur offizielle Release-Versionen von CSI-Treibern verwenden. Denn die CSI-Treiber der Hardwareanbieter unterscheiden sich von durch die Community entwickelten. Websites, die Community-Entwicklungsprojekte hosten, geben oft bekannt, welches die aktuelle stabile Version des Codes ist, stellen aber manchmal auch ein oder mehrere Vor-Releases zur Verfügung. Diese Vor-Releases können fehlerhaft sein, weshalb man sie niemals in Produktionsumgebungen einsetzen sollte – auch dann nicht, wenn sie interessante neue Funktionen enthalten.