Backup e ripristino dell'infrastruttura di cluster di gestione e del carico di lavoro in vSphere (anteprima tecnica)

Questo argomento spiega come eseguire il backup e il ripristino dell'infrastruttura del cluster per Tanzu Kubernetes Grid (TKG) con un cluster di gestione autonomo in vSphere:

Utilizzando Velero per eseguire il backup e il ripristino degli oggetti del cluster del carico di lavoro nel cluster di gestione autonomo e
Ricreando il cluster di gestione autonomo dai relativi file di configurazione

Nota

VMware non supporta l'utilizzo di Velero per eseguire il backup dei cluster di gestione autonomi TKG.

Se un cluster di gestione autonomo viene riconfigurato dopo la distribuzione, è possibile che la ricreazione di tale cluster descritta qui non ripristini tutte le risorse del cluster.

Per eseguire il backup e il ripristino dei carichi di lavoro e dei volumi di storage dinamici ospitati nei cluster del carico di lavoro di Tanzu Kubernetes Grid (TKG) con un cluster di gestione autonomo, vedere Backup e ripristino dei cluster del carico di lavoro.

Per eseguire il backup e il ripristino dei cluster vSphere with Tanzu, inclusi i cluster supervisore e i cluster del carico di lavoro che creano, vedere Backup e ripristino di vSphere with Tanzu nella documentazione di VMware vSphere 8.0.

Attenzione

Lo stato di questa funzionalità è Anteprima tecnica e non è quindi supportata. Vedere Stati delle funzionalità di TKG.

L'autenticazione Pinniped nei cluster del carico di lavoro non funziona dopo la ricreazione del cluster di gestione.

Configurazione di Velero

È possibile utilizzare Velero, uno strumento open source standard della community, per eseguire il backup e il ripristino dell'infrastruttura e dei carichi di lavoro del cluster di gestione autonoma TKG.

Velero supporta una serie di provider di storage per l'archiviazione dei suoi backup. Velero supporta anche:

Pre e post-hook per il backup e il ripristino per eseguire processi personalizzati prima o dopo gli eventi di backup e ripristino.
L'esclusione di aspetti dello stato del carico di lavoro o del cluster che non sono adatti al backup/ripristino.

Una sottoscrizione di Tanzu Kubernetes Grid include il supporto per la distribuzione di Velero testata da VMware e compatibile disponibile nella pagina di download di Tanzu Kubernetes Grid.

Per eseguire il backup e il ripristino dei cluster TKG, è necessario:

La CLI di Velero v1.9.7 in esecuzione nella workstation locale. Vedere Installazione della CLI di Velero.
Un provider di storage con posizioni in cui salvare i backup. Vedere Configurazione di un provider di storage.
Un server Velero in esecuzione nei cluster di cui si sta eseguendo il backup:
- Velero in un cluster del carico di lavoro esegue il backup dei carichi di lavoro e dello storage dinamico, come descritto di seguito.
- Velero in un cluster di gestione autonomo esegue il backup degli oggetti del cluster del carico di lavoro, come descritto in Backup e ripristino dell'infrastruttura di cluster di gestione e del carico di lavoro.

Dopo aver completato i prerequisiti precedenti, è possibile utilizzare Velero anche per eseguire la migrazione dei carichi di lavoro tra cluster. Per istruzioni, vedere Migrazione del cluster e Filtro delle risorse nella documentazione di Velero.

Installazione della CLI di Velero

Attenzione
Se è già stata installata la CLI di Velero v1.8.1 o versioni precedenti distribuita con le versioni precedenti di TKG, è necessario eseguire l'aggiornamento a v1.9.7. Le versioni precedenti di Velero non funzionano con le CRD utilizzate in v1.9 e versioni successive.

Per installare la CLI di Velero v1.9.7, eseguire i passaggi seguenti:

Passare alla pagina di download di Tanzu Kubernetes Grid e accedere con le credenziali di VMware Customer Connect.
In Download prodotti (Product Downloads) fare clic su Vai ai download (Go to Downloads).
Scorrere fino alle voci di Velero e scaricare il file .gz della CLI di Velero per il sistema operativo della workstation. Il nome del file inizia con velero-linux-, velero-mac- o velero-windows64-.
Utilizzare il comando gunzip o lo strumento di estrazione desiderato per decomprimere il file binario:
```
gzip -d <RELEASE-TARBALL-NAME>.gz
```
Rinominare il file binario della CLI per la piattaforma con velero, assicurarsi che sia eseguibile e aggiungerlo in PATH.
- Piattaforme macOS e Linux:
  1. Spostare il file binario nella cartella /usr/local/bin e rinominarlo con velero.
  2. Rendere eseguibile il file:
```
chmod +x /usr/local/bin/velero
```
- Piattaforme Windows:
  1. Creare una nuova cartella Program Files\velero e copiare il file binario in tale cartella.
  2. Rinominare il file binario con velero.exe.
  3. Fare clic con il pulsante destro del mouse sulla cartella velero, selezionare Proprietà > Sicurezza e assicurarsi che l'account utente disponga dell'autorizzazione Controllo completo.
  4. Utilizzare Windows Search per cercare env.
  5. Selezionare Modifica le variabili di ambiente relative al sistema e fare clic sul pulsante Variabili di ambiente.
  6. Selezionare la riga Path sotto Variabili di sistema e fare clic su Modifica.
  7. Fare clic su Nuovo per aggiungere una nuova riga e immettere il percorso del file binario velero.

Configurazione di un provider di storage

Per eseguire il backup dei contenuti del cluster del carico di lavoro Tanzu Kubernetes Grid, sono necessarie le posizioni di storage per:

Backup dello storage dell'oggetto cluster per i metadati di Kubernetes nei cluster
Snapshot dei volumi per i dati utilizzati dai cluster

Vedere Posizioni di storage di backup e posizioni degli snapshot dei volumi nella documentazione di Velero. Velero supporta una serie di provider di storage, che possono essere:

Un provider di storage cloud online.
Un servizio di storage di oggetti locale come MinIO per gli ambienti con proxy o air gap.

VMware consiglia di dedicare un bucket di storage univoco a ogni cluster.

Per configurare MinIO:

Eseguire l'immagine del container minio con le credenziali di MinIO e una posizione di storage, ad esempio:

$ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7

Salvare le credenziali in un file locale da passare all'opzione --secret-file di velero install ad esempio:
```
[default]
aws_access_key_id=minio
aws_secret_access_key=minio123
```

Storage per vSphere

In vSphere, i backup di storage dell'oggetto cluster e gli snapshot dei volumi vengono salvati nella stessa posizione di storage. Questa posizione deve essere uno storage esterno compatibile con S3 in Amazon Web Services (AWS) o un provider S3 come MinIO.

Per configurare lo storage per Velero in vSphere, vedere Plug-in Velero per vSphere in Vanilla Kubernetes Cluster per il plug-in v1.4.3.

Storage per e in AWS

Per configurare lo storage per Velero in AWS, eseguire le procedure nel repository dei plug-in Velero per AWS:

Configurare lo storage S3 in base alle esigenze per ogni plug-in. Il plug-in dell'archivio di oggetti archivia e recupera i backup dell'oggetto cluster, mentre lo strumento di creazione di snapshot del volume archivia e recupera i volumi di dati.

Storage per e in Azure

Per configurare lo storage per Velero in Azure, eseguire le procedure nel repository dei plug-in Velero per Azure:

Distribuzione del server Velero nel cluster di gestione

Per eseguire il backup degli oggetti del cluster del carico di lavoro, installare il server Velero v1.9.7 nel cluster di gestione autonomo e verificare le installazioni.

Opzioni di installazione di Velero

Per installare Velero, eseguire velero install con le seguenti opzioni:

--provider $PROVIDER: Ad esempio, aws
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1
--bucket $BUCKET: Nome del bucket S3
--backup-location-config region=$REGION: Regione AWS in cui si trova il bucket
--snapshot-location-config region=$REGION: Regione AWS in cui si trova il bucket
(Facoltativo) --kubeconfig per installare il server Velero in un cluster diverso da quello predefinito corrente.
(Facoltativo) --secret-file ./VELERO-CREDS: un modo per consentire a Velero di accedere a un bucket S3 consiste nel passare a questa opzione un file VELERO-CREDS locale con aspetto simile al seguente:
```
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
```
Per ulteriori opzioni, vedere Installazione e avvio di Velero.

Quando si esegue il comando velero install, viene creato nel cluster uno spazio dei nomi denominato velero in cui viene posizionata una distribuzione denominata velero.

Sono necessarie le seguenti impostazioni generali:

Plug-in del cluster di gestione: È necessario il plug-in seguente. L'opzione sospende i cluster e raccoglie le risorse relative ai cluster di cui viene eseguito il backup.

--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1

Nota
È possibile aggiungere più opzioni separate da una virgola. Ad esempio:
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1

Nessuna posizione dello snapshot Per il backup dell'infrastruttura del cluster, non impostare --snapshot-location-config

Verifica dell'installazione di Velero

Quando l'esecuzione del comando velero install viene completata, verificare che Velero sia stato installato correttamente:

Verificare che lo stato del pod Velero sia Running:

kubectl -n velero get pod
NAME                      READY   STATUS    RESTARTS   AGE
velero-78fdbcd446-v5cqr   1/1     Running   0          3h41m

Verificare che la posizione del backup sia nella fase Available:

velero backup-location get
NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
default   aws        mgmt            Available   2022-11-11 05:55:55 +0000 UTC   ReadWrite     true

Backup degli oggetti del cluster del carico di lavoro

Per eseguire il backup di tutti gli oggetti del cluster del carico di lavoro gestiti da un cluster di gestione autonomo, eseguire:

velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait

Nota

--exclude-namespaces tkg-system esclude il cluster di gestione stesso.

--include-resources cluster.cluster.x-k8s.io include gli oggetti del cluster del carico di lavoro

VMware consiglia di eseguire il backup dei cluster del carico di lavoro immediatamente dopo aver apportato modifiche strutturali, come la scalabilità verticale o orizzontale. In questo modo si evita la mancata corrispondenza tra gli oggetti di backup e l'infrastruttura fisica che può impedire la corretta esecuzione del processo di ripristino.

Pianificazione dei backup

Quando gli oggetti del cluster vengono modificati dopo il backup più recente, lo stato del sistema dopo il ripristino non corrisponde allo stato desiderato più recente. Questo problema viene denominato "deviazione". Per informazioni su come eseguire il ripristino da alcuni tipi di deviazione comuni, vedere la sezione Gestione delle deviazioni di seguito.

Per ridurre le deviazioni, VMware consiglia di utilizzare Velero per pianificare backup regolari. Ad esempio, per eseguire il backup di tutti i cluster del carico di lavoro ogni giorno e conservare ogni backup per 14 giorni:

velero create schedule daily-bak --schedule="@every 24h"  --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s

Per ulteriori opzioni di pianificazione di Velero, vedere Pianificazione di un backup nella documentazione di Velero.

Completamento del ripristino

Per ripristinare un cluster di gestione autonomo e gli oggetti del cluster del carico di lavoro che gestisce:

Ricreare il cluster di gestione tramite il file di configurazione, mgmt-cluster-config.yaml in questo caso, come indicato in Distribuzione di cluster di gestione da un file di configurazione.

Nota
Tutte le modifiche della configurazione applicate al cluster di gestione dopo la distribuzione devono essere riportate nel file di configurazione o nelle variabili di ambiente. In caso contrario, non verranno ripristinate.

Immediatamente dopo la creazione del cluster di gestione, deve essere presente un solo TKR:

tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.25.7---vmware.1-tkg.1  v1.25.7+vmware.1-tkg.1  True        True

Attendere alcuni minuti finché tutti i TKR utilizzati dai cluster del carico di lavoro di cui è stato eseguito il backup non sono disponibili:

tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.23.17---vmware.2-tkg.2  v1.23.17+vmware.2-tkg.2  True        True
v1.24.11---vmware.1-tkg.1  v1.24.11+vmware.1-tkg.1  True        True
v1.25.7---vmware.1-tkg.1   v1.25.7+vmware.1-tkg.1 True        True

Installare Velero nel cluster di gestione, seguendo le istruzioni della sezione Distribuzione del server Velero nei cluster precedente. Assicurarsi che le impostazioni di configurazione relative alle credenziali e alla posizione del backup abbiano gli stessi valori specificati quando il backup è stato creato.

Dopo aver installato Velero, eseguire velero backup get finché i backup non sono sincronizzati e il comando elenca il backup che si desidera utilizzare:

velero backup get
NAME                 STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
my-backup            Completed   0        0          2022-12-07 17:10:42 +0000 UTC   24d       default            <none>

Eseguire velero restore create per ripristinare le risorse del cluster del carico di lavoro. VMware consiglia di utilizzare il backup più recente:

velero restore create my-restore --from-backup my-backup --wait

Al termine del ripristino, lo stato dei cluster è createdStalled:

tanzu cluster list
NAME                NAMESPACE  STATUS          CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    createdStalled  0/3           0/3      v1.25.7+vmware.1   <none>  prod  v1.25.7---vmware.1-tkg.1

Applicare patch agli oggetti del cluster per impostare la proprietà paused di tali oggetti su false. Questa operazione è necessaria perché gli oggetti del cluster vengono ricreati con stato paused nel nuovo cluster di gestione per impedire ai controller di tentare la riconciliazione:
- Per annullare la sospensione di un cluster dopo che è stato ripristinato, eseguire:
```
kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
```
- Per annullare la sospensione di tutti i cluster in più spazi dei nomi, eseguire lo script:
```
#!/bin/bash

for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system");
do
      clusters=$(kubectl -n $ns get cluster -o name)
      if [[ -n $clusters ]];then
              kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}'
      fi
done
```

Verificare che lo stato di tutti i cluster del carico di lavoro sia running, ad esempio:

tanzu cluster list
NAME                NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    running  3/3           3/3      v1.25.7+vmware.1  <none>  prod  v1.25.7---vmware.1-tkg.1

Per ogni cluster del carico di lavoro, eseguire tanzu cluster get CLUSTER-NAME per verificare che lo stato di tutti i componenti sia running, ad esempio:

tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  3/3           3/3      v1.25.7+vmware.1 <none>  v1.25.7---vmware.1-tkg.1

Details:

NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
/tkg-vc-antrea                                                True                     4h14m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5  True                     4h36m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn      True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt                         True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp                         True                     4h23m
│ └─Machine/tkg-vc-antrea-ch5hn-x7nmm                         True                     4h32m
└─Workers
  ├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn                True                     4h23m
  │ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9       True                     4h24m
  ├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh                True                     4h24m
  │ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667       True                     4h28m
  └─MachineDeployment/tkg-vc-antrea-md-2-brm2m                True                     4h21m
    └─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn       True                     4h23m

Quando tutti i cluster del carico di lavoro sono in esecuzione, è possibile gestire i cluster del carico di lavoro con la CLI di Tanzu.

Gestione delle deviazioni

I casi di deviazione possono essere complicati, ma alcuni modelli e tentativi di riduzione comuni includono:

Nodi worker obsoleti:
- Nodi aggiuntivi inutilizzati
- Può verificarsi se il numero di nodi worker è diminuito dopo il backup
- La riduzione della deviazione spesso non è necessaria. Dopo il ripristino, il controllo di integrità della macchina elimina gli oggetti obsoleti della macchina e vengono creati nuovi nodi per soddisfare il numero di macchine desiderato.

Infrastruttura ghost del nodo worker:

Infrastruttura del nodo non gestita superflua
Può verificarsi se il numero di nodi worker è aumentato dopo il backup

Riduzione della deviazione:

Recuperare il kubeconfig del cluster del carico di lavoro e impostarlo come contesto di kubectl.

Confrontare l'output dei comandi kubectl e tanzu seguenti:

# Get the actual worker nodes of the workload cluster
$ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node
NAME                                        STATUS   ROLES           AGE    VERSION
tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9   Ready    <none>          44m    v1.25.7+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.25.7+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.25.7+vmware.1

# Get the worker nodes managed by the TKG
$ tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  1/1           1/1      v1.25.7+vmware.1  <none>  v1.25.7---vmware.1-tkg.1-zshippable

  Details:

  NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
  /tkg-vc-antrea                                                True                     13m
  ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9  True                     13m
  ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx      True                     13m
  │ └─Machine/tkg-vc-antrea-wdsfx-2hkxp                         True                     13m
  └─Workers
    └─MachineDeployment/tkg-vc-antrea-md-0-p9vn5                True                     13m
      └─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt       True                     13m

Per ogni nodo worker indicato da kubectl che non dispone di un elenco Workers > Machine in tanzu cluster get:
1. Aumentare il numero di worker fino al valore previsto, ad esempio:
```
tanzu cluster scale ${cluster_name} --worker-machine-count 2
```
2. Utilizzare il kubeconfig del cluster per svuotare il nodo ghost. I carichi di lavoro del nodo vengono quindi spostati nei nodi gestiti da TKG:
```
kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
```
3. Rimuovere il nodo ghost dal cluster:
```
kubectl delete node ${node_name}
```
4. Accedere a vSphere oppure a un'altra infrastruttura e rimuovere manualmente la macchina virtuale.

Nodi obsoleti e infrastruttura ghost nel piano di controllo

Nodi inutilizzati e infrastruttura di nodi superflua per il piano di controllo
Può verificarsi se il nodo del piano di controllo è stato sostituito dopo il backup

Riduzione della deviazione:

Recuperare il kubeconfig del cluster del carico di lavoro e impostarlo come contesto di kubectl.

Confrontare l'output dei comandi kubectl e tanzu seguenti:

# Get the actual control plane nodes of the workload cluster
$ kubectl --context wc-admin@wc get node
NAME                             STATUS   ROLES           AGE    VERSION
wc-2cjn4-4xbf8                   Ready    control-plane   107s   v1.25.7+vmware.1
wc-2cjn4-4zljs                   Ready    control-plane   26h    v1.25.7+vmware.1
wc-2cjn4-59v95                   Ready    control-plane   26h    v1.25.7+vmware.1
wc-2cjn4-ncgxb                   Ready    control-plane   25h    v1.25.7+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w   Ready    <none>          26h    v1.25.7+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc   Ready    <none>          26h    v1.25.7+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv   Ready    <none>          26h    v1.25.7+vmware.1

# Get the control plane nodes managed by the TKG
$ tanzu cluster get wc
NAME  NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
wc    default    updating 4/3           3/3      v1.25.7+vmware.1 <none>  v1.25.7---vmware.1-tkg.1-zshippable

Details:

NAME                                               READY  SEVERITY  REASON  SINCE  MESSAGE
/wc                                                True                     24m
├─ClusterInfrastructure - VSphereCluster/wc-9nq7v  True                     26m
├─ControlPlane - KubeadmControlPlane/wc-2cjn4      True                     24m
│ ├─Machine/wc-2cjn4-4xbf8                         True                     24m
│ ├─Machine/wc-2cjn4-4zljs                         True                     26m
│ └─Machine/wc-2cjn4-59v95                         True                     26m
└─Workers
├─MachineDeployment/wc-md-0-nl928                True                     26m
│ └─Machine/wc-md-0-nl928-5df8b9bfbd-nww2w       True                     26m
├─MachineDeployment/wc-md-1-j4m55                True                     26m
│ └─Machine/wc-md-1-j4m55-589cfcd9d6-jxmvc       True                     26m
└─MachineDeployment/wc-md-2-sd4ww                True                     26m
  └─Machine/wc-md-2-sd4ww-7b7db5dcbb-crwdv       True                     26m

Per ogni nodo control-plane indicato da kubectl in cui non è presente un elenco ControlPlane > Machine in tanzu cluster get:
1. Eliminare il nodo:
```
kubectl delete node ${node_name}
```
2. Accedere a vSphere oppure a un'altra infrastruttura e rimuovere manualmente la macchina virtuale.