Após excluir todos os nós do trabalhador, por que meus pods não iniciam em novos nós do trabalhador?

Resolva problemas relacionados a falhas na exclusão de nós de trabalho e pods travados.

Nuvem privada virtual Infraestrutura clássica

Você excluiu todos os nós do trabalhador em seu cluster para que exista zero nó do trabalhador. Em seguida, incluiu um ou mais nós do trabalhador. Quando você executa o comando a seguir, vários pods para componentes do Kubernetes estão presos no status ContainerCreating e os pods calico-node estão presos no status CrashLoopBackOff.

oc -n calico-system get pods

Quando você exclui todos os nós do trabalhador em seu cluster, não existe nenhum nó do trabalhador para que o pod calico-kube-controllers seja executado. Os dados do pod do controlador Calico não podem ser atualizados para remover os dados dos nós do trabalhador excluídos. Quando o pod do controlador do Calico começa a ser executado novamente nos novos nós do trabalhador, seus dados não são atualizados para os novos nós do trabalhador e ele não inicia os pods calico-node.

Exclua as entradas do nó do trabalhador calico-node existentes para que novos pods possam ser criados.

Antes de começar: instale a CLI do Calico.

  1. Execute o comando ibmcloud oc cluster config e copie e cole a saída para configurar a variável de ambiente KUBECONFIG. Inclua as opções --admin e --network com o comando ibmcloud oc cluster config. A opção --admin faz download das chaves para acessar o seu portfólio de infraestrutura e executar comandos do Calico em seus nós do trabalhador. A opção --network faz download do arquivo de configuração do Calico para executar todos os comandos do Calico.

    ibmcloud oc cluster config --cluster CLUSTER_NAME_OR_ID --admin --network
    
  2. Para os pods calico-node que estão presos no status CrashLoopBackOff, anote os endereços IP NODE.

    oc -n calico-system get pods -o wide
    

    Nesta saída de exemplo, o pod calico-node não pode iniciar no nó do trabalhador 10.176.48.106.

    NAME                                           READY   STATUS              RESTARTS   AGE     IP              NODE            NOMINATED NODE   READINESS GATES
    ...
    calico-kube-controllers-656c5785dd-kc9x2       1/1     Running             0          25h     10.176.48.107   10.176.48.107   <none>           <none>
    calico-node-mkqbx                              0/1     CrashLoopBackOff    1851       25h     10.176.48.106   10.176.48.106   <none>           <none>
    coredns-7b56dd58f7-7gtzr                       0/1     ContainerCreating   0          25h     172.30.99.82    10.176.48.106   <none>           <none>
    
  3. Obtenha os IDs das entradas do nó do trabalhador calico-node. Copie os IDs para somente os endereços IP do nó do trabalhador recuperados na etapa anterior.

    calicoctl get nodes -o wide
    
  4. Use os IDs para excluir as entradas do nó do trabalhador. Depois de excluir as entradas do nó do trabalhador, o controlador do Calico replaneja os pods calico-node nos novos nós do trabalhador.

    calicoctl delete node <node_ID>
    
  5. Verifique se os pods de componentes do Kubernetes, incluindo os pods calico-node, estão agora em execução. Pode levar alguns minutos para que os pods calico-node sejam planejados e para que novos pods de componentes sejam criados.

    oc -n calico-system get pods
    

Para evitar esse erro no futuro, nunca exclua todos os nós do trabalhador em seu cluster. Sempre execute pelo menos um nó do trabalhador em seu cluster e, se você usar o Ingress ou rotas para expor apps, execute pelo menos dois nós do trabalhador por zona.