Esta documentação é referente à versão atual do GKE na AWS, lançada em novembro de 2021. Consulte as Notas de lançamento para mais informações.

Solução de problemas de clusters do Anthos na AWS

Use estas etapas de solução de problemas se você tiver problemas para instalar ou usar clusters do Anthos na AWS.

Falhas na criação de cluster

Quando você faz uma solicitação para criar um cluster, os clusters do Anthos na AWS primeiro executam 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, depois que os clusters do Anthos na AWS criarem 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 ver detalhes sobre a falha, execute:

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 ver detalhes sobre a falha de criação é descrever o recurso Operation associado à chamada de API do cluster de criação.

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 clusters 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 resposta será 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 no Papel de API e no 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

Isso pode ocorrer devido a papéis do IAM ausentes ou papéis do IAM especificados incorretamente. É 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.",

"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ê verá 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.",

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

Abra o console da instância do EC2 da AWS.
Clique em Instâncias.
Encontre a instância pelo nome. Os clusters do Anthos na AWS geralmente criam 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.
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, os clusters do Anthos na AWS primeiro executam 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 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 como abaixo geralmente indica que você deixou de adicionar 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 (o <encoded_auth_failure_message> é editado para simplificar):

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 acima, envie uma solicitação para a API decode-authorization-message do AWS STS, conforme mostrado abaixo:

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

A saída resultante será semelhante a esta:

...
"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 acima indica que não foi possível executar a ação ec2:DeleteTags no recurso de regra do grupo de segurança do EC2 no 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.

Não é possível se conectar ao cluster com o kubectl

Nesta seção, você aprende alguns truques para diagnosticar problemas na conexão com o cluster usando a ferramenta de linha de comando kubectl.

O servidor não tem um recurso

Erros como error: the server doesn't have a resource type "services" podem acontecer quando um cluster não tem pools de nós em execução ou o gateway do Connect não pode se conectar a um pool de nós. Para verificar o status dos pools de nós, execute o seguinte comando:

gcloud container aws node-pools list \
    --cluster-name CLUSTER_NAME \
    --location LOCATION

Substitua:

CLUSTER_NAME: o nome do cluster.
LOCATION: o local do Google Cloud que gerencia o cluster

A saída inclui o status dos pools de nós do cluster. Se você não tiver um pool de nós listado, crie um pool de nós.

Como solucionar problemas do gateway do Connect

O seguinte erro ocorre quando seu nome de usuário não tem acesso de administrador ao 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

É possível configurar mais usuários transmitindo a sinalização --admin-users ao criar um cluster.

Se você usa o gateway do Connect e não consegue se conectar ao cluster, siga estas etapas:

Consiga os usuários autorizados para o cluster.
```
gcloud container aws clusters describe CLUSTER_NAME \
  --format 'value(authorization.admin_users)'
```
Substitua CLUSTER_NAME pelo nome do cluster.

A saída inclui os nomes de usuário com acesso de administrador ao cluster. Exemplo:
```
{'username': 'administrator@example.com'}
```
Consiga o nome de usuário autenticado no momento com a Google Cloud CLI.
```
gcloud config get-value account
```
A saída inclui a conta autenticada com a Google Cloud CLI. Se as saídas de gcloud containers aws clusters describe e gcloud config get-value account forem diferentes, execute gcloud auth login e faça a autenticação com o nome de usuário que tem acesso administrativo ao cluster.

Comando do kubectl para de responder

Se o comando kubectl não responder ou expirar, o motivo mais comum será que você ainda não criou um pool de nós. Por padrão, os clusters do Anthos na AWS geram arquivos kubeconfig que usam o gateway do Connect como um endpoint acessível pela Internet. Para que isso funcione, a implantação gke-connect-agent precisa ser executada em um pool de nós no cluster.

Para mais informações de diagnóstico, execute o comando a seguir:

kubectl cluster-info -v=9

Se não houver pools de nós em execução, você verá solicitações para connectgateway.googleapis.com com um erro 404 cannot find active connections for cluster.

Falha nos comandos kubectl exec, attach e port-forward

Os comandos kubectl exec, kubectl attach e kubectl port-forward podem apresentar falha com a mensagem error: unable to upgrade connection ao usar o gateway Connect. Essa é uma limitação ao usar o gateway do Connect como o endpoint do servidor da API Kubernetes.

Para contornar esse problema, use um kubeconfig que especifique o endpoint particular do cluster. Para instruções sobre como acessar o cluster usando o endpoint particular, consulte Configurar o acesso ao cluster para o kubectl.

`kubectl logs` falha com `remote error: tls: internal error`

Isso pode acontecer quando o papel da API Control Plane não tem uma permissão. Por exemplo, isso pode acontecer se o papel da AWS não tiver a permissão ec2:DescribeDhcpOptions. Nesse caso, as solicitações de assinatura de certificado dos nós não podem ser aprovadas, e o nó de trabalho não terá um certificado válido.

Para determinar se esse é o problema, verifique se há solicitações de assinatura de certificado pendentes que não foram aprovadas com este comando:

kubectl get csr

Para resolver isso, verifique se o papel da AWS corresponde aos requisitos da documentação.

Solução de problemas genérica do kubectl

Se você usar o gateway do Connect:

Verifique se você ativou o gateway do Connect no seu projeto do Google Cloud:
```
gcloud services enable connectgateway.googleapis.com
```
Veja se você tem pelo menos um pool de nós do Linux em execução.
Verifique se o gke-connect-agent está em execução. Consulte a solução de problemas de conexão para mais detalhes.

O Kubernetes Service (LoadBalancer) ou a Entrada do Kubernetes não funcionam

Se os balanceadores de carga elásticos da AWS (ELB/NLB/ALB) foram criados, mas não estão funcionando conforme o esperado, isso pode ser causado por problemas com a inclusão de tags de sub-rede. Saiba mais em Sub-redes do balanceador de carga.

Erros da API

O Kubernetes 1.22 suspende o uso e substitui várias APIs. Se você tiver feito upgrade do cluster para a versão 1.22 ou posterior, qualquer chamada feita pelo aplicativo para uma das APIs suspensas falhará.

Solução

Faça upgrade do seu aplicativo para substituir as chamadas de API obsoletas pelos correspondentes mais recentes.

Não é possível excluir o cluster

FAILED_PRECONDITION: não foi possível assumir o papel

Se você receber um erro semelhante a este, talvez o papel da API Anthos Multi-Cloud não exista:

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

Para corrigir o problema, siga as etapas em Criar papel da API Anthos Multi-Cloud. Quando recriar o papel com o mesmo nome e permissões, teste novamente o comando.

Resolver problemas de cargas de trabalho do Arm

Falhas nos pods em nós do Arm

O problema a seguir ocorre quando você implanta um pod em um nó do Arm, mas a imagem do contêiner não é criada para a arquitetura do Arm.

Para identificar o problema, conclua as seguintes tarefas:

Veja o status dos seus pods:
```
kubectl get pods
```
Acessar os registros de um pod com falha:
```
kubectl logs POD_NAME
```
Substitua POD_NAME pelo nome do pod com falha.

A mensagem de erro nos registros do pod é semelhante a esta:
```
exec ./hello-app: exec format error
```

Para resolver esse problema, verifique se a imagem do contêiner é compatível com a arquitetura do Arm. Como prática recomendada, crie várias imagens de arquitetura.

Erro de clusters inacessíveis na IU

Algumas superfícies de IU no console do Google Cloud têm um problema ao se conectarem aos clusters 1.25.5-gke.1500 e 1.25.4-gke.1300 da versão. Especificamente a lista de clusters do Anthos Service Mesh.

Esse problema resulta em um aviso de que o cluster está inacessível, apesar de poder fazer login e interagir com ele de outras páginas.

Essa foi uma regressão devido à remoção de gateway-impersonate ClusterRoleBinding nessas duas versões de cluster.

Uma solução alternativa é adicionar as permissões necessárias manualmente aplicando este YAML:

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

Substitua ADMIN_USER1 e ADMIN_USER2 pelas contas de usuário de administrador dos clusters específicos (endereços de e-mail). Neste exemplo, há apenas dois usuários administradores.

Para ver a lista de usuários administradores configurados para o cluster:

gcloud container aws clusters describe CLUSTER_NAME \
  --location GOOGLE_CLOUD_LOCATION \
  --format "value(authorization.adminUsers)"

Este ClusterRole será substituído automaticamente ao fazer upgrade para uma versão mais recente do cluster.