[ad_1]
Problemas de agendamento de pod são um dos erros mais comuns do Kubernetes. Existem várias razões pelas quais um novo Pod pode ficar preso em um Pending esteve com FailedScheduling como sua razão. Um pod mostrando esse status não iniciará nenhum contêiner, portanto, você não poderá usar seu aplicativo.
Os pods pendentes causados por problemas de agendamento geralmente não começam a ser executados sem alguma intervenção manual. Você precisará investigar a causa raiz e tomar medidas para reparar seu cluster. Neste artigo, você aprenderá a diagnosticar e resolver esse problema para aumentar suas cargas de trabalho.
Identificação de um erro de programação com falha
É normal que os pods exibam um Pending status por um curto período de tempo após adicioná-los ao cluster. O Kubernetes precisa agendar instâncias de contêiner para seus nós, e esses nós precisam extrair a imagem de seu registro. O primeiro sinal de um agendamento de pod com falha é quando ele ainda é exibido como Pending depois de decorrido o período normal de arranque. Você pode verificar o status executando o Kubectl’s get pods domínio:
$ kubectl get pods NAME READY STATUS RESTARTS AGE demo-pod 0/1 Pending 0 4m05s
demo-pod tem mais de quatro minutos, mas ainda está no Pending doença. Os pods geralmente não demoram tanto para iniciar os contêineres, então é hora de começar a investigar o que o Kubernetes está esperando.
A próxima etapa de diagnóstico é recuperar o histórico de eventos do pod usando o describe pod domínio:
$ kubectl describe pod demo-pod ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- ... Warning FailedScheduling 4m default-scheduler 0/4 nodes are available: 1 Too many pods, 3 Insufficient cpu.
O histórico de eventos confirma uma FailedScheduling erro é a razão para o prolongado Pending doença. Esse evento é relatado quando o Kubernetes não consegue alocar o número necessário de pods para qualquer um dos nós do trabalhador em seu cluster.
A mensagem do evento revela por que o agendamento é impossível no momento: há quatro nós no cluster, mas nenhum deles pode usar o Pod. Três dos nós têm capacidade de CPU insuficiente, enquanto o outro atingiu um limite no número de pods que pode aceitar.
Compreendendo erros de programação com falha e problemas semelhantes
O Kubernetes só pode agendar pods em nós que tenham recursos sobressalentes disponíveis. Nós com capacidade esgotada de CPU ou memória não podem aceitar mais pods. Os pods também podem falhar ao agendar se solicitarem explicitamente mais recursos do que qualquer nó pode fornecer. Isso mantém a estabilidade do cluster.
O plano de controle do Kubernetes conhece os pods que já estão atribuídos a nós em seu cluster. Ele usa essas informações para determinar o conjunto de nós que podem receber um novo pod. Ocorre um erro de agendamento quando não há candidatos disponíveis, deixando o pod preso Pending até que a capacidade seja liberada.
O Kubernetes também pode falhar ao agendar Pods por outros motivos. Existem várias maneiras pelas quais os nós podem ser considerados inelegíveis para hospedar um pod, apesar de terem recursos de sistema adequados:
- Um administrador pode ter isolado o nó para evitar que ele receba novos pods antes de uma operação de manutenção.
- O nó pode ser contaminado com um efeito que impede o agendamento de pods. O nó não aceitará seu Pod a menos que tenha a tolerância correspondente.
- Seu pod pode estar solicitando um
hostPortque já está vinculado em node. Os nós só podem fornecer um número de porta específico para um único pod por vez. - Seu Pod pode estar usando um
nodeSelectorisso significa que deve ser agendado para um nó com uma tag específica. Nós sem a tag não serão elegíveis. - Afinidades e antiafinidades de pod e nó podem não ter êxito, causando um conflito de agendamento que impede que novos pods sejam aceitos.
- O Pod pode ter um
nodeNamecampo que identifica um nó específico para agendar. O pod ficará preso pendente se esse nó estiver offline ou não puder ser agendado.
é da responsabilidade kube-scheduler, o agendador do Kubernetes, para trabalhar com essas condições e identificar o conjunto de nós que podem receber um novo pod. UMA FailedScheduling O evento ocorre quando nenhum dos nós atende aos critérios.
Resolvendo o estado FailedScheduling
A mensagem que aparece ao lado de FailedScheduling Os eventos geralmente revelam por que cada nó em seu cluster não conseguiu pegar o pod. Você pode usar essas informações para começar a resolver o problema. No exemplo mostrado acima, o cluster tinha quatro pods, três em que o limite de CPU foi atingido e um que excedeu o limite de contagem de pods.
A capacidade do cluster é a causa raiz neste caso. Você pode dimensionar seu cluster com novos nós para resolver problemas de consumo de hardware, adicionando recursos que fornecerão flexibilidade adicional. Como isso também aumentará seus custos, vale a pena verificar primeiro se você tem pods redundantes em seu cluster. A remoção de recursos não utilizados liberará capacidade para novos.
Você pode inspecionar os recursos disponíveis em cada um de seus nós usando o describe node domínio:
$ kubectl describe node demo-node ... Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 812m (90%) 202m (22%) memory 905Mi (57%) 715Mi (45%) ephemeral-storage 0 (0%) 0 (0%) hugepages-2Mi 0 (0%) 0 (0%)
Os pods neste nó já estão solicitando 57% da memória disponível. Se um novo Pod solicitar 1 Gi para si mesmo, o nó não poderá aceitar a solicitação de agendamento. Monitorar essas informações para cada um de seus nós pode ajudá-lo a avaliar se seu cluster está sendo superprovisionado. É importante ter capacidade sobressalente disponível caso um de seus nós fique inativo e suas cargas de trabalho precisem ser reprogramadas para outro.
Falhas de programação devido à falta de nós programáveis exibirão uma mensagem semelhante à seguinte no FailedScheduling evento:
0/4 nodes are available: 4 node(s) were unschedulable
Os nós que não podem ser agendados porque foram isolados incluirão SchedulingDisabled no seu campo de status:
$ kubectl get nodes NAME STATUS ROLES AGE VERSION node-1 Ready,SchedulingDisabled control-plane,master 26m v1.23.3
Você pode descordar o nó para permitir que ele receba novos pods:
$ kubectl uncordon node-1 node/node-1 uncordoned
Quando os nós não são isolados e não possuem recursos suficientes, os erros de programação são normalmente causados por contaminação ou erro incorreto. nodeSelector campo em seu pod. se você estiver usando nodeSelectorverifique se você não cometeu um erro de digitação e se há pods em seu cluster com as tags especificadas.
Quando os nós estiverem contaminados, certifique-se de incluir a tolerância correspondente no manifesto do seu pod. Como exemplo, aqui está um nó que foi corrompido, para que os pods não sejam agendados a menos que tenham um demo-taint: allow tolerância:
$ kubectl taint nodes node-1 demo-taint=allow:NoSchedule
Modifique os manifestos do seu Pod para que eles possam ser agendados no Node:
spec:
tolerations:
- key: demo-taint
operator: Equal
value: allow
effect: NoSchedule
Resolvendo o problema que causou a FailedScheduling state permitirá que o Kubernetes retome o agendamento de seus pods pendentes. Eles começarão a ser executados automaticamente logo após o plano de controle detectar alterações em seus nós. Você não precisa reiniciar ou recriar manualmente seus pods, a menos que o problema seja causado por erros no manifesto de seu pod, como afinidade incorreta ou nodeSelector Campos.
Resumo
FailedScheduling Erros ocorrem quando o Kubernetes não consegue colocar um novo pod em qualquer nó do cluster. Isso geralmente ocorre porque os nós existentes estão com poucos recursos de hardware, como CPU, memória e disco. Quando esse for o caso, você pode resolver o problema dimensionando seu cluster para incluir nós adicionais.
Os erros de programação também surgem quando os pods especificam afinidades, antiafinidades e seletores de nós que não podem satisfazer atualmente os nós disponíveis em seu cluster. Nós isolados e contaminados reduzem ainda mais as opções disponíveis para o Kubernetes. Esse tipo de problema pode ser resolvido verificando seus manifestos quanto a erros de digitação nas tags e removendo as restrições que você não precisa mais.
[ad_2]
