Résoudre les problèmes de création ou de mise à jour du cluster

Cette page explique comment résoudre les problèmes liés à l'installation ou à la mise à niveau de GKE sur AWS.

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

Échecs de création de cluster

Lorsque vous envoyez une requête de création de cluster, GKE sur AWS exécute d'abord 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 plusieurs minutes après le début de la création du cluster, une fois que GKE sur AWS a 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 en savoir plus sur l'échec, exécutez la commande suivante:

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

Remplacez les éléments suivants :

  • 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 détails 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 le code temporel 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

Le résultat ressemble à ce qui 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 mal spécifié peut entraîner des échecs ultérieurement lors de l'utilisation du 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 Rôle API et Rôle 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 et affiche un état d'opération semblable à celui-ci:

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

Cet échec peut être dû à des rôles IAM manquants ou à des rôles IAM spécifiés de manière incorrecte. Vous pouvez exposer les problèmes IAM à l'aide d'AWS CloudTrail.

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

    et

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

    et

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

  1. Ouvrez la console dédiée aux instances AWS EC2.
  2. Cliquez sur Instances.
  3. Recherchez l'instance par son nom. GKE sur AWS crée généralement des instances nommées CLUSTER_NAME-cp pour les nœuds de plan de contrôle ou CLUSTER_NAME-np pour les nœuds de pool de nœuds.
  4. 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.

Échec de la mise à jour du cluster

Lorsque vous mettez à jour un cluster, comme lorsque vous créez un cluster, GKE sur AWS exécute d'abord un ensemble de tests préalables 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 utiliser 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, et 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 du cluster peuvent également échouer une fois les tests préliminaires terminés. Cela peut se produire plusieurs minutes après le début de la mise à jour du cluster et que l'état de la ressource AWS de votre projet Google Cloud est défini sur DEGRADED.

Pour obtenir des informations sur l'échec et l'opération associée, suivez les étapes décrites 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 prend en charge la mise à jour des tags du plan de contrôle. Pour mettre à jour les tags, vous avez besoin d'un cluster équipé de Kubernetes 1.24 ou version ultérieure. Vous devez également vous assurer que votre rôle IAM AWS dispose des autorisations appropriées, répertoriées sur la page Mettre à jour le cluster pour mettre à jour les tags du plan de contrôle.

Une erreur indiquant un échec d'authentification indique généralement que vous n'avez pas ajouté une autorisation IAM. Par exemple, si le rôle API n'a pas inclus l'autorisation ec2:DeleteTags, la mise à jour du cluster pour les tags peut échouer et renvoyer un message d'erreur semblable au suivant (<encoded_auth_failure_message> est masqué pour des raisons 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é précédent, vous pouvez envoyer une requête à l'API AWS STS decode-Authorization-message, comme indiqué dans la commande suivante:

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 précédente indique que vous n'avez pas pu effectuer 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 et renvoyez la requête API de mise à jour pour mettre à jour les tags du plan de contrôle.

Étapes suivantes