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 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:
- Reduzieren Sie die Anzahl der Dateien im Volume.
- Einstellung
[fsGroup]
nicht mehr verwenden - Ändern Sie die Anwendung
fsGroupChangePolicy
inOnRootMismatch
.
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
- Wenn Pods fehlschlagen, sollten Sie
restartPolicy:Always
oderrestartPolicy:OnFailure
in Ihrer PodSpec verwenden. - 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:
- Behalten Sie das geänderte PersistentVolume-Objekt unverändert bei.
- 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. - 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:
- Wählen Sie eine neue Zone in derselben Region mit genügend Kapazität für den ausgewählten Maschinentyp aus, in der Hyperdisk Balanced Storage Pools verfügbar sind.
- Löschen Sie den vorhandenen Speicherpool und erstellen Sie ihn in der neuen Zone neu. Das liegt daran, dass Speicherpools zonale Ressourcen sind.
- Erstellen Sie Ihren Cluster oder Knotenpool in der neuen Zone.
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:
- Sie können eine Supportanfrage erstellen, indem Sie sich an den Cloud Customer Care wenden.
- Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem Tag
google-kubernetes-engine
nach ähnlichen Problemen suchen. Sie können auch dem#kubernetes-engine
-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten. - Sie können Fehler melden oder Funktionsanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.