Google Distributed Cloud kann mehrere Speicherkonfigurationen verwenden und bietet Schnittstellen für die Block- und Dateispeicherverwaltung über die folgenden Kubernetes-Objekte:
Flüchtiger Speicher über Kubernetes-Volumes
Kubernetes-Volume
-Ressourcen sind Speichereinheiten, auf die Container in einem Pod
zugreifen können. Sitzungsspezifischer Speicher unterstützt die folgenden Volume-Typen:
Sitzungsspezifische Speichertypen bleiben nicht bestehen, wenn ein Pod nicht mehr vorhanden ist. Verwenden Sie sitzungsspezifischen Speicher für Konfigurationsinformationen und als Cache-Speicher für Anwendungen.
Sitzungsspezifische Speichertypen teilen und verbrauchen Ressourcen auf dem Bootlaufwerk des Knotens. Lokale sitzungsspezifische Speicherressourcen lassen sich genauso verwalten wie CPU- und Arbeitsspeicherressourcen.
Nichtflüchtiger Speicher mit PersistentVolume
-Ressourcen
Ein PersistentVolume
von Kubernetes ist eine Ressource, die einen Pod
als langfristigen Speicher verwenden kann. Die Lebensdauer von nichtflüchtigen Volumes ist unabhängig von der Lebensdauer eines Pods. Daher bleiben das Laufwerk und die Daten in einem nichtflüchtigen Volume bestehen, wenn sich der Cluster ändert und Pods gelöscht und neu erstellt werden. Sie können PersistentVolume
-Ressourcen dynamisch über die PersistentVolumeClaims
API bereitstellen oder ein Clusteradministrator kann sie explizit erstellen.
Google Distributed Cloud kann nichtflüchtigen Speicher mithilfe einer Vielzahl von Speichersystemen sichern, einschließlich CSI-Treibern (Container Storage Interface) und lokaler Volumes.
CSI-Treiber (Container Storage Interface)
Google Distributed Cloud ist mit CSI v1.0-Treibern kompatibel. CSI ist eine offene Standard-Benutzeroberfläche, die von vielen großen Speicheranbietern unterstützt wird. CSI-Treiber installieren, um Produktionsspeicherplatz von einem GDC-fähigen Speicherpartner zu erhalten. Eine vollständige Liste der GDC Ready-Speicherpartner finden Sie unter GDC Ready-Speicherpartner.
Wenn Sie CSI in Ihrem Cluster verwenden möchten, stellen Sie den CSI-Treiber bereit, den der Speicheranbieter in Ihren Clustern bereitgestellt hat. Konfigurieren Sie dann Arbeitslasten für die Verwendung des CSI-Treibers mit der StorageClass
API oder legen SieStorageClass
als Standard-API fest.
Lokale Volumes
Für den Proof of Concept und erweiterte Anwendungsfälle können Sie lokale PersistentVolume-Ressourcen verwenden. Google Distributed Cloud bündelt den sig-storage-local-static-provisioner, der Bereitstellungspunkte auf jedem Knoten erkennt und ein lokales nichtflüchtiges Volume für jeden Bereitstellungspunkt erstellt.
Google Distributed Cloud-Cluster verwenden den lokalen Volume-Bereitsteller (LVP), um lokale nichtflüchtige Volumes zu verwalten. In einem Google Distributed Cloud-Cluster gibt es drei Arten von Speicherklassen für lokale nichtflüchtige Volumes:
- LVP-Freigabe
- LVP-Knotenbereitstellungen
- Anthos-System
LVP-Freigabe
Mit dieser Option wird ein lokales nichtflüchtiges Volume erstellt, das von Unterverzeichnissen in einem lokalen und freigegebenen Dateisystem gesichert wird. Bei der Clustererstellung werden diese Unterverzeichnisse automatisch erzeugt. Arbeitslasten, die diese Speicherklasse verwenden, teilen die Kapazität und Eingabe-/Ausgabevorgänge pro Sekunde (IOPS), da dasselbe freigegebene Dateisystem die nichtflüchtigen Volumes unterstützt. Konfigurieren Sie Laufwerke über LVP-Knotenbereitstellungen, um die Isolation zu verbessern.
Weitere Informationen finden Sie unter LVP-Freigabe konfigurieren.
LVP-Knotenbereitstellungen
Mit dieser Option wird ein lokales nichtflüchtiges Volume für jedes bereitgestellte Laufwerk im konfigurierten Verzeichnis erstellt. Sie müssen jedes Laufwerk vor oder nach der Clustererstellung formatieren und bereitstellen.
Weitere Informationen finden Sie unter LVP-Knotenbereitstellungen konfigurieren.
Anthos-System
Diese Speicherklasse erstellt während der Clustererstellung vorkonfigurierte nichtflüchtige Volumes, die von den Anthos-System-Pods verwendet werden. Der Name der StorageClass lautet anthos-system
. Ändern oder löschen Sie diese Speicherklasse nicht und verwenden Sie sie nicht für zustandsorientierte Arbeitslasten.
Nächste Schritte
- Weitere Informationen zu Volumes
- Weitere Informationen zur Container Storage-Schnittstelle in Kubernetes.
- Volume-Snapshots erstellen
- Kapazität nichtflüchtiger Volumes erhöhen