Fazer backup e restaurar clusters

Nesta página, descrevemos como fazer backup e restaurar clusters criados com clusters do Anthos em bare metal. Estas instruções se aplicam a todos os tipos de cluster compatíveis com clusters do Anthos em bare metal.

Fazer backup de um cluster

O processo de backup tem duas partes. Primeiro, um snapshot é criado no armazenamento etcd. Em seguida, os certificados de ICP relacionados são salvos em 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 ICP 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 alta disponibilidade (HA, na sigla em inglês)

Recomendamos que você faça backup dos clusters regularmente para garantir que os dados do snapshot estejam relativamente atualizados. A taxa de backups depende da frequência com que ocorrem alterações significativas nos clusters.

Criar um snapshot do armazenamento etcd

Em clusters do Anthos em bare metal, um pod chamado etcd-CONTROL_PLANE_NAME no namespace do sistema kube executa o etcd para esse plano de controle. Para fazer backup do armazenamento etcd do cluster, siga estas etapas na estação de trabalho de administrador:

Use kubectl get po para identificar o pod do etcd.

kubectl --kubeconfig CLUSTER_KUBECONFIG get po -n kube-system \
    -l 'component=etcd,tier=control-plane'

A resposta inclui o nome do pod do etcd e o status dele.

Use kubectl describe pod para ver os contêineres em execução no pod etcd, incluindo o contêiner do etcd.
```
kubectl --kubeconfig CLUSTER_KUBECONFIG describe pod ETCD_POD_NAME -n kube-system
```

Execute um shell Bash no contêiner do etcd:

kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
    ETCD_POD_NAME --container etcd --namespace kube-system \
    -- bin/sh

No shell do contêiner do etcd, use etcdctl (versão 3 da API) para salvar um snapshot, snapshot.db, do armazenamento etcd.

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/peer.crt \
    --key=/etc/kubernetes/pki/etcd/peer.key \
    snapshot save /tmp/snapshotDATESTAMP.db

Substitua DATESTAMP pela data atual para evitar a substituição de snapshots posteriores.

Saia do shell no contêiner e execute o comando a seguir para copiar o arquivo de snapshot para a estação de trabalho de administrador.
```
kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
    kube-system/ETCD_POD_NAME:/tmp/snapshot.db \
    --container etcd snapshot.db
```

Copie o binário etcdctl do pod etcd para que possa ser usado durante o processo de restauração.

kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
  kube-system/ETCD_POD_NAME:/usr/local/bin/etcdctl \
  --container etcd etcdctl

Armazene o arquivo de snapshot e o binário etcdctl em um local fora do cluster e não dependa da operação do cluster.

Arquivar os certificados da ICP

Os certificados a serem armazenados em backup estão localizados no diretório /etc/kubernetes/pki do plano de controle. Os certificados de ICP em conjunto com o arquivo de armazenamento do etcd snapshot.db são necessários para recuperar um cluster no caso do plano de controle ser completamente desligado. As etapas a seguir criam um arquivo tar, contendo os certificados de ICP.

Use ssh para se conectar ao plano de controle do cluster como raiz.
```
ssh root@CONTROL_PLANE_NAME
```
No plano de controle, crie um arquivo tar, certs_backup.tar.gz, com o conteúdo do diretório /etc/kubernetes/pki.
```
tar -czvf certs_backup.tar.gz -C /etc/kubernetes/pki .
```
Criar o arquivo tar no plano de controle preserva todas as permissões do arquivo de certificado.
Saia do plano de controle e, na estação de trabalho, copie o arquivo tar contendo os certificados para um local de preferência na estação de trabalho.
```
sudo scp root@CONTROL_PLANE_NAME:certs_backup.tar.gz BACKUP_PATH
```

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 processo de restauração do cluster tem duas partes. Primeiro, os certificados de ICP são restaurados no plano de controle. Em seguida, os dados do armazenamento do etcd são restaurados.

Restaurar certificados de ICP

Supondo que você tenha feito backup dos certificados de ICP conforme descrito em Arquivar os certificados de ICP, as etapas a seguir descrevem como restaurar os certificados a partir do arquivo tar para um plano de controle.

Copie o arquivo tar de certificados de ICP, certs_backup.tar.gz, da estação de trabalho para o plano de controle do cluster.
```
sudo scp -r BACKUP_PATH/certs_backup.tar.gz root@CONTROL_PLANE_NAME:~/
```
Use ssh para se conectar ao plano de controle do cluster como raiz.
```
ssh root@CONTROL_PLANE_NAME
```
No plano de controle, extraia o conteúdo do arquivo tar para o diretório /etc/kubernetes/pki.
```
tar -xzvf certs_backup.tar.gz -C /etc/kubernetes/pki/
```
Saia do plano de controle.

Restaurar o armazenamento etcd

Ao restaurar o armazenamento etcd, o processo depende de o cluster estar ou não em execução em modo de alta disponibilidade (HA, na sigla em inglês) e, em caso afirmativo, se o quórum foi ou não preservado. Use as seguintes orientações para restaurar o armazenamento etcd para uma determinada situação de falha de cluster:

Se o cluster com falha não estiver em execução no modo de HA, restaure o armazenamento etcd no plano de controle com as seguintes etapas.
Se o cluster estiver em execução no modo de HA e o quórum for preservado, não faça nada. Enquanto um quórum for preservado, você não precisará restaurar clusters com falha.
Se o cluster estiver em execução no modo de HA e o quórum for perdido, repita as etapas a seguir para restaurar o armazenamento etcd para cada membro com falha.

Siga essas etapas na estação de trabalho para remover e restaurar o armazenamento etcd em um plano de controle para um cluster com falha:

Crie um diretório /backup no diretório raiz do plano de controle.
```
ssh root@CONTROL_PLANE_NAME "mkdir /backup"
```
Esta etapa não é obrigatória, mas é recomendada. Nas etapas a seguir, presume-se que você criou um diretório /backup.
Copie o arquivo do snapshot etcd do binário snapshot.db e etcdctl da estação de trabalho para o diretório backup no plano de controle do cluster.
```
sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup
sudo scp etcdctl root@CONTROL_PLANE_NAME:/backup
```
Use SSH para se conectar ao nó do plano de controle:
```
ssh root@CONTROL_PLANE_NAME
```
Interrompa os pods estáticos etcd e kube-apiserver movendo os arquivos de manifesto para fora do diretório /etc/kubernetes/manifests e para o diretório /backup.
```
sudo mv /etc/kubernetes/manifests/etcd.yaml /backup/etcd.yaml
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /backup/kube-apiserver.yaml
```
Remova o diretório de dados do etcd.
```
rm -rf /var/lib/etcd/
```

Execute a restauração do snapshot etcdctl usando o binário salvo.

sudo chmod +x /backup/etcdctl
sudo ETCDCTL_API=3 /backup/etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --data-dir=/var/lib/etcd \
    --name=CONTROL_PLANE_NAME \
    --initial-advertise-peer-urls=https://CONTROL_PLANE_IP:2380 \
    --initial-cluster=CONTROL_PLANE_NAME=https://CONTROL_PLANE_IP:2380 \
    snapshot restore /backup/snapshot.db

As entradas para --name, --initial-advertise-peer-urls e --initial-cluster podem ser encontradas no arquivo de manifesto etcd.yaml que foi movido para o diretório /backup.

Verifique se /var/lib/etcd foi recriado e se um novo membro foi criado em /var/lib/etcd/member.
Mude o proprietário do diretório /var/lib/etcd/member para 2003. Começando com clusters do Anthos na versão em Bare Metal 1.10.0, o contêiner etcd é executado como usuário não raiz com UID e GID de 2003.
```
sudo chown -R 2003:2003 /var/lib/etcd
```

Mova os manifestos etcd e kube-apiserver de volta para o diretório /manifests para que os pods estáticos possam ser reiniciados.

sudo mv /backup/etcd.yaml /etc/kubernetes/manifests/etcd.yaml
sudo mv /backup/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml

Execute um shell Bash no contêiner do etcd:

kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
    ETCD_POD_NAME --container etcd --namespace kube-system \
    -- bin/sh

Use etcdctl para confirmar que o membro adicionado está funcionando corretamente.

ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt  \
    --key=/etc/kubernetes/pki/etcd/peer.key \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --endpoints=CONTROL_PLANE_IP:2379 \
    endpoint health

Se você estiver restaurando vários membros com falha, depois que todos os membros com falha tiverem sido restaurados, execute o comando com os endereços IP do plano de controle de todos os membros restaurados no campo "--endpoints".

Exemplo:

ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt  \
    --key=/etc/kubernetes/pki/etcd/peer.key \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --endpoints=10.200.0.3:2379,10.200.0.4:2379,10.200.0.5:2379 \
    endpoint health

Em caso de êxito em todos os endpoints, o cluster estará funcionando corretamente.

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.

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.

Os clusters do Anthos em bare metal versão 1.14 e posterior têm mensagens de erro mais claras em que os 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.