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 console do Google Cloud ou a ferramenta de linha de comando kubectl.

kubectl get pods

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

kubectl describe pod POD_NAME

kubectl logs POD_NAME

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. Quando um contêiner falha ou sai logo após a inicialização (CrashLoop), o Kubernetes tenta reiniciá-lo. A cada reinicialização falha, o atraso (BackOff) antes da próxima tentativa aumenta exponencialmente (10s, 20s, 40s, etc.), até um máximo de cinco minutos.

As seções a seguir ajudam a identificar por que o contêiner pode estar falhando.

Usar o playbook interativo de pods com loop de falhas

Comece a resolver problemas sobre o que está causando um status CrashLoopBackOff usando o livro de estratégia interativo no console do Google Cloud:

1. Acesse o manual interativo de pods com Crashlooping:

   Acessar o manual

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

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

4. Siga cada uma das seções para identificar a causa:

   1. Identificar erros do aplicativo
   2. Investigar problemas de falta de memória
   3. Investigue as interrupções de nós
   4. Investigar falhas de sondagem de atividade
   5. Correlacionar eventos de mudança

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

Inspecionar registros

Um contêiner pode falhar por vários motivos. Verificar os registros de um pod ajuda na solução de problemas da causa raiz.

É possível verificar os registros com o console do Google Cloud ou a ferramenta de linha de comando kubectl.

Verificar o código de saída do contêiner com falha

Para entender melhor por que o contêiner falhou, encontre o código de saída:

1. Descreva o pod:

   kubectl describe pod POD_NAME
   

   Substitua POD_NAME pelo nome do pod problemático.

2. Revise o valor no campo containers: CONTAINER_NAME: last state: exit code:

   • Se o código de saída for 1, o contêiner falhou porque o aplicativo falhou.
   • Se o código de saída for 0, verifique por quanto tempo seu app estava sendo executado. Os contêineres saem quando o processo principal do aplicativo é encerrado. Se seu aplicativo concluir a execução rápido demais, o contêiner pode continuar reiniciando. Se você receber esse erro, uma solução é definir o campo restartPolicy como OnFailure. Depois de fazer essa mudança, o app só será reiniciado quando o código de saída não for 0.

Conectar-se a um contêiner em execução

Para executar comandos bash no contêiner e testar a rede ou verificar se você tem acesso a arquivos ou bancos de dados usados pelo aplicativo, abra um shell para o pod:

kubectl exec -it POD_NAME -- /bin/bash

Se houver mais de um contêiner no pod, adicione -c CONTAINER_NAME.

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.

Verifique esse problema usando o console do Google Cloud ou a ferramenta de linha de comando kubectl.

kubectl describe pod POD_NAME

Problema: a imagem não foi encontrada

Se a imagem não for encontrada, siga estas etapas:

1. Verifique se o nome da imagem está correto.
2. Verifique se a tag da imagem está correta. (Tente :latest ou nenhuma tag para extrair a imagem mais recente).
3. Se a imagem tiver um caminho de registro completo, verifique se ela existe no registro do Docker que você está usando. Se você fornecer apenas o nome da imagem, verifique o registro do Docker Hub.

4. Em clusters do GKE Standard, tente extrair a imagem do Docker manualmente:

   1. Use o SSH para se conectar ao nó:

      Por exemplo, para usar o SSH para se conectar a uma VM, execute o seguinte comando:

      gcloud compute ssh VM_NAME --zone=ZONE_NAME
      

      Substitua:

      • VM_NAME: o nome da VM.
      • ZONE_NAME: uma zona do Compute Engine.

   2. Gere um arquivo de configuração em /home/[USER]/.docker/config.json:

      docker-credential-gcr configure-docker
      

      Verifique se o arquivo de configuração em /home/[USER]/.docker/config.json inclui o registro da imagem no campo credHelpers. Por exemplo, o arquivo a seguir inclui informações de autenticação para imagens hospedadas em asia.gcr.io, eu.gcr.io, gcr.io, marketplace.gcr.io e us.gcr.io:

      {
      "auths": {},
      "credHelpers": {
        "asia.gcr.io": "gcr",
        "eu.gcr.io": "gcr",
        "gcr.io": "gcr",
        "marketplace.gcr.io": "gcr",
        "us.gcr.io": "gcr"
      }
      }
      

   3. Tente extrair a imagem:

      docker pull IMAGE_NAME
      

   Se a extração da imagem funcionar manualmente, provavelmente será necessário especificar ImagePullSecrets em um pod. Os pods só podem referenciar segredos de extração de imagem em seu próprio namespace, portanto, esse processo precisa ser feito uma vez por namespace.

Erro: permissão recusada

Se você encontrar um erro de "permissão negada" ou "sem acesso para extrair", verifique se você está conectado e/ou tem acesso à imagem. Tente um dos métodos a seguir, dependendo do registro em que você hospeda as imagens.

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role="roles/artifactregistry.reader"

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.

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

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

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

   Acessar o manual

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

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

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 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.

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: PodFitsHostPorts

PodFitsHostPorts indica que uma porta que um nó está tentando usar já está em uso.

Para resolver esse problema, verifique o valor hostPort da especificação do pod em spec: containers: ports: hostPort. Pode ser necessário alterar esse valor para outra porta.

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.

kubectl get nodes

kubectl uncordon NODE_NAME

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0