Mettre à niveau des clusters de gestion autonomes

Pour mettre à niveau Tanzu Kubernetes Grid avec un cluster de gestion autonome, vous devez d'abord mettre à niveau le cluster de gestion autonome. Vous ne pouvez pas mettre à niveau les clusters de charge de travail tant que vous n'avez pas mis à niveau le cluster de gestion qui les gère.

Si vous exécutez TKG avec vSphere with Tanzu Supervisor, ne suivez pas cette procédure. Au lieu de cela, mettez à niveau le superviseur dans le cadre de vSphere et mettez à jour la version de Kubernetes du superviseur en mettant à niveau ses TKR.

Important
Tanzu Kubernetes Grid v2.4.x est la dernière version de TKG qui prend en charge la mise à niveau de clusters de gestion TKG autonomes existants sur AWS et Azure. La possibilité de mettre à niveau les clusters de gestion TKG autonomes sur AWS et Azure sera supprimée dans Tanzu Kubernetes Grid version v2.5.

À partir de maintenant, VMware vous recommande d'utiliser Tanzu Mission Control pour créer des clusters AWS EKS et Azure AKS natifs. Cependant, la mise à niveau des clusters de gestion TKG autonomes existants sur AWS et Azure reste entièrement prise en charge pour toutes les versions de TKG, y compris TKG v2.4.x.

Pour plus d'informations, reportez-vous à la section Obsolescence des clusters de gestion et de charge de travail TKG sur AWS et Azure des Notes de mise à jour de VMware Tanzu Kubernetes Grid v2.4.

La mise à niveau du cluster de gestion met automatiquement à niveau les modules gérés automatiquement qu'il exécute.

Remarque
Lorsque vous avez installé la CLI Tanzu, mais avant la mise à niveau d'un cluster de gestion autonome, tous les groupes de commandes CLI propres au contexte (tanzu cluster, tanzu kubernetes-release) ne sont pas disponibles et ne sont pas inclus dans la sortie --help de la CLI Tanzu.

Les clusters de gestion et les clusters de charge de travail utilisent des certificats clients pour authentifier les clients. Ces certificats sont valides pendant un an. Pour les renouveler, mettez à niveau vos clusters au moins une fois par an ou effectuez une rotation manuelle de ceux-ci, comme décrit dans la section Renouveler les certificats de cluster (MC autonome) ou dans l'article de la base de connaissances VMware Comment effectuer une rotation des certificats dans un cluster Tanzu Kubernetes Grid.

Conditions requises

Vous avez examiné les problèmes connus liés à la mise à niveau. Consultez la rubrique Problèmes connus.
Vous avez effectué les étapes de la section Mise à niveau de Tanzu Kubernetes Grid qui se produisent avant l'étape de mise à niveau des clusters de gestion.
Accès restreint à Internet (Internet-Restricted) : Si vous avez déployé la version précédente de Tanzu Kubernetes Grid dans un environnement à accès restreint à Internet, vous avez suivi les étapes de la section Préparer un environnement à accès restreint à Internet pour recréer et exécuter les scripts requis avec les nouvelles versions de l'image de composant.
Clusters personnalisés (Custom clusters) : Si vous disposez de clusters de charge de travail qui utilisent une définition ClusterClass personnalisée, vous avez effectué les étapes de la section Mettre à niveau des clusters personnalisés.
LDAP : Si la version précédente du cluster de gestion est intégrée à un fournisseur d'identité LDAP, vous avez effectué les étapes décrites dans la section (LDAP uniquement) Mettre à jour les paramètres LDAP.

(LDAP uniquement) Mettre à jour les paramètres LDAP

À partir de Tanzu Kubernetes Grid v2.3, vous devez définir les variables LDAP_BIND_DN et LDAP_BIND_PASSWORD lors de la configuration d'un fournisseur d'identité LDAP. Avant de mettre à niveau un cluster de gestion configuré pour utiliser un fournisseur d'identité LDAP pour Tanzu Kubernetes Grid v2.3, définissez ces variables si vous ne l'avez pas déjà fait. La mise à niveau de votre cluster de gestion sans définir LDAP_BIND_DN et LDAP_BIND_PASSWORD entraîne l'échec du déploiement de la valeur App de Pinniped et la ressource personnalisée App renvoie une erreur. Pour plus d'informations sur ces variables de configuration, reportez-vous à la section Fournisseurs d'identité - LDAP du document Référence de variable de fichier de configuration.

Pour mettre à jour LDAP_BIND_DN et LDAP_BIND_PASSWORD, vous devez utiliser la version du plug-in d'interface de ligne de commande management-cluster qui correspond à la version de votre cluster de gestion. Procédez comme suit avant de mettre à niveau le cluster de gestion :

Ajoutez LDAP_BIND_DN et LDAP_BIND_PASSWORD au fichier de configuration de votre cluster de gestion.
Vérifiez que la version correcte du plug-in management-cluster est installée sur votre machine. Pour Tanzu Kubernetes Grid v2.2.0, la version correcte est v0.29.0.
```
tanzu plugin list
```
Si la version correcte du plug-in management-cluster n'est pas installée, procédez comme suit :
1. Dans la liste de toutes les versions disponibles, recherchez la version du plug-in management-cluster qui correspond à la version de votre cluster de gestion :
```
tanzu plugin search -n management-cluster --show-details
```
2. Installez le plug-in :
```
tanzu plugin install management-cluster --version PLUGIN-VERSION
```
  PLUGIN-VERSION correspond à la version que vous avez recherchée à l'étape précédente.
Pour générer un secret du module Pinniped, exécutez :
```
FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run -f YOUR-MANAGEMENT-CLUSTER-CONFIG-FILE.yaml > PINNIPED-PACKAGE-SECRET.yaml
```
YOUR-MANAGEMENT-CLUSTER-CONFIG-FILE.yaml correspond au fichier de configuration que vous avez mis à jour à l'étape précédente et PINNIPED-PACKAGE-SECRET.yaml est le nouveau secret du module Pinniped.
Confirmez que le secret obtenu inclut vos paramètres mis à jour, définissez le contexte kubectl sur le cluster de gestion et appliquez le secret :
```
kubectl apply -f PINNIPED-PACKAGE-SECRET.yaml
```

Procédure

Exécutez la commande tanzu context use pour afficher une liste interactive des clusters de gestion disponibles pour la mise à niveau.
```
tanzu context use
```
Sélectionnez le cluster de gestion que vous souhaitez mettre à niveau. Pour plus d'informations, reportez-vous à la section Répertorier les clusters de gestion et modifier le contexte.
Obtenez les informations d’identification de l’administrateur du cluster. L'alias de la CLI Tanzu mc est court pour management-cluster.
```
tanzu mc kubeconfig get --admin
```

Connectez kubectl au cluster de gestion.

kubectl config use-context CLUSTER-NAME-admin@CLUSTER-NAME.

Si le cluster de gestion est en cours d'exécution sur Azure, définissez la variable d'environnement AZURE_CLIENT_SECRET avant de mettre à niveau le cluster :
```
export AZURE_CLIENT_SECRET=YOUR-AZURE-CLIENT-SECRET
```
Exécutez la commande tanzu mc upgrade et entrez y pour confirmer.

Remarque
Après l'exécution de cette commande, les utilisateurs non-administrateurs ne peuvent pas se connecter aux clusters de charge de travail associés tant que les espaces Pinniped n'ont pas terminé le redémarrage.
```
tanzu mc upgrade
```
Si plusieurs images de VM de base dans votre compte IaaS ont la même version de Kubernetes que celle vers laquelle vous effectuez la mise à niveau, vous pouvez inclure --os-name et d'autres options pour spécifier le système d'exploitation cible comme décrit dans la section Sélectionner un système d'exploitation vers lequel effectuer la mise à niveau :
```
tanzu mc upgrade --os-name ubuntu
```
Sur vSphere, vous pouvez utiliser l'option --vsphere-vm-template-name pour spécifier un modèle OVA cible pour les nœuds de cluster comme décrit dans la section Sélectionner un modèle OVA vers lequel effectuer la mise à niveau :
```
tanzu mc upgrade --vsphere-vm-template-name "/dc0/vm/tanzu/ubuntu-2004-kube-v1.29.9-vmware.1"
```
Pour ignorer l'étape de confirmation lorsque vous mettez à niveau un cluster, spécifiez l'option --yes.
```
tanzu mc upgrade --yes
```
Le processus de mise à niveau met d'abord à niveau les fournisseurs d'API de cluster pour vSphere, Amazon Web Services (AWS) ou Azure qui s'exécutent dans le cluster de gestion. Ensuite, il met à niveau la version de Kubernetes dans tous les nœuds de plan de contrôle et worker du cluster de gestion.

Important
Pendant la mise à niveau d'un cluster de gestion, n'exécutez pas les commandes tanzu cluster ou tanzu mc sur celui-ci ou sur les clusters de charge de travail qu'il gère, par exemple à partir d'une autre machine de démarrage ou d'une autre fenêtre de shell.

Si la mise à niveau expire avant sa fin, exécutez tanzu mc upgrade de nouveau et spécifiez l'option --timeout avec une valeur supérieure à la valeur par défaut de 30 minutes.
```
tanzu mc upgrade --timeout 45m0s
```
Remarque
Lorsque vous avez installé la version v2.3 de l'interface de ligne de commande, mais avant la mise à niveau d'un cluster de gestion autonome, tous les groupes de commandes CLI propres au contexte (tanzu cluster, tanzu kubernetes-release) ainsi que toutes les commandes de plug-in management-cluster, à l'exception de tanzu mc upgrade et de tanzu mc create, ne sont pas disponibles et ne sont pas inclus dans la sortie --help de la CLI Tanzu.

Une fois la mise à niveau terminée, exécutez de nouveau la commande tanzu cluster list avec les options --include-management-cluster -A pour vérifier que le cluster de gestion a été mis à niveau.

tanzu cluster list --include-management-cluster -A

Vous voyez que le cluster de gestion exécute désormais la nouvelle version de Kubernetes, mais que les clusters de charge de travail exécutent toujours les versions précédentes de Kubernetes.

 NAME                 NAMESPACE   STATUS    CONTROLPLANE  WORKERS  KUBERNETES         ROLES       PLA   TKR
 k8s-1-24-14-cluster  default     running   1/1           1/1      v1.24.14+vmware.1  <none>      dev   v1.24.14---vmware.1-tkg.1
 k8s-1-25-10-cluster  default     running   1/1           1/1      v1.25.10+vmware.1  <none>      dev   v1.25.10---vmware.1-tkg.1
 mgmt-cluster         tkg-system  running   1/1           1/1      v1.26.8+vmware.1   management  dev   v1.26.8---vmware.2-tkg.1

Régénérez le fichier admin kubeconfig :
```
tanzu management-cluster kubeconfig get --admin
```
Voici un exemple de sortie de cette commande :
```
Credentials of cluster 'mgmt' have been saved
You can now access the cluster by running 'kubectl config use-context mgmt-admin@mgmt'
```
Important
Si vous ne renouvelez pas kubeconfig après la mise à niveau, vous ne pourrez pas accéder au cluster après son expiration.

Tâches suivantes

Vous pouvez désormais :

Mettez à niveau les clusters de charge de travail que ce cluster de gestion gère.
Créer des clusters de charge de travail. Par défaut, tous les nouveaux clusters que vous déployez avec ce cluster de gestion exécuteront la nouvelle version par défaut de Kubernetes. Cependant, si nécessaire, vous pouvez utiliser la commande tanzu cluster create avec l'option --tkr pour déployer de nouveaux clusters qui exécutent différentes versions de Kubernetes. Pour plus d'informations, reportez-vous à la section Plusieurs versions de Kubernetes.