Esta página mostra como resolver erros com as cargas de trabalho implementadas no Google Kubernetes Engine (GKE).
Para obter aconselhamento mais geral sobre a resolução de problemas das suas aplicações, consulte o artigo Resolução de problemas de aplicações na documentação do Kubernetes.
Todos os erros: verifique o estado do pod
Se existirem problemas com os pods de uma carga de trabalho, o Kubernetes atualiza o estado do pod
com uma mensagem de erro. Veja estes erros verificando o estado de um pod através da
consola ou da ferramenta de linha de comandos kubectl. Google Cloud
Consola
Siga estes passos:
Na Google Cloud consola, aceda à página Workloads.
Selecione a carga de trabalho que quer investigar. O separador Vista geral apresenta o estado da carga de trabalho.
Na secção Pods geridos, clique em qualquer mensagem de estado de erro.
kubectl
Para ver todos os pods em execução no seu cluster, execute o seguinte comando:
kubectl get pods
O resultado é semelhante ao seguinte:
NAME READY STATUS RESTARTS AGE
POD_NAME 0/1 CrashLoopBackOff 23 8d
Os potenciais erros são apresentados na coluna Status.
Para obter informações mais detalhadas sobre um pod específico, execute o seguinte comando:
kubectl describe pod POD_NAME
Substitua POD_NAME pelo nome do pod que quer investigar.
No resultado, o campo Events mostra mais informações sobre os erros.
Se quiser ver mais informações, consulte os registos do contentor:
kubectl logs POD_NAME
Estes registos podem ajudar a identificar se um comando ou um código no contentor causou a falha de sistema do pod.
Depois de identificar o erro, use as secções seguintes para tentar resolver o problema.
Erro: CrashLoopBackOff
O estado CrashLoopBackOff não significa que exista um erro específico. Em vez disso, indica que um contentor está a falhar repetidamente após o reinício.
Para mais informações, consulte o artigo Resolva problemas de eventos CrashLoopBackOff.
Erros: ImagePullBackOff e ErrImagePull
Um estado de ImagePullBackOff ou ErrImagePull indica que não é possível carregar a imagem usada por um contentor a partir do registo de imagens.
Para orientações sobre a resolução de problemas destes estados, consulte o artigo Resolva problemas de obtenção de imagens.
Erro: o pod não é agendável
Um estado de PodUnschedulable indica que não é possível agendar o seu Pod devido a recursos insuficientes ou a algum erro de configuração.
Se tiver configurado métricas do plano de controlo, pode encontrar mais informações acerca destes erros nas métricas do programador e nas métricas do servidor da API.
Use o manual interativo de pods não agendáveis
Pode resolver problemas de erros PodUnschedulable através do manual interativo
na consola Google Cloud :
Aceda ao manual interativo de pods não agendáveis:
Na lista pendente Cluster, selecione o cluster que quer resolver. Se não conseguir encontrar o cluster, introduza o nome do cluster no campo Filtrar.
Na lista pendente Namespace, selecione o espaço de nomes que quer resolver. Se não conseguir encontrar o seu espaço de nomes, introduza-o no campo Filtro.
Para ajudar a identificar a causa, siga cada uma das secções do playbook:
- Investigue a CPU e a memória
- Investigue o número máximo de pods por nó
- Investigue o comportamento do escalador automático
- Investigue outros modos de falha
- Correlacione eventos de alteração
Opcional: para receber notificações sobre erros futuros, na secção Sugestões de mitigação futuras, selecione Criar um alerta.
PodUnschedulable
Erro: recursos insuficientes
Pode encontrar um erro que indica uma 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 existe CPU suficiente disponível para satisfazer os pedidos de um pod.
Se os pedidos de recursos do Pod excederem os de um único nó de qualquer conjunto de nós elegível, o GKE não agenda o Pod e também não aciona o aumento da escala para adicionar um novo nó. Para que o GKE agende o pod, tem de pedir menos recursos para o pod ou criar um novo conjunto de nós com recursos suficientes.
Também pode ativar o aprovisionamento automático de nós para que o GKE possa criar automaticamente conjuntos de nós com nós onde os pods não agendados podem ser executados.
O pedido de CPU predefinido é de 100 m ou 10% de uma CPU (ou um núcleo).
Se quiser pedir mais ou menos recursos, especifique o valor na especificação do pod em spec: containers: resources: requests.
Erro: MatchNodeSelector
MatchNodeSelector indica que não existem nós que correspondam ao seletor de etiquetas do pod.
Para verificar isto, consulte as etiquetas especificadas no campo nodeSelector da especificação do pod, em spec: nodeSelector.
Para ver como os nós no cluster estão etiquetados, execute o seguinte comando:
kubectl get nodes --show-labels
Para anexar uma etiqueta a um nó, execute o seguinte comando:
kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE
Substitua o seguinte:
NODE_NAME: o nó ao qual quer adicionar uma etiqueta.LABEL_KEY: a chave da etiqueta.LABEL_VALUE: o valor da etiqueta.
Para mais informações, consulte o artigo Atribuir pods a nós na documentação do Kubernetes.
Erro: PodToleratesNodeTaints
PodToleratesNodeTaints indica que não é possível agendar o pod para nenhum nó porque o pod não tem tolerâncias que correspondam a contaminações de nós existentes.
Para verificar se é este o caso, execute o seguinte comando:
kubectl describe nodes NODE_NAME
No resultado, verifique o campo Taints, que apresenta pares chave-valor e
efeitos de agendamento.
Se o efeito apresentado for NoSchedule, não é possível agendar nenhum Pod nesse nó, a menos que tenha uma tolerância correspondente.
Uma forma de resolver este problema é remover a mancha. Por exemplo, para remover uma contaminação NoSchedule, execute o seguinte comando:
kubectl taint nodes NODE_NAME key:NoSchedule-
Erro: PodFitsHostPorts
O erro PodFitsHostPorts significa que um nó está a tentar usar uma porta que já está ocupada.
Para resolver o problema, considere seguir as práticas recomendadas do Kubernetes e usar um NodePort em vez de um hostPort.
Se tiver de usar um hostPort, verifique os manifestos dos pods e certifique-se de que todos os pods no mesmo nó têm valores únicos definidos para hostPort.
Erro: não tem disponibilidade mínima
Se um nó tiver recursos adequados, mas continuar a ver a mensagem Does not have minimum availability
, verifique o estado do pod. Se o estado for SchedulingDisabled ou Cordoned, o nó não pode agendar novos pods. Pode verificar o estado de um nó através da Google Cloud consola ou da ferramenta de linha de comandos kubectl.
Consola
Siga estes passos:
Aceda à página do Google Kubernetes Engine na Google Cloud consola.
Selecione o cluster que quer investigar. O separador Nodes apresenta os nós e o respetivo estado.
Para ativar a programação no nó, siga estes passos:
Na lista, clique no nó que quer investigar.
Na secção Detalhes do nó, clique em Desativar isolamento.
kubectl
Para obter os estados dos seus nós, execute o seguinte comando:
kubectl get nodes
Para ativar o agendamento no nó, execute o seguinte comando:
kubectl uncordon NODE_NAME
Erro: foi atingido o limite máximo de pods por nó
Se o limite de agrupamentos máximos por nó for atingido por todos os nós no cluster, os agrupamentos ficam bloqueados no estado de agendamento impossível. No separador Eventos do podcast, é apresentada uma mensagem
com a expressão Too many pods.
Para resolver este erro, conclua os seguintes passos:
Verifique a configuração do
Maximum pods per nodeno separador Nodes (Nós) dos detalhes do cluster do GKE na Google Cloud consola.Obtenha uma lista de nós:
kubectl get nodesPara cada nó, verifique o número de pods em execução no nó:
kubectl get pods -o wide | grep NODE_NAME | wc -lSe o limite for atingido, adicione um novo conjunto de nós ou adicione nós adicionais ao conjunto de nós existente.
Problema: foi atingido o tamanho máximo do conjunto de nós com o escalador automático do cluster ativado
Se o conjunto de nós tiver atingido o respetivo tamanho máximo de acordo com a configuração do escalador automático do cluster, o GKE não aciona o aumento da escala para o pod que, de outra forma, seria agendado com este conjunto de nós. Se quiser que o pod seja agendado com este conjunto de nós, altere a configuração do autoscaler do cluster.
Problema: tamanho máximo do node pool atingido com o redimensionador automático de cluster desativado
Se o conjunto de nós tiver atingido o número máximo de nós e o dimensionamento automático do cluster estiver desativado, o GKE não pode agendar o pod com o conjunto de nós. Aumente o tamanho do seu conjunto de nós ou ative o dimensionamento automático do cluster para que o GKE redimensione o cluster automaticamente.
Erro: Unbound PersistentVolumeClaims
Unbound PersistentVolumeClaims indica que o Pod faz referência a um PersistentVolumeClaim que não está associado. Este erro pode ocorrer se o seu PersistentVolume não tiver sido aprovisionado. Pode verificar se o aprovisionamento falhou ao
obter os eventos para o seu PersistentVolumeClaim e examiná-los para
detetar falhas.
Para obter eventos, execute o seguinte comando:
kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0
Substitua o seguinte:
STATEFULSET_NAME: o nome do objeto StatefulSet.PVC_NAME: o nome do objeto PersistentVolumeClaim.
Isto também pode acontecer se tiver ocorrido um erro de configuração durante o pré-aprovisionamento manual de um PersistentVolume e a respetiva associação a um PersistentVolumeClaim.
Para resolver este erro, tente pré-aprovisionar o volume novamente.
Erro: quota insuficiente
Verifique se o seu projeto tem quota suficiente do Compute Engine para o GKE aumentar a escala do cluster. Se o GKE tentar adicionar um nó ao seu cluster para agendar o pod e o aumento da escala exceder a quota disponível do seu projeto, recebe a mensagem de erro scale.up.error.quota.exceeded.
Para saber mais, consulte o artigo Erros do ScaleUp.
Problema: APIs descontinuadas
Certifique-se de que não está a usar APIs descontinuadas que são removidas com a versão secundária do cluster. Para saber mais, consulte o artigo Descontinuações de funcionalidades e APIs.
Erro: não tinha portas livres para as portas do agrupamento pedidas
Se vir um erro semelhante ao seguinte, é provável que tenha 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 associação de um agrupamento a um hostPort limita onde o GKE pode agendar o agrupamento, porque cada combinação de hostIP, hostPort e protocol tem de ser única.
Para resolver o problema, considere seguir as
práticas recomendadas do Kubernetes
e usar um NodePort em vez de um hostPort.
Se tiver de usar um hostPort, verifique os manifestos dos pods e certifique-se de que todos os pods no mesmo nó têm valores únicos definidos para hostPort.
O que se segue?
Se não conseguir encontrar uma solução para o seu problema na documentação, consulte a secção Obtenha apoio técnico para receber mais ajuda, incluindo aconselhamento sobre os seguintes tópicos:
- Abrindo um registo de apoio ao cliente através do contacto com o Cloud Customer Care.
- Receber apoio técnico da comunidade fazendo perguntas no StackOverflow e usando a etiqueta
google-kubernetes-enginepara pesquisar problemas semelhantes. Também pode juntar-se ao#kubernetes-enginecanal do Slack para receber mais apoio técnico da comunidade. - Abrir erros ou pedidos de funcionalidades através do rastreador de problemas público.