Diese Dokumentation bezieht sich auf die aktuelle Version von GKE on AWS, die im November 2021 veröffentlicht wurde. Weitere Informationen finden Sie in den Versionshinweisen.

Fehlerbehebung für Anthos-Cluster in AWS

Führen Sie diese Schritte zur Fehlerbehebung aus, wenn Sie Probleme beim Erstellen oder Verwenden von Anthos-Cluster in AWS haben.

Clustererstellung ist nicht erfolgreich

Wenn Sie eine Anfrage zum Erstellen eines Clusters senden, führt Anthos Clusters on AWS zuerst eine Reihe von Preflight-Tests aus, um die Anfrage zu prüfen. Ist die Clustererstellung nicht erfolgreich, kann dies daran liegen, dass einer dieser Preflight-Tests fehlgeschlagen ist oder ein Schritt im Clustererstellungsprozess nicht abgeschlossen wurde.

Wenn ein Preflight-Test fehlschlägt, erstellt Ihr Cluster keine Ressourcen und gibt direkt Informationen zum Fehler zurück. Wenn Sie beispielsweise versuchen, einen Cluster mit dem Namen invalid%%%name zu erstellen, schlägt der Preflight-Test für einen gültigen Clusternamen fehl und die Anfrage gibt folgenden Fehler zurück:

ERROR: (gcloud.container.aws.clusters.create) INVALID_ARGUMENT: must be
between 1-63 characters, valid characters are /[a-z][0-9]-/, should start with a
letter, and end with a letter or a number: "invalid%%%name",
field: aws_cluster_id

Die Clustererstellung kann auch fehlschlagen, nachdem die Preflight-Tests bestanden wurden. Dies kann einige Minuten nach Beginn der Clustererstellung geschehen, nachdem Anthos-Cluster in AWS Ressourcen in Google Cloud und AWS erstellt hat. In diesem Fall ist in Ihrem Google Cloud-Projekt eine AWS-Ressource mit dem Status ERROR vorhanden.

Führen Sie folgenden Befehl aus, um Details zum Fehler abzurufen:

gcloud container aws clusters describe CLUSTER_NAME \
  --location GOOGLE_CLOUD_LOCATION \
  --format "value(state, errors)"

Ersetzen Sie:

CLUSTER_NAME durch den Namen des Clusters, dessen Status Sie abfragen
GOOGLE_CLOUD_LOCATION durch den Namen der Google Cloud-Region, die diesen AWS-Cluster verwaltet

Alternativ können Sie Details zum Fehler bei der Erstellung abrufen. Beschreiben Sie dafür die Ressource Operation, die dem Aufruf der Cluster-API zugeordnet ist.

gcloud container aws operations describe OPERATION_ID

Ersetzen Sie OPERATION_ID durch die ID des Vorgangs, der den Cluster erstellt hat. Wenn Sie die Vorgangs-ID der Anfrage zur Clustererstellung nicht haben, können Sie sie mit dem folgenden Befehl abrufen:

gcloud container aws operations list \
  --location GOOGLE_CLOUD_LOCATION

Verwenden Sie den Zeitstempel oder zugehörige Informationen, um den gewünschten Clustererstellungsvorgang zu identifizieren.

Wenn die Clustererstellung beispielsweise aufgrund einer AWS-IAM-Rolle fehlgeschlagen ist, die nicht über alle erforderlichen Berechtigungen verfügt, sehen dieser Befehl und seine Ergebnisse in etwa so aus:

gcloud container aws operations describe b6a3d042-8c30-4524-9a99-6ffcdc24b370 \
  --location GOOGLE_CLOUD_LOCATION

Die Antwort sieht in etwa so aus:

done: true
error:
  code: 9
  message: 'could not set deregistration_delay timeout for the target group: AccessDenied
    User: arn:aws:sts::0123456789:assumed-role/foo-1p-dev-oneplatform/multicloud-service-agent
    is not authorized to perform: elasticloadbalancing:ModifyTargetGroupAttributes
    on resource: arn:aws:elasticloadbalancing:us-west-2:0123456789:targetgroup/gke-4nrk57tlyjva-cp-tcp443/74b57728e7a3d5b9
    because no identity-based policy allows the elasticloadbalancing:ModifyTargetGroupAttributes
    action'
metadata:
  '@type': type.googleapis.com/google.cloud.gkemulticloud.v1.OperationMetadata
  createTime: '2021-12-02T17:47:31.516995Z'
  endTime: '2021-12-02T18:03:12.590148Z'
  statusDetail: Cluster is being deployed
  target: projects/123456789/locations/us-west1/awsClusters/aws-prod1
name: projects/123456789/locations/us-west1/operations/b6a3d042-8c30-4524-9a99-6ffcdc24b370

Erstellung oder Betrieb eines Clusters schlagen mit einem Autorisierungsfehler fehl

Ein angezeigter Autorisierungsfehler weist in der Regel darauf hin, dass eine der beiden beim Erstellen des Clusters angegebenen AWS-IAM-Rollen falsch erstellt wurde. Wenn die API-Rolle beispielsweise nicht die Berechtigung elasticloadbalancing:ModifyTargetGroupAttributes enthält, schlägt die Erstellung des Clusters mit einer Fehlermeldung fehl, die in etwa so aussieht:

ERROR: (gcloud.container.aws.clusters.create) could not set
deregistration_delay timeout for the target group: AccessDenied User:
arn:aws:sts::0123456789:assumed-role/cloudshell-user-dev-api-role/multicloud-
service-agent is not authorized to perform:
elasticloadbalancing:ModifyTargetGroupAttributes on resource:
arn:aws:elasticloadbalancing:us-east-1:0123456789:targetgroup/gke-u6au6c65e4iq-
cp-tcp443/be4c0f8d872bb60e because no identity-based policy allows the
elasticloadbalancing:ModifyTargetGroupAttributes action

Auch wenn es so wirkt, als wäre ein Cluster erfolgreich erstellt worden, kann eine falsch angegebene IAM-Rolle während des Betriebs des Clusters zu Fehlern führen, z. B. bei Verwendung von Befehlen wie kubectl logs.

Um solche Autorisierungsfehler zu beheben, prüfen Sie die Richtlinien, die Sie den beiden IAM-Rollen bei der Clustererstellung zugeordnet haben. Achten Sie insbesondere darauf, dass sie den Beschreibungen unter AWS-IAM-Rollen erstellen entsprechen. Löschen Sie dann den Cluster und erstellen Sie ihn neu. Die einzelnen Rollenbeschreibungen finden Sie unter API-Rolle und Rolle der Steuerungsebene.

Erstellung oder Betrieb eines Clusters schlagen in der Systemdiagnose fehl

Manchmal schlägt die Clustererstellung während der Systemdiagnose mit einem Vorgangsstatus fehl, der in etwa so aussieht:

done: true
error:
  code: 4
  message: Operation failed
metadata:
  '@type': type.googleapis.com/google.cloud.gkemulticloud.v1.OperationMetadata
  createTime: '2022-06-29T18:26:39.739574Z'
  endTime: '2022-06-29T18:54:45.632136Z'
  errorDetail: Operation failed
  statusDetail: Health-checking cluster
  target: projects/123456789/locations/us-west1/awsClusters/aws-prod1
name: projects/123456789/locations/us-west1/operations/8a7a3b7f-242d-4fff-b518-f361d41c6597

Dies kann daran liegen, dass IAM-Rollen fehlen oder falsch angegeben sind. Sie können AWS CloudTrail verwenden, um IAM-Probleme anzuzeigen.

Beispiel:

Wenn die API-Rolle nicht die Berechtigung kms:GenerateDataKeyWithoutPlaintext für den KMS-Schlüssel des Haupt-Volumes der Steuerungsebene enthielt, werden folgende Ereignisse angezeigt:

"eventName": "AttachVolume",
"errorCode": "Client.InvalidVolume.NotFound",
"errorMessage": "The volume 'vol-0ff75940ce333aebb' does not exist.",

und

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/foo-1p-dev-oneplatform/multicloud-service-agent is not authorized to perform: kms:GenerateDataKeyWithoutPlaintext on resource: arn:aws:kms:us-west1:0123456789:key/57a61a45-d9c1-4038-9021-8eb08ba339ba because no identity-based policy allows the kms:GenerateDataKeyWithoutPlaintext action",

Wenn die Rolle der Steuerungsebene nicht die Berechtigung kms:CreateGrant für den KMS-Schlüssel des Haupt-Volumes enthielt, werden folgende Ereignisse angezeigt:

"eventName": "AttachVolume",
"errorCode": "Client.CustomerKeyHasBeenRevoked",
"errorMessage": "Volume vol-0d022beb769c8e33b cannot be attached. The encrypted volume was unable to access the KMS key.",

und

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/foo-controlplane/i-0a11fae03eb0b08c1 is not authorized to perform: kms:CreateGrant on resource: arn:aws:kms:us-west1:0123456789:key/57a61a45-d9c1-4038-9021-8eb08ba339ba because no identity-based policy allows the kms:CreateGrant action",

Wenn Sie die mit dem Dienst verknüpfte Rolle namens AWSServiceRoleForAutoScaling mit der Berechtigung kms:CreateGrant zur Verwendung des KMS-Schlüssels des Root-Volumes der Steuerungsebene nicht zugewiesen haben, werden folgende Ereignisse angezeigt:

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/AWSServiceRoleForAutoScaling/AutoScaling is not authorized to perform: kms:CreateGrant on resource: arn:aws:kms:us-west1:0123456789:key/c77a3a26-bc91-4434-bac0-0aa963cb0c31 because no identity-based policy allows the kms:CreateGrant action",

Wenn Sie die mit dem Dienst verknüpfte Rolle namens AWSServiceRoleForAutoScaling mit der Berechtigung kms:GenerateDataKeyWithoutPlaintext zur Verwendung des KMS-Schlüssels des Root-Volumes der Steuerungsebene nicht zugewiesen haben, werden folgende Ereignisse angezeigt:

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::0123456789:assumed-role/AWSServiceRoleForAutoScaling/AutoScaling is not authorized to perform: kms:GenerateDataKeyWithoutPlaintext on resource: arn:aws:kms:us-west1:0123456789:key/c77a3a26-bc91-4434-bac0-0aa963cb0c31 because no identity-based policy allows the kms:CreateGrant action",

Warten, bis Knoten dem Cluster hinzugefügt werden

Wenn beim Erstellen eines Knotenpools der folgende Fehler angezeigt wird, prüfen Sie, dass Ihre VPC keinen verknüpften sekundären IPv4-CIDR-Block enthält.

errorDetail: Operation failed
statusDetail: Waiting for nodes to join the cluster (0 out of 1 are ready)

Erstellen Sie zur Behebung dieses Problems eine Sicherheitsgruppe, die alle CIDR-Blöcke enthält, und fügen Sie diese Gruppe Ihrem Cluster hinzu. Weitere Informationen finden Sie unter Knotenpools in sekundären CIDR-Blöcken von VPC.

Systemlog einer Instanz abrufen

Wenn eine Steuerungsebene oder Knotenpoolinstanz nicht gestartet wird, können Sie ihr Systemlog überprüfen. So prüfen Sie das Systemlog:

Öffnen Sie die Konsole der AWS EC2-Instanz.
Klicken Sie auf Instanzen.
Suchen Sie die Instanz anhand des Namens. Anthos-Cluster in AWS erstellen in der Regel Instanzen mit dem Namen CLUSTER-NAME-cp für Steuerungsebenenknoten oder CLUSTER-NAME-np für Knotenpools.
Wählen Sie Aktionen -> Monitoring und Fehlerbehebung -> Systemlog abrufen aus. Das Systemlog der Instanz wird angezeigt.

Fehler beim Aktualisieren des Clusters

Wenn Sie einen Cluster aktualisieren, führt Anthos on AWS zuerst genau wie beim Erstellen eines neuen Clusters eine Reihe von Preflight-Tests aus, um die Anfrage zu prüfen. Wenn die Clusteraktualisierung fehlschlägt, kann das daran liegen, dass einer dieser Preflight-Tests fehlgeschlagen ist oder ein Schritt im Clusteraktualisierungsprozess selbst nicht abgeschlossen wurde.

Wenn ein Preflight-Test fehlschlägt, aktualisiert Ihr Cluster keine Ressourcen und gibt Informationen zum Fehler direkt an Sie zurück. Wenn Sie beispielsweise versuchen, einen Cluster so zu aktualisieren, dass ein SSH-Schlüsselpaar mit dem Namen test_ec2_keypair verwendet wird, versucht der Preflight-Test, das EC2-Schlüsselpaar abzurufen und schlägt fehl und die Anfrage gibt den folgenden Fehler zurück:

ERROR: (gcloud.container.aws.clusters.update) INVALID_ARGUMENT: key pair
"test_ec2_keypair" not found,
field: aws_cluster.control_plane.ssh_config.ec2_key_pair

Clusteraktualisierungen können auch fehlschlagen, nachdem die Preflight-Tests bestanden wurden. Dies kann einige Minuten nach Beginn der Clusteraktualisierung geschehen und der Status Ihrer AWS-Ressource in Ihrem Google Cloud-Projekt wird auf DEGRADED gesetzt.

Folgen Sie den Schritten unter Fehler beim Erstellen von Clustern, um Details zum Fehler und zum zugehörigen Vorgang zu erhalten.

Clusteraktualisierung schlägt beim Aktualisieren von Tags der Steuerungsebene fehl

Die AWS Update API unterstützt jetzt die Aktualisierung von Tags auf Steuerungsebene. Zum Aktualisieren von Tags benötigen Sie einen Cluster mit Kubernetes Version 1.24 oder höher. Ihre AWS-IAM-Rolle muss außerdem die entsprechenden Berechtigungen haben, die auf der Seite Cluster aktualisieren zum Aktualisieren von Tags der Steuerungsebene aufgeführt sind.

Ein Fehler, der einen Authentifizierungsfehler wie unten zeigt, ist normalerweise ein Hinweis darauf, dass Sie eine IAM-Berechtigung nicht hinzugefügt haben. Wenn die API-Rolle beispielsweise die Berechtigung ec2:DeleteTags nicht enthält, kann die Clusteraktualisierung für Tags mit einer Fehlermeldung fehlschlagen, die in etwa so aussieht (die <encoded_auth_failure_message> wird der Kürze halber entfernt):

ERROR: (gcloud.container.aws.clusters.update) could not delete tags:
UnauthorizedOperation You are not authorized to perform this operation.
Encoded authorization failure message: <encoded_auth_failure_message>

Zum Debuggen der oben codierten Fehlermeldung können Sie wie unten beschrieben eine Anfrage an die AWS STS-API decode-authorization-message senden:

aws sts decode-authorization-message --encoded-message
<encoded_auth_failure_message> --query DecodedMessage --output
text | jq '.' | less

Die Ausgabe sieht in etwa so aus:

...
"principal": {
  "id": "AROAXMEL2SCNPG6RCJ72B:iam-session",
  "arn": "arn:aws:sts::1234567890:assumed-role/iam_role/iam-session"
},
"action": "ec2:DeleteTags",
"resource": "arn:aws:ec2:us-west-2:1234567890:security-group-rule/sgr-00bdbaef24a92df62",
...

Die obige Antwort gibt an, dass Sie die Aktion ec2:DeleteTags für die EC2-Sicherheitsgruppenregelressource des AWS-Clusters nicht ausführen konnten. Aktualisieren Sie Ihre API-Rolle entsprechend und senden Sie die Update API-Anfrage noch einmal, um die Tags der Steuerungsebene zu aktualisieren.

Keine Verbindung zum Cluster mit kubectl möglich

Dieser Abschnitt enthält einige Hinweise zum Diagnostizieren von Problemen beim Herstellen einer Verbindung zu Ihrem Cluster mit dem kubectl-Befehlszeilentool.

Server hat keine Ressource

Fehler wie error: the server doesn't have a resource type "services" können auftreten, wenn ein Cluster keine laufenden Knotenpools hat oder das Connect Gateway keine Verbindung zu einem Knotenpool herstellen kann. Zum Prüfen des Status Ihrer Knotenpools führen Sie folgenden Befehl aus:

gcloud container aws node-pools list \
    --cluster-name CLUSTER_NAME \
    --location LOCATION

Dabei gilt:

CLUSTER_NAME: der Name des Clusters
LOCATION: der Google Cloud-Standort, der Ihren Cluster verwaltet

Die Ausgabe enthält die Namen der Knotenpools Ihres Clusters. Erstellen Sie einen Knotenpool, wenn kein Knotenpool aufgeführt ist.

Fehlerbehebung für Connect-Gateway

Der folgende Fehler tritt auf, wenn Ihr Nutzername keinen Administratorzugriff auf Ihren Cluster hat:

Error from server (Forbidden): users "administrator@example.com" is forbidden:
User "system:serviceaccount:gke-connect:connect-agent-sa" cannot impersonate
resource "users" in API group "" at the cluster scope

Sie können zusätzliche Nutzer konfigurieren, indem Sie beim Erstellen eines Clusters das Flag --admin-users übergeben.

Wenn Sie ein Connect Gateway verwenden und keine Verbindung zu Ihrem Cluster herstellen können, gehen Sie so vor:

Rufen Sie die autorisierten Nutzer für Ihren Cluster ab.
```
gcloud container aws clusters describe CLUSTER_NAME \
  --format 'value(authorization.admin_users)'
```
Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Die Ausgabe enthält die Nutzernamen mit Administratorzugriff auf den Cluster. Beispiel:
```
{'username': 'administrator@example.com'}
```
Rufen Sie den Nutzernamen ab, der derzeit bei der Google Cloud CLI authentifiziert ist.
```
gcloud config get-value account
```
Die Ausgabe enthält das Konto, das mit der Google Cloud CLI authentifiziert wurde. Wenn die Ausgabe von gcloud containers aws clusters describe und gcloud config get-value account nicht übereinstimmt, führen Sie gcloud auth login aus und authentifizieren Sie sich als Nutzername mit Administratorzugriff auf den Cluster.

kubectl-Befehl reagiert nicht mehr

Wenn der kubectl-Befehl nicht reagiert oder das Zeitlimit überschreitet, ist dies häufig darauf zurückzuführen, dass Sie noch keinen Knotenpool erstellt haben. Standardmäßig generiert Anthos-Cluster in AWS kubeconfig-Dateien, die ein Connect-Gateway als über das Internet erreichbaren Endpunkt verwenden. Damit dies funktioniert, muss das gke-connect-agent-Deployment in einem Knotenpool im Cluster ausgeführt werden.

Führen Sie folgenden Befehl aus, um weitere Diagnoseinformationen abzurufen:

kubectl cluster-info -v=9

Sind keine laufenden Knotenpools vorhanden, schlagen Anfragen an connectgateway.googleapis.com mit dem 404-cannot find active connections for cluster-Fehler fehl.

Befehle „kubectl exec“, „kubectl attach“ und „kubectl port-forward“ schlagen fehl

Die Befehle kubectl exec, kubectl attach und kubectl port-forward können bei der Verwendung eines Connect-Gateways mit der Meldung error: unable to upgrade connection fehlschlagen. Dies ist eine Einschränkung, wenn das Connect-Gateway als Kubernetes API-Server-Endpunkt verwendet wird.

Verwenden Sie zur Umgehung dieses Problems eine kubeconfig, die den privaten Endpunkt des Clusters angibt. Eine Anleitung zum Zugriff auf den Cluster über seinen privaten Endpunkt finden Sie unter Clusterzugriff für kubectl konfigurieren.

`kubectl logs` schlägt mit `remote error: tls: internal error` fehl

Das kann passieren, wenn der API-Rolle der Steuerungsebene eine Berechtigung fehlt. Das kann zum Beispiel passieren, wenn Ihrer AWS-Rolle die Berechtigung ec2:DescribeDhcpOptions fehlt. In diesem Fall können Anfragen zur Zertifikatsignierung von Knoten nicht genehmigt werden und dem Worker-Knoten fehlt ein gültiges Zertifikat.

Um festzustellen, ob dies das Problem ist, können Sie prüfen, ob ausstehende Anfragen zur Zertifikatsignierung vorhanden sind, die mit diesem Befehl nicht genehmigt wurden:

kubectl get csr

Um dieses Problem zu beheben, prüfen Sie, ob Ihre AWS-Rolle den Anforderungen in der Dokumentation entspricht.

Generische kubectl-Fehlerbehebung

Wenn Sie das Connect-Gateway verwenden:

Prüfen Sie, ob das Connect-Gateway in Ihrem Google Cloud-Projekt aktiviert ist:
```
gcloud services enable connectgateway.googleapis.com
```
Prüfen Sie, ob mindestens ein Linux-Knotenpool ausgeführt wird.
Prüfen Sie, ob der gke-connect-agent ausgeführt wird. Weitere Informationen finden Sie unter Fehlerbehebung für Connect.

Kubernetes-Service (LoadBalancer) oder Kubernetes-Ingress funktioniert nicht

Wenn Ihre AWS Elastic Load Balancer (ELB/NLB/ALB) erstellt wurden, aber nicht wie erwartet funktionieren, kann dies an Problemen mit dem Subnetz-Tagging liegen. Weitere Informationen finden Sie unter Load-Balancer-Subnetze.

API-Fehler

Mit Kubernetes 1.22 werden mehrere APIs verworfen und ersetzt. Wenn Sie Ihren Cluster auf Version 1.22 oder höher aktualisiert haben, schlagen alle Aufrufe Ihrer Anwendung an eine der verworfenen APIs fehl.

Lösung

Führen Sie ein Upgrade Ihrer Anwendung durch, um Aufrufe von verworfenen APIs durch Aufrufe der neueren Gegenstücke zu ersetzen.

Cluster kann nicht gelöscht werden

FAILED_PRECONDITION: Rolle konnte nicht angenommen werden

Wenn ein Fehler wie der folgende angezeigt wird, ist Ihre Anthos Multi-Cloud API-Rolle möglicherweise nicht vorhanden:

ERROR: (gcloud.container.aws.clusters.delete) FAILED_PRECONDITION: Could not
assume role
"arn:aws:iam::ACCOUNT_NUMBER:role/gke123456-anthos-api-role"
through service account
"service-123456789@gcp-sa-gkemulticloud.iam.gserviceaccount.com".
Please make sure the role has a trust policy allowing the GCP service agent to
assume it: WebIdentityErr failed to retrieve credentials

Folgen Sie der Anleitung unter Rolle „Anthos Multi-Cloud API erstellen”, um das Problem zu beheben. Wenn Sie die Rolle mit demselben Namen und denselben Berechtigungen neu erstellen, können Sie den Befehl noch einmal ausführen.

Fehlerbehebung bei Arm-Arbeitslasten

Pods auf Arm-Knoten stürzen ab

Das folgende Problem tritt auf, wenn Sie einen Pod auf einem Arm-Knoten bereitstellen, das Container-Image jedoch nicht für die Arm-Architektur erstellt wird.

Führen Sie die folgenden Aufgaben aus, um das Problem zu identifizieren:

Rufen Sie den Status der Pods ab:
```
kubectl get pods
```
Rufen Sie die Logs für den abstürzenden Pod ab:
```
kubectl logs POD_NAME
```
Ersetzen Sie POD_NAME durch den Namen des abstürzenden Pods.

Die Fehlermeldung in Ihren Pod-Logs sieht in etwa so aus:
```
exec ./hello-app: exec format error
```

Achten Sie zur Behebung dieses Problems darauf, dass Ihr Container-Image die Arm-Architektur unterstützt. Es hat sich bewährt, mehrere Architektur-Images zu erstellen.

In der UI wurde ein Fehler für nicht erreichbare Cluster erkannt

Einige UI-Oberflächen in der Google Cloud Console haben ein Problem beim Herstellen einer Verbindung zu den Clustern der Version 1.25.5-gke.1500 und 1.25.4-gke.1300. Insbesondere die Clusterliste für Anthos Service Mesh.

Dieses Problem führt zu einer Warnung, dass der Cluster nicht erreichbar ist, obwohl er sich über andere Seiten anmelden und damit interagieren kann.

Dies war eine Regression aufgrund der Entfernung von gateway-impersonate ClusterRoleBinding in diesen beiden Clusterversionen.

Sie können das Problem umgehen, indem Sie die erforderlichen Berechtigungen mit diesem YAML-Code manuell hinzufügen:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: connect-agent-impersonate-admin-users
rules:
- apiGroups:
  - ""
  resourceNames:
  - ADMIN_USER1
  - ADMIN_USER2
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: connect-agent-impersonate-admin-users
roleRef:
  kind: ClusterRole
  name: connect-agent-impersonate-admin-users
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect

Ersetzen Sie ADMIN_USER1 und ADMIN_USER2 durch die Administratorkonten Ihrer Cluster (E-Mail-Adressen). In diesem Beispiel haben nur zwei Administratoren zwei Administratoren.

So rufen Sie die Liste der für den Cluster konfigurierten Administratornutzer auf:

gcloud container aws clusters describe CLUSTER_NAME \
  --location GOOGLE_CLOUD_LOCATION \
  --format "value(authorization.adminUsers)"

ClusterRole wird beim Upgrade auf eine neuere Clusterversion automatisch überschrieben.