Problemas com seus clusters do Autopilot do Google Kubernetes Engine (GKE) podem afetar a disponibilidade e a eficiência operacional do seu aplicativo. Esses problemas podem interromper todo o ciclo de vida dos aplicativos, desde a implantação inicial até o escalonamento sob carga.
Use esta página para diagnosticar e resolver problemas comuns específicos dos clusters do
Autopilot. Encontre orientações sobre como resolver problemas de criação de cluster
que impedem o provisionamento do cluster, problemas de escalonamento, como erros out
of resources
, e problemas específicos da carga de trabalho, como erros de armazenamento
temporário ou pods presos no estado Pending
.
Essas informações são importantes para desenvolvedores de aplicativos que precisam garantir que os aplicativos sejam implantados e executados sem problemas, e para administradores e operadores de plataforma responsáveis pela integridade geral e pelo gerenciamento de recursos dos clusters do Autopilot. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Funções e tarefas de usuário comuns do GKE.
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:
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, comomy-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 ...
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.defaultNodeServiceAccount
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 projetoGoogle 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:
- 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. - 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 events --for='pod/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:
- Use as classes prioritárias do Kubernetes para provisionar capacidade extra de computação de modo consistente no cluster. Para detalhes, consulte Provisionar capacidade extra de computação para o escalonamento rápido de pods.
- Use as reservas de capacidade do Compute Engine com as classes de computação Performance ou Accelerator. Para mais detalhes, consulte Consumo de recursos zonais reservados.
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:
- Os pods têm memória e CPU suficientes.
- O intervalo CIDR do endereço IP do pod é grande o suficiente para acomodar o tamanho máximo previsto do cluster.
Problemas com a carga de trabalho
Cargas de trabalho com erro de armazenamento temporário
O GKE não vai criar pods se o armazenamento temporário do pod as solicitações excedem o máximo de 10 GiB no Autopilot no GKE versão 1.28.6-gke.1317000 e posterior.
Para diagnosticar esse problema, descreva o controlador de carga de trabalho, como a implantação ou o job:
kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME
Substitua:
CONTROLLER_TYPE
: o tipo de controlador de carga de trabalho, comoreplicaset
oudaemonset
. Para uma lista de tipos de controladores, consulte Carga de trabalho de configuração.CONTROLLER_NAME
: o nome da carga de trabalho travada.
Se o pod não for criado porque a solicitação de armazenamento temporário excedeu o máximo, a saída será semelhante a esta:
# 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 esse problema, atualize as solicitações de armazenamento temporário para que o armazenamento temporário total solicitado por contêineres de carga de trabalho e por contêineres injetados por webhooks seja menor ou igual ao máximo permitido. Para mais informações sobre o máximo, consulte Solicitações de recursos no Autopilot. para a configuração da 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:
Descreva seu pod pendente:
kubectl describe pod POD_NAME
Substitua
POD_NAME
pelo nome do pod pendente.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.
Falha ao programar pods do sistema em clusters vazios
Esse evento ocorre quando nenhuma das suas cargas de trabalho está em execução em um 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 reduzir escala vertical para zero nós se você não estiver executando nenhuma das suas cargas de trabalho no cluster. Esse comportamento minimiza o desperdício de recursos de computação no cluster.
Quando um cluster é reduzido a zero nós, as cargas de trabalho do sistema do GKE
não são programadas e permanecem no estado Pending
. Esse é o comportamento esperado, e nenhuma ação é necessária. Na próxima vez que você implantar uma
carga de trabalho no cluster, o GKE vai escalonar o cluster verticalmente, e os
pods do sistema pendentes serão executados nesses nós.
Para verificar se os pods do sistema estão pendentes devido a um cluster vazio, faça o seguinte:
Verifique se o cluster tem nós:
kubectl get nodes
A saída é a seguinte, indicando que o cluster não tem nós:
No resources found
Verifique o status dos pods do sistema:
kubectl get pods --namespace=kube-system
O resultado será assim:
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
Verifique o motivo de os pods do sistema terem o status
Pending
:kubectl describe pod --namespace=kube-system SYSTEM_POD_NAME
Substitua
SYSTEM_POD_NAME
pelo nome de um pod do sistema na saída do comando anterior.O resultado será assim:
... 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 campoMessage
para o eventoFailedScheduling
indica que o pod do sistema não foi programado porque o cluster está vazio.
Erro relacionado à permissão ao tentar executar o tcpdump em um pod no Autopilot do GKE
O acesso aos nós subjacentes é proibido em um cluster do Autopilot do GKE. Portanto, é necessário executar o utilitário tcpdump
em um pod e copiá-lo usando o comando kubectl cp.
Se você geralmente executa o utilitário tcpdump em um pod no cluster do GKE Autopilot, talvez o seguinte erro apareça:
tcpdump: eth0: You don't have permission to perform this capture on that device
(socket: Operation not permitted)
Isso acontece porque o Autopilot do GKE, por padrão, aplica um contexto de segurança a todos os pods que descartam o recurso NET_RAW
para reduzir possíveis 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 carga de trabalho exigir o recurso NET_RAW
, você poderá reativá-lo:
Adicione o recurso
NET_RAW
à seçãosecurityContext
da especificação YAML do pod:securityContext: capabilities: add: - NET_RAW
Execute
tcpdump
de dentro de um pod:tcpdump port 53 -w packetcap.pcap tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
Use o comando
kubectl cp
para copiá-lo na sua máquina local para uma análise mais detalhada:kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME
Use
kubectl exec
para executar o comandotcpdump
a fim de realizar a captura de pacotes de rede e redirecionar a saída:kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap
A seguir
Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos:
- Abrir um caso de suporte entrando em contato com o Cloud Customer Care.
- Receber suporte da comunidade fazendo perguntas no StackOverflow e usando a tag
google-kubernetes-engine
para pesquisar problemas semelhantes. Você também pode participar do canal do Slack#kubernetes-engine
para receber mais suporte da comunidade. - Abrir bugs ou solicitações de recursos usando o Issue Tracker público.