Soluciona problemas de creación o actualización del clúster

En esta página, se muestra cómo resolver problemas relacionados con la instalación o actualización de GKE en AWS.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Errores de creación de clústeres

Cuando realizas una solicitud para crear un clúster, GKE en AWS primero ejecuta un conjunto de pruebas previas para verificar la solicitud. Si la creación del clúster falla, puede deberse a que una de estas pruebas previas falló o a que un paso del proceso de creación del clúster no se completó.

Si una prueba preliminar falla, tu clúster no crea ningún recurso y te muestra información sobre el error directamente. Por ejemplo, si intentas crear un clúster con el nombre invalid%%%name, la prueba preliminar para un nombre de clúster válido fallará y la solicitud mostrará el siguiente error:

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 creación del clúster también puede fallar después de que se aprueben las pruebas preliminares. Esto puede ocurrir varios minutos después de que comenzara la creación del clúster, después de que GKE en AWS haya creado recursos en Google Cloud y en AWS. En este caso, existirá un recurso de AWS en tu proyecto de Google Cloud con su estado configurado como ERROR.

Para obtener detalles sobre la falla, ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

  • CLUSTER_NAME por el nombre del clúster cuyo estado consultas
  • GOOGLE_CLOUD_LOCATION por el nombre de la región de Google Cloud que administra este clúster de AWS

De manera alternativa, puedes obtener detalles sobre el error de creación con la descripción del recurso Operation asociado con la llamada a la API de creación de clústeres.

gcloud container aws operations describe OPERATION_ID

Reemplaza OPERATION_ID por el ID de la operación que creó el clúster. Si no tienes el ID de operación de la solicitud de creación de clústeres, puedes recuperarlo con el siguiente comando:

gcloud container aws operations list \
    --location GOOGLE_CLOUD_LOCATION

Usa la marca de tiempo o la información relacionada para identificar la operación de creación de clústeres de interés.

Por ejemplo, si la creación de tu clúster falló debido a un rol de IAM de AWS con permisos insuficientes, este comando y sus resultados se parecerán al siguiente ejemplo:

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

El resultado es similar al siguiente:

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 creación o la operación del clúster falla con un error de autorización

Por lo general, un error que muestra una falla de autorización indica que uno de los dos roles de IAM de AWS que especificaste durante el comando de creación del clúster se creó de manera incorrecta. Por ejemplo, si el rol de la API no incluye el permiso elasticloadbalancing:ModifyTargetGroupAttributes, la creación del clúster fallará con un mensaje de error similar al siguiente:

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

Incluso si un clúster parece haber sido creado con éxito, un rol de IAM especificado de forma incorrecta puede causar fallas más adelante durante la operación del clúster, como cuando se usan comandos como kubectl logs.

Para resolver estos errores de autorización, confirma que las políticas asociadas con los dos roles de IAM que especificaste durante la creación del clúster sean correctas. En particular, asegúrate de que coincidan con las descripciones de Crea roles de IAM de AWS y, luego, borra y vuelve a crear el clúster. Las descripciones de roles individuales están disponibles en Rol de API y Rol del plano de control.

La creación o la operación del clúster fallan en la etapa de verificación de estado

A veces, la creación del clúster falla durante la verificación de estado con un estado operativo similar al siguiente:

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

Esta falla puede deberse a roles de IAM faltantes o a roles de IAM especificados de forma incorrecta. Puedes usar AWS CloudTrail para mostrar problemas de IAM.

Por ejemplo:

  • Si el rol de la API no incluyó el permiso kms:GenerateDataKeyWithoutPlaintext para la clave de KMS de volumen principal del plano de control, verás los siguientes eventos:

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

    y

    "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 el rol del plano de control no incluyó el permiso kms:CreateGrant para la clave de KMS de volumen principal del plano de control, verás los siguientes eventos:

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

    y

    "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 no otorgaste el rol vinculado al servicio llamado AWSServiceRoleForAutoScaling con permisos kms:CreateGrant para usar la clave de KMS del volumen raíz del plano de control, verás los siguientes eventos:

    "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 no otorgaste el rol vinculado al servicio llamada AWSServiceRoleForAutoScaling con permisos kms:GenerateDataKeyWithoutPlaintext para usar la clave de KMS del volumen raíz del plano de control, verás los siguientes eventos:

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

Espera a que los nodos se unan al clúster

Si recibes el siguiente error cuando creas un grupo de nodos, verifica que tu VPC no incluya un bloque CIDR IPv4 secundario asociado.

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

Para solucionar este problema, crea un grupo de seguridad que incluya todos los bloques de CIDR y agrégalo a tu clúster. Para obtener más información, consulta Grupos de nodos en bloques CIDR secundarios de VPC.

Obtén el registro del sistema de una instancia

Si una instancia de grupo de nodos o de plano de control no se inicia, puedes inspeccionar su registro del sistema. Para inspeccionar el registro del sistema, haz lo siguiente:

  1. Abre la consola de instancias de AWS EC2.
  2. Haz clic en Instances.
  3. Busca la instancia por nombre. Por lo general, GKE en AWS crea instancias llamadas CLUSTER_NAME-cp para los nodos del plano de control o CLUSTER_NAME-np para los nodos del grupo de nodos.
  4. Selecciona Actions -> Monitor and Troubleshoot -> Get System Log. Aparecerá el registro del sistema de la instancia.

Errores de actualización del clúster

Cuando actualizas un clúster, al igual que cuando creas un clúster nuevo, GKE en AWS primero ejecuta un conjunto de pruebas preliminares para verificar la solicitud. Si la actualización del clúster falla, puede deberse a que una de estas pruebas preliminares falló o a que un paso del proceso de actualización del clúster no se completó.

Si una prueba preliminar falla, tu clúster no actualiza ningún recurso y te muestra información sobre el error directamente. Por ejemplo, si intentas actualizar un clúster para usar un par de llaves SSH con el nombre test_ec2_keypair, la prueba preliminar intenta recuperar el par de claves EC2 y falla, y la solicitud muestra el siguiente error:

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

La actualización del clúster también puede fallar después de que se aprueben las pruebas preliminares. Esto puede suceder varios minutos después de que comenzara la actualización del clúster y tu recurso de AWS en tu proyecto de Google Cloud tendrá el estado establecido como DEGRADED.

Para obtener detalles sobre la falla y la operación relacionada, sigue los pasos descritos en Fallas de creación de clústeres.

La actualización del clúster falla cuando se actualizan las etiquetas del plano de control

La API de actualización de AWS admite la actualización de etiquetas del plano de control. Para actualizar las etiquetas, necesitas un clúster con la versión 1.24 de Kubernetes o superior. También debes asegurarte de que tu rol de IAM de AWS tenga los permisos adecuados que se indican en la página de actualizar el clúster para actualizar etiquetas del plano de control.

Por lo general, un error que muestra una falla de autenticación indica que no agregaste un permiso de IAM. Por ejemplo, si el rol de la API no incluyó el permiso ec2:DeleteTags, la actualización del clúster para las etiquetas puede fallar con un mensaje de error similar al siguiente (el <encoded_auth_failure_message> está oculto por cuestiones de brevedad):

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>

Para depurar el mensaje de falla codificada anterior, puedes enviar una solicitud a la API decode-authorization-message de AWS STS como se muestra en el siguiente comando:

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

El resultado es similar al siguiente:

...
"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 respuesta anterior indica que no pudiste realizar la acción ec2:DeleteTags en el recurso de la regla del grupo de seguridad de EC2 del clúster de AWS. Actualiza tu rol de API según corresponda y vuelve a enviar la solicitud a la API de actualización para actualizar las etiquetas del plano de control.

¿Qué sigue?