Fazer backup e restaurar um cluster de usuário

Version 1.28 

• Versão 1.28 (mais recente)
• Versão 1.16
• Versão 1.15
• Versões anteriores (sem suporte)

Este documento mostra como fazer backup e restauração do armazenamento etcd para um cluster de usuário. Esta página também fornece um script que pode ser usado para fazer backup automático do armazenamento etcd de um cluster.

É possível criar um arquivo de backup para recuperação de desastres imprevistos que podem danificar os dados etcd do cluster. Armazene o arquivo de backup em um local fora do cluster que não dependa da operação dele.

Aviso: usar um arquivo de backup para restaurar os dados do etcd é o último recurso. Não recomendamos 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.

Limitações

• Este procedimento não faz backup de dados específicos do aplicativo.

• Este procedimento não faz backup dos PersistentVolumes.

• As cargas de trabalho programadas após a criação de um backup não são restauradas com esse backup.

• Não é possível restaurar um cluster após uma falha no upgrade.

• Esse procedimento não tem a finalidade de restaurar um cluster excluído.

Como fazer backup de um cluster de usuário

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

As etapas de backup a serem seguidas dependem da ativação do Controlplane V2 no cluster de usuário. Quando o plano de controle V2 está ativado, o plano do cluster de usuário é executado no próprio cluster. Quando o plano de controle V2 não está ativado, o plano de controle do cluster de usuário é executado em um ou mais nós no cluster de administrador, chamado de 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 a saída for true, siga as etapas do Controlplane V2 para fazer backup do cluster. Caso contrário, siga as etapas do Kubeception.

Cubecepção

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

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

   onde:

   • ADMIN_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de administrador.
   • USER_CLUSTER_NAME é o nome do cluster de usuário.

2. No shell, no diretório /tmp, crie um backup 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
   

3. No shell, insira exit para sair.

4. Copie /tmp/snapshot.db do contêiner 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
   

Plano de controle V2

1. Consiga 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"}'
   

   onde:

   • USER_CLUSTER_KUBECONFIG é o arquivo kubeconfig do cluster de usuário.

   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
   

   Observe que pode haver vários pods etcd, por exemplo, três para clusters de alta disponibilidade. Para backup, qualquer pod etcd deve funcionar.

2. Coloque um shell no contêiner etcd:

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

   onde:

   • POD_NAME é o nome do pod do etcd retirado da etapa anterior.

3. No shell, crie um arquivo de backup chamado 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
   

4. No shell, insira exit para sair.

5. Copie snapshot.db do contêiner 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
   

6. Copie os secrets do diretório PKI:

   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
   

   onde:

   • NODE_NAME é o arquivo que contém a chave SSH para o nó do plano de controle.
   • NODE_EXTERNAL_IP é o endereço IP do nó do plano de controle do usuário de que você quer que os secrets sejam copiados.
   Observação :para clusters de alta disponibilidade, copie os secrets de todos os nós do plano de controle do usuário usando as instruções

Como restaurar um cluster de usuário de um backup (que não é de HA)

Antes de usar um arquivo de backup para restaurar o armazenamento etcd do cluster de usuários, faça o diagnóstico do seu cluster e resolva problemas existentes. Usar um backup para restaurar um cluster problemático pode recriar ou piorar problemas. Entre em contato com a equipe de suporte do GKE no VMware para receber mais ajuda sobre como restaurar os clusters.

Nas instruções a seguir, explicamos como usar um arquivo de backup para restaurar um cluster de usuário nos casos em que os dados do etcd do cluster foram corrompidos e o pod do etcd apresenta um loop de falhas.

Cubecepção

É possível restaurar os dados do etcd implantando um pod utilitário que substitui os dados corrompidos pelo backup. O servidor da API do cluster de administrador precisa estar em execução, e o programador do cluster de administrador tem de ser capaz de programar novos pods.

1. Encontre o nome do secret usado pelo etcd no cluster do usuário:

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

2. Copie o seguinte manifesto de pod em um arquivo chamado etcd-utility.yaml. Substitua:

   • NODE_NAME: o nó em que o pod kube-etcd-0 está em execução.

   • ADMIN_CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster de administrador.

   • USER_CLUSTER_NAME: o nome do cluster do usuário.

   • GKE_ON_PREM_VERSION: a versão do cluster em que você quer executar a restauração do etcd (por exemplo, 1.5.0-gke.0).

   • KUBE_ETCD_SECRET_NAME: o nome do secret usado pelo etcd no cluster do usuário, começando com 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
   

3. Implante o pod utilitário:

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

4. Copie snapshot.db do diretório atual para o diretório raiz do pod utilitário:

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

5. Coloque um shell no contêiner etcd-utility:

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

6. No shell, no diretório raiz, execute o seguinte comando para criar uma nova pasta 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
   

7. No shell, exclua os dados antigos do etcd:

   rm -r var/lib/etcd/*
   

8. No shell, copie os dados do etcd restaurados para o local permanente:

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

9. No shell, insira exit para sair.

10. Exclua o pod do etcd com falha:

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

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

12. Exclua o pod utilitário:

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

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

    rm etcd-utility.yaml
    

Plano de controle V2

É possível restaurar os dados do etcd um de cada vez, implantando um contêiner temporário do etcd que substitui os dados danificados pelo backup.

1. Insira um shell no nó do plano de controle do usuário:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

2. No shell, interrompa o servidor da API Kubernetes e o servidor etcd:

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

3. No shell, digite exit para sair.

4. Execute scp para copiar o arquivo de backup snapshot.db e os secrets para o nó do plano de controle do usuário:

   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
   

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

   sudo docker run --rm -t \
   -v /opt/data/var/lib:/var/lib \
   -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
   -v /tmp:/tmp \
   --env ETCDCTL_API=3 \
   gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION 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
   

   onde:

   • GKE_ON_PREM_VERSION é a versão do GKE Enterprise usada como tag de imagem;
   • NODE_NAME é o nome do nó em que a restauração está sendo realizada.
   • NODE_IP_ADDRESS é o IP do nó mencionado

6. Adicione a flag - --initial-cluster-state=new ao arquivo de manifesto do etcd no comando do contêiner.

   Exemplo:

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

7. No shell, inicie os servidores kube-apiserver e etcd:

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

8. No shell, digite exit para sair.

Observação: se os pods events-etcd estiverem no estado CrashLoopBackOff, adicione a sinalização - --initial-cluster-state=new e reinicie os pods. Os eventos vão ficar fora de sincronia, e você vai perder os eventos armazenados anteriormente.

Como restaurar um cluster de usuário de um backup (HA)

Cubecepção

Esta seção mostra como restaurar os dados do etcd para um cluster de usuário de alta disponibilidade (HA).

Para um cluster de usuário HA, existem três nós no cluster de administrador que servem como planos de controle para o cluster de usuário. Cada um desses nós executa um pod do etcd que mantém os dados do etcd em um volume de armazenamento.

Se dois dos pods do etcd estiverem íntegros e os dados nos volumes de armazenamento associados estiverem intactos, não será necessário usar um arquivo de backup. Isso ocorre porque você ainda tem um quórum de etcd.

No caso raro em que dois dos volumes de armazenamento etcd tenham dados corrompidos, você precisará usar um arquivo de backup para restaurar os dados etcd.

Para executar as etapas desta seção, você precisa já ter criado um arquivo snapshot.db, conforme descrito em Como fazer backup de um cluster de usuário.

Como listar seus pods e nós do etcd

1. Liste os pods do etcd que gerenciam o armazenamento etcd para seu cluster de usuários. Esses 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 etcd e os nós em que eles são executados. Os nós mostrados na saída são do cluster de administrador, e servem como planos de controle para o cluster de usuário:

   NAME              ...   NODE
   kube-etcd-0       ...   xxx
   kube-etcd-1       ...   yyy
   kube-etcd-2       ...   zzz
   

2. Anote os nomes dos pods e os nomes dos nós do plano de controle para uso posterior.

   Observe que cada pod do etcd é chamado de kube-etcd anexado com um número. Esse número é chamado de número de membro do pod. Ele identifica o pod como um membro específico do cluster do etcd com os dados de objeto para o cluster de usuário. Este guia usa o marcador MEMBER_NUMBER para se referir ao número de membro do pod do etcd.

   Observe também que cada pod no cluster do etcd é executado no próprio nó.

Como se preparar para implantar os pods utilitários

1. Salve um manifesto para o PodDisruptionBudget (PDB) do servidor da API Kubernetes do cluster de usuário. Em seguida, exclua 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
   

2. Interrompa o servidor da API Kubernetes e a implantação de manutenção do etcd. Isso garante que nenhum componente usará o etcd durante a restauração:

   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
   

3. Lembre-se do nome da imagem do contêiner dos pods do etcd.

Como implantar os pods utilitários

Importante: execute as etapas desta seção para cada um dos pods do etcd.

1. Lembre-se do nome do pod do etcd e do nome do nó em que o pod é executado.

2. Salve o seguinte manifesto de pod no diretório atual em um arquivo chamado 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 utilitário executado temporariamente para restaurar dados do etcd.

1. Crie o pod utilitário no seu cluster de administrador:

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

2. Copie o arquivo de backup, snapshot.db, para o diretório raiz do pod utilitário:

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

3. Coloque um shell no contêiner etcd-utility no pod utilitário:

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

4. No 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 do etcd no diretório /kube-etcd-MEMBER_NUMBER.etcd.

5. No shell, exclua os dados antigos do etcd:

   rm -r var/lib/etcd/*
   

6. No shell, copie os dados do etcd restaurados para o local permanente:

   cp -r kube-etcd-MEMBER_NUMBER.etcd/* var/lib/etcd/
   

7. No shell, remova o diretório temporário do etcd e o arquivo de backup:

   rm -R kube-etcd-MEMBER_NUMBER.etcd/
   rm snapshot.db
   

8. No shell, insira exit para sair.

9. Exclua o pod utilitário:

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

Como reiniciar componentes

Agora que você implantou e excluiu os pods utilitários, é necessário reiniciar alguns componentes do cluster.

1. Reinicie os pods no StatefulSet kube-etcd:

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

2. Inicie os servidores da API Kubernetes para o cluster de usuário:

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

3. Inicie a implantação de manutenção do etcd no cluster de usuário:

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

4. Restaure o PDB para o servidor da API Kubernetes:

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

Plano de controle V2

Esta seção mostra como restaurar os dados do etcd para um cluster de usuário de alta disponibilidade (HA).

Para um cluster de usuário de alta disponibilidade, há três nós no cluster de usuário que servem como plano de controle para o cluster de usuário. Cada um desses nós executa um pod do etcd que mantém os dados do etcd em um volume de armazenamento.

Se dois dos pods do etcd estiverem íntegros e os dados nos volumes de armazenamento associados estiverem intactos, não será necessário usar um arquivo de backup. Isso porque você ainda teria um quórum de etcd.

No caso raro em que dois dos volumes de armazenamento etcd tenham dados corrompidos, você precisará usar um arquivo de backup para restaurar os dados etcd.

Para realizar as etapas desta seção, você precisa ter criado um arquivo snapshot.db, conforme descrito em Como fazer backup de um cluster de usuário.

Como listar seus pods e nós do etcd

Importante :siga as etapas nas seções a seguir para cada um dos nós de CP do cluster de usuário.

1. Liste os pods etcd e os respectivos nós:

   kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -l component=etcd,tier=control-plane -o wide
   

   A saída mostra os pods etcd e os nós em que eles são executados. Os nós mostrados na saída são do cluster de administrador, e servem como planos de controle para o cluster de usuário:

   NAME           ...   NODE
   etcd-xxx       ...   xxx
   etcd-yyy       ...   yyy
   etcd-zzz       ...   zzz
   

2. Anote os nomes dos pods e os nomes dos nós do plano de controle para uso posterior.

   Observe que cada pod do etcd é denominado etcd-xxx anexado com um nome de nó. Isso ocorre porque no plano de controle V2 os pods do etcd são executados como um pod estático.

Preparando a restauração

1. Execute scp para copiar o arquivo de backup snapshot.db para todos os nós do plano de controle do usuário:

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

2. Copie os secrets para o respectivo nó do plano de controle do usuário:

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

3. Insira um shell no nó do plano de controle do usuário:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

Como realizar a restauração

1. Lembre-se do nome do pod do etcd e do nome do nó em que o pod é executado.

2. No shell, interrompa o servidor da API Kubernetes e o servidor do etcd em todos os nós do plano de controle do usuário:

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

3. No shell, use snapshot.db para restaurar os dados do etcd em todos os nós do plano de controle do usuário:

   sudo docker run --rm -t \
   -v /opt/data/var/lib:/var/lib \
   -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
   -v /tmp:/tmp \
   --env ETCDCTL_API=3 \
   gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION 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
   

   onde:

   • GKE_ON_PREM_VERSION é a versão do GKE Enterprise usada como tag de imagem;
   • NODE_NAME é o nome do nó em que a restauração está sendo realizada.
   • NODE_IP_ADDRESS é o IP do nó mencionado
   • Preencha NODE1, NODE2, NODE3 e IP do respectivo nó para a sinalização --initial-cluster. Também é possível conseguir isso no manifesto do etcd.

4. Adicione a flag - --initial-cluster-state=existing ao arquivo de manifesto do etcd no comando do contêiner.

   Exemplo:

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

Como reiniciar componentes

1. No shell, inicie os servidores kube-apiserver e etcd em todos os nós do plano de controle do usuário:

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

2. No shell, digite exit para sair.

3. Verifique se kube-apiserver e etcd estão em execução em todos os nós do plano de controle do usuário:

   kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
   -n kube-system -l tier=control-plane
   

Observação: se os pods events-etcd estiverem no estado CrashLoopBackOff, adicione a sinalização - --initial-cluster-state=new e reinicie os pods. Os eventos vão ficar fora de sincronia, e você vai perder os eventos armazenados anteriormente.

Backup automático de cluster

É possível usar o script fornecido aqui como um exemplo de como fazer backup dos clusters automaticamente. O script a seguir não é compatível, e só deve ser usado 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:

Cubecepção

• Defina BACKUP_DIR como o caminho em que você quer armazenar os backups de cluster de administrador e de usuário. Esse caminho não deveria existir.
• 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 sua chave SSH.
• 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/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

Plano de controle V2

• Defina BACKUP_DIR como o caminho em que você quer armazenar os backups de cluster de administrador e de usuário. Esse caminho não deveria existir.
• Defina ADMIN_CLUSTER_KUBECONFIG como o caminho do arquivo kubeconfig do cluster de administrador.
• Defina USER_CLUSTER_KUBECONFIG como o caminho do kubeconfig do cluster de usuário.
• 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 sua chave SSH.
• 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_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

Verificar a restauração

Para verificar se o cluster foi restaurado, execute gkectl diagnose cluster.

A seguir

• Fazer backup e restaurar um cluster de administrador
• 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.