Fazer backup e restaurar clusters com bmctl

Nesta página, descrevemos como usar o bmctl para fazer backup e restaurar clusters criados com o Google Distributed Cloud. Estas instruções se aplicam a todos os tipos de cluster compatíveis com o Google Distributed Cloud.

O processo de backup e restauração bmctl não inclui volumes persistentes. Todos os volumes criados pelo provisionador de volume local (LVP, na sigla em inglês) não são alterados.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Fazer backup de um cluster

O comando bmctl backup cluster adiciona as informações de cluster do armazenamento etcd e os certificados de PKI do cluster especificado o cluster a um arquivo .tar. O armazenamento etcd é o armazenamento secundário do Kubernetes para todos os dados de cluster e contém todos os objetos do Kubernetes e objetos personalizados necessários para gerenciar o estado do cluster. Os certificados de PKI são usados para autenticação por TLS. Esses dados são armazenados em backup a partir do plano de controle do cluster ou de um dos planos de controle para uma implantação de alta disponibilidade (HA, na sigla em inglês)

O arquivo tar de backup contém credenciais confidenciais, incluindo as chaves da conta de serviço e a chave SSH. Armazene os arquivos de backup em um local seguro. Para evitar a exposição não intencional de arquivos, o processo de backup do Google Distributed Cloud usa apenas arquivos na memória.

Faça backup dos clusters regularmente para garantir que os dados de snapshots sejam relativamente atuais. Ajuste a taxa de backups para refletir a frequência de alterações significativas nos clusters.

A versão de bmctl que você usa para fazer backup de um cluster precisa corresponder à versão do cluster de gerenciamento.

Para fazer backup de um cluster:

  1. Verifique se o cluster está funcionando corretamente, com credenciais de trabalho e conectividade SSH para todos os nós.

    O objetivo do processo de backup é capturar o cluster em um estado válido conhecido para que você consiga restaurar a operação se ocorrer uma falha catastrófica.

    Use o seguinte comando para verificar o cluster:

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBEONFIG

    Substitua:

    • CLUSTER_NAME: o nome do cluster que você planeja armazenar em backup.
    • ADMIN_KUBEONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

  2. Execute o seguinte comando para garantir que o cluster de destino não esteja em um estado de reconciliação:

    kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBEONFIG

    Substitua:

    • CLUSTER_NAME: o nome do cluster para backup.
    • CLUSTER_NAMESPACE: o namespace do cluster. Por padrão, os namespaces do cluster do Google Distributed Cloud são o nome do cluster precedido de cluster-. Por exemplo, se você nomear o cluster test, o namespace terá um nome como cluster-test.
    • ADMIN_KUBEONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

  3. Verifique a seção Status na resposta ao comando para Conditions do tipo Reconciling.

    Conforme mostrado no exemplo a seguir, um status False para essas Conditions significa que o cluster está estável e pronto para ser salvo em backup.

    ...
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 backup do cluster:

    bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBEONFIG

    Substitua:

    • CLUSTER_NAME: o nome do cluster para backup.
    • ADMIN_KUBEONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

    Por padrão, o arquivo tar de backup foi salvo no diretório do espaço de trabalho (bmctl-workspace, por padrão) na estação de trabalho do administrador. O arquivo .tar é chamado de CLUSTER_NAME_backup_TIMESTAMP.tar.gz, em que CLUSTER_NAME é o nome do cluster que está sendo armazenado em backup e TIMESTAMP é a data e a hora em que o backup foi feito. Por exemplo, se o nome do cluster for testuser, o arquivo de backup terá um nome como testuser_backup_2006-01-02T150405Z0700.tar.gz.

    Para especificar um nome e local diferentes para o arquivo de backup, use a sinalização --backup-file.

O arquivo de backup expira após um ano e o processo de restauração do cluster não funciona com arquivos de backup expirados.

Restaurar um cluster

A restauração de um cluster a partir de um backup é um último recurso e precisa ser usado quando um cluster falhar de forma catastrófica e não puder ser retornado de forma alguma. Por exemplo, se os dados do etcd estiverem corrompidos ou o pod do etcd estiver em um loop de falhas.

O arquivo tar de backup 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 arquivos, o processo de restauração do Google Distributed Cloud usa apenas arquivos na memória.

A versão de bmctl que você usa para fazer backup de um cluster precisa corresponder à versão do cluster de gerenciamento.

Para restaurar um cluster:

  1. Garanta que todas as máquinas de nó que estavam disponíveis para o cluster no momento do backup estejam funcionando corretamente e acessíveis.

  2. Garanta que a conectividade SSH entre os nós funcione com as chaves SSH usadas no momento do backup.

    Essas chaves SSH são restabelecidas como parte do processo de restauração.

  3. Verifique se as chaves da conta de serviço que foram usadas no momento do backup ainda estão ativas.

    Essas chaves de conta de serviço são restabelecidas 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:

    • CLUSTER_NAME: o nome do cluster que você está restaurando.
    • BACKUP_FILE: o caminho e o nome do arquivo de backup que você está usando.

  5. Para restaurar um cluster de usuário, execute o seguinte comando:

    bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBEONFIG

    Substitua:

    • CLUSTER_NAME: o nome do cluster que você está restaurando.
    • BACKUP_FILE: o caminho e o nome do arquivo de backup que você está usando.
    • ADMIN_KUBEONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

No final do processo de restauração, um novo arquivo kubeconfig é gerado para o cluster restaurado.

Resolver problemas

Se você tiver problemas com o processo de backup ou restauração, as seções a seguir poderão ajudar a resolver o problema.

Se precisar de mais ajuda, entre em contato com o Suporte do Google.

Memória insuficiente durante um backup ou restauração

Você pode receber mensagens de erro durante o processo de backup ou restauração que não sejam muito autoexplicativas ou claras nas próximas etapas. Se a estação de trabalho em que você executa o comando bmctl não tem muita RAM, você pode ter memória insuficiente para executar o processo de backup ou restauração.

O Google Distributed Cloud versão 1.13 e mais recentes podem usar o parâmetro --use-disk no comando de backup. Para preservar as permissões do arquivo, esse parâmetro modifica as permissões dos arquivos. Portanto, exige que o usuário que executa o comando seja um usuário raiz (ou use sudo).

Permissões ausentes para arquivos durante a restauração

Após uma tarefa de restauração bem-sucedida, a exclusão do bootstrap pode falhar com uma mensagem de erro semelhante ao exemplo a seguir:

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

Esse erro pode significar que alguns diretórios exigidos pela restauração não são graváveis.

As versões 1.14 e mais recentes do Google Distributed Cloud têm mensagens de erro mais claras sobre quais diretórios precisam ser graváveis. Verifique se os diretórios relatados são graváveis e atualize as permissões nos diretórios conforme necessário.

Atualização da chave SSH após um backup interromper o processo de restauração

As operações relacionadas ao SSH durante o processo de restauração podem falhar se a chave SSH for atualizada após a realização do backup. Nesse caso, a nova chave SSH se torna inválida para o processo de restauração.

Para resolver esse problema, adicione temporariamente a chave SSH original de volta e execute a restauração. Após a conclusão do processo de restauração, é possível girar a chave SSH.