Fehlerbehebung bei Speicher in GKE

Probleme mit dem Speicher in Google Kubernetes Engine-Clustern (GKE) können sich auf verschiedene Weise äußern, von Leistungsengpässen und Fehlern beim Einbinden von Volumes bis hin zu Fehlern bei der Verwendung bestimmter Laufwerkstypen mit bestimmten Maschinentypen. Diese Probleme können sich auf den Anwendungsstatus, die Datenpersistenz und den allgemeinen Zustand der Arbeitslast auswirken.

In diesem Dokument wird beschrieben, wie Sie häufige Probleme mit der Speicherfunktion in Ihren Clustern beheben. Hier finden Sie Anleitungen zur Fehlerbehebung bei Problemen im Zusammenhang mit der Bereitstellung und dem Anhängen von Volumes, dem Datenzugriff und der Leistung sowie der Verwaltung der Speicherkapazität.

Diese Informationen sind sowohl für Plattformadministratoren und ‑operatoren, die die Clusterinfrastruktur und den Speicher verwalten, als auch für Anwendungsentwickler wichtig, deren Arbeitslasten auf persistenten Speicher angewiesen sind. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Fehler 400: RePD kann keiner optimierten VM hinzugefügt werden

Regionale nichtflüchtige Speicher sind von der Verwendung mit speicheroptimierten Maschinen oder computing-optimierten Maschinen ausgeschlossen.

Verwenden Sie eine Speicherklasse für nichtregionale nichtflüchtige Speicher, wenn die Verwendung eines regionalen nichtflüchtigen Speichers keine Notwendigkeit ist. Wenn ein regionaler nichtflüchtiger Speicher erforderlich ist, sollten Sie Planungsstrategien wie Markierungen und Toleranzen in Betracht ziehen. So lässt sich gewährleisten, dass die Pods, die regionalen nichtflüchtigen Speicher benötigen, in einem Knotenpool geplant werden, der keine optimierten Maschinen enthält.

Probleme mit der Laufwerksleistung beheben

Die Leistung des Bootlaufwerks ist wichtig, da das Bootlaufwerk für GKE-Knoten nicht nur für das Betriebssystem, sondern auch für Folgendes verwendet wird:

  • Docker-Images
  • Das Containerdateisystem für das, was nicht als Volume bereitgestellt wird (d. h. das Overlay-Dateisystem). Es enthält häufig Verzeichnisse wie /tmp.
  • Laufwerkgestützte emptyDir-Volumes, es sei denn, der Knoten verwendet eine lokale SSD.

Die Laufwerksleistung wird für alle Laufwerke desselben Laufwerktyps auf einem Knoten geteilt. Beispiel: Wenn Sie ein 100-GB-pd-standard-Bootlaufwerk und ein 100-GB-pd-standard-PersistentVolume mit vielen Aktivitäten haben, beträgt die Leistung des Bootlaufwerks die eines 200-GB-Laufwerks. Wenn auf dem PersistentVolume viele Aktivitäten ausgeführt werden, wirkt sich dies auch auf die Leistung des Bootlaufwerks aus.

Wenn Sie auf Ihren Knoten Meldungen wie die folgenden sehen, kann das ein Anzeichen für eine geringe Laufwerksleistung sein:

INFO: task dockerd:2314 blocked for more than 300 seconds.

fs: disk usage and inodes count on following dirs took 13.572074343s

PLEG is not healthy: pleg was last seen active 6m46.842473987s ago; threshold is 3m0s

Lesen Sie die folgenden Informationen, um solche Probleme zu beheben:

  • Lesen Sie den Artikel Vergleich der Speicherlaufwerktypen und wählen Sie einen nichtflüchtigen Speichertyp aus, der Ihren Anforderungen entspricht.
  • Dieses Problem tritt häufig bei Knoten auf, die nichtflüchtige Standardspeicher mit einer Größe von weniger als 200 GB verwenden. Erwägen Sie, die Größe Ihrer Laufwerke zu erhöhen oder zu SSDs zu wechseln, insbesondere bei Clustern, die in der Produktion verwendet werden.
  • Erwägen Sie, lokale SSDs für sitzungsspezifischen Speicher in Ihren Knotenpools zu aktivieren. Das ist besonders effektiv, wenn Sie Container haben, die häufig emptyDir-Volumes verwenden.

Das Bereitstellen eines Volumes reagiert aufgrund der Einstellung fsGroup nicht mehr

Ein Problem, das dazu führen kann, dass die PersistentVolume-Bereitstellung fehlschlägt, ist ein Pod, der mit der Einstellung fsGroup konfiguriert ist. Normalerweise werden Bereitstellungen automatisch wiederholt und der Bereitstellungsfehler wird von selbst behoben. Wenn sich auf PersistentVolume jedoch eine große Anzahl von Dateien befindet, versucht kubelet, die Eigentümerschaft für jede Datei im Dateisystem zu ändern. Dies kann die Bereitstellungslatenz des Volumes erhöhen.

Unable to attach or mount volumes for pod; skipping pod ... timed out waiting for the condition

Wenn Sie prüfen möchten, ob ein Bereitstellungsfehler auf die Einstellung fsGroup zurückzuführen ist, können Sie die Logs für den Pod prüfen. Wenn das Problem mit der Einstellung fsGroup zusammenhängt, wird der folgende Logeintrag angezeigt:

Setting volume ownership for /var/lib/kubelet/pods/POD_UUID and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699

Wenn PersistentVolume nicht innerhalb weniger Minuten bereitgestellt wird, führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:

Langsame Laufwerkvorgänge verursachen Fehler bei der Pod-Erstellung

Weitere Informationen finden Sie unter Containerd-Problem Nr. 4604.

Betroffene GKE-Knotenversionen: 1.18, 1.19, 1.20.0 bis 1.20.15-gke.2100, 1.21.0 bis 1.21.9-gke.2000, 1.21.10 bis 1.21.10-gke.100, 1.22.0 bis 1.22.6-gke.2000, 1.22.7 bis 1.22.7-gke.100, 1.23.0 bis 1.23.3-gke.700, 1.23.4 bis 1.23.4-gke.100

In den k8s_node container-runtime-Protokollen können die folgenden Beispielfehler angezeigt werden:

Error: failed to reserve container name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0": name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0" is reserved for "1234567812345678123456781234567812345678123456781234567812345678"

Risikominderung

  1. Wenn Pods fehlschlagen, sollten Sie restartPolicy:Always oder restartPolicy:OnFailure in Ihrer PodSpec verwenden.
  2. Erhöhen Sie die Bootlaufwerk-IOPS. Führen Sie beispielsweise ein Upgrade des Laufwerkstyps aus oder erhöhen Sie die Laufwerkgröße.

Diverse Fehlerkorrekturen

Dieses Problem wurde in containerd 1.6.0 und höher behoben. Die GKE-Versionen mit dieser Fehlerkorrektur sind 1.20.15-gke.2100+, 1.21.9-gke.2000+, 1.21.10-gke.100+, 1.22.6-gke.2000+, 1.22.7-gke.100 und höher, 1.23.3-gke.1700 und höher sowie 1.23.4-gke.100 und höher

Änderungen der Volume-Erweiterung werden im Containerdateisystem nicht berücksichtigt

Achten Sie bei der Volume-Erweiterung darauf, immer den PersistentVolumeClaim zu aktualisieren. Wenn Sie ein PersistentVolume direkt ändern, kann dies zu einer fehlschlagenden Volume-Erweiterung führen. Dies könnte zu einem der folgenden Szenarien führen:

  • Wenn ein PersistentVolume-Objekt direkt geändert wird, werden sowohl die PersistentVolume- als auch die PersistentVolumeClaim-Werte auf einen neuen Wert aktualisiert. Die Dateisystemgröße wird jedoch nicht im Container widergespiegelt und verwendet weiterhin die alte Volume-Größe.

  • Wenn ein PersistentVolume-Objekt direkt geändert wird, gefolgt von Aktualisierungen für den PersistentVolumeClaim, wobei das Feld status.capacity auf eine neue Größe aktualisiert wird, kann dies zu Änderungen am PersistentVolume, aber nicht am PersistentVolumeClaim oder Containerdateisystem führen.

So beheben Sie das Problem:

  1. Behalten Sie das geänderte PersistentVolume-Objekt unverändert bei.
  2. Bearbeiten Sie das PersistentVolumeClaim-Objekt und legen Sie spec.resources.requests.storage auf einen Wert fest, der höher als der im PersistentVolume verwendete ist.
  3. Prüfen Sie, ob die Größe des PersistentVolume auf den neuen Wert angepasst wurde.

Nach diesen Änderungen werden die Größe von PersistentVolume, PersistentVolumeClaim und dem Containerdateisystem automatisch durch das Kubelet angepasst.

Prüfen Sie, ob die Änderungen im Pod übernommen werden.

kubectl exec POD_NAME  -- /bin/bash -c "df -h"

Ersetzen Sie POD_NAME durch den an PersistentVolumeClaim angehängten Pod.

Der ausgewählte Maschinentyp sollte eine lokale SSD haben

Beim Erstellen eines Clusters oder eines Knotenpools, der eine lokale SSD verwendet, kann der folgende Fehler auftreten:

The selected machine type (c3-standard-22-lssd) has a fixed number of local SSD(s): 4. The EphemeralStorageLocalSsdConfig's count field should be left unset or set to 4, but was set to 1.

In der Fehlermeldung wird möglicherweise LocalNvmeSsdBlockConfig anstelle von EphemeralStorageLocalSsdConfig angezeigt, je nachdem, was Sie angegeben haben.

Dieser Fehler tritt auf, wenn die Anzahl der angegebenen lokalen SSD-Laufwerke nicht mit der Anzahl der im Maschinentyp enthaltenen lokalen SSD-Laufwerke übereinstimmt.

Geben Sie zum Beheben dieses Problems eine Anzahl lokaler SSDs an, die dem gewünschten Maschinentyp entspricht. Bei Maschinenserien der dritten Generation müssen Sie das Flag „Local SSD“ count weglassen. Der richtige Wert wird dann automatisch konfiguriert.

Hyperdisk Storage Pools: Cluster- oder Knotenpoolerstellung schlägt fehl

Wenn Sie versuchen, Hyperdisk Balanced-Laufwerke als Boot- oder angeschlossene Laufwerke Ihres Knotens in einem Hyperdisk Storage Pool bereitzustellen, kann der Fehler ZONE_RESOURCE_POOL_EXHAUSTED oder ähnliche Compute Engine-Ressourcenfehler auftreten.

Dies geschieht, wenn Sie versuchen, einen GKE-Cluster oder -Knotenpool in einer Zone zu erstellen, in der die Ressourcen knapp werden, z. B.:

  • In der Zone sind möglicherweise nicht genügend Hyperdisk Balanced-Laufwerke verfügbar.
  • Die Zone hat möglicherweise nicht genügend Kapazität, um die Knoten des von Ihnen angegebenen Maschinentyps zu erstellen, z. B. c3-standard-4.

So lösen Sie dieses Problem:

  1. Wählen Sie eine neue Zone in derselben Region mit ausreichend Kapazität für den ausgewählten Maschinentyp aus, in der Hyperdisk Balanced Storage Pools verfügbar sind.
  2. Löschen Sie den vorhandenen Speicherpool und erstellen Sie ihn in der neuen Zone neu. Das liegt daran, dass Speicherpools zonale Ressourcen sind.
  3. Erstellen Sie Ihren Cluster oder Knotenpool in der neuen Zone.

Hohe Speicherauslastung des Knotens erkannt

Wenn Sie Knotenereignisse oder ‑bedingungen im Zusammenhang mit StoragePressureRootFileSystem mit dem Grund StoragePressureDetected beobachten, deutet dies darauf hin, dass das Stammdateisystem des Knotens oder ein wichtiger Speichereinbindungspunkt eine hohe Festplattennutzung aufweist und sich seiner Kapazität nähert.

Wenn Sie einen Knoten mit dem Befehl kubectl describe node NODE_NAME beschreiben, wird möglicherweise ein Ereignis wie dieses angezeigt:

Events:
  Type     Reason                      Age   From                     Message
  ----     ------                      ----  ----                     -------
  ...
  Warning  StoragePressureDetected     46m   device-capacity-monitor  Node condition StoragePressureRootFileSystem is now: True, reason: StoragePressureDetected, message: "Disk /dev/nvme0n1 usage 89% exceeds threshold 85%"

Ursache:

Der Grund StoragePressureDetected bedeutet, dass die Festplattennutzung im Root-Dateisystem des Knotens (häufig mnt/stateful_partition oder zugehörige Mounts) einen vordefinierten Schwellenwert (z. B. 85%) überschritten hat. Das kann folgende Ursachen haben:

  • Arbeitslasten, die übermäßig viele Daten in emptyDir-Volumes schreiben, die nicht von lokalen SSDs unterstützt werden.
  • Große Container-Images werden auf den Knoten abgerufen.
  • Logdateien, die sich auf dem Knoten ansammeln.
  • Andere Prozesse, die Speicherplatz belegen.

Eine anhaltend hohe Festplattennutzung kann zu Knoteninstabilität, Pod-Bereinigungen und Anwendungsfehlern führen.

Debugging und Lösung:

Festplattennutzung ermitteln: Stellen Sie über SSH eine Verbindung zum betroffenen Knoten her und prüfen Sie mit Befehlen wie df -h die Festplattennutzung an verschiedenen Mount-Punkten. Achten Sie dabei besonders auf /mnt/stateful_partition und alle Mounts für temporären Speicher.

Speichermuster der Arbeitslast analysieren: Prüfen Sie die Speicheranforderungen und Nutzungsmuster der Pods, die auf dem Knoten ausgeführt werden. Ermitteln Sie, ob bestimmte Arbeitslasten überproportional viel sitzungsspezifischen Speicherplatz belegen.

Speicherkapazität des Knotens erhöhen: Die primäre Lösung besteht oft darin, dafür zu sorgen, dass Ihre Knoten über eine ausreichende Speicherkapazität für Ihre Arbeitslasten verfügen. Berücksichtige Folgendes:

  • Größere Bootlaufwerke verwenden: Wählen Sie beim Erstellen von Knotenpools eine größere Bootlaufwerkgröße aus, wenn für Ihre Arbeitslasten mehr flüchtiger Speicher im Stammdateisystem erforderlich ist.
  • Größere lokale SSDs für sitzungsspezifischen Speicher verwenden: Konfigurieren Sie für Arbeitslasten, die einen leistungsstarken, latenzarmen sitzungsspezifischen Speicher benötigen, Ihre Knotenpools so, dass lokale SSDs verwendet werden. Dadurch wird eine separate, größere Kapazität für emptyDir-Volumes bereitgestellt.
  • Arbeitslastanfragen oder ‑limits anpassen: Achten Sie darauf, dass Ihre Pod-Spezifikationen geeignete Anfragen und Limits für sitzungsspezifischen Speicher enthalten, damit der Scheduler Pods auf Knoten mit ausreichend Speicherplatz platzieren kann und eine unkontrollierte Festplattennutzung verhindert wird.
  • Nicht verwendete Ressourcen bereinigen: Entfernen Sie alle unnötigen Dateien, alten Container-Images oder Logs vom Knoten, wenn sie zur hohen Festplattennutzung beitragen.

Wenn Sie die Speicherkapazität und ‑nutzung auf dem Knoten berücksichtigen, können Sie Probleme im Zusammenhang mit StoragePressureDetected beheben und den Knotenbetrieb unterstützen.

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen: