Resolver problemas com cargas de trabalho implantadas

Nesta página, mostramos como resolver erros com as cargas de trabalho implantadas no Google Kubernetes Engine (GKE).

Para conselhos mais gerais sobre a solução de problemas de aplicativos, consulte Solução de problemas de aplicativos na documentação do Kubernetes.

Todos os erros: verificar o status do pod

Se houver problemas com os pods de uma carga de trabalho, o Kubernetes vai atualizar o status do pod com uma mensagem de erro. Para conferir esses erros, verifique o status de um pod usando o Google Cloud console ou a ferramenta de linha de comando kubectl.

Console

Siga as etapas abaixo:

  1. No Google Cloud console, acesse a página Cargas de trabalho.

    Acesse "Cargas de trabalho"

  2. Selecione a carga de trabalho que você quer investigar. A guia Visão geral exibe o status da carga de trabalho.

  3. Na seção Gerenciar pods, clique em qualquer mensagem de status de erro.

kubectl

Para ver todos os pods em execução no cluster, execute o seguinte comando:

kubectl get pods

O resultado será assim:

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

Os possíveis erros são listados na coluna Status.

Para mais informações sobre um pod específico, execute o seguinte comando:

kubectl describe pod POD_NAME

Substitua POD_NAME pelo nome do pod que você quer investigar.

Na saída, o campo Events mostra mais informações sobre erros.

Para mais informações, consulte os registros do contêiner:

kubectl logs POD_NAME

Esses registros podem ajudar a identificar se um comando ou código no contêiner causou a falha do pod.

Depois de identificar o erro, use as seções a seguir para tentar resolver o problema.

Erro: CrashLoopBackOff

Um status de CrashLoopBackOff não significa que há um erro específico, mas indica que um contêiner está falhando repetidamente após a reinicialização.

Para mais informações, consulte Resolver problemas de eventos CrashLoopBackOff.

Erros: ImagePullBackOff e ErrImagePull

Um status de ImagePullBackOff ou ErrImagePull indica que a imagem usada por um contêiner não pode ser carregada do registro de imagem.

Para orientações sobre como resolver problemas com esses status, consulte Resolver problemas de extração de imagens.

Erro: OutOfPods

Um status de OutOfPods indica que um nó não pode executar um pod porque atingiu a capacidade máxima de pods.

Sintomas

Você pode encontrar uma mensagem nos eventos do pod semelhante a esta:

Node didn't have enough resource: pods, requested: 1, used: 32, capacity: 32

Causa

Esse erro ocorre quando há uma solicitação para programar um pod em um nó que já está na capacidade máxima. Essa situação pode ocorrer com frequência durante a inicialização do nó, por exemplo, quando o componente kube-scheduler atribui pods a um novo nó antes que o agente kubelet tenha informado a presença de pods estáticos, como o componente kube-proxy, que exigem a própria capacidade de pod.

Resolução

Para resolver esse problema, tente uma das seguintes soluções:

  • Aumente o número máximo de pods por nó. Se os nós atingirem consistentemente o limite de pods, aumente a configuração --max-pods-per-node para os pools de nós. O aumento do número de pods pode exigir nós maiores para lidar com o aumento das demandas de recursos.

  • Ative o escalonador automático de clusters e o provisionamento automático de nós. Se você ficar sem capacidade de pods com frequência, ativar o escalonador automático de clusters e o provisionamento automático de nós pode ajudar a garantir que o cluster tenha nós suficientes para atender à demanda das cargas de trabalho.

  • Mude o perfil de escalonamento automático. Se você já usa o cluster escalonador automático, tente mudar o perfil de escalonamento automático para o balanced perfil em vez do optimize-utilization perfil. O perfil optimize-utilization pode aumentar a probabilidade de erros OutOfPods porque tenta colocar pods nos nós mais utilizados.

Erro: o pod não pode ser programado

Um status de PodUnschedulable indica que o pod não pode ser programado devido a recursos insuficientes ou a algum erro de configuração.

Se você tiver configurado métricas do plano de controle, encontre mais informações sobre esses erros em métricas do programador e métricas do servidor da API.

Usar o manual interativo de pods não programáveis

É possível resolver erros PodUnschedulable usando o manual interativo no Google Cloud console:

  1. Acesse o manual interativo de pods não programáveis:

    Acessar o manual

  2. Na lista suspensa Cluster, selecione o cluster que você quer resolver. Se não encontrar o cluster, digite o nome dele no Filtrar campo.

  3. Na lista suspensa Namespace, selecione o namespace que você quer resolver. Se não encontrar o namespace, digite-o no Filtrar campo.

  4. Para ajudar a identificar a causa, siga cada uma das seções do manual:

    1. Investigar CPU e memória
    2. Investigar o máximo de pods por nó
    3. Investigar comportamento do escalador automático
    4. Investigar outros modos de falha
    5. Correlacionar eventos de mudança

  5. Opcional: para receber notificações sobre futuros erros PodUnschedulable, na seção Dicas de mitigação futura, selecione Criar um alerta.

Erro: recursos insuficientes

Um status PodUnschedulable pode ocorrer se não houver CPU, memória ou outros recursos suficientes para atender às solicitações do pod.

Sintomas

Talvez você encontre um erro indicando falta de CPU, memória ou outro recurso. Por exemplo: No nodes are available that match all of the predicates: Insufficient cpu (2). Essa mensagem indica que, em dois nós, não há CPU suficiente disponível para atender às solicitações de um pod.

Causa

Se as solicitações de recursos do pod excederem o de um único nó de qualquer pool de nós qualificado, o GKE não vai programar o pod e também não acionará o escalonamento vertical para adicionar um novo nó.

O cluster executa contêineres do sistema no namespace kube-system. Esses contêineres também usam recursos de cluster.

Resolução

Tente as seguintes soluções:

  • Ajuste a solicitação de recursos do pod especificando um valor menor no campo spec: containers: resources: requests. A solicitação de CPU padrão é 100m ou 10% de uma CPU (ou um núcleo).

  • Crie um novo pool de nós com nós que tenham recursos suficientes para atender às solicitações do pod.

  • Ative o provisionamento automático de nós para que o GKE possa criar automaticamente pools de nós com nós em que os pods não programados podem ser executados.

Erro: MatchNodeSelector

Um erro MatchNodeSelector indica que não há nós que correspondam ao seletor de rótulos do pod.

Sintomas

O status ou os eventos do pod mostram um erro MatchNodeSelector.

Causa

Os rótulos especificados no campo nodeSelector do manifesto do pod não existem em nenhum nó no cluster.

Resolução

Para resolver esse erro, verifique se os rótulos especificados no campo nodeSelector do pod correspondem aos rótulos em pelo menos um nó no cluster:

  1. Identifique os requisitos de rótulo que o pod está procurando verificando o campo spec: nodeSelector.

  2. Para saber se algum rótulo corresponde aos requisitos do pod, confira os rótulos reais atribuídos aos nós no cluster:

    kubectl get nodes --show-labels

  3. Se um nó for destinado a executar esse pod, anexe o rótulo necessário:

    kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

    Substitua:

    • NODE_NAME: o nó em que você quer adicionar um rótulo.
    • LABEL_KEY: a chave do rótulo.
    • LABEL_VALUE: o valor do rótulo.

Para mais informações, consulte Como atribuir pods a nós na documentação do Kubernetes.

Erro: PodToleratesNodeTaints

Um erro PodToleratesNodeTaints indica que o pod não pode ser programado para nenhum nó porque ele não tem tolerâncias que correspondam aos taints de nó existentes.

Sintomas

O status ou os eventos do pod mostram um erro PodToleratesNodeTaints.

Causa

O pod não pode ser programado para nenhum nó porque ele não tem tolerâncias que correspondam aos taints de nó existentes.

Resolução

  1. Verifique os taints no nó:

    kubectl describe nodes NODE_NAME

    Na saída, verifique o campo Taints, que lista pares de valor-chave e efeitos de programação. Se o efeito listado for NoSchedule, nenhum pod poderá ser programado nesse nó, a menos que exista uma tolerância correspondente .

  2. Remova o taint do nó. Por exemplo, para remover um taint NoSchedule, execute o seguinte comando:

    kubectl taint nodes NODE_NAME key:NoSchedule-

Erro: PodFitsHostPorts

O erro PodFitsHostPorts significa que um nó está tentando usar uma porta que já está ocupada.

Sintomas

O status do pod mostra um erro PodFitsHostPorts.

Causa

Um pod está solicitando uma porta de host que já está em uso por outro pod ou processo no nó de destino.

Resolução

Para resolver o problema, siga as práticas recomendadas do Kubernetes e use um serviço NodePort em vez da configuração hostPort.

Se você precisar usar uma porta de host, verifique os manifestos dos pods e verifique se todos os pods no mesmo nó têm valores exclusivos definidos para a configuração hostPort.

Erro: não há disponibilidade mínima

Esse erro pode ocorrer se um nó tiver recursos adequados, mas não estiver disponível para programação.

Sintomas

  • Você encontra o erro Does not have minimum availability.

  • O status do nó mostra um status SchedulingDisabled ou Cordoned.

Causa

O status restrito do nó impede que novos pods sejam programados nele.

Resolução

Para disponibilizar o nó para programar pods novamente, remova a restrição:

Console

Siga as etapas abaixo:

  1. Acesse a página do Google Kubernetes Engine no Google Cloud console do.

    Acessar o Google Kubernetes Engine

  2. Selecione o cluster que você quer investigar. A guia Nós exibe os nós e o status deles.

Para ativar a programação no nó, execute as seguintes etapas:

  1. Na lista, clique no nó que você quer investigar.

  2. Na seção Detalhes do nó, clique em Não programável.

kubectl

Para receber o status dos seus nós, execute o seguinte comando:

kubectl get nodes

Para ativar a programação no nó, execute:

kubectl uncordon NODE_NAME

Erro: o limite máximo de pods por nó foi atingido

Um erro Too many pods indica que um pod não pode ser programado porque o nó de destino atingiu a capacidade máxima de pods configurada.

Sintomas

  • Os pods ficam presos em um estado Unschedulable.
  • Você encontra uma mensagem que inclui a frase Too many pods.

Causa

O limite máximo de pods por nó é atingido por todos os nós no cluster.

Resolução

Para resolver esse erro, siga estas etapas:

  1. Verifique a configuração de Maximum pods per node na guia "Nós" nos detalhes do cluster do GKE no Google Cloud console do Google Cloud.

  2. Consulte uma lista de nós:

    kubectl get nodes

  3. Para cada nó, verifique o número de pods em execução nele:

    kubectl get pods -o wide | grep NODE_NAME | wc -l

  4. Se o limite for atingido, adicione um novo pool de nós ou adicione mais nós ao atual.

Problema: tamanho máximo do pool de nós atingido com o escalonador automático de clusters ativado

Esse problema ocorre quando um pool de nós atinge o tamanho máximo configurado no escalonador automático de clusters.

Sintomas

O GKE não aciona escalonar verticalmente de um pod que seria programado com esse pool de nós. Em vez disso, o pod permanece em um estado Pending.

Causa

O pool de nós atingiu o seu tamanho máximo de acordo com a configuração do escalonador automático de clusters.

Resolução

Aumente o tamanho máximo do pool de nós mudando a configuração do escalonador automático de clusters.

Problema: tamanho máximo do pool de nós atingido com o escalonador automático de cluster desativado

Esse problema ocorre quando um pool de nós atinge o tamanho máximo e o escalonador automático de clusters está desativado.

Sintomas

O GKE não pode programar o pod com o pool de nós.

Causa

O pool de nós atingiu o número máximo de nós e o escalonador automático de clusters está desativado.

Resolução

Para resolver esse problema, tente uma das seguintes soluções:

Erro: PersistentVolumeClaims não vinculados

Um erro Unbound PersistentVolumeClaims indica que o pod se refere a uma PersistentVolumeClaim não vinculada.

Sintomas

O status ou os eventos do pod mostram um erro Unbound PersistentVolumeClaims.

Causa

Esse erro pode ocorrer por um dos seguintes motivos:

  • O PersistentVolume não foi provisionado.
  • Ocorreu um erro de configuração durante o pré-provisionamento manual de um PersistentVolume e sua vinculação a um PersistentVolumeClaim.

Resolução

  1. Verifique se o provisionamento falhou acessando os eventos do seu PersistentVolumeClaim:

    kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

    Substitua:

    • STATEFULSET_NAME: o nome do objeto StatefulSet.
    • PVC_NAME: o nome do objeto PersistentVolumeClaim.

  2. Tente pré-provisionar o volume novamente.

Erro: cota insuficiente

Se o GKE tentar escalonar verticalmente o cluster para programar um pod, mas encontrar restrições de cota, o escalonamento vertical falhará.

Sintomas

Você recebe a mensagem de erro scale.up.error.quota.exceeded nos eventos do pod.

Causa

O escalonamento vertical do cluster excederia a cota disponível do projeto.

Resolução

Verifique se o projeto tem cota suficiente do Compute Engine para o GKE escalonar verticalmente o cluster. Para mais informações, consulte Erros de ScaleUp.

Problema: APIs descontinuadas

O uso de APIs que não são mais compatíveis nos manifestos pode impedir a implantação da carga de trabalho.

Sintomas

As cargas de trabalho não são implantadas ou executadas devido ao uso de APIs descontinuadas.

Causa

Os manifestos usam APIs descontinuadas que são removidas na versão secundária do cluster.

Resolução

Verifique se você não está usando APIs descontinuadas. Atualize os manifestos para usar APIs compatíveis. Para mais informações, consulte Descontinuações de recursos e APIs.

Erro: não havia portas livres para as portas de pod solicitadas

A vinculação de um pod a uma porta de host limita onde o GKE pode programar o pod, porque cada combinação de endereço hostIP, configuração hostPort e valor protocol precisa ser exclusiva.

Sintomas

Você vai encontrar um erro semelhante ao seguinte:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Causa

Vários pods no mesmo nó especificam o mesmo valor definido no campo hostPort.

Resolução

Para resolver esse problema, tente uma das seguintes soluções:

  • Siga as práticas recomendadas do Kubernetes e use um serviço NodePort em vez de uma porta de host.
  • Se você precisar usar uma porta de host, verifique os manifestos dos pods e verifique se todos os pods no mesmo nó têm valores exclusivos definidos para o campo hostPort.

Problema: falhas de aplicativos e de sondagens em pods

Esse problema ocorre quando você executa aplicativos que usam HTTPS para se comunicar com um servidor.

Sintomas

As falhas nesses aplicativos são semelhantes às seguintes:

  • Os pods não são iniciados e os contêineres falham com o código de saída 137.

  • Os probes de atividade ou prontidão falham com uma mensagem de erro semelhante a esta:

    probeResult="failure" output="Get "https://example.com/healthy": EOF"

  • Os pods são executados conforme o esperado, mas os registros de aplicativos mostram falhas de conexão.

Causa

As versões 1.30 e mais recentes do Kubernetes usam versões do Golang que desativam os seguintes pacotes de criptografia TLS:

  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

Resolução

Use pacotes de criptografia compatíveis do TLS 1.2 e versões mais recentes.

A seguir