4xx-Fehler beheben


Auf dieser Seite erfahren Sie, wie Sie 400-, 401-, 403- und 404-Fehler beheben, die bei der Verwendung von Google Kubernetes Engine (GKE) auftreten können.

Problem: Fehler bei der Authentifizierung und Autorisierung

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.

Mögliche Ursachen:

  • Das gke-gcloud-auth-plugin-Authentifizierungs-Plug-in ist nicht richtig installiert oder konfiguriert.
  • Sie haben nicht die Berechtigungen, um eine Verbindung zum Cluster-API-Server herzustellen und kubectl-Befehle auszuführen.

Führen Sie die Schritte in den folgenden Abschnitten aus, um die Ursache zu ermitteln:

  1. Mit dem Cluster über curl verbinden
  2. Plug-in in kubeconfig konfigurieren

Mit dem Cluster über curl verbinden

Um die Ursache des Authentifizierungs- und Autorisierungsfehlers zu diagnostizieren, stellen Sie mit curl eine Verbindung zum Cluster her. Bei der Verwendung von curl werden das kubectl-Befehlszeilentool und das gke-gcloud-auth-plugin-Plug-in umgangen.

  1. Legen Sie Umgebungsvariablen fest:

    APISERVER=https://$(gcloud container clusters describe CLUSTER_NAME \
        --location=COMPUTE_LOCATION --format "value(endpoint)")
    TOKEN=$(gcloud auth print-access-token)
    
  2. Prüfen Sie, ob Ihr Zugriffstoken gültig ist:

    curl https://oauth2.googleapis.com/tokeninfo?access_token=$TOKEN
    

    Wenn Sie ein gültiges Zugriffstoken haben, wird mit diesem Befehl eine Anfrage an den OAuth 2.0-Server von Google gesendet. Der Server antwortet mit Informationen zum Token.

  3. Versuchen Sie, eine Verbindung zum Core-API-Endpunkt auf dem API-Server herzustellen:

    # Get cluster CA certificate
    gcloud container clusters describe CLUSTER_NAME \
        --location=COMPUTE_LOCATION \
        --format "value(masterAuth.clusterCaCertificate)" | \
        base64 -d > /tmp/ca.crt
    
    # Make API call with authentication and CA certificate
    curl -s -X GET "${APISERVER}/api/v1/namespaces" \
        --header "Authorization: Bearer $TOKEN" \
        --cacert /tmp/ca.crt
    

    Wenn der Befehl curl erfolgreich ausgeführt wird, wird eine Liste der Namespaces angezeigt. Fahren Sie mit den Schritten im Abschnitt Plug-in in kubeconfig konfigurieren fort, um zu prüfen, ob das Plug-in die Ursache ist.

    Wenn der Befehl curl mit einer Ausgabe wie der folgenden fehlschlägt, haben Sie nicht die richtigen Berechtigungen für den Zugriff auf den Cluster:

    {
    "kind": "Status",
    "apiVersion": "v1",
    "metadata": {},
    "status": "Failure",
    "message": "Unauthorized",
    "reason": "Unauthorized",
    "code": 401
    }
    

    Wenden Sie sich an Ihren Administrator, um dieses Problem zu beheben und die richtigen Berechtigungen für den Zugriff auf den Cluster zu erhalten.

Verwendung des Plug-ins in kubeconfig konfigurieren

Wenn Sie beim Herstellen einer Verbindung zu Ihren Clustern Authentifizierungs- und Autorisierungsfehler erhalten, aber mit curl eine Verbindung zum Cluster herstellen konnten, prüfen Sie, ob Sie ohne das gke-gcloud-auth-plugin-Plug-in auf Ihren Cluster zugreifen können.

Um dieses Problem zu beheben, konfigurieren Sie Ihre lokale Umgebung so, dass die Binärdatei gke-gcloud-auth-plugin bei der Authentifizierung am Cluster ignoriert wird. In Kubernetes-Clients mit Version 1.25 und höher ist das Binärprogramm gke-gcloud-auth-plugin erforderlich. Sie müssen also eine Version 1.24 oder früher für das Befehlszeilentool kubectl verwenden.

So greifen Sie ohne das Plug-in auf Ihren Cluster zu:

  1. Installieren Sie das kubectl-Befehlszeilentool mit Version 1.24 oder früher mit curl. Im folgenden Beispiel wird das Tool mit Version 1.24 installiert:

    curl -LO https://dl.k8s.io/release/v1.24.0/bin/linux/amd64/kubectl
    
  2. Öffnen Sie die Shell-Startskriptdatei in einem Texteditor. Öffnen Sie beispielsweise .bashrc für die Bash-Shell:

    vi ~/.bashrc
    

    Wenn Sie macOS verwenden, verwenden Sie in dieser Anleitung ~/.bash_profile anstelle von .bashrc.

  3. Fügen Sie der Startskriptdatei die folgende Zeile hinzu und speichern Sie sie:

    export USE_GKE_GCLOUD_AUTH_PLUGIN=False
    
  4. Führen Sie das Startskript aus:

    source ~/.bashrc
    
  5. Rufen Sie Anmeldedaten für Ihren Cluster ab, wodurch die Datei .kube/config eingerichtet wird:

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

    Ersetzen Sie Folgendes:

  6. Führen Sie einen kubectl-Befehl aus. Beispiel:

    kubectl cluster-info
    

    Wenn Sie nach dem Ausführen dieser Befehle einen 401-Fehler oder einen ähnlichen Autorisierungsfehler erhalten, prüfen Sie, ob Sie die richtigen Berechtigungen haben, und führen Sie den Schritt, der den Fehler zurückgegeben hat, noch einmal aus.

Fehler 400: Knotenpool muss neu erstellt werden

Der folgende Fehler kann auftreten, wenn Sie versuchen, eine Aktion auszuführen, bei der Ihre Steuerungsebene und Knoten neu erstellt werden:

ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.

Dieser Fehler kann beispielsweise auftreten, wenn Sie eine laufende Anmeldedatenrotation abschließen.

Im Backend werden Knotenpools für die Neuerstellung markiert, aber es kann einige Zeit dauern, bis die Neuerstellung tatsächlich beginnt. Daher schlägt der Vorgang fehl, weil GKE noch keinen oder mehrere Knotenpools in Ihrem Cluster neu erstellt hat.

Wählen Sie eine der folgenden Lösungen aus, um dieses Problem zu beheben:

  • Warten Sie, bis die Neuerstellung erfolgt ist. Das kann je nach Faktoren wie vorhandenen Wartungsfenstern und ‑ausschlüssen Stunden, Tage oder Wochen dauern.
  • Starten Sie manuell eine Neuerstellung der betroffenen Knotenpools, indem Sie ein Versionsupgrade auf dieselbe Version wie die Steuerungsebene starten.

    Führen Sie den folgenden Befehl aus, um eine Neuerstellung zu starten:

    gcloud container clusters upgrade CLUSTER_NAME \
        --node-pool=POOL_NAME
    

    Versuchen Sie es nach Abschluss des Upgrades noch einmal.

Fehler 401: Nicht autorisiert

Cluster mit Knotendienstkonten identifizieren, denen wichtige Berechtigungen fehlen

Wenn Sie Cluster mit Knotendienstkonten identifizieren möchten, denen wichtige Berechtigungen fehlen, verwenden Sie GKE-Empfehlungen des NODE_SA_MISSING_PERMISSIONS-Empfehlungssubtyps:

  • Verwenden Sie die Google Cloud Konsole. Rufen Sie die Seite Kubernetes-Cluster auf und suchen Sie in der Spalte Benachrichtigungen nach der Empfehlung Kritische Berechtigungen erteilen für bestimmte Cluster.
  • Verwenden Sie die gcloud CLI oder die Recommender API und geben Sie den Recommender-Untertyp NODE_SA_MISSING_PERMISSIONS an.

    Führen Sie den folgenden Befehl aus, um Empfehlungen abzufragen:

    gcloud recommender recommendations list \
        --recommender=google.container.DiagnosisRecommender \
        --location LOCATION \
        --project PROJECT_ID \
        --format yaml \
        --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"
    

Es kann bis zu 24 Stunden dauern, bis die Empfehlung angezeigt wird. Eine ausführliche Anleitung finden Sie unter Insights und Empfehlungen ansehen.

Weisen Sie dem Dienstkonto des Knotens die Rolle roles/container.defaultNodeServiceAccount zu, um diese Empfehlung umzusetzen.

Sie können ein Skript ausführen, das in den Standard- und Autopilot-Clustern Ihres Projekts nach Knotendienstkonten sucht, die nicht die erforderlichen Berechtigungen für GKE haben. In diesem Skript werden die gcloud CLI und das jq-Dienstprogramm verwendet. Wenn Sie das Skript aufrufen möchten, maximieren Sie den folgenden Abschnitt:

Skript ansehen

#!/bin/bash

# Set your project ID
project_id=PROJECT_ID
project_number=$(gcloud projects describe "$project_id" --format="value(projectNumber)")
declare -a all_service_accounts
declare -a sa_missing_permissions

# Function to check if a service account has a specific permission
# $1: project_id
# $2: service_account
# $3: permission
service_account_has_permission() {
  local project_id="$1"
  local service_account="$2"
  local permission="$3"

  local roles=$(gcloud projects get-iam-policy "$project_id" \
          --flatten="bindings[].members" \
          --format="table[no-heading](bindings.role)" \
          --filter="bindings.members:\"$service_account\"")

  for role in $roles; do
    if role_has_permission "$role" "$permission"; then
      echo "Yes" # Has permission
      return
    fi
  done

  echo "No" # Does not have permission
}

# Function to check if a role has the specific permission
# $1: role
# $2: permission
role_has_permission() {
  local role="$1"
  local permission="$2"
  gcloud iam roles describe "$role" --format="json" | \
  jq -r ".includedPermissions" | \
  grep -q "$permission"
}

# Function to add $1 into the service account array all_service_accounts
# $1: service account
add_service_account() {
  local service_account="$1"
  all_service_accounts+=( ${service_account} )
}

# Function to add service accounts into the global array all_service_accounts for a Standard GKE cluster
# $1: project_id
# $2: location
# $3: cluster_name
add_service_accounts_for_standard() {
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"

  while read nodepool; do
    nodepool_name=$(echo "$nodepool" | awk '{print $1}')
    if [[ "$nodepool_name" == "" ]]; then
      # skip the empty line which is from running `gcloud container node-pools list` in GCP console
      continue
    fi
    while read nodepool_details; do
      service_account=$(echo "$nodepool_details" | awk '{print $1}')

      if [[ "$service_account" == "default" ]]; then
        service_account="${project_number}-compute@developer.gserviceaccount.com"
      fi
      if [[ -n "$service_account" ]]; then
        printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" $service_account $project_id  $cluster_name $cluster_location $nodepool_name
        add_service_account "${service_account}"
      else
        echo "cannot find service account for node pool $project_id\t$cluster_name\t$cluster_location\t$nodepool_details"
      fi
    done <<< "$(gcloud container node-pools describe "$nodepool_name" --cluster "$cluster_name" --zone "$cluster_location" --project "$project_id" --format="table[no-heading](config.serviceAccount)")"
  done <<< "$(gcloud container node-pools list --cluster "$cluster_name" --zone "$cluster_location" --project "$project_id" --format="table[no-heading](name)")"

}

# Function to add service accounts into the global array all_service_accounts for an Autopilot GKE cluster
# Autopilot cluster only has one node service account.
# $1: project_id
# $2: location
# $3: cluster_name
add_service_account_for_autopilot(){
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"

  while read service_account; do
      if [[ "$service_account" == "default" ]]; then
        service_account="${project_number}-compute@developer.gserviceaccount.com"
      fi
      if [[ -n "$service_account" ]]; then
        printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" $service_account $project_id  $cluster_name $cluster_location $nodepool_name
        add_service_account "${service_account}"
      else
        echo "cannot find service account" for cluster  "$project_id\t$cluster_name\t$cluster_location\t"
      fi
  done <<< "$(gcloud container clusters describe "$cluster_name" --location "$cluster_location" --project "$project_id" --format="table[no-heading](autoscaling.autoprovisioningNodePoolDefaults.serviceAccount)")"
}


# Function to check whether the cluster is an Autopilot cluster or not
# $1: project_id
# $2: location
# $3: cluster_name
is_autopilot_cluster() {
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"
  autopilot=$(gcloud container clusters describe "$cluster_name" --location "$cluster_location" --format="table[no-heading](autopilot.enabled)")
  echo "$autopilot"
}


echo "--- 1. List all service accounts in all GKE node pools"
printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" "service_account" "project_id" "cluster_name" "cluster_location" "nodepool_name"
while read cluster; do
  cluster_name=$(echo "$cluster" | awk '{print $1}')
  cluster_location=$(echo "$cluster" | awk '{print $2}')
  # how to find a cluster is a Standard cluster or an Autopilot cluster
  autopilot=$(is_autopilot_cluster "$project_id" "$cluster_location" "$cluster_name")
  if [[ "$autopilot" == "True" ]]; then
    add_service_account_for_autopilot "$project_id" "$cluster_location"  "$cluster_name"
  else
    add_service_accounts_for_standard "$project_id" "$cluster_location"  "$cluster_name"
  fi
done <<< "$(gcloud container clusters list --project "$project_id" --format="value(name,location)")"

echo "--- 2. Check if service accounts have permissions"
unique_service_accounts=($(echo "${all_service_accounts[@]}" | tr ' ' '\n' | sort -u | tr '\n' ' '))

echo "Service accounts: ${unique_service_accounts[@]}"
printf "%-60s| %-40s| %-40s| %-20s\n" "service_account" "has_logging_permission" "has_monitoring_permission" "has_performance_hpa_metric_write_permission"
for sa in "${unique_service_accounts[@]}"; do
  logging_permission=$(service_account_has_permission "$project_id" "$sa" "logging.logEntries.create")
  time_series_create_permission=$(service_account_has_permission "$project_id" "$sa" "monitoring.timeSeries.create")
  metric_descriptors_create_permission=$(service_account_has_permission "$project_id" "$sa" "monitoring.metricDescriptors.create")
  if [[ "$time_series_create_permission" == "No" || "$metric_descriptors_create_permission" == "No" ]]; then
    monitoring_permission="No"
  else
    monitoring_permission="Yes"
  fi
  performance_hpa_metric_write_permission=$(service_account_has_permission "$project_id" "$sa" "autoscaling.sites.writeMetrics")
  printf "%-60s| %-40s| %-40s| %-20s\n" $sa $logging_permission $monitoring_permission $performance_hpa_metric_write_permission

  if [[ "$logging_permission" == "No" || "$monitoring_permission" == "No" || "$performance_hpa_metric_write_permission" == "No" ]]; then
    sa_missing_permissions+=( ${sa} )
  fi
done

echo "--- 3. List all service accounts that don't have the above permissions"
if [[ "${#sa_missing_permissions[@]}" -gt 0 ]]; then
  printf "Grant roles/container.defaultNodeServiceAccount to the following service accounts: %s\n" "${sa_missing_permissions[@]}"
else
  echo "All service accounts have the above permissions"
fi

Knotendienstkonten in einem Cluster identifizieren, denen wichtige Berechtigungen fehlen

GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knoten-Dienstkonten müssen in Ihrem Projekt mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) haben. Standardmäßig verwendet GKE das Compute Engine-Standarddienstkonto, das automatisch in Ihrem Projekt erstellt wird, als Knotendienstkonto.

Wenn Ihre Organisation die Einschränkung der Organisationsrichtlinie iam.automaticIamGrantsForDefaultServiceAccounts erzwingt, erhält das Compute Engine-Standarddienstkonto in Ihrem Projekt möglicherweise nicht automatisch die erforderlichen Berechtigungen für GKE.

  1. So finden Sie den Namen des Dienstkontos, das von Ihren Knoten verwendet wird:

    Console

    1. Zur Seite Kubernetes-Cluster

      Zur Seite "Kubernetes-Cluster"

    2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie untersuchen möchten.
    3. Führen Sie je nach Clustermodus einen der folgenden Schritte aus:
      • Suchen Sie bei Clustern im Autopilot-Modus im Abschnitt Sicherheit nach dem Feld Dienstkonto.
      • Gehen Sie für Cluster im Standardmodus so vor:
        1. Klicken Sie auf den Tab Knoten.
        2. Klicken Sie in der Tabelle Knotenpools auf einen Knotenpoolnamen. Die Seite Knotenpooldetails wird geöffnet.
        3. Suchen Sie im Abschnitt Sicherheit nach dem Feld Dienstkonto.

    Wenn der Wert im Feld Dienstkonto default ist, verwenden Ihre Knoten das Compute Engine-Standarddienstkonto. Wenn der Wert in diesem Feld nicht default ist, verwenden Ihre Knoten ein benutzerdefiniertes Dienstkonto. Informationen zum Zuweisen der erforderlichen Rolle zu einem benutzerdefinierten Dienstkonto finden Sie unter IAM-Dienstkonten mit geringsten Berechtigungen verwenden.

    gcloud

    Führen Sie für Cluster im Autopilot-Modus den folgenden Befehl aus:

    gcloud container clusters describe CLUSTER_NAME \
        --location=LOCATION \
        --flatten=autoscaling.autoprovisioningNodePoolDefaults.serviceAccount

    Führen Sie für Cluster im Standardmodus den folgenden Befehl aus:

    gcloud container clusters describe CLUSTER_NAME \
        --location=LOCATION \
        --format="table(nodePools.name,nodePools.config.serviceAccount)"

    Wenn die Ausgabe default ist, verwenden Ihre Knoten das Compute Engine-Standarddienstkonto. Wenn die Ausgabe nicht default ist, verwenden Ihre Knoten ein benutzerdefiniertes Dienstkonto. Informationen zum Zuweisen der erforderlichen Rolle zu einem benutzerdefinierten Dienstkonto finden Sie unter IAM-Dienstkonten mit geringsten Berechtigungen verwenden.

  2. So weisen Sie dem Compute Engine-Standarddienstkonto die Rolle roles/container.defaultNodeServiceAccount zu:

    Console

    1. Rufen Sie die Seite Willkommen auf:

      Zur Begrüßungsseite

    2. Klicken Sie im Feld Projektnummer auf  In die Zwischenablage kopieren.
    3. Rufen Sie die IAM-Seite auf.

      IAM aufrufen

    4. Klicken Sie auf Zugriff erlauben.
    5. Geben Sie im Feld Neue Hauptkonten den folgenden Wert an:
      PROJECT_NUMBER-compute@developer.gserviceaccount.com
      Ersetzen Sie PROJECT_NUMBER durch die kopierte Projektnummer.
    6. Wählen Sie im Menü Rolle auswählen die Rolle Kubernetes Engine Default Node Service Account aus.
    7. Klicken Sie auf Speichern.

    gcloud

    1. So finden Sie Ihre Google Cloud Projektnummer:
      gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)"

      Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

      Die Ausgabe sieht etwa so aus:

      12345678901
      
    2. Weisen Sie dem Compute Engine-Standarddienstkonto die Rolle roles/container.defaultNodeServiceAccount zu:
      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
          --role="roles/container.defaultNodeServiceAccount"

      Ersetzen Sie PROJECT_NUMBER durch die Projektnummer aus dem vorherigen Schritt.

Fehler 403: Unzureichende Berechtigungen

Der folgende Fehler tritt auf, wenn Sie versuchen, mit gcloud container clusters get-credentials eine Verbindung zu einem GKE-Cluster herzustellen, das Konto aber keine Berechtigung für den Zugriff auf den Kubernetes API-Server hat:

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Required "container.clusters.get" permission(s) for "projects/<your-project>/locations/<region>/clusters/<your-cluster>".

So beheben Sie das Problem:

  1. Ermitteln Sie das Konto, bei dem das Zugriffsproblem auftritt:

    gcloud auth list
    
  2. Gewähren Sie dem Konto den erforderlichen Zugriff gemäß der Anleitung unter Authentifizierung beim Kubernetes API-Server.

Fehler 403: Budget für Wiederholungsversuche aufgebraucht

Der folgende Fehler kann auftreten, wenn Sie versuchen, einen GKE-Cluster zu erstellen:

Error: googleapi: Error 403: Retry budget exhausted: Google Compute Engine:
Required permission 'PERMISSION_NAME' for 'RESOURCE_NAME'.

In dieser Fehlermeldung gelten die folgenden Variablen:

  • PERMISSION_NAME: Der Name einer Berechtigung, z. B. compute.regions.get.
  • RESOURCE_NAME: Der Pfad zur Google Cloud-Ressource, auf die Sie zugreifen wollten, z. B. eine Compute Engine-Region.

Dieser Fehler tritt auf, wenn das dem Cluster zugeordnete IAM-Dienstkonto nicht die erforderlichen Mindestberechtigungen zum Erstellen des Clusters hat.

So beheben Sie das Problem:

  1. Erstellen oder ändern Sie ein IAM-Dienstkonto, damit es alle erforderlichen Berechtigungen zum Ausführen eines GKE-Cluster hat. Eine Anleitung finden Sie unter IAM-Dienstkonten mit geringsten Berechtigungen verwenden.
  2. Geben Sie das aktualisierte IAM-Dienstkonto in Ihrem Befehl zum Erstellen des Clusters mit dem Flag --service-account an. Eine Anleitung finden Sie unter Autopilot-Cluster erstellen.

Alternativ können Sie das Flag --service-account weglassen, damit GKE das Compute Engine-Standarddienstkonto im Projekt verwendet, das standardmäßig die erforderlichen Berechtigungen hat.

Fehler 404: Ressource nicht gefunden

Wenn beim Aufrufen von gcloud container-Befehlen der Fehler 404 (Ressource nicht gefunden) angezeigt wird, beheben Sie das Problem, indem Sie sich noch einmal in der Google Cloud CLI authentifizieren:

gcloud auth login

Fehler 400/403: Dem Konto fehlen Bearbeitungsberechtigungen

Ein Fehler vom Typ „Dem Konto fehlen Bearbeitungsberechtigungen“ (Fehler 400 oder 403) weist darauf hin, dass eines der folgenden Elemente manuell gelöscht oder bearbeitet wurde:

Wenn Sie die Compute Engine API oder die GKE API aktivieren, Google Cloudwerden die folgenden Dienstkonten und Agents erstellt:

  • Compute Engine-Standarddienstkonto in Ihrem Projekt. GKE hängt dieses Dienstkonto standardmäßig an Knoten an, um Systemaufgaben wie Logging und Monitoring auszuführen.
  • Google APIs Service Agent in einem von Google verwalteten Projekt mit Bearbeitungsberechtigungen für Ihr Projekt.
  • Google Kubernetes Engine-Dienst-Agent in einem von Google verwalteten Projekt mit der Rolle Kubernetes Engine-Dienst-Agent für Ihr Projekt.

Das Erstellen von Clustern und die gesamte Verwaltung schlagen fehl, wenn jemand diese Berechtigungen bearbeitet, die Rollenbindungen für das Projekt entfernt, das Dienstkonto vollständig entfernt oder die API deaktiviert.

Berechtigungen für den GKE-Dienst-Agent prüfen

So prüfen Sie, ob dem Google Kubernetes Engine-Dienstkonto die Rolle Kubernetes Engine-Dienst-Agent für das Projekt zugewiesen ist:

  1. Ermitteln Sie den Namen Ihres Google Kubernetes Engine-Dienstkontos. Alle Dienstkonten haben das folgende Format:

    service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
    

    Ersetzen Sie PROJECT_NUMBER mit Ihrer Projekt-ID.

  2. Prüfen Sie, ob Ihrem Google Kubernetes Engine-Dienstkonto im Projekt die Rolle Kubernetes Engine-Dienst-Agent zugewiesen ist:

    gcloud projects get-iam-policy PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Falls jemand die Rolle Kubernetes Engine-Dienst-Agent aus Ihrem Google Kubernetes Engine-Dienstkonto entfernt hat, fügen Sie sie wieder hinzu, um das Problem zu beheben. Andernfalls folgen Sie der Anleitung unten, um die Kubernetes Engine API wieder zu aktivieren. Dadurch werden Ihre Dienstkonten und Berechtigungen wiederhergestellt:

Console

  1. Rufen Sie in der Google Cloud Console die Seite APIs & Dienste auf.

    Rufen Sie "APIs & Dienste" auf.

  2. Wählen Sie Ihr Projekt aus.

  3. Klicken Sie auf APIs und Dienste aktivieren.

  4. Suchen Sie "Kubernetes" und wählen Sie anschließend in den Suchergebnissen die API aus.

  5. Klicken Sie auf Aktivieren. Wenn Sie die API bereits aktiviert hatten, deaktivieren Sie sie und aktivieren Sie sie dann noch einmal. Es kann einige Minuten dauern, bis die API und zugehörige Dienste aktiviert werden.

gcloud

Führen Sie die folgenden Befehle in der gcloud CLI aus:

PROJECT_NUMBER=$(gcloud projects describe "PROJECT_ID"
    --format 'get(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:service-${PROJECT_NUMBER?}@container-engine-robot.iam.gserviceaccount.com" \
    --role roles/container.serviceAgent

Nächste Schritte