Solução de problemas de clusters do Autopilot

Nesta página, mostramos como resolver problemas com clusters do Autopilot do Google Kubernetes Engine (GKE).

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

Problemas com clusters

Não é possível criar um cluster: nenhum nó registrado

O problema a seguir ocorre quando você tenta criar um cluster do Autopilot com uma conta de serviço do IAM que está desativada ou não tem as permissões necessárias. A criação do cluster falha com a seguinte mensagem de erro:

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

Para resolver o problema, faça o seguinte:

  1. Verifique se a conta de serviço padrão do Compute Engine ou a conta de serviço personalizada do IAM que você quer usar está desativada:

    gcloud iam service-accounts describe SERVICE_ACCOUNT

    Substitua SERVICE_ACCOUNT pelo endereço de e-mail da conta de serviço, como my-iam-account@my-first-project.iam.gserviceaccount.com.

    Se a conta de serviço for desativada, a saída vai ser semelhante a esta:

    disabled: true
displayName: my-service-account
email: my-service-account@my-project.iam.gserviceaccount.com
...

  2. Ative a conta de serviço se ela estiver desativada:

    gcloud iam service-accounts enable SERVICE_ACCOUNT

Se a conta de serviço estiver ativada e o erro persistir, conceda a ela as permissões mínimas necessárias para o GKE:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT" \
    --role roles/container.nodeServiceAccount

Namespace travado no estado de encerramento quando o cluster tem 0 nós

O problema a seguir ocorre quando você exclui um namespace em um cluster depois que ele é reduzido a zero nós. O componente metrics-server não pode aceitar a solicitação de exclusão de namespace porque o componente tem zero réplicas.

Para diagnosticar esse problema, execute o seguinte comando:

kubectl describe ns/NAMESPACE_NAME

Substitua NAMESPACE_NAME pelo nome do namespace.

A saída é esta:

Discovery failed for some groups, 1 failing: unable to retrieve the complete
list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to
handle the request

Para resolver esse problema, escalone qualquer carga de trabalho para que o GKE crie um novo nó. Quando o nó estiver pronto, a solicitação de exclusão de namespace será concluída automaticamente. Depois que o GKE excluir o namespace, reduza a carga de trabalho novamente.

Problemas de escalonamento

Falha ao escalonar verticalmente o nó: o pod corre o risco de não ser programado

O problema a seguir ocorre quando a geração de registros da porta serial está desativada no seu projeto do Google Cloud. Os clusters do Autopilot do GKE exigem a geração de registros da porta serial para depurar problemas de nós com eficiência. Se a geração de registros da porta serial estiver desativada, o Autopilot não poderá provisionar nós para executar as cargas de trabalho.

A mensagem de erro no log de eventos do Kubernetes é semelhante a esta:

LAST SEEN   TYPE      REASON          OBJECT                          MESSAGE
12s         Warning   FailedScaleUp   pod/pod-test-5b97f7c978-h9lvl   Node scale up in zones associated with this pod failed: Internal error. Pod is at risk of not being scheduled

A geração de registros da porta serial pode ser desativada no nível da organização por uma política da organização que aplica a restrição compute.disableSerialPortLogging. A geração de registros da porta serial também pode ser desativada no nível da instância do projeto ou da máquina virtual (VM).

Para resolver esse problema, faça o seguinte:

  1. Peça ao administrador de políticas da organização do Google Cloud para remover a restrição compute.disableSerialPortLogging do projeto com o cluster do Autopilot.
  2. Se você não tiver uma política da organização que aplique essa restrição, tente ativar a geração de registros da porta serial nos metadados do seu projeto. Essa ação requer a permissão compute.projects.setCommonInstanceMetadata do IAM.

Falha no escalonamento vertical do nó: GCE sem recursos

O problema a seguir ocorre quando as cargas de trabalho solicitam mais recursos do que estão disponíveis para uso nessa região ou zona do Compute Engine. Seus pods podem permanecer no estado Pending.

  • Verifique os eventos do pod:

    kubectl get events --for='POD_NAME' --types=Warning

    Substitua RESOURCE_NAME pelo nome do recurso pendente do Kubernetes. Por exemplo, pod/example-pod.

    O resultado será assim:

    LAST SEEN         TYPE            REASON                  OBJECT                   Message
19m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
14m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
12m (x2 over 18m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-f associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.
34s (x3 over 17m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-b associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.

Para resolver esse problema, tente o seguinte:

  • Implante o pod em uma região ou zona diferente. Se o pod tiver uma restrição zonal, como um seletor de topologia, remova a restrição, se possível. Para instruções, consulte Colocar pods do GKE em zonas específicas.
  • Crie um cluster em uma região diferente e tente implantar novamente.
  • Tente usar outra classe de computação. As classes de computação que são apoiadas por tipos de máquina menores do Compute Engine têm mais chances de ter recursos disponíveis. Por exemplo, o tipo de máquina padrão do Autopilot tem a maior disponibilidade. Para conferir uma lista de classes de computação e os tipos de máquina correspondentes, consulte Quando usar classes de computação específicas.
  • Se você executa cargas de trabalho de GPU, a GPU solicitada pode não estar disponível no local do nó. Tente implantar a carga de trabalho em um local diferente ou solicitar um tipo diferente de GPU.

Para evitar problemas de escalonamento vertical causados pela disponibilidade de recursos no futuro, considere as seguintes abordagens:

Falha no escalonamento vertical dos nós: recursos zonais do pod excedidos

O problema a seguir ocorre quando o Autopilot não provisiona novos nós para um pod em uma zona específica porque um novo nó violaria os limites de recursos.

A mensagem de erro nos registros é semelhante a esta:

    "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              ...

Esse erro refere-se a um evento noScaleUp, em que o provisionamento automático de nós não provisionou nenhum grupo de nós para o pod na zona.

Se você encontrar esse erro, confirme o seguinte:

Problemas com a carga de trabalho

Pods travados no estado pendente

Um pod pode ficar travado no status Pending se você selecionar um nó específico para que ele use, mas a soma das solicitações de recursos no pod e nos DaemonSets que precisam ser executados no nó excede o capacidade máxima alocável do nó. Isso pode fazer com que o pod tenha um status Pending e permaneça não programado.

Para evitar esse problema, avalie os tamanhos das cargas de trabalho implantadas para garantir que estejam dentro das solicitações máximas de recursos do Autopilot compatíveis.

Tente também programar os DaemonSets antes de programar os pods de carga de trabalho regulares.

Desempenho de carga de trabalho consistentemente não confiável em um nó específico

No GKE versão 1.24 e posterior, se as cargas de trabalho em um nó específico tiverem consistentemente interrupções, falhas ou comportamentos semelhantes não confiáveis, é possível informar o GKE sobre o nó problemático restringindo ele com o seguinte comando:

kubectl drain NODE_NAME --ignore-daemonsets

Substitua NODE_NAME pelo nome do nó problemático. Para encontrar o nome do nó, execute kubectl get nodes.

O GKE faz o seguinte:

  • Remove as cargas de trabalho atuais do nó e interrompe a programação de cargas de trabalho nele.
  • Recria automaticamente todas as cargas de trabalho removidas que são gerenciadas por um controlador, como uma implantação ou um StatefulSet, em outros nós.
  • Encerra quaisquer cargas de trabalho que permaneçam no nó e repara ou recria o nó ao longo do tempo.
  • Se você usar o Autopilot, o GKE será encerrado e substituirá o nó imediatamente e ignorará qualquer PodDisruptionBudgets configurado.

A programação de pods em clusters vazios leva mais tempo do que o esperado

Esse evento ocorre quando você implanta uma carga de trabalho em um cluster do Autopilot que não tem outras cargas de trabalho. Os clusters do Autopilot começam sem nós utilizáveis e são escalonados para zero nós se o cluster estiver vazio para evitar recursos de computação não utilizados. A implantação de uma carga de trabalho em um cluster com nenhum nó aciona um evento de escalonamento vertical.

Se isso acontecer, o Autopilot estará funcionando conforme o esperado e nenhuma ação será necessária. A carga de trabalho será implantada conforme o esperado após a inicialização dos novos nós.

Verifique se os pods estão aguardando novos nós:

  1. Descreva seu pod pendente:

    kubectl describe pod POD_NAME

    Substitua POD_NAME pelo nome do pod pendente.

  2. Verifique a seção Events da saída. Se o pod estiver aguardando novos nós, a saída será semelhante a esta:

    Events:
  Type     Reason            Age   From                                   Message
  ----     ------            ----  ----                                   -------
  Warning  FailedScheduling  11s   gke.io/optimize-utilization-scheduler  no nodes available to schedule pods
  Normal   TriggeredScaleUp  4s    cluster-autoscaler                     pod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-9293c6db-grp 0->1 (max: 1000)} {https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-d99371e7-grp 0->1 (max: 1000)}]

    O evento TriggeredScaleUp mostra que o cluster está escalonando verticalmente de zero nós para quantos nós são necessários para executar a carga de trabalho implantada.

A seguir

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