Nesta página, descrevemos como criar e restaurar manualmente backups de clusters de administrador e de usuário do GKE On-Prem. Nesta página, também incluímos um script que pode ser usado para fazer backup dos clusters automaticamente.
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.
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:
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.
No shell, use
etcdctl
para criar um backup chamadosnapshot.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
Saia do contêiner:
exit
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 os problemas. Entre em contato com a equipe de suporte do GKE On-Prem para receber mais ajuda de 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.
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
restore-etcd.yaml
apiVersion: v1 kind: Pod metadata: labels: Component: restore-etcd-[MEMBER_NUMBER] name: restore-etcd-0 namespace: restore-etcd-[MEMBER_NUMBER] 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]
Implante o pod:
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ -n [USER_CLUSTER_NAME] create -f restore-etcd.yaml
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
Ative o shell no pod
restore-etcd
:kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ -it -n [USER_CLUSTER_NAME] exec restore-etcd-0 -- bin/sh
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
Substitua os dados danificados do etcd pelo backup:
rm -r var/lib/etcd/*; cp -r default.etcd/* var/lib/etcd/
Saia do contêiner:
exit
Exclua o pod com falha etcd:
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ -n [USER_CLUSTER_NAME] delete pod kube-etcd-0
Verifique se o pod do etcd não está mais falhando.
Remova
restore-etcd.yaml
e exclua o podrestore-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:
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 gke-admin-master
em que [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador.
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
Verifique se é possível entrar no plano de controle do administrador usando esta chave privada:
ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
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:
Consiga o nome do pod etcd:
kubectl --kubeconfig [ADMIN_KUBECONFIG] get pods \ -n kube-system | grep etcd-gke-admin-master
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.
No shell, use
etcdctl
para criar um backup chamadosnapshot.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
Saia do contêiner:
exit
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:
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.
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
Copie localmente os Secrets para o diretório de backup local:
sudo cp -r /etc/kubernetes/pki/* backup/
Altere as permissões dos Secrets de backup:
sudo chmod -R +rw backup/
Saia do contêiner:
exit
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.
Execute
scp
para copiarsnapshot.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.
Coloque um shell no plano de controle do administrador:
sudo ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
Copie
snapshot.db/
para/mnt
:sudo cp snapshot.db /mnt/
Crie um diretório temporário, como
backup
:mkdir backup
Saia do plano de controle do administrador:
exit
Copie os certificados para
backup/
:sudo scp -r -i vsphere_tmp [BACKUP_CERT_FILE] ubuntu@[EXTERNAL_IP]:backup/
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.
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
Copie os Secrets de backup para
/etc/kubernetes/pki/
:sudo cp -r backup/* /etc/kubernetes/pki/
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/"
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
Saia do plano de controle do administrador:
exit
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 arquivologs/gkectl-$(date).log
no diretório local em que você executagkectl
. -
Para
gkeadm
, o arquivo de registros padrão élogs/gkeadm-$(date).log
no diretório local em que você executagkeadm
.
-
Para
- 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:
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
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.