Container Service for Kubernetes:Troubleshoot pod issues

Mensagem de erro

Descrição

Solução

no nodes available to schedule pods.

O cluster não possui nós disponíveis para agendamento de pods.

1. Verifique se algum nó no cluster está no estado NotReady. Se um nó estiver NotReady, inspecione-o e repare-o.

2. Verifique se o pod define um nodeSelector, nodeAffinity ou tolerâncias a taints. Caso nenhuma restrição de agendamento esteja definida, considere adicionar mais nós ao node pool.

• 0/x nodes are available: x Insufficient cpu.

• 0/x nodes are available: x Insufficient memory.

Nenhum nó disponível no cluster consegue atender às solicitações de recursos de CPU ou memória do pod.

Um nó torna-se não agendável quando o total de requests alocados atinge a capacidade, mesmo que a utilização real seja baixa.

Na página de detalhes do cluster alvo, acesse Nodes > Nodes e verifique a taxa de alocação de requests de CPU ou memória para o nó alvo. Passe o mouse sobre a taxa de alocação para visualizar os valores específicos de alocação de recursos.

Para visualizar o uso detalhado de recursos do nó, consulte Use kubectl to view node resource usage.

• Otimizar a configuração de recursos:

  • Se o uso de recursos de um nó for consistentemente inferior aos seus requests, há desperdício de recursos. Reduza a configuração de requests da workload. Consulte Set CPU and memory resource limits for a container.

    Ative resource profiling para obter a configuração recomendada de requests.

  • Ative Horizontal Pod Autoscaler (HPA) para reduzir réplicas durante horários de menor demanda.

• Limpar workloads desnecessárias: Desative ou reduza pods não essenciais.

• Escalar horizontalmente o node pool: Se o uso de recursos nos nós alvo for consistentemente alto, os nós estão saturados. Você pode scale out the node pool.

x node(s) didn't match pod's node affinity/selector.

Os nós existentes não correspondem à política de afinidade de nó do pod (nodeAffinity/nodeSelector). Consulte Assigning Pods to Nodes.

1. Visualize todos os rótulos em um nó.

   Console

   1. Na página de detalhes do cluster alvo, acesse Nodes > Nodes.

   2. Na página Nodes, localize o nó alvo e, na coluna Actions, clique em More > Manage Labels and Taints para visualizar seus rótulos.

   Kubectl

   Substitua <YOUR_NODE_NAME> pelo nome real do seu nó.

   kubectl get node <YOUR_NODE_NAME> --show-labels

2. Verifique e ajuste a regra de afinidade de nó para a workload (deployment).

   Console

   Ao criar uma nova workload:

   1. Na página Advanced para criar um Deployment Create, localize Node Affinity na seção Scheduling e clique em Add.

   2. Configure Required (afinidade rígida) ou Optional (afinidade suave) com base nas necessidades do seu negócio. Múltiplos Selector possuem uma relação lógica AND, enquanto múltiplas Rule possuem uma relação lógica OR.

   Para workloads existentes:

   1. Na página Nodes > Nodes, clique em > Node Affinity na coluna Actions do Deployment alvo.

   2. O método de configuração é o mesmo descrito acima.

   Exemplo YAML

   NodeAffinity

   As políticas de afinidade incluem afinidade rígida (requiredDuringSchedulingIgnoredDuringExecution), que deve ser atendida, e afinidade suave (preferredDuringSchedulingIgnoredDuringExecution), que expressa uma preferência. O exemplo a seguir usa afinidade rígida.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-node-affinity-deploy
         labels:
           app: demo-node-affinity
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: demo-node-affinity
         template:
           metadata:
             labels:
               app: demo-node-affinity
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             affinity:
               nodeAffinity:
                 # Hard affinity: The rule must be met.
                 requiredDuringSchedulingIgnoredDuringExecution:
                   nodeSelectorTerms:
                   - matchExpressions:
                     - key: disktype
                       operator: In
                       values:
                       - ssd
                       - nvme  # Logic: The node's 'disktype' label must be either 'ssd' or 'nvme'.

   NodeSelector

   Isso fornece uma correspondência exata simples. O pod é agendado apenas se os rótulos do nó atenderem às condições.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-node-selector-deploy
         labels:
           app: demo-node-selector
       spec:
         replicas: 2  
         selector:
           matchLabels:
             app: demo-node-selector  
         template:
           metadata:
             labels:
               app: demo-node-selector
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             # The pod is scheduled only if the node has the label disktype=ssd.
             nodeSelector:
               disktype: ssd

• x node(s) didn't match pod affinity rules.

• x node(s) didn't match pod anti-affinity rules.

• Incompatibilidade de regra de afinidade. O pod possui uma regra de pod affinity (por exemplo, exigindo um rótulo específico), mas nenhum nó hospeda um pod com um rótulo correspondente, impedindo o agendamento.

• Conflito de anti-afinidade. O pod possui uma regra de pod anti-affinity (por exemplo, não pode coexistir com outra aplicação), mas todos os nós disponíveis já hospedam um pod conflitante, impedindo o agendamento.

1. Visualize os rótulos dos pods em um nó.

   Console

   1. Na página de detalhes do cluster alvo, acesse Nodes > Nodes.

   2. Na página Nodes, clique em nome do nó alvo para visualizar sua página de detalhes. Role para baixo até a seção Pods para visualizar os valores de rótulo para diferentes pods na coluna Label.

   Kubectl

   • Visualizar pods e seus rótulos em um nó específico: Substitua <YOUR_NAMESPACE> pelo nome do seu namespace e <YOUR_NODE_NAME> pelo nome real do seu nó.

     kubectl get pods -n <YOUR_NAMESPACE> --field-selector spec.nodeName=<YOUR_NODE_NAME> -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels

   • Consultar pods por rótulo: Substitua <LABEL> pelo par chave-valor real do rótulo, como app=nginx.

     kubectl get pods -A -l <LABEL> -o wide

2. Verifique e ajuste a regra de afinidade de pod para a workload (deployment).

   Console

   1. Ao criar uma nova workload, na página Create do Deployment Advanced, localize Pod Affinity/Pod Anti-affinity na seção Scheduling e clique em Add.

   2. Configure Required (afinidade rígida) ou Optional (afinidade suave) com base nas necessidades do seu negócio. Múltiplos Selector possuem uma relação lógica AND, enquanto múltiplas opções Add Rule possuem uma relação lógica OR.

   Exemplo YAML

   As políticas de afinidade classificam-se em afinidade rígida (requiredDuringSchedulingIgnoredDuringExecution) e afinidade suave (preferredDuringSchedulingIgnoredDuringExecution). Regras de afinidade rígida devem ser atendidas, enquanto regras de afinidade suave são preferenciais. O exemplo a seguir mostra uma configuração para uma pod affinity obrigatória.

   Para configurar pod anti-affinity, basta substituir podAffinity por podAntiAffinity.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-podaffinity-deploy
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: demo-podaffinity
         template:
           metadata:
             labels:
               app: demo-podaffinity
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             affinity:
               podAffinity:
                 # Hard affinity: Pod must be co-located with a pod that has the 'app: nginx' label.
                 requiredDuringSchedulingIgnoredDuringExecution:
                 - labelSelector:
                     matchExpressions:
                     - key: app
                       operator: In
                       values:
                       - nginx
                   # Topology domain scope: host-level isolation.
                   topologyKey: kubernetes.io/hostname

0/x nodes are available: x node(s) had volume node affinity conflict.

O agendamento falha devido a um conflito de afinidade de nó de volume. Isso geralmente ocorre porque um disco cloud não pode ser montado em zonas diferentes.

• Para um PV provisionado estaticamente, configure a afinidade de nó do pod para garantir que ele seja agendado em um nó na mesma zona que o PV.

• Para um PV provisionado dinamicamente, defina o volumeBindingMode da StorageClass como WaitForFirstConsumer. Isso garante que o PV seja criado somente após o pod ter sido agendado em um nó, assegurando que o disco cloud seja criado na mesma zona que o nó do pod.

InvalidInstanceType.NotSupportDiskCategory

A instância ECS não suporta o tipo de disco cloud especificado.

Consulte Instance families para confirmar os tipos de disco cloud suportados pela sua instância ECS. Ao montar, atualize o tipo de disco cloud para um que seja suportado pela instância ECS.

0/x nodes are available: x node(s) had taints that the pod didn't tolerate.

O pod não pode ser agendado em um nó porque falta uma tolerância para um dos taints do nó.

• Se o taint foi adicionado manualmente, remova-o ou configure uma tolerância para o pod. Consulte Taints and Tolerations e Manage node labels and taints.

• Se o taint foi adicionado pelo sistema, resolva o problema subjacente abaixo e aguarde o reagendamento.

  Visualizar taints adicionados pelo sistema

  • node.kubernetes.io/not-ready: O nó está no estado NotReady.

  • node.kubernetes.io/unreachable: O nó está inacessível para o controlador de nós. Isso equivale ao status Ready do nó sendo Unknown.

  • node.kubernetes.io/memory-pressure: O nó está sob pressão de memória.

  • node.kubernetes.io/disk-pressure: O nó está sob pressão de disco.

  • node.kubernetes.io/pid-pressure: O nó está sob pressão de PID.

  • node.kubernetes.io/network-unavailable: A rede do nó está indisponível.

  • node.kubernetes.io/unschedulable: O nó está marcado como não agendável.

0/x nodes are available: x Insufficient ephemeral-storage.

O nó possui armazenamento efêmero insuficiente.

1. Verifique a solicitação de armazenamento efêmero do Pod, que é o valor de spec.containers.resources.requests.ephemeral-storage no YAML do Pod. Se o valor for muito alto e exceder a capacidade real disponível do nó, o Pod falhará ao ser agendado.

2. Verifique a capacidade total de armazenamento efêmero em cada nó com kubectl describe node | grep -A10 Capacity. Se for insuficiente, expanda o disco do nó ou adicione mais nós.

0/x nodes are available: pod has unbound immediate persistent volume claims.

O pod falhou ao vincular a uma persistent volume claim (PVC).

Verifique se a PVC ou PV especificado pelo pod foi criado. Execute kubectl describe pvc <pvc-name> ou kubectl describe pv <pv-name> para visualizar eventos de PVC e PV para diagnóstico adicional. Consulte Storage FAQ - CSI.

Mensagem de erro

Descrição

Solução sugerida

Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:

O acesso ao repositório de imagens foi negado porque um imagePullSecret não foi especificado quando o pod foi criado.

Verifique se o Secret especificado no campo spec.imagePullSecrets do arquivo YAML da workload existe.

Ao usar o ACR, utilize um credential helper para fazer pull de imagens sem senha. Consulte Pull images from the same account.

Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host

O endereço do repositório de imagens não pôde ser resolvido ao fazer pull de uma imagem via HTTPS.

1. Verifique se o endereço do repositório de imagens em spec.containers.image do arquivo YAML do pod está correto. Se estiver incorreto, atualize-o.

2. Se o endereço estiver correto, verifique a conectividade de rede do nó onde o pod está sendo executado até o repositório de imagens. Acesse o nó (para mais informações, consulte Choose an ECS remote connection method) e execute o comando curl -kv https://xxxxxx/xxxxx/ para verificar se o endereço está acessível. Se ocorrer um erro, investigate possíveis problemas de rede, como configuração de rede incorreta, regras de firewall ou problemas de resolução DNS.

Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device

O nó possui espaço em disco insuficiente.

Acesse o nó (consulte Choose an ECS remote connection method) e execute df -h para verificar o espaço em disco. Se o disco estiver cheio, redimensione-o. Consulte Step 1: Resize a cloud disk.

Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority

O repositório de imagens de terceiros usa um certificado assinado por uma Autoridade Certificadora (CA) desconhecida ou insegura.

1. O repositório de terceiros deve usar um certificado emitido por uma CA confiável.

2. Se você estiver usando um repositório de imagens privado, consulte Create an application from a private image repository.

3. Se não for possível alterar o certificado, configure o nó para permitir pull e push de imagens de um repositório que usa um certificado inseguro. Recomendamos usar este método apenas em ambientes de teste, pois pode afetar outros pods no nó.

Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

A operação foi cancelada, possivelmente porque o arquivo de imagem é muito grande. O Kubernetes tem um tempo limite padrão para pull de imagens. Se o pull não progredir por um período específico, o Kubernetes assume que a operação falhou ou não está respondendo e cancela a tarefa.

1. Verifique se imagePullPolicy está definido como IfNotPresent no arquivo YAML do pod.

2. Acesse o nó onde o pod está sendo executado (para mais informações, consulte Choose an ECS remote connection method) e execute docker pull ou crictl pull para verificar se a imagem pode ser baixada.

Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Não é possível conectar ao repositório de imagens devido a problemas de rede.

1. Acesse o nó onde o pod está sendo executado (para mais informações, consulte Choose an ECS remote connection method) e execute o comando curl https://xxxxxx/xxxxx/ para verificar se o endereço está acessível. Se ocorrer um erro, investigate possíveis problemas de rede, como configuração de rede incorreta, regras de firewall ou problemas de resolução DNS.

2. Verifique a política de rede pública do nó, incluindo configurações para entradas SNAT e Endereços IP Elásticos (EIPs) vinculados.

Failed to pull image "xxxx:xxx": failed to pull and unpack image "xxxx:xxx": failed to resolve reference "xxxx:xxx": failed to do request: Head "xxxx:xxx": dial tcp xxx.xxx.xx.x:xxx: i/o timeout

Tempo limite de conexão excedido devido a problemas de rede ao fazer pull de uma imagem de um repositório no exterior.

Fazer pull de imagens de repositórios no exterior, como Docker Hub, pode falhar em clusters ACK devido a redes de operadoras instáveis. Para resolver isso, considere as seguintes soluções:

• Assine imagens de source no exterior usando Container Registry. Para instruções, consulte Sync images by using artifact subscription.

• Crie uma instância Global Accelerator (GA) para fazer pull de imagens diretamente usando sua rede de aceleração global. Para detalhes, consulte Accelerate cross-region ACK image pulls with GA.

Too Many Requests.

O Docker Hub impõe limites de taxa nas requisições de pull de imagem.

Faça upload da imagem para Container Registry (ACR) e faça pull dela de um repositório de imagens ACR.

O status Pulling image é exibido consistentemente

O mecanismo de limitação de taxa de pull de imagem do kubelet pode ter sido acionado.

Ajuste o registryPullQPS (QPS máximo para o repositório de imagens) e registryBurst (número máximo de pulls de imagem em rajada) usando o recurso Customize node pool kubelet configurations.

Mensagem de erro

Descrição

Solução

Preso no estado Init:N/M

O pod possui M contêineres init; N concluídos, mas os M-N restantes falharam ao iniciar.

1. Verifique os eventos do pod e problemas de contêiner init com kubectl describe pod -n <ns> <pod name>.

2. Verifique os logs dos contêineres init não iniciados com kubectl logs -n <ns> <pod name> -c <container name>.

3. Revise a configuração do pod, como as configurações de health check, para garantir que os contêineres init estejam configurados corretamente.

Consulte Debug init containers.

Preso no estado Init:Error

Um contêiner init no pod falhou ao iniciar.

Preso no estado Init:CrashLoopBackOff

Um contêiner init no pod falhou ao iniciar e está em um loop de reinicialização.

Mensagem de erro

Descrição

Solução

failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx

Este é um comportamento esperado devido ao design do plugin de rede Flannel.

Atualize o componente Flannel para v0.15.1.11-7e95fe23-aliyun ou posterior. Consulte Flannel.

Em clusters que executam uma versão do Kubernetes anterior a 1.20, pode ocorrer vazamento de endereço IP se um pod reiniciar repetidamente ou se pods de um CronJob concluírem suas tarefas e saírem rapidamente.

Atualize o cluster para Kubernetes 1.20 ou posterior (recomenda-se o mais recente). Consulte Manually upgrade a cluster.

Defeitos no containerd e runC causam esse problema.

Para uma correção de emergência, consulte Why does my pod fail to start with the error "no IP addresses available in range"?

error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found

O plugin de rede Terway mantém um banco de dados interno no nó para rastrear e gerenciar elastic network interfaces (ENIs). Esse erro ocorre quando o estado do banco de dados é inconsistente com a configuração real do dispositivo de rede, causando falha na alocação de ENI.

1. As interfaces de rede carregam de forma assíncrona. A interface ainda pode estar carregando durante a configuração do CNI, o que aciona uma nova tentativa automática do CNI. Esse processo não afeta a alocação final da ENI. Verifique o status final do pod para confirmar o sucesso.

2. Se a criação do pod ainda falhar e esse erro persistir, provavelmente o driver falhou ao carregar a ENI devido à memória de ordem alta insuficiente. Restart the ECS instance para resolver isso.

• cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded

• cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition

O plugin de rede Terway pode ter falhado ao solicitar um endereço IP do vSwitch.

1. Visualize os logs do contêiner Terway dentro do pod do componente Terway no nó para verificar o processo de alocação de ENI.

2. Visualize informações de ENI para o pod Terway com kubectl logs -n kube-system <terwayPodName > -c terway | grep <podName>. Obtenha o Request ID e a mensagem de erro da OpenAPI.

3. Use o Request ID e a mensagem de erro para investigar a falha.

Mensagem de erro

Descrição

Solução

O log contém exit(0).

1. Acesse o nó onde a workload anômala está implantada.

2. Use docker ps -a | grep $podName para verificar. Se o contêiner não tiver um processo persistente, ele sai com código de status 0.

Os eventos do pod mostram Liveness probe failed: ....

A sonda de vivacidade falhou, causando a reinicialização da aplicação.

• Configuração da sonda de vivacidade: Na página Edit da Workloads alvo, verifique se o caminho da requisição de health check (por exemplo, /healthz) e a porta correspondem aos fornecidos pela aplicação. Aumente o Initial Delay (s) para garantir que a sonda de vivacidade inicie somente após a aplicação ter sido totalmente lançada.

  Desative temporariamente a Liveness. Em seguida, acesse o terminal do pod ou seu nó host e use um comando, como curl, para verificar se o método de health check funciona corretamente.

• Solucione problemas da aplicação: Investigue o problema verificando os Events e Logs do pod. Selecione Show the log of the last container exit.

Os eventos do pod mostram Startup probe failed: ....

A sonda de inicialização falhou, causando a reinicialização da aplicação.

• Configuração da sonda de inicialização: Na página Edit da Workloads alvo, verifique se o caminho da requisição de health check (por exemplo, /healthz) e a porta correspondem aos fornecidos pela aplicação. Se a aplicação demorar muito para iniciar, aumente o Unhealthy Threshold para evitar reinicializações prematuras.

  Desative temporariamente a Startup. Em seguida, acesse o terminal do pod ou seu nó host e use um comando, como curl, para verificar se o método de health check funciona corretamente.

• Solucione problemas da aplicação: Investigue o problema verificando os Events e Logs do pod. Selecione Show the log of the last container exit.

O log do pod contém no space left on device.

Espaço em disco cloud insuficiente.

• Resize the cloud disk.

• Limpe imagens desnecessárias para liberar espaço em disco e configure imageGCHighThresholdPercent para definir o limiar para coleta de lixo de imagens no nó.

A inicialização falha sem informações de evento.

Esse problema ocorre quando um contêiner requer mais recursos do que seus limites declarados, causando sua falha.

Verifique se a configuração de recursos do pod está correta. Ative resource profiling para obter configurações recomendadas de Request e Limit para o contêiner.

O log do pod mostra Address already in use.

Existe um conflito de porta entre contêineres no mesmo pod.

1. Verifique se o pod está configurado com hostNetwork: true. Essa configuração faz com que os contêineres no pod compartilhem o namespace de rede e o espaço de porta do host. Se isso não for necessário, altere para hostNetwork: false.

2. Se o pod exigir hostNetwork: true, configure pod anti-affinity para garantir que pods do mesmo replica set sejam agendados em nós diferentes.

3. Verifique se nenhum outro pod no mesmo nó está usando a porta.

O log do pod mostra container init caused "setenv: invalid argument": unknown.

A workload monta um Secret, mas o valor no Secret não está codificado em Base64.

• Crie o Secret no console (os valores são codificados em Base64 automaticamente). Consulte Manage Secrets.

• Crie o Secret a partir de um arquivo YAML e codifique manualmente o valor em Base64 executando o comando echo -n "xxxxx" | base64.

Problema específico da aplicação.

Examine os logs do pod para solucionar o problema.

Mensagem de erro

Descrição

Solução

Os eventos do pod mostram Readiness probe failed: ....

A sonda de prontidão falhou, impedindo o pod alvo de receber tráfego.

• Configuração da sonda de prontidão: Na página Edit da Workloads alvo, verifique se o caminho do health check (por exemplo, /healthz) e a porta correspondem aos da aplicação. Se a aplicação iniciar lentamente, aumente o Unhealthy Threshold para evitar falhas prematuras.

  Desative temporariamente a Readiness, então use curl no terminal do pod ou host para verificar o endpoint de health check.

• Solucione problemas da aplicação: Investigue o problema verificando os Events e Logs do pod. Selecione Show the log of the last container exit.

O status do pod é o mesmo acima. Os eventos do pod mostram Startup probe failed: ....

Uma sonda de inicialização com falha causa a reinicialização do contêiner. Este erro não deve resultar em um estado Running/NotReady persistente, mas sim em um estado 'CrashLoopBackOff'.

Solucione este problema conforme descrito na seção "Falha na inicialização do Pod (CrashLoopBackOff)" para Startups.

Nível de OOM

Descrição

Solução recomendada

Nível de SO

Verifique o log do kernel em /var/log/messages no nó do pod. Se o log mostrar um processo eliminado, mas não contiver logs de cgroup, o evento OOM ocorreu no nível do SO.

• Aumente a memória do nó ou distribua workloads em mais nós. Consulte Scale node resources e Schedule applications to specific nodes.

• Identifique Pods com alto consumo de memória no nó e defina limites de memória apropriados.

Nível de cgroup

Verifique o log do kernel em /var/log/messages no nó do pod. Se o log contiver uma mensagem de erro semelhante a Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx, o evento OOM ocorreu no nível do cgroup.

• Aumente os limites de memória do Pod. Mantenha o uso real abaixo de 80% dos limites. Consulte Manage Pods e Scale node resources.

• Ative resource profiling para obter configurações recomendadas de request e limit do contêiner.

Causa possível

Descrição

Solução recomendada

O nó está no estado NotReady.

O pod é excluído automaticamente após o nó se recuperar do estado NotReady.

O pod está configurado com finalizers.

Se um pod estiver configurado com finalizers, o Kubernetes executa as operações de limpeza especificadas pelos finalizers antes de excluir o pod. Se uma operação de limpeza falhar ao responder, o pod permanece no estado Terminating.

Verifique a configuração de finalizer do pod com kubectl get pod -n <ns> <pod name> -o yaml e investigue a causa.

O hook preStop do pod é inválido ou está travado.

Se um hook preStop estiver configurado para o pod, o Kubernetes executa o hook antes de terminar o contêiner. O pod permanece no estado Terminating enquanto o hook está em execução.

Verifique a configuração do hook preStop do pod com kubectl get pod -n <ns> <pod name> -o yaml e investigue a causa.

Um período de desligamento gracioso está configurado para o pod.

Se um Pod estiver configurado com um período de desligamento gracioso (terminationGracePeriodSeconds), o Pod entra no estado Terminating após receber um comando de término, como kubectl delete pod <pod_name>. O Kubernetes considera o Pod desligado com sucesso somente após o tempo especificado em terminationGracePeriodSeconds decorrer ou o contêiner sair.

O Kubernetes exclui automaticamente o pod após o contêiner concluir um desligamento gracioso.

O contêiner não responde.

Quando você solicita parar ou excluir um pod, o Kubernetes envia um sinal SIGTERM para os contêineres no pod. Se um contêiner não lidar corretamente com o sinal SIGTERM durante o término, o pod pode permanecer no estado Terminating.

1. Force a exclusão do pod com kubectl delete pod <pod-name> --grace-period=0 --force.

2. Verifique os logs do containerd ou Docker no nó do pod para investigar mais.

Causa possível

Descrição

Solução recomendada

O nó está sob pressão de recursos devido a fatores como uso de memória ou disco.

O nó pode estar enfrentando pressão de memória, pressão de disco ou pressão de PID.

• Verifique os taints do nó com kubectl describe node <node name> | grep Taints. A saída pode incluir:

  • Pressão de memória: O nó tem o taint node.kubernetes.io/memory-pressure.

  • Pressão de disco: O nó tem o taint node.kubernetes.io/disk-pressure.

  • Pressão de PID: O nó tem o taint node.kubernetes.io/pid-pressure.

• O status do pod é um dos seguintes:

  • Evicted

  • ContainerStatusUnknown, e o campo reason no arquivo YAML do pod mostra Evicted.

• Pressão de memória:

  • Ajuste a configuração de recursos do pod com base nos requisitos do seu negócio. Consulte Manage pods.

  • Atualize o nó. Consulte Scale node resources.

• Pressão de disco:

  • Limpe periodicamente logs de aplicação dos pods no nó para liberar espaço em disco.

  • Expanda o disco do nó. Consulte Step 1: Resize a cloud disk.

• Pressão de PID: Ajuste a configuração de recursos do pod. Consulte Process ID Limits and Reservations.

Ocorre uma evicção inesperada.

Um taint NoExecute adicionado manualmente no nó do pod causou uma evicção inesperada.

Verifique se há um taint NoExecute com kubectl describe node <node name> | grep Taints. Se existir, remova-o.

A evicção não prossegue conforme o esperado.

• --pod-eviction-timeout: Pods em um nó com falha são evacuados após este período de tempo limite. O padrão é 5 minutos.

• --node-eviction-rate: O número de pods evacuados de um nó por segundo. O padrão é 0,1, significando que no máximo um pod é evacuado de um nó a cada 10 segundos.

• --secondary-node-eviction-rate: A taxa secundária de evicção de nó. Se muitos nós em um cluster falharem, a taxa de evicção é reduzida para este valor. O padrão é 0,01.

• --unhealthy-zone-threshold: O limiar de zona de disponibilidade não saudável. O padrão é 0,55. Quando a fração de nós com falha em uma zona de disponibilidade excede este limiar, a zona é considerada não saudável.

• --large-cluster-size-threshold: O limiar de tamanho de cluster grande. O padrão é 50. Um cluster é considerado grande quando tem mais de 50 nós.

Em um cluster pequeno (50 nós ou menos), se mais de 55% dos nós falharem, a evicção de pods para. Consulte Rate limits on eviction.

Em um cluster grande (mais de 50 nós), se a fração de nós não saudáveis exceder o --unhealthy-zone-threshold (padrão 0,55), a taxa de evicção cai para --secondary-node-eviction-rate (padrão 0,01 pods por segundo). Consulte Rate limits on eviction.

Um pod é frequentemente reagendado para seu nó original após ser evacuado.

O kubelet evacua pods com base no uso real de recursos, enquanto o scheduler coloca pods com base em requests de recursos. Como uma evicção libera recursos, o scheduler pode reagendar um pod para o mesmo nó se seus requests ainda couberem.

Ajuste os requests de recursos do pod para caber nos recursos alocáveis do nó. Consulte Set CPU and memory resources for a container. Ative resource profiling para obter valores recomendados de request e limit.