Resolver problemas de criação ou atualização de clusters

Nesta página, mostramos como resolver problemas relacionados à instalação ou ao upgrade do GKE na AWS.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Falhas na criação de cluster

Quando você faz uma solicitação para criar um cluster, o GKE na AWS primeiro executa um conjunto de testes de simulação para verificar a solicitação. Se a criação do cluster falhar, pode ser porque um desses testes de simulação falhou ou porque uma etapa no processo de criação do cluster não foi concluída.

Quando um teste de simulação falha, o cluster não cria recursos e retorna informações sobre o erro diretamente para você. Por exemplo, se você tenta criar um cluster com o nome invalid%%%name, o teste de simulação de um nome de cluster válido falha, e a solicitação retorna o seguinte erro:

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

A criação do cluster também pode falhar depois da aprovação dos testes de simulação. Isso pode acontecer vários minutos depois que a criação do cluster começar, após o GKE na AWS criar recursos no Google Cloud e na AWS. Nesse caso, vai haver um recurso da AWS no projeto do Google Cloud com o estado definido como ERROR.

Para conferir detalhes sobre a falha, execute o seguinte comando:

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

Substitua:

  • CLUSTER_NAME pelo nome do cluster com o estado você está consultando
  • GOOGLE_CLOUD_LOCATION pelo nome da região do Google Cloud que gerencia esse cluster da AWS

Outra opção para conferir detalhes sobre a falha de criação é descrever o recurso Operation associado à chamada de API de criação do cluster.

gcloud container aws operations describe OPERATION_ID

Substitua OPERATION_ID pelo ID da operação que criou o cluster. Se você não tiver o ID da operação de sua solicitação de criação do cluster, será possível buscá-lo com o seguinte comando:

gcloud container aws operations list \
    --location GOOGLE_CLOUD_LOCATION

Use o carimbo de data/hora ou as informações relacionadas para identificar a operação de criação de cluster de interesse.

Por exemplo, se a criação do cluster falhou devido a um papel do IAM da AWS com permissão insuficiente, esse comando e os resultados dele serão semelhantes ao exemplo a seguir:

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

A saída é semelhante a esta:

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

Falha na criação ou operação do cluster com um erro de autorização

Um erro que mostra uma falha de autorização geralmente indica que um dos dois papéis do IAM da AWS especificados durante o comando de criação do cluster foi criado incorretamente. Por exemplo, se o papel da API não incluir a permissão elasticloadbalancing:ModifyTargetGroupAttributes, a criação do cluster vai falhar com uma mensagem de erro semelhante a esta:

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

Mesmo que um cluster pareça ter sido criado com sucesso, um papel do IAM especificado incorretamente pode causar falhas posteriormente durante a operação do cluster, como ao usar comandos como kubectl logs.

Para resolver esses erros de autorização, confirme se as políticas associadas aos dois papéis do IAM especificados durante a criação do cluster estão corretas. Especificamente, verifique se elas correspondem às descrições em Criar papéis do IAM da AWS. Em seguida, exclua e recrie o cluster. As descrições de papéis individuais estão disponíveis em Papel de API e em Papel do plano de controle.

A criação ou operação do cluster falha no estágio de verificação de integridade

Às vezes, a criação do cluster falha durante a verificação de integridade com um status de operação semelhante a este:

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

Essa falha pode ocorrer devido à ausência de papéis do IAM ou à especificação incorreta de papéis do IAM. É possível usar o AWS CloudTrail para mostrar problemas do IAM.

Exemplo:

  • Se o papel da API não incluir a permissão kms:GenerateDataKeyWithoutPlaintext para a chave KMS do volume principal do plano de controle, você verá os seguintes eventos:

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

    e

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

  • Se o papel do plano de controle não incluir a permissão kms:CreateGrant para a chave KMS do volume principal do plano de controle, você receberá os seguintes eventos:

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

    e

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

  • Se você não tiver concedido o papel vinculado ao serviço chamado AWSServiceRoleForAutoScaling com permissões kms:CreateGrant para usar a chave KMS do volume raiz do plano de controle, verá os seguintes 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",

  • Se você não tiver concedido o papel vinculado ao serviço chamado AWSServiceRoleForAutoScaling com permissões kms:GenerateDataKeyWithoutPlaintext para usar a chave KMS do volume raiz do plano de controle, verá os seguintes 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",

Aguardando os nós participarem do cluster

Se você receber o seguinte erro ao criar um pool de nós, verifique se sua VPC não inclui um bloco CIDR IPv4 secundário associado.

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

Para corrigir esse problema, crie um grupo de segurança que inclua todos os blocos CIDR e adicione esse grupo ao seu cluster. Para mais informações, consulte Pools de nós em blocos CIDR secundários da VPC.

Acessar o registro do sistema de uma instância

Se um plano de controle ou uma instância de pool de nós não for iniciada, será possível inspecionar o registro do sistema. Para inspecionar o registro do sistema, faça isto:

  1. Abra o console da instância do EC2 da AWS.
  2. Clique em Instâncias.
  3. Encontre a instância pelo nome. O GKE na AWS geralmente cria instâncias chamadas CLUSTER_NAME-cp para nós do plano de controle ou CLUSTER_NAME-np para nós do pool de nós.
  4. Escolha Ações -> Monitorar e resolver problemas -> Acessar registro do sistema. O registro do sistema da instância é exibido.

Falhas de atualização do cluster

Quando você atualiza um cluster, assim como ao criar um novo cluster, o GKE na AWS primeiro executa um conjunto de testes de simulação para verificar a solicitação. Se a atualização do cluster falhar, pode ser porque um desses testes de simulação falhou ou porque uma etapa no processo de atualização do cluster não foi concluída.

Quando um teste de simulação falha, o cluster não atualiza recursos e retorna informações sobre o erro diretamente para você. Por exemplo, se você tentar atualizar um cluster para usar um par de chaves SSH com o nome test_ec2_keypair, o teste de simulação tentará buscar o par de chaves EC2 e falhará, e a solicitação retornará o erro a seguir:

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

A atualização do cluster também pode falhar depois da aprovação dos testes de simulação. Isso pode acontecer vários minutos após o início da atualização do cluster e o recurso da AWS no projeto do Google Cloud terá o estado definido como DEGRADED.

Para ver detalhes sobre a falha e a operação relacionada, siga as etapas descritas em Falhas de criação do cluster.

A atualização de cluster falha ao atualizar as tags do plano de controle

A API de atualização da AWS agora é compatível com a atualização das tags do plano de controle. Para atualizar tags, você precisa de um cluster com o Kubernetes versão 1.24 ou mais recente. Também é preciso garantir que o papel do IAM da AWS tenha as permissões apropriadas, conforme listado na página Atualizar cluster para atualizar o plano de controle.

Um erro que mostra uma falha de autenticação geralmente indica que você não adicionou alguma permissão do IAM. Por exemplo, se o papel da API não incluir a permissão ec2:DeleteTags, a atualização do cluster para tags poderá falhar com uma mensagem de erro semelhante a esta (<encoded_auth_failure_message> é encoberto para fins de simplificação):

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 a mensagem de falha codificada anterior, envie uma solicitação para a API decode-authorization-message do STS da AWS, conforme mostrado no seguinte comando:

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

O resultado será assim:

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

A resposta anterior indica que não foi possível executar a ação ec2:DeleteTags no recurso de regra do grupo de segurança do EC2 do cluster da AWS. Atualize o papel da APIde acordo e reenvie a solicitação da API de atualização para atualizar as tags do plano de controle.

A seguir