Fazer backup e restaurar clusters

Version 1.7 (unsupported)

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

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.

Aviso: usar um arquivo de backup para restaurar os dados do etcd é o último recurso. Não recomendamos fazer a restauração de um arquivo de backup, a menos que o cluster esteja completamente corrompido. Entre em contato com o Suporte do Google e receba ajuda para decidir a melhor solução.

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:

1. 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.

2. 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
   

3. 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
   

4. 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/healthcheck-client.crt \
       --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
       snapshot save snapshotDATESTAMP.db
   

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

5. 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:snapshot.db \
       --container etcd snapshot.db
   

6. Armazene o arquivo de snapshot em um local fora do cluster que não dependa da operação dele.

Arquivar os certificados de 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.

1. Use ssh para se conectar ao plano de controle do cluster como raiz.

   ssh root@CONTROL_PLANE_NAME
   

2. 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.

3. 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.

1. 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:~/
   

2. Use ssh para se conectar ao plano de controle do cluster como raiz.

   ssh root@CONTROL_PLANE_NAME
   

3. 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/
   

4. 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:

1. 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.

2. Copie o arquivo de snapshot do etcd, snapshot.db, 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
   

3. Use SSH para se conectar ao nó do plano de controle:

   ssh root@CONTROL_PLANE_NAME
   

4. 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
   

5. Remova o diretório de dados do etcd.

   rm -rf /var/lib/etcd/
   

6. Executar a restauração de snapshot etcdctl usando o docker.

   sudo docker run --rm -t \
       -v /var/lib:/var/lib \
       -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
       -v /backup:/backup \
       --env ETCDCTL_API=3 \
       k8s.gcr.io/etcd:3.2.24 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.

7. Verifique se /var/lib/etcd foi recriado e se um novo membro foi criado em /var/lib/etcd/member.

8. 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
   

9. 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
   

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

    ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt  \
        --key=/etc/kubernetes/pki/etcd/healthcheck-client.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/healthcheck-client.crt  \
        --key=/etc/kubernetes/pki/etcd/healthcheck-client.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.