Fehlerbehebung bei Speicher in GKE

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

In diesem Dokument finden Sie Informationen zur Behebung häufiger Probleme mit der Speicherfunktion in Ihren Clustern. 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 Clusterinfrastruktur und Speicher verwalten, als auch für Anwendungsentwickler, deren Arbeitslasten auf nichtflüchtigen Speicher angewiesen sind, wichtig. Weitere Informationen zu den 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-Speicherpools: Erstellung von Clustern oder Knotenpools schlägt fehl

Wenn Sie versuchen, Hyperdisk Balanced-Laufwerke als Boot- oder angehängte Laufwerke Ihres Knotens in einem Hyperdisk-Speicherpool 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 sind, z. B.:

  • In der Zone sind möglicherweise nicht genügend Hyperdisk Balanced-Laufwerke verfügbar.
  • In der Zone ist möglicherweise nicht genügend Kapazität vorhanden, 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 ausreichender Kapazität für den ausgewählten Maschinentyp aus, in der Hyperdisk Balanced-Speicherpools 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 Auslastung des Knotenspeichers erkannt

Wenn Sie Knotenereignisse oder Bedingungen im Zusammenhang mit StoragePressureRootFileSystem mit dem Grund StoragePressureDetected beobachten, deutet dies darauf hin, dass das Root-Dateisystem des Knotens oder ein kritischer Speicherbereitstellungspunkt eine hohe Laufwerksnutzung aufweist und sich der Kapazitätsgrenze 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 Laufwerksnutzung im Stammdateisystem des Knotens (häufig mnt/stateful_partition oder zugehörige Bereitstellungen) einen vordefinierten Schwellenwert (z. B. 85%) überschritten hat. Dies kann folgende Ursachen haben:

  • Arbeitslasten, die übermäßig viele Daten auf emptyDir-Volumes schreiben, die nicht durch lokale SSDs gesichert sind.
  • Große Container-Images, die auf den Knoten übertragen werden.
  • Logdateien, die sich auf dem Knoten ansammeln.
  • Andere Prozesse, die Speicherplatz belegen.

Eine anhaltend hohe Laufwerksauslastung kann zu instabilen Knoten, Pod-Entfernungen und Anwendungsausfällen führen.

Debugging und Fehlerbehebung:

Speichernutzung ermitteln: Stellen Sie über SSH eine Verbindung zum betroffenen Knoten her und verwenden Sie Befehle wie df -h, um die Speichernutzung an verschiedenen Bereitstellungspunkten zu prüfen. Achten Sie dabei besonders auf /mnt/stateful_partition und alle sitzungsspezifischen Speicherbereitstellungen.

Speichermuster von Arbeitslasten analysieren: Prüfen Sie die Speicheranfragen und Nutzungsmuster der Pods, die auf dem Knoten ausgeführt werden. Prüfen Sie, ob bestimmte Arbeitslasten überproportional viel sitzungsspezifischen Speicher verbrauchen.

Knotenspeicherkapazität erhöhen: Beachten Sie, dass die primäre Lösung oft darin besteht, dafür zu sorgen, dass Ihre Knoten über ausreichend 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 Ihre Arbeitslasten mehr sitzungsspezifischen Speicher im Stammdateisystem erfordern.
  • Größere lokale SSDs für sitzungsspezifischen Speicher verwenden: Konfigurieren Sie Ihre Knotenpools für Arbeitslasten, die einen leistungsstarken sitzungsspezifischen Speicher mit niedriger Latenz erfordern, 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 Planer Pods auf Knoten mit ausreichend Speicherplatz platzieren kann und eine unkontrollierte Laufwerksnutzung verhindert wird.
  • Nicht verwendete Ressourcen bereinigen: Entfernen Sie alle unnötigen Dateien, alten Container-Images oder Logs vom Knoten, wenn sie zur hohen Laufwerksnutzung beitragen.

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

Fehlerbehebung bei Cloud Storage FUSE-OOM-Ereignissen (Out of Memory)

Wenn Ihre Pods eine hohe Arbeitsspeicherauslastung oder OOM-Ereignisse (Out of Memory) im Zusammenhang mit dem Cloud Storage FUSE-CSI-Treiber aufweisen, können Sie CPU- und Arbeitsspeicher-Snapshots mit Cloud Profiler erfassen und analysieren. Richten Sie diese Optionen unter Sidecar-Container des Cloud Storage FUSE-CSI-Treibers konfigurieren ein.

Wenn ein Pod durch OOM beendet wird, können Sie das Ereignis mit dem folgenden Workflow dem richtigen Cloud Profiler-Snapshot zuordnen:

  1. Cloud Logging prüfen: Rufen Sie Cloud Logging auf, um das Kubernetes-OOM-Ereignis zu finden.

  2. Nach Pod-Name filtern: Führen Sie die folgende Abfrage aus, um die Ereignisprotokolle für Ihren spezifischen Pod zu finden. Ersetzen Sie dabei POD_NAME durch den Namen des Arbeitslast-Pods:

    jsonPayload.involvedObject.name="POD_NAME"
jsonPayload.involvedObject.kind="Pod"
OOMKilled

  3. Pod-UID extrahieren: Maximieren Sie das entsprechende OOM-Ereignisprotokoll und notieren Sie sich den Zeitstempel und die genaue Pod-UID unter jsonPayload.involvedObject.uid.

  4. In Cloud Profiler analysieren: Rufen Sie Cloud Profiler auf, filtern Sie die Dienstversion im Format POD_NAME_POD_UID und passen Sie den Zeitraum an den OOM-Zeitstempel an. So können Sie sich das genaue Speicherprofil der jeweiligen Containerinstanz direkt vor dem Beenden ansehen.

Zustandsorientierte Arbeitslasten bleiben aufgrund unzureichender Rechenkapazität im Status Pending hängen

Wenn Sie zustandsorientierte Arbeitslasten haben, die im Status Pending mit Fehlermeldungen wie ZONE_RESOURCE_POOL_EXHAUSTED oder GCE_STOCKOUT hängen bleiben, hat eine bestimmte Zone möglicherweise nur begrenzte Rechenkapazität.

Wenn ein Compute-Knoten in einer Zone mit unzureichender Kapazität offline geht, kann das Ersetzen dieses Knotens fehlschlagen. Zustandsorientierte Pods, die auf vorhandenen zonalen PersistentVolumes (z. B. einem Standard-pd-ssd- oder pd-balanced-Laufwerk) basieren, sind auf die Zone beschränkt, in der dieses Volume erstellt wurde. Da der Pod in dieser bestimmten Zone geplant werden muss, um das Volume bereitzustellen, bleibt der Pod Pending, bis Rechenkapazität in dieser Zone verfügbar ist.

Beachten Sie Folgendes, um dieses Problem bei zukünftigen zustandsorientierten Arbeitslasten zu vermeiden:

  • Vermeiden Sie Fallbacks in derselben Zone zwischen pd-ssd und pd-balanced: Da pd-ssd- und pd-balanced-Volumes dieselben Kapazitätslimits und Verfügbarkeitspools in einer Zone haben, wird das Problem der fehlenden Kapazität nicht behoben, wenn Sie Ihre StorageClass in der gleichen Zone von pd-ssd zu pd-balanced ändern. Versuchen Sie dies nicht als Fallback.
  • Hyperdisk-kompatible Formen verwenden: Einige Maschinenserien unterstützen Hyperdisks. Ziehen Sie die Verwendung einer Hyperdisk-kompatiblen Form in Betracht, da diese möglicherweise andere Verfügbarkeitseinschränkungen hat, die hilfreich sind, wenn eine Zone nicht über genügend Kapazität verfügt. Prüfen Sie vor der Migration von Arbeitslasten, ob Sie genügend Laufwerkskontingente haben.
  • Dynamische Topologiebindung (WaitForFirstConsumer) aktivieren: Wenn Sie neue zustandsorientierte Arbeitslasten erstellen, konfigurieren Sie Ihre StorageClass-Definition mit dem Feldwertpaar volumeBindingMode: WaitForFirstConsumer. Mit dieser Einstellung wird die Erstellung des Volumes verzögert, bis ein Pod auf einem fehlerfreien Knoten in einer Zone mit ausreichender Rechenkapazität geplant ist. Dadurch wird verhindert, dass der Pod durch eine vorzeitige Volume-Erstellung in einer Offline- oder ausgelasteten Zone gesperrt wird.
  • Automatische Auswahl des Laufwerkstyps für VM-Fallbacks konfigurieren: In GKE-Version 1.35.3-gke.1290000 und höher können Sie benutzerdefinierte ComputeClasses für Arbeitslasten konfigurieren, die über VM-Generationen hinweg Fallbacks ausführen (z. B. N4 zu N2 oder C4 zu C2). Mit der automatischen Auswahl des Laufwerkstyps können Sie eine StorageClass-Definition mit den Feld-Wert-Paaren parameters.type: dynamic und use-allowed-disk-topology: "true" konfigurieren. Mit dieser Konfiguration kann GKE automatisch hyperdisk-balanced-Laufwerke auf neueren Maschinengenerationen bereitstellen und auf älteren Generationen auf pd-balanced-Laufwerke zurückgreifen.

Nächste Schritte