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

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:

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.9.x o versioni precedenti distribuita con le versioni precedenti di TKG, è necessario eseguire l'aggiornamento a v1.10.3. Le versioni precedenti di Velero non funzionano con le CRD utilizzate in v1.10 e versioni successive. Per informazioni, vedere Aggiornamento di Velero di seguito.

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

  1. Passare alla pagina di download di Tanzu Kubernetes Grid e accedere con le credenziali di VMware Customer Connect.
  2. In Download prodotti (Product Downloads) fare clic su Vai ai download (Go to Downloads).
  3. 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-.

  4. Utilizzare il comando gunzip o lo strumento di estrazione desiderato per decomprimere il file binario:

    gzip -d <RELEASE-TARBALL-NAME>.gz

  5. Rinominare il file binario della CLI per la piattaforma con velero, assicurarsi che sia eseguibile e aggiungerlo in PATH.

    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
    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.

Aggiornamento di Velero

Velero v1.10.3 utilizza CRD diversi per v1.9.x. Inoltre, Velero v1.10 ha adottato Kopia con Restic come programma di caricamento, che ha portato a diverse modifiche nella denominazione dei componenti e dei comandi e nel modo in cui Velero funziona. Per ulteriori informazioni sulle modifiche importanti tra v1.9.x e v1.10, vedere Modifiche importanti nel registro delle modifiche di Velero v1.10. Se è stato installato Velero v1.9.x con una versione precedente di TKG, è necessario aggiornare Velero.

  1. Eseguire la procedura descritta in Installazione della CLI di Velero per installare Velero v1.10.3.

  2. Aggiornare le definizioni CRD con il file binario di Velero v1.10.

    velero install --crds-only --dry-run -o yaml | kubectl apply -f -

  3. Aggiornare la distribuzione di Velero e la configurazione dei set di daemon in modo che corrisponda alla ridenominazione del componente avvenuta in Velero v1.10.

    Nel comando seguente, uploader_type può essere restic o kopia.

    kubectl get deploy -n velero -ojson \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \
| sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \
| sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \
| sed "s#restic-timeout#fs-backup-timeout#g" \
| kubectl apply -f -

  4. (Facoltativo) Se si utilizza il set di daemon restic, rinominare i componenti corrispondenti.

    echo $(kubectl get ds -n velero restic -ojson) \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \
| sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \
| kubectl apply -f -
kubectl delete ds -n velero restic --force --grace-period 0

Per ulteriori informazioni, vedere Aggiornamento a Velero 1.10 nella documentazione di 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:

  1. 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

  2. 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.5.1.

Storage per e in AWS

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

  1. Creazione di un bucket S3.

  2. Impostazione delle autorizzazioni per Velero.

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:

  1. Creare un account di storage e un container blob di Azure

  2. Recuperare il gruppo di risorse contenente le macchine virtuali e i dischi

  3. Impostare le autorizzazioni per Velero

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.

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.10.3 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.6.2_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.2.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.6.2_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.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:

  1. 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

  2. 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 rilevare e ripristinare 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 frequenti e 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.

Rigenerazione dei file kubeconfig dopo il ripristino

Dopo aver utilizzato Velero per ripristinare un cluster del carico di lavoro, è necessario distribuire il nuovo file kubeconfig a chiunque lo utilizzi:

  1. Rigenerare kubeconfig:

    tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

  2. Distribuire l'output del comando precedente a chiunque utilizzi i cluster per sostituire il file kubeconfig precedente.

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 dal file di configurazione, utilizzare Velero per ripristinare i cluster del carico di lavoro e distribuire i nuovi file kubeconfig agli utenti che li utilizzano:

  1. Se si sospetta una deviazione tra il backup più recente degli oggetti del cluster del carico di lavoro e il loro stato attualmente in corso, utilizzare lo strumento Rilevatore deviazione per generare un report di correzione, come descritto in Utilizzo del rilevatore di deviazione.

  2. Assicurarsi che tutte le modifiche alla configurazione apportate al cluster di gestione dopo la sua distribuzione iniziale si riflettano nel relativo file di configurazione o nelle variabili di ambiente. In caso contrario, non ripristina lo stato più recente.

  3. 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.

    • Se il cluster di gestione o i relativi cluster del carico di lavoro sono stati distribuiti in più zone di disponibilità in vSphere come descritto in Esecuzione di cluster in più zone di disponibilità, includere anche il file con le definizioni di oggetti VSphereFailureDomain e VSphereDeploymentZone ad esempio includendo --az-file vsphere-zones.yaml nel comando tanzu mc create.

  4. 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.26.8---vmware.2-tkg.1  v1.26.8+vmware.1-tkg.1  True        True

  5. 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.24.17---vmware.2-tkg.2  v1.24.17+vmware.2-tkg.2  True        True
v1.25.13---vmware.1-tkg.1  v1.25.13+vmware.1-tkg.1  True        True
v1.26.8---vmware.2-tkg.1   v1.26.8+vmware.1-tkg.1   True        True

  6. 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.

  7. 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>

  8. 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.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-tkg.1

  9. 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

  10. 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.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-tkg.1

  11. 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.26.8+vmware.1 <none>  v1.26.8---vmware.2-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.

  12. Se è stato eseguito il rilevatore di deviazione prima di ricreare il cluster di gestione, correggere o analizzare manualmente tutti gli oggetti contrassegnati nel report Rilevatore deviazione come descritto in Correzione della deviazione.

  13. Rigenerare e distribuire nuovi file kubeconfig per il cluster di gestione e i relativi cluster del carico di lavoro:

    1. Rigenerare il cluster di gestione kubeconfig:

      tanzu management-cluster kubeconfig get

    2. Per ogni cluster del carico di lavoro, rigenerare kubeconfig:

      tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

    3. Distribuire gli output dei comandi precedenti a chiunque utilizzi i cluster per sostituire i file kubeconfig precedenti.

Gestione delle deviazioni

La deviazione avviene quando gli oggetti del cluster vengono modificati dopo il backup più recente e lo stato del sistema dopo il ripristino non corrisponde allo stato desiderato più recente.

Per ridurre al minimo la deviazione, VMware consiglia di pianificare backup frequenti e regolari.

Per consentire di rilevare e correggere la deviazione, è possibile utilizzare lo strumento Rilevatore deviazione descritto nelle sezioni seguenti.

Utilizzo del rilevatore di deviazione

Rilevatore di deviazione è uno strumento da riga di comando che:

  • Confronta il contenuto di un backup TKG con lo stato corrente dell'infrastruttura degli oggetti del cluster TKG e
  • Genera un report in cui sono elencati i potenziali problemi e i passaggi per correggere la deviazione
Importante

Il rilevatore di deviazione si trova nello stato Sperimentale non supportato. La deviazione è complessa e il rilevatore della deviazione potrebbe non rilevare tutte le istanze di deviazione. Deve essere utilizzato solo come riferimento e mai in sostituzione di backup regolari.

Per informazioni su come installare e utilizzare il rilevatore di deviazione, vedere Rilevatore di deviazione per il cluster di gestione di Tanzu Kubernetes Grid nel sito Web della Knowledge Base di VMware. Il processo complessivo è:

  1. Prima di ripristinare TKG dal backup, eseguire il comando drift-detector per generare un report.

  2. Scaricare e ripristinare TKG dal backup più recente.

  3. Facendo riferimento al report Rilevatore deviazione, seguire le istruzioni in Correzione della deviazione per eseguire azioni di correzione sullo stato ripristinato di TKG.

Correzione della deviazione

I casi di deviazione possono essere complicati, ma se si dispone di un report Rilevatore di deviazione o si rilevano altre deviazioni dello stato dell'oggetto cluster dall'ultimo backup, è possibile correggere alcuni modelli comuni come indicato di seguito:

  • 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:

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

      2. 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.26.8+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.26.8+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.26.8+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.26.8+vmware.1  <none>  v1.26.8---vmware.2-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

      3. 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:

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

      2. 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.26.8+vmware.1
wc-2cjn4-4zljs                   Ready    control-plane   26h    v1.26.8+vmware.1
wc-2cjn4-59v95                   Ready    control-plane   26h    v1.26.8+vmware.1
wc-2cjn4-ncgxb                   Ready    control-plane   25h    v1.26.8+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w   Ready    <none>          26h    v1.26.8+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc   Ready    <none>          26h    v1.26.8+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv   Ready    <none>          26h    v1.26.8+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.26.8+vmware.1 <none>  v1.26.8---vmware.2-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

      3. 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.
check-circle-line exclamation-circle-line close-line
Scroll to top icon