Redefinir um nó com falha no GKE em bare metal

Se os nós do GKE em bare metal falharem, como devido à configuração incorreta do armazenamento, da rede ou do SO, você vai querer restaurar a integridade do cluster com eficiência. Depois de restaurar a integridade do cluster, é possível solucionar a falha do nó.

Neste documento, mostramos como se recuperar de cenários de falha de nó ao redefinir e remover o nó de maneira forçada, se necessário.

Se você quiser adicionar ou remover nós de um cluster em circunstâncias normais quando um nó não falhar, consulte Atualizar clusters.

Visão geral

Quando há uma falha de nó, às vezes não é possível executar comandos de redefinição nele, porque o nó pode estar inacessível. Talvez seja necessário remover o nó do cluster à força.

Quando você redefine corretamente um nó e atualiza o cluster, as seguintes ações ocorrem:

  1. o nó é redefinido, de maneira semelhante a kubeadm reset, e a máquina retorna ao estado pré-instalado.
  2. as referências relacionadas ao nó são removidas dos recursos personalizados do pool de nós e do cluster.

Nó de trabalho

Para remover um nó de um cluster, primeiro faça a limpeza dele:

  1. tente redefinir o nó de maneira limpa. Depois que o nó é redefinido, ele é removido do cluster:

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      --kubeconfig ADMIN_KUBECONFIG
    

    Substitua os seguintes valores:

    • COMMA_SEPARATED_IP: os endereços IP dos nós a serem redefinidos, como 10.200.0.8,10.200.0.9.
    • CLUSTER_NAME: o nome do cluster de destino que contém os nós com falha.
    • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

    Agora é possível diagnosticar o nó e corrigir configurações incorretas que causaram a falha inicial. Pule as etapas restantes nesta seção.

  2. Se a etapa anterior para redefinir o nó falhar, você poderá removê-lo à força do cluster. Essa remoção forçada pula a etapa anterior que executa os comandos de redefinição e executa apenas a etapa para remover as referências relacionadas ao nó dos recursos personalizados do pool de nós e do cluster:

    bmctl reset nodes \
     --addresses COMMA_SEPARATED_IPS \
     --cluster CLUSTER_NAME \
     --kubeconfig ADMIN_KUBECONFIG \
     --force
    

    Agora é possível diagnosticar o nó e corrigir configurações incorretas que causaram a falha inicial.

  3. Se você removeu à força o nó do cluster de nós na etapa anterior, execute o comando bmctl reset novamente para redefinir os nós:

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      --kubeconfig ADMIN_KUBECONFIG
    

Falha de nó de plano de controle único

O processo é o mesmo dos nós de trabalho. Para nós do plano de controle, bmctl também limpa a assinatura etcd.

Para remover um nó de um cluster, primeiro faça a limpeza dele:

  1. tente redefinir o nó de maneira limpa. Depois que o nó é redefinido, ele é removido do cluster:

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      --kubeconfig ADMIN_KUBECONFIG
    

    Substitua os seguintes valores:

    • COMMA_SEPARATED_IP: os endereços IP dos nós a serem redefinidos, como 10.200.0.8,10.200.0.9.
    • CLUSTER_NAME: o nome do cluster de destino que contém os nós com falha.
    • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

    Agora é possível diagnosticar o nó e corrigir configurações incorretas que causaram a falha inicial. Pule as etapas restantes nesta seção.

  2. Se a etapa anterior para redefinir o nó falhar, você poderá removê-lo à força do cluster. Essa remoção forçada pula a etapa anterior que executa os comandos de redefinição e executa apenas a etapa para remover as referências relacionadas ao nó dos recursos personalizados do pool de nós e do cluster:

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      --kubeconfig ADMIN_KUBECONFIG \
      --force
    

    Agora é possível diagnosticar o nó e corrigir configurações incorretas que causaram a falha inicial.

  3. Se você removeu à força o nó do cluster de nós na etapa anterior, execute o comando bmctl reset novamente para redefinir os nós:

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      --kubeconfig ADMIN_KUBECONFIG
    

Quórum perdido no plano de controle de alta disponibilidade

Se muitos nós dos planos de controle em um cluster de alta disponibilidade entrarem em um estado com falha, o cluster perderá o quórum e ficará indisponível.

  1. Para recuperar um cluster que perdeu o quórum, execute o seguinte comando em um nó íntegro:

    bmctl restore --control-plane-node CONTROL_PLANE_NODE \
      --cluster CLUSTER_NAME \
      [--kubeconfig KUBECONFIG_FILE]
    

    Substitua os seguintes valores:

    • CONTROL_PLANE_NODE: os endereços IP de um nó íntegro que permanece como parte do cluster.
    • CLUSTER_NAME: o nome do cluster de destino que contém os nós com falha.
    • KUBECONFIG_FILE: se estiver recuperando um cluster de usuário, o caminho para o arquivo kubeconfig do cluster de usuário.
  2. Depois de recuperar os nós com falha, execute o comando bmctl reset para redefini-los:

    bmctl reset nodes \
      --addresses COMMA_SEPARATED_IPS \
      --cluster CLUSTER_NAME \
      [--kubeconfig KUBECONFIG_FILE]
    

    Substitua os seguintes valores:

    • COMMA_SEPARATED_IP: os endereços IP dos nós a serem redefinidos, como 10.200.0.8,10.200.0.9.
    • CLUSTER_NAME: o nome do cluster de destino que contém os nós com falha.
    • KUBECONFIG_FILE: o caminho até o arquivo kubeconfig do cluster de administrador.

    Se os nós com falha fizessem parte dos pools de nós do balanceador de carga, eles poderiam conseguir o endereço IP virtual do plano de controle e tornar o novo cluster instável depois de recuperar os nós. Execute os comandos de redefinição nos nós com falha assim que possível depois de recuperá-los.

A seguir

Para mais informações sobre como adicionar ou remover nós de um cluster quando não houver falha e verificar o status do nó, consulte Atualizar clusters.