Resolução de problemas de clusters do Autopilot

Esta página mostra como resolver problemas com clusters do Autopilot do Google Kubernetes Engine (GKE).

Problemas de cluster

Não é possível criar um cluster: 0 nós registados

O seguinte problema ocorre quando tenta criar um cluster do Autopilot com uma conta de serviço do IAM desativada ou que não tem as autorizaçõ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 predefinida do Compute Engine ou a conta de serviço do IAM personalizada que quer usar está desativada:

    gcloud iam service-accounts describe SERVICE_ACCOUNT

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

    Se a conta de serviço estiver desativada, o resultado é semelhante ao seguinte:

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

  2. Se a conta de serviço estiver desativada, ative-a:

    gcloud iam service-accounts enable SERVICE_ACCOUNT

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

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

O espaço de nomes fica bloqueado no estado de encerramento quando o cluster tem 0 nós

O seguinte problema ocorre quando elimina um espaço de nomes num cluster depois de o cluster ser reduzido para zero nós. O componente metrics-server não pode aceitar o pedido de eliminação do espaço de nomes porque o componente tem zero réplicas.

Para diagnosticar este problema, execute o seguinte comando:

kubectl describe ns/NAMESPACE_NAME

Substitua NAMESPACE_NAME pelo nome do espaço de nomes.

O resultado é o seguinte:

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 este problema, aumente a escala de qualquer carga de trabalho para acionar o GKE de modo a criar um novo nó. Quando o nó estiver pronto, o pedido de eliminação do espaço de nomes é concluído automaticamente. Depois de o GKE eliminar o espaço de nomes, reduza a escala da carga de trabalho.

Problemas de dimensionamento

O aumento da escala do nó falhou: o pod está em risco de não ser agendado

O problema seguinte ocorre quando o registo da porta série está desativado no seu projetoTrusted Cloud by S3NS . Os clusters do GKE Autopilot requerem o registo em porta série para depurar eficazmente os problemas dos nós. Se o registo da porta série estiver desativado, o Autopilot não pode aprovisionar nós para executar as suas cargas de trabalho.

A mensagem de erro no registo de eventos do Kubernetes é semelhante à seguinte:

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

O registo de portas série pode ser desativado ao nível da organização através de uma política da organização que aplique a restrição compute.disableSerialPortLogging. O registo da porta série também pode ser desativado ao nível do projeto ou da instância de máquina virtual (VM).

Para resolver este problema, faça o seguinte:

  1. Peça ao administrador da política da sua Trusted Cloud by S3NS organização para remover a restrição compute.disableSerialPortLogging no projeto com o seu cluster do Autopilot.
  2. Se não tiver uma política da organização que aplique esta restrição, experimente ativar o registo da porta série nos metadados do projeto. Esta ação requer a compute.projects.setCommonInstanceMetadataautorização da IAM.

Falha no aumento da escala do nó: o GCE está sem recursos

O problema seguinte ocorre quando as suas cargas de trabalho pedem mais recursos do que os disponíveis para utilização nessa região ou zona do Compute Engine. Os seus Pods podem permanecer no estado Pending.

  • Verifique os eventos do Pod:

    kubectl events --for='pod/POD_NAME' --types=Warning

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

    O resultado é semelhante ao seguinte:

    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 este problema, experimente o seguinte:

  • Implemente o pod numa região ou zona diferente. Se o seu pod tiver uma restrição zonal, como um seletor de topologia, remova a restrição, se possível. Para ver instruções, consulte o artigo Coloque pods do GKE em zonas específicas.
  • Crie um cluster numa região diferente e tente novamente a implementação.
  • Experimente usar uma classe de computação diferente. As classes de computação suportadas por tipos de máquinas do Compute Engine mais pequenos têm maior probabilidade de ter recursos disponíveis. Por exemplo, o tipo de máquina predefinido para o Autopilot tem a disponibilidade mais elevada. Para ver uma lista das classes de computação e dos tipos de máquinas correspondentes, consulte o artigo Quando usar classes de computação específicas.
  • Se executar cargas de trabalho de GPU, a GPU pedida pode não estar disponível na localização do nó. Experimente implementar a sua carga de trabalho numa localização diferente ou pedir um tipo de GPU diferente.

Para evitar problemas de expansão causados pela disponibilidade de recursos no futuro, considere as seguintes abordagens:

Falha ao aumentar a escala dos nós: recursos zonais de pods excedidos

O seguinte problema ocorre quando o Autopilot não aprovisiona novos nós para um pod numa zona específica porque um novo nó violaria os limites de recursos.

A mensagem de erro nos seus registos é semelhante à seguinte:

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

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

Se encontrar este erro, confirme o seguinte:

Problemas com cargas de trabalho

Cargas de trabalho bloqueadas com erro de armazenamento efémero

O GKE não cria pods se os pedidos de armazenamento efémero de pods excederem o máximo de 10 GiB do Autopilot na versão 1.28.6-gke.1317000 e posterior do GKE.

Para diagnosticar este problema, descreva o controlador da carga de trabalho, como a implementação ou o trabalho:

kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME

Substitua o seguinte:

  • CONTROLLER_TYPE: o tipo de controlador de carga de trabalho, como replicaset ou daemonset. Para ver uma lista de tipos de controladores, consulte o artigo Gestão de carga de trabalho.
  • CONTROLLER_NAME: o nome da carga de trabalho bloqueada.

Se o Pod não for criado porque o pedido de armazenamento efémero excede o máximo, o resultado é semelhante ao seguinte:

# lines omitted for clarity

Events:

{"[denied by autogke-pod-limit-constraints]":["Max ephemeral-storage requested by init containers for workload '' is higher than the Autopilot maximum of '10Gi'.","Total ephemeral-storage requested by containers for workload '' is higher than the Autopilot maximum of '10Gi'."]}

Para resolver este problema, atualize os seus pedidos de armazenamento efémero para que o armazenamento efémero total pedido pelos contentores de carga de trabalho e pelos contentores que os webhooks injetam seja inferior ou igual ao máximo permitido. Para mais informações sobre o máximo, consulte Pedidos de recursos no Autopilot. para a configuração da carga de trabalho.

Pods bloqueados no estado pendente

Um pod pode ficar bloqueado no estado Pending se selecionar um nó específico para o pod usar, mas a soma dos pedidos de recursos no pod e nos DaemonSets que têm de ser executados no nó exceder a capacidade máxima alocável do nó. Isto pode fazer com que o seu Pod tenha o estado Pending e permaneça não agendado.

Para evitar este problema, avalie os tamanhos das cargas de trabalho implementadas para garantir que estão dentro dos pedidos máximos de recursos suportados para o Autopilot.

Também pode tentar agendar os DaemonSets antes de agendar os seus Pods de carga de trabalho normais.

Desempenho da carga de trabalho consistentemente não fiável num nó específico

Na versão 1.24 e posterior do GKE, se as suas cargas de trabalho num nó específico sofrerem consistentemente interrupções, falhas ou um comportamento não fiável semelhante, pode informar o GKE sobre o nó problemático isolando-o através do seguinte comando:

kubectl drain NODE_NAME --ignore-daemonsets

Substitua NODE_NAME pelo nome do nó problemático. Pode encontrar o nome do nó executando kubectl get nodes.

O GKE faz o seguinte:

  • Expulsa as cargas de trabalho existentes do nó e para de agendar cargas de trabalho nesse nó.
  • Recria automaticamente todas as cargas de trabalho desalojadas que são geridas por um controlador, como uma implementação ou um StatefulSet, noutros nós.
  • Termina todas as cargas de trabalho que permanecem no nó e repara ou recria o nó ao longo do tempo.
  • Se usar o Autopilot, o GKE encerra e substitui o nó imediatamente e ignora quaisquer PodDisruptionBudgets configurados.

Os pods demoram mais tempo do que o esperado a serem agendados em clusters vazios

Este evento ocorre quando implementa uma carga de trabalho num cluster do Autopilot que não tem outras cargas de trabalho. Os clusters do Autopilot começam com zero nós utilizáveis e são reduzidos para zero nós se o cluster estiver vazio para evitar ter recursos de computação não utilizados no cluster. A implementação de uma carga de trabalho num cluster com zero nós aciona um evento de expansão.

Se isto acontecer, o Autopilot está a funcionar conforme previsto e não é necessária nenhuma ação. A sua carga de trabalho é implementada conforme esperado após o arranque dos novos nós.

Verifique se os seus pods estão à espera de novos nós:

  1. Descreva o seu Pod pendente:

    kubectl describe pod POD_NAME

    Substitua POD_NAME pelo nome do seu Pod pendente.

  2. Verifique a secção Events do resultado. Se o Pod estiver à espera de novos nós, o resultado é semelhante ao seguinte:

    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á a ser dimensionado de zero nós para o número de nós necessários para executar a carga de trabalho implementada.

Os pods do sistema não conseguem ser agendados em clusters vazios

Este evento ocorre quando nenhuma das suas cargas de trabalho está a ser executada num cluster, o que resulta na redução do cluster para zero nós. Os clusters do Autopilot começam com zero nós utilizáveis e são reduzidos para zero nós se não estiver a executar nenhuma das suas cargas de trabalho no cluster. Este comportamento minimiza os recursos de computação desperdiçados no cluster.

Quando um cluster é reduzido para zero nós, as cargas de trabalho do sistema do GKE não são agendadas e permanecem no estado Pending. Este é o comportamento esperado e não é necessária nenhuma ação. Da próxima vez que implementar uma carga de trabalho no cluster, o GKE vai aumentar a escala do cluster e os pods do sistema pendentes vão ser executados nesses nós.

Para verificar se os pods do sistema estão pendentes devido a um cluster vazio, faça o seguinte:

  1. Verifique se o cluster tem nós:

    kubectl get nodes

    A saída é a seguinte, o que indica que o cluster tem zero nós:

    No resources found

  2. Verifique o estado dos pods do sistema:

    kubectl get pods --namespace=kube-system

    O resultado é semelhante ao seguinte:

    NAME                                                       READY   STATUS    RESTARTS   AGE
antrea-controller-horizontal-autoscaler-6d97f7cf7c-ngfd2   0/1     Pending   0          9d
egress-nat-controller-84bc985778-6jcwl                     0/1     Pending   0          9d
event-exporter-gke-5c5b457d58-7njv7                        0/2     Pending   0          3d5h
event-exporter-gke-6cd5c599c6-bn665                        0/2     Pending   0          9d
konnectivity-agent-694b68fb7f-gws8j                        0/2     Pending   0          3d5h
konnectivity-agent-7d659bf64d-lp4kt                        0/2     Pending   0          9d
konnectivity-agent-7d659bf64d-rkrw2                        0/2     Pending   0          9d
konnectivity-agent-autoscaler-5b6ff64fcd-wn7fw             0/1     Pending   0          9d
konnectivity-agent-autoscaler-cc5bd5684-tgtwp              0/1     Pending   0          3d5h
kube-dns-65ccc769cc-5q5q7                                  0/5     Pending   0          3d5h
kube-dns-7f7cdb9b75-qkq4l                                  0/5     Pending   0          9d
kube-dns-7f7cdb9b75-skrx4                                  0/5     Pending   0          9d
kube-dns-autoscaler-6ffdbff798-vhvkg                       0/1     Pending   0          9d
kube-dns-autoscaler-8b7698c76-mgcx8                        0/1     Pending   0          3d5h
l7-default-backend-87b58b54c-x5q7f                         0/1     Pending   0          9d
metrics-server-v1.31.0-769c5b4896-t5jjr                    0/1     Pending   0          9d

  3. Verifique o motivo pelo qual os pods do sistema têm o estado Pending:

    kubectl describe pod --namespace=kube-system SYSTEM_POD_NAME

    Substitua SYSTEM_POD_NAME pelo nome de qualquer Pod do sistema a partir do resultado do comando anterior.

    O resultado é semelhante ao seguinte:

    ...
Events:
Type     Reason            Age                       From               Message
----     ------            ----                      ----               -------
Warning  FailedScheduling  4m35s (x27935 over 3d5h)  default-scheduler  no nodes available to schedule pods
...

    Na saída, o valor no nodes available to schedule pods no campo Message do evento FailedScheduling indica que o pod do sistema não foi agendado porque o cluster está vazio.

O acesso aos nós subjacentes é proibido num cluster do GKE Autopilot. Assim, é necessário executar o utilitário tcpdump a partir de um pod e, em seguida, copiá-lo com o comando kubectl cp. Se executar geralmente o utilitário tcpdump a partir de um pod num cluster do GKE Autopilot, pode ver o seguinte erro:

    tcpdump: eth0: You don't have permission to perform this capture on that device
    (socket: Operation not permitted)

Isto acontece porque o GKE Autopilot, por predefinição, aplica um contexto de segurança a todos os pods que removem a capacidade NET_RAW para mitigar potenciais vulnerabilidades. Por exemplo:

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: tcpdump
  name: tcpdump
spec:
  containers:
  - image: nginx
    name: nginx
    resources:
      limits:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
      requests:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
    securityContext:
      capabilities:
        # This section drops NET_RAW to mitigate security vulnerabilities
        drop:
        - NET_RAW

Como solução, se a sua carga de trabalho exigir a capacidade NET_RAW, pode reativá-la:

  1. Adicione a capacidade NET_RAW à secção securityContext da especificação YAML do seu pod:

    securityContext:
  capabilities:
    add:
    - NET_RAW

  2. Executar tcpdump a partir de um agrupamento:

    tcpdump port 53 -w packetcap.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

  3. Use o comando kubectl cp para o copiar para o seu computador local para análise adicional:

    kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME

  4. Use kubectl exec para executar o comando tcpdump para realizar a captura de pacotes de rede e redirecionar o resultado:

    kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap

O que se segue?