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 console do Google Cloud ou a ferramenta de linha de comando kubectl.
Console
Siga as etapas abaixo:
No console Google Cloud , acesse a página Cargas de trabalho.
Selecione a carga de trabalho que você quer investigar. A guia Visão geral exibe o status da carga de trabalho.
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 relacionados a esses status, consulte Resolver problemas de extração de imagens.
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 playbook interativo no console Google Cloud :
Acesse o playbook interativo de pods não programáveis:
Na lista suspensa Cluster, selecione o cluster que você quer resolver problemas. Se não encontrar o cluster, digite o nome dele no campo Filtro.
Na lista suspensa Namespace, selecione o namespace que você quer resolver. Se você não encontrar seu namespace, digite-o no campo Filtro.
Para ajudar a identificar a causa, siga cada uma das seções do manual:
- Investigar CPU e memória
- Investigar o máximo de pods por nó
- Investigar comportamento do escalador automático
- Investigar outros modos de falha
- Correlacionar eventos de mudança
Opcional: para receber notificações sobre futuros erros do
PodUnschedulable, na seção Dicas de mitigação futura, selecione Criar um alerta.
Erro: recursos insuficientes
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), que indica que, em dois nós, não há CPU suficiente
disponível para atender às solicitações de um pod.
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ó. Para que o GKE programe o pod, é necessário solicitar menos recursos para o pod ou criar um novo pool de nós com recursos suficientes.
Também é possível ativar 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.
A solicitação de CPU padrão é 100m ou 10% de uma CPU (ou
um núcleo).
Se quiser solicitar mais ou menos recursos, especifique o valor na especificação do pod em spec: containers: resources: requests
Erro: MatchNodeSelector
MatchNodeSelector indica que não há nós que correspondam ao seletor de
rótulos do pod.
Para verificar isso, confira os rótulos especificados no campo nodeSelector da especificação do pod, em spec: nodeSelector.
Para ver como os nós no cluster são rotulados, execute o seguinte comando:
kubectl get nodes --show-labels
Para anexar um rótulo a um nó, execute o seguinte comando:
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
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.
Para verificar se esse é o caso, execute o seguinte comando:
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.
Uma maneira de resolver esse problema é remover o taint. 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.
Para resolver o problema, siga as práticas recomendadas do Kubernetes e use um NodePort em vez de um hostPort.
Se você precisar usar um hostPort, verifique os manifestos dos pods e confira se todos os pods no mesmo nó têm valores exclusivos definidos para hostPort.
Erro: não há disponibilidade mínima
Se um nó tiver recursos adequados, mas ainda exibir a mensagem Does not have minimum availability, verifique o status do pod. Se o status for SchedulingDisabled ou Cordoned,
o nó não poderá programar novos pods. É possível verificar o status de um
nó usando o console do Google Cloud ou a ferramenta de linha de comando kubectl.
Console
Siga as etapas abaixo:
Acesse a página do Google Kubernetes Engine no Google Cloud console.
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:
Na lista, clique no nó que você quer investigar.
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
Se o limite Máximo de pods por nó
for atingido por todos os nós no cluster, os pods ficarão presos no
estado não programável. Na guia Eventos do pod, é mostrada uma mensagem
incluindo a frase Too many pods.
Para resolver esse erro, siga estas etapas:
Verifique a configuração de
Maximum pods per nodena guia "Nós" nos detalhes do cluster do GKE no console Google Cloud .Consulte uma lista de nós:
kubectl get nodesPara cada nó, verifique o número de pods em execução nele:
kubectl get pods -o wide | grep NODE_NAME | wc -lSe 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
Se o pool de nós atingir seutamanho máximo De acordo com a configuração do escalonador automático de cluster, o GKE não aciona o escalonamento vertical do pod que seria programado com esse pool de nós. Se você quiser que o pod seja programado com esse pool de nós, altere 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
Se o pool de nós atingir o número máximo de nós e o escalonador automático de cluster estiver desativado, o GKE não poderá programar o pod com o pool de nós. Aumente o tamanho do pool de nós ou ative o escalonador automático de clusters para que o GKE redimensione seu cluster automaticamente.
Erro: PersistentVolumeClaims não vinculados
Unbound PersistentVolumeClaims indica que o pod se refere a uma
PersistentVolumeClaim não vinculada. Esse erro pode acontecer caso seu
PersistentVolume falhe ao provisionar. É possível verificar se o provisionamento falhou
procurando por erros nos eventos do seu
PersistentVolumeClaim.
Para acessar eventos, execute o seguinte comando:
kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0
Substitua:
STATEFULSET_NAME: o nome do objeto StatefulSet.PVC_NAME: o nome do objeto PersistentVolumeClaim.
Isso também pode acontecer se houver um erro de configuração durante o pré-provisionamento manual de um PersistentVolume e sua vinculação a um PersistentVolumeClaim.
Para resolver esse erro, tente pré-aprovisionar o volume novamente.
Erro: cota insuficiente
Verifique se o projeto tem cota suficiente do Compute Engine para
o GKE escalonar verticalmente o cluster. Se o GKE tentar adicionar um nó ao cluster para programar o pod e o escalonamento vertical exceder a cota disponível do projeto, você receberá a mensagem de erro scale.up.error.quota.exceeded.
Para saber mais, consulte Erros de ScaleUp.
Problema: APIs descontinuadas
Verifique se você não está usando APIs descontinuadas que foram removidas com a versão secundária do seu cluster. Para saber mais, consulte Descontinuações de recursos e APIs.
Erro: não havia portas livres para as portas de pod solicitadas
Se você encontrar um erro semelhante ao seguinte, provavelmente terá vários pods
no mesmo nó com o mesmo valor definido no campo hostPort:
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.
A vinculação de um pod a um hostPort limita onde o GKE pode programar o
pod, porque cada combinação de hostIP, hostPort e protocol precisa ser
única.
Para resolver o problema, siga as práticas recomendadas do Kubernetes e use um NodePort em vez de um hostPort.
Se você precisar usar um hostPort, verifique os manifestos dos pods e confira se todos os pods no mesmo nó têm valores exclusivos definidos para hostPort.
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-enginepara pesquisar problemas semelhantes. Você também pode participar do canal do Slack#kubernetes-enginepara receber mais suporte da comunidade. - Abrir bugs ou solicitações de recursos usando o Issue Tracker público.