Fehlerbehebung bei der Netzwerkisolation in GKE

Auf dieser Seite wird beschrieben, wie Sie Probleme mit der Netzwerkisolation in der Google Kubernetes Engine (GKE) beheben.

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

GKE-Cluster wird nicht ausgeführt

Ein Cluster funktioniert in folgenden Fällen nicht mehr: – Die Firewallregeln, die eingehenden Traffic von der Cluster-Kontrollebene zu Knoten auf Port 10250 zulassen, werden gelöscht. – Die Standardroute zum Standard-Internetgateway wird gelöscht. Wenn Sie die Standardroute löschen, müssen Sie dafür sorgen, dass der Traffic an die erforderlichenGoogle Cloud -Dienste weitergeleitet wird. Weitere Informationen finden Sie unter Benutzerdefiniertes Routing.

Zeitüberschreitung beim Erstellen eines Clusters

Symptome
Cluster, die in Version 1.28 oder niedriger mit privaten Knoten erstellt wurden, erfordern eine Peering-Route zwischen VPCs. Es kann jedoch jeweils nur ein Peering-Vorgang ausgeführt werden. Wenn Sie versuchen, mehrere Cluster mit den oben genannten Eigenschaften 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 niedriger seriell, damit die VPC-Peering-Routen für jeden nachfolgenden Cluster bereits ohne externen Endpunkt 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.

  • Cluster in Version 1.29 oder höher erstellen

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 mehr auf dem Cluster ausführen, da die Erreichbarkeit der Steuerungsebene unterbrochen ist. Wenn Sie die Kontrollebene prüfen, wird in den Protokollen 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

Gehen Sie so vor:

  1. Erstellen Sie einen neuen temporären Cluster für das VPC-Netzwerk-Peering. Die Cluster-Erstellung führt zu einer Wiederherstellung des VPC-Netzwerk-Peerings und der alte Cluster wird wieder in den Normalbetrieb versetzt.

  2. Löschen Sie den vorübergehend erstellten VPC-Netzwerk-Peering-Cluster, nachdem der alte Cluster wieder in den Normalbetrieb versetzt wurde.

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 mehr auf dem Cluster ausführen, da die Verbindung zum Zugriff auf die Steuerungsebene getrennt ist. Wenn Sie die Kontrollebene prüfen, wird in den Protokollen 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

Rotieren Sie die IP-Adresse der Steuerungsebene.

Cluster überschneidet sich mit aktivem Peer

Symptome

Wenn Sie versuchen, einen Cluster ohne externen Endpunkt zu erstellen, wird ein Fehler wie der folgende 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 neu in Version 1.29 und fügen Sie das Flag --enable-private-nodes hinzu.

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

Nach dem Erstellen eines Clusters ohne externen Endpunkt wird bei dem Versuch, kubectl-Befehle für den Cluster auszuführen, ein Fehler wie einer der 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 Clustersteuerungsebene 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 mithilfe ihrer externen IP-Adresse zulässig ist. Wenn Sie den externen Zugriff auf die Clustersteuerungsebene 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 beliebiger 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 zu diesem Fehler führen:

  • 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 einen Cluster mit einem automatischen Subnetz oder ein benutzerdefiniertes Subnetz erstellen, wird möglicherweise einer der folgenden Fehler zurückgegeben:

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 CIDR-Bereiche wiederzuverwenden, die in einem kürzlich gelöschten Cluster verwendet wurden.

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 müssen nur zusätzlich konfiguriert werden, um die Anforderungen für den Internetzugriff zu erfüllen. Die Knoten können jedoch auf Google Cloud APIs und ‑Dienste, einschließlich Artifact Registry, zugreifen, wenn Sie privaten Google-Zugriff aktiviert und die Netzwerkanforderungen erfüllt haben.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Kopieren Sie die Images in Ihrem Cluster von Docker Hub nach 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.

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 ein, 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 ein Standardcluster mit privaten Knotenpools erstellt wurde, bleibt der Schritt bei der Systemdiagnose hängen und meldet einen Fehler wie einen der folgenden:

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 zu diesem Fehler führen:

  • Clusterknoten können die erforderlichen Binärdateien nicht von der Cloud Storage API (storage.googleapis.com) herunterladen.
  • Firewallregeln schränken den ausgehenden Traffic ein.
  • IAM-Berechtigungen für die freigegebene 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:

Kubelet konnte keine Pod-Sandbox erstellen

Symptome

Nachdem Sie einen Cluster mit privaten Knoten erstellt haben, wird ein Fehler wie einer der folgenden angezeigt:

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, die nur Knoten mit privaten IP-Adressen verwenden, wird die Standardroute (0.0.0.0/0) bei Verwendung von benutzerdefiniertem Routing und Netzwerk-Appliances von Drittanbietern in der VPC häufig an die Appliance weitergeleitet anstatt an das Standard-Internetgateway. 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 in 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 wie die folgende angezeigt:

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

Ihr Cluster verwendet ein Legacy-Netzwerk.

Lösung

Migrieren Sie Ihre Cluster zu Private Service Connect. Weitere Informationen zum Status der Migration erhalten Sie vom Support .

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

Symptome

Nachdem Sie den IP-Adressendpunkt deaktiviert haben, wird eine Fehlermeldung wie die folgende 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:

  • Alle Knotenpools manuell in einer anderen Version neu erstellen.
  • 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 wie die folgende 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 muss eine IP-Adressrotation oder ein Versionsupdate durchgeführt werden.

Lösung

Verwenden Sie eine der folgenden Lösungen:

Clustererstellung schlägt fehl, wenn Organisationsrichtlinien definiert sind

Symptome

Beim Versuch, einen Cluster zu erstellen, wird eine Fehlermeldung wie die folgende angezeigt:

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Mögliche Ursachen

Der Clusterendpunkt oder das Cluster-Backend wird durch eine Organisationsrichtlinie eines Nutzers blockiert.

Lösung

Wenn Sie Instanzen erlauben möchten, Endpunkte mit der Einschränkung compute.restrictPrivateServiceConnectProducer zu erstellen, führen Sie die Schritte unter Nutzerseitige Organisationsrichtlinien 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, in dem Private Service Connect verwendet wird, 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 derGoogle Cloud -Konsole 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

In Version 1.29 oder höher können Sie keinen Cluster 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 Google Cloud -Projekt werden private IP-basierte Webhooks verwendet. Daher können Sie keinen Cluster mit Private Service Connect erstellen. Stattdessen verwendet Ihr Cluster das VPC-Netzwerk-Peering, das das Flag master-ipv4-cidr analysiert.

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 hinzu, um gültige CIDRs zu definieren. Diese Lösung hat die folgenden Einschränkungen:

    • Das Flag master-ipv4-cidr wurde in der Google Cloud Console eingestellt. Sie können dieses Flag nur mit der Google Cloud CLI oder Terraform aktualisieren.
    • VPC-Netzwerk-Peering wird in GKE-Version 1.29 oder höher nicht mehr unterstützt.

  • Migrieren Sie Ihre privaten IP-basierten Webhooks. Folgen Sie dazu der Anleitung unter Einschränkungen von Private Service Connect. Wenden Sie sich an den Support , um die Verwendung von Clustern mit Private Service Connect zu aktivieren.

In Clustern mit öffentlichen Knoten kann kein Bereich für interne IP-Adressen 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 mit dem Flag enable-private-nodes so konfigurieren, dass Knoten mit internen IP-Adressen (private Knoten) bereitgestellt werden.

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Erstellen Sie einen Cluster mit dem folgenden Befehl:

    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: den internen IP-Adressbereich für die Steuerungsebene.

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

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

Symptome
Wenn in Autopilot-Clustern nur private Knoten verwendet werden, können Sie Arbeitslasten nicht mithilfe des cloud.google.com/private-node=false-Knoten-Selectors in öffentlichen Pods planen.
Mögliche Ursachen
Die Konfiguration des private-node-Flags, das im Pod als false festgelegt 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 für Ihren 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-Adressen zuweisen

Symptome

Wenn Sie versuchen, den primären IP-Adressbereich des Subnetzes in die Liste der autorisierten Netzwerke aufzunehmen, wird ein Fehler wie der folgende 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.