Fehlerbehebung für das kubectl-Befehlszeilentool

Bei der Arbeit mit Google Kubernetes Engine (GKE) können Probleme mit dem kubectl-Befehlszeilentool die Bereitstellung von Anwendungen oder die Verwaltung von Clusterressourcen verhindern. Diese Probleme lassen sich in der Regel in zwei Kategorien einteilen: Authentifizierungsfehler, bei denen der Cluster Ihre Identität nicht erkennt, und Verbindungsfehler, bei denen Ihr Tool die Steuerungsebene des Clusters nicht erreichen kann.

Auf dieser Seite finden Sie Informationen zur Diagnose und Behebung dieser Probleme. Hier finden Sie Schritte zur Fehlerbehebung bei verschiedenen Authentifizierungsproblemen und zur Behebung von Verbindungsproblemen zwischen dem kubectl-Tool und der Steuerungsebene Ihres Clusters. Hier erfahren Sie, wie Sie prüfen, ob die erforderlichen Plug-ins installiert und konfiguriert sind, und wie Sie die Netzwerkrichtlinie und die Firewall für Dienste wie SSH und Konnectivity konfigurieren.

Diese Informationen sind wichtig für alle, die kubectl-Befehle verwenden, um Anwendungen oder Clusterressourcen in GKE zu verwalten. Das ist besonders wichtig für Anwendungsentwickler und Plattformadministratoren und ‑betreiber, die für ihre täglichen Kernaufgaben auf kubectl-Befehle angewiesen sind. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

Weitere Informationen finden Sie in den folgenden Ressourcen:

  • Weitere Informationen zu Problemen, die nicht spezifisch für GKE sind, finden Sie in der Kubernetes-Dokumentation unter Fehlerbehebung bei kubectl.
  • Weitere Informationen zur Verwendung von kubectl-Befehlen zum Diagnostizieren von Problemen mit Ihren Clustern und Arbeitslasten finden Sie unter Clusterstatus mit kubectl untersuchen.

Fehler bei der Authentifizierung und Autorisierung

Wenn bei der Verwendung der Befehle des kubectl-Befehlszeilentools Fehler im Zusammenhang mit der Authentifizierung und Autorisierung auftreten, finden Sie in den folgenden Abschnitten Ratschläge.

Fehler: 401 (Unauthorized)

Beim Herstellen einer Verbindung zu GKE-Clustern kann ein Authentifizierungs- und Autorisierungsfehler mit dem HTTP-Statuscode 401 (Unauthorized) auftreten. Dieses Problem kann auftreten, wenn Sie versuchen, einen kubectl-Befehl in Ihrem GKE-Cluster über eine lokale Umgebung auszuführen. Weitere Informationen finden Sie unter Problem: Authentifizierungs- und Autorisierungsfehler.

Fehler: Unzureichende Authentifizierungsbereiche

Wenn Sie gcloud container clusters get-credentials ausführen, wird möglicherweise der folgende Fehler angezeigt:

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Request had insufficient authentication scopes.

Dieser Fehler tritt auf, weil Sie von einer Compute Engine-VM, die nicht den cloud-platform-Bereich hat, auf die GKE API zugreifen.

Um diesen Fehler zu beheben, gewähren Sie den fehlenden cloud-platform-Bereich. Eine Anleitung zum Ändern der Bereiche auf Ihrer Compute Engine-VM-Instanz finden Sie in der Compute Engine-Dokumentation unter Dienstkonten für Instanzen erstellen und aktivieren.

Fehler: Ausführbare Datei gke-gcloud-auth-plugin nicht gefunden

Beim Ausführen von kubectl-Befehlen oder benutzerdefinierten Clients, die mit GKE interagieren, können ähnliche Fehlermeldungen wie die folgenden auftreten:

Unable to connect to the server: getting credentials: exec: executable gke-gcloud-auth-plugin not found

It looks like you are trying to use a client-go credential plugin that is not installed.

To learn more about this feature, consult the documentation available at:
      https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins

Visit cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin to install gke-gcloud-auth-plugin.

Unable to connect to the server: getting credentials: exec: fork/exec /usr/lib/google-cloud-sdk/bin/gke-gcloud-auth-plugin: no such file or directory

Installieren Sie zur Behebung des Problems gke-gcloud-auth-plugin wie unter Erforderliche Plug-ins installieren beschrieben.

Fehler: Kein Authentifizierungsanbieter gefunden

Der folgende Fehler tritt auf, wenn kubectl oder benutzerdefinierte Kubernetes-Clients mit Kubernetes client-go Version 1.26 oder höher erstellt wurden:

no Auth Provider found for name "gcp"

So beheben Sie das Problem:

  1. Installieren Sie gke-gcloud-auth-plugin wie unter Erforderliche Plug-ins installieren beschrieben.

  2. Aktualisieren Sie auf die neueste Version der gcloud CLI:

    gcloud components update

  3. Aktualisieren Sie die Datei kubeconfig:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene des Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

Fehler: Das GCP-Authentifizierungs-Plug-in wurde verworfen, verwenden Sie stattdessen gcloud

Diese Warnmeldung wird möglicherweise angezeigt, nachdem Sie gke-gcloud-auth-plugin installiert und einen kubectl-Befehl für einen GKE-Cluster ausgeführt haben:

WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.

Diese Meldung wird angezeigt, wenn Ihre Clientversion älter als 1.26 ist.

Damit Ihr Client stattdessen das Authentifizierungs-Plug-in gke-gcloud-auth-plugin verwendet, gehen Sie so vor:

  1. Öffnen Sie das Shell-Anmeldeskript in einem Texteditor:

    Bash

    vi ~/.bashrc

    Zsh

    vi ~/.zshrc

    Wenn Sie PowerShell verwenden, überspringen Sie diesen Schritt.

  2. Legen Sie die folgende Umgebungsvariable fest:

    Bash

    export USE_GKE_GCLOUD_AUTH_PLUGIN=True

    Zsh

    export USE_GKE_GCLOUD_AUTH_PLUGIN=True

    PowerShell

    [Environment]::SetEnvironmentVariable('USE_GKE_GCLOUD_AUTH_PLUGIN', True, 'Machine')

  3. Wenden Sie die Variable in Ihrer Umgebung an:

    Bash

    source ~/.bashrc

    Zsh

    source ~/.zshrc

    PowerShell

    Beenden Sie das Terminal und öffnen Sie eine neue Terminalsitzung.

  4. gcloud CLI aktualisieren

    gcloud components update

  5. Beim Cluster authentifizieren:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene des Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

Problem: Befehl kubectl wurde nicht gefunden

Wenn Sie die Meldung erhalten, dass der Befehl kubectl nicht gefunden wurde, installieren Sie die kubectl-Binärdatei neu und legen Sie die Umgebungsvariable $PATH fest:

  1. Installieren Sie die kubectl-Binärdatei:

    gcloud components update kubectl

  2. Wenn das Installationsprogramm Sie auffordert, die Umgebungsvariable $PATH zu ändern, geben Sie y ein, um fortzufahren. Durch die Änderung dieser Variablen können Sie kubectl-Befehle verwenden, ohne den vollständigen Pfad eingeben zu müssen.

    Alternativ können Sie die folgende Zeile an dem Speicherort für Umgebungsvariablen in der verwendeten Shell hinzufügen, z. B. in ~/.bashrc (oder ~/.bash_profile unter macOS):

    export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/

  3. Führen Sie den folgenden Befehl aus, um die aktualisierte Datei zu laden. Im folgenden Beispiel wird .bashrc verwendet:

    source ~/.bashrc

    Wenn Sie macOS verwenden, nutzen Sie ~/.bash_profile anstelle von .bashrc.

Problem: kubectl-Befehle geben den Fehler "Verbindung verweigert" aus

Wenn kubectl-Befehle den Fehler „Verbindung verweigert“ zurückgeben, müssen Sie den Clusterkontext mit dem folgenden Befehl festlegen:

gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene Ihres Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.

Wenn Sie sich nicht sicher sind, was Sie für den Clusternamen oder den Standort eingeben sollen, können Sie den folgenden Befehl verwenden, um die vorhandenen Cluster aufzulisten:

gcloud container clusters list

Fehler: Zeitüberschreitung beim kubectl-Befehl

Wenn Sie einen Cluster erstellt und versucht haben, einen kubectl-Befehl für den Cluster auszuführen, der kubectl-Befehl jedoch ein Zeitlimit überschreitet, wird ein Fehler ähnlich dem folgenden angezeigt:

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

Diese Fehler weisen darauf hin, dass kubectl nicht mit der Steuerungsebene des Clusters kommunizieren kann.

So beheben Sie dieses Problem:

  1. Rufen Sie $HOME/.kube/config auf oder führen Sie den Befehl kubectl config view aus, um zu prüfen, ob die Konfigurationsdatei den Clusterkontext und die externe IP-Adresse der Steuerungsebene enthält.

  2. Legen Sie die Clusteranmeldedaten fest:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene des Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.
    • PROJECT_ID: die ID des Projekts, in dem der Cluster erstellt wurde.

  3. Wenn Sie autorisierte Netzwerke im Cluster aktiviert haben, muss die Liste der vorhandenen autorisierten Netzwerke die ausgehende IP-Adresse des Computers enthalten, von dem aus Sie eine Verbindung herstellen möchten. Sie finden Ihre autorisierten Netzwerke in der Console oder durch Ausführen des folgenden Befehls:

    gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID \
    --format "flattened(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetwork
sConfig.cidrBlocks[])"

    Wenn die ausgehende IP-Adresse des Computers nicht in der Liste der autorisierten Netzwerke in der Ausgabe des vorherigen Befehls enthalten ist, führen Sie einen der folgenden Schritte aus:

Fehler: kubectl-Befehle geben den Fehler „Es konnte keine API-Version festgelegt werden“ zurück

Wenn kubectl-Befehle den Fehler failed to negotiate an API version zurückgeben, müssen Sie dafür sorgen, dass kubectl Authentifizierungsanmeldedaten hat:

gcloud auth application-default login

Problem: Der Befehl kubectl logs, attach, exec oder port-forward reagiert nicht mehr

Wenn die Befehle kubectl, logs, attach, exec oder port-forward nicht mehr reagieren, kann der API-Server in der Regel nicht mit den Knoten kommunizieren.

Prüfen Sie zuerst, ob Ihr Cluster Knoten enthält. Wenn Sie die Anzahl der Knoten in Ihrem Cluster bis auf null reduziert haben, funktionieren Befehle nicht. Passen Sie die Größe Ihres Clusters an, um das Problem zu beheben. Es muss mindestens ein Knoten vorhanden sein.

Wenn Ihr Cluster mindestens einen Knoten hat, prüfen Sie, ob Sie SSH- oder Konnectivity-Proxy-Tunnel für eine sichere Kommunikation verwenden. In den folgenden Abschnitten werden die für die einzelnen Dienste spezifischen Schritte zur Fehlerbehebung beschrieben:

SSH-Probleme beheben

Wenn Sie SSH verwenden, speichert GKE eine Datei mit dem öffentlichen SSH-Schlüssel in den Metadaten Ihres Compute Engine-Projekts. Alle Compute Engine-VMs, die von Google bereitgestellte Images verwenden, prüfen regelmäßig die allgemeinen Metadaten ihres Projekts und die Instanzmetadaten auf SSH-Schlüssel, um diese der Liste mit autorisierten Nutzern der VM hinzuzufügen. GKE fügt dem Compute Engine-Netzwerk außerdem eine Firewallregel hinzu, mit der der SSH-Zugriff von der IP-Adresse der Steuerungsebene auf jeden Knoten im Cluster möglich ist.

Die folgenden Einstellungen können Probleme mit der SSH-Kommunikation verursachen:

  • Die Firewallregeln Ihres Netzwerks lassen keinen SSH-Zugriff auf die Steuerungsebene zu.

    Alle Compute Engine-Netzwerke werden mit einer Firewallregel mit dem Namen default-allow-ssh erstellt, die den SSH-Zugriff über alle IP-Adressen ermöglicht (erfordert einen gültigen privaten Schlüssel). Von GKE wird darüber hinaus für jeden öffentlichen Cluster eine SSH-Regel der Form gke-CLUSTER_NAME-RANDOM_CHARACTERS-ssh eingefügt, mit der der SSH-Zugriff speziell von der Steuerungsebene des Clusters auf dessen Knoten möglich ist.

    Wenn keine dieser Regeln existiert, kann die Steuerungsebene keine SSH-Tunnel öffnen.

    Prüfen Sie, ob Ihre Konfiguration diese Regeln enthält, um festzustellen, ob dies die Ursache des Problems ist.

    Um dieses Problem zu beheben, identifizieren Sie das Tag, das sich auf allen Knoten des Clusters befindet, und fügen Sie dann noch einmal eine Firewallregel hinzu, die den Zugriff auf VMs mit diesem Tag über die IP-Adresse der Steuerungsebene ermöglicht.

  • Der Metadaten-Eintrag Ihres Projekts für ssh-keys ist voll.

    Wenn der Metadateneintrag ssh-keys des Projekts nahe der maximalen Größe liegt, kann GKE keinen eigenen SSH-Schlüssel zum Öffnen von SSH-Tunneln hinzufügen.

    Um zu prüfen, ob dies das Problem ist, sehen Sie sich die Länge der Liste der ssh-keys an. Sie können die Metadaten Ihres Projekts mit dem folgenden Befehl aufrufen und optional das Flag --project einfügen:

    gcloud compute project-info describe [--project=PROJECT_ID]

    Löschen Sie einige SSH-Schlüssel, die nicht mehr benötigt werden, um dieses Problem zu beheben.

  • Sie haben auf den VMs im Cluster für ein Metadatenfeld den Schlüssel ssh-keys festgelegt.

    Der Knoten-Agent auf VMs bevorzugt pro Instanz zugewiesene SSH-Schlüssel gegenüber projektweiten SSH-Schlüsseln. Wenn Sie also speziell auf den Clusterknoten SSH-Schlüssel eingerichtet haben, dann wird der SSH-Schlüssel der Steuerungsebene in den Projektmetadaten von den Knoten nicht beachtet.

    Führen Sie zum Prüfen gcloud compute instances describe VM_NAME aus und suchen Sie in den Metadaten das Feld ssh-keys.

    Löschen Sie zum Beheben des Problems die pro Instanz zugewiesenen SSH-Schlüssel aus den Instanzmetadaten.

Probleme mit dem Konnectivity-Proxy beheben

Sie können feststellen, ob Ihr Cluster den Konnectivity-Proxy verwendet, indem Sie nach der folgenden Systembereitstellung suchen:

kubectl get deployments konnectivity-agent --namespace kube-system

Wenn Ihr Cluster den Konnectivity-Proxy verwendet, sieht die Ausgabe in etwa so aus:

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
konnectivity-agent   3/3     3            3           18d

Nachdem Sie bestätigt haben, dass Sie den Konnectivity-Proxy verwenden, müssen Sie dafür sorgen, dass die Konnectivity-Agents den erforderlichen Firewall-Zugriff haben und Ihre Netzwerkrichtlinien richtig eingerichtet sind.

Erforderlichen Firewallzugriff zulassen

Prüfen Sie, ob die Firewallregeln Ihres Netzwerks den Zugriff auf die folgenden Ports zulassen:

  • Steuerungsebenenport: Bei der Clustererstellung stellen Konnectivity-Agents Verbindungen zur Steuerungsebene über Port 8132 her. Wenn Sie einen kubectl-Befehl ausführen, verwendet der API-Server diese Verbindung, um mit dem Cluster zu kommunizieren. Achten Sie darauf, dass ausgehender Traffic zur Steuerungsebene des Clusters auf Port 8132 zugelassen wird. Zum Vergleich: Der API-Server verwendet Port 443. Wenn Sie Regeln haben, die den Zugriff auf ausgehenden Traffic verweigern, müssen Sie die Regeln möglicherweise ändern oder Ausnahmen erstellen.

  • kubelet-Port: Da Konnectivity-Agents System-Pods sind, die auf Ihren Clusterknoten bereitgestellt werden, müssen Ihre Firewallregeln die folgenden Arten von Traffic zulassen:

    • Eingehender Traffic zu Ihren Arbeitslasten über Port 10250 aus Ihren Pod-Bereichen.
    • Ausgehender Traffic aus Ihren Pod-Bereichen.

    Wenn Ihre Firewallregeln diese Art von Traffic nicht zulassen, ändern Sie Ihre Regeln.

Netzwerkrichtlinie anpassen

Der Konnectivity-Proxy kann Probleme haben, wenn die Netzwerkrichtlinie Ihres Clusters eine der folgenden Aktionen ausführt:

  • Blockiert eingehenden Traffic vom Namespace kube-system zum Namespace workload
  • Blockiert ausgehenden Traffic zur Cluster-Steuerungsebene an Port 8132

Wenn der Ingress durch die Netzwerkrichtlinie von Arbeitslast-Pods blockiert wird, enthalten die konnectivity-agent-Logs eine Fehlermeldung ähnlich der folgenden:

"error dialing backend" error="dial tcp POD_IP_ADDRESS:PORT: i/o timeout"

In der Fehlermeldung ist POD_IP_ADDRESS die IP-Adresse des Arbeitslast-Pods.

Wenn der ausgehende Traffic durch eine Netzwerkrichtlinie blockiert wird, enthalten die konnectivity-agent-Logs eine Fehlermeldung wie die folgende:

"cannot connect once" err="rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp CP_IP_ADDRESS:8132: i/o timeout

Im Fehler ist CP_IP_ADDRESS die IP-Adresse der Clustersteuerungsebene.

Diese Funktionen sind für ein korrektes Funktionieren des Clusters nicht erforderlich. Wenn Sie es vorziehen, Ihr Clusternetzwerk für alle externen Zugriffe zu sperren, können Sie Funktionen wie diese nicht mehr verwenden.

Wenn Sie prüfen möchten, ob die Ingress- oder Egress-Regeln der Netzwerkrichtlinie die Ursache des Problems sind, suchen Sie mit dem folgenden Befehl nach den Netzwerkrichtlinien im betroffenen Namespace:

kubectl get networkpolicy --namespace AFFECTED_NAMESPACE

Fügen Sie dem Feld spec.ingress der Netzwerkrichtlinien Folgendes hinzu, um das Problem mit der Ingress-Richtlinie zu beheben:

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
    podSelector:
      matchLabels:
        k8s-app: konnectivity-agent

Fügen Sie dem Feld spec.egress der Netzwerkrichtlinien Folgendes hinzu, um das Problem mit der Egress-Richtlinie zu beheben:

egress:
- to:
  - ipBlock:
      cidr: CP_IP_ADDRESS/32
  ports:
  - protocol: TCP
    port: 8132

Wenn in Ihrer Netzwerkrichtlinie eine Kombination aus Regeln für ein- und ausgehenden Traffic verwendet wird, sollten Sie beide anpassen.

IP-Masquerade-Agent anpassen

Die Cluster-Steuerungsebene akzeptiert den Traffic von den Konnectivity-Agents, wenn die Quell-IP-Adresse in den Pod-IP-Adressbereichen liegt. Wenn Sie die Konfiguration von ip-masq-agent ändern, um die Quell-IP-Adresse für den Traffic zur Steuerungsebene des Clusters zu maskieren, können bei den Konnectivity-Agents Verbindungsfehler auftreten.

Um das Problem zu beheben und dafür zu sorgen, dass der Traffic von Konnectivity-Agents zur Clustersteuerungsebene nicht auf die Knoten-IP-Adresse maskiert wird, fügen Sie die IP-Adresse der Steuerungsebene der Liste nonMasqueradeCIDRs in der ConfigMap ip-masq-agent hinzu:

nonMasqueradeCIDRs:
- CONTROL_PLANE_IP_ADDRESS/32

Weitere Informationen zu dieser Konfiguration finden Sie unter IP-Masquerade-Agent.

Fehler: kubectl-Befehle schlagen mit dem Fehler „Kein Agent verfügbar“ fehl

Wenn Sie kubectl-Befehle ausführen, für die eine Verbindung von der GKE-Steuerungsebene zu einem Pod erforderlich ist, z. B. kubectl exec, kubectl logs oder kubectl port-forward, schlägt der Befehl möglicherweise mit Fehlermeldungen fehl, die den folgenden ähneln:

Error from server: error dialing backend: No agent available

failed to call webhook: Post "https://WEBHOOK_SERVICE.WEBHOOK_NAMESPACE.svc:PORT/PATH?timeout=10s": No agent available

v1beta1.metrics.k8s.io failed with: failing or missing response from https://NODE_IP:10250/apis/metrics.k8s.io/v1beta1: Get "https://NODE_IP:10250/apis/metrics.k8s.io/v1beta1": No agent available

Diese Fehler weisen auf ein Problem mit Konnectivity hin, dem sicheren Kommunikationstunnel zwischen der GKE-Steuerungsebene und den Knoten Ihres Clusters. Das bedeutet insbesondere, dass die konnectivity-server auf der Steuerungsebene keine Verbindung zu fehlerfreien konnectivity-agent-Pods im Namespace kube-system herstellen kann.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  1. Prüfen Sie den Status der konnectivity-agent-Pods:

    1. Prüfen Sie, ob die konnectivity-agent-Pods ausgeführt werden:

      kubectl get pods -n kube-system -l k8s-app=konnectivity-agent

      Die Ausgabe sieht etwa so aus:

      NAME                                   READY   STATUS    RESTARTS  AGE
konnectivity-agent-abc123def4-xsy1a    2/2     Running   0         31d
konnectivity-agent-abc123def4-yza2b    2/2     Running   0         31d
konnectivity-agent-abc123def4-zxb3c    2/2     Running   0         31d

      Prüfen Sie den Wert in der Spalte Status. Wenn die Pods den Status Running haben, prüfen Sie die Logs auf Verbindungsprobleme. Andernfalls müssen Sie herausfinden, warum die Pods nicht ausgeführt werden.

    2. Logs auf Verbindungsprobleme prüfen Wenn die Pods den Status Running haben, prüfen Sie die Logs auf Verbindungsprobleme. Da der Befehl kubectl logs von der Konnektivität abhängt, verwenden Sie den Log-Explorer in derGoogle Cloud Console:

      1. Rufen Sie in der Google Cloud Console den Log-Explorer auf.

        Zum Log-Explorer

      2. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein.

        resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="kube-system"
labels."k8s-pod/k8s-app"="konnectivity-agent"
resource.labels.container_name="konnectivity-agent"

        Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

      3. Klicken Sie auf Abfrage ausführen.

      4. Sehen Sie sich die Ausgabe an. Sehen Sie sich die konnectivity-agent-Logs an und suchen Sie nach Fehlern, die angeben, warum der Agent keine Verbindung herstellen kann. Authentifizierungs- oder Berechtigungsfehler deuten oft auf einen falsch konfigurierten Webhook hin, der Token-Rezensionen blockiert. Fehler vom Typ „Verbindung abgelehnt“ oder „Zeitüberschreitung“ bedeuten in der Regel, dass eine Firewallregel oder Netzwerkrichtlinie den Traffic zur Steuerungsebene auf dem TCP-Port 8132 oder den Traffic zwischen dem Konnectivity-Agent und anderen Knoten blockiert. Zertifikatsfehler deuten darauf hin, dass eine Firewall oder ein Proxy den verschlüsselten TLS-Traffic prüft und beeinträchtigt.

    3. Untersuchen Sie, warum die Pods nicht ausgeführt werden. Wenn Pods den Status Pending oder einen anderen Status haben, der nicht „Wird ausgeführt“ ist, untersuchen Sie die Ursache. konnectivity-agent wird als Deployment und nicht als DaemonSet ausgeführt. Da der Agent als Deployment ausgeführt wird, müssen die Agent-Pods nur auf einer Teilmenge von Knoten ausgeführt werden. Wenn diese bestimmte Teilmenge von Knoten jedoch nicht verfügbar ist, kann der gesamte Dienst ausfallen.

      Häufige Ursachen für einen nicht ausgeführten Pod:

      • Benutzerdefinierte Knotenmarkierungen, die verhindern, dass ein Pod geplant wird.
      • Unzureichende Knotenressourcen (CPU oder Arbeitsspeicher).
      • Restriktive Richtlinien für die Binärautorisierung, die GKE-System-Images blockieren.

      Wenn Sie weitere Informationen dazu erhalten möchten, warum ein bestimmter Pod nicht ausgeführt wird, verwenden Sie den Befehl kubectl describe:

      kubectl describe pod POD_NAME -n kube-system

      Ersetzen Sie POD_NAME durch den Namen des Pods, der nicht ausgeführt wird.

  2. Untersuchen Sie Ihre Admission-Webhooks, um sicherzustellen, dass keiner von ihnen TokenReview-API-Anfragen blockiert. Für die konnectivity-agent sind Dienstkonto-Tokens erforderlich. Wenn die Tokenüberprüfung beeinträchtigt wird, können sich Kundenservicemitarbeiter nicht verbinden. Wenn ein Webhook die Ursache ist, kann Konnectivity erst wiederhergestellt werden, wenn der fehlerhafte Webhook entfernt oder repariert wurde.

  3. Achten Sie darauf, dass Ihre Firewallregeln ausgehenden TCP-Traffic von Ihren GKE-Knoten zur IP-Adresse der Steuerungsebene auf Port 8132 zulassen. Diese Verbindung ist erforderlich, damit konnectivity-agent den Konnectivity-Dienst erreichen kann. Weitere Informationen finden Sie unter Erforderlichen Firewallzugriff zulassen.

  4. Achten Sie darauf, dass keine Netzwerkrichtlinienregeln vorhanden sind, die wichtigen Konnectivity-Traffic einschränken. Netzwerkrichtlinienregeln sollten sowohl clusterinternen Traffic (Pod-zu-Pod) innerhalb des kube-system-Namespace als auch ausgehenden Traffic von den konnectivity-agent-Pods zur GKE-Steuerungsebene zulassen.

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen: