Faça uma cópia de segurança e restaure clusters com o bmctl

Esta página descreve como usar o bmctl para fazer uma cópia de segurança e restaurar clusters criados com o Google Distributed Cloud (apenas software) em hardware físico. Estas instruções aplicam-se a todos os tipos de clusters.

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 cópia de segurança e restauro bmctl não inclui volumes persistentes. Todos os volumes criados pelo aprovisionador de volumes local (LVP) permanecem inalterados.

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 ao cliente.
• Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
• Componentes suportados.

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

O comando bmctl 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 de PKI são usados para autenticação através de TLS. Estes dados são cópias de segurança 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 do Google Distributed Cloud 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.

A versão do bmctl que usa para fazer uma cópia de segurança de um cluster tem de corresponder à versão do cluster de gestão.

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

1. Certifique-se de que o cluster está a funcionar corretamente, com credenciais válidas e conetividade SSH a todos os nós.

   O objetivo do processo de cópia de segurança é capturar o cluster num estado bom conhecido, para que possa restaurar o funcionamento se ocorrer uma falha catastrófica.

   Use o seguinte comando para verificar o cluster:

   bmctl check cluster -c 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 seguinte comando para garantir que o cluster de destino não se encontra num estado de conciliação:

   kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
   

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster do qual quer fazer uma cópia de segurança.
   • CLUSTER_NAMESPACE: o espaço de nomes do cluster. Por predefinição, os espaços de nomes do cluster para o Google Distributed Cloud são o nome do cluster precedido de cluster-. Por exemplo, se der o nome test ao seu cluster, o espaço de nomes tem um nome como cluster-test.
   • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig para o cluster de administrador.

3. Verifique a secção Status no resultado do comando para Conditions do tipo Reconciling.

   Conforme mostrado no exemplo seguinte, um estado de False para estes Conditions significa que o cluster está estável e pronto para ter uma cópia de segurança.

   ...
   Status:
     ...
     Cluster State:  Running
     ...
     Control Plane Node Pool Status:
       ...
       Conditions:
         Last Transition Time:  2023-11-03T16:37:15Z
         Observed Generation:   1
         Reason:                ReconciliationCompleted
         Status:                False
         Type:                  Reconciling
     ...
   

4. Execute o seguinte comando para fazer uma cópia de segurança do cluster:

   bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   Substitua o seguinte:

   • CLUSTER_NAME: o nome do cluster do qual quer fazer uma cópia de segurança.
   • ADMIN_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

   Por predefinição, o ficheiro TAR de cópia de segurança é guardado no diretório do espaço de trabalho (bmctl-workspace, por predefinição) na estação de trabalho do administrador. O ficheiro TAR tem o nome CLUSTER_NAME_backup_TIMESTAMP.tar.gz, onde 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_2006-01-02T150405Z0700.tar.gz.

   Para especificar um nome e uma localização diferentes para o ficheiro de cópia de segurança, use a flag --backup-file.

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.

Restaure um conjunto

A restauração de um cluster a partir de uma cópia de segurança é um último recurso e 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 etcd Pod está num ciclo de falhas.

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 de etcd-events vazia, pelo que perde os objetos de eventos existentes. No entanto, a perda de objetos de eventos não tem impacto no funcionamento do cluster. Os eventos devem ser tratados apenas como dados informativos, de melhor esforço e suplementares.

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.

A versão do bmctl que usa para restaurar um cluster tem de corresponder à versão do cluster de gestão.

Para restaurar um cluster:

1. Certifique-se de que todas as máquinas de nós que estavam disponíveis para o cluster no momento da cópia de segurança estão a funcionar corretamente e acessíveis.

2. Certifique-se de que a conetividade SSH entre os 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.

3. Certifique-se de que 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.

4. Para restaurar um cluster de administrador, híbrido ou autónomo, execute o seguinte comando:

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
   

   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.

5. Para restaurar um cluster de utilizadores, execute o seguinte comando:

   bmctl restore cluster -c 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.

Quando a restauração terminar, siga os passos seguintes para verificar se foi bem-sucedida:

1. Execute os seguintes comandos para verificar a disponibilidade do nó e os pods do sistema em execução com o ficheiro kubeconfig gerado:

   Existem dois tipos de pods etcd:

   • etcd-HOST_NAME, que corresponde ao agrupamento etcd principal
   • etcd-events-HOST_NAME, que corresponde ao agrupamento etcd-events

   kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
   kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
   

2. Para cada pod etcd, execute o seguinte para verificar o estado de funcionamento do etcd:

   kubectl exec ETCD_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Para um membro etcd saudável, a resposta deve ter o seguinte aspeto:

   https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms
   

3. Para cada etcd-eventspod, execute o seguinte comando para verificar o estado de funcionamento:etcd-events

   kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
       --kubeconfig GENERATED_KUBECONFIG \
       -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
       --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'
   

   Para um membro etcd-events em bom estado, a resposta deve ter o seguinte aspeto:

   https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms
   

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 o Apoio técnico da Google.

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

Pode receber mensagens de erro durante o processo de cópia de segurança ou restauro que não são muito autoexplicativas nem claras quanto aos passos seguintes. Se a estação de trabalho onde executa o comando bmctl não tiver muita RAM, pode ter memória insuficiente para realizar o processo de cópia de segurança ou restauro.

O Google Distributed Cloud versão 1.13 e posterior pode usar 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, pelo que requer que o utilizador que executa o comando seja um utilizador root (ou use sudo).

Autorizações em falta para ficheiros durante o restauro

Após uma tarefa de restauro bem-sucedida, a eliminação da inicialização pode falhar com uma mensagem de erro semelhante ao seguinte exemplo:

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

Este erro pode significar que alguns diretórios necessários para o restauro não são graváveis.

A versão 1.14 e posteriores do Google Distributed Cloud têm mensagens de erro mais claras sobre os diretórios que têm de ser graváveis. Certifique-se de que os diretórios comunicados são graváveis e atualize as autorizações nos diretórios conforme necessário.

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 da 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 e, em seguida, fazer a restauração. Após a conclusão do processo de restauro, pode rodar a chave SSH.