Solução de problemas comuns

Nesta página, mostramos como resolver problemas comuns com o GKE na AWS.

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

Mensagens de erro comuns

As seções a seguir explicam as causas e as soluções de algumas mensagens de erro comuns.

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.

Usuário proibido

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:

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

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

Problemas com comandos kubectl

As seções a seguir fornecem orientações sobre como resolver problemas com comandos kubectl que não respondem ou com falha.

Comandos kubectl param de responder

Se o cluster executar uma versão do Kubernetes anterior à 1.25 e os comandos kubectl não responderem ou expirarem, o motivo mais comum é você ainda não ter criado um pool de nós. Por padrão, o GKE na AWS gera 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 seguinte comando:

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.

Para clusters com a versão 1.25 ou posterior do Kubernetes, o gke-connect-agent é executado no plano de controle e o pool de nós não é necessário. Se o comando kubectl não responder, verifique os registros do componente do plano de controle com o Cloud Logging.

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.

Os registros do kubectl falham com erro remoto: 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.

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

  • Para clusters com uma versão do Kubernetes anterior à 1.25, verifique se você tem pelo menos um pool de nós do Linux em execução e se o gke-connect-agent está em execução. Para mais detalhes, consulte Resolver problemas de conexões de cluster.

  • Para clusters com a versão 1.25 ou posterior do Kubernetes, verifique os registros gke-connect-agent com o Cloud Logging.

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.

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:

  1. Veja o status dos seus pods:

    kubectl get pods

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

Não é possível excluir o cluster

Se você receber um erro semelhante ao seguinte ao tentar excluir um cluster, talvez seu papel da API GKE 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.

A seguir