Faça uma cópia de segurança e restaure clusters avançados com o gkectl

Este documento descreve como fazer uma cópia de segurança e restaurar clusters de administrador e de utilizadores do Google Distributed Cloud versão 1.32 e superior que tenham o cluster avançado ativado. A funcionalidade de cópia de segurança e restauro está em pré-visualização na versão 1.32 e em disponibilidade geral na versão 1.33 e superior.

Aviso: a utilização de um ficheiro de cópia de segurança para restaurar o cluster é um último recurso. O processo de restauro repõe o cluster existente e substitui as informações do cluster. Não recomendamos a restauração a partir de um ficheiro de cópia de segurança, a menos que o cluster tenha falhado de forma catastrófica. Contacte o Cloud Customer Care para receber ajuda na decisão do melhor curso de ação.

O processo de gkectl cópia de segurança e restauro não inclui volumes persistentes. Todos os volumes criados pelo aprovisionador de volumes local (LVP) permanecem inalterados.

Faça uma cópia de segurança de um cluster

O comando gkectl backup cluster adiciona as informações do cluster do armazenamento etcd e os certificados de infraestrutura de chaves públicas para o cluster especificado a um ficheiro TAR. O armazenamento etcd é o armazenamento de apoio do Kubernetes para todos os dados do cluster e contém todos os objetos do Kubernetes e objetos personalizados necessários para gerir o estado do cluster. Os certificados PKI são usados para autenticação através do Transport Layer Security (TLS). Estes dados são copiados a partir do plano de controlo do cluster ou de um dos planos de controlo para uma implementação de alta disponibilidade (HA).

O ficheiro TAR de cópia de segurança contém credenciais confidenciais, incluindo as chaves da conta de serviço e a chave SSH. Armazene ficheiros de cópia de segurança num local seguro. Para evitar a exposição não intencional de ficheiros, o processo de cópia de segurança usa apenas ficheiros na memória.

Faça regularmente uma cópia de segurança dos seus clusters para garantir que os dados da análise rápida estão relativamente atualizados. Ajuste a taxa de cópias de segurança para refletir a frequência de alterações significativas aos seus clusters.

Antes de começar, certifique-se de que o cluster está a funcionar corretamente, com credenciais funcionais e conetividade SSH a todos os nós. O objetivo do processo de cópia de segurança é capturar o cluster num estado conhecido em bom estado para que possa restaurar o funcionamento se ocorrer uma falha catastrófica.

Para fazer uma cópia de segurança de um cluster:

1. Execute o seguinte comando para verificar o seu cluster:

   gkectl diagnose cluster --cluster-name CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster do qual planeia fazer uma cópia de segurança.

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig para o cluster de administrador.

2. Execute o comando aplicável para fazer uma cópia de segurança do cluster:

   Cluster de administrador

   gkectl backup admin --kubeconfig ADMIN_KUBECONFIG
   

   Cluster de utilizadores

   gkectl backup cluster --cluster-name CLUSTER_NAME \
       --kubeconfig ADMIN_KUBECONFIG
   

Por predefinição, o ficheiro TAR de cópia de segurança é guardado no diretório gkectl-workspace/backups na sua estação de trabalho de administração. O ficheiro TAR tem o nome CLUSTER_NAME_backup_TIMESTAMP.tar.gz, em que CLUSTER_NAME é o nome do cluster cuja cópia de segurança está a ser feita e TIMESTAMP é a data e a hora em que a cópia de segurança foi feita. Por exemplo, se o nome do cluster for testuser, o ficheiro de cópia de segurança tem um nome como testuser_backup_2025-08-23T150405Z0700.tar.gz.

Opcionalmente, pode especificar um nome e uma localização diferentes para o ficheiro de cópia de segurança com a flag --backup-file, por exemplo:

gkectl backup cluster testuser \
    --kubeconfig admin-cluster/kubeconfig \
    --backup-file cluster-backups/testuser-backup-aug-23-2025.tar.gz

O ficheiro de cópia de segurança expira após um ano e o processo de restauro do cluster não funciona com ficheiros de cópia de segurança expirados.

Cópia de segurança para o vSphere

Para configurar cópias de segurança de modo que o ficheiro de cópia de segurança dos clusters de administrador e de utilizador seja carregado para o vSphere, além de ser guardado na estação de trabalho de administrador, faça o seguinte:

1. Adicione o campo clusterBackup.datastore ao ficheiro de configuração do cluster de administrador:

   clusterBackup:
       datastore: DATASTORE
   

   Substitua DATASTORE pelo arquivo de dados onde quer armazenar a cópia de segurança. O arquivo de dados tem de estar no mesmo centro de dados que o cluster de administração. As cópias de segurança estão localizadas no diretório anthos/CLUSTER_NAME/backup do arquivo de dados especificado.

2. Atualize o cluster de administrador:

   gkectl update admin --kubeconfig ADMIN_KUBECONFIG \
       --config ADMIN_CONFIG
   

   Substitua o seguinte:

   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig para o cluster de administrador.

   • ADMIN_CONFIG: o caminho do ficheiro de configuração do cluster de administrador.

Por predefinição, o comando gkectl backup guarda os três ficheiros de cópia de segurança mais recentes no vSphere e elimina os ficheiros de cópia de segurança mais antigos. Se quiser manter os ficheiros de cópia de segurança mais antigos, adicione a flag --keep-all-backups, que está disponível na versão 1.32.100 e superior.

Restaure um conjunto

A restauração de um cluster a partir de uma cópia de segurança é um último recurso e só deve ser usada quando um cluster falhou de forma catastrófica e não pode ser reposto em serviço de outra forma. Por exemplo, os dados do etcd estão danificados ou o pod do etcd está num ciclo de falhas de sistema.

Use o comando gkectl restore apenas se todos os três nós do plano de controlo tiverem falhado.

• Se apenas um nó tiver falhado e autoRepair.enabled estiver definido como true no ficheiro de configuração do cluster de administrador, o nó com falha é reparado automaticamente. Se autoRepair.enabled não estiver configurado, adicione-o ao ficheiro de configuração do cluster de administrador e execute gkectl update admin. Após a atualização, o nó é recriado automaticamente.

• Se dois nós do plano de controlo falharam, consulte a secção Restaurar quórum nesta página.

Nota: para melhorar o desempenho do cluster, o Google Distributed Cloud usa uma instância etcd separada para armazenar objetos de eventos. Estes objetos Event têm um tempo de vida (TTL) de uma hora. A operação de restauro do cluster cria uma nova instância etcd-events vazia, pelo que perde os objetos de eventos existentes. No entanto, a perda de objetos Event não tem impacto no funcionamento do cluster. Os eventos devem ser tratados como dados informativos, de melhor esforço e suplementares apenas.

O ficheiro TAR de cópia de segurança contém credenciais confidenciais, incluindo as chaves da conta de serviço e a chave SSH. Para evitar a exposição não intencional de ficheiros, o processo de restauro do Google Distributed Cloud usa apenas ficheiros na memória.

Antes de restaurar um cluster, certifique-se de que as seguintes condições são cumpridas:

• Todas as máquinas de nós do plano de controlo que estavam disponíveis para o cluster no momento da cópia de segurança estão a funcionar corretamente e acessíveis.
• A conetividade SSH entre nós funciona com as chaves SSH que foram usadas no momento da cópia de segurança. Estas chaves SSH são repostas como parte do processo de restauro.
• As chaves da conta de serviço usadas no momento da cópia de segurança ainda estão ativas. Estas chaves de contas de serviço são repostas para o cluster restaurado.

Para restaurar um cluster:

1. Execute o comando aplicável para restaurar o cluster:

   Cluster de administrador

   gkectl restore admin --backup-file BACKUP_FILE \
       --config ADMIN_CONFIG
   

   Substitua o seguinte:

   • BACKUP_FILE: o caminho e o nome do ficheiro de cópia de segurança que está a usar.

   • ADMIN_CONFIG: o caminho para o ficheiro de configuração do cluster de administrador.

   Cluster de utilizadores

   gkectl restore cluster --cluster-name CLUSTER_NAME \
       --backup-file BACKUP_FILE \
       --kubeconfig ADMIN_KUBECONFIG
   

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster que está a restaurar.

   • BACKUP_FILE: o caminho e o nome do ficheiro de cópia de segurança que está a usar.

   • ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

   No final do processo de restauro, é gerado um novo ficheiro kubeconfig para o cluster restaurado no diretório do espaço de trabalho gkectl-workspace.

2. Quando o restauro terminar, execute o seguinte comando para verificar se foi bem-sucedido:

   gkectl diagnose cluster --cluster-name CLUSTER_NAME \
       --kubeconfig GENERATED_KUBECONFIG
   

   Substitua GENERATED_KUBECONFIG pelo ficheiro kubeconfig gerado.

Restaure o quórum

Quando dois nós do plano de controlo falham num cluster, pode usar o comando gkectl restore para restaurar o quórum. Quando restaura o quórum, em vez de especificar o ficheiro de cópia de segurança no comando gkectl restore, especifica o endereço IP do nó do plano de controlo em funcionamento.

Antes de executar o comando, certifique-se de que as seguintes condições são cumpridas:

• Existe um (e apenas um) nó do plano de controlo a funcionar.
• O nó do plano de controlo funcional está acessível com a chave SSH. Para mais informações, consulte o artigo Usar o SSH para estabelecer ligação a um nó do cluster.

Para restaurar o quórum, execute o comando aplicável para o tipo de cluster:

Cluster de administrador

gkectl restore admin --kubeconfig ADMIN_KUBECONFIG \
    --config ADMIN_CONFIG \
    --control-plane-node WORKING_NODE_IP \
    --ssh-key ADMIN_SSH_KEY_PATH

Substitua o seguinte:

• ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig para o cluster de administrador.

• ADMIN_CONFIG: o caminho do ficheiro de configuração do cluster de administrador.

• WORKING_NODE_IP: o endereço IP do nó do plano de controlo em funcionamento.

• ADMIN_SSH_KEY_PATH: o caminho da chave SSH do cluster de administrador.

Cluster de utilizadores

gkectl restore cluster --cluster-name CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --control-plane-node WORKING_NODE_IP \
    --ssh-key USER_SSH_KEY_PATH

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster que está a restaurar.

• ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

• WORKING_NODE_IP: o endereço IP do nó do plano de controlo em funcionamento.

• USER_SSH_KEY_PATH: o caminho da chave SSH do cluster de utilizadores.

Resolver problemas

Se tiver problemas com o processo de cópia de segurança ou restauro, as secções seguintes podem ajudar a resolver o problema.

Se precisar de assistência adicional, contacte a equipa do apoio ao cliente do Google Cloud.

Ficar sem memória durante uma cópia de segurança ou um restauro

Se a estação de trabalho onde executa o comando gkectl não tiver muita RAM, pode ter memória insuficiente para realizar o processo de cópia de segurança ou restauro. Se necessário, crie e use um disco de memória temporário para processar as operações de cópia de segurança ou restauro usando o parâmetro --use-disk no comando de cópia de segurança. Para preservar as autorizações dos ficheiros, este parâmetro modifica as autorizações dos ficheiros. Por isso, tem de executar o comando como utilizador root (ou usar sudo).

A atualização da chave SSH após uma cópia de segurança interrompe o processo de restauro

As operações relacionadas com SSH durante o processo de restauro podem falhar se a chave SSH for atualizada após a realização de uma cópia de segurança. Neste caso, a nova chave SSH torna-se inválida para o processo de restauro. Para resolver este problema, pode adicionar temporariamente a chave SSH original novamente e, em seguida, fazer o restauro. Após a conclusão do processo de restauro, pode rodar a chave SSH.