Quando os nós do Google Distributed Cloud falham, o que pode acontecer devido a problemas com 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ó redefinindo e removendo 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.
Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.
Redefinir nós
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:
- o nó é redefinido, de maneira semelhante a
kubeadm reset, e a máquina retorna ao estado pré-instalado. - 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) devem ser ignorados. Se
o parâmetro --force for usado, bmctl vai executar apenas a etapa de remoção (etapa
2) e não vai executar os comandos de redefinição.
Remover o nó de trabalho
Para remover um nó de worker de um cluster, siga estas etapas:
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_KUBECONFIGSubstitua:
COMMA_SEPARATED_IP: os endereços IP dos nós a serem redefinidos, como10.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 arquivokubeconfigdo cluster de administrador.
Se o 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.
Se a etapa anterior para redefinir o nó falhar, remova-o à 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 \ --forceAgora é possível diagnosticar o nó e corrigir configurações incorretas que causaram a falha inicial.
Se você removeu à força o nó do cluster de nós na etapa anterior, execute o comando
bmctl resetnovamente para redefinir os nós:bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
Remover um nó de 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 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:
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_KUBECONFIGSubstitua os seguintes valores:
COMMA_SEPARATED_IP: os endereços IP dos nós a serem redefinidos, como10.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 arquivokubeconfigdo cluster de administrador.
Se o 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.
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 \ --forceAgora é possível diagnosticar o nó e corrigir configurações incorretas que causaram a falha inicial.
Se você removeu à força o nó do cluster de nós na etapa anterior, execute o comando
bmctl resetnovamente para redefinir os nós:bmctl reset nodes \ --addresses COMMA_SEPARATED_IPS \ --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIGRedefinir um nó quando o plano de controle estiver inacessível
É possível executar o comando abaixo para reverter uma máquina para 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 GCR_SERVICE_ACCOUNT_KEY
Substitua:
NODE_IP_ADDRESSES: uma lista separada por vírgulas de endereços IP de nó, 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ó. 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),rootserá usado.GCR_SERVICE_ACCOUNT_KEY: o caminho do arquivo de chave JSON da conta de serviço do Container Registry.
Esse comando não remove as referências ao nó dos recursos personalizados do cluster e do pool de nós. Depois de restaurar o acesso ao plano de controle do cluster, remova o nó do cluster à força 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 de um cluster
de gerenciamento, ele 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.
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 arquivokubeconfigdo cluster de usuário.
Depois de recuperar os nós com falha, execute o comando
bmctl resetpara 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, como10.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 arquivokubeconfigdo 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 HA com cinco nós ou mais.
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.
<>