Speicher für GKE-Cluster

In diesem Dokument werden die von GKE unterstützten Speicheroptionen sowie einige wichtige Überlegungen zur Auswahl der besten Option für Ihre Geschäftsanforderungen behandelt.

GKE unterstützt die folgenden Speichertypen und Integrationen:

Blockspeicher (Persistent Disk)

Persistent Disk-Volumes sind robuste Netzwerkspeichergeräte, die von Compute Engine verwaltet werden und auf die Ihre GKE-Cluster wie auf physische Laufwerke auf einem Desktop-Computer oder einem Server zugreifen können. Wenn Ihre Cluster zusätzlichen Speicherplatz benötigen, können Sie Ihren Knoten weitere Persistent Disk-Volumes hinzufügen oder die Größe der vorhandenen Persistent Disk-Volumes anpassen. Sie können festlegen, dass GKE dynamisch PersistentVolumes bereitstellt, die von Persistent Disk unterstützt werden, oder Sie können Laufwerke manuell bereitstellen.

Diese Speicheroption wird in GKE Autopilot- und Standard-Clustern unterstützt.

Standardmäßig sind Persistent Disk-Volumes zonale Ressourcen, die sich in einer einzelnen Zone innerhalb einer Region befinden. Sie können regionale Persistent Disk-Volumes erstellen, die sich in zwei Zonen derselben Region befinden. Sie können ein Persistent Disk-Volume auch schreibgeschützt an mehrere Knoten gleichzeitig anhängen. Dies wird sowohl für zonale als auch für regionale Persistent Disk-Volumes unterstützt.

Persistent Disk-Speicher in GKE ist persistent, d. h., die auf den Laufwerken gespeicherten Daten bleiben bestehen, auch wenn der Pod, der sie verwendet, beendet wird.

Vorteile von Persistent Disk-Speicher

Verwenden Sie Persistent Disk-Speicher, wenn Ihre Cluster Zugriff auf hochleistungsfähigen, hochverfügbaren langlebigen Blockspeicher benötigen. Ein Persistent Disk-Volume ist normalerweise an einen einzelnen Pod angehängt. Diese Speicheroption unterstützt den ReadWriteOnce-Zugriffsmodus. GKE unterstützt die Konfiguration von Persistent Disk-Volumes mit einer Reihe von Latenz- und Leistungsoptionen, darunter:

  • Abgestimmter nichtflüchtiger Speicher: Geeignet für Standardanwendungen für Unternehmen. Diese Option bietet ein ausgewogenes Verhältnis von Leistung und Kosten. Gesichert durch Solid-State-Laufwerke (SSD) Dies ist die Standardoption zur dynamischen Volume-Bereitstellung in Clustern und auf Knoten mit GKE 1.24 oder höher.
  • Nichtflüchtiger Leistungsspeicher: Geeignet für Analysen mit Hochskalierung, Datenbanken und nichtflüchtiges Caching. Diese Option ist ideal für leistungsempfindliche Arbeitslasten. Gesichert durch Solid-State-Laufwerke (SSD)
  • Nichtflüchtiger Standardspeicher: Geeignet für Big-Data- und Big-Computing-Arbeitslasten. Diese Option ist der kostengünstigste Laufwerkstyp. Unterstützt durch Standardfestplattenlaufwerke (Standard-HDDs).
  • Extrem nichtflüchtiger Speicher: Geeignet für Unternehmensanwendungen wie SAP HANA und Oracle. Diese Option bietet die höchste Leistung, um die Anforderungen der größten In-Memory-Datenbanken zu erfüllen. Unterstützt durch Solid-State-Laufwerke (SSD). Verwenden Sie für leistungskritische Anwendungen, bei denen Persistent Disk nicht genügend Leistung bietet, Hyperdisk Extreme-Laufwerke.

Informationen zur Verwendung dieser Speicheroption finden Sie in den folgenden Ressourcen:

Blockspeicher (Google Cloud Hyperdisk)

Hyperdisk-Volumes verwenden die nächste Generation von Google Cloud-Blockspeicher. Mit Hyperdisk-Volumes können Sie die Leistung Ihres Blockspeichers dynamisch auf Ihre Arbeitslast abstimmen. Sie können die Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) und den Durchsatz für Ihre Anwendungen unabhängig konfigurieren und an wechselnde Leistungsanforderungen anpassen.

Diese Speicheroption wird in GKE Autopilot- und Standard-Clustern unterstützt. Hyperdisk-Volumes sind zonale Ressourcen, die der regionalen Verfügbarkeit unterliegen. Hyperdisk-Speicher in GKE ist persistent, d. h., die auf den Laufwerken gespeicherten Daten bleiben bestehen, auch wenn der Pod, der sie verwendet, beendet wird.

Vorteile von Hyperdisk-Speicher

Verwenden Sie Hyperdisk-Speicher, wenn Sie IOPS oder den Durchsatz dynamisch anpassen müssen. Ein Hyperdisk-Volume ist in der Regel an einen einzelnen Pod angehängt. Diese Speicheroption unterstützt den ReadWriteOnce-Zugriffsmodus. Je nach Ihren Preis-Leistungs-Anforderungen können Sie aus den folgenden Hyperdisk-Speicheroptionen für GKE auswählen:

  • Hyperdis Throughput: Optimiert für einen kostengünstigen hohen Durchsatz von bis zu 3 GB/s (≥128 KB E/A-Größe). Dies ist eine gute Option, wenn Ihr Anwendungsfall auf Analysen mit Hochskalierung (z. B. Hadoop oder Kafka), auf die Wiederherstellung kalter Daten von Sicherungsservern und auf durchsatzorientierte kostenempfindliche Arbeitslasten ausgerichtet ist. Diese Speicheroption wird in GKE Autopilot- und Standard-Clustern unterstützt.
  • Hyperdisk Extreme: Optimiert für IOPS-Leistung mit über 320.000 bereitgestellten IOPS und einem Durchsatz von mehr als 4,8 GB/s. Dies ist eine gute Option, wenn Sie leistungsstarke Arbeitslasten wie Datenbankverwaltungssysteme bereitstellen. Diese Speicheroption wird nur für Standardcluster unterstützt.

Informationen zur Verwendung dieser Speicheroption finden Sie in den folgenden Ressourcen:

Sitzungsspezifischer und Rohblockspeicher (lokale SSD)

Lokale SSD-Laufwerke sind physische Laufwerke, die direkt mit den Knoten verbunden sind. Sie bieten eine bessere Leistung, sind jedoch sitzungsspezifisch. Jedes lokale SSD-Volume ist einem bestimmten Knoten zugeordnet. Sie können das Volume nicht auf einen anderen Knoten verschieben.

Diese Speicheroption wird in GKE Standard-Clustern unterstützt. Autopilot-Unterstützung für lokale SSDs ist in der Vorschau auf A2 Ultra A100-Maschinen sowie in Clustern und Knotenpools verfügbar, auf denen GKE 1.27 und höher ausgeführt wird.

Von lokalem SSD-Speicher in GKE unterstützter sitzungsspezifischer Speicher ist an den Lebenszyklus eines Pods gebunden. Wenn Ihr Pod beendet wird, wird auch der mit diesem Pod verknüpfte sitzungsspezifische Speicher gelöscht.

Vorteile von lokalen SSDs

Die Verwendung von lokalem SSD-Speicher in GKE-Clustern eignet sich, wenn Sie Hot-Caching für Datenbanken und Echtzeitanalysen oder Flash-optimierte sitzungsspezifische Speicher mit den niedrigsten Latenzen benötigen. Lokaler SSD-Speicher kann besonders als Caching-Ebene vor Cloud Storage für KI/ML, Batchverarbeitung, Analysen und In-Memory-Datenbanken effektiv sein.

Informationen zur Verwendung dieser Speicheroption finden Sie in den folgenden Ressourcen:

Dateispeicher

Filestore bietet ein cloudbasiertes freigegebenes Dateisystem für unstrukturierte Daten mit NFS-Zugriff (Network File System). Filestore-Instanzen fungieren als Dateiserver in Google Cloud und bieten dauerhaften Speicher mit ReadWriteMany-Zugriff auf Ihre GKE-Cluster. Filestore-Instanzen sind vom Host entkoppelt und erfordern minimale manuelle Eingriffe. Arbeitslast-Failovers erfolgen nahtlos, da keine Infrastrukturvorgänge zum Anhängen oder Trennen von Volumes nötig sind.

Diese Speicheroption wird in GKE Autopilot- und Standard-Clustern unterstützt. Filestore-Speicher mit der Enterprise-Dienststufe ist standardmäßig auf regionale Verfügbarkeit ausgelegt, während die anderen Dienststufen zonale Verfügbarkeit haben. Der Filestore-Speicher in GKE ist persistent, d. h., die in den Instanzen gespeicherten Daten bleiben erhalten, auch wenn der Pod, der sie verwendet, beendet wird.

Vorteile von Filestore-Speicher

Verwenden Sie Filestore-Speicher, wenn Ihre Anwendungen Zugriff auf das Netzwerkdateisystem (NFS) sowie mehrere Leser und Autoren benötigen. Diese Speicheroption eignet sich, wenn Ihr Anwendungsfall Content-Management-Systeme, die Anwendungsmigration, Datenanalyse, Rendering und Medienverarbeitung umfasst.

Für zusätzliche Kosteneffizienz können Sie mit Filestore-Mehrfachfreigaben für GKE eine Instanz der Filestore-Enterprise-Stufe von 10 GiB oder höher mit bis zu 80 PersistentVolumes freigeben.

Informationen zur Verwendung dieser Speicheroption finden Sie in den folgenden Ressourcen:

Objektspeicher (Cloud Storage FUSE)

Cloud Storage ist ein Objektspeicher für binäre und Objektdaten, Blobs und unstrukturierte Daten. Der Cloud Storage FUSE-CSI-Treiber verwaltet die Einbindung von Cloud Storage FUSE in Kubernetes APIs, um vorhandene Cloud Storage-Buckets als Volumes zu nutzen. Sie können den CSI-Treiber für Cloud Storage FUSE verwenden, um Buckets als Dateisysteme auf GKE-Knoten bereitzustellen.

Der Cloud Storage FUSE CSI-Treiber unterstützt die Zugriffsmodi ReadWriteMany, ReadOnlyMany und ReadWriteOnce in GKE Autopilot- und Standard-Clustern. Cloud Storage-Objekte sind regional verfügbar. Cloud Storage-Daten in GKE sind persistent, d. h., die in den Buckets gespeicherten Daten bleiben bestehen, auch wenn der Pod, der sie verwendet, beendet wird.

Vorteile von Cloud Storage FUSE

Die Option mit Cloud Storage FUSE ist geeignet, wenn Sie Dateisemantik vor Cloud Storage für die Portabilität benötigen. Cloud Storage FUSE wird auch häufig von Entwicklern verwendet, die ML-Training speichern und abrufen und Daten als Objekte in Cloud Storage modellieren möchten.

Informationen zur Verwendung dieser Speicheroption finden Sie in den folgenden Ressourcen:

Verwaltete Datenbanken

Eine verwaltete Datenbank wie Cloud SQL oder Spanner bietet einen geringeren operativen Aufwand und ist für die Google Cloud-Infrastruktur optimiert. Verwaltete Datenbanken sind weniger mühsam zu warten und zu betreiben als eine Datenbank, die Sie direkt in Kubernetes bereitstellen.

Vorteile von verwalteten Datenbanken

Mit einer von Google Cloud verwalteten Datenbank können Ihre zustandsorientierten Arbeitslasten in GKE auf nichtflüchtige Daten zugreifen, während Wartungsaufgaben wie Sicherungen, Patches und Skalierung automatisiert werden. Sie erstellen eine Datenbank und Ihre Anwendung und lassen sie von Google Cloud skalieren. Dies bedeutet jedoch auch, dass Sie möglicherweise keinen Zugriff auf die genaue Version einer Datenbank, die Erweiterung oder den genauen gewünschten Flavor der Datenbank haben.

GKE unterstützt die Verbindung mit von Google Cloud verwalteten Datenbankdiensten, darunter:

Informationen zur Verwendung dieser Speicheroption finden Sie in den folgenden Ressourcen:

Build-Artefakte (Artifact Registry)

Artifact Registry ist ein Repository-Manager für Container-Images, Betriebssystempakete und Sprachpakete, die Sie erstellen und bereitstellen.

Vorteile von Artifact Registry

Artifact Registry ist eine geeignete Option zum Speichern von privaten Container-Images, Helm-Diagrammen und anderen Build-Artefakten.

Informationen zum Abrufen von Images aus Artifact Registry-Docker-Repositories in GKE finden Sie in der Dokumentation zu Artifact Registry unter In Google Kubernetes Engine bereitstellen.

Nächste Schritte