Eseguire il backup e il ripristino di un cluster utente

Questo documento mostra come eseguire il backup e il ripristino del repository etcd per un cluster utente creato con Google Distributed Cloud (solo software) per VMware. Questa pagina fornisce anche uno script che puoi utilizzare per eseguire automaticamente il backup dello spazio dati etcd di un cluster.

Puoi creare un file di backup per il recupero da eventi catastrofici imprevisti che potrebbero danneggiare i dati etcd del tuo cluster. Archivia il file di backup in una posizione al di fuori del cluster e non dipendente dal funzionamento del cluster.

Nota: l'utilizzo di uno strumento di backup di terze parti, come Veeam, per eseguire il backup di un cluster di utenti non è supportato. Il backup del cluster con uno strumento di terze parti potrebbe portare a errori imprevisti nelle operazioni del cluster.

Limitazioni

• Questa procedura non esegue il backup dei dati specifici dell'applicazione.

• Questa procedura non esegue il backup dei PersistentVolume.

• I workload pianificati dopo la creazione di un backup non vengono ripristinati con quel backup.

• Non puoi ripristinare un cluster dopo un upgrade non riuscito.

• Questa procedura non è pensata per ripristinare un cluster eliminato.

Avviso: l'utilizzo di un file di backup per ripristinare i dati etcd è l'ultima risorsa. Sconsigliamo di eseguire il ripristino da un file di backup a meno che il cluster non sia completamente guasto. Contatta l'Assistenza Google per decidere la strategia migliore.

Per ulteriori informazioni sulle limitazioni, consulta Incompatibilità dell'infrastruttura.

Eseguire il backup di un cluster utente

Un backup del cluster utente è uno snapshot dello spazio dati etcd del cluster utente. Lo spazio dati etcd contiene tutti gli oggetti Kubernetes e personalizzati necessari per gestire lo stato del cluster. Lo snapshot contiene i dati necessari per ricreare i componenti e i carichi di lavoro del cluster.

I passaggi per il backup da seguire dipendono dall'eventuale attivazione di Controlplane V2 sul cluster utente. Quando il control plane v2 è abilitato, il control plane per il cluster utente viene eseguito sul cluster utente stesso. Se il control plane v2 non è attivo, il control plane per il cluster utente viene eseguito su uno o più nodi nel cluster di amministrazione, operazione nota come kubeception.

Esegui il seguente comando per determinare se nel cluster è attivato Controlplane V2:

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

Se l'output è true, segui la procedura per Control plane V2 per eseguire il backup del cluster. In caso contrario, segui i passaggi di Kubeception.

Kubeception

1. Apri una shell nel contenitore kube-etcd:

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

   dove:

   • ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione.
   • USER_CLUSTER_NAME è il nome del cluster di utenti.

2. Nella shell, nella directory /tmp, crea il backup denominato 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. Nella shell, inserisci exit per uscire dalla shell.

4. Copia /tmp/snapshot.db dal contenitore kube-etcd alla directory corrente:

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

Control plane V2

1. Recupera il nome del pod etcd:

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

   dove:

   • USER_CLUSTER_KUBECONFIG è il file kubeconfig del cluster utente.

   Esempio:

   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
   

   Tieni presente che possono essere presenti più pod etcd, ad esempio 3 per i cluster HA. Per il backup, qualsiasi pod etcd dovrebbe funzionare.

2. Apri una shell nel contenitore etcd:

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

   dove:

   • POD_NAME è il nome del pod etcd preso dal passaggio precedente.

3. Nella shell, crea un file di backup denominato 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. Nella shell, inserisci exit per uscire dalla shell.

5. Copia snapshot.db dal contenitore etcd alla home directory della workstation:

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

6. Copia i secret dalla directory 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
   

   dove:

   • NODE_NAME è il file contenente la chiave SSH per il nodo del piano di controllo
   • NODE_EXTERNAL_IP è l'indirizzo IP del nodo del control plane dell'utente da cui vuoi copiare i secret.
   Nota: per i cluster HA, copia i secret da tutti i nodi del control plane utente seguendo le istruzioni

Ripristino di un cluster utente da un backup (non HA)

Prima di utilizzare un file di backup per ripristinare l'etcd store del cluster utente, diagnosi il cluster e risolvi i problemi esistenti. L'utilizzo di un backup per ripristinare un cluster problematico potrebbe ricreare o aggravare i problemi. Contatta il team di assistenza Google Cloud per ricevere ulteriore assistenza per il ripristino dei cluster.

Le istruzioni riportate di seguito spiegano come utilizzare un file di backup per ripristinare un cluster di utenti nei casi in cui i dati etcd del cluster siano stati danneggiati e il pod etcd del cluster di utenti sia in crashloop.

Kubeception

Puoi ripristinare i dati etcd dispiegando un pod di utilità che sovrascrive i dati danneggiati con il backup. Il server API del cluster di amministrazione deve essere in esecuzione e il programmatore del cluster di amministrazione deve essere in grado di pianificare nuovi pod.

1. Trova il nome del segreto utilizzato da etcd nel cluster utente:

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

2. Copia il seguente manifest del pod in un file denominato etcd-utility.yaml. Sostituisci quanto segue:

   • NODE_NAME: il nodo su cui è in esecuzione il pod kube-etcd-0.

   • ADMIN_CLUSTER_KUBECONFIG: il file kubeconfig del cluster di amministrazione.

   • USER_CLUSTER_NAME: il nome del cluster di utenti.

   • GKE_ON_PREM_VERSION: la versione del cluster dove vuoi eseguire il ripristino di etcd (ad esempio 1.5.0-gke.0).

   • KUBE_ETCD_SECRET_NAME: il nome del segreto utilizzato da etcd nel cluster utente, che inizia con 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. Esegui il deployment del pod di utilità:

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

4. Copia snapshot.db dalla directory corrente alla directory principale del pod di utilità:

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

5. Apri una shell nel contenitore etcd-utility:

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

6. Nella shell, nella directory principale, esegui il seguente comando per creare una nuova cartella contenente il 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. Nella shell, elimina i vecchi dati etcd:

   rm -r var/lib/etcd/*
   

8. Nella shell, copia i dati etcd ripristinati nella posizione permanente:

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

9. Nella shell, inserisci exit per uscire dalla shell.

10. Elimina il pod etcd in crash:

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

11. Verifica che il pod etcd non abbia più arresti anomali.

12. Elimina il pod di utilità:

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

13. Rimuovi etcd-utility.yaml dalla directory corrente:

    rm etcd-utility.yaml
    

Control plane V2

Puoi ripristinare i dati di etcd uno alla volta implementando un contenitore etcd temporaneo che sovrascriva i dati danneggiati con il backup.

1. Ottieni una shell nel nodo del piano di controllo utente:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

2. Nella shell, arresta il server API Kubernetes e il server etcd:

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

3. Nella shell, inserisci exit per uscire dalla shell.

4. Esegui scp per copiare il file di backup snapshot.db e i secret nel nodo del piano di controllo dell'utente:

   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. Nella shell, utilizza snapshot.db per ripristinare i dati 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
   

   dove:

   • GKE_ON_PREM_VERSION è la versione di GKE Enterprise utilizzata come tag immagine
   • NODE_NAME è il nome del nodo in cui viene eseguito il ripristino
   • NODE_IP_ADDRESS è l'IP del nodo in questione

6. Aggiungi il flag - --initial-cluster-state=new nel file manifest di etcd nel comando del contenitore.

   Esempio:

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

7. Nella shell, avvia i server kube-apiserver ed etcd:

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

8. Nella shell, inserisci exit per uscire dalla shell.

Nota: se i pod events-etcd sono nello stato CrashLoopBackOff, aggiungi il flag - --initial-cluster-state=new e riavvia i pod. Gli eventi non saranno sincronizzati e perderai quelli memorizzati in precedenza.

Ripristino di un cluster utente da un backup (HA)

Kubeception

Questa sezione mostra come ripristinare i dati etcd per un cluster utente ad alta disponibilità (HA).

Per un cluster utente ad alta disponibilità, nel cluster di amministrazione sono presenti tre nodi che fungono da control plane per il cluster utente. Ciascuno di questi nodi esegue un pod etcd che mantiene i dati etcd su un volume di archiviazione.

Se due dei pod etcd sono operativi e i dati sui volumi di archiviazione associati sono intatti, non è necessario utilizzare un file di backup. Questo accade perché hai ancora un quorum etcd.

Nel raro caso in cui due dei volumi di archiviazione etcd presentino dati corrotti, devi utilizzare un file di backup per ripristinare i dati etcd.

Per eseguire i passaggi descritti in questa sezione, devi aver già creato un file snapshot.db come descritto in Eseguire il backup di un cluster utente.

Elenco dei pod e dei nodi etcd

1. Elenca i pod etcd che gestiscono lo store etcd per il tuo cluster utente. Questi pod vengono eseguiti nel cluster di amministrazione:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --namespace USER_CLUSTER_NAME \
   --output wide | grep kube-etcd
   

   L'output mostra i pod etcd e i nodi su cui vengono eseguiti. I nodi mostrati nell'output sono i nodi del cluster di amministrazione che fungono da control plane per il cluster utente:

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

2. Prendi nota dei nomi dei pod e dei nodi del piano di controllo per riferimento futuro.

   Tieni presente che ogni pod etcd è denominato kube-etcd con un numero aggiunto. Questo numero è chiamato numero membro del pod. Identifica il pod come un determinato membro del cluster etcd che contiene i dati dell'oggetto per il cluster utente. Questa guida utilizza il segnaposto MEMBER_NUMBER per fare riferimento al numero di membri del pod etcd.

   Inoltre, tieni presente che ogni pod nel cluster etcd viene eseguito su un proprio nodo.

Preparazione al deployment dei pod di utilità

1. Salva un manifest per PodDisruptionBudget (PDB) per il server API Kubernetes del cluster utente. Dopodiché elimina il file 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. Interrompi il server API Kubernetes e il deployment di manutenzione di etcd. In questo modo, viene garantito che nessun componente utilizzi etcd durante il ripristino:

   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. Ricorda il nome dell'immagine del contenitore per i pod etcd.

Esegui il deployment dei pod di utilità

Importante: esegui i passaggi descritti in questa sezione per ogni pod etcd.

1. Ricorda il nome del pod etcd e il nome del nodo in cui viene eseguito il pod.

2. Salva il seguente manifest del pod nella directory corrente in un file denominato 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

Il manifest precedente descrive un pod di utilità che viene eseguito temporaneamente per ripristinare i dati etcd.

1. Crea il pod di utilità nel cluster di amministrazione:

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

2. Copia il file di backup snapshot.db nella directory principale del tuo pod di utilità:

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

3. Apri una shell nel container etcd-utility nel pod di utilità:

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

4. Nella shell, nella directory principale, utilizza snapshot.db per ripristinare i dati di 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
   

   Il comando precedente ha memorizzato i dati etcd nella directory /kube-etcd-MEMBER_NUMBER.etcd.

5. Nella shell, elimina i vecchi dati etcd:

   rm -r var/lib/etcd/*
   

6. Nella shell, copia i dati etcd ripristinati nella posizione permanente:

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

7. Nella shell, rimuovi la directory etcd temporanea e il file di backup:

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

8. Nella shell, inserisci exit per uscire dalla shell.

9. Elimina il pod di utilità:

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

Riavviare i componenti

Ora che hai eseguito il deployment ed eliminato i pod di utilità, devi riavviare alcuni componenti del cluster.

1. Riavvia i pod nell'oggetto StatefulSet kube-etcd:

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

2. Avvia i server API Kubernetes per il tuo cluster utente:

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

3. Avvia il deployment della manutenzione di etcd per il cluster di utenti:

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

4. Ripristina il PDB per il server API Kubernetes:

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

Control plane V2

Questa sezione mostra come ripristinare i dati etcd per un cluster utente ad alta disponibilità (HA).

Per un cluster utente ad alta disponibilità, sono presenti tre nodi nel cluster utente che fungono da control plane per il cluster utente. Ciascuno di questi nodi esegue un pod etcd che mantiene i dati etcd su un volume di archiviazione.

Se due dei pod etcd sono operativi e i dati sui volumi di archiviazione associati sono intatti, non è necessario utilizzare un file di backup. Questo accade perché avresti comunque un quorum etcd.

Nel raro caso in cui due dei volumi di archiviazione etcd presentino dati corrotti, devi utilizzare un file di backup per ripristinare i dati etcd.

Per eseguire i passaggi descritti in questa sezione, devi aver già creato un file snapshot.db come descritto in Eseguire il backup di un cluster utente.

Elenco dei pod e dei nodi etcd

Importante: segui i passaggi descritti nelle sezioni seguenti per ciascuno dei nodi CP del cluster di utenti.

1. Elenca i pod etcd e il relativo nodo:

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

   L'output mostra i pod etcd e i nodi su cui vengono eseguiti. I nodi mostrati nell'output sono i nodi del cluster di amministrazione che fungono da control plane per il cluster utente:

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

2. Prendi nota dei nomi dei pod e dei nodi del piano di controllo per riferimento futuro.

   Tieni presente che a ogni pod etcd viene assegnato il nome etcd-xxx a cui viene aggiunto il nome di un nodo. Questo perché in Controlplane V2 i pod etcd vengono eseguiti come pod statici.

Preparazione al ripristino

1. Esegui scp per copiare il file di backup snapshot.db in tutti i nodi del control plane dell'utente:

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

2. Copia i secret nel rispettivo nodo del control plane dell'utente:

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

3. Ottieni una shell nel nodo del piano di controllo utente:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

Eseguire il ripristino

1. Ricorda il nome del pod etcd e il nome del nodo in cui viene eseguito il pod.

2. Nella shell, interrompi il server API Kubernetes e il server etcd su tutti i nodi del piano di controllo utente:

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

3. Nella shell, utilizza snapshot.db per ripristinare i dati etcd su tutti i nodi del piano di controllo utente:

   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
   

   dove:

   • GKE_ON_PREM_VERSION è la versione di GKE Enterprise utilizzata come tag immagine
   • NODE_NAME è il nome del nodo in cui viene eseguito il ripristino
   • NODE_IP_ADDRESS è l'IP del nodo in questione
   • Compila NODE1, NODE2, NODE3 e IP del rispettivo nodo per il flag --initial-cluster. Puoi anche recuperarlo dal manifest etcd.

4. Aggiungi il flag - --initial-cluster-state=existing nel file manifest di etcd nel comando del contenitore.

   Esempio:

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

Riavviare i componenti

1. Nella shell, avvia i server kube-apiserver e etcd in tutti i nodi del piano di controllo utente:

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

2. Nella shell, inserisci exit per uscire dalla shell.

3. Verifica che kube-apiserver e etcd siano in esecuzione su tutti i nodi del control plane dell'utente:

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

Nota: se i pod events-etcd sono nello stato CrashLoopBackOff, aggiungi il flag - --initial-cluster-state=new e riavvia i pod. Gli eventi non saranno sincronizzati e perderai quelli memorizzati in precedenza.

Backup automatico del cluster

Puoi utilizzare lo script fornito qui come esempio di come eseguire automaticamente il backup dei cluster. Tieni presente che lo script seguente non è supportato e deve essere utilizzato solo come riferimento per scrivere uno script migliore, più solido e completo. Prima di eseguire lo script, inserisci i valori per le cinque variabili all'inizio dello script:

Kubeception

• Imposta BACKUP_DIR sul percorso in cui vuoi archiviare i backup del cluster di amministrazione e utente. Questo percorso non dovrebbe esistere.
• Imposta ADMIN_CLUSTER_KUBECONFIG sul percorso del file kubeconfig del cluster di amministrazione
• Imposta USER_CLUSTER_NAMESPACE sul nome del cluster utente. Il nome del tuo cluster utente è uno spazio dei nomi nel cluster di amministrazione.
• Imposta EXTERNAL_IP sul VIP che hai riservato per il servizio del piano di controllo amministrativo.
• Imposta SSH_PRIVATE_KEY sul percorso della chiave SSH.
• Se utilizzi una rete privata, imposta JUMP_IP sull'indirizzo IP del jump server della tua rete.

#!/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

Control plane V2

• Imposta BACKUP_DIR sul percorso in cui vuoi archiviare i backup del cluster di amministrazione e utente. Questo percorso non dovrebbe esistere.
• Imposta ADMIN_CLUSTER_KUBECONFIG sul percorso del file kubeconfig del cluster di amministrazione
• Imposta USER_CLUSTER_KUBECONFIG sul percorso del file kubeconfig del cluster utente.
• Imposta EXTERNAL_IP sul VIP che hai riservato per il servizio del piano di controllo amministrativo.
• Imposta SSH_PRIVATE_KEY sul percorso della chiave SSH.
• Se utilizzi una rete privata, imposta JUMP_IP sull'indirizzo IP del jump server della tua rete.

#!/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

Verificare il ripristino

Per verificare che il cluster sia stato ripristinato correttamente, esegui gkectl diagnose cluster.

Passaggi successivi

• Eseguire il backup e il ripristino di un cluster di amministrazione
• Diagnostica dei problemi relativi ai cluster
• Scopri di più su augur, uno strumento open source per il ripristino di singoli oggetti dai backup di etcd.