Como fazer backup e restaurar clusters

Nesta página, descrevemos como criar e restaurar manualmente backups do armazenamento de chaves-valor etcd dos clusters do usuário e de administrador do GKE On-Prem. Esta página também fornece um script que pode ser usado para fazer o backup automático dos armazenamentos etcd dos clusters.

Crie backups para recuperação de desastres previstos que possam danificar dados etcd e secrets. Certifique-se de armazenar backups em um local que não esteja no cluster e que não dependa da operação do cluster. Para permanecer seguro, considere criar uma cópia do backup.

Embora o pod de eventos etcd executado em cada cluster não seja essencial para a restauração de um cluster de usuário, é possível seguir um processo semelhante para fazer o backup dele. Observe também que esse procedimento permite fazer o backup apenas dos armazenamentos do etcd. Os PersistentVolumes não são armazenados em backup como parte deste guia, e você precisa planejar um procedimento adicional de backup e restauração para eles.

Restrições

• O backup de dados específicos do aplicativo está fora do escopo desse recurso.
• Os secrets permanecem válidos até que sejam girados manualmente.
• As cargas de trabalho programadas após a criação de um backup não são restauradas com esse backup.
• No momento, não é possível restaurar a partir de upgrades com falha no cluster.
• Esse procedimento não tem a finalidade de restaurar um cluster excluído.

Problemas conhecidos

Ao executar comandos sudo, você pode encontrar o seguinte erro:

sudo: unable to resolve host gke-admin-master-[CLUSTER_ID]

Se você fizer isso, adicione a linha a seguir ao arquivo /etc/hosts:

127.0.0.1 gke-admin-master-[CLUSTER_ID]

Backups de cluster de usuário

Um backup de cluster de usuário contém um snapshot do etcd do cluster de usuário. O etcd de um cluster contém, entre outras coisas, todos os objetos do Kubernetes e quaisquer objetos personalizados necessários para gerenciar o estado do cluster. Esse snapshot contém os dados necessários para recriar os componentes e as cargas de trabalho do cluster.

Como fazer backup de um cluster de usuário

O etcd de um cluster de usuário é armazenado no nó do plano de controle, que você pode acessar usando o kubeconfig do cluster de administrador.

Para criar um snapshot do etcd, execute as seguintes etapas:

1. Coloque um shell no contêiner no kube-etcd:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] exec \
   -it -n [USER_CLUSTER_NAME] kube-etcd-0 -c \
   kube-etcd -- bin/sh

   em que:

   • [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador.
   • [USER_CLUSTER_NAME] é o nome do cluster de usuário. Especificamente, você está transmitindo um namespace no cluster de administrador que tem o nome do cluster de usuário.

2. No shell, use etcdctl para criar um backup chamado snapshot.db no diretório local:

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
   --cacert=/etcd.local.config/certificates/etcdCA.crt \
   --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key \
   snapshot save snapshot.db

3. Saia do contêiner:

   exit

4. Copie o backup do contêiner kube-etcd usando kubectl cp:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
   [USER_CLUSTER_NAME]/kube-etcd-0:snapshot.db [DIRECTORY] -c kube-etcd

   em que [RELATIVE_DIRECTORY] é um caminho em que você quer armazenar o backup.

Como restaurar o backup de um cluster de usuário

• Antes de restaurar um backup, faça o diagnóstico do cluster e resolva os problemas atuais. A restauração de um backup para um cluster problemático pode recriar ou agravar problemas. Entre em contato com a equipe de suporte do GKE On-Prem para receber mais ajuda sobre como restaurar os clusters.

• Se você criou um cluster de usuário HA, execute estas etapas uma vez por membro do cluster do etcd. É possível usar o mesmo snapshot ao restaurar cada membro do etcd. Não siga essas etapas, a menos que todos os pods do etcd estejam em um loop de falhas: isso indica que há dados corrompidos.

Loop de falhas etcd do pod

As instruções a seguir mostram como restaurar um backup nos casos em que os dados do etcd de um cluster do usuário foram corrompidos e o pod do etcd está causando um loop de falhas. É possível realizar a recuperação implantando um pod etcd nos volumes do pod e substituindo os dados danificados pelo backup, supondo que o servidor da API do cluster de usuários esteja em execução e possa programar novos pods.

1. Copie a especificação de pod do etcd abaixo de um arquivo, restore-etcd.yaml, depois de preencher os seguintes valores de marcador:

   • [MEMBER_NUMBER] é o pod numerado que você está restaurando.
   • [NODE_NAME] é o nó em que o pod [MEMBER_NUMBER[ está em execução.
   • [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador.
   • [USER_CLUSTER_NAME] é o nome do cluster de usuário.

   • [DEFAULT_TOKEN] é usado para autenticação. Para encontrar esse valor, execute o comando a seguir:

     kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
     -n [USER_CLUSTER_NAME] get pods kube-etcd-0 \
     -o yaml | grep default-token

   Observação: o valor image abaixo pressupõe que você esteja usando o registro gcr.io Altere o nome da imagem, se você estiver usando um registro particular.

   restore-etcd.yaml

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       Component: restore-etcd-[MEMBER_NUMBER]
     name: restore-etcd-0
     namespace: [USER_CLUSTER_NAME]
   spec:
     restartPolicy: Never
     containers:
     - command: ["/bin/sh"]
       args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
       image: gcr.io/gke-on-prem-release/etcd:v3.2.24-1-gke.0
       imagePullPolicy: IfNotPresent
       name: restore-etcd
       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
       volumeMounts:
       - mountPath: /var/lib/etcd
         name: data
       - mountPath: /etcd.local.config/certificates
         name: etcd-certs
       - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
         name: [DEFAULT_TOKEN]
         readOnly: true
     dnsPolicy: ClusterFirst
     hostname: restore-etcd-0
     imagePullSecrets:
     - name: private-registry-creds
     nodeSelector:
       kubernetes.googleapis.com/cluster-name: [USER_CLUSTER_NAME]
       kubernetes.io/hostname: [NODE_NAME]
     priority: 0
     restartPolicy: Always
     schedulerName: default-scheduler
     securityContext: {}
     serviceAccount: default
     serviceAccountName: default
     subdomain: restore-etcd
     terminationGracePeriodSeconds: 30
     tolerations:
     - effect: NoExecute
       key: node.kubernetes.io/not-ready
       operator: Exists
       tolerationSeconds: 300
     - effect: NoExecute
       key: node.kubernetes.io/unreachable
       operator: Exists
       tolerationSeconds: 300
     volumes:
     - name: data
       persistentVolumeClaim:
         claimName: data-kube-etcd-[MEMBER_NUMBER]
     - name: etcd-certs
       secret:
         defaultMode: 420
         secretName: kube-etcd-certs
     - name: [DEFAULT_TOKEN]
       secret:
         defaultMode: 420
         secretName: [DEFAULT_TOKEN]
         

2. Implante o pod:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -n [USER_CLUSTER_NAME] create -f restore-etcd.yaml

3. Copie o arquivo de backup do etcd, snapshot.db, para o novo pod. snapshot.db fica no diretório relativo em que você criou o backup:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   cp [RELATIVE_DIRECTORY]/snapshot.db \
   [USER_CLUSTER_NAME]/restore-etcd-0:snapshot.db

4. Ative o shell no pod restore-etcd:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -it -n [USER_CLUSTER_NAME] exec restore-etcd-0 -- bin/sh

5. Execute o seguinte comando para criar uma nova pasta default.etcd que contenha o backup:

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
   --cacert=/etcd.local.config/certificates/etcdCA.crt \
   --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key \
   snapshot restore snapshot.db

6. Substitua os dados danificados do etcd pelo backup:

   rm -r var/lib/etcd/*; cp -r default.etcd/* var/lib/etcd/

7. Saia do contêiner:

   exit

8. Exclua o pod com falha etcd:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -n [USER_CLUSTER_NAME] delete pod kube-etcd-0

9. Verifique se o pod do etcd não está mais falhando.

10. Remova restore-etcd.yaml e exclua o pod restore-etcd:

    rm restore-etcd.yaml;
    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    -n [USER_CLUSTER_NAME] delete pod restore-etcd-0

Backups de cluster do administrador

Um backup de cluster de administrador contém os seguintes elementos:

• Um snapshot do etcd do cluster de administrador.
• Os Secrets do plano de controle do administrador, necessários para a autenticação nos clusters de administrador e de usuário.

Conclua as etapas a seguir antes de criar um backup do cluster de administrador:

1. Encontre o endereço IP externo do cluster de administrador, que é usado para fazer o SSH no plano de controle do cluster de administrador:

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get nodes -n kube-system -o wide | grep master

   em que [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador.

2. Crie uma chave SSH chamada vsphere_tmp a partir da chave privada do cluster de administrador.

   É possível encontrar a chave privada nos Secrets dos clusters de administrador:

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get secrets sshkeys -n kube-system -o yaml

   Na resposta ao comando, encontre a chave privada no campo vsphere_tmp.

   Copie a chave privada para vsphere_tmp:

   echo "[PRIVATE_KEY]" | base64 -d > vsphere_tmp; chmod 600 vsphere_tmp

3. Verifique se é possível entrar no plano de controle do administrador usando esta chave privada:

   ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
   

4. Saia do contêiner:

   exit

Como fazer backup de um cluster de administrador

É possível fazer o backup do etcd de um cluster de administrador e dos secrets do plano de controle.

etcd

Para fazer o backup do etcd do cluster de administração:

1. Consiga o nome do pod etcd:

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get pods \
   -n kube-system | grep etcd-gke-admin-master

2. Coloque um shell no contêiner kube-etcd do pod:

   kubectl --kubeconfig [ADMIN_KUBECONFIG]  exec -it \
   -n kube-system [ADMIN_ETCD_POD] -- bin/sh

   em que [ADMIN_ETCD_POD] é o nome do pod etcd.

3. No shell, use etcdctl para criar um backup chamado snapshot.db no diretório local:

   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 snapshot.db

4. Saia do contêiner:

   exit

5. Copie o backup do contêiner kube-etcd usando kubectl cp:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
   kube-system/[ADMIN_ETCD_POD]:snapshot.db [RELATIVE_DIRECTORY]
   

   em que [RELATIVE_DIRECTORY] é um caminho em que você quer armazenar o backup.

Secrets

Para fazer backup dos secrets do plano de controle do administrador:

1. Coloque um Shell no nó do plano de controle de administrador:

   ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
   

   em que [EXTERNAL_IP] é o endereço IP externo do plano de controle do administrador coletado anteriormente.

2. Crie um diretório de backup local. Isso é opcional, mas altamente recomendado. É necessário alterar as permissões dos Secrets de backup para copiá-los do nó:

   mkdir backup

3. Copie localmente os Secrets para o diretório de backup local:

   sudo cp -r /etc/kubernetes/pki/* backup/

4. Altere as permissões dos Secrets de backup:

   sudo chmod -R +rw backup/

5. Saia do contêiner:

   exit

6. Execute scp para copiar a pasta de backup do nó do plano de controle do administrador:

   sudo scp -r -i vsphere_tmp  ubuntu@[EXTERNAL_IP]:backup/ [RELATIVE_DIRECTORY]
   

   em que [RELATIVE_DIRECTORY] é um caminho em que você quer armazenar o backup.

Como restaurar um cluster de administrador

O procedimento a seguir recria um cluster de administrador armazenado em backup e todos os planos de controle do usuário que ele gerenciou quando o snapshot do etcd foi criado.

Observação: o cluster de usuários ainda pode executar as cargas de trabalho mesmo que o plano de controle do usuário esteja inativo. No entanto, se um plano de controle do usuário estiver inativo, ele não poderá programar cargas de trabalho novas ou atualizadas nem lidar com outras falhas de cluster.

1. Execute scp para copiar snapshot.db para o plano de controle do administrador:

   sudo scp -i vsphere_tmp snapshot.db ubuntu@[EXTERNAL_IP]:

   em que [EXTERNAL_IP] é o endereço IP externo do plano de controle do administrador coletado anteriormente.

2. Coloque um shell no plano de controle do administrador:

   sudo ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
   

3. Copie snapshot.db/ para /mnt:

   sudo cp snapshot.db /mnt/

4. Crie um diretório temporário, como backup:

   Observação: isso não será necessário se já houver uma pasta de backup contendo os Secrets.

   mkdir backup

5. Saia do plano de controle do administrador:

   exit

6. Copie os certificados para backup/:

   sudo scp -r -i vsphere_tmp [BACKUP_CERT_FILE] ubuntu@[EXTERNAL_IP]:backup/

7. Coloque um Shell no nó do plano de controle de administrador:

   ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
   

   em que [EXTERNAL_IP] é o endereço IP externo do plano de controle do administrador coletado anteriormente.

8. Execute kubeadm reset. Isso interrompe tudo que ainda está em execução no cluster de administrador, exclui todos os dados do etcd e exclui os Secrets em /etc/kubernetes/pki/:

   sudo kubeadm reset --ignore-preflight-errors=all

9. Copie os Secrets de backup para /etc/kubernetes/pki/:

   sudo cp -r backup/* /etc/kubernetes/pki/

10. Execute etcdctl restore com o Docker:

    sudo docker run --rm \
    -v '/mnt:/backup' \
    -v '/var/lib/etcd:/var/lib/etcd' --env ETCDCTL_API=3 'k8s.gcr.io/etcd-amd64:3.1.12' /bin/sh -c "etcdctl snapshot restore '/backup/snapshot.db'; mv /default.etcd/member/ /var/lib/etcd/"

11. Execute kubeadm init. Isso reutiliza todos os Secrets de backup e reinicia o etcd com o snapshot restaurado:

    sudo kubeadm init --config /etc/kubernetes/kubeadm_config.yaml --ignore-preflight-errors=DirAvailable--var-lib-etcd

12. Saia do plano de controle do administrador:

    exit

13. Copie o arquivo kubeconfig recém-gerado do nó de administrador:

    sudo scp -i vsphere_tmp ubuntu@[EXTERNAL_IP]:[HOME]/.kube/config kubeconfig

    em que:

    • [EXTERNAL_IP] é o endereço IP externo do plano de controle de administrador.
    • [HOME] é o diretório inicial no nó de administrador.

    Agora é possível usar esse novo arquivo kubeconfig para acessar o cluster restaurado.

Script de backup

Use o script incluído aqui para fazer backup dos seus clusters automaticamente. Antes de executar o script, preencha os valores das cinco variáveis no início do script:

• Defina BACKUP_DIR como o caminho em que você quer armazenar os backups dos clusters de administrador e de usuário.
• Defina ADMIN_CLUSTER_KUBECONFIG como o caminho do arquivo kubeconfig do cluster de administrador.
• Defina USER_CLUSTER_NAMESPACE como o nome do cluster de usuário. O nome do cluster de usuário é um namespace no cluster de administração.
• Defina EXTERNAL_IP como o VIP que você reservou para o serviço de plano de controle do administrador.
• Defina SSH_PRIVATE_KEY como o caminho da chave SSH que você criou ao configurar a estação de trabalho do administrador.
• Se você estiver usando uma rede privada, defina JUMP_IP como o endereço IP do servidor jump da sua rede.

#!/usr/bin/env bash

# Automates manual steps for taking backups of user and admin clusters.
# Fill in the variables below before running the script.

BACKUP_DIR=""                       # path to store user and admin cluster backups
ADMIN_CLUSTER_KUBECONFIG=""         # path to admin cluster kubeconfig
USER_CLUSTER_NAMESPACE=""           # user cluster namespace
EXTERNAL_IP=""                      # admin control plane node external ip - follow steps in documentation
SSH_PRIVATE_KEY=""                  # path to vsphere_tmp ssh private key - follow steps in documentation
JUMP_IP=""                          # network jump server IP - leave empty string if not using private network.

mkdir -p $BACKUP_DIR
mkdir $BACKUP_DIR/pki

# USER CLUSTER BACKUP

# Snapshot user cluster etcd
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG}  exec -it -n ${USER_CLUSTER_NAMESPACE} kube-etcd-0 -c kube-etcd -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etcd.local.config/certificates/etcdCA.crt --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key snapshot save ${USER_CLUSTER_NAMESPACE}_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp ${USER_CLUSTER_NAMESPACE}/kube-etcd-0:${USER_CLUSTER_NAMESPACE}_snapshot.db $BACKUP_DIR/

# ADMIN CLUSTER BACKUP

# Set up ssh options
SSH_OPTS=(-oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY})
if [ "${JUMP_IP}" != "" ]; then
    SSH_OPTS+=(-oProxyCommand="ssh -oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY} -W %h:%p ubuntu@${JUMP_IP}")
fi

# Copy admin certs
ssh "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP}:/etc/kubernetes/pki/* ${BACKUP_DIR}/pki/

# Snapshot admin cluster etcd
admin_etcd=$(kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} get pods -n kube-system -o=name | grep etcd | cut -c 5-)
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG}  exec -it -n kube-system ${admin_etcd} -- /bin/sh -ec "export 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 admin_snapshot.db"

Solução de problemas

Para mais informações, consulte Solução de problemas.

Como diagnosticar problemas de cluster usando gkectl

Use os comandos gkectl diagnose para identificar problemas de cluster e compartilhar informações do cluster com o Google. Consulte Como diagnosticar problemas de cluster.

Comportamento de geração de registros padrão

Para gkectl e gkeadm, basta usar as configurações de geração de registros padrão:

• Por padrão, as entradas de registro são salvas da seguinte maneira:

  • Para gkectl, o arquivo de registros padrão é /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e está vinculado ao arquivo logs/gkectl-$(date).log no diretório local em que você executa gkectl.
  • Para gkeadm, o arquivo de registros padrão é logs/gkeadm-$(date).log no diretório local em que você executa gkeadm.
• Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam impressas no terminal (quando --alsologtostderr é false).
• O nível de detalhamento -v5 (padrão) abrange todas as entradas de registro exigidas pela equipe de suporte.
• O arquivo de registros também contém o comando executado e a mensagem de erro.

Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.

Como especificar um local não padrão para o arquivo de registros

Se quiser especificar um local não padrão para o arquivo de registros gkectl, use a sinalização --log_file. O arquivo de registro que você especificar não será vinculado ao diretório local.

Se quiser especificar um local não padrão para o arquivo de registros gkeadm, use a sinalização --log_file.

Como localizar registros da API Cluster no cluster de administrador

Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:

1. Encontre o nome do pod de controladores da API Cluster no namespace kube-system, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

2. Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use grep ou uma ferramenta semelhante para pesquisar erros:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

A seguir

• Saiba como diagnosticar problemas de cluster
• Saiba mais sobre o Augur, uma ferramenta de código aberto para restaurar objetos individuais de backups do etcd.