Fehlerbehebung bei Speicher in GKE

Auf dieser Seite wird beschrieben, wie Sie speicherbezogene Probleme in Ihren GKE-Clustern (Google Kubernetes Engine) beheben können.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

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.
  • Laufwerksgestützte emptyDir-Volumes, es sei denn, der Knoten verwendet eine lokale SSD.

Die Laufwerksleistung wird für alle Laufwerke desselben Laufwerkstyps 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 das PersistentVolume viele Aktivitäten beinhaltet, wirkt sich dies außerdem auf die Leistung des Bootlaufwerks aus.

Wenn auf Ihren Knoten Nachrichten wie die folgenden angezeigt werden, kann dies ein Symptom für eine geringe Laufwerkleistung 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 Folgendes, um solche Probleme zu beheben:

  • Lesen Sie die Vergleiche für 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. Ziehen Sie in Betracht, 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. Dies 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 PersistentVolume jedoch eine große Anzahl von Dateien hat, versucht kubelet, die Eigentümerschaft für jede Datei im Dateisystem zu ändern. Dies kann die Latenz der Volume-Bereitstellung 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 fsGroup-Einstellung 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 das PersistentVolume nicht innerhalb weniger Minuten bereitgestellt wird, führen Sie die folgenden Schritte aus, um das 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

Die folgenden Beispielfehler werden möglicherweise in den k8s_node container-runtime-Logs angezeigt:

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 oder höher behoben. 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+, 1.23.3-gke.1700+ und 1.23.4-gke.100+

Ä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 kann 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

Der folgende Fehler kann auftreten, wenn Sie einen Cluster oder einen Knotenpool erstellen, der eine lokale SSD verwendet:

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, welchen Wert Sie angegeben haben.

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

Geben Sie zur Behebung dieses Problems eine Anzahl lokaler SSD-Laufwerke an, die dem gewünschten Maschinentyp entsprechen. Für Maschinenserien der dritten Generation müssen Sie das Flag count für die lokale SSD weglassen. Der richtige Wert wird automatisch konfiguriert.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.