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

Fehlerbehebung für Anthos-Cluster in Azure

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

Clustererstellung ist nicht erfolgreich

Wenn Sie eine Anfrage zum Erstellen eines Clusters senden, führt Anthos-Cluster in Azure 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.azure.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: azure_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 Azure Ressourcen in Google Cloud und Azure erstellt habt. In diesem Fall ist in Ihrem Google Cloud-Projekt eine Azure-Ressource mit dem Status ERROR vorhanden.

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

gcloud container azure 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 Azure-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 azure 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 azure operations list \
  --location GOOGLE_CLOUD_LOCATION

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

Fehler beim Aktualisieren des Clusters

Wenn Sie einen Cluster aktualisieren, führt Anthos on Azure 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.azure.clusters.update) INVALID_ARGUMENT: key pair
"test_ec2_keypair" not found,
field: azure_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 Azure-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.

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 azure 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 azure 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 azure 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 Azure 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.

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.

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.

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 azure clusters describe CLUSTER_NAME \
  --location GOOGLE_CLOUD_LOCATION \
  --format "value(authorization.adminUsers)"

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