Auf dieser Seite sind bekannte Probleme mit dem GKE-Netzwerk aufgeführt. Diese Seite richtet sich an Administratoren und Architekten, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten und auf Benachrichtigungen und Seiten reagieren, wenn Service Level Objectives (SLOs) nicht erfüllt werden oder Anwendungen ausfallen.
Zum Filtern der bekannten Probleme nach einer Produktversion wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.
Wählen Sie Ihre GKE-Version aus:
Oder suchen Sie nach Ihrem Problem:
| Identifizierte Version(en) | Korrigierte Version(en) | Problem und Problemumgehung |
|---|---|---|
| 1,36 | Fehlerbehebung läuft |
Verbindungsfehler und System-Pods in einer Absturzschleife auf Windows-Knoten, die Layer-4-Load-Balancer verwendenBei GKE-Clustern mit Windows Server-Knotenpools, auf denen Version 1.36 ausgeführt wird, kann Folgendes auftreten:
Dieses Problem tritt auf, wenn Cluster interne Layer-4-Load-Balancer ohne GKE-Teileinstellung oder externe Passthrough-Network Load Balancer mit älteren Zielpools oder Instanzgruppen verwenden. In GKE 1.36 aktiviert der Compute Engine-Gast-Agent standardmäßig Workaround: Versuchen Sie Folgendes, um dieses Problem zu beheben:
|
| InferencePool-Helm-Diagramm v1.1.0 |
InferencePool-Flag „targetPortNumber“ ignoriertIn Version Workaround: Prüfen Sie den Port nach der Installation: kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \ --context=CLUSTER_CONTEXT Wenn der Port falsch ist, patchen Sie die benutzerdefinierte Ressource kubectl patch inferencepool POOL_NAME --type=merge \ -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \ --context=CLUSTER_CONTEXT |
|
| 1.33, 1.34, 1.35 |
|
Zeitweise Pod-Verbindungs- oder DNS-Fehler aufgrund des Löschens von
|
| 1.29, 1.30, 1.31, 1.32, 1.33 | 1,34 |
Der
|
| 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
Pod-IP-Adressenleck auf Knoten mit GKE Dataplane V2Bei Clustern mit aktiviertem GKE Dataplane V2 kann es zu einer Erschöpfung der Pod-IP-Adressen auf Knoten kommen. Dieses Problem wird durch einen Fehler in der Containerlaufzeit verursacht, der dazu führen kann, dass zugewiesene IP-Adressen offengelegt werden, wenn Pods während der Erstellung vorübergehende CNI-Fehler aufweisen. Das Problem wird ausgelöst, wenn der GKE-Clusterknoten auf eine der folgenden GKE-Versionen aktualisiert oder mit einer dieser Versionen erstellt wird:
Wenn dieses Problem auftritt, können neue Pods, die auf dem betroffenen Knoten geplant sind, nicht gestartet werden und geben eine Fehlermeldung wie die folgende zurück: Workaround: Sie können dieses Problem beheben, indem Sie das DaemonSet zur Aussetzung von Maßnahmen auf den Cluster anwenden, um die gehackten IP-Ressourcen zu bereinigen: apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 seccompProfile: type: RuntimeDefault automountServiceAccountToken: false containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerd |
|
| 1.31, 1.32, 1.33 |
|
Ausfälle von Ingress- und Service-Load-Balancern in Clustern mit einem Legacy-NetzwerkEine Inkompatibilität mit Legacy-Netzwerken führt dazu, dass die Backends eines von GKE verwalteten Load Balancers, der mit Ingress oder Service bereitgestellt wird, getrennt werden. Dies führt dazu, dass der Load Balancer keine aktiven Backends hat, was wiederum dazu führt, dass alle eingehenden Anfragen an diese Load Balancer verworfen werden. Das Problem betrifft GKE-Cluster, die ein Legacy-Netzwerk verwenden und die Version 1.31 oder höher haben. Führen Sie den folgenden Befehl aus, um GKE-Cluster mit einem Legacy-Netzwerk zu identifizieren:
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"
Bei einem Cluster mit einem Legacy-Netzwerk wird für diesen Befehl eine leere Ausgabe zurückgegeben. Workaround: Da Legacy-Netzwerke schon seit einiger Zeit eingestellt sind, ist die bevorzugte Lösung, Ihr Legacy-Netzwerk zu einem VPC-Netzwerk zu migrieren. Dazu können Sie ein Legacy-Netzwerk, das GKE-Cluster enthält, umwandeln. Wenn Sie diese Migration derzeit nicht durchführen können, wenden Sie sich an Cloud Customer Care. |
| 1.30, 1.31, 1.32 |
|
Neu erstellte Knoten werden den internen Layer-4-Load-Balancern nicht hinzugefügt.Google Cloud Load Balancer, die für interne LoadBalancer-Dienste erstellt werden, können neu erstellte Knoten in der Backend-Instanzgruppe verpassen. Das Problem ist am deutlichsten bei einem Cluster zu sehen, der auf null Knoten und dann wieder auf einen oder mehrere Knoten skaliert wurde. Behelfslösungen:
|
| 1.31,1.32 |
|
Gateway API-Probleme aufgrund von „storedVersions“, die aus dem CRD-Status entfernt wurden
Der Kube-Addon-Manager in GKE entfernt fälschlicherweise die Ihr Cluster ist möglicherweise gefährdet, wenn alle folgenden Bedingungen erfüllt sind:
Workaround: Als Problemumgehung wird empfohlen, Clusterupgrades zu verschieben, bis das Problem behoben ist.
Wenn Sie die Clusterversion aktualisieren müssen, müssen Sie alternativ die Speicherversion für alle betroffenen Gateway API-CRDs auf
|
| 1,32 |
|
Neue Pods können nicht initialisiert werden und bleiben im Status „ContainerCreating“ hängen
Neue Pods können nicht erstellt werden und bleiben im Status Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded Das Problem betrifft GKE-Cluster mit Versionen zwischen 1.32 und vor 1.32.3-gke.1170000, die mit den GKE-Versionen 1.31 oder 1.32 erstellt wurden. Die Ursache ist, dass eine speicherinterne Datenstruktur, die eine Sammlung zugewiesener Cilium-Identitäten verwaltet, nicht korrekt mit dem Status des Kubernetes API-Servers synchronisiert wurde.
Mit dem folgenden Befehl können Sie die Ressource gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
Wenn für den GKE-Cluster Logging aktiviert ist, protokolliert der Container resource.type="k8s_container" resource.labels.container_name="cilium-agent" Workaround: Eine vorübergehende Abhilfe besteht darin, die Steuerungsebene neu zu starten. Dazu können Sie die Steuerungsebene auf die Version aktualisieren, die bereits ausgeführt wird: gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 1.27,1.28,1.29,1.30,1.31 |
NEG-Controller verwaltet keine Endpunkte mehr, wenn der Port aus dem Dienst entfernt wirdWenn der NEG-Controller so konfiguriert ist, dass er eine eigenständige NEG für einen Dienst erstellt, und einer der konfigurierten Ports später aus dem Dienst entfernt wird, verwaltet der NEG-Controller irgendwann keine Endpunkte mehr für die NEG. Zusätzlich zu Diensten, bei denen der Nutzer eine eigenständige NEG-Annotation erstellt, wirkt sich dies auch auf Dienste aus, die von GKE Gateway, MCI und GKE Multi-Cluster-Gateway referenziert werden. Workaround: Wenn Sie einen Port aus einem Dienst mit einer Annotation für eine eigenständige NEG entfernen, muss die Annotation ebenfalls aktualisiert werden, um den betreffenden Port zu entfernen. |
|
| 1,28 |
Gateway-TLS-KonfigurationsfehlerWir haben ein Problem mit der Konfiguration von TLS für Gateways in Clustern mit der GKE-Version 1.28.4-gke.1083000 festgestellt. Dies betrifft TLS-Konfigurationen, die entweder ein SSLCertificate oder eine CertificateMap verwenden. Wenn Sie ein Upgrade für einen Cluster mit vorhandenen Gateways ausführen, schlagen Aktualisierungen am Gateway fehl. Für neue Gateways werden die Load Balancer nicht bereitgestellt. Dieses Problem wird in einer zukünftigen GKE 1.28-Patchversion behoben. |
|
| 1.27,1.28,1.29 |
|
Zeitweise Fehler beim VerbindungsaufbauBei Clustern mit Steuerungsebenenversionen ab 1.26.6-gke.1900 können gelegentlich Fehler beim Verbindungsaufbau auftreten. Die Wahrscheinlichkeit von Fehlern ist gering und es sind nicht alle Cluster betroffen. Die Fehler sollten nach einigen Tagen nach Auftreten der Symptome vollständig aufhören. |
| 1.27,1.28,1.29 |
|
Probleme mit der DNS-Auflösung bei Container-Optimized OSBei Arbeitslasten, die auf GKE-Clustern mit Container-Optimized OS-basierten Knoten ausgeführt werden, können Probleme mit der DNS-Auflösung auftreten. |
| 1,28 | 1.28.3-gke.1090000 oder höher |
Netzwerkrichtlinie bricht eine Verbindung aufgrund einer falschen Verbindungsverfolgung abWenn ein Client-Pod in Clustern mit aktivierter GKE Dataplane V2 über einen Dienst oder die virtuelle IP-Adresse eines internen Passthrough-Network Load Balancers eine Verbindung zu sich selbst herstellt, wird das Antwortpaket aufgrund eines falschen Conntrack-Lookups in der Datenebene nicht als Teil einer vorhandenen Verbindung identifiziert. Das bedeutet, dass eine Netzwerkrichtlinie, die eingehenden Traffic für den Pod einschränkt, für das Paket falsch erzwungen wird. Die Auswirkungen dieses Problems hängen von der Anzahl der konfigurierten Pods für den Dienst ab. Wenn der Service beispielsweise einen Backend-Pod hat, schlägt die Verbindung immer fehl. Wenn der Service zwei Backend-Pods hat, schlägt die Verbindung in 50 % der Fälle fehl. Workaround:
Sie können dieses Problem mindern, indem Sie |
| 1.27,1.28 |
|
Paketdrops für Hairpin-AnschlussflowsWenn ein Pod in Clustern mit aktiviertem GKE Dataplane V2 mithilfe eines Service eine TCP-Verbindung zu sich selbst erstellt, sodass der Pod sowohl Quelle als auch Ziel der Verbindung ist, überwacht die GKE Dataplane V2 eBPF-Verbindungsüberwachung den Verbindungsstatus nicht korrekt, was zu verlorenen conntrack-Einträgen führt. Wenn ein Verbindungstupel (Protokoll, Quell-/Ziel-IP und Quell-/Zielport) geleakt wurde, können neue Verbindungen, die dasselbe Verbindungstupel verwenden, dazu führen, dass Rückgabepakete verworfen werden. Workaround: Versuchen Sie einen der folgenden Schritte, um das Problem zu umgehen:
|
| Älter als 1.31.0-gke.1506000 | 1.31.0-gke.1506000 und höher |
Gerätetypnetzwerk in GKE-Multi-Netzwerk schlägt bei langen Netzwerknamen fehlDie Clustererstellung schlägt mit dem folgenden Fehler fehl:
Workaround: Beschränken Sie die Länge von gerätetypisierten Netzwerkobjektnamen auf maximal 41 Zeichen. Der vollständige Pfad jedes UNIX-Domain-Sockets wird zusammengesetzt, einschließlich des entsprechenden Netzwerknamens. Linux hat eine Einschränkung für die Länge von Socket-Pfaden (unter 107 Byte). Nach Berücksichtigung des Verzeichnisses, des Dateinamenspräfixes und der Erweiterung |
| 1.27, 1.28, 1.29, 1.30 |
|
Verbindungsprobleme für
|
| 1.31, 1.32 |
|
Fehlerhafter UDP-Traffic zwischen Pods, die auf demselben Knoten ausgeführt werdenBei Clustern mit aktivierter knoteninterner Sichtbarkeit kann es zu fehlerhaftem UDP-Traffic zwischen Pods kommen, die auf demselben Knoten ausgeführt werden. Das Problem wird ausgelöst, wenn der GKE-Clusterknoten auf eine der folgenden GKE-Versionen aktualisiert oder mit einer dieser Versionen erstellt wird:
Der betroffene Pfad ist der Pod-zu-Pod-UDP-Traffic auf demselben Knoten über Hostport oder Dienst. Lösung Aktualisieren Sie den Cluster auf eine der folgenden korrigierten Versionen:
|
| 1.28, 1.29, 1.30, 1.31 |
Calico-Pods sind auf Clustern mit weniger als 3 Knoten und unzureichender vCPU nicht fehlerfreiCalico-typha- und Calico-node-Pods können nicht auf Clustern geplant werden, die alle folgenden Bedingungen erfüllen: insgesamt weniger als 3 Knoten, jeder Knoten hat maximal 1 zuweisbare vCPU und die Netzwerkrichtlinie ist aktiviert. Dies liegt an unzureichenden CPU-Ressourcen. Behelfslösungen:
|
|
Ausfälle von Multi-Cluster-Gateways (MCG) in zonalen Clustern während Upgrades der SteuerungsebeneBei Bereitstellungen mit Multi-Cluster-Gateway (MCG) in zonalen GKE-Clustern kann es bei Ereignissen, die einen Neustart der Steuerungsebene verursachen, z. B. bei einem Clusterupgrade, zu Ausfällen mit „503“-Fehlern kommen. Das liegt daran, dass MCG einen Legacy-Mechanismus für die Erkennung von Netzwerk-Endpunktgruppen (NEGs) verwendet, der fälschlicherweise null Back-Ends meldet, wenn Knoten in einem zonalen Cluster während des Neustarts der Steuerungsebene vorübergehend nicht verfügbar sind. Dadurch werden alle Back-Ends vom Load Balancer entfernt, was zu Trafficverlusten führt. Behelfslösungen:
|
||
Race-Bedingung für NEG-BereitschaftsgateUnter bestimmten Bedingungen können die Bereitschaftsgates einen „falsch positiven“ Bereitschaftsstatus zurückgeben, bevor die Ingress-Systemdiagnose einen fehlerfreien Status meldet. Dadurch werden Fehlerereignisse wie die folgenden für das Ingress-Objekt generiert:
Dieses Problem führt dazu, dass der Load Balancer einen Eine relativ kleine Anzahl von Pods (z. B. 2) im Vergleich zur Anzahl der NEGs erhöht das Risiko dieser Race-Bedingung. NEGs werden für jede Region erstellt, wobei eine NEG pro Zone erstellt wird. Dies führt in der Regel zu drei NEGs. Wenn es eine relativ große Anzahl von Pods gibt, sodass jede NEG vor dem Start des Rolling Updates immer mehrere Pods hat, ist es sehr unwahrscheinlich, dass diese Race-Bedingung ausgelöst wird. Workaround: Die beste Möglichkeit, diese Race-Bedingung zu verhindern, besteht darin, mehr Back-Ends in der Netzwerk-Endpunktgruppe zu haben. Achten Sie darauf, dass die Strategie für das rollierende Update so konfiguriert ist, dass immer mindestens ein Pod ausgeführt wird. Wenn beispielsweise nur zwei Pods normal ausgeführt werden, könnte eine Beispielkonfiguration so aussehen: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 Das vorherige Beispiel ist ein Vorschlag. Sie müssen die Strategie anhand mehrerer Faktoren aktualisieren, z. B. der Anzahl der Replikate. |
||
Unvollständige Speicherbereinigung von containernativen Load BalancernDie GKE führt alle zwei Minuten eine automatische Speicherbereinigung für containernative Load Balancer durch. Wenn ein Cluster gelöscht wird, bevor die Load Balancer vollständig entfernt wurden, müssen Sie die NEGs des Load Balancers manuell löschen. Workaround: Führen Sie folgenden Befehl aus, um die NEGs in Ihrem Projekt aufzulisten: gcloud compute network-endpoint-groups list Suchen Sie in der Befehlsausgabe nach den relevanten NEGs. Führen Sie zum Löschen einer NEG folgenden Befehl aus und ersetzen Sie dabei gcloud compute network-endpoint-groups delete <var>NEG_NAME</var> |
||
Arbeitslast-Rollouts auf Endpunktweitergabe abstimmenDieses Problem tritt nicht bei Clustern auf, die Arbeitslast-Einführungen über Pod-Readiness-Feedback verwalten. Wenn Sie eine Arbeitslast in Ihrem Cluster bereitstellen oder eine vorhandene Arbeitslast aktualisieren, kann es länger dauern, bis der container-native Load Balancer neue Endpunkte weitergibt, als es dauert, bis das Rollout der Arbeitslast abgeschlossen ist. Workaround: Für Ihre Arbeitslasten sollten Sie die Werte von
|
||
initialDelaySeconds in Pod readinessProbe nicht berücksichtigtMan könnte erwarten, dass die Konfigurationseinstellung |