Auf dieser Seite werden bekannte Probleme mit der GKE-Netzwerkfunktion 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:
| Ermittelte Version(en) | Korrigierte Version(en) | Problem und Problemumgehung |
|---|---|---|
| 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
Leck von Pod-IP-Adressen auf Knoten mit GKE Dataplane V2Bei Clustern mit aktivierter GKE Dataplane V2 kann es auf Knoten zu einer Erschöpfung der Pod-IP-Adressen kommen. Dieses Problem wird durch einen Container-Laufzeitfehler verursacht, durch den zugewiesene IP-Adressen verloren gehen können, wenn bei der Erstellung von Pods vorübergehende CNI-Fehler auftreten. Das Problem tritt auf, 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. Es wird eine Fehlermeldung ähnlich der folgenden zurückgegeben: Workaround: Um dieses Problem zu beheben, können Sie das DaemonSet zur Problembehebung 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 GKE-verwalteten Load Balancers, der mit Ingress oder Service bereitgestellt wird, getrennt werden. Dadurch hat der Load-Balancer keine aktiven Back-Ends mehr, 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 ist die Ausgabe für diesen Befehl leer. Workaround: Da Legacy-Netzwerke schon seit einiger Zeit eingestellt wurden, ist die bevorzugte Lösung, Ihr Legacy-Netzwerk zu einem VPC-Netzwerk zu migrieren. Dazu können Sie ein Legacy-Netzwerk umwandeln, das GKE-Cluster enthält. Wenn Sie diese Migration derzeit nicht durchführen können, wenden Sie sich an den Cloud Customer Care. |
| 1.30, 1.31, 1.32 |
|
Neu erstellte Knoten werden nicht den internen Layer 4-Load-Balancern hinzugefügt.Bei Google Cloud -Load-Balancern, die für interne LoadBalancer-Dienste erstellt werden, fehlen möglicherweise neu erstellte Knoten in der Backend-Instanzgruppe. Das Problem ist am deutlichsten in einem Cluster zu sehen, der auf null Knoten skaliert und dann wieder auf einen oder mehrere Knoten skaliert wurde. Problemumgehungen:
|
| 1.31,1.32 |
|
Probleme mit der Gateway API 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: Der empfohlene Workaround besteht darin, Clusterupgrades zu verzögern, 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 verbleiben 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 in Versionen zwischen 1.32 und vor 1.32.3-gke.1170000, die in GKE-Versionen 1.31 oder 1.32 erstellt wurden. Die Ursache ist, dass eine In-Memory-Datenstruktur, in der eine Sammlung zugewiesener Cilium-Identitäten verwaltet wurde, nicht richtig mit dem Status des Kubernetes API-Servers synchronisiert wurde.
Mit dem folgenden Befehl können Sie die gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
Wenn im GKE-Cluster Logging aktiviert ist, protokolliert der resource.type="k8s_container" resource.labels.container_name="cilium-agent" Workaround: Eine vorübergehende Abhilfe besteht darin, die Steuerungsebene neu zu starten. Dies kann erreicht werden, indem Sie die Steuerungsebene auf dieselbe 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 Endpunkte nicht mehr, wenn Port aus 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 schließlich keine Endpunkte mehr für die NEG. Neben Diensten, für die der Nutzer eine eigenständige NEG-Annotation erstellt, betrifft dies auch Dienste, auf die von GKE Gateway, MCI und GKE Multi-Cluster-Gateway verwiesen wird. Workaround: Wenn Sie einen Port aus einem Dienst mit einer eigenständigen NEG-Annotation entfernen, muss die Annotation auch aktualisiert werden, um den betreffenden Port zu entfernen. |
|
| 1,28 |
Gateway-TLS-KonfigurationsfehlerWir haben ein Problem bei der Konfiguration von TLS für Gateways in Clustern mit GKE-Version 1.28.4-gke.1083000 festgestellt. Dies betrifft TLS-Konfigurationen mit einem SSLCertificate oder einer CertificateMap. Wenn Sie einen Cluster mit vorhandenen Gateways aktualisieren, schlagen Aktualisierungen des Gateways fehl. Bei neuen 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 fehlgeschlagene VerbindungsaufbautenBei Clustern mit Steuerungsebenenversionen ab 1.26.6-gke.1900 kann es zu zeitweiligen Fehlern beim Herstellen von Verbindungen kommen. Die Wahrscheinlichkeit von Fehlern ist gering und sie betreffen nicht alle Cluster. Die Ausfälle sollten nach einigen Tagen nach dem 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, kann es zu Problemen bei der DNS-Auflösung kommen. |
| 1,28 | 1.28.3-gke.1090000 oder höher |
Netzwerkrichtlinie bricht eine Verbindung aufgrund einer falschen Verbindungsverfolgung abWenn in Clustern mit aktivierter GKE Dataplane V2 ein Client-Pod über einen Dienst oder die virtuelle IP-Adresse eines internen Passthrough-Network Load Balancer 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 Dienst beispielsweise einen Backend-Pod hat, schlägt die Verbindung immer fehl. Wenn der Dienst 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 in Clustern mit aktiviertem GKE Dataplane V2 ein Pod 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) offengelegt wurde, kann es bei neuen Verbindungen mit demselben Verbindungstupel dazu kommen, 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ätetypisiertes Netzwerk 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 Namen von Netzwerkobjekten mit Gerätetyp auf maximal 41 Zeichen. Der vollständige Pfad jedes UNIX-Domain-Sockets wird zusammengesetzt, einschließlich des entsprechenden Netzwerknamens. Unter Linux gilt eine Beschränkung für die Länge von Socket-Pfaden (unter 107 Byte). Nach Berücksichtigung des Verzeichnisses, des Dateinamenprä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, für die die knoteninterne Sichtbarkeit aktiviert ist, kann es zu Problemen mit dem UDP-Traffic zwischen Pods kommen, die auf demselben Knoten ausgeführt werden. Das Problem tritt auf, wenn der GKE-Clusterknoten auf eine der folgenden GKE-Versionen aktualisiert oder mit einer dieser Versionen erstellt wird:
Der betroffene Pfad ist 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 in Clustern mit weniger als 3 Knoten und unzureichender vCPU nicht fehlerfreiDie Pods „calico-typha“ und „calico-node“ können nicht in Clustern geplant werden, die alle folgenden Bedingungen erfüllen: weniger als 3 Knoten insgesamt, jeder Knoten mit maximal 1 zuweisbaren vCPU und Netzwerkrichtlinie aktiviert aktiviert. Das liegt an unzureichenden CPU-Ressourcen. Problemumgehungen:
|
|
MCG-Ausfälle (Multi-Cluster Gateway) in zonalen Clustern während Upgrades der SteuerungsebeneBei Bereitstellungen mit Multi-Cluster Gateway (MCG) in zonalen GKE-Clustern kann es während Ereignissen, die einen Neustart der Steuerungsebene verursachen, z. B. bei einem Clusterupgrade, zu Ausfällen mit `503`-Fehlern kommen. Das liegt daran, dass MCG auf einem Legacy-Mechanismus für die Ermittlung von Netzwerk-Endpunktgruppen (NEGs) basiert, 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. Problemumgehungen:
|