C’est l’heure de Tanzu (NTP) 

Un retour d’expérience concernant la configuration de l’heure dans TKGm (Tanzu Kubernetes Grid Multi Cloud => avec un Management Cluster). En effet, lorsqu’on souhaite renforcer sa configuration, comme toujours la documentation est à lire (RTFM).

Le sujet est découpé en 2 articles, un premier sur le partie configuration des serveurs de temps (NTP) et le un second (à paraître) sur la partie Timezone.

 

Etat des lieux

Suite au déploiement de cluster Tanzu, on constate dans les logs du Pare Feu (dans notre cas une Edge T1 Gateway) un grand nombre de flux vers plein de serveur NTP public. 

Lors de l’installation, nous avions suivi la documentation et spécifié les serveurs NTP via l’option 42 de DHCP. 

RAS, la configuration est bonne! 

Depuis notre jumpbox, on recupere la liste des nodes:

Ensuite, on rebondit pour se connecter sur un des nodes via la clé ssh et le compte utilisateur capv. 

C’est chrony qui gère la partie NTP sur les images VMware des nodes (photon ou Ubuntu). 

Via la commande chronyc sources, on affiche la liste des serveurs NTP. 

On voit bien notre serveur NTP interne (10.200.11.200) et des serveurs NTP publics ?! 

On vérifie aussi la configuration de chrony (/etc/chrony/chrony.conf) 

Nous pouvons constater la référence aux serveurs NTP Publics, nous pourrions modifier directement le fichier de configuration, mais dans cette situation, il va falloir passer sur l’ensemble des VM… et dans le cas de changement (MAJ, Scale UP, Resize), il serait nécessaire de réaliser de nouveau la modification. 

Reconfiguration NTP du cluster

Après quelques recherches, il existe une documentation pour réaliser cette opération. Pour cela, il faut modifier la configuration cloud init des VM, par chance c’est géré directement dans la ressource API KubeAdmConfigTemplate (et KubeAdmControlPlane). 

Allez, on sort son kubectl (et kubectx) préféré, si on n’est pas déjà, on bascule dans le context du Management Cluster. 

kubectx
kubectx adm-tnz-admin@adm-tnz

On récupère le template de configuration des nodes  

kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate time-tnz-md-0 -o yaml > time-tnz-md-0v1.yaml

Puis on rajoute les lignes de configuration suivantes et en renommant le nom (name) du template (…v1) 

nano time-tnz-md-0v1.yaml

Dans le « bloc » spec: template: spec: on rajoute

    ntp:
      enabled: true
      servers:
        - 10.200.11.200

On applique le template via

kubectl apply -f time-tnz-md0v1.yaml

On modifie maintenant le Machine Deployment de nos nodes. 

kubectl get MachineDeployment
kubectl edit MachineDeployment time-tnz-md-0

Il suffit de changer la référence au template 

On applique et automatiquement des nouveaux nodes vont être recrée avec la nouvelle configuration.

Au bout de quelques minutes (suivant le nombre de nodes), on se reconnecte sur un des nodes et on check la configuration

ssh [email protected]
chronyc sources

Puis la configuration (chrony.conf) :

A présent, nous constatons que nous disposons uniquement de nos serveurs NTP. 

Il est possible d’éditer un template existant (l’objet n’est pas immutable) mais cela n’est pas appliqué de suite, il faut forcer la reconstruction du nodes en supprimant par exemple, le node et il sera recréé automatiquement par le Machine Health Check avec le nouveau template. 

Il faut réaliser la même opération pour le controlplane mais actuellement, les controlplanes n’utilisent pas de template. Il faut modifier directement le KubeAdmControlPlane. 

On récupère la liste des KubeAdmControlPlane et on edit celui qui concerne notre cluster 

kubectl get KubeAdmControlPlane
kubectl edit KubeAdmControlPlane time-tnz-control-plane

On rajoute les mêmes lignes (attention à l’indentation, ce n’est pas la même que pour KubeAdmConfigTemplate…) 

Et on sauvegarde :

Egalement pour les nodes, les controlplanes vont être redéployés avec la nouvelle configuration. (dans mon cas, un unique controlplane…).

Une petite verification de l’état de mon workload cluster

tanzu cluster get time-tnz

Une dernière vérification directement sur un controlplane.

kubectx time-tnz-admin@time-tnz
kubectl get nodes -o wide
ssh [email protected]
chronyc sources
more /etc/chrony/chrony.conf

Déploiement d’un nouveau cluster

Le problème de cette méthode, c’est qu’il faut réaliser l’opération à chaque déploiement d’un nouveau cluster…  par chance, c’est aussi dans la documentation

Pour cela, il est possible de venir personnaliser la configuration des YAML poussés pour un déploiement. 

Cela utilise l’outil ytt (YAML Template Tools) de la suite carvel(.dev)

Il suffit de copier le contenu du fichier (vsphere-ntp.yaml) suivant dans le dossier ytt.

#@ 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:
        - 10.200.11.200

#@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:
          - 10.200.11.200

On copie le contenu du fichier dans le dossier ytt du provider vsphere de tanzu  

Cela modifie la génération de yaml, pour rajouter la configuration NTP dans KubeAdmControlPlane et KuneAdmConfigTemplate (pour plus de détails, vous pouvez vous référer à la documentation ytt) 

Maintenant quand on génère un nouveau cluster via la commande

 tanzu cluster create -f cluster_tnz_time.yaml -d

Si on active le dry-run et qu’on observe les yaml générés, on constate bien la présente de la configuration NTP. 

alagoutte@ALG-ADM-TNZ:~$ diff -u output/cluster_without_ntp.yaml output/cluster_with_ntp.yaml
--- output/cluster_without_ntp.yaml     2023-02-07 20:13:15.989083506 +0000
+++ output/cluster_with_ntp.yaml        2023-02-07 20:14:46.279937623 +0000
@@ -194,6 +194,10 @@
           cloud-provider: external
           tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,[...]
         name: '{{ ds.meta_data.hostname }}'
+    ntp:
+      enabled: true
+      servers:
+      - 10.200.11.200
     preKubeadmCommands:
     - hostname "{{ ds.meta_data.hostname }}"
     - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
@@ -230,6 +234,10 @@
             cloud-provider: external
             tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,[...]
           name: '{{ ds.meta_data.hostname }}'
+      ntp:
+        enabled: true
+        servers:
+        - 10.200.11.200
       preKubeadmCommands:
       - hostname "{{ ds.meta_data.hostname }}"
       - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts

Il suffit maintenant de déployer notre nouveau workload cluster !

TKGm 2 et le NTP

Et news de dernière minute, TKGm 2.1 viens de sortir. Et dans les nouveautés indiquées dans la release note, il est maintenant possible de configurer directement dans le fichier yaml de création d’un workload cluster, le paramètre NTP_SERVERS. comme aussi les nouveaux paramètres CONTROL_PLANE_NODE_NAMESERVERS & WORKER_NODE_NAMESERVERS  pour la partie DNS ou encore  NODE_IPAM_IP_POOL_NAME pour les adresses IPs des nodes (une prochaine proposition d’article…)

La documentation sur ce nouveau parameère.

Une seule contrainte, il faut deployer un cluster en utilisant un ClusterClass (par défaut avec TKGm 2.1)

A présent, on obtient un name/value : ntpServers pour la topology tkg-vsphere-default-v1.0.0 dans l’api cluster.x-k8s.io/v1beta1

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  annotations:
    osInfo: ubuntu,20.04,amd64
    tkg.tanzu.vmware.com/cluster-controlplane-endpoint: 10.200.100.182
    tkg/plan: prod
  labels:
    tkg.tanzu.vmware.com/cluster-name: time-tnz-2
  name: time-tnz-2
  namespace: default
spec:
[...]
  topology:
    class: tkg-vsphere-default-v1.0.0
[..]
    - name: worker
      value:
        count: 1
        machine:
          diskGiB: 20
          memoryMiB: 4096
          numCPUs: 2
    - name: ntpServers
      value:
      - 10.200.11.200
    version: v1.24.9+vmware.1

Conclusion

Maintenant vous êtes sûr d’avoir vos différents clusters à l’heure ou presque, nous parlerons dans un prochain article de comment configurer la timezone au niveau des différents nodes !