Kubernetes CSI: Grundlagen von CSI-Volumes und Erstellen eines CSI-Treibers

Was ist Kubernetes CSI?

Kubernetes CSI ist eine Kubernetes-spezifische Implementierung der Container Storage Interface (CSI). Die CSI-Spezifikation bietet einen Standard, der die Konnektivität zwischen Speichersystemen und Container-Orchestrierungsplattformen (CO) ermöglicht. Sie bildet die Grundlage der Kubernetes- Speicherverwaltung.

Der CSI-Standard legt fest, wie beliebige Blöcke und Dateispeichersysteme Workloads auf Containersystemen wie Kubernetes ausgesetzt werden. Drittanbieter von Speicherlösungen können CSI verwenden, um Plug-Ins zu erstellen und bereitzustellen, damit Kubernetes mit neuen Speichersystemen funktioniert, ohne den Kerncode von Kubernetes bearbeiten zu müssen.

Die Notwendigkeit von CSI

Vor der Container Storage Interface unterstützte Kubernetes nur die Verwendung von In-Tree-K8S-Volume-Plugins, die mithilfe von Kubernetes-Kernbinärdateien geschrieben und bereitgestellt werden mussten. Dies bedeutete, dass Speicheranbieter die Kerncodebasis ihrer K8S-Plugins überprüfen mussten, um die Unterstützung für neue Speichersysteme zu ermöglichen.

Flex-Volume, eine Plug-in-basierte Lösung, versuchte dieses Problem zu lösen, indem die ausführbare API für Plug-ins von Drittanbietern zugänglich gemacht wurde. Obwohl diese Lösung hinsichtlich der Trennung von k8s-Binärdateien nach einem ähnlichen Prinzip wie CSI funktionierte, gab es bei diesem Ansatz eine Reihe von Problemen. Erstens erforderte sie Root-Zugriff auf das Master- und Host-Dateisystem, um die Bereitstellung von Treiberdateien zu ermöglichen. Zweitens war sie mit erheblichen Betriebssystemabhängigkeiten und -voraussetzungen verbunden, die auf dem Host als vorhanden vorausgesetzt wurden.

CSI behebt solche Probleme durch Containerisierung und die Nutzung von K8S-Speicherprimitiven. CSI hat sich zur allgegenwärtigen Lösung für die Nutzung von Out-of-Tree-Speicher-Plugins entwickelt. Es ermöglicht Speicheranbietern die Bereitstellung von Plugins über Standard-K8S-Primitive wie Speicherklassen, PersistentVolumes (PVs) und PersistentVolumeClaims (PVCs).

Das Hauptziel von CSI besteht darin, den Mechanismus zur Bereitstellung aller Arten von Speichersystemen über alle Container-Orchestratoren hinweg zu standardisieren.

Verwandte Inhalte: Lesen Sie unseren Leitfaden zu Kubernetes Persistent Volumes

Wie verwende ich ein CSI-Volume?

Ein CSI-Volume kann zum Bereitstellen von PersistentVolume-Ressourcen verwendet werden, die von Kubernetes-Workloads genutzt werden können. Sie können PersistentVolumes dynamisch (wenn sie von einem Workload angefordert werden) oder manuell bereitstellen.

Dynamische Bereitstellung

Sie können eine StorageClass erstellen, die auf ein CSI-Speicher-Plugin verweist. Dadurch können Kubernetes-Workloads dynamisch PersistentVolumes erstellen. Die in diesen PersistentVolumes gespeicherten Daten bleiben auf dem im CSI-Plugin definierten Speichergerät erhalten.

Beispielsweise ermöglicht die folgende StorageClass die Bereitstellung von Speichervolumes vom Typ „Fast-Storage“ mithilfe eines CSI-Plugins namens „csi-driver.example.com“. (Dieses und die anderen Beispiele unten wurden im offiziellen Kubernetes CSI- Blogbeitrag veröffentlicht .)

Wenn eine Kubernetes-Entität ein PersistentVolumeClaim-Objekt erstellt, das diese StorageClass anfordert, wird ein zur StorageClass gehörendes PersistentVolume dynamisch bereitgestellt. Die folgende Abbildung zeigt ein Beispiel für ein PVC, das auf die Fast-Storage-StorageClass verweist.

Beachten Sie, dass die obige StorageClass-Definition drei Parameter enthält: Typ und zwei Geheimnisse namens mysecret und mynamespace. Wenn der PVC deklariert wird, geschieht Folgendes im Hintergrund:

1. Die StorageClass führt einen CreateVolume-Aufruf für das CSI-Plugin (csi-driver.example.com) aus und übergibt die Parameter, einschließlich der Geheimnisse, die den Zugriff auf das Speichergerät ermöglichen.
2. Kubernetes erstellt automatisch ein PersistentVolume-Objekt, das ein Speichervolumen darstellt, das physisch auf dem CSI-Plugin-Gerät gespeichert ist.
3. Kubernetes bindet das PersistentVolume (PV)-Objekt an den entsprechenden PersistentVolumeClaim (PVC).
4. Ab diesem Zeitpunkt können die beanspruchten Pods oder Container das Speichervolumen nutzen.

Lesen Sie unseren Blogbeitrag: Dynamische Bereitstellung persistenter Kubernetes-Volumes mit NetApp Trident und Cloud Volumes ONTAP

Manuelle Bereitstellung

Sie können ein Volume in Kubernetes manuell bereitstellen und es für Workloads verfügbar machen, ohne den PVC-Mechanismus zu verwenden. Die folgende Abbildung zeigt ein Beispiel für ein PV-Objekt, das Workloads die Nutzung eines Speichervolumes namens „existingVolumeName“ ermöglicht. Wie oben erwähnt, verweist das CSI-Volume auf das Speicher-Plugin csi-driver.example.com.

Anhängen und Mounten von Volumes

Das folgende Bild zeigt ein Beispiel, wie eine Kubernetes-Pod-Vorlage auf ein PVC verweisen kann, um auf ein CSI-Volume zuzugreifen.

Wenn ein PersistenVolumeClaim in der Pod-Vorlage erscheint, löst Kubernetes bei jeder Pod-Planung mehrere Vorgänge im CSI-Plugin aus, darunter ControllerPublishVolume, NodeStageVolume und NodePublishVolume. Dadurch wird ein Speichervolume erstellt, eingebunden und für die im Pod ausgeführten Container verfügbar gemacht.

Plugins zum Speichern von Kubernetes-Volumes

CSI-Treiberkomponenten

CSI-Treiber in Kubernetes werden normalerweise mit Controller- und Pro-Knoten-Komponenten bereitgestellt.

Controller-Komponente
Das Controller-Plugin wird entweder als Deployment oder als StatefulSet bereitgestellt und kann auf jedem Knoten im Cluster gemountet werden. Es umfasst einen CSI-Treiber, der einen CSI-Controller-Dienst sowie einen Sidecar-Container (oder mehrere Container) implementiert. Ein Controller-Sidecar-Container interagiert normalerweise mit Kubernetes-Objekten und ruft auch den CSI-Controller-Dienst auf.

Der Controller benötigt keinen direkten Zugriff auf einen Host – er kann alle Vorgänge über externe Control-Plane-Dienste und die Kubernetes-API ausführen. Es ist möglich, mehrere Kopien einer Controller-Komponente für hohe Verfügbarkeit (HA) bereitzustellen. Sie sollten jedoch die Leader-Wahl implementieren, um sicherzustellen, dass immer nur ein Controller aktiv ist.

Zu den Controller-Sidecars gehören ein externer Provisioner, ein externer Attacher, ein externer Snapshotter und ein externer Resizer. Die Einbeziehung bestimmter Sidecars in eine Bereitstellung kann optional sein, abhängig von den auf der Sidecar-Seite aufgeführten Spezifikationen.

Der Controller kommuniziert mit Sidecar-Containern, die für die Verwaltung von Kubernetes-Ereignissen zuständig sind. Der Controller sendet dann entsprechende Aufrufe an den CSI-Treiber. Ein UNIX-Domain-Socket wird über ein EmptyDir-Volume freigegeben, wodurch die Aufrufe zwischen Sidecars und Treiber ermöglicht werden.

Controller-Sidecars verwenden rollenbasierte Zugriffskontrollregeln (RBAC), um ihre Interaktion mit Kubernetes-Objekten zu steuern. Die Sidecar-Repositorys bieten Beispiele für RBAC-Konfigurationen, die Sie in Ihre RBAC-Richtlinien integrieren können.

Knotenspezifische Komponente:
Das Knoten-Plugin sollte über ein DaemonSet auf allen Knoten in einem Cluster bereitgestellt werden. Es besteht aus dem CSI-Treiber, der den CSI-Knotendienst implementiert, und dem Sidecar-Container, der als Knotentreiber-Registrar dient.

Die Knotenkomponente kommuniziert mit dem Kubelet, das auf allen Knoten läuft und Aufrufe für den CSI-Knotendienst verarbeitet. Die Aufrufe können Speichervolumes in einem Speichersystem mounten oder unmounten und sie für den Pod verfügbar machen. Das Kubelet verwendet einen UNIX-Domain-Socket, der über ein HostPath-Volume auf dem Host freigegeben wird, um Aufrufe an den CSI-Treiber zu tätigen. Ein zusätzlicher UNIX-Domain-Socket wird vom Node-Driver-Registrar verwendet, um den Treiber beim Kubelet zu registrieren.

Das Node-Plugin benötigt direkten Zugriff auf einen Host, um Treibervolumes zu mounten. Um Dateisystem-Mounts und Blockgeräte für den Kubelet verfügbar zu machen, benötigt der CSI-Treiber einen bidirektionalen Mount-Punkt, der es dem Kubelet ermöglicht, die vom Treibercontainer erstellten Mounts zu sehen.

Einsatz

Kubernetes legt nicht die Verpackung eines CSI-Volume-Treibers fest, bietet jedoch Empfehlungen zur Vereinfachung der Bereitstellung containerisierter CSI-Treiber auf Kubernetes.

Speicheranbietern wird empfohlen, beim Einsatz eines containerisierten CSI-Volume-Treibers die folgenden Schritte auszuführen:

• Erstellen Sie einen Container, um das Verhalten des Volume-Plugins zu implementieren und eine gRPC-Schnittstelle über einen UNIX-Domain-Socket bereitzustellen. Der Container sollte als „CSI-Volume-Treiber“ bezeichnet und gemäß den CSI-Spezifikationen (mit Controller, Knoten und Identitätsdiensten) konfiguriert werden.
• Gruppieren Sie den Volume-Treibercontainer mit zusätzlichen Containern, die vom Kubernetes-Team bereitgestellt werden, wie z. B. External-Attacher, External-Provisioner, Cluster-Driver-Registrar, Node-Driver-Registrar, External-Resizer, External-Snapshotter und Livenessprobe. Diese Container erleichtern die Interaktion des Treibercontainers mit Kubernetes.
• Weisen Sie Clusteradministratoren an, das entsprechende DaemonSet und StatefulSet bereitzustellen und Unterstützung für das Speichersystem des Anbieters im Kubernetes-Cluster hinzuzufügen.

Eine weitere Option für eine potenziell einfachere Bereitstellung besteht darin, alle Komponenten, einschließlich des externen Provisioners und des externen Attachers, in einem einzigen DaemonSet zu haben. Diese Strategie verbraucht jedoch mehr Ressourcen und erfordert die Verwendung eines Leader-Wahlprotokolls (z. B. https://git.k8s.io/contrib/election) für die Komponenten „External-Attacher“ und „External-Provisioner“.

Aktivieren privilegierter Pods

Der Kubernetes-Cluster muss privilegierte Pods aktivieren, um die Verwendung von CSI-Treibern zu ermöglichen. Beispielsweise müssen Sie das Flag --allow-privileged für das Kubelet und den API-Server auf „true“ setzen. In bestimmten Umgebungen wie kubeadm, GCE und GKE ist dies die Standardeinstellung.

Der API-Server muss mit den folgenden privilegierten Flags gestartet werden:

$ ./kube-apiserver ... --allow-privileged=true ... $ ./kubelet ... --allow-privileged=true ...

Aktivieren der Mount-Propagation

Das Container Storage Interface erfordert eine Mount-Propagation-Funktion, die die gemeinsame Nutzung gemounteter Volumes zwischen Containern innerhalb desselben Knotens oder Pods ermöglicht. Der Docker-Daemon für einen Cluster muss die Mount-Freigabe zulassen, um die Mount-Propagation zu ermöglichen.

Kubernetes CSI mit NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP , die führende Speicherverwaltungslösung für Unternehmen, bietet sichere und bewährte Speicherverwaltungsdienste auf AWS, Azure und Google Cloud. Die Kapazität von Cloud Volumes ONTAP ist bis in den Petabyte-Bereich skalierbar und unterstützt verschiedene Anwendungsfälle wie Dateidienste, Datenbanken, DevOps oder andere Unternehmens-Workloads mit einem leistungsstarken Funktionsumfang, darunter Hochverfügbarkeit, Datenschutz, Speichereffizienz, Kubernetes-Integration und mehr.

Insbesondere unterstützt Cloud Volumes ONTAP die Bereitstellungs- und Verwaltungsanforderungen von Kubernetes Persistent Volume für containerisierte Workloads.

Erfahren Sie mehr über Kubernetes NFS Provisioning File Services mit Cloud Volumes ONTAP und Trident .

Erfahren Sie in diesen Fallstudien zu Kubernetes-Workloads mit Cloud Volumes ONTAP mehr darüber, wie Cloud Volumes ONTAP dabei hilft, die Herausforderungen containerisierter Anwendungen zu bewältigen.