Resolva problemas comuns

Esta página mostra como resolver problemas comuns com o GKE na AWS.

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

Mensagens de erro comuns

As secções seguintes explicam as causas e as resoluções de algumas mensagens de erro comuns.

O servidor não tem um recurso

Podem ocorrer erros, como error: the server doesn't have a resource type "services", quando um cluster não tem pools de nós em execução ou o gateway Connect não consegue estabelecer ligação a um pool de nós. Para verificar o estado dos seus pools de nós, execute o seguinte comando:

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

Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster
  • LOCATION: a localização que gere o seu cluster Google Cloud

O resultado inclui o estado dos conjuntos de nós do cluster. Se não tiver um node pool listado, crie um node pool.

Utilizador proibido

O seguinte erro ocorre quando o seu nome de utilizador 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

Pode configurar utilizadores adicionais transmitindo a flag --admin-users quando cria um cluster.

Se usar o gateway Connect e não conseguir estabelecer ligação ao cluster, experimente os seguintes passos:

  1. Obtenha os utilizadores autorizados para o seu cluster.

    gcloud container aws clusters describe CLUSTER_NAME \
    --format 'value(authorization.admin_users)'

    Substitua CLUSTER_NAME pelo nome do cluster.

    O resultado inclui os nomes de utilizador com acesso de administrador ao cluster. Por exemplo:

    {'username': 'administrator@example.com'}

  2. Obtenha o nome de utilizador atualmente autenticado com a CLI do Google Cloud.

    gcloud config get-value account

    O resultado inclui a conta autenticada com a CLI Google Cloud. Se o resultado de gcloud containers aws clusters describe e gcloud config get-value account não corresponder, execute gcloud auth login e autentique-se como o nome de utilizador com acesso administrativo ao cluster.

Problemas com comandos kubectl

As secções seguintes fornecem orientações sobre como resolver problemas com comandos kubectl que não respondem ou falham.

Os comandos kubectl deixam de responder

Se o cluster executar uma versão do Kubernetes anterior à 1.25 e os kubectl comandos não responderem ou excederem o tempo limite, o motivo mais comum é que ainda não criou um conjunto de nós. Por predefinição, o GKE on AWS gera ficheiros kubeconfig que usam o gateway do Connect como um ponto final acessível através da Internet. Para que isto funcione, a implementação gke-connect-agent tem de estar a ser executada num conjunto de nós no cluster.

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

kubectl cluster-info -v=9

Se não existirem pools de nós em execução, vê pedidos para connectgateway.googleapis.com falharem com um erro 404 cannot find active connections for cluster.

Para clusters com uma versão do Kubernetes 1.25 ou posterior, o gke-connect-agent é executado no plano de controlo e não é necessário um conjunto de nós. Se o comando kubectl não responder, verifique os registos dos componentes do plano de controlo com o Cloud Logging.

Os comandos kubectl exec, attach e port-forward falham

Os comandos kubectl exec, kubectl attach e kubectl port-forward podem falhar com a mensagem error: unable to upgrade connection quando usar o gateway Connect. Esta é uma limitação quando usa o gateway Connect como o ponto final do servidor da API Kubernetes.

Para contornar esta situação, use um kubeconfig que especifique o ponto final privado do cluster. Para obter instruções sobre como aceder ao cluster através do respetivo ponto final privado, consulte o artigo Configure o acesso ao cluster para o kubectl.

O comando kubectl logs falha com o erro remoto: tls: internal error

Este problema pode ocorrer quando a API Control Plane Role não tem uma autorização. Por exemplo, isto pode acontecer se a sua função da AWS não tiver a autorizaçãoec2:DescribeDhcpOptions. Neste caso, não é possível aprovar pedidos de assinatura de certificados de nós, e o nó de trabalho não tem um certificado válido.

Para determinar se este é o problema, pode verificar se existem pedidos de assinatura de certificados pendentes que não foram aprovados com este comando:

kubectl get csr

Para resolver este problema, confirme se a sua função da AWS corresponde aos requisitos.

Resolução de problemas genérica do kubectl

Se usar o gateway do Connect:

  • Certifique-se de que ativou o gateway Connect no seu Google Cloud projeto:

    gcloud services enable connectgateway.googleapis.com

  • Para clusters com uma versão do Kubernetes anterior à 1.25, certifique-se de que tem, pelo menos, um pool de nós do Linux em execução e que o gke-connect-agent está em execução. Para obter detalhes, consulte o artigo Resolva problemas de ligações de clusters.

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

O serviço do Kubernetes (LoadBalancer) ou o Kubernetes Ingress não funcionam

Se os seus equilibradores de carga elásticos (ELB/NLB/ALB) da AWS foram criados, mas não estão a funcionar como esperado, isto pode dever-se a problemas com a etiquetagem de sub-redes. Para mais informações, consulte Sub-redes do equilibrador de carga.

Falha dos pods nos nós Arm

O seguinte problema ocorre quando implementa um pod num nó Arm, mas a imagem do contentor não é criada para a arquitetura Arm.

Para identificar o problema, conclua as seguintes tarefas:

  1. Obtenha o estado dos seus Pods:

    kubectl get pods

  2. Obtenha os registos do pod com falhas:

    kubectl logs POD_NAME

    Substitua POD_NAME pelo nome do pod com falhas.

    A mensagem de erro nos registos do pod é semelhante à seguinte:

    exec ./hello-app: exec format error

Para resolver este problema, certifique-se de que a imagem do contentor suporta a arquitetura Arm. Como prática recomendada, crie várias imagens de arquitetura.

Não é possível eliminar o conjunto

Se receber um erro semelhante ao seguinte quando tentar eliminar um cluster, a sua função da API GKE Multi-Cloud pode não existir:

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 os passos em Crie a função da API GKE Multi-Cloud. Quando recria a função com o mesmo nome e autorizações, pode tentar novamente o comando.

O que se segue?