Nesta página, descrevemos como usar o bmctl
para fazer backup e restaurar clusters criados
com GDCV para Bare Metal. Estas instruções se aplicam a todos os tipos de cluster com suporte
do GKE em Bare Metal.
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.
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 GKE em Bare Metal 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:
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.
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 para o GKE em Bare Metal são o nome do cluster precedido porcluster-
. Por exemplo, se você nomear o clustertest
, o namespace terá um nome comocluster-test
.ADMIN_KUBEONFIG
: o caminho do arquivo kubeconfig do cluster de administrador.
Verifique a seção
Status
na resposta ao comando paraConditions
do tipoReconciling
.Conforme mostrado no exemplo a seguir, um status
False
para essasConditions
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 ...
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 deCLUSTER_NAME_backup_TIMESTAMP.tar.gz
, em queCLUSTER_NAME
é o nome do cluster que está sendo armazenado em backup eTIMESTAMP
é a data e a hora em que o backup foi feito. Por exemplo, se o nome do cluster fortestuser
, o arquivo de backup terá um nome comotestuser_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 GKE em Bare Metal 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:
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.
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.
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.
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.
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.
A GDCV para Bare Metal versão 1.13 e mais recentes pode 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.
O GDCV para Bare Metal versão 1.14 e mais recentes 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.