Configuration de cluster hérité avec ytt

Cette rubrique décrit comment utiliser des superpositions ytt pour configurer des clusters de charge de travail basés sur TKC hérités et sur un plan déployés par Tanzu Kubernetes Grid (TKG), ceci afin de définir des propriétés de cluster et d'objet sous-jacentes qui ne sont pas définies par des variables de configuration dans un fichier de configuration de cluster, comme indiqué dans la section Configurer un cluster déployé par un superviseur avec un fichier de configuration pour les clusters TKC ou Référence de variable de fichier de configuration pour les clusters basés sur un plan.

Pour plus d'informations sur le téléchargement et l'installation de ytt, reportez-vous à la section Installer les outils Carvel.

Les superpositions ytt ne sont pas nécessaires et ne sont pas prises en charge pour les clusters basés sur une classe, pour lesquels toutes les propriétés configurables peuvent être définies à un niveau élevé dans l'objet Cluster simplifié lui-même. Si la CLI Tanzu détecte ytt sur votre machine lors de l'exécution de tanzu cluster create pour un cluster basé sur une classe, elle génère une erreur It seems like you have done some customizations to the template overlays.

Présentation

Dans le cadre de la configuration avancée des clusters de charge de travail basés sur TKC et sur un plan, pour définir des propriétés d'objet qui ne peuvent pas être définies par des variables de configuration de cluster, vous pouvez personnaliser les fichiers de configuration TKC, du cluster basé sur un plan et du plan de cluster dans le répertoire local ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere de n'importe quelle machine de démarrage.

Vous pouvez personnaliser ces configurations en ajoutant ou en modifiant des fichiers de configuration directement ou en utilisant des superpositions ytt.

La personnalisation directe des fichiers de configuration est plus simple, mais si vous êtes à l'aise avec les superpositions ytt, celles-ci vous permettent de personnaliser les configurations à différentes portées et de gérer plusieurs fichiers de configuration modulaires, sans modifier de manière destructrice les valeurs de configuration en amont et héritées. Les superpositions ytt s'appliquent uniquement aux nouveaux clusters de charge de travail basés sur TKC et un plan créés à l'aide de la CLI Tanzu.

Pour obtenir plus d'informations sur le fonctionnement et la priorité des différentes formes de configuration du cluster, reportez-vous à la section À propos du TKC hérité et de la configuration du cluster basée sur un plan dans À propos de Tanzu Kubernetes Grid.

Comportement et conventions de `ytt`

Les comportements et conventions de traitement de ytt sont les suivants :

Priorité (Precedence) : ytt traverse d'abord la profondeur des répertoires dans l'ordre alphabétique des noms de fichier et remplace au fur et à mesure les paramètres dupliqués. Lorsqu'il existe des définitions en double, celle que ytt traite en dernier est prioritaire.

Types de superpositions (Overlay Types) : les différents types de superposition ytt changent ou définissent des éléments différents :

Les fichiers de valeurs de données (Data values files) définissent ou modifient des valeurs de configuration sans modifier les structures des objets. Il s'agit notamment des fichiers de nomenclature et, par convention, des fichiers avec data dans leurs noms.
Les fichiers de superposition (Overlay files) apportent des modifications aux définitions de structure d'objets. Par convention, ces fichiers ont overlay dans leurs noms.

Pour plus d'informations sur ytt, y compris pour obtenir des exemples de superposition et un outil de validation interactif, reportez-vous à :

Outils Carvel (Carvel Tools) > ytt > Interactive Playground
The IT Hollow: Using YTT to Customize TKG Deployments

Clusters et plans de cluster

Pour les clusters basés sur TKC et sur un plan, le répertoire ~/.config/tanzu/tkg/providers/ de la machine de démarrage inclut les répertoires ytt et les fichiers overlay.yaml à différents niveaux, ce qui vous permet de définir la portée des paramètres de configuration à chaque niveau.

Répertoires ytt spécifiques au fournisseur et à la version. Par exemple, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0.
- Configurations spécifiques pour la version de l'API du fournisseur.
- Le fichier base-template.yaml contient des espaces réservés intégralement majuscules tels que "${CLUSTER_NAME}" et ne doit pas être modifié.
- Le fichier overlay.yaml est adapté aux valeurs de superposition dans base-template.yaml.
Répertoires ytt à l'échelle du fournisseur. Par exemple, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
- Configurations à l'échelle du fournisseur qui s'appliquent à toutes les versions.
Répertoire ytt de niveau supérieur, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
- Configurations pour différents fournisseurs.
- Organisés en répertoires numérotés et traités par ordre numérique.
- Vous pouvez créer un sous-répertoire /04_user_customizations pour les configurations prioritaires sur n'importe quel sous-répertoire ytt de numérotation inférieure.

Superpositions `ytt`

Cette section contient des superpositions pour personnaliser des clusters de charge de travail basés sur un plan déployés par un cluster de gestion autonome et pour créer de nouveaux plans de cluster.

Limitations :

Vous pouvez utiliser uniquement des superpositions ytt pour modifier les clusters de charge de travail. L'utilisation de superpositions ytt pour modifier des clusters de gestion autonomes n'est pas prise en charge.
Les superpositions de clusters de charge de travail sont appliquées uniquement lors de la création du cluster et ne modifient pas les clusters existants. Reportez-vous à la section Modification des ressources dans les clusters existants pour savoir comment modifier les clusters existants.

Les exemples suivants montrent comment utiliser les fichiers de superposition de configuration pour personnaliser les clusters de charge de travail et créer un plan de cluster.

Pour une superposition qui personnalise les certificats approuvés dans un cluster, reportez-vous à la section Configurer des clusters avec plusieurs registres approuvés du document Gérer les secrets et les certificats de cluster.

Serveurs de noms sur vSphere

Cet exemple ajoute un ou plusieurs serveurs de noms personnalisés aux nœuds worker et de plan de contrôle dans les clusters Tanzu Kubernetes Grid hérités sur vSphere. Il désactive la résolution DNS depuis DHCP afin que les serveurs de noms personnalisés soient prioritaires.

Pour configurer des serveurs de noms personnalisés dans un cluster basé sur une classe, utilisez les variables de configuration CONTROL_PLANE_NODE_NAMESERVERS et WORKER_NODE_NAMESERVERS.

Deux fichiers de superposition s'appliquent aux nœuds de plan de contrôle et les deux autres s'appliquent aux nœuds worker. Vous ajoutez les quatre fichiers dans votre répertoire ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/.

Les fichiers de superposition varient selon que vos nœuds sont basés sur des images Ubuntu ou Photon Machine. En outre, vous n'avez pas besoin de fichiers de superposition DHCP pour Ubuntu.

Une ligne de chaque fichier overlay-dns définit les adresses du serveur de noms. Le code ci-dessous affiche un serveur de noms unique, mais vous pouvez spécifier plusieurs serveurs de noms sous forme de liste, par exemple nameservers: ["1.2.3.4","5.6.7.8"].

Fichier vsphere-overlay-dns-control-plane.yaml :

Ubuntu :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

Photon :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

Fichier vsphere-overlay-dns-workers.yaml :

Ubuntu :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

Photon :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

Fichier vsphere-overlay-dhcp-control-plane.yaml (Photon uniquement) :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    preKubeadmCommands:
    #! disable dns from being emitted by dhcp client
    #@overlay/append
    - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

Fichier vsphere-overlay-dhcp-workers.yaml (Photon uniquement) :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      preKubeadmCommands:
      #! disable dns from being emitted by dhcp client
      #@overlay/append
      - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

Point de terminaison de plan de contrôle du nom de domaine complet avec NSX ALB

Pour créer des clusters de charge de travail sur vSphere avec NSX Advanced Load Balancer qui sont configurés avec le paramètre VSPHERE_CONTROL_PLANE_ENDPOINT défini sur un nom de domaine complet plutôt qu'une adresse IP, créez un fichier de superposition dans votre répertoire .config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ (tel que fqdn-cert-api.yaml) avec le contenu suivant :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"}), expects="1+"
#@overlay/match-child-defaults missing_ok=True
---

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: #@ "{}-control-plane".format(data.values.CLUSTER_NAME)
spec:
  kubeadmConfigSpec:
    clusterConfiguration:
      apiServer:
        certSANs:
        - CONTROLPLANE-FQDN

Où CONTROLPLANE-FQDN est le nom de domaine complet de votre plan de contrôle du cluster de charge de travail.

Une fois la superposition en place, créez le cluster.

Lorsque vous créez le cluster, suivez la procédure Configurer les réservations DHCP de nœuds et l'enregistrement DNS du point de terminaison (vSphere uniquement) pour créer un enregistrement DNS.

Avant de créer chaque cluster supplémentaire avec un point de terminaison de nom de domaine complet, modifiez le paramètre CONTROLPLANE-FQDN dans la superposition si nécessaire.

Résoudre le domaine .local

Dans les systèmes Linux modernes, les tentatives de résolution des noms d'hôte dont le suffixe de domaine se termine par .local peuvent échouer. Ce problème se produit, car systemd-networkd, le programme de résolution DNS dans la plupart des distributions Linux, tente de résoudre le domaine .local au moyen d'un DNS multidiffusion (mDNS), et non au moyen de serveurs DNS standard.

Pour configurer la résolution de domaine .local dans un cluster basé sur une classe, utilisez les variables de configuration CONTROL_PLANE_NODE_SEARCH_DOMAINS et WORKER_NODE_SEARCH_DOMAINS.

Pour résoudre ce problème connu dans les clusters hérités, ajoutez une ligne searchDomains avec le suffixe de votre domaine local à la fin des fichiers vsphere-overlay-dns-control-plane.yaml et vsphere-overlay-dns-workers.yaml dans le répertoire ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/.

Exemple pour le fichier vsphere-overlay-dns-control-plane.yaml :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

Exemple pour le fichier vsphere-overlay-dns-workers.yaml :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

Configuration de NTP sans option DHCP 42 (vSphere)

L'authentification TLS dans les clusters Tanzu Kubernetes Grid nécessite une synchronisation de l'heure précise. Dans la plupart des environnements basés sur DHCP, vous pouvez configurer la synchronisation à l'aide de l'option DHCP 42.

Si vous déployez des clusters hérités dans un environnement vSphere qui ne dispose pas de l'option DHCP 42, utilisez le code de superposition comme suit pour que Tanzu Kubernetes Grid crée des clusters avec des serveurs NTP qui maintiennent la synchronisation.

Pour configurer NTP dans un cluster basé sur une classe, utilisez la variable de configuration NTP_SERVERS.

Dans ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, créez un fichier .yaml ou augmentez un fichier de superposition existant avec le code suivant, en modifiant l'exemple time.google.com sur le serveur NTP souhaité :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    #@overlay/match missing_ok=True
    ntp:
      #@overlay/match missing_ok=True
      enabled: true
      #@overlay/match missing_ok=True
      servers:
        - time.google.com

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      ntp:
        #@overlay/match missing_ok=True
        enabled: true
        #@overlay/match missing_ok=True
        servers:
          - time.google.com

Étiquettes de nœuds personnalisées

Cette superposition attribue des étiquettes persistantes aux nœuds de cluster lors de la création du cluster hérité. Cela est utile, car les étiquettes appliquées manuellement via kubectl ne sont pas conservées lors du remplacement du nœud.

Reportez-vous à la section Variables supplémentaires dans les superpositions ytt.

Pour configurer des étiquettes de nœud personnalisées pour les nœuds de plan de contrôle dans un cluster basé sur une classe, utilisez la variable de configuration CONTROL_PLANE_NODE_LABELS.

Dans le répertoire ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, créez un fichier .yaml ou augmentez un fichier de superposition existant avec le code suivant.

Pour les étiquettes de nœud de plan de contrôle, configurez les sections initConfiguration et joinConfiguration afin que les étiquettes soient appliquées au premier nœud créé et à tous les nœuds qui se joignent après :
```
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    initConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS
    joinConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS
```
Où NODE-LABELS est une liste de chaînes clé/valeur d'étiquette séparées par des virgules qui inclut node-type=control-plane, par exemple "examplekey1=labelvalue1,examplekey2=labelvalue2".

Pour les étiquettes de nœud worker :
```
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: NODE-LABELS
```
Où NODE-LABELS est une liste de chaînes clé/valeur d'étiquette séparées par des virgules qui inclut node-type=worker, par exemple "examplekey1=labelvalue1,examplekey2=labelvalue2".

Désactiver l'hôte bastion sur AWS

Pour obtenir un exemple de superposition qui désactive l'hôte bastion pour les clusters de charge de travail sur AWS, reportez-vous à la page Deactivate Bastion Server on AWS dans le référentiel TKG Lab.

Nouveau plan `nginx`

Cet exemple ajoute et configure un nouveau plan de cluster de charge de travail nginx qui exécute un serveur nginx. Il utilise l'ensemble de ressources du cluster (CRS, Cluster Resource Set) pour déployer le serveur nginx sur des clusters vSphere créés avec le fournisseur d'API de cluster vSphere version v1.7.1.

Dans .tkg/providers/infrastructure-vsphere/v1.7.1/, ajoutez un nouveau fichier cluster-template-definition-nginx.yaml dont le contenu est identique aux fichiers cluster-template-definition-dev.yaml et cluster-template-definition-prod.yaml :
```
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TemplateDefinition
spec:
  paths:
    - path: providers/infrastructure-vsphere/v1.7.1/ytt
    - path: providers/infrastructure-vsphere/ytt
    - path: providers/ytt
    - path: bom
      filemark: text-plain
    - path: providers/config_default.yaml
```
La présence de ce fichier crée un plan, et la CLI tanzu analyse son nom de fichier pour créer l'option nginx à transmettre à tanzu cluster create --plan.

Dans ~/.config/tanzu/tkg/providers/ytt/04_user_customizations/, créez un fichier deploy_service.yaml contenant :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@ load("@ytt:yaml", "yaml")

#@ def nginx_deployment():
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
#@ end

#@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx":

---
apiVersion: addons.cluster.x-k8s.io/v1beta1
kind: ClusterResourceSet
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
  labels:
    cluster.x-k8s.io/cluster-name: #@ data.values.CLUSTER_NAME
spec:
  strategy: "ApplyOnce"
  clusterSelector:
    matchLabels:
      tkg.tanzu.vmware.com/cluster-name: #@ data.values.CLUSTER_NAME
  resources:
  - name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
    kind: ConfigMap
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
type: addons.cluster.x-k8s.io/resource-set
stringData:
  value: #@ yaml.encode(nginx_deployment())

#@ end

Dans ce fichier, la condition #@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx": applique la superposition qui suit aux clusters de charge de travail avec le plan nginx.

Si le répertoire 04_user_customizations n'existe pas déjà sous le répertoire ytt de niveau supérieur, créez-le.

Variables supplémentaires dans les superpositions `ytt`

Les superpositions appliquent leurs configurations à tous les clusters récemment créés. Pour personnaliser les clusters individuellement avec différents paramètres de superposition, vous pouvez combiner des superpositions avec des variables personnalisées que vous ajoutez à la configuration du cluster.

Cet exemple montre comment utiliser des variables de configuration de cluster supplémentaires pour définir des étiquettes de nœud personnalisées pour différents clusters.

Remarque
après la mise à niveau de la CLI Tanzu, vous devez appliquer à nouveau ces modifications à votre nouveau répertoire ~/.config/tanzu/tkg/providers. La version précédente sera renommée en tant que sauvegarde horodatée.

Étiquettes de nœud via la variable de configuration

L'ajout d'une variable WORKER_NODE_LABELS aux fichiers de configuration par défaut et de configuration de cluster permet de créer de nouveaux clusters avec différentes étiquettes de nœud worker.

Modifiez ~/.config/tanzu/tkg/providers/config_default.yaml et ajoutez la variable personnalisée par défaut en bas de l'écran :
```
#! ---------------------------------------------------------------------
#! Custom variables
#! ---------------------------------------------------------------------

WORKER_NODE_LABELS: ""
```
Définir cette valeur par défaut empêche l'ajout d'étiquettes indésirables à un cluster si ce fichier de configuration ne dispose pas de cette variable.
Ajoutez une ligne près de la fin de ~/.config/tanzu/tkg/providers/ytt/lib/config_variable_association.star, au-dessus du crochet fermant final, qui associe la nouvelle variable à un type de fournisseur.
```
"WORKER_NODE_LABELS": ["vsphere", "aws", "azure"],
}

end
```

Dans le répertoire ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, créez un fichier .yaml ou augmentez un fichier de superposition existant avec le code suivant, qui ajoute la variable WORKER_NODE_LABELS en tant que valeur de données :

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: #@ data.values.WORKER_NODE_LABELS

Pour tout nouveau cluster de charge de travail, vous pouvez désormais définir WORKER_NODE_LABEL dans son fichier de variables de configuration de cluster, afin d'appliquer sa valeur en tant qu'étiquette à chaque nœud de cluster.
```
WORKER_NODE_LABELS: "workload-classification=production"
```

Modification des ressources dans les clusters existants

Les superpositions ytt s'appliquent uniquement aux nouveaux clusters de charge de travail basés sur un plan que vous déployez à l'aide de la CLI Tanzu connectée à un cluster de gestion autonome. Pour modifier les ressources d'un cluster qui existe déjà, vous devez les modifier dans le cluster de gestion autonome et les transférer vers le cluster de charge de travail comme décrit ci-dessous.

Modifier NTP sans option DHCP 42 (vSphere)

Cette procédure apporte aux clusters existants la même modification que la superposition Configuration de NTP sans option DHCP 42 (vSphere) applique aux nouveaux clusters.

La modification des paramètres NTP sur un cluster existant nécessite :

La création d'une ressource KubeadmConfigTemplate pour refléter les nouveaux paramètres.
La mise à jour de MachineDeployment pour que les nœuds worker pointent vers la nouvelle ressource.
La mise à jour de la ressource KubeadmControlPlane pour mettre à jour les nœuds du plan de contrôle.
- La mise à jour de NTP sur les nœuds du plan de contrôle n'est pas possible dans les versions de Tanzu Kubernetes Grid antérieures à la version 1.5.

Pour modifier les paramètres NTP sur un cluster existant, exécutez ce qui suit à partir du cluster de gestion et de l'espace de noms contenant le cluster à modifier, nommé cluster1 dans cet exemple :

Créez une ressource KubeadmConfigTemplate et mettez à jour le MachineDeployment pour chaque paire KubeadmConfigTemplate / MachineDeployment. Pour un cluster de plan prod, répétez cette opération trois fois :
1. Créez la ressource KubeadmConfigTemplate pour les nœuds worker.
  - Recherchez le KubeadmConfigTemplate existant et exportez-le dans un fichier yaml pour le modifier.
```
kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate cluster1-md-0 -o yaml > cluster1-md-0.yaml
```
  - Modifiez le fichier exporté en ajoutant une section ntp sous la section spec.template.spec existante et en ajoutant -v1 au champ name sous metadata, en supposant qu'il s'agit de la première mise à jour :
```
metadata:
...
  name: cluster1-md-0-v1  # from cluster1-md-0
...
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```
  - Appliquez le fichier yaml mis à jour pour créer la ressource.
```
kubectl apply -f cluster1-md-0.yaml
```
2. Mettez à jour la ressource MachineDeployment pour qu'elle pointe vers la ressource KubeadmConfigTemplate récemment créée.
  1. Recherchez et modifiez la ressource MachineDeployment existante pour le cluster.
```
kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0
```
  2. Modifiez la valeur spec.template.spec.bootstrap.configRef.name pour définir le nouveau nom de la ressource KubeadmConfigTemplate.
```
spec:
  template:
      ...
      spec:
        bootstrap:
          configRef:
            apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
            kind: KubeadmConfigTemplate
            name: cluster1-md-0-v1 # from cluster1-md-0
```
  3. Enregistrez et quittez le fichier, ce qui déclenche la recréation des nœuds worker.
Modifiez la ressource KubeadmControlPlane pour les nœuds du plan de contrôle afin d'inclure les serveurs NTP.
1. Recherchez et modifiez la ressource KubeadmControlPlane existante pour le cluster.
```
kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane
```
2. Modifiez la section spec.kubeadmConfigSpec en ajoutant une nouvelle section ntp en dessous. Enregistrez et quittez le fichier.
```
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```