Fehlerbehebung bei privaten Clustern in GKE

Auf dieser Seite wird beschrieben, wie Sie Probleme mit privaten Google Kubernetes Engine-Clustern beheben können.

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

Privater Cluster wird nicht ausgeführt

Ein privater Cluster funktioniert nicht mehr, wenn das VPC-Peering zwischen der Clustersteuerungsebene und den Clusterknoten gelöscht wird, 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 erforderlichen Google Cloud-Dienste weitergeleitet wird. Weitere Informationen finden Sie unter Benutzerdefiniertes Routing.

Zeitüberschreitung beim Erstellen eines privaten Clusters

Jeder private Cluster erfordert eine Peering-Route zwischen VPCs. Es ist jedoch jeweils immer nur ein Peering-Vorgang möglich. Wenn Sie versuchen, mehrere private Cluster gleichzeitig zu erstellen, kann es zu einer Zeitüberschreitung bei der Clustererstellung kommen. Wenn Sie dies vermeiden möchten, erstellen Sie seriell neue private Cluster, damit die VPC-Peering-Routen für jeden nachfolgenden privaten Cluster bereits vorhanden sind. Beim Versuch, einen einzelnen privaten Cluster zu erstellen, kann es zu einer Zeitüberschreitung kommen, wenn Vorgänge in Ihrer VPC ausgeführt werden.

Eine VPC-Netzwerk-Peering-Verbindung im privaten Cluster 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 auf dem Cluster ausführen, da die Erreichbarkeit zur Steuerungsebene getrennt ist. Wenn Sie die Steuerungsebene prüfen, wird in Logs ein Fehler wie der folgende angezeigt:

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

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

Lösung

Gehen Sie so vor:

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

  • Löschen Sie den vorübergehend erstellten VPC-Netzwerk-Peering-Cluster, nachdem der alte Cluster wiederhergestellt wurde.

Cluster überschneidet sich mit aktivem Peer

Symptome

Bei dem Versuch, einen privaten Cluster 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

Löschen Sie den Cluster und erstellen Sie ihn noch einmal mit einem anderen CIDR der Steuerungsebene.

Steuerungsebene eines privaten Clusters 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 privaten Clusters 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

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. Diese Konfiguration kann nach der Erstellung des Clusters nicht mehr geändert werden. 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(masterAuthorizedNetworksConfig)"\
      --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 Global auf privaten Endpunkt der Steuerungsebene zugreifen.

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

    gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "privateClusterConfig.masterGlobalAccessConfig"

    Ersetzen Sie Folgendes:

    Eine erfolgreiche Ausgabe sieht etwa so aus:

      enabled: true

  2. Wenn null zurückgegeben wird, aktivieren Sie den globalen Zugriff auf die Steuerungsebene.

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

Bei dem Versuch, einen privaten 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

Eine der folgenden:

  • 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:

  • 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.
  • 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 privaten Cluster mit einem automatischen Subnetz oder ein benutzerdefiniertes Subnetz erstellen, wird möglicherweise der folgende 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.
Mögliche Ursachen

Der von Ihnen angegebene CIDR-Bereich der Steuerungsebene überschneidet sich mit einem anderen IP-Bereich im Cluster. Dieser Fehler kann auch auftreten, wenn Sie kürzlich einen privaten Cluster gelöscht haben und versuchen, einen neuen privaten Cluster mit demselben CIDR-Bereich der Steuerungsebene zu erstellen.

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 in einem privaten Cluster haben keine externen IP-Adressen. Daher erfüllen sie nicht die Anforderungen für den Internetzugriff. Die Knoten können jedoch auf Google Cloud APIs und Google-Dienste, einschließlich Artifact Registry, zugreifen, wenn Sie privaten Google-Zugriff aktiviert haben und die Netzwerkanforderungen erfüllen.

Lösung

Verwenden Sie eine der folgenden Lösungen:

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

Eine der folgenden:

  • 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 privaten Cluster 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

Verwenden Sie eine der folgenden Lösungen:

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

Bei der Verwendung von benutzerdefiniertem Routing und Netzwerk-Appliances von Drittanbietern in der VPC, die Ihr privater Cluster verwendet, wird die Standardroute (0.0.0.0/0) 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 privaten GKE-Clustern können nicht auf das Internet zugreifen

Pods in privaten GKE-Clustern 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.