Backup e ripristino di cluster

Questa pagina descrive come creare e ripristinare manualmente i backup degli amministratori e dei cluster utente GKE On-Prem. In questa pagina viene fornito anche uno script che puoi utilizzare per eseguire automaticamente il backup dei tuoi cluster.

Dovresti creare dei backup per il ripristino in seguito a calamità previste che potrebbero danneggiare dati e secret di etcd. Assicurati di archiviare i backup in una posizione esterna al cluster e che non dipende dall'operazione del cluster. Se vuoi essere al sicuro, valuta anche la possibilità di creare una copia di backup.

Sebbene il pod eventi etcd eseguito in ogni cluster non sia fondamentale per il ripristino di un cluster utente, puoi seguire una procedura simile per eseguirne il backup.

Limitazioni

  • Il backup di dati specifici dell'applicazione non rientra nell'ambito di questa funzionalità.
  • I secret rimangono validi finché non li ruota manualmente.
  • I carichi di lavoro pianificati dopo aver creato un backup non vengono ripristinati con tale backup.
  • Al momento non puoi eseguire il ripristino da upgrade del cluster non riusciti.
  • Lo scopo di questa procedura non è ripristinare un cluster eliminato.

Problemi noti

Quando esegui i comandi sudo, potresti riscontrare il seguente errore:

sudo: unable to resolve host gke-admin-master-[CLUSTER_ID]

In questo caso, aggiungi la seguente riga al file /etc/hosts:

127.0.0.1 gke-admin-master-[CLUSTER_ID]

Backup dei cluster utente

Un backup del cluster utente contiene uno snapshot del cluster utente e così via. Un etcd di cluster contiene, tra le altre cose, tutti gli oggetti Kubernetes e tutti gli oggetti personalizzati necessari per gestire lo stato del cluster. Questo snapshot contiene i dati necessari per ricreare i componenti e i carichi di lavoro del cluster.

Backup di un cluster utente

Un etcd di un cluster utente è archiviato nel nodo del piano di controllo, a cui puoi accedere tramite il kubeconfig del cluster di amministrazione.

Per creare uno snapshot di etcd, esegui il comando seguente:

  1. Accedi al container kube-etcd:

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

    dove:

    • [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.
    • [USER_CLUSTER_NAME] è il nome del cluster utente. In particolare, stai passando a uno spazio dei nomi nel cluster di amministrazione che prende il nome dal cluster utente.
  2. Dalla shell, utilizza etcdctl per creare un backup denominato snapshot.db nella directory locale:

    ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cacert=/etcd.local.config/certificates/etcdCA.crt \
    --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key \
    snapshot save snapshot.db
  3. Esci dal contenitore:

    exit
  4. Copia il backup dal container kube-etcd utilizzando kubectl cp:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
    [USER_CLUSTER_NAME]/kube-etcd-0:snapshot.db [DIRECTORY] -c kube-etcd

    dove [RELATIVE_DIRECTORY] è un percorso in cui vuoi archiviare il tuo backup.

Ripristino di un backup del cluster utente

  • Prima di ripristinare un backup, assicurati di diagnosi del cluster e di risolvere i problemi esistenti. Il ripristino di un backup in un cluster problematico potrebbe ricreare o esacerbare i problemi. Contatta il team di assistenza GKE On-Prem per ulteriore assistenza sul ripristino dei cluster.

  • Se hai creato un cluster utente HA, devi eseguire questi passaggi una volta per ogni membro del cluster etcd. Puoi utilizzare lo stesso snapshot per ripristinare ogni membro etcd. Non seguire questi passaggi, a meno che tutti i pod etcd non siano arresti anomali: significa che c'è un danneggiamento dei dati.

Pod etcd di Crashlooping

Le istruzioni seguenti spiegano come ripristinare un backup nei casi in cui i dati etcd di un cluster utente siano danneggiati e che il relativo pod etcd si arresti in modo anomalo. Puoi recuperarlo eseguendo il deployment di un pod etcd nei volumi dei pod esistenti e sovrascrivendo i dati danneggiati con il backup, supponendo che il server API del cluster utente sia in esecuzione e possa pianificare nuovi pod.

  1. Copia la specifica pod pod etcd in un file restore-etcd.yaml dopo aver completato i seguenti valori segnaposto:

    • [MEMBER_NUMBER] è il pod numerato che stai ripristinando.
    • [NODE_NAME] è il nodo su cui è in esecuzione il pod [MEMBER_NUMBER[.
    • [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.
    • [USER_CLUSTER_NAME] è il nome del cluster utente.
    • [DEFAULT_TOKEN] viene utilizzato per l'autenticazione. Puoi trovare questo valore eseguendo questo comando:

      kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
      -n [USER_CLUSTER_NAME] get pods kube-etcd-0 \
      -o yaml | grep default-token

    ripristino-etcd.yaml

    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        Component: restore-etcd-[MEMBER_NUMBER]
      name: restore-etcd-0
      namespace: restore-etcd-[MEMBER_NUMBER]
    spec:
      restartPolicy: Never
      containers:
      - command: ["/bin/sh"]
        args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
        image: gcr.io/gke-on-prem-release/etcd:v3.2.24-1-gke.0
        imagePullPolicy: IfNotPresent
        name: restore-etcd
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/lib/etcd
          name: data
        - mountPath: /etcd.local.config/certificates
          name: etcd-certs
        - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
          name: [DEFAULT_TOKEN]
          readOnly: true
      dnsPolicy: ClusterFirst
      hostname: restore-etcd-0
      imagePullSecrets:
      - name: private-registry-creds
      nodeSelector:
        kubernetes.googleapis.com/cluster-name: [USER_CLUSTER_NAME]
        kubernetes.io.hostname: [NODE_NAME]
      priority: 0
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: default
      serviceAccountName: default
      subdomain: restore-etcd
      terminationGracePeriodSeconds: 30
      tolerations:
      - effect: NoExecute
        key: node.kubernetes.io/not-ready
        operator: Exists
        tolerationSeconds: 300
      - effect: NoExecute
        key: node.kubernetes.io/unreachable
        operator: Exists
        tolerationSeconds: 300
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: data-kube-etcd-[MEMBER_NUMBER]
      - name: etcd-certs
        secret:
          defaultMode: 420
          secretName: kube-etcd-certs
      - name: [DEFAULT_TOKEN]
        secret:
          defaultMode: 420
          secretName: [DEFAULT_TOKEN]
          
  2. Esegui il deployment del pod:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    -n [USER_CLUSTER_NAME] create -f restore-etcd.yaml
  3. Copia il file di backup etcd's, snapshot.db nel nuovo pod. snapshot.db si trova nella directory relativa in cui hai creato il backup:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    cp [RELATIVE_DIRECTORY]/snapshot.db \
    [USER_CLUSTER_NAME]/restore-etcd-0:snapshot.db
  4. Shell nel pod restore-etcd:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    -it -n [USER_CLUSTER_NAME] exec restore-etcd-0 -- bin/sh
  5. Esegui il comando seguente per creare una nuova cartella default.etcd 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
  6. Sovrascrivi i dati etcd danneggiati con il backup:

    rm -r var/lib/etcd/*; cp -r default.etcd/* var/lib/etcd/
  7. Esci dal contenitore:

    exit
  8. Elimina il pod etcd con arresto anomalo:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    -n [USER_CLUSTER_NAME] delete pod kube-etcd-0
  9. Verifica che il pod etcd non si stia più arrestando in modo anomalo.

  10. Rimuovi restore-etcd.yaml ed elimina il pod restore-etcd:

    rm restore-etcd.yaml;
    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    -n [USER_CLUSTER_NAME] delete pod restore-etcd-0

Backup dei cluster di amministrazione

Un backup del cluster di amministrazione contiene quanto segue:

  • Un'istantanea del cluster di amministrazione e così via.
  • I secret del piano di controllo dell'amministratore, necessari per l'autenticazione nei cluster di amministrazione e degli utenti.

Completa i seguenti passaggi prima di creare un backup del cluster di amministrazione:

  1. Individua l'indirizzo IP esterno del cluster di amministrazione, utilizzato per accedere tramite SSH al piano di controllo del cluster di amministrazione:

    kubectl --kubeconfig [ADMIN_KUBECONFIG] get nodes -n kube-system -o wide | grep gke-admin-master

    dove [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.

  2. Crea una chiave SSH denominata vsphere_tmp dalla chiave privata del cluster di amministrazione.

    Puoi trovare la chiave privata nei Secret dei cluster di amministrazione:

    kubectl --kubeconfig [ADMIN_KUBECONFIG] get secrets sshkeys -n kube-system -o yaml

    Nell'output dei comandi, puoi trovare la chiave privata nel campo vsphere_tmp.

    Copia la chiave privata in vsphere_tmp:

    echo "[PRIVATE_KEY]" | base64 -d > vsphere_tmp; chmod 600 vsphere_tmp
  3. Verifica di poter utilizzare il shell nel piano di controllo amministrativo utilizzando questa chiave privata:

    ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
    
  4. Esci dal contenitore:

    exit

Backup di un cluster di amministrazione

Puoi eseguire il backup di secret ecc. di un cluster di amministrazione e dei relativi Secret del piano di controllo.

etcd

Per eseguire il backup di etcd del cluster di amministrazione:

  1. Ottieni il nome del pod etcd:

    kubectl --kubeconfig [ADMIN_KUBECONFIG] get pods \
    -n kube-system | grep etcd-gke-admin-master
  2. Accedi al container kube-etcd del pod:

    kubectl --kubeconfig [ADMIN_KUBECONFIG]  exec -it \
    -n kube-system [ADMIN_ETCD_POD] -- bin/sh

    dove [ADMIN_ETCD_POD] è il nome del pod etcd.

  3. Dalla shell, utilizza etcdctl per creare un backup denominato snapshot.db nella directory locale:

    ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
    --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save snapshot.db
  4. Esci dal contenitore:

    exit
  5. Copia il backup dal container kube-etcd utilizzando kubectl cp:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
    kube-system/[ADMIN_ETCD_POD]:snapshot.db [RELATIVE_DIRECTORY]
    

    dove [RELATIVE_DIRECTORY] è un percorso in cui vuoi archiviare il tuo backup.

Secret

Per eseguire il backup dei secret del piano di controllo dell'amministratore:

  1. Shell nel nodo del piano di controllo dell'amministratore:

    ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
    

    dove [EXTERNAL_IP] è l'indirizzo IP esterno del piano di controllo dell'amministratore, che hai raccolto in precedenza.

  2. Crea una directory di backup locale. Questa operazione è facoltativa, ma fortemente consigliata. Devi cambiare le autorizzazioni del backup Secret' per copiarle dal nodo:

    mkdir backup
  3. Copia localmente i Secret nella directory di backup locale:

    sudo cp -r /etc/kubernetes/pki/* backup/
  4. Modifica le autorizzazioni dei Secret di backup:

    sudo chmod -R +rw backup/
  5. Esci dal contenitore:

    exit
  6. Esegui scp per copiare la cartella di backup dal nodo del piano di controllo dell'amministratore:

    sudo scp -r -i vsphere_tmp  ubuntu@[EXTERNAL_IP]:backup/ [RELATIVE_DIRECTORY]
    

    dove [RELATIVE_DIRECTORY] è un percorso in cui vuoi archiviare il tuo backup.

Ripristino di un cluster di amministrazione

La procedura seguente ricrea un cluster di amministrazione di cui è stato eseguito il backup e tutti i piani di controllo utente che ha gestito al momento della creazione dello snapshot etcd.

  1. Esegui scp per copiare snapshot.db nel piano di controllo dell'amministratore:

    sudo scp -i vsphere_tmp snapshot.db ubuntu@[EXTERNAL_IP]:

    dove [EXTERNAL_IP] è l'indirizzo IP esterno del piano di controllo dell'amministratore, che hai raccolto in precedenza.

  2. Accedi al piano di controllo dell'amministratore:

    sudo ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
    
  3. Copia snapshot.db/ in /mnt:

    sudo cp snapshot.db /mnt/
  4. Crea una directory temporanea, ad esempio backup:

    mkdir backup
  5. Esci dal piano di controllo dell'amministratore:

    exit
  6. Copia i certificati in backup/:

    sudo scp -r -i vsphere_tmp [BACKUP_CERT_FILE] ubuntu@[EXTERNAL_IP]:backup/
  7. Shell nel nodo del piano di controllo dell'amministratore:

    ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
    

    dove [EXTERNAL_IP] è l'indirizzo IP esterno del piano di controllo dell'amministratore, che hai raccolto in precedenza.

  8. Esegui kubeadm reset. In questo modo arresta tutto ciò che è ancora in esecuzione nel cluster di amministrazione, elimina tutti i dati etcd e i Secret in /etc/kubernetes/pki/:

    sudo kubeadm reset --ignore-preflight-errors=all
  9. Copia i Secret di backup in /etc/kubernetes/pki/:

    sudo cp -r backup/* /etc/kubernetes/pki/
  10. Esegui etcdctl restore con Docker:

    sudo docker run --rm \
    -v '/mnt:/backup' \
    -v '/var/lib/etcd:/var/lib/etcd' --env ETCDCTL_API=3 'k8s.gcr.io/etcd-amd64:3.1.12' /bin/sh -c "etcdctl snapshot restore '/backup/snapshot.db'; mv /default.etcd/member/ /var/lib/etcd/"
  11. Esegui kubeadm init. In questo modo vengono riutilizzati tutti i Secret di backup, riavviati etcd con lo snapshot ripristinato:

    sudo kubeadm init --config /etc/kubernetes/kubeadm_config.yaml --ignore-preflight-errors=DirAvailable--var-lib-etcd
  12. Esci dal piano di controllo dell'amministratore:

    exit
  13. Copia il file kubeconfig appena generato dal nodo amministratore:

    sudo scp -i vsphere_tmp ubuntu@[EXTERNAL_IP]:[HOME]/.kube/config kubeconfig

    dove:

    • [EXTERNAL_IP] è l'indirizzo IP esterno del piano di controllo dell'amministratore.
    • [HOME] è la home directory sul nodo amministratore.

    Ora puoi utilizzare questo nuovo file kubeconfig per accedere al cluster ripristinato.

Script di backup

Puoi utilizzare lo script fornito qui per eseguire automaticamente il backup dei tuoi cluster. Prima di eseguire lo script, inserisci i valori per le cinque variabili all'inizio dello script:

  • Imposta BACKUP_DIR sul percorso in cui vuoi archiviare i backup dell'amministratore e del cluster utente.
  • Imposta il percorso del file kubeconfig del cluster di amministrazione ADMIN_CLUSTER_KUBECONFIG
  • Imposta il nome del cluster utente come USER_CLUSTER_NAMESPACE. Il nome del cluster utente è uno spazio dei nomi nel cluster di amministrazione.
  • Imposta EXTERNAL_IP sul VIP prenotato per il servizio del piano di controllo dell'amministratore.
  • Imposta SSH_PRIVATE_KEY sul percorso della chiave SSH creata quando configuri la workstation di amministrazione.
  • Se utilizzi una rete privata, imposta JUMP_IP sull'indirizzo IP del jump server della 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/

# ADMIN CLUSTER BACKUP

# Set up ssh options
SSH_OPTS=(-oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY})
if [ "${JUMP_IP}" != "" ]; then
    SSH_OPTS+=(-oProxyCommand="ssh -oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY} -W %h:%p ubuntu@${JUMP_IP}")
fi

# Copy admin certs
ssh "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP}:/etc/kubernetes/pki/* ${BACKUP_DIR}/pki/

# Snapshot admin cluster etcd
admin_etcd=$(kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} get pods -n kube-system -o=name | grep etcd | cut -c 5-)
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG}  exec -it -n kube-system ${admin_etcd} -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key snapshot save admin_snapshot.db"

Risolvere i problemi

Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.

Diagnostica dei problemi del cluster con gkectl

Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividerli con Google. Consulta Diagnosi dei problemi del cluster.

Comportamento di logging predefinito

Per gkectl e gkeadm è sufficiente utilizzare le impostazioni di logging predefinite:

  • Per impostazione predefinita, le voci di log vengono salvate come segue:

    • Per gkectl, il file di log predefinito è /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e il file è collegato direttamente al file logs/gkectl-$(date).log nella directory locale in cui viene eseguito gkectl.
    • Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
  • Tutte le voci di log vengono salvate nel file di log, anche se non sono stampate nel terminale (quando --alsologtostderr è false).
  • Il livello di dettaglio -v5 (predefinito) copre tutte le voci di log necessarie al team di assistenza.
  • Il file di log contiene anche il comando eseguito e il messaggio di errore.

Se hai bisogno di aiuto, ti consigliamo di inviare il file di log al team di assistenza.

Specificare una posizione non predefinita per il file di log

Per specificare una posizione non predefinita per il file di log gkectl, utilizza il flag --log_file. Il file di log specificato non verrà collegato direttamente alla directory locale.

Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.

Localizzazione dei log dell'API Cluster nel cluster di amministrazione

Se l'avvio di una VM non riesce dopo l'avvio del piano di controllo dell'amministratore, puoi provare a eseguire il debug controllando i controller dell'API cluster nel log:

  1. Trova il nome del pod dei controller API del cluster nello spazio dei nomi kube-system, dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Apri i log del pod, dove [POD_NAME] è il nome del pod. Se preferisci, utilizza grep o uno strumento simile per cercare errori:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Passaggi successivi