Créer une ClusterClass personnalisée

Cette rubrique explique comment créer votre propre ressource ClusterClass personnalisée pour un cluster de gestion autonome Tanzu Kubernetes Grid (TKG), l'utiliser pour créer des clusters de charge de travail basés sur une classe et utiliser des clusters basés sur la ClusterClass personnalisée.

Pour baser un cluster sur une ClusterClass personnalisée, définissez sa spec.topology.class sur le nom ClusterClass.

Ces procédures ne s'appliquent pas à TKG avec un superviseur vSphere with Tanzu.

Attention :

La ClusterClass personnalisée est une fonctionnalité Kubernetes expérimentale, selon la documentation de l'API du cluster en amont. En raison de la plage de personnalisations disponible avec la ClusterClass personnalisée, VMware ne peut pas tester ou valider toutes les personnalisations possibles. Les clients sont responsables du test, de la validation et du dépannage de leurs clusters ClusterClass personnalisés. Les clients peuvent ouvrir des tickets de support concernant leurs clusters ClusterClass personnalisés. Toutefois, le support VMware se limite uniquement au principe du « meilleur effort » et ne peut pas garantir la résolution de chaque problème ouvert pour les clusters ClusterClass personnalisés. Les clients doivent tenir compte de ces risques avant de déployer des clusters ClusterClass personnalisés dans des environnements de production. Pour créer des clusters de charge de travail à l'aide de la ressource ClusterClass par défaut, suivez les procédures décrites dans la section Étapes du déploiement d'un cluster.

Configuration requise

Pour créer une ClusterClass personnalisée, vous devez installer ytt, imgpkg, la CLI Tanzu et kubectl localement. Pour plus d'informations sur le téléchargement et l'installation de ytt et de imgpkg, reportez-vous à la section Installer les outils Carvel.

Options : Modèles par rapport à Nouvelle spécification d'objet

Pour créer une ClusterClass personnalisée, VMware recommande de commencer par le manifeste ClusterClass par défaut existant ou les modèles YTT décrits dans la section Créer un manifeste ClusterClass de base. Lorsqu'une nouvelle version de l'objet ClusterClass par défaut est publiée, par exemple avec une nouvelle version de TKG, vous pouvez ensuite appliquer la superposition à la nouvelle version afin de mettre en œuvre les mêmes personnalisations. Les procédures contenues dans cette rubrique décrivent cette méthode de création d'un objet ClusterClass personnalisé.

Pour écrire un objet ClusterClass entièrement nouveau sans utiliser de modèle existant, suivez la procédure décrite dans la section Écriture d'une ClusterClass de la documentation de l'API de cluster.

Créer un manifeste ClusterClass de base

Vous pouvez créer un manifeste ClusterClass de base selon le manifeste ClusterClass par défaut ou les modèles YTT fournis par Tanzu Kubernetes Grid. Tous les clusters personnalisés que vous créez doivent être basés sur ce manifeste ClusterClass de base. Le processus comporte 3 étapes :

1. Obtenez le manifeste ClusterClass par défaut ou les modèles YTT pour votre plate-forme cible.
2. Utilisez le manifeste ClusterClass par défaut ou les modèles YTT pour générer un manifeste ClusterClass de base personnalisé qui inclut des informations sur votre infrastructure.
3. Utilisez ce manifeste ClusterClass de base comme modèle à partir duquel créer vos clusters personnalisés.

Trois méthodes permettent de créer un manifeste ClusterClass de base pour vos clusters.

• Méthode 1 : Obtenir directement le manifeste de base à partir d'un cluster de gestion. Il s'agit de la méthode la plus simple. Un manifeste de base par défaut est généré automatiquement lorsque vous déployez un cluster de gestion. Ce manifeste de base inclut la configuration de l'infrastructure que vous avez fournie lors du déploiement du cluster de gestion. Vous pouvez l'utiliser comme manifeste ClusterClass de base directement.
• Méthode 2 : Obtenir les modèles YTT à partir de la CLI Tanzu (Avancé). Lorsque vous installez la CLI Tanzu, les modèles YTT sont installés sur votre machine. Pour créer un manifeste de base à partir de ces modèles YTT, vous devez créer une superposition YTT qui fournit la configuration de votre infrastructure.
• Méthode 3 : Obtenir les modèles YTT à partir du registre d'images TKG (Avancé). Vous pouvez également obtenir les modèles YTT à partir du registre d'images TKG. Pour créer un manifeste de base à partir de ces modèles YTT, vous devez créer une superposition YTT qui fournit la configuration de votre infrastructure.

Important

Les méthodes 2 et 3 sont destinées aux utilisateurs avancés qui doivent répondre aux cas d'utilisation suivants :

• Vous souhaitez générer des définitions ClusterClass personnalisées pour votre système CI, sans déployer de cluster de gestion autonome.
• Vous souhaitez que les clusters de charge de travail utilisent une infrastructure différente de celle des clusters de gestion.

Méthode 1 : Obtenir le manifeste de base directement à partir d'un cluster de gestion

Lorsque vous déployez un cluster de gestion dans Tanzu Kubernetes Grid v2.3.0 et versions ultérieures, vous trouverez le manifeste ClusterClass par défaut dans le dossier ~/.config/tanzu/tkg/clusterclassconfigs.

Pour afficher le manifeste des plates-formes cibles sur lesquelles vous avez déployé un cluster de gestion, exécutez la commande suivante :

tree ~/.config/tanzu/tkg/clusterclassconfigs/

Par exemple, si vous avez déployé un cluster de gestion sur vSphere, le fichier YAML suivant s'affiche.

.config/tanzu/tkg/clusterclassconfigs/
└── tkg-vsphere-default-v1.1.0.yaml
 
1 directory, 1 file

Le manifeste généré contient des informations sur votre plate-forme cible qui ont été extraites de votre déploiement de cluster de gestion. Vous pouvez l'utiliser directement comme manifeste de base pour la création d'une ClusterClass personnalisée. Pour les étapes suivantes, reportez-vous à la section Personnaliser votre manifeste ClusterClass de base.

Méthode 2 : Obtenir les modèles YTT à partir de la CLI Tanzu

Après avoir installé la CLI Tanzu v1.0.0 ou une version ultérieure, mais avant d'avoir déployé un cluster de gestion, vous trouverez les modèles YTT pour la ClusterClass par défaut dans le dossier ~/.config/tanzu/tkg/providers/infrastructure-<provider name>/<provider version>/cconly. Vous pouvez utiliser ces modèles pour créer un manifeste de base pour la création d'une ClusterClass personnalisée.

1. Pour rechercher les modèles, exécutez la commande appropriée pour votre plate-forme cible.

   vSphere

   tree ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
   

   Les fichiers YAML suivants s'affichent.

   .config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   
   1 directory, 3 files
   

   AWS

   tree ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
   

   Les fichiers YAML suivants s'affichent.

   .config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   

   Azure

   tree ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
   

   Les fichiers YAML suivants s'affichent.

   .config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   

2. Créez un fichier data-value YTT nommé user_input.yaml avec le contenu suivant.

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   

3. Ajoutez les valeurs de configuration appropriées à votre plate-forme à user_input.yaml.

   Vous pouvez utiliser les valeurs de configuration que vous avez utilisées lorsque vous avez déployé un cluster de gestion. Par exemple, un fichier user_input.yaml pour vSphere ressemble à ceci :

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   ENABLE_MHC: true
   ENABLE_MHC_CONTROL_PLANE: true
   ENABLE_MHC_WORKER_NODE: true
   MHC_UNKNOWN_STATUS_TIMEOUT: 5m
   MHC_FALSE_STATUS_TIMEOUT: 12m
   MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
   MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
   NODE_STARTUP_TIMEOUT: 20m
   VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
   VSPHERE_DATACENTER: /dc0
   VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
   VSPHERE_FOLDER: /dc0/vm
   VSPHERE_NETWORK: /dc0/network/VM Network
   VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
   VSPHERE_SERVER: xxx.xxx.xxx.xxx
   VSPHERE_USERNAME: [email protected]
   VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
   VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
   VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
   VSPHERE_WORKER_MEM_MIB: "8192"
   VSPHERE_WORKER_NUM_CPUS: "4"
   VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.0"       # change it to the version in TKG BOM
   NAMESPACE: "tkg-system"                       # DO NOT change it
   

4. Utilisez ytt pour générer le manifeste ClusterClass de base pour votre plate-forme cible.

   vSphere

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

   AWS

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

   Azure

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

Maintenant que vous avez généré un manifeste de base pour votre infrastructure, reportez-vous à la section Personnaliser votre manifeste ClusterClass de base pour les étapes suivantes.

Méthode 3 : Obtenir des modèles YTT à partir du registre d'images TKG

Les modèles YTT de la ClusterClass par défaut sont également disponibles en téléchargement à partir du référentiel d'images TKG. Vous pouvez utiliser ces modèles pour créer un manifeste de base pour la création d'une ClusterClass personnalisée.

1. Extrayez les modèles YTT de l'image providerTemplate dans le registre TKG officiel.

   Pour TKG v2.3.1, la balise d'image providerTemplate est v0.30.2. Pour trouver la version de la balise dans le fichier de nomenclature TKG, recherchez providerTemplateImage.

   imgpkg pull -i projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates:v0.30.2 -o providers
   

   La sortie ressemble à ceci :

   Pulling image 'projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates@sha256:b210d26c610800f5da4b3aa55bfbc8ffae9275fa2c4073a2b1332e2045a6e1da'
   Extracting layer 'sha256:3ba336232c0e616b2b6c8f263593497c5a059a645f4c6137ea0eb658f4a8538a' (1/1)
   
   Succeeded
   

   Les fichiers de modèle YAML sont téléchargés dans un dossier providers.

2. Créez un fichier data-value YTT nommé user_input.yaml avec le contenu suivant.

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   

3. Ajoutez les valeurs de configuration appropriées à votre plate-forme à user_input.yaml.

   Vous pouvez utiliser les valeurs de configuration que vous avez utilisées lorsque vous avez déployé un cluster de gestion. Par exemple, un fichier user_input.yaml pour vSphere ressemble à ceci :

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   ENABLE_MHC: true
   ENABLE_MHC_CONTROL_PLANE: true
   ENABLE_MHC_WORKER_NODE: true
   MHC_UNKNOWN_STATUS_TIMEOUT: 5m
   MHC_FALSE_STATUS_TIMEOUT: 12m
   MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
   MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
   NODE_STARTUP_TIMEOUT: 20m
   VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
   VSPHERE_DATACENTER: /dc0
   VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
   VSPHERE_FOLDER: /dc0/vm
   VSPHERE_NETWORK: /dc0/network/VM Network
   VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
   VSPHERE_SERVER: xxx.xxx.xxx.xxx
   VSPHERE_USERNAME: [email protected]
   VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
   VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
   VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
   VSPHERE_WORKER_MEM_MIB: "8192"
   VSPHERE_WORKER_NUM_CPUS: "4"
   VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.0"       # change it to the version in TKG BOM
   NAMESPACE: "tkg-system"                       # DO NOT change it
   

4. Utilisez ytt pour générer le manifeste ClusterClass de base pour votre plate-forme cible.

   vSphere

   ytt -f providers/infrastructure-vsphere/v1.7.0/cconly -f providers/config_default.yaml -f user_input.yaml
   

   AWS

   ytt -f providers/infrastructure-aws/v2.1.3/cconly -f providers/config_default.yaml -f user_input.yaml
   

   Azure

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

Maintenant que vous avez généré un manifeste de base pour votre infrastructure, reportez-vous à la section Personnaliser votre manifeste ClusterClass de base pour les étapes suivantes.

Personnaliser votre manifeste ClusterClass de base

Pour personnaliser votre manifeste ClusterClass, créez des fichiers de superposition ytt avec le manifeste. L'exemple suivant montre comment modifier un paramètre de noyau Linux dans la définition clusterClass.

1. Créez un dossier custom structuré comme suit :

   tree custom
   custom
   |-- overlays
       |-- filter.yaml
       |-- kernels.yaml
   

2. Modifiez custom/overlays/kernels.yaml.

   Par exemple, ajoutez nfConntrackMax comme variable et définissez un correctif pour cet élément qui ajoute sa valeur au paramètre de noyau net.netfilter.nf_conntrack_max pour les nœuds de plan de contrôle.

   Cette superposition ajoute une commande au champ preKubeadmCommands, pour écrire la configuration dans sysctl.conf. Pour que le paramètre prenne effet, ajoutez la commande sysctl -p pour appliquer cette modification. Les définitions ClusterClass par défaut sont immuables. Par conséquent, cette superposition modifie également le nom de votre ClusterClass personnalisée et de tous ses modèles en ajoutant -extended.

   cat custom/overlays/kernels.yaml
   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.subset({"kind":"ClusterClass"})
   ---
   apiVersion: cluster.x-k8s.io/v1beta1
   kind: ClusterClass
   metadata:
     name: tkg-vsphere-default-v1.1.0-extended
   spec:
     variables:
     - name: nfConntrackMax
       required: false
       schema:
         openAPIV3Schema:
           type: string
     patches:
     - name: nfConntrackMax
       enabledIf: '{{ not (empty .nfConntrackMax) }}'
       definitions:
         - selector:
             apiVersion: controlplane.cluster.x-k8s.io/v1beta1
             kind: KubeadmControlPlaneTemplate
             matchResources:
               controlPlane: true
           jsonPatches:
             - op: add
               path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
               valueFrom:
                 template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
             - op: add
               path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
               value: sysctl -p
   

3. Supprimez les ressources que vous ne souhaitez pas modifier.

   Dans cet exemple, tous les modèles sont destinés à être partagés entre la ClusterClass personnalisée et celle par défaut afin de tous les supprimer. Vous pouvez également créer un modèle personnalisé selon le modèle par défaut de la même manière et, dans ce cas, vous devez vous assurer que la valeur kind n'est pas exclue.

   cat custom/overlays/filter.yaml
   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.not_op(overlay.subset({"kind": "ClusterClass"})),expects="0+"
   ---
   #@overlay/remove
   

4. Utilisez le manifeste ClusterClass par défaut pour générer la ClusterClass de base.

   ytt -f tkg-vsphere-default-v1.1.0.yaml -f custom/overlays/filter.yaml > default_cc.yaml
   

5. Générez la ClusterClass personnalisée.

   ytt -f tkg-vsphere-default-v1.1.0.yaml -f custom/ > custom_cc.yaml
   

6. (Facultatif) Vérifiez la différence entre la ClusterClass par défaut et votre classe personnalisée pour confirmer que les modifications ont été appliquées.

   diff default_cc.yaml custom_cc.yaml
   

   La sortie doit ressembler à ceci :

   4c4
   <   name: tkg-vsphere-default-v1.1.0
   ---
   >   name: tkg-vsphere-default-v1.1.0-extended
   638a639,643
   >   - name: nfConntrackMax
   >     required: false
   >     schema:
   >       openAPIV3Schema:
   >         type: string
   2607a2613,2628
   >   - name: nfConntrackMax
   >     enabledIf: '{{ not (empty .nfConntrackMax) }}'
   >     definitions:
   >     - selector:
   >         apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   >         kind: KubeadmControlPlaneTemplate
   >         matchResources:
   >           controlPlane: true
   >       jsonPatches:
   >       - op: add
   >         path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
   >         valueFrom:
   >           template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
   >       - op: add
   >         path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
   >         value: sysctl -p
   

Dans cet exemple, vous pouvez constater que la valeur -extended a été ajoutée au nom du cluster.

Installer la ClusterClass personnalisée dans le cluster de gestion

Pour permettre à votre cluster de gestion d'utiliser votre ClusterClass personnalisée, installez-la en appliquant le nouveau manifeste.

1. Appliquez le manifeste ClusterClass.

   kubectl apply -f custom_cc.yaml
   

   La sortie suivante doit s'afficher.

   clusterclass.cluster.x-k8s.io/tkg-vsphere-default-v1.1.0-extended created
   

2. Vérifiez si la ClusterClass personnalisée s'est propagée à l'espace de noms par défaut, par exemple :

   kubectl get clusterclass
   

   La sortie suivante doit s'afficher.

   NAME                                  AGE
   tkg-vsphere-default-v1.1.0            2d23h
   tkg-vsphere-default-v1.1.0-extended   11s
   

Générer le manifeste de cluster de charge de travail personnalisé

Lorsque vous créez votre ClusterClass personnalisée, vous pouvez l'utiliser pour créer un cluster de charge de travail qui inclut votre personnalisation.

1. Exécutez tanzu cluster create avec l'option --dry-run pour générer un manifeste de cluster à partir du fichier de configuration du cluster standard :

   tanzu cluster create --file workload-1.yaml --dry-run > default_cluster.yaml
   

2. Créez une superposition ytt ou modifiez directement le manifeste du cluster.

   Il est recommandé de créer une superposition ytt, par exemple cluster_overlay.yaml, pour effectuer les opérations suivantes :

   • Remplacez la valeur topology.class par le nom de votre ClusterClass personnalisée.
   • Ajoutez vos variables personnalisées au bloc variables, avec une valeur par défaut.

   Comme pour la modification des spécifications d'objets ClusterClass, l'utilisation d'une superposition comme suit vous permet d'appliquer automatiquement les modifications aux nouveaux objets à chaque nouvelle version de cluster en amont.

   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.subset({"kind":"Cluster"})
   ---
   apiVersion: cluster.x-k8s.io/v1beta1
   kind: Cluster
   spec:
     topology:
       class: tkg-vsphere-default-v1.1.0-extended
       variables:
       - name: nfConntrackMax
         value: "1048576
   

3. Générez le manifeste custom_cluster.yaml :

   ytt -f default_cluster.yaml -f cluster_overlay.yaml > custom_cluster.yaml
   

4. (Facultatif) Comme avec la ClusterClass ci-dessus, vous pouvez exécuter diff pour comparer votre manifeste de cluster de classe personnalisée avec un cluster basé sur une classe par défaut, par exemple :

   diff custom_cluster.yaml default_cluster.yaml
   

   La sortie doit ressembler à ceci :

   <     class: tkg-vsphere-default-v1.1.0
   ---
   >     class: tkg-vsphere-default-v1.1.0-extended
   142a143,144
   >     - name: nfConntrackMax
   >       value: "1048576"
   

Créer un cluster personnalisé

Créez un cluster de charge de travail personnalisé basé sur le manifeste personnalisé généré ci-dessus comme suit.

1. Créez le cluster.

   tanzu cluster create -f custom_cluster.yaml
   

2. Vérifiez les propriétés de l'objet créé.

   Par exemple, avec la modification du noyau ci-dessus, récupérez l'objet KubeadmControlPlane et confirmez que la configuration du noyau est définie :

   kubectl get kcp workload-1-jgwd9 -o yaml
   

   La sortie doit ressembler à ceci :

   apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   kind: KubeadmControlPlane
   ...
       preKubeadmCommands:
       - hostname "{{ ds.meta_data.hostname }}"
       - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
       - echo "127.0.0.1   localhost" >>/etc/hosts
       - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
       - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
       - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
       - sysctl -p
   ...
   

3. Connectez-vous à un nœud de plan de contrôle et confirmez que son sysctl.conf est modifié :

   capv@workload-1-jgwd9:~$ sudo cat /etc/sysctl.conf
   ...
   net.ipv6.neigh.default.gc_thresh3=16384
   fs.file-max=9223372036854775807
   net.netfilter.nf_conntrack_max=1048576
   

Mettre à niveau des clusters personnalisés

Si vous avez créé des clusters personnalisés avec une version précédente, vous pouvez les mettre à niveau vers la dernière version de TKG.

Préparer la mise à niveau des clusters

Avant de mettre à niveau les clusters, vous devez effectuer les étapes de préparation.

1. Avant de mettre à niveau le cluster de gestion, créez des clusters de test avec la version du manifeste personnalisé que vous avez créé pour la version précédente.

   Par exemple, créez un cluster personnalisé nommé test-upgrade.

2. Obtenez des informations sur les versions de ClusterClass disponibles avec votre cluster de gestion TKG 2.2.

   kubectl get clusterclass
   

   Si vous avez créé les clusters personnalisés avec TKG v2.2.0, la version de ClusterClass doit être 1.0.0. Par exemple :

   NAME                                  AGE
   tkg-vsphere-default-extended-v1.0.0   21m
   tkg-vsphere-default-v1.0.0            10d
   

3. Obtenez les informations sur les versions de ClusterClass exécutées dans votre cluster test-upgrade.

   kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
   

   La sortie doit contenir tkg-vsphere-default-extended-v1.0.0.

4. Suivez les instructions de la section Mettre à niveau les clusters de gestion autonomes pour mettre à niveau le cluster de gestion vers TKG 2.3.

5. Obtenez des informations sur la version de ClusterClass disponible lorsque vous mettez à niveau le cluster de gestion vers la version v.2.3.

   kubectl get cluster mgmt-cluster-name -n tkg-system -o jsonpath='{.spec.topology.class}'
   

   La sortie doit être tkg-vsphere-default-v1.1.0 si le cluster de gestion s'exécute sur vSphere.

6. Suivez les procédures décrites dans la section Créer un manifeste ClusterClass de base et Personnaliser votre manifeste ClusterClass de base pour créer une version de votre manifeste ClusterClass.
   • Par exemple, nommez la nouvelle ClusterClass personnalisée tkg-vsphere-default-v1.1.0-extended et incluez les mêmes variables personnalisées que dans l'ancienne version tkg-vsphere-default-extended-v1.0.0.
   • Nommez la nouvelle superposition custom_cc.yaml.

7. Installez la nouvelle ClusterClass personnalisée dans le cluster de gestion.

   kubectl apply -f custom_cc.yaml
   

8. Obtenez des informations sur les versions de ClusterClass qui sont désormais disponibles avec votre cluster de gestion.

   kubectl get clusterclass
   

   Les versions les plus anciennes et les plus récentes doivent s'afficher.

   NAME                                  AGE
   tkg-vsphere-default-extended-v1.0.0   61m
   tkg-vsphere-default-v1.0.0            10d
   tkg-vsphere-default-v1.1.0            25m
   tkg-vsphere-default-v1.1.0-extended   15s
   

Effectuer la mise à niveau

Une fois les étapes de préparation effectuées, vous pouvez tester la mise à niveau sur le cluster de test avant de mettre à niveau vos clusters de production.

1. Rebasez le cluster test-upgrade de l'ancienne version de la ClusterClass personnalisée vers la nouvelle.

   kubectl patch cluster test-upgrade --type merge -p '{"spec": {"topology": {"class": "tkg-vsphere-default-v1.1.0-extended"}}}'   
   

   La sortie doit contenir cluster.cluster.x-k8s.io/test-upgrade patched.

2. Obtenez les informations sur la version de ClusterClass en cours d'exécution dans votre cluster test-upgrade.

   kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
   

   La sortie doit contenir tkg-vsphere-default-v1.1.0-extended. Auparavant, il s'agissait de la version tkg-vsphere-default-extended-v1.0.0.

3. Attendez plusieurs minutes et exécutez kubectl get cluster jusqu'à ce que UpdatesAvailable soit mis à jour vers true.

   kubectl get cluster test-upgrade -o yaml
   

   Lorsque vous êtes prêt, un message semblable au suivant doit s'afficher dans la sortie :

   ...
   status:
     conditions:
   ...
     - lastTransitionTime: "2023-06-19T09:59:21Z"
       message: '[v1.25.9+vmware.1-tkg.1-20230609 v1.26.4+vmware.1-tkg.1-20230609]'
       status: "True"
       type: UpdatesAvailable
     controlPlaneReady: true
     infrastructureReady: true
     observedGeneration: 5
     phase: Provisioned
   

4. Mettez à niveau le cluster test-upgrade.

   tanzu cluster upgrade test-upgrade    
   

5. Vérifiez les propriétés de l'objet créé.

   Par exemple, avec la modification du noyau décrite dans l'exemple ci-dessus, récupérez l'objet KubeadmControlPlane et confirmez que la configuration du noyau est définie :

   kubectl get kcp test-upgrade-nsc6d -o yaml
   

   La sortie doit ressembler à ceci :

   apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   kind: KubeadmControlPlane
   ...
       preKubeadmCommands:
       - hostname "{{ ds.meta_data.hostname }}"
       - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
       - echo "127.0.0.1   localhost" >>/etc/hosts
       - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
       - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
       - sed -i 's|".*/pause|"projects-stg.registry.vmware.com/tkg/pause|' /etc/containerd/config.toml
       - systemctl restart containerd
       - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
       - sysctl -p  
   

Mettre à niveau des clusters de production

Si le test de mise à niveau est réussi, répétez les étapes de la section Effectuer la mise à niveau sur vos clusters de production.

Remarque

Si vous rencontrez des erreurs pendant la mise à niveau, vous pouvez effectuer une restauration en rebasant le cluster de la nouvelle version de la ClusterClass personnalisée vers l'ancienne version.

Rebaser un cluster par défaut pour utiliser une ClusterClass personnalisée

Si vous avez créé des clusters avec la ClusterClass par défaut et que vous souhaitez les mettre à jour pour utiliser une ClusterClass personnalisée, utilisez kubectl pour modifier l'objet Cluster :

• Remplacez spec.topology.class par le nom de votre manifeste ClassClass personnalisé.
• Modifiez spec.topology.variables pour ajouter vos variables personnalisées.

Rebaser un cluster personnalisé pour utiliser la ClusterClass par défaut

Pour restaurer une nouvelle version de la ClusterClass par défaut :

• Remplacez spec.topology.class par la nouvelle version de la ClusterClass par défaut.
• Modifiez spec.topology.variables pour supprimer vos variables personnalisées. Vous devrez peut-être ajouter de nouvelles variables qui sont définies dans la nouvelle version de la ClusterClass par défaut.