Mettre à niveau les clusters de charge de travail

Cette rubrique explique comment mettre à niveau des clusters de charge de travail Tanzu Kubernetes Grid (TKG). Pour TKG avec un cluster de gestion autonome, vous devez d'abord mettre à niveau le cluster de gestion qui gère les clusters de charge de travail.

Important

Pour mettre à niveau des clusters de charge de travail que vous avez déployés avec le superviseur dans vSphere 8, reportez-vous à la section Mise à niveau des clusters déployés par le superviseur (vSphere 8 uniquement) dans le document Création et gestion de clusters de charge de travail TKG 2.3 avec la CLI Tanzu.

Pour mettre à niveau des clusters de charge de travail Edge qui utilisent des modèles de VM stockés localement, reportez-vous à la section Mettre à niveau un cluster Edge avec un modèle de VM local.

Pour mettre à niveau les clusters de charge de travail que vous avez créés à partir d'un manifeste de cluster personnalisé, reportez-vous à la section Mettre à niveau des clusters personnalisés.

Les clusters de gestion autonomes 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.

Conditions requises

Vous avez effectué les étapes de la section Mise à niveau Tanzu Kubernetes Grid.
Si vous exécutez TKG avec un cluster de gestion autonome, vous avez effectué les étapes de la section Mettre à niveau des clusters de gestion autonomes.

Conditions préalables à l'infrastructure

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

À 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 charge de travail TKG 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.

vSphere: Si vous mettez à niveau des clusters qui s'exécutent sur vSphere, avant de pouvoir mettre à niveau des clusters vers une version autre que celle par défaut de Kubernetes pour votre version de Tanzu Kubernetes Grid, les fichiers OVA de modèle d'image de base appropriés doivent être disponibles dans vSphere en tant que modèles de machine virtuelle. Pour plus d'informations sur l'importation de fichiers OVA dans vSphere, reportez-vous à l'onglet vSphere de la section Préparer la mise à niveau des clusters.
AWS: Si vous mettez à niveau des clusters qui s'exécutent sur Amazon Web Services (AWS), les AMI (Amazon Machine Image) Amazon Linux 2 qui incluent les versions de Kubernetes prises en charge sont publiquement disponibles pour tous les utilisateurs AWS, dans toutes les régions AWS prises en charge. Tanzu Kubernetes Grid utilise automatiquement l'AMI appropriée pour la version de Kubernetes que vous spécifiez lors de la mise à niveau.
Azure: Si vous mettez à niveau des clusters qui s'exécutent sur Azure, assurez-vous d'avoir effectué les étapes décrites dans l'onglet Azure de la section Préparer la mise à niveau des clusters.

Procédure

Le processus de mise à niveau met à niveau la version de Kubernetes dans tous les nœuds de plan de contrôle et worker de vos clusters de charge de travail.

Pour afficher une liste interactive des clusters de gestion disponibles et sélectionner le cluster de gestion qui gère les clusters à mettre à niveau, exécutez la commande tanzu context use :
```
tanzu context use
```

Pour répertorier vos clusters de charge de travail, exécutez :

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

La commande tanzu cluster list avec les options --include-management-cluster -A affiche la version de Kubernetes qui s'exécute dans le cluster de gestion et tous les clusters qu'il gère. Dans cet exemple, vous pouvez voir que le cluster de gestion a déjà été mis à niveau vers la version v1.26.8, mais que les clusters de charge de travail exécutent d'anciennes versions de Kubernetes.

NAME                 NAMESPACE   STATUS    CONTROLPLANE  WORKERS  KUBERNETES         ROLES       PLAN  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      1.25.10+vmware.1   <none>      dev   1.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.1-tkg.1

Pour découvrir les versions de Kubernetes mises à disposition par un cluster de gestion, exécutez la commande tanzu kubernetes-release get :
```
tanzu kubernetes-release get
```
La sortie répertorie toutes les versions de Kubernetes que vous pouvez utiliser pour déployer des clusters, avec les remarques suivantes :
- COMPATIBLE : Le cluster de gestion actuel peut déployer des clusters de charge de travail avec cette version de Tanzu Kubernetes (tkr).
- UPDATES AVAILABLE : Cette tkr n'est pas la plus récente de sa ligne de version de Kubernetes. Tous les clusters de charge de travail exécutant cette version tkr peuvent être mis à niveau vers des versions plus récentes.
Par exemple :
```
NAME                              VERSION                         COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.24.17---vmware.1-tiny.2-tkg.1  v1.24.17+vmware.1-tiny.2-tkg.1  True        True
v1.24.17---vmware.2-tkg.1         v1.24.17+vmware.2-tkg.1         True        True
v1.25.13---vmware.1-tiny.2-tkg.1  v1.25.13+vmware.1-tiny.2-tkg.1  True        True
v1.25.13---vmware.2-tkg.1         v1.25.13+vmware.2-tkg.1         True        True
v1.26.8---vmware.1-tiny.2-tkg.1   v1.26.8+vmware.1-tiny.2-tkg.1   True        True
v1.26.8---vmware.2-tkg.1          v1.26.8+vmware.2-tkg.1          True        True
```
Pour découvrir les versions tkr plus récentes vers lesquelles vous pouvez mettre à niveau un cluster de charge de travail exécutant une ancienne version tkr, exécutez la commande tanzu kubernetes-release available-upgrades get, en spécifiant la version tkr actuelle :
```
tanzu kubernetes-release available-upgrades get v1.25.10---vmware.2-tkg.1
```
Cette commande répertorie toutes les versions de Kubernetes disponibles vers lesquelles vous pouvez mettre à niveau les clusters qui exécutent la version spécifiée.

Vous pouvez également découvrir les versions tkr disponibles pour un cluster de charge de travail spécifique en spécifiant le nom du cluster dans la commande tanzu cluster available-upgrades get :
```
tanzu cluster available-upgrades get k8s-1-24-14-cluster
```
Cette commande répertorie toutes les versions de Kubernetes compatibles avec le cluster spécifié.

Vous ne pouvez pas ignorer les versions mineures lors de la mise à niveau de votre version tkr. Par exemple, vous ne pouvez pas mettre à niveau un cluster directement de la version v1.24.x vers la version v1.26.x. Vous devez mettre à niveau un cluster v1.24.x vers la version v1.25.x avant de mettre à niveau le cluster vers la version v1.26.x.
(Azure) Si le cluster s'exécute 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
```
(vSphere) Tout cluster qui utilise IPAM de nœud nécessite au moins une adresse IP non attribuée dans son pool d'adresses IP avant la mise à niveau.
1. Pour vérifier si un cluster utilise l'IPAM de nœud, recherchez addressesFromPools dans le paramètre spec.topology.variables network de l'objet du cluster :
```
kubectl -n NAMESPACE get cluster CLUSTER-NAME -o json | jq '.spec.topology.variables[] | select(.name=="network")'
```
  CLUSTER-NAME et NAMESPACE correspondent au nom du cluster de charge de travail et à l'espace de noms du cluster de gestion. Par exemple :
```
kubectl -n default get cluster my-work-cluster -o json | jq '.spec.topology.variables[] | select(.name=="network")'
{
  "name": "network",
  "value": {
    "addressesFromPools": [
      {
        "apiGroup": "ipam.cluster.x-k8s.io",
        "kind": "InClusterIPPool",
        "name": "mgmt-cluster-nimbus"
      }
    ],
    "ipv6Primary": false
  }
} 
```
2. Pour vérifier que le pool d'adresses IP du cluster contient des adresses inutilisées, comparez le nombre total dans le pool avec le nombre actuellement alloué, tel que généré par la commande suivante :
```
kubectl -n NAMESPACE get ipaddress | grep POOL-NAME | wc -l
```
Exécutez la commande tanzu cluster upgrade CLUSTER-NAME et entrez y pour confirmer. Pour ignorer l'étape de confirmation, spécifiez l'option --yes.

Pour mettre à niveau le cluster vers la version par défaut de Kubernetes pour cette version de Tanzu Kubernetes Grid, exécutez la commande tanzu cluster upgrade sans option. Dans cette version, la version par défaut est v1.26.8. Par exemple :
```
tanzu cluster upgrade k8s-1-25-7-cluster
```
Si le cluster n'est pas en cours d'exécution dans l'espace de noms default, spécifiez l'option --namespace :
```
tanzu cluster upgrade CLUSTER-NAME --namespace NAMESPACE-NAME
```
Si une mise à niveau expire avant qu'elle ne se termine, exécutez de nouveau tanzu cluster upgrade et spécifiez l'option --timeout avec une valeur supérieure à la valeur par défaut de 30 minutes :
```
tanzu cluster upgrade CLUSTER-NAME --timeout 45m0s
```
Important
Les opérations sur Azure prennent parfois plus de temps que sur d'autres plates-formes. Si vous mettez à niveau des clusters sur Azure, définissez systématiquement l'option --timeout afin d'éviter les échecs.

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 cluster upgrade CLUSTER-NAME --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 cluster upgrade CLUSTER-NAME --vsphere-vm-template-name "/dc0/vm/tanzu/ubuntu-2004-kube-v1.29.9-vmware.1"
```
Comme vous ne pouvez pas ignorer les versions mineures de tkr, la commande de mise à niveau échoue si vous tentez de mettre à niveau un cluster qui se trouve plus d'une version mineure avant la version par défaut. Par exemple, vous ne pouvez pas effectuer une mise à niveau directe de la version v1.24.x vers la version v1.26.x. Pour mettre à niveau un cluster vers une version de Kubernetes qui n'est pas la version par défaut de cette version de Tanzu Kubernetes Grid, spécifiez l'option --tkr avec le NAME de la version choisie, comme indiqué par tanzu kubernetes-release get ci-dessus. Par exemple, pour mettre à niveau le cluster k8s-1-24-14-cluster de la v1.24.14 à la v1.25.13.
```
tanzu cluster upgrade k8s-1-24-14-cluster --tkr v1.25.13---vmware.1-tkg.1
```
Une fois la mise à niveau terminée, exécutez la commande tanzu cluster list pour vérifier que le cluster de charge de travail a été mis à niveau :
```
tanzu cluster list --include-management-cluster -A
```
Régénérez le fichier admin kubeconfig :
```
tanzu cluster kubeconfig get CLUSTER-NAME --admin
```
Où CLUSTER-NAME est le nom du cluster de charge de travail.

Important
Si vous ne renouvelez pas kubeconfig après la mise à niveau, vous ne pourrez pas accéder au cluster après son expiration.
Si vous utilisez un fournisseur d'identité LDAP ou OIDC, confirmez que vous pouvez vous authentifier sur le cluster avec kubectl. Par exemple :
```
kubectl get pods -A --kubeconfig my-cluster-credentials
```
Mettez à niveau tous les modules gérés par la CLI tels que Contour, Fluent Bit ou Prometheus qui s'exécutent sur vos clusters de charge de travail. Pour plus d'informations sur la mise à niveau des modules gérés par la CLI, reportez-vous à la section Mettre à jour un module.

Important
Si vous avez installé Prometheus sur un cluster de charge de travail et que vous mettez à niveau le cluster de charge de travail vers Kubernetes v1.25, vous devez mettre à niveau Prometheus vers au moins la version 2.37.0+vmware.3-tkg.1. Les versions antérieures du module Prometheus, par exemple version 2.37.0+vmware.1-tkg.1, ne sont pas compatibles avec Kubernetes 1.25.

Mettre à niveau un cluster Edge avec un modèle de VM local

Vous ne pouvez pas utiliser la commande tanzu cluster upgrade pour mettre à niveau la version de Kubernetes d'un cluster de charge de travail Edge avec un modèle de VM local, comme décrit dans la section Spécification d'un modèle de VM local ci-dessus.

Mettez plutôt à niveau la version de Kubernetes du cluster de charge de travail Edge comme suit :

Chargez le nouveau modèle de VM vers l'instance de vCenter locale et enregistrez son chemin d'accès d'inventaire, par exemple /dc0/vm/ubuntu-2004-kube-v1.26.8+vmware.1-tkg.1.
Modifiez le manifeste de l'objet Cluster à mettre à niveau :
```
kubectl edit cluster CLUSTER-NAME
```
CLUSTER-NAME correspond au nom du cluster
Sous spec.topology, mettez à jour les éléments suivants :
- Définissez version pour refléter la nouvelle version de Kubernetes.
- Définissez toutes les valeurs vcenter.template à mettre à jour, à l'échelle du cluster ou dans les déploiements de machines individuelles, sur le chemin d'accès d'inventaire du nouveau modèle local.
Enregistrez et quittez pour appliquer les nouveaux paramètres de l'objet Cluster.

Tâches suivantes

Vous pouvez maintenant continuer à utiliser la CLI Tanzu pour gérer vos clusters. Pour plus d'informations, reportez-vous à la section Création et gestion de clusters de charge de travail TKG 2.3 avec la CLI Tanzu.