Reportez-vous à ces instructions pour provisionner un cluster TKG basé sur une ClusterClass personnalisée. Notez que ces instructions sont spécifiques aux environnements vSphere 8 U2 et ultérieurs.

Conditions requises

La procédure de provisionnement d'un cluster TKG basé sur une ClusterClass personnalisée est mise à jour pour la version vSphere 8 U2.

Respectez les conditions préalables suivantes.
  • Environnement vSphere 8 U2 et versions ultérieures
  • Gestion de la charge de travail activée
  • Superviseur configuré
  • Client Ubuntu avec Outils de l'interface de ligne de commande Kubernetes pour vSphere installé
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.

Workflows de haut niveau

Les workflows de haut niveau sont les suivants.

Le workflow suivant est tout ce dont vous avez besoin pour commencer.
Étape Tâche Instructions
1 Créez une ClusterClass personnalisée en clonant la ClusterClass par défaut. 1 : Créer une ClusterClass personnalisée
2 Provisionnez un nouveau cluster TKG basé sur la ClusterClass personnalisée et vérifiez que tous les nœuds du cluster s'activent correctement. 2 : Créer un cluster TKG basé sur la ClusterClass personnalisée
Reportez-vous au workflow suivant pour apporter des modifications à la ClusterClass personnalisée et initier une mise à jour continue des nœuds de cluster ClusterClass personnalisés.
Note : L'opération illustrée dans le workflow ci-dessous est un exemple de ce que vous pouvez faire sur une ClusterClass personnalisée. Vos cas d'utilisation peuvent différer, mais le workflow général doit être applicable.
Étape Tâche Instructions
3 Connectez-vous via SSH à l'un des nœuds worker pour confirmer qu'il existe des modules à mettre à jour. 3 : Vérifier l'existence des mises à jour du module
4 Mettez à jour la ClusterClass personnalisée avec une nouvelle commande qui effectue les mises à jour. 4 : Mettre à jour la ClusterClass personnalisée
5 Confirmez le déploiement de nouveaux nœuds avec les mises à jour déjà en cours d'exécution. 5 : Vérifier la mise à jour continue des nœuds de cluster

1 : Créer une ClusterClass personnalisée

La première partie implique la création d'une ClusterClass personnalisée nommée ccc (abréviation de customclusterclass) en clonant la ClusterClass par défaut nommée tanzukubernetescluster.
Note : Le nom ClusterClass personnalisé est défini par l'utilisateur. Si vous utilisez un autre nom, modifiez les instructions de manière appropriée.
  1. Créez et configurez un Espace de noms vSphere nommé ccc-ns.

    Configurez les autorisations, le stockage, la bibliothèque de contenu et les classes de machine virtuelle. Reportez-vous à la documentation selon vos besoins.

    Note : Le nom de l' Espace de noms vSphere est défini par l'utilisateur. Si vous utilisez un autre nom, modifiez les instructions de manière appropriée.
  2. Connectez-vous à Superviseur.
    kubectl vsphere login --server=IP-ADDRESS --vsphere-username [email protected]
  3. Écrivez la sortie de la ClusterClass par défaut dans un fichier nommé ccc.yaml.
    kubectl -n ccc-ns get clusterclass tanzukubernetescluster -o yaml > ccc.yaml
    Ou, la version du raccourci : 
    kubectl -n ccc-ns get cc tanzukubernetescluster -o yaml > ccc.yaml
  4. Ouvrez pour modifier le fichier ClusterClass cloné.
    vim ccc.yaml
  5. Modifiez le fichier ccc.yaml.
    • Supprimez la ligne metadata.creationTimestamp
    • Supprimez la ligne metadata.generation
    • Supprimez la ligne metadata.resourceVersion
    • Supprimez la ligne metadata.uid
    • Modifiez la valeur de metadata.name de tanzukubernetescluster à ccc
    • Laissez la valeur metadata.namespace telle qu'elle est : ccc-ns
    • Laissez la valeur metadata.annotations telle qu'elle est pour run.tanzu.vmware.com/resolve-tkr: "". Cette annotation est requise pour la résolution/les données de TKR.
  6. Enregistrez et vérifiez les modifications.
    apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
  annotations:
    run.tanzu.vmware.com/resolve-tkr: ""
  name: ccc
  namespace: ccc-ns
spec:
...
  7. Créez l'objet ClusterClass personnalisé.
    kubectl apply -f ccc.yaml -n ccc-ns
    Résultat attendu : 
    clusterclass.cluster.x-k8s.io/ccc created
  8. Répertoriez la ClusterClass personnalisée.
    kubectl get cc -n ccc-ns
    Résultat attendu : 
    NAME                     AGE
ccc                      3m14s
tanzukubernetescluster   29m

2 : Créer un cluster TKG basé sur la ClusterClass personnalisée

Utilisez l' API de cluster v1beta1 pour créer un cluster basé sur une ClusterClass.
  1. Construisez le manifeste ccc-cluster.yaml pour provisionner le cluster.
    #ccc-cluster.yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: ccc-cluster
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.0.2.0/16
    services:
      cidrBlocks:
      - 198.51.100.0/12
    serviceDomain: cluster.local
  topology:
    class: ccc
    version: v1.26.5---vmware.2-fips.1-tkg.1
    controlPlane:
      replicas: 1
    workers:
      machineDeployments:
        - class: node-pool
          name: tkgs-node-pool-1
          replicas: 1
    variables:
    - name: vmClass
      value: guaranteed-small
    - name: storageClass
      value: tkg-storage-profile
    Où :
    • La valeur metadata.name est le nom du cluster : ccc-cluster
    • La valeur spec.topology.class est le nom de la ClusterClass personnalisée : ccc
    • La valeur spec.topology.version est la version TKR
    • La valeur spec.topology.variables.storageClass est le nom de la classe de stockage persistant
    Note : À des fins de test, 1 réplica est suffisant pour le plan de contrôle et le pool de nœuds worker. En production, utilisez 3 réplicas pour le plan de contrôle et au moins 3 réplicas pour chaque pool de nœuds worker.
  2. Créez le cluster TKG en fonction de la ClusterClass personnalisée.
    kubectl apply -f ccc-cluster.yaml -n ccc-ns
    Résultat attendu : 
    cluster.cluster.x-k8s.io/ccc-cluster created
  3. Vérifiez le provisionnement du cluster.
    Exécutez la commande suivante. Attendez que tous les nœuds du cluster s'activent correctement. 
    kubectl -n ccc-ns get cc,clusters,vsphereclusters,kcp,machinedeployment,machineset,machine,vspheremachine,virtualmachineservice
    Note : Il sera utile d'exécuter cette commande dans une session distincte afin de pouvoir surveiller la progression de la mise à jour continue à l'étape 5.

3 : Vérifier l'existence des mises à jour du module

Connectez-vous via SSH à l'un des nœuds worker pour confirmer qu'il existe des modules à mettre à jour.
Note : L'objectif de cette étape est simplement de vérifier qu'il existe des modules à mettre à jour, pas de les mettre à jour réellement. Ils seront mis à jour par la ClusterClass personnalisée lors du déploiement de nouveaux nœuds de cluster (étapes suivantes). Cette étape et celles qui suivent sont un exemple de ce que vous pouvez faire sur une ClusterClass personnalisée.
  1. Exécutez la commande suivante pour obtenir le secret SSH.
    export CC=ccc-cluster && kubectl get secret -n ccc-ns ${CC}-ssh -o jsonpath={.data.ssh-privatekey} | base64 -d > ${CC}-ssh && chomd 4000 ${CC}-ssh
  2. Exécutez la commande suivante pour obtenir l'adresse IP de la machine virtuelle du nœud worker.
    kubectl -n ccc-ns get vm -o wide
    Note : Si vous avez déployé plusieurs nœuds worker, choisissez-en un. N'utilisez pas de nœud de plan de contrôle.
  3. Exécutez la commande suivante pour vous connecter via SSH à la machine virtuelle du nœud worker.
    ssh -i ${CC}-ssh vmware-system-user@IP-ADDRESS-OF-WORKER-NODE
    Par exemple : 
    ssh -i ${CC}-ssh [email protected]
    Note : Entrez « oui » pour continuer la connexion.
    Résultat attendu : après l'utilisation de SSH dans l'hôte, le message suivant doit s'afficher. 
    tdnf update info not availble yet!
  4. Exécutez les commandes suivantes et recherchez les mises à jour.
    sudo -i
    tdnf update
  5. À l'invite, entrez « N » pour non (ne pas mettre à jour).
    Résultat attendu : 
    Operation aborted
    Note : L'objectif ici est simplement de vérifier l'existence des mises à jour, pas de lancer des mises à jour. Vous allez lancer les mises à jour en ajoutant une commande à la ClusterClass personnalisée dans la section suivante.
  6. Tapez « exit » pour vous déconnecter de la session SSH, puis tapez de nouveau « exit ».

4 : Mettre à jour la ClusterClass personnalisée

Mettez à jour la ClusterClass personnalisée avec une nouvelle commande qui effectue une mise à jour tdnf.
  1. Ouvrez pour modifier la ClusterClass personnalisée nommée ccc.
    kubectl edit cc ccc -n ccc-ns
  2. Faites défiler l'écran vers le bas jusqu'à la section suivante avec postKubeadmCommands.
      - definitions:
    - jsonPatches:
      - op: add
        path: /spec/template/spec/kubeadmConfigSpec/postKubeadmCommands
        valueFrom:
          template: |
            - touch /root/kubeadm-complete
            - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
            - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
      selector:
        apiVersion: controlplane.cluster.x-k8s.io/v1beta1
        kind: KubeadmControlPlaneTemplate
        matchResources:
          controlPlane: true
    - jsonPatches:
      - op: add
        path: /spec/template/spec/postKubeadmCommands
        valueFrom:
          template: |
            - touch /root/kubeadm-complete
            - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
            - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
      selector:
        apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
        kind: KubeadmConfigTemplate
        matchResources:
          machineDeploymentClass:
            names:
            - node-pool
    name: controlPlanePostKubeadmCommandsSuccess
    Ajoutez la commande suivante aux champs valueFrom.template. 
    - tdnf update -y
    Par exemple : 
      - definitions:
    - jsonPatches:
      - op: add
        path: /spec/template/spec/kubeadmConfigSpec/postKubeadmCommands
        valueFrom:
          template: |
            - touch /root/kubeadm-complete
            - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
            - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
            - tdnf update -y
      selector:
        apiVersion: controlplane.cluster.x-k8s.io/v1beta1
        kind: KubeadmControlPlaneTemplate
        matchResources:
          controlPlane: true
    - jsonPatches:
      - op: add
        path: /spec/template/spec/postKubeadmCommands
        valueFrom:
          template: |
            - touch /root/kubeadm-complete
            - vmware-rpctool 'info-set guestinfo.kubeadm.phase complete'
            - vmware-rpctool 'info-set guestinfo.kubeadm.error ---'
            - tdnf update -y
      selector:
        apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
        kind: KubeadmConfigTemplate
        matchResources:
          machineDeploymentClass:
            names:
            - node-pool
    name: controlPlanePostKubeadmCommandsSuccess
  3. Enregistrez les modifications apportées à la ClusterClass personnalisée et fermez l'éditeur.
    wq
    Résultat attendu : 
    clusterclass.cluster.x-k8s/ccc edited

5 : Vérifier la mise à jour continue des nœuds de cluster

La mise à jour de la ClusterClass personnalisée déclenche une mise à jour continue des nœuds de cluster pour les clusters provisionnés en fonction de cette ClusterClass. Les nouveaux nœuds ont été appliqués avec la commande ci-dessus.
  1. Vérifiez le provisionnement du cluster en exécutant la commande suivante.
    Attendez que tous les nœuds du cluster s'activent correctement. 
    kubectl -n ccc-ns get cc,clusters,vsphereclusters,kcp,machinedeployment,machineset,machine,vspheremachine,virtualmachineservice
  2. Vous devez voir que les nouveaux nœuds, avec de nouveaux UUID, sont déployés.
  3. Exécutez la commande suivante pour vous connecter via SSH à la machine virtuelle du nœud worker.
    ssh -i ${CC}-ssh vmware-system-user@IP-ADDRESS-OF-WORKER-NODE
    Résultat attendu : après l'utilisation de SSH dans l'hôte, le message suivant doit s'afficher. 
    tdnf update info not availble yet!
  4. Exécutez les commandes suivantes :
    sudo -i
    tdnf update

    Résultat attendu : vous devez voir beaucoup moins de modules qui doivent être mis à jour.

  5. À l'invite, entrez « N » pour non (ne pas mettre à jour).
    Résultat attendu : 
    Operation aborted
  6. Exécutez la commande suivante pour confirmer que tdnf a été exécuté.
    cat /var/log/cloud-init-output.log | grep -i tdnf
  7. Tapez « exit » pour vous déconnecter de la session SSH, puis tapez de nouveau « exit ».

Maintenance d'une ClusterClass personnalisée

Après la mise à niveau du Service TKG vers une nouvelle version, vous devez vous assurer que votre ClusterClass personnalisée dérivée de la ClusterClass par défaut à partir de la précédente version du Service TKG est mise à jour avec les modifications apportées à la ClusterClass par défaut fournie avec la nouvelle version du Service TKG.

Utilisez le workflow suivant pour conserver votre ClusterClass personnalisée synchronisée avec la ClusterClass fournie par le système. Notez que ces instructions supposent que vous avez créé une ClusterClass personnalisée initiale comme décrit dans le présent document.
  1. Mettre à niveau la version du Service TKG.

    Par exemple, mettez à niveau le Service TKG de la version 3.0 vers la version 3.1.

    Reportez-vous à la section Installation et mise à niveau du Service TKG.

  2. Créez une ClusterClass personnalisée en suivant les instructions de ce document.

    Modifiez manuellement la nouvelle ClusterClass personnalisée en ajoutant à son nom la version du Service TKG, telle que ccc-3.1.

  3. Ajoutez les correctifs et variables personnalisés de la ClusterClass personnalisée précédente à la nouvelle ClusterClass personnalisée.

    Pour ce faire, cat ccc.yaml et copiez les correctifs et variables personnalisés à partir de celui-ci dans ccc-3.1.yaml.

  4. Appliquez la nouvelle classe ClusterClass personnalisée et attendez que le rapprochement réussisse.
  5. Mettez à jour les clusters TKG à l'aide de la classe ClusterClass personnalisée précédente vers la nouvelle clusterClass personnalisée en modifiant le champ spec.topology.class dans l'objet de cluster.

ClusterClass non gérée

Pour vSphere 8 U2 et versions ultérieures, vous pouvez ajouter une annotation à une ClusterClass personnalisée si vous ne souhaitez pas que le contrôleur TKG gère la ClusterClass personnalisée. Sachez que si vous ajoutez cette annotation, vous êtes responsable de la création manuelle de tous les objets Kubernetes sous-jacents, tels que les certificats, les secrets, etc. Reportez-vous à la documentation du clusterClass vSphere 8 U1 personnalisé pour obtenir des instructions à ce sujet.

L'annotation est la suivante :
Clé d'annotation Valeur
run.tanzu.vmware.com/unmanaged-clusterclass «   »
Voici un exemple d'ajout de l'annotation à la ClusterClass personnalisée nommée ccc : 
apiVersion: cluster.x-k8s.io/v1beta1
kind: ClusterClass
metadata:
  annotations:
    run.tanzu.vmware.com/resolve-tkr: ""
    run.tanzu.vmware.com/unmanaged-clusterclass: ""
  name: ccc
  namespace: ccc-ns
spec:
...