O que fazer se um pod não for removido?
O que é remoção
Quando ocorre uma exceção em um nó, o Kubernetes expulsa os pods do nó para garantir a disponibilidade da carga de trabalho.
No Kubernetes, tanto o kube-controller-manager quanto o kubelet podem remover pods.
- Remoção implementada por kube-controller-manager
kube-controller-manager consiste em vários controladores, e a remoção é implementada pelo controlador do nó. O controlador verifica periodicamente o status de todos os nós. Quando um nó está no estado NotReady por um período de tempo, todos os pods no nó são removidos.
kube-controller-manager fornece os seguintes parâmetros de inicialização para controlar remoções:
- pod-eviction-timeout: um intervalo quando um nó está inativo, após o qual pods nesse nó são removidos. O intervalo padrão é de 5 minutos.
- node-eviction-rate: uma taxa na qual os nós são removidos, que é implementada pelo algoritmo de controle de tráfego do bucket do token. O valor padrão é 0.1, indicando que 0,1 nós são removidos por segundo. Observe que essa taxa não é a taxa na qual os pods são removidos, mas a taxa na qual os nós são removidos. Ou seja, um nó é limpo a cada 10 segundos.
- secondary-node-eviction-rate: taxa de remoção secundária. Quando um grande número de nós está inativo no cluster, a taxa de remoção diminui. O valor padrão é 0.01.
- unhealthy-zone-threshold: limite para que uma zona seja considerada insalubre. Esse parâmetro determina quando ativar a taxa de remoção secundária. O valor padrão é 0.55. Ou seja, se a porcentagem de nós descendentes em uma zona exceder 55%, a zona é insalubre.
- large-cluster-size-threshold: limite para que um cluster seja considerado grande. Quando o número de nós em uma zona excede esse limite, a zona é considerada como um cluster grande. Se a porcentagem de nós inativos em um cluster grande exceder 55%, a taxa de remoção será reduzida para 0,01. Se o cluster for pequeno, a taxa de remoção é reduzida para 0.
- Remoção implementada pelo kubelet
Se os recursos de um nó forem usados, o kubelet executa a política de remoção com base na prioridade do pod, no uso de recursos e na solicitação de recursos. Se os pods tiverem a mesma prioridade, o pod que usar mais recursos ou solicitar mais recursos será removido primeiro.
kube-controller-manager expulsa todos os pods em um nó, enquanto kubelet remove certos pods em um nó. Os pods a serem removidos são determinados pelo QoS do pod. O kubelet verifica periodicamente os recursos de memória e disco do nó. Se os recursos são insuficientes, os pods são removidos com base na prioridade.
Existem limites de remoção suave e limites de remoção dura.
- Limite de remoção suave: um período de carência é definido para recursos de nó. O kubelet recuperará os recursos do nó associados a esse limite se esse período de tolerância for excedido. Se o uso do recurso do nó atingir esse limite, mas ficar abaixo dele antes que o período de carência seja excedido, o kubelet não irá remover pods no nó.
- Limite de remoção dura: pods são imediatamente removidos uma vez que este limite é atingido.
O kubelet fornece os seguintes parâmetros para controlar as remoções:
- eviction-soft descreve um conjunto de limites de remoção que, se atendidos durante um período de carência correspondente, acionariam uma remoção do pod. Por exemplo, se memory.available for menor que 1,5 Gi, a remoção do pod será executada somente depois que o período de carência especificado por eviction-soft-grace-period for excedido.
- eviction-soft-grace-period: um conjunto de períodos de tolerância de remoção que correspondem a quanto tempo um limite de remoção suave deve conter antes de acionar uma remoção de pod. O valor padrão é 90 segundos.
- eviction-max-pod-grace-period: período de carência máximo permitido para usar ao encerrar pods em resposta a um limite de remoção suave que está sendo atingido.
- eviction-pressure-transition-period: duração pela qual o kubelet tem que esperar antes de fazer a transição para fora de uma condição de pressão de remoção. O valor padrão é 5 minutos. Se o tempo exceder o limite, o nó é definido para pressão de memória ou pressão de disco e, em seguida, a remoção de pod é iniciada.
- eviction-minimum-reclaim: número mínimo de recursos que devem ser recuperados em cada remoção.
- eviction-hard descreve um conjunto de limites de remoção (como memory.available<1Gi) que, se atendidos, acionariam uma remoção de pod.
Localização de falha
Se os pods não forem removidos quando o nó estiver com defeito, execute as seguintes etapas para localizar a falha:
Depois que o comando a seguir é executado, a saída do comando mostra que muitos pods estão no estado Evicted.
kubectl get pods
cat /var/paas/sys/log/kubernetes/kubelet.log | grep -i Evicted -C3
Processo de solução de problemas
Os métodos de solução de problemas são classificados com base na probabilidade de ocorrência das possíveis causas. É aconselhável verificar as possíveis causas de alta probabilidade para baixa probabilidade para localizar rapidamente a causa do problema.
Se a falha persistir após uma possível causa ser corrigida, verifique outras possíveis causas.
- Item de verificação 1: se as tolerâncias foram configuradas no pod
- Item de verificação 2: se as condições para parar a remoção do pod são atendidas
- Item de verificação 3: se os recursos alocados do contêiner são os mesmos que os do nó
- Item de verificação 4: se o pod falha continuamente e é reimplementado
Item de verificação 1: se as tolerâncias foram configuradas no pod
Use kubectl ou escolha More > Edit YAML ao lado da carga de trabalho correspondente para verificar se as tolerâncias estão instaladas na carga de trabalho. Para mais detalhes, veja https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/.
Item de verificação 2: se as condições para parar a remoção do pod são atendidas
Se o número de nós em um cluster for menor que 50 e o número de nós defeituosos representar mais de 55% do total de nós, a remoção do pod será suspensa. Nesse caso, o Kubernetes tentará remover a carga de trabalho no nó defeituoso. Para obter detalhes, consulte https://kubernetes.io/docs/concepts/architecture/nodes/.
Item de verificação 3: se os recursos alocados do contêiner são os mesmos que os do nó
Um contêiner removido é frequentemente agendado para o nó original.
Possível causa
Um nó remove um contêiner com base no uso de recursos do nó. O contêiner removido é agendado com base nos recursos de nó alocados. Remoção e agendamento são baseados em regras diferentes. Portanto, um contêiner removido pode ser agendado para o nó original novamente.
Solução
Aloque adequadamente os recursos para cada contêiner.
Item de verificação 4: se o pod falha continuamente e é reimplementado
Um pod de carga de trabalho no cluster falha e está sendo reimplementado constantemente.
Análise
Depois que um pod é removido e agendado para um novo nó, se pods nesse nó também estiverem sendo removidos, o pod será removido novamente. Pods podem ser removidos repetidamente.
Se a remoção for acionada por kube-controller-manager, um pod no estado Terminating é deixado. Ele é automaticamente excluído somente depois que o nó onde o contêiner está localizado é restaurado. Se o nó tiver sido excluído ou não puder ser restaurado devido a outros motivos, você poderá excluir o pod à força.
Se a remoção for acionada pelo kubelet, um pod no estado Evicted é deixado. Ele é usado apenas para localização de falhas subsequentes e pode ser excluído diretamente.
Solução
Execute o seguinte comando para excluir os pods removidos:
kubectl get pods <namespace> | grep Evicted | awk '{print $1}' | xargs kubectl delete pod <namespace>
No comando anterior, <namespace> indica o nome do namespace. Defina-o com base nos requisitos do site.
Referência
Submissão de um tíquete de serviço
Se o problema persistir, envie um tíquete de serviço.
