Cette rubrique explique comment sauvegarder et restaurer l'infrastructure de cluster pour Tanzu Kubernetes Grid (TKG) avec un cluster de gestion autonome sur vSphere en procédant comme suit :
VMware ne prend pas en charge l'utilisation de Velero pour sauvegarder des clusters de gestion autonomes TKG. Si un cluster de gestion autonome est reconfiguré après son déploiement, sa recréation comme décrit ici risque de ne pas récupérer toutes ses ressources.
Pour sauvegarder et restaurer les charges de travail et les volumes de stockage dynamiques hébergés sur des clusters de charge de travail Tanzu Kubernetes Grid (TKG) avec un cluster de gestion autonome, reportez-vous à la section Sauvegarder et restaurer des charges de travail de cluster.
Pour sauvegarder et restaurer des clusters vSphere with Tanzu, y compris les clusters superviseurs et les clusters de charge de travail qu'ils créent, reportez-vous à la section Sauvegarde et restauration de vSphere with Tanzu dans la documentation de VMware vSphere 8.0.
Attention :
Cette fonctionnalité est dans l'état Version d'évaluation technique non pris en charge. Reportez-vous à la section États des fonctionnalités TKG.
L'authentification de Pinniped sur les clusters de charge de travail ne fonctionne pas après la recréation de leur cluster de gestion.
Vous pouvez utiliser Velero, un outil standard de la communauté open source, pour sauvegarder et restaurer l'infrastructure du cluster TKG avec des clusters de gestion autonomes sur vSphere.
Pour configurer Velero, suivez les instructions décrites dans Configurer Velero dans la rubrique Sauvegarder et restaurer des charges de travail de cluster. La section contient également plus d'informations sur Velero.
Pour sauvegarder des objets de cluster de charge de travail, installez le serveur Velero v1.9.5 sur le cluster de gestion autonome comme décrit dans Options d'installation de Velero, mais avec les paramètres requis suivants :
Plug-in de cluster de gestion :
ce plug-in obligatoire suspend les clusters et collecte les ressources associées aux clusters en cours de sauvegarde.
--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
Aucun emplacement de snapshot : pour la sauvegarde de l'infrastructure de cluster, ne définissez pas --snapshot-location-config
Une fois la commande velero install terminée, vérifiez que Velero a bien été installé :
Vérifiez que l'état de l'espace Velero est Running :
kubectl -n velero get pod
NAME READY STATUS RESTARTS AGE
velero-78fdbcd446-v5cqr 1/1 Running 0 3h41m
Vérifiez que l'emplacement de sauvegarde se trouve dans la phase 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
Pour sauvegarder tous les objets de cluster de charge de travail gérés par un cluster de gestion autonome, exécutez :
velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait
Remarques :
--exclude-namespaces tkg-system exclut le cluster de gestion lui-même.--include-resources cluster.cluster.x-k8s.io inclut les objets du cluster de charge de travailRemarqueVMware recommande de sauvegarder les clusters de charge de travail immédiatement après avoir apporté des modifications structurelles, telles que la montée ou la descente en puissance. Cela évite une non-correspondance entre les objets de sauvegarde et l'infrastructure physique qui peut faire échouer le processus de restauration.
Lorsque des objets de cluster sont modifiés après la sauvegarde la plus récente, l'état du système après une restauration ne correspond pas à l'état le plus récent souhaité. Ce problème est appelé « dérive ». Reportez-vous à la section Gestion des dérives ci-dessous pour savoir comment récupérer à partir de certains types courants de dérive.
Pour atténuer la dérive, VMware recommande d'utiliser Velero pour planifier des sauvegardes régulières. Par exemple, pour sauvegarder tous les clusters de charge de travail quotidiennement et conserver chaque sauvegarde pendant 14 jours :
velero create schedule daily-bak --schedule="@every 24h" --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s
Pour plus d'options de planification de Velero, reportez-vous à la section Schedule a Backup dans la documentation de Velero.
Pour restaurer un cluster de gestion autonome et les objets du cluster de charge de travail qu’il gère :
Recréez le cluster de gestion à partir de son fichier de configuration, mgmt-cluster-config.yaml ici, comme décrit dans Déployer des clusters de gestion à partir d'un fichier de configuration.
RemarqueToutes les modifications de configuration appliquées au cluster de gestion après son déploiement doivent être reflétées dans le fichier de configuration ou les variables d'environnement, sinon elles ne seront pas restaurées.
Immédiatement après la création du cluster de gestion, il ne doit y avoir qu'une seule TKr :
tanzu kubernetes-release get
NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE
v1.24.9---vmware.1-tkg.1 v1.24.9+vmware.1-tkg.1 True True
Patientez quelques minutes jusqu'à ce que toutes les TKr utilisées par les clusters de charge de travail sauvegardés soient disponibles :
tanzu kubernetes-release get
NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE
v1.22.17---vmware.2-tkg.2 v1.22.17+vmware.2-tkg.2 True True
v1.23.15---vmware.1-tkg.1 v1.23.15+vmware.1-tkg.1 True True
v1.24.9---vmware.1-tkg.1 v1.24.9+vmware.1-tkg.1 True True
Installez Velero sur le cluster de gestion, en suivant les instructions Déployer le serveur Velero sur des clusters ci-dessus. Assurez-vous que les informations d'identification et les paramètres de configuration de l'emplacement de sauvegarde ont les mêmes valeurs que lors de la sauvegarde.
Après l'installation de Velero, exécutez velero backup get jusqu'à ce que les sauvegardes soient synchronisées et que la commande répertorie la sauvegarde que vous souhaitez utiliser :
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>
Exécutez velero restore create pour restaurer les ressources du cluster de charge de travail. VMware recommande d'utiliser la sauvegarde la plus récente :
velero restore create my-restore --from-backup my-backup --wait
Une fois la restauration terminée, l'état des clusters est createdStalled :
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
tkg-vc-antrea default createdStalled 0/3 0/3 v1.24.9+vmware.1 <none> prod v1.24.9---vmware.1-tkg.1
Corrigez les objets du cluster pour définir leur propriété paused sur false. Cela est nécessaire, car les objets du cluster sont recréés dans un état paused sur le nouveau cluster de gestion, afin d'empêcher leurs contrôleurs de tenter de concilier :
Pour annuler le couplage d'un cluster après sa restauration, exécutez :
kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
Pour annuler le couplage de tous les clusters dans plusieurs espaces de noms, exécutez le 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
Vérifiez que tous les clusters de charge de travail sont dans l'état running, par exemple :
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
tkg-vc-antrea default running 3/3 3/3 v1.24.9+vmware.1 <none> prod v1.24.9---vmware.1-tkg.1
Pour chaque cluster de charge de travail, exécutez tanzu cluster get CLUSTER-NAME pour vérifier que tous les composants sont dans l'état running, par exemple :
tanzu cluster get tkg-vc-antrea
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR
tkg-vc-antrea default running 3/3 3/3 v1.24.9+vmware.1 <none> v1.24.9---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
Une fois que tous les clusters de charge de travail sont en cours d'exécution, vous pouvez gérer les clusters de charge de travail avec la CLI Tanzu.
Les cas de dérive peuvent être compliqués, mais quelques modèles et atténuations courants incluent :
Nœuds worker obsolètes :
Infrastructure de nœud worker fantôme :
Atténuation :
kubeconfig et définissez-le sur le contexte kubectl.Comparez la sortie des commandes kubectl et tanzu suivantes :
# 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.24.9+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt Ready <none> 114m v1.24.9+vmware.1
tkg-vc-antrea-wdsfx-2hkxp Ready control-plane 116m v1.24.9+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.24.9+vmware.1 <none> v1.24.9---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
Pour chaque nœud worker répertorié par kubectl qui ne dispose pas d'une liste Workers > Machine de tanzu cluster get :
Monter en puissance les travailleurs à la valeur attendue, par exemple :
tanzu cluster scale ${cluster_name} --worker-machine-count 2
kubeconfig pour drainer le nœud fantôme, qui déplace ses charges de travail vers des nœuds gérés par TKG :kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
Supprimez le nœud fantôme du cluster :
kubectl delete node ${node_name}
Connectez-vous à vSphere ou à une autre infrastructure et supprimez manuellement la machine virtuelle.
Nœuds obsolètes et infrastructure fantôme sur le plan de contrôle
Atténuation :
kubeconfig et définissez-le sur le contexte kubectl.Comparez la sortie des commandes kubectl et tanzu suivantes :
# 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.24.9+vmware.1
wc-2cjn4-4zljs Ready control-plane 26h v1.24.9+vmware.1
wc-2cjn4-59v95 Ready control-plane 26h v1.24.9+vmware.1
wc-2cjn4-ncgxb Ready control-plane 25h v1.24.9+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w Ready <none> 26h v1.24.9+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc Ready <none> 26h v1.24.9+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv Ready <none> 26h v1.24.9+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.24.9+vmware.1 <none> v1.24.9---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
Pour chaque nœud control-plane répertorié par kubectl qui ne dispose pas d'une liste ControlPlane > Machine provenant du cluster tanzu cluster get :
Supprimez le nœud :
kubectl delete node ${node_name}
