Lokale Solid-State-Laufwerke (SSDs) sind feste SSD-Laufwerke, die auf einer einzelnen Compute Engine-VM bereitgestellt werden können. Sie können lokale SSDs in GKE verwenden, um einen leistungsstarken Speicher zu erhalten, der nicht persistent (sitzungsspezifisch) ist und an jeden Knoten in Ihrem Cluster angehängt ist. Sie zeichnen sich auch durch einen höheren Durchsatz und eine geringere Latenz als Standardlaufwerke aus.
In Version 1.25.3-gke.1800 und höher können Sie einen GKE-Knotenpool für die Verwendung lokaler SSDs mit einer NVMe-Schnittstelle für lokalen sitzungsspezifischen Speicher oder Rohblockspeicher konfigurieren.
Wenn Sie GKE mit Standardclustern verwenden, können Sie beim Erstellen von Knotenpools lokale SSD-Vlumes an Knoten anhängen. Dies verbessert die Leistung von flüchtigem Speicher für Ihre Arbeitslasten, die emptyDir-Volumes oder lokale PersistentVolumes verwenden. Sie können Knotenpools mit lokalen SSDs im Rahmen der Maschinentyplimits des Clusters und der Kontingente Ihres Projekts erstellen.
Eine lokale SSD ist nur mit einem einzelnen Knoten verbunden und die Knoten selbst sind auch sitzungsspezifisch. Eine Arbeitslast kann zu einer beliebigen Zeit auf einem anderen Knoten geplant werden.
Weitere Informationen zu den Vorteilen und Einschränkungen lokaler SSDs wie der Leistung und der zulässigen Anzahl von SSD-Laufwerken pro Maschinentyp finden Sie in der Compute Engine-Dokumentation unter Lokale SSDs.
Vorteile lokaler SSDs für GKE
Eine lokale SSD ist eine gute Wahl, wenn Ihre Arbeitslasten eine der folgenden Anforderungen haben:
- Sie möchten Anwendungen ausführen, die Daten herunterladen und verarbeiten, z. B. KI oder maschinelles Lernen, Analysen, Batchverarbeitung, lokales Caching und In-Memory-Datenbanken.
- Ihre Anwendungen haben spezielle Speicheranforderungen, und Sie möchten Rohblockzugriff auf leistungsstarken sitzungsspezifischen Speicher haben.
- Sie möchten spezielle Datenanwendungen ausführen und lokale SSD-Volumes wie einen Cache auf Knotenebene für Ihre Pods ausführen. Mit diesem Ansatz können Sie die Leistung von In-Memory-Datenbankanwendungen wie Aerospike oder Redis verbessern.
Sitzungsspezifischer Speicher
Wir empfehlen die Verwendung der --ephemeral-storage-local-ssd-Option, um lokale SSDs für sitzungsspezifischen Knotenspeicher bereitzustellen. Dies ist die Standardeinstellung, wenn Sie eine Maschinenserie der dritten Generation verwenden.
Bei diesem Ansatz werden die emptyDir-Volumes, Container-Beschreibbare Ebenen und Images, die zusammen Ihren sitzungsspezifischen Knotenspeicher auf der lokalen SSD bilden. Zu den Vorteilen gehören eine verbesserte E/A-Bandbreite als der standardmäßige nichtflüchtige Speicher und verbesserte Pod-Startzeiten.
Die Verwendung lokaler SSDs für sitzungsspezifischen Knotenspeicher bedeutet, dass lokale SSD-Laufwerke im Bootlaufwerk nicht für andere Zwecke verfügbar sind. Ändern Sie das Bootlaufwerk nicht direkt mit einem privilegierten Daemonset, HostPath oder einem anderen Mechanismus, andernfalls schlägt der Knoten möglicherweise fehl. Wenn Sie die lokalen SSD-Volumes genau steuern möchten, verwenden Sie stattdessen den Rohdatenblock.
Gerätespeicher blockieren
Der Blockspeicher für Geräte ermöglicht einen zufälligen Zugriff auf Daten in festen Blöcken. Einige spezielle Anwendungen erfordern direkten Zugriff auf einen Blockgerätespeicher, da die Dateisystemebene beispielsweise unnötigen Overhead verursacht.
Typische Szenarien für die Verwendung des Blockgerätespeichers sind:
- Datenbanken, bei denen Daten direkt im zugrunde liegenden Speicher organisiert sind.
- Software, die selbst eine Art Speicherdienst implementiert (softwaredefinierte Speichersysteme).
In der GKE-Version 1.25.3-gke.1800 und höher können Sie mit der Option --local-nvme-ssd-block Cluster und Knotenpools mit angehängten lokalen NVMe-SSD-Rohdaten erstellen. Sie können dann Blockspeicher anpassen, indem Sie ein Dateisystem Ihrer Wahl (z. B. ZFS oder HDFS) formatieren und RAID konfigurieren. Diese Option ist geeignet, wenn Sie zusätzliche Kontrolle über Arbeitslasten benötigen, die speziell Zugriff auf Blockspeicher erfordern, der von lokalen SSDs unterstützt wird.
Sie können den Ansatz des Blockzugriffs auch mit lokalen SSDs verwenden, wenn Sie einen einheitlichen Daten-Cache für Daten von Pods verwenden möchten und die Daten an einen Knotenlebenszyklus gebunden sind. Dazu installieren Sie ein DaemonSet mit einer RAID-Konfiguration, formatieren ein Dateisystem und verwenden ein lokales PersistentVolume, um Daten zwischen Pods freizugeben.
Maschinenanforderungen
Die Art, wie Sie lokale SSD für Ihre GKE-Cluster und -Knotenpools bereitstellen, hängt vom zugrunde liegenden Maschinentyp ab. GKE unterstützt lokale SSD-Volumes auf der Maschinenserie der ersten, zweiten und dritten Generation von Compute Engine. Für lokale SSD-Volumes ist der Maschinentyp n1-standard-1 oder höher erforderlich.
Der Standardmaschinentyp e2-medium wird nicht unterstützt.
Verwenden Sie zur Identifizierung Ihrer Maschinenserie die Nummer im Namen des Maschinentyps. N1-Maschinen sind beispielsweise die erste Generation und N2-Maschinen der zweiten Generation.
Eine Liste der verfügbaren Maschinenserien und -typen finden Sie in der Compute Engine-Dokumentation unter Ressourcen- und Vergleichsanleitung für Maschinenfamilien.
Anforderungen der Maschinenserie der ersten und zweiten Generation
Wenn Sie eine Maschinenserie der ersten oder zweiten Generation mit lokaler SSD verwenden möchten, muss auf Ihrem Cluster oder Knotenpool die GKE-Version 1.25.3-gke.1800 oder höher ausgeführt werden.
Wenn Sie eine lokale SSD auf einer Maschinenserie der ersten oder zweiten Generation bereitstellen möchten, geben Sie die Anzahl der lokalen SSD-Volumes an, die mit Ihrer VM verwendet werden sollen. Eine Liste der Maschinenserien und der entsprechenden zulässigen Anzahl lokaler SSDs finden Sie in der Compute Engine-Dokumentation unter Gültige Anzahl lokaler SSDs auswählen.
Anforderungen für Maschinenserien der dritten Generation
Wenn Sie eine Maschinenserie der dritten Generation mit lokaler SSD verwenden möchten, muss Ihr Cluster oder Knotenpool eine der folgenden GKE-Versionen oder höher ausführen:
- 1.25.13-gke.200 bis 1.26
- 1.26.8-gke.200 bis 1.27
- 1.27.5-gke.200 bis 1.28
- 1.28.1-gke.200 bis 1.29
Für die Maschinenserie der dritten Generation ist jeder Maschinentyp entweder ohne lokale SSD oder eine feste Anzahl lokaler SSD-Volumes vorkonfiguriert. Sie geben die Anzahl der lokalen SSD-Volumes an, die einbezogen werden sollen. Stattdessen wird die für Ihre Cluster verfügbare lokale SSD-Kapazität implizit als Teil der VM-Form definiert.
Eine Liste der Maschinenserien und der entsprechenden zulässigen Anzahl lokaler SSDs finden Sie in der Compute Engine-Dokumentation unter Gültige Anzahl lokaler SSDs auswählen.
Nutzungsmuster für lokale SSD-Volumes
So verwenden Sie lokale SSD-Volumes in Ihren Clustern:
- Knotenpool mit angehängtem lokalem SSD-Speicher bereitstellen: Um einen GKE-Knotenpool mit angehängten lokalen SSDs zu erstellen, übergeben Sie entweder den sitzungsspezifischen Speicherparameter oder den Rohblockspeicherparameter, wenn Sie den
create clusterverwenden. Mit den Parametern für die lokale SSD wird ein GKE-Knotenpool erstellt, bei dem lokale SSD angehängt und als lokaler sitzungsspezifischer Speicher oder Rohblockspeicher konfiguriert wird, je nachdem, welche Parameter Sie auswählen. Weitere Informationen zu den Optionen für die Bereitstellung lokaler SSDs finden Sie unter Lokale SSD-Parameter. - Zugriff auf Daten von lokalen SSD-Volumes: Um die Daten von lokalen SSD-Volumes zu verwenden, können Sie ein Kubernetes-Konstrukt wie ein emptyDir-Volume oder ein lokales nichtflüchtiges Volume verwenden. Weitere Informationen zu diesen Optionen finden Sie unter Lokaler SSD-Zugriff.
Lokale SSD-Parameter in GKE
In der folgenden Tabelle sind die empfohlenen Parameter zusammengefasst, die GKE für die Bereitstellung von lokalem SSD-Speicher auf Clustern bereitstellt. Sie können diese Parameter mit der gcloud CLI übergeben.
| Lokaler SSD-Typ | gcloud CLI-Befehl | GKE-Verfügbarkeit | Lokales SSD-Profil |
|---|---|---|---|
| Sitzungsspezifischer lokaler SSD-Speicher | gcloud container clusters create |
v1.25.3-gke.1800 oder höher |
Speichertechnologie: NVMe Für mehrere Pods freigegebene Daten: Nein Datenlebenszyklus: Pod Größe und Notwendigkeit der RAID-Konfiguration: Bis zu 9 TiB. GKE konfiguriert RAID automatisch im Hintergrund. Format: Dateisystem (Kubernetes emptyDir) Kubernetes-Planer-Integration: Standardmäßig vollständig eingebunden. Der Kubernetes-Planer sorgt dafür, dass auf dem Knoten Platz bleibt, bevor die Knoten platziert und bei Bedarf skaliert werden. Informationen zur Verwendung dieses API-Parameters finden Sie unter Lokalen SSD-gestützten Speicher bereitstellen und verwenden. |
| Lokaler NVMe-SSD-Block | gcloud container clusters create |
v1.25.3-gke.1800 oder höher |
Speichertechnologie: NVMe Für mehrere Pods freigegebene Daten: Ja, über lokale PVs. Datenlebenszyklus: Knoten Größe und Notwendigkeit der RAID-Konfiguration: Bis zu 9 TiB. Bei größeren Größen müssen Sie RAID manuell konfigurieren. Format: Rohblock Kubernetes-Planer-Integration: Nein, standardmäßig. Sie müssen die Kapazität auf Knoten sicherstellen und Noisy Neighbours bewältigen. Wenn Sie das lokale PV aktivieren, ist die Planung eingebunden. Informationen zur Verwendung dieses API-Parameters finden Sie unter Lokalen SSD-gestützten Rohblockspeicher bereitstellen und verwenden. |
Unterstützung für vorhandene lokale SSD-Parameter
In der folgenden Tabelle sind diese vorhandenen lokalen SSD-Parameter und die empfohlenen Substitutionen zusammengefasst:
| Vorhandene lokale SSD-Parameter | gcloud CLI-Befehl | Lokales SSD-Profil | Empfohlene GA-Version der lokalen SSD-Parameter |
|---|---|---|---|
| Parameter für Anzahl der lokalen SSDs | gcloud container clusters create |
Speichertechnologie: SCSI Für Pods freigegebene Daten: Ja, über lokale PVs Datenlebenszyklus: Knoten Größe und Notwendigkeit einer RAID-Konfiguration: 375 GiB In größeren Fällen müssen Sie RAID manuell konfigurieren. Format: Dateisystem (ext-4) Kubernetes-Planer-Integration: Nein, standardmäßig. Sie müssen die Kapazität auf Knoten sicherstellen und Noisy Neighbours bewältigen. Wenn Sie das lokale PV aktivieren, ist die Planung eingebunden. |
gcloud container clusters create |
| Flüchtiger Speicherparameter (Beta) | gcloud beta container clusters create |
Speichertechnologie: NVMe Für mehrere Pods freigegebene Daten: Nein Datenlebenszyklus: Pod Größe und Notwendigkeit der RAID-Konfiguration: Bis zu 9 TiB. GKE konfiguriert RAID automatisch im Hintergrund. Format: Dateisystem (Kubernetes emptyDir) Kubernetes-Planer-Integration: Standardmäßig vollständig eingebunden. Der Kubernetes-Planer sorgt dafür, dass auf den Knoten Platz bleibt, bevor die Knoten platziert werden, und skalieren bei Bedarf. |
gcloud container clusters create |
| Parameter „Lokale SSD-Volumes“ (Alpha) | gcloud alpha container clusters create |
Speichertechnologie: NVMe oder SCSI Für mehrere Pods freigegebene Daten: Nein Datenlebenszyklus: Knoten Größe und Notwendigkeit einer RAID-Konfiguration: 375 GiB. Bei größeren Größen müssen Sie RAID manuell konfigurieren. Format: Dateisystem (ext-4) oder Rohblock Kubernetes-Planer-Integration: Nein, Sie müssen standardmäßig die Kapazität auf Knoten sicherstellen und Noisy Neighbours bewältigen. |
gcloud container clusters create |
Lokaler SSD-Zugriff
Sie haben folgende Möglichkeiten, auf lokale SSD-Volumes zuzugreifen.
emptyDir-Volume
In der GKE-Version 1.25.3-gke.1800 und höher können Sie sitzungsspezifischen Speicher als emptyDir-Volume über lokale SSDs über die Option --ephemeral-storage-local-ssd verwenden. Wir empfehlen diesen Ansatz in den meisten Fällen, einschließlich Anwendungen, die einen leistungsfähigen sitzungsspezifischen temporären Speicherbereich benötigen.
Mit GKE können Sie einen Knotenpool konfigurieren, um sitzungsspezifischen Knotenspeicher auf lokalen SSDs mit einer NVMe-Schnittstelle bereitzustellen.
Weitere Informationen finden Sie in diesem Beispiel.
Lokales nichtflüchtiges Volume
Ein lokales nichtflüchtiges Volume stellt ein lokales Laufwerk dar, das mit einem einzelnen Knoten verbunden ist. Mit lokalen nichtflüchtigen Volumes können Sie lokale SSD-Ressourcen über Pods hinweg gemeinsam nutzen. Da es sich bei dem lokalen Laufwerk um ein lokales SSD-Laufwerk handelt, sind die Daten weiterhin sitzungsspezifisch.
Wir empfehlen diesen Ansatz, wenn eine der folgenden Ausführungen auf Ihrem Cluster ausgeführt wird:
- Arbeitslasten mit StatefulSets und volumeClaimTemplates.
- Arbeitslasten, die sich Knotenpools teilen. Jedes lokale SSD-Volume kann über einen PersistentVolumeClaim reserviert werden. Spezifische HostPaths werden nicht direkt in der Pod-Spezifikation codiert.
- Pods, die Datenbindung an dieselbe lokale SSD voraussetzen. Ein Pod wird immer für denselben Knoten wie sein lokales PersistentVolume eingeplant.
Weitere Informationen finden Sie in diesem Beispiel und der Open-Source-Dokumentation zu Volumes von Kubernetes.
Einschränkungen
Ihre Anwendung muss den Verlust des Zugriffs auf Daten auf lokalen SSD-Volumes reibungslos verarbeiten können. Daten, die auf ein lokales SSD-Laufwerk geschrieben werden, gehen verloren, wenn der Pod oder Knoten gelöscht, repariert oder aktualisiert wird oder ein nicht behebbarer Fehler auftritt.
Der sitzungsspezifische Speicher für lokale SSDs konfiguriert lokale SSD-Volumes so, dass sie einen Pod-basierten Datenlebenszyklus haben. Der Parameter für lokale NVMe-SSD-Blöcke konfiguriert lokale SSD-Volumes für einen knotenbasierten Datenlebenszyklus.
Wenn Sie nichtflüchtigen Speicher benötigen, empfehlen wir eine dauerhafte Speicheroption (z. B. Persistent Disk, Filestore oder Cloud Storage). Sie können auch regionale Replikate verwenden, um das Risiko eines Datenverlusts während des Lebenszyklus von Clustern oder Anwendungen zu minimieren.
Die Konfigurationseinstellungen der lokalen SSD können nach dem Erstellen des Knotenpools nicht mehr geändert werden. Sie können die lokale SSD-Konfiguration für einen vorhandenen Knotenpool nicht aktivieren, deaktivieren oder aktualisieren. Sie müssen den Knotenpool löschen und einen neuen erstellen, um Änderungen vorzunehmen.
Pods, die emptyDir verwenden, verwenden eine transparente lokale SSD. Dies gilt jedoch für alle Pods auf allen Knoten im Knotenpool. GKE unterstützt nicht die Verwendung einiger Pods im selben Knotenpool, die lokale SSD-DirDir-Volumes verwenden, die von einer lokalen SSD unterstützt werden, und andere Pods, die emptyDir-Volumes verwenden, die von einem Knoten-Bootlaufwerk unterstützt werden. Wenn Sie Arbeitslasten haben, die emptyDir-Volumes verwenden, die von einem Bootlaufwerk für Knoten unterstützt werden, planen Sie die Arbeitslasten in einem anderen Knotenpool.
Autopilot-Cluster und automatische Knotenbereitstellung werden für lokale SSDs nicht unterstützt.
Wir empfehlen die Verwendung der lokalen SSD als sitzungsspezifischer Speicher für Arbeitslasten, die auf speicheroptimierten VMs (Z3) ausgeführt werden. Z3-Knoten werden während Wartungsereignissen beendet. Daten auf der lokalen SSD für diese Knoten sind daher während einer Wartung möglicherweise nicht verfügbar und eine Datenwiederherstellung wird nach der Wartung nicht garantiert.
Nächste Schritte
- Lokalen SSD-Speicher bereitstellen und verwenden
- Lokalen SSD-gestützten Blockspeicher bereitstellen und verwenden