Knoten für die Verwendung von Festplattenspeicher als virtuellen Arbeitsspeicher konfigurieren

Mit dem GKE-Knoten-Arbeitsspeicheraustausch (Google Kubernetes Engine) können GKE-Knoten Speicherplatz als virtuellen Arbeitsspeicher verwenden, wenn der physische Arbeitsspeicher erschöpft ist. Der Knotenspeicher-Swap kann die Ausfallsicherheit von Anwendungen verbessern und Fehler aufgrund von unzureichendem Arbeitsspeicher (Out-of-Memory, OOM) für bestimmte Arbeitslasten verhindern.

Wann sollte der Knotenspeicher-Swap verwendet werden?

Verwenden Sie den Knotenspeicher-Swap, um einen Puffer gegen OOM-Fehler für speicherintensive Anwendungen bereitzustellen, insbesondere bei unerwarteten Nutzungsspitzen. Der Knotenspeicher-Swap kann die Ausfallsicherheit Ihrer Arbeitslast verbessern, z. B. in den folgenden Szenarien:

  • Arbeitslasten mit unvorhersehbaren Speichermustern ausführen
  • Risiko von Anwendungsabstürzen aufgrund von Knotenspeichererschöpfung reduzieren.
  • Optimieren Sie die Kosten, indem Sie eine Überdimensionierung des Arbeitsspeichers für gelegentliche Spitzen vermeiden.

Funktionsweise des Knotenspeicheraustauschs

Wenn Sie den Knotenspeicher-Swap aktivieren, konfiguriert GKE das Betriebssystem des Knotens so, dass Speicherplatz als virtueller Speicher verwendet wird. Dieser Prozess bietet einen Puffer für Anwendungen, die vorübergehend unter Arbeitsspeicherdruck stehen.

Die GKE berechnet die Container-Swap-Limits basierend auf den Arbeitsspeicherressourcenlimits des Containers und dem Gesamtarbeitsspeicher des Knotens.

Sie können Swap auf verschiedenen Speichertypen konfigurieren, um Leistung und Kosten auszugleichen:

  • Bootlaufwerk: Verwendet das Bootlaufwerk des Knotens als Auslagerungsspeicher.
  • Sitzungsspezifische lokale SSD: Verwendet eine lokale SSD, die auch für sitzungsspezifischen Pod-Speicher freigegeben ist. Wenn der Knoten eine gemischte lokale SSD-Kapazität verwendet, wird für den Swap nur der sitzungsspezifische Speicherteil der lokalen SSDs verwendet.
  • Dedizierte lokale SSD: Reserviert eine oder mehrere lokale SSDs ausschließlich für den Swap.

Zum Schutz sensibler Daten verschlüsselt die GKE den Swap-Speicher standardmäßig mit einem sitzungsspezifischen Schlüssel.

Anforderungen und Einschränkungen

Für den Knotenspeicher-Swap gelten die folgenden Anforderungen und Einschränkungen:

  • GKE-Cluster müssen Version 1.34.1-gke.1341000 oder höher haben.
  • Nur Pods mit der Dienstqualitätsklasse (Quality of Service, QoS) Burstable können den Knotenspeicher-Swap verwenden. Weitere Informationen zu Dienstqualitätsklassen finden Sie in der Kubernetes-Dokumentation unter Pod-Dienstqualitätsklassen.
  • Wenn Sie die Größe der Arbeitsspeicherressourcen von Containern anpassen möchten, müssen Sie die Richtlinie zur Größenanpassung von Containern auf RestartContainer festlegen.
  • Wenn Sie den Knotenspeicher-Swap so konfigurieren, dass ein Bootlaufwerk verwendet wird, darf die Swap-Größe 50 % der Gesamtkapazität des Bootlaufwerks nicht überschreiten.

Wenn Sie den Knotenspeicher-Swap so konfigurieren, dass eine lokale SSD verwendet wird, müssen die folgenden Anforderungen erfüllt sein:

  • Der Maschinentyp muss lokale SSDs unterstützen. Sie können nur lokale SSDs verwenden, die als sitzungsspezifischer Speicher oder gemischter Speicher bereitgestellt wurden. Sie können keine lokalen SSDs verwenden, die als Rohblockspeicher bereitgestellt wurden. Eine Liste der unterstützten Swap-Profile in diesem Modus finden Sie unter Knotenspeicher-Swap mit gemischter lokaler SSD-Kapazität.
  • Knoten müssen mit lokalen SSDs bereitgestellt werden. Die Bereitstellungsmethode hängt von der Maschinenserie ab:
    • Legen Sie für Maschinenserien der ersten oder zweiten Generation das Flag --ephemeral-storage-local-ssd=count fest.
    • Wählen Sie für eine Maschinenserie der dritten oder vierten Generation einen Maschinentyp aus, der lokale SSDs bündelt.
  • Der Standardmaschinentyp e2-medium unterstützt keine lokalen SSDs. Sie müssen daher einen anderen Maschinentyp auswählen.
  • Eine Anleitung zum Erstellen oder Aktualisieren eines Clusters, damit er lokale SSDs bereitstellt, finden Sie unter Sitzungsspezifischen lokalen SSD-gestützten Speicher bereitstellen und verwenden.

Best Practices

Der Knotenspeicher-Swap ist als Sicherheitsnetz für unvorhersehbare Speicherspitzen gedacht, nicht als Ersatz für ausreichenden physischen Speicher. Informationen zur Optimierung von Arbeitslasten finden Sie unter Größe von GKE-Arbeitslasten in großem Maßstab anpassen.

Beachten Sie außerdem die folgenden Best Practices, wenn Sie den Knotenspeicheraustausch verwenden:

  • Isolieren Sie Knoten mit aktiviertem Knotenspeicher-Swap, indem Sie eine Markierung auf den Knotenpool anwenden, z. B. gke-swap=enabled:NoSchedule, und den Arbeitslasten, die Swap verwenden sollen, eine entsprechende Toleranz hinzufügen.
  • Dimensionieren Sie den Auslagerungsspeicher des Knotens entsprechend. Unzureichender Arbeitsspeicher auf dem Knoten; Auslagerungsbereich verhindert möglicherweise keine OOM-Fehler und eine übermäßige Nutzung kann die Leistung beeinträchtigen.
  • Überwachen Sie die Nutzung des Knotenspeicheraustauschs für Ihre Arbeitslasten. Häufige Verwendung des Knotenspeicheraustauschs kann ein Indikator für Arbeitsspeichermangel sein.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
  • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Knotenspeicher-Swap aktivieren

Sie können den Knotenspeicher-Swap für einen Cluster oder Knotenpool aktivieren. Wenn Sie den Knotenspeicher-Swap aktivieren möchten, erstellen oder aktualisieren Sie eine system-config.yaml-Datei, die die gewünschte Knotenspeicher-Swap-Konfiguration enthält. Im folgenden Beispiel wird der Knotenspeicher-Swap mit Standardeinstellungen aktiviert:

linuxConfig:
  swapConfig:
    enabled: true

Es gibt weitere Einstellungen, die Sie konfigurieren können. In diesem Beispiel wird ein unverschlüsselter Swap so konfiguriert, dass 30 % des Speichers einer sitzungsspezifischen lokalen SSD verwendet werden:

linuxConfig:
  swapConfig:
    enabled: true
    encryptionConfig:
      disabled: true
    ephemeralLocalSsdProfile:
      swapSizePercent: 30

Eine Liste der optionalen Felder, die Sie konfigurieren können, finden Sie in der LinuxNodeConfig-API-Dokumentation.

Knoten-Arbeitsspeicherauslagerung in einem Cluster aktivieren

Führen Sie einen der folgenden Schritte aus, um den Knotenspeicher-Swap für einen Cluster zu aktivieren:

  • Führen Sie den folgenden Befehl aus, um einen neuen Cluster mit aktiviertem Knotenspeicher-Swap zu erstellen:

    gcloud container clusters create CLUSTER_NAME \
        --location=LOCATION \
        --cluster-version=1.34.1-gke.1341000 \
        --system-config-from-file=system-config.yaml
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des neuen Clusters.
    • LOCATION: die Region oder Zone für Ihren Cluster.
  • Führen Sie den folgenden Befehl aus, um einen vorhandenen Cluster zu aktualisieren und den Knotenspeicher-Swap zu aktivieren:

    gcloud container clusters update CLUSTER_NAME \
        --location=LOCATION \
        --system-config-from-file=system-config.yaml
    

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des neuen Clusters.
    • LOCATION: die Region oder Zone für Ihren Cluster.

Knotenarbeitsspeicher-Swap für einen Knotenpool aktivieren

Führen Sie einen der folgenden Schritte aus, um den Knotenspeicher-Swap für einen Knotenpool zu aktivieren:

  • Führen Sie den folgenden Befehl aus, um einen neuen Knotenpool mit aktiviertem Knotenspeicher-Swap zu erstellen:

    gcloud container node-pools create NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --location=LOCATION \
        --node-version=1.34.1-gke.1293000 \
        --system-config-from-file=system-config.yaml \
        --machine-type=MACHINE_TYPE
    

    Ersetzen Sie Folgendes:

    • NODEPOOL_NAME ist der Name des neuen Knotenpools.
    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Region oder Zone für Ihren Cluster.
    • MACHINE_TYPE: ein kompatibler Maschinentyp. Wählen Sie für lokale SSDs einen Maschinentyp aus, der lokale SSDs bündelt, z. B. n1-standard-1.
  • Führen Sie den folgenden Befehl aus, um einen vorhandenen Knotenpool zu aktualisieren und den Knotenspeicher-Swap zu aktivieren:

    gcloud container node-pools update NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --location=LOCATION \
        --system-config-from-file=system-config.yaml
    

    Ersetzen Sie Folgendes:

    • NODEPOOL_NAME: Der Name des Knotenpools.
    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Region oder Zone für Ihren Cluster.

Konfiguration prüfen

So prüfen Sie, ob der Knotenspeicher-Swap aktiviert ist:

  1. Prüfen Sie mit dem folgenden Befehl, ob die system-config.yaml mit den swapConfig-Einstellungen angewendet wird:

    gcloud container node-pools describe NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --location=LOCATION \
        --format='yaml(config.linuxNodeConfig.swapConfig)'
    
  2. Prüfen Sie mit dem folgenden Befehl, ob die kubelet-Konfiguration auf dem Knoten vorhanden ist:

    kubectl get --raw "/api/v1/nodes/NODE_NAME/proxy/configz" | jq .kubeletconfig.memorySwap
    

Arbeitsspeicherauslagerung überwachen

Sie können den Knotenspeicher mit Cloud Monitoring oder kubectl überwachen.

Monitoring

Die folgenden Systemmesswerte sind standardmäßig verfügbar, um die Swap-Nutzung zu beobachten:

  • kubernetes.io/node/memory/swap_used_bytes
  • kubernetes.io/container/memory/swap_used_bytes

GKE bietet auch Messwerte zur Swap-Nutzung auf Containerebene über cAdvisor. Wenn Sie diese Messwerte verwenden möchten, aktivieren Sie cAdvisor im Cluster:

  • prometheus.googleapis.com/container_memory_swap/gauge

kubectl

Führen Sie die folgenden Schritte aus, um die Swap-Nutzung mit kubectl-Befehlen zu überwachen:

  1. Prüfen Sie die Bedingung SwapDetected für das Knotenobjekt mit dem folgenden Befehl:

    kubectl get node NODE_NAME -o jsonpath='{.status.conditions[?(@.type=="Swap")]}' | jq .
    

    Die Ausgabe sieht etwa so aus:

    {
      "lastHeartbeatTime": "2025-07-11T00:14:52Z",
      "lastTransitionTime": "2025-06-25T05:20:10Z",
      "message": "Swap is active: Total=49Gi Used=0B Free=49Gi",
      "reason": "SwapDetected",
      "status": "True",
      "type": "Swap"
    }
    
  2. Prüfen Sie die Swap-Kapazität mit dem folgenden Befehl:

    kubectl get node NODE_NAME -o jsonpath='{.status.nodeInfo.swap}'
    

    Die Ausgabe sieht etwa so aus:

    {"capacity":53687087104}
    

Knoten-Arbeitsspeicherauslagerung mit gemischter lokaler SSD-Kapazität

Sie können den Knotenspeicher-Swap für Knotenpools aktivieren, die gemischte lokale SSDs bereitstellen. GKE unterstützt die folgenden Swap-Profile:

  • Bootlaufwerk (bootDiskProfile)
  • Sitzungsspezifische lokale SSD (ephemeralLocalSsdProfile): GKE weist Swap-Speicherplatz aus dem sitzungsspezifischen Speicherbereich der lokalen SSDs zu, nicht aus den Rohblockpartitionen.

GKE unterstützt das dedizierte Swap-Profil für lokale SSDs (dedicatedLocalSsdProfile) mit gemischten lokalen SSDs nicht.

Wenn Sie das sitzungsspezifische Profil für lokale SSDs verwenden, beachten Sie Folgendes:

  • Das Feld swapSizePercent ist ein Prozentsatz der sitzungsspezifischen Kapazität, die Sie mit dem Unterfeld capacity festlegen, und nicht die gesamte physische Kapazität der lokalen SSD. Bei Einstellungen wie capacity=200GB und swapSizePercent: 20 weist GKE beispielsweise 40 GiB Swap zu.
  • Durch den Swap-Speicher wird der sitzungsspezifische Speicher reduziert, der für Ihre Pods verfügbar ist. Die GKE berechnet den reservierten sitzungsspezifischen Speicher aus der sitzungsspezifischen Kapazität abzüglich der Swap-Größe.
  • Die Swap-Größe darf 80 % der sitzungsspezifischen Kapazität abzüglich des sitzungsspezifischen Speichers, den GKE für die Systemnutzung reserviert, nicht überschreiten. Wenn die sitzungsspezifische Kapazität zu klein für den Swap ist, schlägt die Anfrage fehl.

In der folgenden system-config.yaml-Beispieldatei werden 20 % der sitzungsspezifischen Kapazität für den Swap zugewiesen:

linuxConfig:
  swapConfig:
    enabled: true
    ephemeralLocalSsdProfile:
      swapSizePercent: 20

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit gemischter lokaler SSD-Kapazität und Knotenspeicher-Swap zu erstellen:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --ephemeral-storage-local-ssd count=NUMBER_OF_DISKS,capacity=CAPACITY \
    --system-config-from-file=system-config.yaml

Ersetzen Sie Folgendes:

  • POOL_NAME: Der Name des neuen Knotenpools, den Sie erstellen möchten.
  • CLUSTER_NAME ist der Name des Clusters.
  • MACHINE_TYPE ist der zu verwendende Maschinentyp. Sie können lokale SSDs nicht mit dem Standardmaschinentyp e2-medium verwenden, da Maschinentypen mit gemeinsam genutztem Kern diese nicht unterstützen.
  • NUMBER_OF_DISKS ist die Anzahl der lokalen SSD-Laufwerke, die auf jedem Knoten bereitgestellt werden sollen.
  • CAPACITY: die gesamte lokale SSD-Kapazität, die für den sitzungsspezifischen Speicher formatiert werden soll. Dieser Wert muss größer als 0 und kleiner als die gesamte physische lokale SSD-Kapazität (Anzahl der Laufwerke × Größe pro Laufwerk) sein, z. B. 200GB.

Knotenspeicher-Swap deaktivieren

Wenn Sie den Knotenspeicher-Swap deaktivieren möchten, aktualisieren Sie die Datei system-config.yaml. Gehen Sie dazu so vor:

  1. Aktualisieren Sie die Datei system-config.yaml, um swapConfig.enabled auf false festzulegen:

    linuxConfig:
      swapConfig:
        enabled: false
    
  2. Aktualisieren Sie den Knotenpool mit der neuen Konfiguration:

    gcloud container node-pools update NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --location=LOCATION \
        --system-config-from-file=system-config.yaml
    

Nächste Schritte