Esegui il backup e ripristina un cluster utente

Questo documento mostra come eseguire il backup e il ripristino dell'archivio etcd per un cluster utente creato con Google Distributed Cloud (solo software) per VMware. Anche in questa pagina fornisce uno script che puoi utilizzare eseguire automaticamente il backup dell'archivio etcd di un cluster.

Puoi creare un file di backup per il ripristino da emergenze impreviste che potrebbero danneggiare i dati etcd del cluster. Archivia il file di backup in una posizione all'esterno del cluster e non dipende dal funzionamento del cluster.

Nota: per il backup di un utente viene utilizzato uno strumento di backup di terze parti, come Veeam non è supportato. Il backup del cluster con uno strumento di terze parti potrebbe a errori imprevisti nelle operazioni del cluster.

Limitazioni

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

• Questa procedura non esegue il backup degli oggetti PersistentVolume.

• I carichi di lavoro pianificati dopo la creazione di un backup non vengono ripristinati con questo 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. Me non consigliare il ripristino da un file di backup a meno che il cluster non sia completamente non funzionante. Contatta l'Assistenza Google per ricevere aiuto a decidere la linea d'azione migliore.

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

Backup di un cluster utente in corso...

Un backup del cluster utente è uno snapshot dell'archivio etcd del cluster utente. L'archivio etcd contiene tutti gli oggetti Kubernetes e gli oggetti personalizzati necessaria per gestire lo stato del cluster. Lo snapshot contiene necessari per ricreare i componenti e i carichi di lavoro del cluster.

I passaggi di backup che segui dipendono dall'abilitazione o meno del piano di controllo V2 sul cluster utente. Quando il piano di controllo V2 è abilitato, il piano di controllo per il cluster utente viene eseguito sul cluster utente stesso. Se il piano di controllo V2 abilitato, il piano di controllo per il cluster utente viene eseguito su uno o più nodi e il cluster di amministrazione, detto kubeception.

Esegui questo comando per determinare se il cluster dispone di Controlplane V2 attivato:

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

Se l'output è true, segui i passaggi per Controlplane V2 per eseguire il backup nel cluster. In caso contrario, segui i passaggi di Kubeception.

Kubeception

1. Recupera una shell nel container 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 è la configurazione kubeconfig del cluster di amministrazione .
   • USER_CLUSTER_NAME è il nome del cluster utente.

2. Nella shell, nella directory /tmp, crea un 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. Inserisci exit nella shell per uscire.

4. Copia /tmp/snapshot.db dal container kube-etcd nella directory attuale:

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

Control plane V2

1. Ottieni 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 campo 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 esserci più pod etcd, ad esempio tre per i cluster ad alta disponibilità. Per il backup, qualsiasi pod etcd dovrebbe funzionare.

2. Recupera una shell nel container 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 da al 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. Inserisci exit nella shell per uscire.

5. Copia snapshot.db dal container 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 piano di controllo utente da da cui vuoi che vengano copiati i secret.
   Nota: per i cluster ad alta disponibilità, copia i secret da tutti i nodi del piano di controllo utente utilizzando le istruzioni

Ripristino di un cluster utente da un backup (non ad alta disponibilità)

Prima di utilizzare un file di backup per ripristinare l'archivio etcd del cluster utente, diagnosticare il cluster e risolvere problemi esistenti. L'utilizzo di un backup per ripristinare un cluster problematico potrebbe ricreare o esacerbare i problemi. Contatta il team di assistenza Google Cloud per ulteriore assistenza per il ripristino dei cluster.

Le seguenti istruzioni spiegano come utilizzare un file di backup per ripristinare un utente nei casi in cui i dati etcd del cluster siano stati danneggiati il pod etcd del cluster utente ha un arresto anomalo in loop.

Kubeception

Puoi ripristinare i dati etcd eseguendo il deployment di un pod di utilità che sovrascrive danneggiati dai dati con la copia di backup. Il server API del cluster di amministrazione deve essere in esecuzione lo scheduler del cluster di amministrazione deve essere in grado di pianificare nuovi pod.

1. Trova il nome del secret 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 dei pod in un file denominato etcd-utility.yaml. Sostituisci le seguenti:

   • NODE_NAME: il nodo in cui si trova il pod kube-etcd-0 in esecuzione.

   • ADMIN_CLUSTER_KUBECONFIG: il nome del cluster di amministrazione kubeconfig.

   • USER_CLUSTER_NAME: il nome del cluster utente.

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

   • KUBE_ETCD_SECRET_NAME: il nome del secret utilizzato da etcd nel cluster utente, a partire da 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 dell'utility Pod:

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

4. Copia snapshot.db dalla directory corrente alla directory radice del utilità:

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

5. Recupera una shell nel container 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 root, esegui questo comando per creare nuova cartella che contiene 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 dati etcd precedenti:

   rm -r var/lib/etcd/*
   

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

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

9. Inserisci exit nella shell per uscire.

10. Elimina il pod etcd con arresto anomalo:

    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 dell'utilità:

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

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

    rm etcd-utility.yaml
    

Control plane V2

Puoi ripristinare i dati etcd uno alla volta eseguendo il deployment di un container etcd temporaneo che sovrascrive i dati danneggiati dai dati con la copia di 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. Inserisci exit nella shell per uscire.

4. Esegui scp per copiare il file di backup snapshot.db e secret per il nodo del piano di controllo 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 suddetto nodo

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

   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. Inserisci exit nella shell per uscire.

Nota: se i pod events-etcd sono in stato CrashLoopBackOff, aggiungi il flag - --initial-cluster-state=new e riavvia i pod. Gli eventi non saranno sincronizzati e perderai quelli archiviati 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à.

Per un cluster utente ad alta disponibilità, il cluster di amministrazione comprende tre nodi che di controllo dei piani per il cluster utente. Ciascuno di questi nodi esegue un pod etcd conserva i dati etcd su un volume di archiviazione.

Se due pod etcd sono integri, e i dati sullo spazio di archiviazione associato è intatto, quindi non è necessario utilizzare un file di backup. Questo perché hai ancora un quorum etcd.

Nel raro caso in cui due volumi di archiviazione etcd contengano dati danneggiati, utilizzare un file di backup per ripristinare i dati etcd.

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

Elenco dei pod e dei nodi etcd

1. Elenca i pod etcd che gestiscono l'archivio etcd per il tuo cluster utente. Questi I 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 in cui vengono eseguiti i pod. I nodi mostrati nell'output sono nodi nel cluster di amministrazione che fungono da piani di controllo. per il tuo 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 nomi dei nodi del piano di controllo per un secondo momento.

   Tieni presente che a ogni pod etcd è denominato kube-etcd e aggiunto un numero. Questo numero è chiamato numero membro del pod. Identifica Il pod è un membro particolare del cluster etcd che contiene l'oggetto per il tuo cluster utente. Questa guida utilizza il segnaposto MEMBER_NUMBER per fare riferimento al numero membro del pod etcd.

   Nota inoltre che ogni pod nel cluster etcd viene eseguito sul proprio nodo.

Preparazione del deployment dei pod dell'utilità

1. Salva un manifest per il PodDisruptionBudget (PDB) per il campo il server API Kubernetes. Quindi elimina il 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. Arresta il server API Kubernetes e il deployment di manutenzione etcd. Ciò garantisce che nessun componente utilizzerà 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 container per i pod etcd.

Deployment dei pod di utilità

Importante: esegui i passaggi in questa sezione per ciascuno dei tuoi pod etcd.

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

2. Salva il seguente manifest del pod nella directory attuale 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 esegui temporaneamente per ripristinare i dati etcd.

1. Crea il pod dell'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 utilità:

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

3. Recupera una shell nel container etcd-utility del 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 root, utilizza snapshot.db per ripristinare il file etcd dati:

   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 memorizzava i dati etcd nel Directory /kube-etcd-MEMBER_NUMBER.etcd.

5. Nella shell, elimina i dati etcd precedenti:

   rm -r var/lib/etcd/*
   

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

   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. Inserisci exit nella shell per uscire.

9. Elimina il pod dell'utilità:

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

Riavvio dei componenti

Dopo aver eseguito il deployment e aver eliminato i pod dell'utilità, devi riavviare componenti del cluster.

1. Riavvia i pod nello 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 di manutenzione etcd per il tuo cluster utente:

   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'alta disponibilità nel cluster utente.

Per un cluster utente ad alta disponibilità, il cluster utente contiene tre nodi che di controllo per il cluster utente. Ciascuno di questi nodi esegue un pod etcd conserva i dati etcd su un volume di archiviazione.

Se due pod etcd sono integri, e i dati sullo spazio di archiviazione associato è intatto, quindi non è necessario utilizzare un file di backup. Questo perché c'è ancora un quorum etcd.

Nel raro caso in cui due volumi di archiviazione etcd contengano dati danneggiati, utilizzare un file di backup per ripristinare i dati etcd.

Per eseguire i passaggi di questa sezione, devi aver già creato un snapshot.db come descritto in Backup di un cluster utente.

Elenco dei pod e dei nodi etcd

Importante: esegui i passaggi nelle sezioni seguenti per ciascuno dei nodi CP del cluster utente.

1. Elenca i pod etcd e i rispettivi nodi:

   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 in cui vengono eseguiti i pod. I nodi mostrati nell'output sono nodi nel cluster di amministrazione che fungono da piani di controllo. per il tuo cluster utente:

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

2. Prendi nota dei nomi dei pod e dei nomi dei nodi del piano di controllo per un secondo momento.

   Nota che a ogni pod etcd è denominato etcd-xxx e viene aggiunto un nome nodo. Questo perché in Controlplane V2 i pod etcd vengono eseguiti come pod statici.

Preparazione del ripristino in corso...

1. Esegui scp per copiare il file di backup snapshot.db in tutti i nodi del piano di controllo utente:

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

2. Copia i secret nel rispettivo nodo del piano di controllo 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
   

Esecuzione del ripristino

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

2. Nella shell, arresta 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 suddetto nodo
   • 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 etcd del comando container.

   Esempio:

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

Riavvio dei 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. Inserisci exit nella shell per uscire.

3. Verifica che kube-apiserver e etcd siano in esecuzione su tutti i nodi del piano di controllo utente:

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

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

Backup automatico del cluster

Puoi utilizzare lo script qui fornito come esempio su come eseguire automaticamente il backup dei cluster. Tieni presente che il seguente script non è supportato e deve essere utilizzato solo come riferimento per scrivere uno script migliore, più efficace 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 l'amministratore e l'utente backup del cluster. Questo percorso non deve esistere.
• Imposta ADMIN_CLUSTER_KUBECONFIG sul percorso kubeconfig del cluster di amministrazione file
• Imposta USER_CLUSTER_NAMESPACE sul nome del cluster utente. Il nome del il cluster utente è uno spazio dei nomi nel cluster di amministrazione.
• Imposta EXTERNAL_IP sul VIP che hai prenotato per il piano di controllo amministratore completamente gestito di Google Cloud.
• Imposta SSH_PRIVATE_KEY sul percorso Chiave SSH.
• Se stai utilizzando una rete privata, imposta JUMP_IP sul salto di rete all'indirizzo IP del server.

#!/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 l'amministratore e l'utente backup del cluster. Questo percorso non deve esistere.
• Imposta ADMIN_CLUSTER_KUBECONFIG sul percorso kubeconfig del cluster di amministrazione file
• Imposta USER_CLUSTER_KUBECONFIG sul percorso kubeconfig del cluster utente.
• Imposta EXTERNAL_IP sul VIP che hai prenotato per il piano di controllo amministratore completamente gestito di Google Cloud.
• Imposta SSH_PRIVATE_KEY sul percorso Chiave SSH.
• Se stai utilizzando una rete privata, imposta JUMP_IP sul salto di rete all'indirizzo IP del server.

#!/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 diagnostica cluster.

Passaggi successivi

• Effettuare il backup e il ripristino di un cluster di amministrazione
• Scopri come diagnosticare i problemi dei cluster
• Scopri di più su agosto, una strumento open source per ripristinare singoli oggetti dai backup etcd.