Redefinir um nó com falha no Google Distributed Cloud

Quando os nós do Google Distributed Cloud falham, o que pode acontecer devido a problemas com armazenamento, rede ou configuração incorreta 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 quando um nó não falhar, consulte Atualizar clusters.

Redefinir nós

Quando os nós do Google Distributed Cloud falham devido a falhas de hardware, corrupção de disco ou problemas do sistema operacional, é necessário restaurar a integridade do cluster antes de solucionar problemas da máquina subjacente.

Arquitetura de recuperação de nós

Os nós físicos no Google Distributed Cloud são projetados como unidades de infraestrutura descartáveis. Se o sistema operacional de um nó estiver corrompido, será necessário remover o nó do cluster, reinstalar um sistema operacional Linux de base limpo e adicionar o nó novamente ao cluster.

Não tente restaurar um nó de um backup de imagem do SO no nível do host ou de um snapshot de disco. A restauração de um nó de um estado anterior do SO corrompe o consenso do Raft nos nós do plano de controle e introduz colisões de endereço IP do Dataplane V2 nos nós de trabalho. Para mais informações sobre restrições de backup e recuperação de desastres, consulte Fazer backup e restaurar clusters com o bmctl.

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.

Em alguns dos comandos bmctl a seguir para redefinir nós, o parâmetro --force indica se os comandos de redefinição (etapa 1) precisam ser ignorados. Se o parâmetro --force for usado, bmctl executará apenas a etapa de remoção (etapa 2) e não executará os comandos de redefinição.

Remover nó de trabalho

Para remover um nó de trabalho de um cluster, siga estas etapas:

  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:

    • 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 para o arquivo kubeconfig do cluster de administrador.

    Se esse comando for bem-sucedido, agora será 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, remova o nó à 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

Se o sistema operacional subjacente na máquina estiver corrompido ou não puder ser recuperado:

  1. Limpe as unidades de armazenamento local da máquina.
  2. Instale um sistema operacional Linux novo e compatível e configure os pré-requisitos do nó descritos em Requisitos de configuração do sistema operacional e Pré-requisitos da estação de trabalho e do nó.
  3. Adicione o nó íntegro novamente ao cluster seguindo Atualizar clusters.

Remover um único nó do plano de controle

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

O cluster deixa de estar em um estado de alta disponibilidade (HA) depois que você remove o nó com falha. Para retornar a um estado de HA, adicione um nó íntegro ao cluster.

Para remover um nó de um cluster, siga estas etapas:

  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 para o arquivo kubeconfig do cluster de administrador.

    Se esse comando for bem-sucedido, agora será 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

Se o sistema operacional subjacente na máquina estiver corrompido ou não puder ser recuperado:

  1. Limpe as unidades de armazenamento local da máquina.
  2. Instale um sistema operacional Linux novo e compatível e configure os pré-requisitos do nó descritos em Requisitos de configuração do sistema operacional e Pré-requisitos da estação de trabalho e do nó.
  3. Adicione o nó íntegro novamente ao cluster seguindo Atualizar clusters.

Redefinir um nó quando o plano de controle estiver inacessível

Execute o comando a seguir para reverter uma máquina aos estados pré-instalados quando o plano de controle do cluster estiver inacessível:

bmctl reset nodes \
    --addresses NODE_IP_ADDRESSES \
    --ssh-private-key-path SSH_PRIVATE_KEY_PATH \
    --login-user LOGIN_USER \
    --gcr-service-account-key AR_SERVICE_ACCOUNT_KEY

Substitua:

  • NODE_IP_ADDRESSES: uma lista separada por vírgulas de endereços IP de nós, um para cada nó que você está redefinindo.

  • SSH_PRIVATE_KEY_PATH: o caminho do arquivo de chave privada SSH.

  • LOGIN_USER: o nome de usuário usado para acesso SUDO sem senha às máquinas de nós. A menos que você especifique explicitamente um nome de usuário não raiz para acesso ao nó na configuração do cluster (nodeAccess.loginUser), root será usado.

  • AR_SERVICE_ACCOUNT_KEY: o caminho do arquivo de chave JSON da conta de serviço do Artifact Registry.

Esse comando não remove referências ao nó dos recursos personalizados do pool de nós e do cluster. Depois de restaurar o acesso ao plano de controle do cluster, remova o nó à força do cluster se quiser manter o cluster.

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.

Quando for necessário restaurar clusters de gerenciamento, não forneça o arquivo kubeconfig nos comandos de redefinição. Se você fornecer o arquivo kubeconfig para um cluster de gerenciamento, ele vai forçar um novo cluster a executar a operação de redefinição. Ao restaurar um cluster de usuário, forneça o caminho para o arquivo kubeconfig.

  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:

    • 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:

    • 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 para 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.

Esse processo lida apenas com a recuperação de desastres em uma implantação de alta disponibilidade do plano de controle de três nós. Esse processo não é compatível com a recuperação de configurações de alta disponibilidade com cinco nós ou mais.

Corrigir uma restauração acidental de imagem do SO

Se um nó físico foi restaurado de um backup ou snapshot de imagem no nível do SO e está causando instabilidade no cluster, erros de consenso do etcd ou colisões de IP do Dataplane V2, siga estas etapas para recuperar a integridade do cluster:

  1. Desconecte ou desligue imediatamente o nó afetado para evitar mais corrupção do estado do cluster.
  2. Na estação de trabalho do administrador, execute o comando bmctl reset nodes --force para remover os recursos personalizados do nó do cluster.
  3. Limpe as unidades físicas na máquina.
  4. Instale um sistema operacional Linux de base limpo seguindo os Requisitos de configuração do sistema operacional.
  5. Adicione o nó novamente ao cluster seguindo Atualizar clusters.

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.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care. Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo o seguinte:

  • Requisitos para abrir um caso de suporte.
  • Ferramentas para ajudar na solução de problemas, como configuração do ambiente, registros e métricas.
  • Componentes compatíveis.