Cette documentation concerne la version la plus récente de GKE sur Azure, publiée en novembre 2021. Consultez les notes de version pour plus d'informations.

Résoudre les problèmes liés aux clusters Anthos sur Azure

Suivez ces étapes de dépannage si vous rencontrez des problèmes pour créer ou utiliser des clusters Anthos sur Azure.

Échecs de création de cluster

Lorsque vous effectuez une requête de création de cluster, les clusters Anthos sur Azure commencent par exécuter un ensemble de tests préliminaires pour vérifier la requête. Si la création du cluster échoue, il se peut que l'un de ces tests préliminaires ait échoué ou qu'une étape du processus de création de cluster n'ait pas abouti.

En cas d'échec d'un test préliminaire, votre cluster ne crée aucune ressource et vous renvoie directement les informations sur l'erreur. Par exemple, si vous essayez de créer un cluster nommé invalid%%%name, le test préliminaire de validation du nom de cluster échoue et la requête renvoie l'erreur suivante :

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

La création du cluster peut également échouer une fois les tests préliminaires effectués. Cela peut se produire quelques minutes après le démarrage de la création du cluster, une fois que les clusters Anthos sur Azure ont créé des ressources dans Google Cloud et Azure. Dans ce cas, une ressource Azure existe dans votre projet Google Cloud avec son état défini sur ERROR.

Pour obtenir les détails de l'échec, exécutez la commande suivante :

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

Remplacez :

CLUSTER_NAME par le nom du cluster dont vous interrogez l'état ;
GOOGLE_CLOUD_LOCATION par le nom de la région Google Cloud qui gère ce cluster Azure.

Vous pouvez également obtenir des informations sur l'échec de la création en décrivant la ressource Operation associée à l'appel d'API de création de cluster.

gcloud container azure operations describe OPERATION_ID

Remplacez OPERATION_ID par l'ID de l'opération qui a créé le cluster. Si vous ne disposez pas de l'ID d'opération de votre requête de création de cluster, vous pouvez le récupérer à l'aide de la commande suivante :

gcloud container azure operations list \
  --location GOOGLE_CLOUD_LOCATION

Utilisez l'horodatage ou les informations associées pour identifier l'opération de création de cluster qui vous intéresse.

Échecs de mise à jour du cluster

Lorsque vous mettez à jour un cluster, comme lorsque vous en créez un, clusters Anthos sur Azure exécute d'abord un ensemble de tests préalables au vol pour vérifier la requête. Si la mise à jour du cluster échoue, cela peut être dû à l'échec de l'un de ces tests préliminaires ou à l'échec d'une étape du processus de mise à jour du cluster.

Si un test préliminaire échoue, votre cluster ne met à jour aucune ressource et vous renvoie directement des informations sur l'erreur. Par exemple, si vous essayez de mettre à jour un cluster pour qu'il utilise une paire de clés SSH nommée test_ec2_keypair, le test préliminaire tente de récupérer la paire de clés EC2 et échoue. La requête renvoie l'erreur suivante:

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

Les mises à jour de clusters peuvent également échouer après la fin des tests préliminaires. Cela peut se produire plusieurs minutes après le début de la mise à jour du cluster, et l'état de votre ressource Azure dans votre projet Google Cloud est défini sur DEGRADED.

Pour en savoir plus sur la défaillance et l'opération associée, suivez la procédure décrite dans la section Échecs de création de cluster.

Impossible de se connecter au cluster avec kubectl

Cette section donne des conseils pour diagnostiquer les problèmes de connexion à votre cluster à l'aide de l'outil de ligne de commande kubectl.

Le serveur ne dispose d'aucune ressource

Des erreurs de type error: the server doesn't have a resource type "services" peuvent se produire lorsqu'un cluster ne contient pas de pool de nœuds en cours d'exécution ou lorsqu'une passerelle Connect ne peut pas se connecter à un pool de nœuds. Pour vérifier l'état de vos pools de nœuds, exécutez la commande suivante :

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

Remplacez les éléments suivants :

CLUSTER_NAME : nom de votre cluster.
LOCATION : zone Google Cloud qui gère votre cluster

Le résultat inclut l'état des pools de nœuds de votre cluster. Si aucun pool de nœuds n'est répertorié, créez un pool de nœuds.

Résoudre les problèmes liés à la passerelle Connect

L'erreur suivante se produit lorsque votre nom d'utilisateur ne dispose pas d'un accès administrateur à votre cluster :

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

Vous pouvez configurer des utilisateurs supplémentaires en transmettant l'option --admin-users lorsque vous créez un cluster.

Si vous utilisez la passerelle Connect et que vous ne pouvez pas vous connecter à votre cluster, procédez comme suit :

Identifiez les utilisateurs autorisés dans votre cluster.
```
gcloud container azure clusters describe CLUSTER_NAME \
  --format 'value(authorization.admin_users)'
```
Remplacez CLUSTER_NAME par le nom de votre cluster.

Le résultat inclut les noms d'utilisateur disposant d'un accès administrateur au cluster. Exemple :
```
{'username': 'administrator@example.com'}
```
Obtenez le nom d'utilisateur actuellement authentifié avec la CLI Google Cloud.
```
gcloud config get-value account
```
Le résultat inclut le compte authentifié avec la CLI Google Cloud. Si les résultats de gcloud containers azure clusters describe et gcloud config get-value account ne correspondent pas, exécutez la commande gcloud auth login et authentifiez-vous avec le nom d'utilisateur disposant d'un accès administrateur au cluster.

La commande kubectl cesse de répondre

Si la commande kubectl ne répond pas ou expire, la raison la plus courante est que vous n'avez pas encore créé de pool de nœuds. Par défaut, les clusters Anthos sur Azure génèrent des fichiers kubeconfig qui utilisent la passerelle Connect comme point de terminaison accessible via Internet. Pour que cela fonctionne, le déploiement gke-connect-agent doit être exécuté dans un pool de nœuds sur le cluster.

Pour obtenir plus d'informations de diagnostic dans ce cas précis, exécutez la commande suivante :

kubectl cluster-info -v=9

Si aucun pool de nœuds n'est en cours d'exécution, les requêtes envoyées à connectgateway.googleapis.com échouent avec une erreur 404 cannot find active connections for cluster.

Échec des commandes kubectl exec, attach et port-forward

Les commandes kubectl exec, kubectl attach et kubectl port-forward peuvent échouer avec le message error: unable to upgrade connection lors de l'utilisation de la passerelle Connect. Il s'agit d'une limitation lorsque vous utilisez la passerelle Connect comme point de terminaison du serveur d'API Kubernetes.

Pour contourner ce problème, utilisez une commande kubeconfig qui spécifie le point de terminaison privé du cluster. Pour obtenir des instructions sur l'accès au cluster via son point de terminaison privé, consultez la page Configurer l'accès au cluster pour kubectl.

Résoudre les problèmes génériques liés à kubectl

Si vous utilisez la passerelle Connect, procédez comme suit :

Assurez-vous d'avoir activé la passerelle Connect dans votre projet Google Cloud :
```
gcloud services enable connectgateway.googleapis.com
```
Assurez-vous de disposer d'au moins un pool de nœuds Linux en cours d'exécution.
Assurez-vous que gke-connect-agent est en cours d'exécution. Pour en savoir plus, consultez la section Résoudre les problèmes liés à Connect.

Erreurs d'API

Kubernetes 1.22 abandonne et remplace plusieurs API. Si vous avez mis à niveau votre cluster vers la version 1.22 ou une version ultérieure, tous les appels effectués par votre application vers l'une des API obsolètes échouent.

Solution

Mettez à niveau votre application pour remplacer les appels d'API obsolètes par leurs équivalents plus récents.

Un cluster inaccessible a détecté une erreur dans l'UI

Certaines surfaces d'interface utilisateur de la console Google Cloud rencontrent des difficultés pour se connecter aux clusters 1.25.5-gke.1500 et 1.25.4-gke.1300. en particulier la liste des clusters Anthos Service Mesh.

Ce problème génère un avertissement indiquant que le cluster est inaccessible, même s'il peut se connecter et interagir avec lui à partir d'autres pages.

Il s'agissait d'une régression en raison de la suppression de gateway-impersonate ClusterRoleBinding dans ces deux versions de cluster.

Une solution de contournement consiste à ajouter manuellement les autorisations nécessaires en appliquant le code YAML suivant:

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

Remplacez ADMIN_USER1 et ADMIN_USER2 par vos comptes d'administrateur (adresses e-mail) d'administrateur de clusters spécifiques. Dans cet exemple, il n'y a que deux administrateurs.

Pour afficher la liste des administrateurs configurés pour le cluster:

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

Ce ClusterRole sera automatiquement remplacé lors de la mise à niveau vers une version de cluster plus récente.