Fehlerbehebung bei der Netzwerkisolation in GKE

Falsche Netzwerkisolierung-Konfigurationen in Google Kubernetes Engine (GKE) können Probleme wie Zeitüberschreitungen bei der Clustererstellung, Fehler bei der Knotenregistrierung, Nichterreichbarkeit der Steuerungsebene oder Probleme beim Abrufen von Images verursachen.

In diesem Dokument finden Sie Anleitungen zur Fehlerbehebung bei Problemen wie dem Zugriff auf die Steuerungsebene, Überschneidungen von CIDR-Bereichen, Fehlern beim Abrufen von Images aus öffentlichen Repositories und Problemen im Zusammenhang mit VPC-Netzwerk-Peering oder Private Service Connect.

Diese Informationen sind wichtig für Plattformadministratoren und ‑operatoren sowie Netzwerkadministratoren, die netzwerkisolierte GKE-Cluster konfigurieren und verwalten, um Sicherheits- und Compliance-Anforderungen zu erfüllen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inCloud de Confiance by S3NS Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

GKE-Cluster wird nicht ausgeführt

Ein Cluster funktioniert nicht mehr, wenn die Firewallregeln, die eingehenden Traffic von der Clustersteuerungsebene zu Knoten auf Port 10250 zulassen, gelöscht werden, und wenn die Standardroute zum Standard-Internetgateway gelöscht wird. Wenn Sie die Standardroute löschen, müssen Sie dafür sorgen, dass der Traffic an die erforderlichenCloud de Confiance -Dienste weitergeleitet wird. Weitere Informationen finden Sie unter Benutzerdefiniertes Routing.

Zeitüberschreitung beim Erstellen eines Clusters

Symptome
Für Cluster, die in Version 1.28 oder früher mit privaten Knoten erstellt wurden, ist eine Peering-Route zwischen VPCs erforderlich. Es kann jedoch immer nur ein Peering-Vorgang gleichzeitig ausgeführt werden. Wenn Sie versuchen, mehrere Cluster mit den oben genannten Merkmalen gleichzeitig zu erstellen, kann es zu einer Zeitüberschreitung bei der Clustererstellung kommen.
Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Erstellen Sie Cluster in Version 1.28 oder früher nacheinander, damit die VPC-Peering-Routen für jeden nachfolgenden Cluster ohne externen Endpunkt bereits vorhanden sind. Beim Versuch, einen einzelnen Cluster zu erstellen, kann es zu einer Zeitüberschreitung kommen, wenn Vorgänge in Ihrer VPC ausgeführt werden.

  • Erstellen Sie Cluster in Version 1.29 oder höher.

VPC-Netzwerk-Peering-Verbindung wurde versehentlich gelöscht

Symptome

Wenn Sie versehentlich eine VPC-Netzwerk-Peering-Verbindung löschen, wechselt der Cluster in den Reparaturstatus und alle Knoten zeigen den Status UNKNOWN an. Sie können keine Vorgänge für den Cluster ausführen, da die Erreichbarkeit der Steuerungsebene unterbrochen ist. Wenn Sie die Steuerungsebene prüfen, wird in den Logs ein Fehler wie der folgende angezeigt:

error checking if node NODE_NAME is shutdown: unimplemented
Mögliche Ursachen

Sie haben die VPC-Netzwerk-Peering-Verbindung versehentlich gelöscht.

Lösung

  1. Erstellen Sie einen neuen GKE-Cluster mit einer Version, die vor der PSC-Umstellung und den zugehörigen spezifischen Konfigurationen liegt. Diese Aktion ist erforderlich, um die Neuerstellung der VPC-Peering-Verbindung zu erzwingen. Dadurch wird der alte Cluster wieder in den Normalbetrieb versetzt.
    • Verwenden Sie die folgenden spezifischen Konfigurationen für den neuen Cluster:
      • Release-Version:Extended
      • Clusterversion:Eine Version, die älter als 1.29 ist, z. B. 1.28.15-gke.2403000
      • Master-IPv4-CIDR: ein bestimmter IP-Adressbereich, z. B. --master-ipv4-cidr=172.16.0.192/28
  2. Überwachen Sie den Status des ursprünglichen Clusters.
    • Nachdem der neue Cluster erstellt und das VPC-Peering wiederhergestellt wurde, sollte sich der ursprüngliche Cluster vom Reparaturstatus erholen und seine Knoten sollten wieder den Status Ready haben.
  3. Löschen Sie den temporär erstellten GKE-Cluster.
    • Nachdem der ursprüngliche Cluster vollständig wiederhergestellt wurde und normal funktioniert, können Sie den temporär erstellten GKE-Cluster löschen.

Private Service Connect-Endpunkt und Weiterleitungsregel werden versehentlich gelöscht

Symptome

Wenn Sie versehentlich einen Private Service Connect-Endpunkt oder eine Weiterleitungsregel löschen, wechselt der Cluster in den Reparaturstatus und alle Knoten zeigen den Status UNKNOWN an. Sie können keine Vorgänge für den Cluster ausführen, da der Zugriff auf die Steuerungsebene unterbrochen ist. Wenn Sie die Steuerungsebene prüfen, wird in den Logs ein Fehler wie der folgende angezeigt:

error checking if node NODE_NAME is shutdown: unimplemented
Mögliche Ursachen

Sie haben den Private Service Connect-Endpunkt oder die Weiterleitungsregel versehentlich gelöscht. Beide Ressourcen heißen gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe und ermöglichen die private Verbindung der Steuerungsebene und der Knoten.

Lösung

IP-Adresse der Steuerungsebene rotieren.

Cluster überschneidet sich mit aktivem Peer

Symptome

Wenn Sie versuchen, einen Cluster ohne externen Endpunkt zu erstellen, wird ein Fehler ähnlich dem folgenden zurückgegeben:

Google Compute Engine: An IP range in the peer network overlaps with an IP
range in an active peer of the local network.
Mögliche Ursachen

Sie haben ein überlappendes CIDR der Steuerungsebene ausgewählt.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Löschen Sie den Cluster und erstellen Sie ihn noch einmal mit einem anderen CIDR der Steuerungsebene.
  • Erstellen Sie den Cluster in Version 1.29 neu und fügen Sie das Flag --enable-private-nodes ein.

Steuerungsebene eines Clusters ohne externen Endpunkt kann nicht erreicht werden

Erhöhen Sie die Wahrscheinlichkeit, dass Ihre Cluster-Steuerungsebene erreichbar ist. Implementieren Sie dazu eine der Konfigurationen für den Zugang zu den Clusterendpunkten. Weitere Informationen finden Sie unter Zugriff auf Clusterendpunkte.

Symptome

Nachdem Sie einen Cluster ohne externen Endpunkt erstellt haben, wird beim Versuch, kubectl-Befehle für den Cluster auszuführen, ein Fehler ähnlich dem folgenden zurückgegeben:

Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection
timed out.

Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Mögliche Ursachen

kubectl kann nicht mit der Cluster-Steuerungsebene kommunizieren.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Aktivieren Sie den DNS-Zugriff, um auf einfache Weise sicher auf Ihren Cluster zuzugreifen. Weitere Informationen finden Sie unter DNS-basierter Endpunkt.

  • Prüfen Sie, ob die Anmeldedaten für den Cluster für kubeconfig generiert wurden oder der richtige Kontext aktiviert ist. Weitere Informationen zum Festlegen der Clusteranmeldedaten finden Sie unter kubeconfig-Eintrag generieren.

  • Prüfen Sie, ob der Zugriff auf die Steuerungsebene über den IP-basierten externen Endpunkt zulässig ist. Wenn Sie den externen Zugriff auf die Cluster-Steuerungsebene deaktivieren, wird der Cluster vom Internet isoliert. Bei dieser Konfiguration haben nur autorisierte interne CIDR-Bereiche oder reservierte Netzwerke Zugriff auf die Steuerungsebene.

    1. Prüfen Sie, ob die ursprüngliche IP-Adresse berechtigt ist, die Steuerungsebene zu erreichen:

        gcloud container clusters describe CLUSTER_NAME \
      --format="value(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetworksConfig)"\
      --location=COMPUTE_LOCATION

      Ersetzen Sie Folgendes:

      Wenn die ursprüngliche IP-Adresse nicht autorisiert ist, kann die Ausgabe ein leeres Ergebnis (nur geschweifte Klammern) oder CIDR-Bereiche zurückgeben, die nicht die ursprüngliche IP-Adresse enthalten.

      cidrBlocks:
  cidrBlock: 10.XXX.X.XX/32
  displayName: jumphost
  cidrBlock: 35.XXX.XXX.XX/32
  displayName: cloud shell
enabled: true

    2. Fügen Sie autorisierte Netzwerke für den Zugriff auf die Steuerungsebene hinzu.

  • Wenn Sie den Befehl kubectl in einer lokalen Umgebung oder in einer anderen Region als der Standort des Clusters ausführen, muss der private Endpunkt der Steuerungsebene für den globalen Zugriff aktiviert sein. Weitere Informationen finden Sie unter Zugriff über die interne IP-Adresse der Steuerungsebene von beliebiger Region aus.

    1. Beschreiben Sie den Cluster, um die Antwort der Zugriffskontrollkonfiguration zu sehen:

      gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"

      Ersetzen Sie Folgendes:

      Eine erfolgreiche Ausgabe sieht etwa so aus:

        enabled: true

    2. Wenn null zurückgegeben wird, aktivieren Sie den Zugriff über die interne IP-Adresse der Steuerungsebene von einer beliebigen Region aus.

Cluster kann aufgrund von überschneidendem IPv4-CIDR-Block nicht erstellt werden

Symptome

gcloud container clusters create gibt einen Fehler ähnlich wie diesen zurück:

The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network
10.128.0.0/20.
Mögliche Ursachen

Sie haben einen CIDR-Block der Steuerungsebene angegeben, der sich mit einem vorhandenen Subnetz in Ihrer VPC überschneidet.

Lösung

Geben Sie einen CIDR-Block für --master-ipv4-cidr an, der sich nicht mit einem vorhandenen Subnetz überschneidet.

Cluster kann aufgrund von Dienstbereich, der bereits von einem anderen Cluster verwendet wird, nicht erstellt werden

Symptome

Beim Versuch, einen Cluster zu erstellen, wird ein Fehler wie der folgende zurückgegeben:

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
Mögliche Ursachen

Die folgenden Konfigurationen können diesen Fehler verursachen:

  • Sie haben einen Dienstbereich ausgewählt, der noch von einem anderen Cluster verwendet wird, oder der Cluster wurde nicht gelöscht.
  • Es wurde ein Cluster mit diesem Dienstbereich verwendet, der gelöscht wurde, aber die Metadaten der sekundären Bereiche wurden nicht ordnungsgemäß bereinigt. Sekundäre Bereiche für einen GKE-Cluster werden in den Compute Engine-Metadaten gespeichert und sollten entfernt werden, sobald der Cluster gelöscht wurde. Selbst wenn der Cluster erfolgreich gelöscht wurde, wurden die Metadaten möglicherweise nicht entfernt.
Lösung

Gehen Sie so vor:

  1. Prüfen, ob der Dienstbereich von einem vorhandenen Cluster verwendet wird Sie können den Befehl gcloud container clusters list mit dem Flag filter verwenden, um nach dem Cluster zu suchen. Wenn ein Cluster den Dienstbereich verwendet, müssen Sie diesen Cluster löschen oder einen neuen Dienstbereich erstellen.
  2. Wenn der Dienstbereich nicht von einem vorhandenen Cluster verwendet wird, entfernen Sie den Metadateneintrag manuell, der dem Dienstbereich entspricht, den Sie verwenden möchten.

Subnetz kann nicht erstellt werden

Symptome

Wenn Sie versuchen, einen Cluster mit einem automatischen Subnetz oder ein benutzerdefiniertes Subnetz zu erstellen, können die folgenden Fehler auftreten:

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.

Error: Error waiting for creating GKE cluster: Invalid value for field
PrivateClusterConfig.MasterIpv4CidrBlock: x.x.x.x/28 conflicts with an
existing subnet in one of the peered VPCs.
Mögliche Ursachen

Der von Ihnen angegebene CIDR-Bereich der Steuerungsebene überschneidet sich mit einem anderen IP-Bereich im Cluster. Dieser Fehler bei der Subnetzerstellung kann auch auftreten, wenn Sie versuchen, die master-ipv4-cidr-CIDRs eines kürzlich gelöschten Clusters wiederzuverwenden.

Lösung

Probieren Sie einen anderen CIDR-Bereich aus.

Image kann nicht von öffentlichem Docker Hub heruntergeladen werden

Symptome

Ein Pod, der in Ihrem Cluster ausgeführt wird, zeigt in kubectl describe eine Warnung an:

Failed to pull image: rpc error: code = Unknown desc = Error response
from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
while waiting for connection (Client.Timeout exceeded while awaiting
headers)
Mögliche Ursachen

Knoten mit privaten IP-Adressen erfordern nur eine zusätzliche Konfiguration, um die Anforderungen für den Internetzugriff zu erfüllen. Die Knoten können jedoch auf Cloud de Confiance APIs und -Dienste, einschließlich Artifact Registry, zugreifen, wenn Sie privaten privater Google-Zugriff aktiviert haben und die Netzwerkanforderungen erfüllen.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Kopieren Sie die Images in Ihrem Cluster aus Docker Hub in Artifact Registry. Weitere Informationen finden Sie unter Container aus einer Drittanbieter-Registry migrieren.

  • GKE prüft mirror.gcr.io automatisch auf zwischengespeicherte Kopien von häufig aufgerufenen Docker Hub-Images.

  • Wenn Sie Images aus Docker Hub oder einem anderen öffentlichen Repository abrufen müssen, verwenden Sie Cloud NAT oder einen instanzbasierten Proxy, der das Ziel für eine statische 0.0.0.0/0-Route ist.

Fehler beim Erstellen neuer externer Webhooks

Der folgende Fehler tritt auf, wenn Sie versuchen, ValidatingWebhookConfigurations oder MutatingWebhookConfigurations zu erstellen, die das Feld clientConfig.url verwenden, um einen Webhook-Server außerhalb des Clusters zu kontaktieren:

ValidatingAdmissionPolicy 'gke-restrict-webhook-url' denied request: Egress
traffic from the API server through the control plane is disabled. As a result,
direct API server calls to external webhook servers are blocked. To connect to
external webhooks, update any webhook configurations that use clientConfig.url
to use clientConfig.service instead.

Dieser Fehler tritt auf, wenn Ihre Clusterkonfiguration direkten ausgehenden Traffic vom Kubernetes API-Server verhindert, indem die externen IP-Adressen der VM-Instanzen der Steuerungsebene deaktiviert werden. GKE verwendet eine ValidatingAdmissionPolicy, um das Erstellen oder Aktualisieren von Webhook-Konfigurationen zu verhindern, die das Feld clientConfig.url verwenden.

Beschreiben Sie Ihre Clusterkonfiguration, um die Ursache dieses Fehlers zu ermitteln:

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(controlPlaneEgress)'

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • CONTROL_PLANE_LOCATION: Die Region oder Zone Ihres Clusters, z. B. us-central1 oder us-central1-a.

Wenn ausgehender Traffic vom API-Server deaktiviert ist, lautet die Ausgabe NONE.

Aktualisieren Sie Ihre Webhook-Konfigurationen, um diesen Fehler zu beheben und das Feld clientConfig.service zu verwenden. Mit diesem Feld kann der API-Server Zulassungsanfragen an einen Dienst in Ihrem Cluster senden, anstatt Traffic an eine IP-Adresse oder URL zu senden. Weitere Informationen zum Konfigurieren der Webhooks und des Dienstes finden Sie unter Externe Webhook-Konfiguration.

Wenn Sie die ValidatingAdmissionPolicy löschen, ist die Anfrage zum Erstellen oder Aktualisieren des Webhooks erfolgreich, aber Zulassungsanfragen an den Webhook-Server schlagen fehl.

Fehler bei externen Zulassungs-Webhook-Anfragen

Der folgende Fehler tritt auf, wenn Sie versuchen, Kubernetes-Ressourcen bereitzustellen, die Zulassungs-Webhook-Server außerhalb Ihres Cluster-VPC-Netzwerks auslösen:

Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook WEBHOOK_NAME": failed to call webhook: Post "WEBHOOK_URL": proxyconnect tcp: dial tcp: lookup master-internet-access-unavailable.localhost on 169.254.169.254:53: no such host

Dieser Fehler tritt auf, wenn alle folgenden Bedingungen erfüllt sind:

  • In der Webhook-Konfiguration wird eine IP-Adresse oder URL verwendet, um den externen Webhook-Server zu kontaktieren.
  • Die Clusterkonfiguration verhindert direkten ausgehenden Traffic vom Kubernetes API-Server, indem die externen IP-Adressen der VM-Instanzen der Steuerungsebene deaktiviert werden.

Beschreiben Sie Ihre Clusterkonfiguration, um die Ursache dieses Fehlers zu ermitteln:

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(controlPlaneEgress)'

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • CONTROL_PLANE_LOCATION: Die Region oder Zone Ihres Clusters, z. B. us-central1 oder us-central1-a.

Wenn ausgehender Traffic vom API-Server deaktiviert ist, lautet die Ausgabe NONE.

Führen Sie die folgenden Schritte aus, um diesen Fehler zu beheben:

  1. Identifizieren Sie alle ValidatingWebhookConfigurations oder MutatingWebhookConfigurations im Cluster, die das Feld clientConfig.url verwenden.
  2. Aktualisieren Sie Ihre Webhook-Konfigurationen, um das Feld clientConfig.service zu verwenden. Mit diesem Feld kann der API-Server Zulassungsanfragen an einen Dienst in Ihrem Cluster senden, anstatt Traffic an eine IP-Adresse oder URL zu senden. Weitere Informationen zum Konfigurieren der Webhooks und des Dienstes finden Sie unter Externe Webhook-Konfiguration.

API-Anfrage, bei der Zeitüberschreitung für Zulassungs-Webhook ausgelöst wird

Symptome

Bei einer API-Anfrage, die einen Zulassungs-Webhook auslöst, der für die Verwendung eines Dienstes mit einem anderen targetPort als 443 konfiguriert ist, tritt eine Zeitüberschreitung auf, wodurch die Anfrage fehlschlägt:

Error from server (Timeout): request did not complete within requested timeout 30s
Mögliche Ursachen

Standardmäßig lässt die Firewall keine TCP-Verbindungen zu Knoten zu, mit Ausnahme an den Ports 443 (HTTPS) und 10250 (kubelet). Ein Zulassungs-Webhook, der versucht, mit einem Pod über einen anderen Port als 443 zu kommunizieren, schlägt fehl, wenn keine benutzerdefinierte Firewallregel vorhanden ist, die den Traffic erlaubt.

Lösung

Fügen Sie für Ihren Anwendungsfall eine Firewallregel hinzu.

Cluster kann aufgrund von Fehlern bei der Systemdiagnose nicht erstellt werden

Symptome

Nachdem Sie einen Standardcluster mit privaten Knotenpools erstellt haben, bleibt er beim Systemdiagnoseschritt hängen und meldet einen Fehler, der einem der folgenden ähnelt:

All cluster resources were brought up, but only 0 of 2 have registered.

All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
Mögliche Ursachen

Die folgenden Konfigurationen können diesen Fehler verursachen:

  • Clusterknoten können die erforderlichen Binärdateien nicht über die Cloud Storage API (storage.googleapis.com) herunterladen.
  • Firewallregeln schränken den ausgehenden Traffic ein.
  • IAM-Berechtigungen für die gemeinsam genutzte VPC sind falsch.
  • Für den privaten Google-Zugriff müssen Sie das DNS für *.gcr.io konfigurieren.
Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Aktivieren Sie Privater Google-Zugriff im Subnetz für den Netzwerkzugriff des Knotens auf storage.googleapis.com oder aktivieren Sie Cloud NAT, damit die Knoten mit storage.googleapis.com-Endpunkten kommunizieren können.

  • Bestätigen Sie für den Knoten-Lesezugriff auf storage.googleapis.com, dass das dem Clusterknoten zugewiesene Dienstkonto Speicherlesezugriff hat.

  • Achten Sie darauf, dass Sie entweder eineCloud de Confiance Firewallregel zum Zulassen des gesamten ausgehenden Traffics haben oder eine Firewallregel konfigurieren, um ausgehenden Traffic für Knoten zur Steuerungsebene des Clusters und *.googleapis.com zuzulassen.

  • Erstellen Sie die DNS-Konfiguration für *.gcr.io.

  • Wenn Sie eine nicht standardmäßige Firewall- oder Routeneinrichtung verwenden, konfigurieren Sie den privaten Google-Zugriff.

  • Wenn Sie VPC Service Controls verwenden, richten Sie Container Registry oder Artifact Registry für GKE-Cluster ein.

  • Achten Sie darauf, dass die automatisch erstellten Firewallregeln für eingehenden Traffic nicht gelöscht oder geändert wurden.

  • Wenn Sie freigegebene VPC verwenden, müssen Sie die erforderlichen IAM-Berechtigungen konfigurieren.

Kubelet konnte keine Pod-Sandbox erstellen

Symptome

Nachdem Sie einen Cluster mit privaten Knoten erstellt haben, wird ein Fehler ähnlich dem folgenden gemeldet:

Warning  FailedCreatePodSandBox  12s (x9 over 4m)      kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Mögliche Ursachen

Der Pod calico-node oder netd kann *.gcr.io nicht erreichen.

Lösung

Prüfen Sie, ob Sie die erforderliche Einrichtung für Container Registry oder Artifact Registry abgeschlossen haben.

Private Knoten wurden erstellt, aber nicht dem Cluster hinzugefügt

Bei Clustern mit Knoten, die nur private IP-Adressen verwenden, wird die Standardroute (0.0.0.0/0) häufig zur Appliance anstelle des Standard-Internetgateways umgeleitet. Das ist oft der Fall, wenn benutzerdefiniertes Routing und Netzwerkgeräte von Drittanbietern in der VPC verwendet werden. Zusätzlich zur Verbindung der Steuerungsebene müssen Sie dafür sorgen, dass die folgenden Ziele erreichbar sind:

  • *.googleapis.com
  • *.gcr.io
  • gcr.io

Konfigurieren Sie den privaten Google-Zugriff für alle drei Domains. Diese Best Practice ermöglicht es Ihnen, die neuen Knoten zu starten und dem Cluster beizutreten, während der ausgehende Internettraffic eingeschränkt bleibt.

Arbeitslasten auf GKE-Clustern können nicht auf das Internet zugreifen

Pods, die auf Knoten mit privaten IP-Adressen ausgeführt werden, können nicht auf das Internet zugreifen. Wenn Sie beispielsweise den Befehl apt update aus dem Pod exec shell ausführen, wird ein Fehler ähnlich dem folgenden gemeldet:

0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]

Wenn der sekundäre IP-Adressbereich des Subnetzes, der für Pods im Cluster verwendet wird, nicht auf dem Cloud-NAT-Gateway konfiguriert ist, können die Pods keine Verbindung zum Internet herstellen, da sie keine für das Cloud-NAT-Gateway konfigurierte externe IP-Adresse haben.

Konfigurieren Sie das Cloud NAT-Gateway so, dass es mindestens die folgenden Subnetz-IP-Adressbereiche für das Subnetz anwendet, das Ihr Cluster verwendet:

  • Primärer IP-Adressbereich des Subnetzes (von Knoten verwendet)
  • Sekundärer IP-Adressbereich des Subnetzes, der für Pods im Cluster verwendet wird
  • Sekundärer IP-Adressbereich des Subnetzes, der für Dienste im Cluster verwendet wird

Weitere Informationen finden Sie unter Sekundärer Subnetz-IP-Bereich hinzufügen, der für Pods verwendet wird.

Der direkte IP-Zugriff kann für öffentliche Cluster nicht deaktiviert werden

Symptome

Nachdem Sie den IP-Adressendpunkt deaktiviert haben, wird eine Fehlermeldung ähnlich der folgenden angezeigt:

Direct IP access can't be disabled for public clusters
Mögliche Ursachen

Ihr Cluster verwendet ein Legacy-Netzwerk.

Lösung

Cluster zu Private Service Connect migrieren Weitere Informationen zum Migrationsstatus erhalten Sie vom Support.

Der direkte IP-Zugriff kann für Cluster, die sich in der Mitte der PSC-Migration befinden, nicht deaktiviert werden.

Symptome

Nachdem Sie den IP-Adressendpunkt deaktiviert haben, wird eine Fehlermeldung ähnlich der folgenden angezeigt:

Direct IP access can't be disabled for public clusters
Mögliche Ursachen

Ihr Cluster verwendet ein Legacy-Netzwerk.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Erstellen Sie alle Knotenpools manuell in einer anderen Version neu.
  • Warten Sie, bis GKE die Knotenpools während eines Wartungsereignisses automatisch aktualisiert.

Der interne Endpunkt der Steuerungsebene kann nicht aktiviert werden

Symptome

Wenn Sie versuchen, den internen Endpunkt der Steuerungsebene Ihres Clusters zu aktivieren, werden Fehlermeldungen ähnlich den folgenden angezeigt:

private_endpoint_enforcement_enabled can't be enabled when envoy is disabled

private_endpoint_enforcement_enabled is unsupported. Please upgrade to the minimum support version
Mögliche Ursachen

Für Ihren Cluster ist eine IP-Adressrotation oder ein Versionsupdate erforderlich.

Lösung

Verwenden Sie eine der folgenden Lösungen:

Clustererstellung schlägt fehl, wenn Organisationsrichtlinien definiert sind

Symptome

Wenn Sie versuchen, einen Cluster zu erstellen, wird eine Fehlermeldung wie die folgende angezeigt:

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Mögliche Ursachen

Der Clusterendpunkt oder das Backend wird durch die Organisationsrichtlinie eines Nutzers blockiert.

Lösung

Wenn Sie zulassen möchten, dass Instanzen Endpunkte mit der Einschränkung compute.restrictPrivateServiceConnectProducer erstellen, führen Sie die Schritte unter Organisationsrichtlinien auf Nutzerseite aus.

Der Private Service Connect-Endpunkt wird beim Löschen des Clusters möglicherweise weitergegeben

Symptome

Nach dem Erstellen eines Clusters können folgende Symptome auftreten:

  • In Ihrem Private Service Connect-basierten Cluster wird unter „Private Service Connect“ kein verbundener Endpunkt angezeigt.

  • Sie können das Subnetz oder VPC-Netzwerk, das dem internen Endpunkt in einem Cluster zugewiesen ist, der Private Service Connect verwendet, nicht löschen. Es wird eine Fehlermeldung wie die folgende angezeigt:

    projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Mögliche Ursachen

In GKE-Clustern, die Private Service Connect verwenden, wird ein Private Service Connect-Endpunkt mithilfe einer Weiterleitungsregel bereitgestellt, die eine interne IP-Adresse für den Zugriff auf die Steuerungsebene des Clusters im Netzwerk der Steuerungsebene zuweist. Um die Kommunikation zwischen der Steuerungsebene und den Knoten mit Private Service Connect zu schützen, hält GKE den Endpunkt unsichtbar. Er ist weder in derCloud de Confiance Console noch in der gcloud CLI zu sehen.

Lösung

Führen Sie die folgenden Schritte aus, um zu verhindern, dass der Private Service Connect-Endpunkt vor dem Löschen des Clusters preisgegeben wird:

  1. Weisen Sie dem GKE-Dienstkonto die Rolle Kubernetes Engine Service Agent role zu.
  2. Die Berechtigungen compute.forwardingRules.* und compute.addresses.* dürfen dem GKE-Dienstkonto nicht ausdrücklich verweigert werden.

Wenn der Private Service Connect-Endpunkt gehackt wurde, wenden Sie sich an den Support.

Autorisiertes Netzwerk des Clusters kann nicht geparst werden

Symptome

Sie können keinen Cluster in Version 1.29 oder höher erstellen. Es wird eine Fehlermeldung wie die folgende angezeigt:

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
Mögliche Ursachen

In Ihrem Cloud de Confiance Projekt werden private IP-basierte Webhooks verwendet. Daher können Sie keinen Cluster mit Private Service Connect erstellen. Stattdessen verwendet Ihr Cluster VPC-Netzwerk-Peering, das das Flag master-ipv4-cidr parst.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Fahren Sie mit dem Erstellen des VPC-Netzwerk-Peering-Clusters fort und fügen Sie master-ipv4-cidr ein, um gültige CIDRs zu definieren. Diese Lösung unterliegt den folgenden Einschränkungen:

    • Das Flag master-ipv4-cidr wurde in der Cloud de Confiance Console verworfen. Sie können dieses Flag nur mit der Google Cloud CLI oder Terraform aktualisieren.
    • VPC Network Peering ist ab GKE-Version 1.29 nicht mehr verfügbar.

  • Migrieren Sie Ihre auf privaten IP-Adressen basierenden Webhooks, indem Sie die Schritte unter Einschränkungen von Private Service Connect ausführen.Wenden Sie sich an den Support, um die Verwendung von Clustern mit Private Service Connect zu aktivieren.

Interner IP-Adressbereich kann in Clustern mit öffentlichen Knoten nicht definiert werden

Symptome

Sie können keinen internen IP-Adressbereich mit dem Flag --master-ipv4-cidr definieren. Es wird eine Fehlermeldung wie die folgende angezeigt:

ERROR: (gcloud.container.clusters.create) Cannot specify --master-ipv4-cidr
  without --enable-private-nodes
Mögliche Ursachen

Sie definieren einen internen IP-Adressbereich für die Steuerungsebene mit dem Flag master-ipv4-cidr in einem Cluster, ohne dass das Flag enable-private-nodes aktiviert ist. Wenn Sie einen Cluster mit definiertem master-ipv4-cidr erstellen möchten, müssen Sie Ihren Cluster so konfigurieren, dass Knoten mit internen IP-Adressen (private Knoten) mit dem Flag enable-private-nodes bereitgestellt werden.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Erstellen Sie mit dem folgenden Befehl einen Cluster:

    gcloud container clusters create-auto CLUSTER_NAME \
    --enable-private-nodes \
    --master-ipv4-cidr CP_IP_RANGE

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • CLUSTER_NAME: der interne IP-Adressbereich für die Steuerungsebene.

  • Aktualisieren Sie den Cluster, um Knoten nur mit IP-Adressen bereitzustellen. Weitere Informationen finden Sie unter Cluster konfigurieren.

Öffentliche Arbeitslasten können in Autopilot-Clustern nicht geplant werden

Symptome
Wenn Ihr Autopilot-Cluster nur private Knoten verwendet, können Sie Arbeitslasten in öffentlichen Pods nicht mit dem nodeSelector cloud.google.com/private-node=false planen.
Mögliche Ursachen
Die Konfiguration des Flags private-node, das im nodeSelector des Pods auf false gesetzt ist, ist nur in Clustern der Version 1.30.3 oder höher verfügbar.
Lösung
Aktualisieren Sie Ihren Cluster auf Version 1.30 oder höher.

Der Zugriff auf den DNS-basierten Endpunkt ist deaktiviert

Symptome

Wenn Sie versuchen, kubectl-Befehle für den Cluster auszuführen, wird ein Fehler wie der folgende zurückgegeben:

couldn't get current server API group list:
control_plane_endpoints_config.dns_endpoint_config.allow_external_traffic is
disabled
Mögliche Ursachen

Der DNS-basierte Zugriff wurde in Ihrem Cluster deaktiviert.

Lösung

Aktivieren Sie den Zugriff auf die Steuerungsebene über den DNS-basierten Endpunkt der Steuerungsebene. Weitere Informationen finden Sie unter Zugriff auf die Steuerungsebene ändern.

Knoten können beim Skalieren keine IP-Adresse zuweisen

Symptome

Wenn Sie versuchen, den primären IP-Adressbereich des Subnetzes in die Liste der autorisierten Netzwerke aufzunehmen, wird ein Fehler ähnlich dem folgenden zurückgegeben:

 authorized networks fields cannot be mutated if direct IP access is disabled
Mögliche Ursachen

Sie haben den IP-basierten Endpunkt des Clusters deaktiviert.

Lösung

Deaktivieren und aktivieren Sie den IP-basierten Endpunkt des Clusters mit dem Flag enable-ip-access.

Zu viele CIDR-Blöcke

gcloud gibt den folgenden Fehler zurück, wenn Sie versuchen, einen Cluster mit mehr als 50 CIDR-Blöcken zu erstellen oder zu aktualisieren:

ERROR: (gcloud.container.clusters.update) argument --master-authorized-networks: too many args

Versuchen Sie Folgendes, um dieses Problem zu beheben:

Serververbindung kann nicht hergestellt werden

kubectl-Befehle führen zu einer Zeitüberschreitung wegen falsch konfigurierter CIDR-Blöcke:

Unable to connect to the server: dial tcp MASTER_IP: getsockopt: connection timed out

Geben Sie beim Erstellen oder Aktualisieren eines Clusters die richtigen CIDR-Blöcke an.

Knoten können trotz Netzwerkisolation auf öffentliche Container-Images zugreifen

Symptome

In einem für Netzwerkisolation konfigurierten GKE-Cluster kann es vorkommen, dass das Pullen eines gängigen öffentlichen Images wie redis funktioniert, das Pullen eines weniger gängigen oder privaten Images jedoch fehlschlägt.

Dieses Verhalten ist aufgrund der Standardkonfiguration von GKE zu erwarten und bedeutet nicht, dass GKE Ihre Netzwerkisolation umgangen hat.

Mögliche Ursachen

Dieses Verhalten ist auf das Zusammenspiel zweier Funktionen zurückzuführen:

  • Privater Google-Zugriff: Mit dieser Funktion können Knoten mit internen IP-Adressen eine Verbindung zu Google Cloud APIs und -Diensten herstellen, ohne öffentliche IP-Adressen zu benötigen. Der privater Google-Zugriff ist im Subnetz des Clusters innerhalb der VPC aktiviert, die von den Knoten im Cluster verwendet wird. Wenn ein Cluster oder Knotenpool mit dem Flag --enable-private-nodes erstellt oder aktualisiert wird, aktiviert die GKE automatisch den privater Google-Zugriff in diesem Subnetz. Die einzige Ausnahme ist, wenn Sie eine freigegebene VPC verwenden. In diesem Fall müssen Sie den privater Google-Zugriff manuell aktivieren.
  • Google-Image-Mirror (mirror.gcr.io): Standardmäßig konfiguriert GKE seine Knoten so, dass sie zuerst versuchen, Images aus mirror.gcr.io abzurufen. Dies ist eine von Google verwaltete Artifact Registry, in der häufig angeforderte öffentliche Container-Images im Cache gespeichert werden.

Wenn Sie versuchen, ein Image wie redis abzurufen, verwendet Ihr Knoten den privaten Pfad vom privater Google-Zugriff, um eine Verbindung zu mirror.gcr.io herzustellen. Da redis ein sehr häufiges Bild ist, ist es im Cache vorhanden und der Pull ist erfolgreich. Wenn Sie jedoch ein Bild anfordern, das sich nicht in diesem öffentlichen Cache befindet, schlägt der Pull fehl, da Ihr isolierter Knoten keine andere Möglichkeit hat, die ursprüngliche Quelle zu erreichen.

Lösung

Wenn ein Image, das Sie benötigen, nicht im mirror.gcr.io-Cache verfügbar ist, hosten Sie es in Ihrem eigenen privaten Artifact Registry-Repository. Ihre netzwerkisolierten Knoten können über den privater Google-Zugriff auf dieses Repository zugreifen.

Nächste Schritte