Esta página foi traduzida pela API Cloud Translation.

Reponha um nó com falhas no Google Distributed Cloud

Quando os nós no Google Distributed Cloud falham, o que pode acontecer devido a problemas com o armazenamento, a rede ou a configuração incorreta do SO, quer restaurar de forma eficiente o estado do cluster. Depois de restaurar o estado de funcionamento do cluster, pode resolver problemas de falhas de nós. Este documento mostra como recuperar de cenários de falha de nós através da reposição de um nó e da remoção forçada do nó, se necessário.

Se quiser adicionar ou remover nós de um cluster quando um nó não falhou, consulte o artigo Atualizar clusters.

Reponha nós

Quando ocorre uma falha no nó, por vezes, não pode executar comandos de reposição nos nós, uma vez que o nó pode estar inacessível. Pode ter de remover o nó à força do cluster.

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

O nó é reposto, de forma semelhante a kubeadm reset, e a máquina reverte para o estado pré-instalado.
As referências relacionadas ao nó são removidas dos recursos personalizados do cluster e do conjunto de nós.

Em alguns dos seguintes comandos bmctl para repor nós, o parâmetro --force indica se os comandos de reposição (passo 1) devem ser ignorados. Se o parâmetro --force for usado, o comando bmctl só executa o passo de remoção (passo 2) e não executa os comandos de reposição.

Remova o nó trabalhador

Para remover um nó de trabalho de um cluster, conclua os passos seguintes:

Experimente repor o nó de forma limpa. Após a reposição, o nó é removido do cluster:
```
bmctl reset nodes \
    --addresses COMMA_SEPARATED_IPS \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG
```
Substitua o seguinte:
- COMMA_SEPARATED_IP: os endereços IP dos nós a repor, como 10.200.0.8,10.200.0.9.
- CLUSTER_NAME: o nome do cluster de destino que contém os nós com falhas.
- ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.
Se este comando for bem-sucedido, já pode diagnosticar o nó e corrigir quaisquer configurações incorretas que causaram a falha inicial. Ignore os restantes passos desta secção.
Se o passo anterior para repor o nó falhar, remova o nó à força do cluster. Esta remoção forçada ignora o passo anterior que executa os comandos de reposição e apenas executa o passo para remover as referências relacionadas ao nó dos recursos personalizados do cluster e do conjunto de nós:
```
bmctl reset nodes \
    --addresses COMMA_SEPARATED_IPS \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --force
```
Agora, pode diagnosticar o nó e corrigir quaisquer configurações incorretas que causaram a falha inicial.

Se removeu o nó do cluster de nós à força no passo anterior, execute novamente o comando bmctl reset para repor os nós:

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

Remova um único nó do plano de controlo

O processo é o mesmo que para os nós trabalhadores. Para nós do plano de controlo, bmctl também limpa a associação ao etcd.

O cluster deixa de estar num estado de alta disponibilidade (HA) depois de remover o nó com falhas. Para regressar a um estado de HA, adicione um nó saudável ao cluster.

Para remover um nó de um cluster, conclua os seguintes passos:

Experimente repor o nó de forma limpa. Após a reposição, o nó é 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 repor, como 10.200.0.8,10.200.0.9.
- CLUSTER_NAME: o nome do cluster de destino que contém os nós com falhas.
- ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.
Se este comando for bem-sucedido, já pode diagnosticar o nó e corrigir quaisquer configurações incorretas que causaram a falha inicial. Ignore os restantes passos desta secção.
Se o passo anterior para repor o nó falhar, pode remover o nó do cluster à força. Esta remoção forçada ignora o passo anterior que executa os comandos de reposição e executa apenas o passo para remover as referências relacionadas ao nó dos recursos personalizados do cluster e do conjunto de nós:
```
bmctl reset nodes \
  --addresses COMMA_SEPARATED_IPS \
  --cluster CLUSTER_NAME \
  --kubeconfig ADMIN_KUBECONFIG \
  --force
```
Agora, pode diagnosticar o nó e corrigir quaisquer configurações incorretas que causaram a falha inicial.
Se removeu o nó do cluster de nós à força no passo anterior, execute novamente o comando bmctl reset para repor os nós:
```
bmctl reset nodes \
  --addresses COMMA_SEPARATED_IPS \
  --cluster CLUSTER_NAME \
  --kubeconfig ADMIN_KUBECONFIG
```
Reponha um nó quando o plano de controlo estiver inacessível

Pode executar o seguinte comando para reverter uma máquina para os estados pré-instalados quando o plano de controlo 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 o seguinte:

NODE_IP_ADDRESSES: uma lista separada por vírgulas de endereços IP de nós, um para cada nó que está a repor.
SSH_PRIVATE_KEY_PATH: o caminho do ficheiro da chave privada de SSH.
LOGIN_USER: o nome de utilizador usado para acesso SUDO sem palavra-passe às máquinas de nós. A menos que especifique explicitamente um nome de utilizador não raiz para acesso ao nó na configuração do cluster (nodeAccess.loginUser), é usado root.
AR_SERVICE_ACCOUNT_KEY: o caminho do ficheiro de chave JSON da conta de serviço do Artifact Registry.

Este comando não remove as referências ao nó dos recursos personalizados do cluster e do conjunto de nós. Depois de restaurar o acesso ao painel de controlo do cluster, deve remover o nó do cluster à força se quiser manter o cluster.

Quórum perdido no plano de controlo de HA

Se demasiados nós do plano de controlo num cluster de HA entrarem num estado de falha, o cluster perde o quórum e fica indisponível.

Quando precisar de restaurar clusters de gestão, não faculte o ficheiro kubeconfig nos comandos de reposição. Se fornecer o ficheiro kubeconfig para um cluster de gestão, força um novo cluster a executar a operação de reposição. Quando restaura um cluster de utilizadores, indique o caminho para o ficheiro kubeconfig.

Para recuperar um cluster que perdeu o quórum, execute o seguinte comando num nó saudável restante:
```
bmctl restore --control-plane-node CONTROL_PLANE_NODE \
    --cluster CLUSTER_NAME \
    [--kubeconfig KUBECONFIG_FILE]
```
Substitua o seguinte:
- CONTROL_PLANE_NODE: os endereços IP de um nó em bom estado que permanece como parte do cluster.
- CLUSTER_NAME: o nome do cluster de destino que contém os nós com falhas.
- KUBECONFIG_FILE: se estiver a recuperar um cluster de utilizadores, o caminho para o ficheiro kubeconfig do cluster de utilizadores.
Depois de recuperar os nós com falhas, execute o comando bmctl reset para repor os nós:
```
bmctl reset nodes \
   --addresses COMMA_SEPARATED_IPS \
   --cluster CLUSTER_NAME \
   [--kubeconfig KUBECONFIG_FILE]
```
Substitua o seguinte:
- COMMA_SEPARATED_IP: os endereços IP dos nós a repor, como 10.200.0.8,10.200.0.9.
- CLUSTER_NAME: o nome do cluster de destino que contém os nós com falhas.
- KUBECONFIG_FILE: o caminho para o ficheiro kubeconfig do cluster de administrador.
Se os nós com falhas faziam parte dos conjuntos de nós do balanceador de carga, depois de os nós serem recuperados, podem competir pelo endereço IP virtual do plano de controlo e tornar o novo cluster instável. Execute os comandos de reposição nos nós com falhas assim que possível após a recuperação dos nós.

Este processo apenas processa a recuperação de desastres para uma implementação de HA do plano de controlo de 3 nós. Este processo não suporta a recuperação de configurações de HA com 5 ou mais nós.

O que se segue?

Para mais informações sobre como adicionar ou remover nós de um cluster quando não existe uma falha e para verificar o estado dos nós, consulte o artigo Atualizar clusters.

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

Requisitos para abrir um registo de apoio técnico.
Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
Componentes suportados.

Reponha um nó com falhas no Google Distributed Cloud Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.