Résoudre les problèmes courants

Cette page explique comment résoudre les problèmes courants liés à GKE sur AWS.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Messages d'erreur fréquents

Les sections suivantes décrivent les causes et les solutions de messages d'erreur.

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

Utilisateur interdit

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 :

  1. Identifiez les utilisateurs autorisés dans votre cluster.

    gcloud container aws 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'}

  2. 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 aws 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.

Problèmes liés aux commandes kubectl

Les sections suivantes expliquent comment résoudre les problèmes liés aux commandes kubectl qui ne répondent pas ou qui échouent.

Les commandes kubectl cessent de répondre

Si votre cluster exécute une version de Kubernetes antérieure à 1.25 et que les commandes kubectl ne répondent pas ou expirent, la cause la plus courante est que vous n'avez pas encore créé de pool de nœuds. Par défaut, GKE sur AWS génère 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, 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.

Pour les clusters exécutant Kubernetes 1.25 ou une version ultérieure, le gke-connect-agent s'exécute sur le plan de contrôle et aucun pool de nœuds n'est requis. Si la commande kubectl ne répond pas, vérifiez les journaux du composant du plan de contrôle avec Cloud Logging.

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

La commande kubectl logs renvoie une erreur remote error: tls: internal error

Ce problème peut survenir s'il manque une autorisation au rôle d'API de plan de contrôle. Par exemple, cela peut se produire si votre rôle AWS ne dispose pas de l'autorisation ec2:DescribeDhcpOptions. Dans ce cas, les requêtes de signature de certificat en provenance de nœuds ne peuvent pas être approuvées et le nœud de calcul ne dispose pas de certificat valide.

Pour déterminer si cela est bien à l'origine du problème, vous pouvez vérifier s'il existe des demandes de signature de certificat en attente qui n'ont pas été approuvées, à l'aide de cette commande :

kubectl get csr

Pour résoudre ce problème : vérifiez que votre rôle AWS répond aux exigences.

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

  • Pour les clusters dont la version de Kubernetes est antérieure à la version 1.25, assurez-vous qu'au moins un pool de nœuds Linux est en cours d'exécution et que gke-connect-agent est en cours d'exécution. Pour en savoir plus, consultez Résoudre les problèmes de connexion au cluster.

  • Pour les clusters exécutant Kubernetes 1.25 ou une version ultérieure, consultez les journaux gke-connect-agent à l'aide de Cloud Logging.

Le service Kubernetes (LoadBalancer) ou l'Ingress Kubernetes ne fonctionnent pas

Si vos équilibreurs de charge AWS Elastic Load Balancing (ELB/NLB/ALB) ont été créés mais ne fonctionnent pas comme prévu, cela peut être dû à des problèmes d'ajout de tags de sous-réseau. Pour en savoir plus, consultez la section Sous-réseaux d'équilibreur de charge.

Plantage des pods sur les nœuds Arm

Le problème suivant se produit lorsque vous déployez un pod sur un nœud Arm, mais que l'image de conteneur n'a pas été créée pour l'architecture Arm.

Pour identifier le problème, procédez comme suit :

  1. Obtenez l'état de vos pods :

    kubectl get pods

  2. Obtenez les journaux de l''un des pods qui plante :

    kubectl logs POD_NAME

    Remplacez POD_NAME par le nom du pod qui plante.

    Vous devriez voir dans les journaux de vos pods un message d'erreur semblable à celui-ci :

    exec ./hello-app: exec format error

Pour résoudre ce problème, assurez-vous que votre image de conteneur est compatible avec l'architecture Arm. Nous vous recommandons de créer des images multi-architectures.

Impossible de supprimer le cluster

Si vous recevez un message d'erreur semblable au suivant lorsque vous essayez de supprimer un cluster, il est possible que votre rôle pour l'API GKE Multi-Cloud n'existe pas :

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

Pour résoudre le problème, suivez les étapes décrites dans la section Créer un rôle pour l'API GKE Multi-Cloud. Vous pouvez relancer la commande après avoir recréé le rôle avec le même nom et les mêmes autorisations.

Étapes suivantes