Cette documentation concerne la version actuelle de GKE sur AWS, 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 AWS

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

Échecs de création de cluster

Lorsque vous effectuez une requête de création de cluster, Anthos clusters on AWS commence 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.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

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 AWS ont créé des ressources dans Google Cloud et AWS. Dans ce cas, une ressource AWS 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 aws 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 AWS.

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

Par exemple, si la création de votre cluster échoue en raison d'un rôle IAM AWS ne disposant pas d'autorisations suffisantes, cette commande et ses résultats ressemblent à l'exemple suivant :

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

La réponse se présente comme suit :

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

La création ou l'opération de cluster renvoie une erreur d'autorisation

Une erreur indiquant un échec d'autorisation indique généralement que l'un des deux rôles IAM AWS que vous avez spécifiés lors de la commande de création du cluster n'a pas été créé correctement. Par exemple, si le rôle API n'inclue pas l'autorisation elasticloadbalancing:ModifyTargetGroupAttributes, la création du cluster échoue avec un message d'erreur semblable à celui-ci :

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

Même si un cluster semble avoir été créé avec succès, un rôle IAM spécifié de manière incorrecte peut entraîner des échecs lors d'une opération de cluster, par exemple lors de l'utilisation de commandes telles que kubectl logs.

Pour résoudre ces erreurs d'autorisation, vérifiez que les stratégies associées aux deux rôles IAM que vous avez spécifiés lors de la création du cluster sont correctes. Plus précisément, assurez-vous qu'elles correspondent aux descriptions de la section Créer des rôles AWS IAM, puis supprimez et recréez le cluster. Les descriptions des rôles individuels sont disponibles dans les sections Rôle d'API et Rôle de plan de contrôle.

La création ou l'opération de cluster échoue à l'étape de vérification de l'état

Parfois, la création du cluster échoue lors de la vérification de l'état, avec un état d'opération qui ressemble à ceci :

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

Cela peut être dû à des rôles IAM manquants ou spécifiés de manière incorrecte. Vous pouvez utiliser AWS CloudTrail pour mettre en évidence les problèmes IAM.

Exemple :

Si le rôle API n'inclut pas l'autorisation kms:GenerateDataKeyWithoutPlaintext pour la clé KMS du volume principal du plan de contrôle, les événements suivants s'affichent :

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

"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",

Si le rôle du plan de contrôle n'inclut pas l'autorisation kms:CreateGrant pour la clé KMS du volume principal du plan de contrôle, les événements suivants s'affichent :

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

"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",

Si vous n'avez pas attribué le rôle lié au service nommé AWSServiceRoleForAutoScaling avec des autorisations kms:CreateGrant pour utiliser la clé KMS du volume racine du plan de contrôle, les événements suivants s'affichent :

"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",

Si vous n'avez pas attribué le rôle lié au service nommé AWSServiceRoleForAutoScaling avec des autorisations kms:GenerateDataKeyWithoutPlaintext pour utiliser la clé KMS du volume racine du plan de contrôle, les événements suivants s'affichent :

"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",

Attendre que les nœuds rejoignent le cluster

Si vous recevez l'erreur suivante lors de la création d'un pool de nœuds, vérifiez que votre VPC n'inclut pas de bloc CIDR IPv4 secondaire associé.

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

Pour résoudre ce problème, créez un groupe de sécurité qui inclut tous les blocs CIDR et ajoutez ce groupe à votre cluster. Pour en savoir plus, consultez la page Pools de nœuds dans les blocs CIDR secondaires du VPC.

Obtenir le journal système d'une instance

Si une instance de plan de contrôle ou de pool de nœuds ne démarre pas, vous pouvez inspecter son journal système en procédant comme suit :

Ouvrez la console dédiée aux instances AWS EC2.
Cliquez sur Instances.
Recherchez l'instance par son nom. Les clusters Anthos sur AWS créent généralement des instances nommées CLUSTER-NAME-cp pour les nœuds du plan de contrôle, ou CLUSTER-NAME-np pour les nœuds du pool de nœuds.
Sélectionnez Actions -> Monitor and Troubleshoot -> Get System Log (Actions > (Surveiller et résoudre les problèmes > Obtenir le journal système). Le journal système de l'instance s'affiche.

Échecs de mise à jour du cluster

Lorsque vous mettez à jour un cluster, comme lorsque vous en créez un, clusters Anthos sur AWS 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.aws.clusters.update) INVALID_ARGUMENT: key pair
"test_ec2_keypair" not found,
field: aws_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 AWS 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.

Échec de la mise à jour du cluster lors de la mise à jour des tags du plan de contrôle

L'API de mise à jour AWS accepte désormais la mise à jour des tags du plan de contrôle. Pour mettre à jour les tags, vous devez disposer d'un cluster avec Kubernetes 1.24 ou une version ultérieure. Vous devez également vous assurer que votre rôle AWS IAM dispose des autorisations appropriées, indiquées sur la page Mettre à jour le cluster pour la mise à jour des tags du plan de contrôle.

Une erreur indiquant un échec d'authentification comme ci-dessous indique généralement que vous n'avez pas ajouté d'autorisation IAM. Par exemple, si le rôle d'API n'inclut pas l'autorisation ec2:DeleteTags, la mise à jour du cluster pour les tags peut échouer et un message d'erreur semblable à celui-ci peut s'afficher : <encoded_auth_failure_message> est masqué par souci de concision :

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>

Pour déboguer le message d'échec encodé ci-dessus, vous pouvez envoyer une requête à l'API decode-authorization-message AWS STS comme suit:

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

Le résultat ressemble à ce qui suit:

...
"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",
...

La réponse ci-dessus indique que vous n'avez pas pu exécuter l'action ec2:DeleteTags sur la ressource de règle de groupe de sécurité EC2 du cluster AWS. Mettez à jour votre rôle API en conséquence, puis renvoyez la requête API Update pour mettre à jour les tags du plan de contrôle.

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

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 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'}
```
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.

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, Anthos clusters on 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 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.

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

Cela peut se produire 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 de la documentation.

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.

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.

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.

Impossible de supprimer le cluster

FAILED_PRECONDITION: Could not assume role

Si vous recevez une erreur semblable à la suivante, votre rôle pour l'API Anthos Multi-Cloud peut ne pas exister :

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 Anthos Multi-Cloud. Vous pouvez relancer la commande après avoir recréé le rôle avec le même nom et les mêmes autorisations.

Résoudre les problèmes liés aux charges de travail Arm

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, effectuez les tâches suivantes:

Obtenez l'état de vos pods :
```
kubectl get pods
```
Récupérez les journaux du pod 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 plusieurs images d'architecture.

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