Fehlerbehebung bei Speicher in GKE

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

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.
  • 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.

Korrigieren

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.

Nächste Schritte

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