Esta página foi traduzida pela API Cloud Translation.

Faça uma cópia de segurança e restaure um cluster de utilizadores

Este documento mostra como fazer uma cópia de segurança e restaurar o armazenamento etcd para um cluster de utilizadores criado com o Google Distributed Cloud (apenas software) para VMware. Esta página também fornece um script que pode usar para fazer uma cópia de segurança automática da loja etcd de um cluster.

Pode criar um ficheiro de cópia de segurança para recuperação de desastres inesperados que possam danificar os dados etcd do cluster. Armazene o ficheiro de cópia de segurança numa localização que esteja fora do cluster e não dependa do funcionamento do cluster.

Limitações

Este procedimento não faz uma cópia de segurança dos dados específicos da aplicação.
Este procedimento não faz uma cópia de segurança dos seus PersistentVolumes.
As cargas de trabalho agendadas após a criação de uma cópia de segurança não são restauradas com essa cópia de segurança.
Não pode restaurar um cluster após uma atualização com falha.
Este procedimento não se destina a restaurar um cluster eliminado.
Não use este procedimento para clusters com a opção cluster avançado ativada. Em alternativa, consulte o artigo Faça uma cópia de segurança e restaure clusters avançados com o gkectl.

Para mais informações sobre as limitações, consulte o artigo Incompatibilidade da infraestrutura.

Fazer uma cópia de segurança de um cluster de utilizadores

Uma cópia de segurança do cluster de utilizadores é uma imagem instantânea do armazenamento etcd do cluster de utilizadores. O armazenamento etcd contém todos os objetos do Kubernetes e objetos personalizados necessários para gerir o estado do cluster. A imagem instantânea contém os dados necessários para recriar os componentes e as cargas de trabalho do cluster.

Os passos de cópia de segurança que segue dependem de o Controlplane V2 estar ativado no cluster de utilizadores. Quando o Controlplane V2 está ativado, o plano de controlo para o cluster de utilizador é executado no próprio cluster de utilizador. Quando o Controlplane V2 não está ativado, o plano de controlo do cluster de utilizadores é executado num ou mais nós no cluster de administrador, o que se denomina kubeception.

Execute o seguinte comando para determinar se o cluster tem o Controlplane V2 ativado:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Se o resultado for true, siga os passos do Controlplane V2 para fazer uma cópia de segurança do cluster. Caso contrário, siga os passos do Kubeception.

Kubeception

Coloque uma concha no contentor kube-etcd:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec -it \
 kube-etcd-0 -c kube-etcd -n USER_CLUSTER_NAME \
 -- /bin/sh
```
where:
- ADMIN_CLUSTER_KUBECONFIG é o ficheiro kubeconfig do cluster de administração.
- USER_CLUSTER_NAME é o nome do cluster de utilizadores.

Na shell, no diretório /tmp, crie uma cópia de segurança com o nome snapshot.db:

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

Na shell, introduza exit para sair da shell.

Copie /tmp/snapshot.db do contentor kube-etcd para o diretório atual:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp \
  USER_CLUSTER_NAME/kube-etcd-0:/tmp/snapshot.db \
  --container kube-etcd snapshot.db

Controlplane V2

Obtenha o nome do pod do etcd:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
 -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}'

where:

USER_CLUSTER_KUBECONFIG é o ficheiro kubeconfig do cluster de utilizadores.

Exemplo:

NAME          READY   STATUS    RESTARTS   AGE
etcd-uc1-cp1  1/1     Running   0          38m
etcd-uc1-cp2  1/1     Running   0          37m
etcd-uc1-cp3  1/1     Running   0          38m

Tenha em atenção que podem existir vários pods etcd, por exemplo, 3 para clusters de HA. Para a cópia de segurança, qualquer etcd pod deve funcionar.

Coloque uma concha no contentor etcd:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG exec -it \
 POD_NAME -c etcd -n kube-system -- /bin/sh

where:

POD_NAME é o nome do pod etcd retirado do passo anterior.

Na shell, crie um ficheiro de cópia de segurança denominado snapshot.db:

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

Na shell, introduza exit para sair da shell.

Copie snapshot.db do contentor etcd para o diretório inicial da estação de trabalho:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
 cp POD_NAME:/tmp/snapshot.db ~/snapshot.db \
 -c etcd -n kube-system

Copie os segredos do diretório de ICP:
```
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
sudo chmod -R 0644 /etc/kubernetes/pki/*
sudo chmod 0755 /etc/kubernetes/pki/etcd
exit
scp -ri NODE_NAME.key ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki ~/pki_NODE_NAME
```
where:
- NODE_NAME é o ficheiro que contém a chave SSH para o nó do plano de controlo
- NODE_EXTERNAL_IP é o endereço IP do nó do plano de controlo do utilizador a partir do qual quer que os segredos sejam copiados.
Nota: para clusters de HA, copie os segredos de todos os nós do plano de controlo do utilizador através das instruções

Restaurar um cluster de utilizadores a partir de uma cópia de segurança (não HA)

Antes de usar um ficheiro de cópia de segurança para restaurar o armazenamento etcd do cluster de utilizadores, diagnostique o cluster e resolva os problemas existentes. A utilização de uma cópia de segurança para restaurar um cluster problemático pode recriar ou agravar os problemas. Contacte a Google Cloud equipa de apoio técnico para receber mais assistência com a restauração dos seus clusters.

As instruções seguintes explicam como usar um ficheiro de cópia de segurança para restaurar um cluster de utilizadores nos casos em que os dados etcd do cluster foram danificados e o pod etcd do cluster de utilizadores está em crashloop.

Kubeception

Pode restaurar os dados do etcd implementando um pod de utilidade que substitui os dados danificados pela cópia de segurança. O servidor da API do cluster de administrador tem de estar em execução e o agendador do cluster de administrador tem de conseguir agendar novos pods.

Encontre o nome do segredo usado pelo etcd no cluster de utilizadores:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME \
   get secrets | grep kube-etcd-certs

Copie o seguinte manifesto do Pod para um ficheiro com o nome etcd-utility.yaml. Substitua o seguinte:

NODE_NAME: o nó onde o pod kube-etcd-0 está a ser executado.
ADMIN_CLUSTER_KUBECONFIG: o ficheiro kubeconfig do cluster de administrador.
USER_CLUSTER_NAME: o nome do cluster de utilizadores.
GKE_ON_PREM_VERSION: a versão do cluster onde quer fazer o restauro do etcd (por exemplo, 1.5.0-gke.0).
KUBE_ETCD_SECRET_NAME: o nome do segredo usado pelo etcd no cluster de utilizadores, começando por kube-etcd-certs.

apiVersion: v1
kind: Pod
metadata:
 name: etcd-utility-0
 namespace: USER_CLUSTER_NAME
spec:
 containers:
 - command: ["/bin/sh"]
   args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
   image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
   name: etcd-utility
   volumeMounts:
   - mountPath: /var/lib/etcd
     name: data
   - mountPath: /etcd.local.config/certificates
     name: etcd-certs
 nodeSelector:
   kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
   kubernetes.io/hostname: NODE_NAME
 tolerations:
 - effect: NoExecute
   key: node.kubernetes.io/not-ready
   operator: Exists
   tolerationSeconds: 300
 - effect: NoExecute
   key: node.kubernetes.io/unreachable
   operator: Exists
   tolerationSeconds: 300
 - effect: NoSchedule
   key: node.kubernetes.io/unschedulable
   operator: Exists
 volumes:
 - name: data
   persistentVolumeClaim:
     claimName: data-kube-etcd-0
 - name: etcd-certs
   secret:
     defaultMode: 420
     secretName: KUBE_ETCD_SECRET_NAME

Implemente o pod de utilidade:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  create -f etcd-utility.yaml --namespace USER_CLUSTER_NAME

Copie snapshot.db do diretório atual para o diretório raiz do pod de utilidade:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp snapshot.db \
  USER_CLUSTER_NAME/etcd-utility-0:snapshot.db --container etcd-utility

Coloque uma concha no contentor etcd-utility:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec it \
  etcd-utility-0 --container etcd-utility --namespace USER_CLUSTER_NAME \
  -- bin/sh

Na shell, no diretório raiz, execute o seguinte comando para criar uma nova pasta que contenha a cópia de segurança:

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

Na shell, elimine os dados etcd antigos:
```
rm -r var/lib/etcd/*
```
Na shell, copie os dados etcd restaurados para a respetiva localização permanente:
```
cp -r default.etcd/* var/lib/etcd/
```
Na shell, introduza exit para sair da shell.

Elimine o pod etcd com falhas de sistema:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  delete pod kube-etcd-0 --namespace USER_CLUSTER_NAME

Verifique se o pod etcd já não está a falhar.

Elimine o pod de utilitários:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  delete pod etcd-utility-0 --namespace USER_CLUSTER_NAME

Remova etcd-utility.yaml do diretório atual:
```
rm etcd-utility.yaml
```

Controlplane V2

Pode restaurar os dados etcd um de cada vez implementando um contentor etcd temporário que substitui os dados danificados pela cópia de segurança.

Obtenha um shell no nó do plano de controlo do utilizador:
```
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
```

Na shell, pare o servidor da API Kubernetes e o servidor etcd:

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

Na shell, introduza exit para sair da shell.

Execute scp para copiar o ficheiro de cópia de segurança snapshot.db e os segredos para o nó do plano de controlo do utilizador:

scp -i NODE_NAME.key ~/snapshot.db ubuntu@NODE_EXTERNAL_IP:/tmp/

chmod a+rw pki/
scp -ri NODE_NAME.key ~/pki_NODE_NAME ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki

Na shell, use snapshot.db para restaurar os dados do etcd:

ETCDCTL_API=3 sudo etcdctl \
 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
 --cert=/etc/kubernetes/pki/etcd/server.crt \
 --key=/etc/kubernetes/pki/etcd/server.key \
 --data-dir=/opt/data/var/lib/etcd \
 --name=NODE_NAME \
 --initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \
 --initial-cluster=NODE_NAME=https://NODE_IP_ADDRESS:2380 \
 snapshot restore /tmp/snapshot.db

Substitua o seguinte:

NODE_NAME: o nome do nó onde a restauração está a ser realizada
NODE_IP_ADDRESS: o endereço IP do nó em questão.

Adicione a flag - --initial-cluster-state=new no ficheiro de manifesto etcd no comando do contentor.

Exemplo:
```
containers:
      - command:
        - etcd
        ...
        - --initial-cluster-state=new
        ...
```

Na shell, inicie os servidores kube-apiserver e etcd:

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

Na shell, introduza exit para sair da shell.

Restaurar um cluster de utilizadores a partir de uma cópia de segurança (HA)

Kubeception

Esta secção mostra como restaurar os dados do etcd para um cluster de utilizadores de alta disponibilidade (HA).

Para um cluster de utilizadores de HA, existem três nós no cluster de administrador que funcionam como planos de controlo para o cluster de utilizadores. Cada um desses nós executa um pod etcd que mantém os dados etcd num volume de armazenamento.

Se dois dos pods etcd estiverem em bom estado e os volumes de armazenamento associados estiverem intactos, não é necessário usar um ficheiro de cópia de segurança. Isto acontece porque ainda tem um quórum do etcd.

No caso raro de dois dos volumes de armazenamento etcd terem dados corrompidos, tem de usar um ficheiro de cópia de segurança para restaurar os dados etcd.

Para realizar os passos nesta secção, tem de ter criado um ficheiro snapshot.db conforme descrito em Fazer uma cópia de segurança de um cluster de utilizadores.

Listar os seus pods e nós etcd

Liste os pods etcd que gerem o armazenamento etcd para o cluster de utilizadores. Estes pods são executados no cluster de administrador:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --namespace USER_CLUSTER_NAME \
--output wide | grep kube-etcd
```
A saída mostra os pods do etcd e os nós onde os pods são executados. Os nós apresentados na saída são nós no cluster de administrador que servem como planos de controlo para o cluster de utilizador:
```
NAME              ...   NODE
kube-etcd-0       ...   xxx
kube-etcd-1       ...   yyy
kube-etcd-2       ...   zzz
```
Tome nota dos nomes dos pods e dos nomes dos nós do plano de controlo para mais tarde.

Tenha em atenção que cada pod do etcd tem o nome kube-etcd seguido de um número. Este número é denominado número de membro do Pod. Identifica o pod como um membro específico do cluster etcd que contém os dados do objeto para o seu cluster de utilizador. Este guia usa o marcador de posição MEMBER_NUMBER para se referir ao número de membros do pod etcd.

Repare também que cada Pod no seu cluster etcd é executado no seu próprio nó.

A preparar a implementação dos pods de utilidade

Guarde um manifesto para o PodDisruptionBudget (PDB) para o servidor da API Kubernetes do cluster de utilizador. Em seguida, elimine o PDB.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG get pdb --namespace USER_CLUSTER_NAME \
kube-apiserver-pdb --output yaml > kube-apiserver-pdb.yaml

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pdb --namespace USER_CLUSTER_NAME \
kube-apiserver-pdb

Pare o servidor da API Kubernetes e a implementação de manutenção do etcd. Isto garante que nenhum componente usa o etcd durante o restauro:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
scale --replicas 0 statefulset kube-apiserver

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
scale --replicas 0 deployment gke-master-etcd-maintenance

Recorde o nome da imagem do contentor para os seus pods etcd.

Implementar os pods de utilidade

Recorde o nome do pod etcd e o nome do nó onde o pod é executado.
Guarde o seguinte manifesto do Pod no diretório atual num ficheiro denominado etcd-utility-MEMBER_NUMBER.yaml:

 apiVersion: v1
 kind: Pod
 metadata:
   name: etcd-utility-MEMBER_NUMBER
   namespace: USER_CLUSTER_NAME
 spec:
   containers:
   - command: ["/bin/sh"]
     args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
     image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
     name: etcd-utility
     volumeMounts:
     - mountPath: /var/lib/etcd
       name: data
     - mountPath: /etcd.local.config/certificates
       name: etcd-certs
   nodeSelector:
     kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
     kubernetes.io/hostname: NODE_NAME
   tolerations:
   - effect: NoExecute
     key: node.kubernetes.io/not-ready
     operator: Exists
     tolerationSeconds: 300
   - effect: NoExecute
     key: node.kubernetes.io/unreachable
     operator: Exists
     tolerationSeconds: 300
   - effect: NoSchedule
     key: node.kubernetes.io/unschedulable
     operator: Exists
   volumes:
   - name: data
     persistentVolumeClaim:
       claimName: data-kube-etcd-MEMBER_NUMBER
   - name: etcd-certs
     secret:
       defaultMode: 420
       secretName: KUBE_ETCD_SECRET_NAME

O manifesto anterior descreve um pod de utilidade que executa temporariamente para restaurar dados do etcd.

Crie o pod de utilidade no cluster de administrador:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f etcd-utility-MEMBER_NUMBER.yaml

Copie o ficheiro de cópia de segurança, snapshot.db, para o diretório raiz do seu utilitário Pod:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG cp snapshot.db \
USER_CLUSTER_NAME/etcd-utility-MEMBER_NUMBER:snapshot.db

Obtenha um shell no contentor etcd-utility no pod de utilidade:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG exec -it --namespace USER_CLUSTER_NAME \
etcd-utility-MEMBER_NUMBER --container etcd-utility -- bin/sh

Na shell, no diretório raiz, use snapshot.db para restaurar os dados do etcd:

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 \
--name=kube-etcd-MEMBER_NUMBER \
--initial-cluster=kube-etcd-0=https://kube-etcd-0.kube-etcd:2380,kube-etcd-1=https://kube-etcd-1.kube-etcd:2380,kube-etcd-2=https://kube-etcd-2.kube-etcd:2380 \
--initial-cluster-token=etcd-cluster-1 \
--initial-advertise-peer-urls=https://kube-etcd-MEMBER_NUMBER.kube-etcd:2380 \
snapshot restore snapshot.db

O comando anterior armazenou dados etcd no diretório /kube-etcd-MEMBER_NUMBER.etcd.

Na shell, elimine os dados etcd antigos:
```
rm -r var/lib/etcd/*
```
Na shell, copie os dados etcd restaurados para a respetiva localização permanente:
```
cp -r kube-etcd-MEMBER_NUMBER.etcd/* var/lib/etcd/
```
Na shell, remova o diretório etcd temporário e o ficheiro de cópia de segurança:
```
rm -R kube-etcd-MEMBER_NUMBER.etcd/
rm snapshot.db
```
Na shell, introduza exit para sair da shell.

Elimine o pod de utilitários:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pod \
--namespace USER_CLUSTER_NAME etcd-utility-MEMBER_NUMBER

Reiniciar componentes

Agora que implementou e eliminou os seus pods de utilidade, tem de reiniciar alguns componentes do cluster.

Reinicie os agrupamentos no StatefulSet kube-etcd:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG rollout restart statefulset \
--namespace USER_CLUSTER_NAME kube-etcd

Inicie os servidores da API Kubernetes para o cluster de utilizadores:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale statefulset --replicas 3 \
--namespace USER_CLUSTER_NAME kube-apiserver

Inicie a implementação da manutenção do etcd para o cluster de utilizadores:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale deployment --replicas 1 \
--namespace=USER_CLUSTER_NAME  gke-master-etcd-maintenance

Restaure o PDB para o servidor da API Kubernetes:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG apply -f kube-apiserver-pdb.yaml

Controlplane V2

Esta secção mostra como restaurar os dados do etcd para um cluster de utilizadores de alta disponibilidade (HA).

Para um cluster de utilizadores de HA, existem três nós no cluster de utilizadores que servem como plano de controlo para o cluster de utilizadores. Cada um desses nós executa um pod etcd que mantém os dados etcd num volume de armazenamento.

No caso raro de dois dos volumes de armazenamento etcd terem dados corrompidos, tem de usar um ficheiro de cópia de segurança para restaurar os dados etcd.

Para realizar os passos nesta secção, já tem de ter criado um ficheiro snapshot.db conforme descrito em Fazer uma cópia de segurança de um cluster de utilizadores.

Listar os seus pods e nós etcd

Liste os pods etcd e o respetivo nó:
```
kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
 -n kube-system -l component=etcd,tier=control-plane -o wide
```
A saída mostra os pods do etcd e os nós onde os pods são executados. Os nós apresentados na saída são nós no cluster de administrador que servem como planos de controlo para o cluster de utilizador:
```
NAME           ...   NODE
etcd-xxx       ...   xxx
etcd-yyy       ...   yyy
etcd-zzz       ...   zzz
```
Tome nota dos nomes dos pods e dos nomes dos nós do plano de controlo para mais tarde.

Tenha em atenção que cada pod etcd tem o nome etcd-xxx anexado a um nome de nó. Isto deve-se ao facto de, no Controlplane V2, os pods etcd serem executados como um pod estático.

A preparar o restauro

Execute scp para copiar o ficheiro de cópia de segurança snapshot.db para todos os nós do plano de controlo do utilizador:
```
scp -i NODE_NAME.key ~/snapshot.db ubuntu@NODE_EXTERNAL_IP:/tmp/
```

Copie os segredos para o nó do plano de controlo do utilizador respetivo:

chmod a+rw ~/pki_*
scp -ri NODE_NAME.key ~/pki_NODE_NAME/* ubuntu@NODE_EXTERNAL_IP:/opt/data/etc/kubernetes/pki/

Obtenha um shell no nó do plano de controlo do utilizador:
```
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
```

Realizar o restauro

Recorde o nome do pod etcd e o nome do nó onde o pod é executado.
Na shell, pare o servidor da API Kubernetes e o servidor etcd em todos os nós do plano de controlo do utilizador:
```
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/etcd.yaml ~
```

Na shell, use snapshot.db para restaurar os dados do etcd em todos os nós do plano de controlo do utilizador:

ETCDCTL_API=3 sudo etcdctl \
 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
 --cert=/etc/kubernetes/pki/etcd/server.crt \
 --key=/etc/kubernetes/pki/etcd/server.key \
 --data-dir=/opt/data/var/lib/etcd \
 --name=NODE_NAME \
 --initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \
 --initial-cluster=NODE1=https://NODE1_IP:2380,NODE2=https://NODE2_IP:2380,NODE3=https://NODE3_IP:2380 \
 snapshot restore /tmp/snapshot.db

Substitua o seguinte:

NODE_NAME: o nome do nó onde está a ser feita a restauração.
NODE_IP_ADDRESS: o endereço IP do nó em questão.
Preencha os campos NODE1, NODE2, NODE3 e os campos NODE1_IP, NODE2_IP, NODE3_IP do respetivo nó para a denúncia --initial-cluster. Também pode obtê-lo a partir do manifesto do etcd.

Adicione a flag - --initial-cluster-state=existing no ficheiro de manifesto etcd no comando do contentor.

Exemplo:
```
containers:
      - command:
        - etcd
        ...
        - --initial-cluster-state=existing
        ...
```

Reiniciar componentes

Na shell, inicie os servidores kube-apiserver e etcd em todos os nós do plano de controlo do utilizador:
```
sudo mv ~/etcd.yaml ~/kube-apiserver.yaml /etc/kubernetes/manifests/
```
Na shell, introduza exit para sair da shell.
Verifique se o kube-apiserver e o etcd estão a ser executados em todos os nós do plano de controlo do utilizador:
```
kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -l tier=control-plane
```

Cópia de segurança automática do cluster

Pode usar o script apresentado aqui como exemplo de como fazer automaticamente uma cópia de segurança dos seus clusters. Tenha em atenção que o seguinte script não é suportado e deve ser usado apenas como referência para escrever um script melhor, mais robusto e completo. Antes de executar o script, preencha os valores das cinco variáveis no início do script:

Kubeception

Defina BACKUP_DIR para o caminho onde quer armazenar as cópias de segurança dos clusters de administrador e de utilizador. Este caminho não deve existir.
Defina ADMIN_CLUSTER_KUBECONFIG para o caminho do ficheiro kubeconfig do cluster de administrador
Defina USER_CLUSTER_NAMESPACE para o nome do cluster de utilizadores. O nome do cluster de utilizadores é um espaço de nomes no cluster de administrador.
Defina EXTERNAL_IP para o VIP que reservou para o serviço do plano de controlo do administrador.
Defina SSH_PRIVATE_KEY para o caminho da sua chave SSH.
Se estiver a usar uma rede privada, defina JUMP_IP para o endereço IP do servidor de encaminhamento 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/user-cluster_${USER_CLUSTER_NAMESPACE}_snapshot.db 

# 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 -r "${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 -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}')
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"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:admin_snapshot.db $BACKUP_DIR/admin-cluster_snapshot.db

Controlplane V2

Defina BACKUP_DIR para o caminho onde quer armazenar as cópias de segurança dos clusters de administrador e de utilizador. Este caminho não deve existir.
Defina ADMIN_CLUSTER_KUBECONFIG para o caminho do ficheiro kubeconfig do cluster de administrador
Defina USER_CLUSTER_KUBECONFIG para o caminho do kubeconfig do cluster de utilizadores.
Defina EXTERNAL_IP para o VIP que reservou para o serviço do plano de controlo do administrador.
Defina SSH_PRIVATE_KEY para o caminho da sua chave SSH.
Se estiver a usar uma rede privada, defina JUMP_IP para o endereço IP do servidor de encaminhamento 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_KUBECONFIG=""          # path to user cluster kubeconfig
EXTERNAL_IP=""                      # admin control plane node external ip - follow steps in documentation
SSH_PRIVATE_KEY=""                  # path to 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
user_etcd=$(kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} get pods -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[0].metadata.name}{"\n"}')
kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} exec -it -n kube-system ${user_etcd} -c 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/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /tmp/${user_etcd}_snapshot.db"
kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} cp kube-system/${user_etcd}:/tmp/${user_etcd}_snapshot.db $BACKUP_DIR/${user_etcd}_snapshot.db

# 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 -r "${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 -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}')
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 /tmp/${admin_etcd}_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:/tmp/${admin_etcd}_snapshot.db $BACKUP_DIR/${admin_etcd}_snapshot.db

Valide o restauro

Para verificar se o cluster foi restaurado com êxito, execute o comando gkectl diagnose cluster.

O que se segue?

Faça uma cópia de segurança e restaure um cluster de administrador
Diagnostique problemas de clusters
Saiba mais sobre o auger, uma ferramenta de código aberto para restaurar objetos individuais a partir de cópias de segurança do etcd.

Faça uma cópia de segurança e restaure um cluster de utilizadores Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Limitações

Fazer uma cópia de segurança de um cluster de utilizadores

Kubeception

Controlplane V2

Restaurar um cluster de utilizadores a partir de uma cópia de segurança (não HA)

Kubeception

Controlplane V2

Restaurar um cluster de utilizadores a partir de uma cópia de segurança (HA)

Kubeception

Listar os seus pods e nós etcd

A preparar a implementação dos pods de utilidade

Implementar os pods de utilidade

Reiniciar componentes

Controlplane V2

Listar os seus pods e nós etcd

A preparar o restauro

Realizar o restauro

Reiniciar componentes

Cópia de segurança automática do cluster

Kubeception

Controlplane V2

Valide o restauro

O que se segue?

Faça uma cópia de segurança e restaure um cluster de utilizadores