Grundlegendes zur Container-Speicherschnittstelle (in Kubernetes und mehr)

Hinweis perev. : Wir haben in unserem Test von K8s 1.9 zum ersten Mal über die sogenannten Kubernetes-Speicher-Plug-Ins (Out-of-Tree-CSI-Volume-Plugins) gesprochen , bei denen diese Funktion im Alpha-Versionsstatus angezeigt wurde . Der Autor des neuen Materials, Anoop Vijayan Maniankara (führender DevOps-Ingenieur des finnischen Unternehmens Tuxera), sammelte wichtige Informationen über die Ideen und das CSI-Gerät, um sich schnell mit dem neuen Konzept vertraut zu machen, das laut einigen unserer Mitarbeiter „das nächste große Ding sein wird“. Für eine detailliertere und technischere Untersuchung von CSI finden Sie am Ende des Artikels nützliche Links, unter denen ich besonders die Präsentation eines der Autoren dieser Spezifikation (Jie Yu) hervorhole. Aber es lohnt sich trotzdem, mit dem "großen Bild" zu beginnen ...



Container Storage Interface (CSI) ist eine Initiative zur Vereinheitlichung der Schnittstelle von Speichern wie Ceph, Portworx, NetApp usw. in Container-Orchestrierungssystemen: Kubernetes, Mesos, Docker Swarm, Cloud Foundry und anderen. Die Idee ist, dass die Implementierung eines CSI durch den Speicherhersteller garantiert mit all diesen Systemen funktioniert.


Bildquelle: Jie Yu CSI-Bericht auf der CloudNativeCon EU 2018

Bitte beachten Sie : In diesem Artikel wird nur die dynamische Bereitstellung behandelt. Vorkonfigurierte Volumes und Flex-Volumes gehen über den Rahmen hinaus. Wenn Sie besser verstehen möchten, was besprochen wird, sollten Sie zuerst die Kubernetes-Dokumentation lesen. Darüber hinaus wird der Artikel nicht näher auf die Details der CSI-Implementierung eingehen. Ich werde einen allgemeinen Überblick über CSI geben und den Grundstein für die Erstellung eines CSI-Volumes legen. Schließlich werden Kubernetes-Informationen für Beispiele und Links zu Details verwendet.

Bevor Sie sich mit dem Thema befassen, ist es auch wichtig zu wissen, welche Beiwagencontainer sich in Kubernetes befinden. Sie erweitern die Funktionen des Hauptcontainers ( main ), der im selben Herd vorhanden ist und Speicher und Netzwerk gemeinsam nutzt.

Zum Zeitpunkt dieses Schreibens (13. August 2018) hatten CSI-Komponenten die folgenden Versionen:



Vor CSI


Die erste Veröffentlichung von CSI - v0.1 - fand im Dezember 2017 statt. Natürlich könnte die Bereitstellung für externen Speicher in Orchestrierungssystemen bereits vor dem Erscheinen erfolgen. Im Fall von Kubernetes waren Volume-Plugins - Volume-Plugins für den Speicherbedarf verantwortlich:



Wie Sie aus dem obigen Bild sehen können, sind solche Plugins Teil des Kerns des Orchestrierungssystems. Aus diesem Grund sind die folgenden Probleme aufgetreten, die im CSI-Architekturdokument erwähnt wurden :

  • Die Entwicklung des Volume-Plugins ist eng mit Kubernetes-Releases verbunden und von diesen abhängig.
  • Die Entwickler / Community von Kubernetes sind dafür verantwortlich, alle Plugins zu testen und zu unterstützen, anstatt nur eine stabile Plugin-API zu testen und zu warten.
  • Fehler in Volume-Plugins können nicht nur das Plugin selbst, sondern auch kritische Kubernetes-Komponenten löschen.
  • Plugins erhalten die vollen Berechtigungen für Kubernetes-Komponenten (kubelet und kube-controller-manager);
  • Plugin-Entwickler müssen den Quellcode des Plugins veröffentlichen und können den Pfad der Binärdateien nicht auswählen.

CSI verstehen


Mit der Einführung von CSI veröffentlichte das Kubernetes-Team externe Komponenten, die nicht Teil des Kernels sind und für die Interaktion mit anderen externen Komponenten der Hersteller ausgelegt sind. Sie kommunizieren miteinander über Domain-Sockets (UNIX-Domain-Sockets - ca. Transl.) Mit gRPC .



Externe Komponenten von Kubernetes


Sie werden vom Kubernetes-Team vollständig implementiert und unterstützt und erweitern die Aktivitäten von Kubernetes außerhalb von Kubernetes. Hersteller können sich überhaupt keine Gedanken über die Merkmale ihrer Implementierung machen. Bestehend aus drei Teilen:

  • Der Treiberregistrar ist ein Sidecar-Container, der den CSI-Treiber in Kubelet registriert und den NodeId Treiber zur NodeId in der Kubernetes-API hinzufügt. Zu diesem GetNodeId interagiert es mit dem Identity CSI-Treiberdienst (weitere Details siehe unten - ca. Übersetzung) und ruft GetNodeId über CSI auf.
  • Externer Provisioner - ein Sidecar-Container, der PersistentVolumeClaim- Objekte in der Kubernetes-API CreateVolume und DeleteVolume CreateVolume und DeleteVolume für den Endpunkttreiber DeleteVolume .
  • Externer Anhang ist ein Sidecar-Container, der VolumeAttachment- Objekte in der Kubernetes-API überwacht und die Befehle ControllerPublish und ControllerUnpublish für den Endpunkttreiber aufruft.

Externe Komponente vom Speicherhersteller / Dritten


Herstellerspezifische Implementierung. Jeder Hersteller implementiert die erforderlichen APIs als Teil der Funktionen des gRPC-Dienstes. Zum Beispiel eine Implementierung von GCE PD oder Ceph usw. Sie bestehen auch aus drei Komponenten:

  • CSI-Identität - hauptsächlich zur Identifizierung eines Plugins: Stellen Sie sicher, dass es funktioniert, und geben Sie grundlegende Informationen zum Plugin zurück.

     service Identity { //      rpc GetPluginInfo(GetPluginInfoRequest) returns (GetPluginInfoResponse) {} // ,       Controller rpc GetPluginCapabilities(GetPluginCapabilitiesRequest) returns (GetPluginCapabilitiesResponse) {} //   ,  ,    rpc Probe (ProbeRequest) returns (ProbeResponse) {} } 

    ( kubernetes-csi-identity.proto )
  • CSI Controller ist für die Steuerung und Verwaltung von Volumes verantwortlich: Erstellen, Löschen, Anhängen / Trennen, Snapshots usw.;

     service Controller { //  provisioning  rpc CreateVolume (CreateVolumeRequest) returns (CreateVolumeResponse) {} //     rpc DeleteVolume (DeleteVolumeRequest) returns (DeleteVolumeResponse) {} //       rpc ControllerPublishVolume (ControllerPublishVolumeRequest) returns (ControllerPublishVolumeResponse) {} //       rpc ControllerUnpublishVolume (ControllerUnpublishVolumeRequest) returns (ControllerUnpublishVolumeResponse) {} // ,     /    rpc ValidateVolumeCapabilities (ValidateVolumeCapabilitiesRequest) returns (ValidateVolumeCapabilitiesResponse) {} //     rpc ListVolumes (ListVolumesRequest) returns (ListVolumesResponse) {} //       rpc GetCapacity (GetCapacityRequest) returns (GetCapacityResponse) {} // ,      GetCapacity  Snapshotting rpc ControllerGetCapabilities (ControllerGetCapabilitiesRequest) returns (ControllerGetCapabilitiesResponse) {} //   rpc CreateSnapshot (CreateSnapshotRequest) returns (CreateSnapshotResponse) {} //   rpc DeleteSnapshot (DeleteSnapshotRequest) returns (DeleteSnapshotResponse) {} //    rpc ListSnapshots (ListSnapshotsRequest) returns (ListSnapshotsResponse) {} } 

    ( kubernetes-csi-controller.proto )
  • Der CSI-Knoten ist für die Überwachung der Volume-Aktivität auf dem Kubernetes-Host verantwortlich.

     service Node { //     staging- rpc NodeStageVolume (NodeStageVolumeRequest) returns (NodeStageVolumeResponse) {} //    staging- rpc NodeUnstageVolume (NodeUnstageVolumeRequest) returns (NodeUnstageVolumeResponse) {} //    staging    rpc NodePublishVolume (NodePublishVolumeRequest) returns (NodePublishVolumeResponse) {} //      rpc NodeUnpublishVolume (NodeUnpublishVolumeRequest) returns (NodeUnpublishVolumeResponse) {} //    rpc NodeGetVolumeStats (NodeGetVolumeStatsRequest) returns (NodeGetVolumeStatsResponse) {} //   ID  rpc NodeGetId (NodeGetIdRequest) returns (NodeGetIdResponse) { option deprecated = true; } //   (capabilities)  rpc NodeGetCapabilities (NodeGetCapabilitiesRequest) returns (NodeGetCapabilitiesResponse) {} //   NodeGetId rpc NodeGetInfo (NodeGetInfoRequest) returns (NodeGetInfoResponse) {} } 

    ( kubernetes-csi-node.proto )

Fazit


Das Aufkommen von CSI brachte Orchestrierungssystemen und Speicherherstellern ein offensichtliches Plus. Darüber hinaus unterstützen gut definierte Schnittstellen die einfache Implementierung und das Testen von CSI sowohl für Entwickler als auch für zukünftige Orchestrierungssysteme. Wenn Sie nach dem Lesen dieses Artikels mit der Implementierung Ihrer CSI beginnen möchten, ist Fatih Arslans CSI-Plugin (Container Storage Interface) ein guter Ausgangspunkt.

Referenzen


  1. CSI-Spezifikation ;
  2. Beiwagencontainer bei Kubernetes ;
  3. Jie Yu CSI-Bericht zur KubeCon EU: CloudNativeCon EU 2018 (und hier ist das Video von dieser Präsentation - ca. übersetzt) ;
  4. CSI-Architekturdokument
  5. Aktuelle Dokumentation zu CSI von Kubernetes ;
  6. Veraltete Kubernetes CSI-Dokumentation .

PS vom Übersetzer


Lesen Sie auch in unserem Blog:

Source: https://habr.com/ru/post/de424211/


All Articles