Configurazione di un cluster legacy con ytt

Questo argomento descrive come utilizzare gli overlay ytt per configurare cluster del carico di lavoro legacy basati su TKC o sul piano distribuiti da Tanzu Kubernetes Grid (TKG) per impostare le proprietà del cluster e degli oggetti sottostanti che non possono essere impostate dalle variabili di configurazione in un file di configurazione del cluster, come indicato in Configurazione di un cluster distribuito da un supervisore con un file di configurazione per i cluster TKC o in Informazioni di riferimento sulle variabili del file di configurazione per i cluster basati sul piano.

Per informazioni su come scaricare e installare ytt, vedere Installazione degli strumenti Carvel.

Gli overlay ytt non sono necessari e non sono supportati per i cluster basati sulla classe, per i quali tutte le proprietà configurabili possono essere impostate ad alto livello all'interno dell'oggetto Cluster semplificato stesso. Se la CLI di Tanzu rileva ytt nella macchina dell'utente durante l'esecuzione di tanzu cluster create per un cluster basato sulla classe, viene generato un errore It seems like you have done some customizations to the template overlays.

Panoramica

Per la configurazione avanzata dei cluster del carico di lavoro basati su TKC o sul piano, per impostare le proprietà degli oggetti che non possono essere impostate dalle variabili di configurazione del cluster, è possibile personalizzare i file di configurazione di TKC, del cluster basato sul piano e del piano del cluster nella directory ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere locale di qualsiasi macchina di bootstrap.

È possibile personalizzare queste configurazioni aggiungendo o modificando i file di configurazione direttamente o tramite gli overlay ytt.

La personalizzazione diretta dei file di configurazione è più semplice, ma se si è in grado di utilizzarli, gli overlay ytt consentono di personalizzare le configurazioni in ambiti diversi e di gestire più file di configurazione modulari, senza modificare in modo distruttivo valori di configurazione upstream ed ereditati. Gli overlay ytt si applicano solo ai nuovi cluster del carico di lavoro basati su TKC o sul piano creati tramite la CLI di Tanzu.

Per ulteriori informazioni sul funzionamento e la priorità dei vari metodi di configurazione del cluster, vedere Informazioni sulla configurazione di cluster legacy basati su TKC o su un piano in Informazioni su Tanzu Kubernetes Grid.

Comportamento e convenzioni di `ytt`

I comportamenti e le convenzioni per l'elaborazione di ytt includono:

Precedenza: ytt attraversa la directory in profondità con i file in ordine alfabetico e sovrascrive le impostazioni duplicate mentre procede. Quando sono presenti definizioni duplicate, quella che ytt elabora per ultima ha la precedenza.

Tipi di overlay: diversi tipi di overlay ytt modificano o impostano elementi diversi:

File dei valori dei dati impostano o modificano i valori di configurazione senza modificare le strutture degli oggetti. Questi includono i file Bill of Materials (BoM) e, per convenzione, i file i cui nomi includono data.
File overlay apportano modifiche alle definizioni delle strutture degli oggetti. Per convenzione, questi file includono overlay nei loro nomi.

Per ulteriori informazioni su ytt, inclusi esempi di overlay e uno strumento di convalida interattivo, vedere:

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

Cluster e piani di cluster

Per i cluster basati su TKC o sul piano, la directory della macchina di bootstrap ~/.config/tanzu/tkg/providers/ include directory ytt e file overlay.yaml a livelli diversi, che consentono di definire l'ambito delle impostazioni di configurazione a ogni livello.

Directory ytt specifiche del provider e della versione. Ad esempio, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0.
- Configurazioni specifiche per la versione dell'API del provider.
- Il file base-template.yaml contiene segnaposto tutti maiuscoli come "${CLUSTER_NAME}" e non deve essere modificato.
- Il file overlay.yaml è personalizzato per i valori di overlay in base-template.yaml.
Directory ytt a livello di provider. Ad esempio, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
- Configurazioni a livello di provider che si applicano a tutte le versioni.
Directory ytt di primo livello, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
- Configurazioni tra provider.
- Organizzati in directory numerate ed elaborati in ordine numerico.
- È possibile creare una sottodirectory /04_user_customizations per le configurazioni che hanno la precedenza sulle sottodirectory ytt con un numero inferiore.

Overlay `ytt`

Questa sezione contiene gli overlay per la personalizzazione dei cluster del carico di lavoro basati sul piano distribuiti da un cluster di gestione autonomo e per la creazione di nuovi piani di cluster.

Limiti:

È possibile utilizzare gli overlay ytt solo per modificare i cluster del carico di lavoro. L'utilizzo degli overlay ytt per modificare i cluster di gestione autonomi non è supportato.
Gli overlay dei cluster del carico di lavoro vengono applicati solo al momento della creazione del cluster e non modificano i cluster esistenti. Per informazioni su come modificare i cluster esistenti, vedere Modifica delle risorse di cluster esistenti.

Gli esempi seguenti illustrano come utilizzare i file overlay di configurazione per personalizzare i cluster del carico di lavoro e creare un nuovo piano del cluster.

Per un overlay che personalizza i certificati attendibili in un cluster, vedere Configurazione di cluster con più registri attendibili nell'argomento Gestione di segreti e certificati del cluster.

Server dei nomi in vSphere

In questo esempio vengono aggiunti uno o più server dei nomi personalizzati ai nodi del piano di controllo e ai nodi worker in cluster Tanzu Kubernetes Grid legacy in vSphere. Viene disattivata la risoluzione DNS da DHCP in modo che i server dei nomi personalizzati abbiano la precedenza.

Per configurare server dei nomi personalizzati in un cluster basato sulla classe, utilizzare le variabili di configurazione CONTROL_PLANE_NODE_NAMESERVERS e WORKER_NODE_NAMESERVERS.

Due file di overlay vengono applicati ai nodi del piano di controllo e gli altri due vengono applicati ai nodi worker. Aggiungere tutti e quattro i file nella directory ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/.

I file di overlay variano a seconda che i nodi siano basati su immagini di macchine Ubuntu o Photon e non sono necessari file di overlay DHCP per Ubuntu.

Una riga in ogni file overlay-dns imposta gli indirizzi del server dei nomi. Il codice seguente include un singolo server dei nomi, ma è possibile specificare più server dei nomi sotto forma di elenco, ad esempio nameservers: ["1.2.3.4","5.6.7.8"].

File 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"]

File 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"]

File vsphere-overlay-dhcp-control-plane.yaml (solo Photon):

#@ 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'

File vsphere-overlay-dhcp-workers.yaml (solo Photon):

#@ 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'

Endpoint del piano di controllo del nome di dominio completo con NSX ALB

Per creare in vSphere con NSX Advanced Load Balancer cluster del carico di lavoro configurati con VSPHERE_CONTROL_PLANE_ENDPOINT impostato su un nome di dominio completo anziché su un indirizzo IP, creare un file di overlay nella directory .config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, ad esempio fqdn-cert-api.yaml, con il contenuto seguente:

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

In cui CONTROLPLANE-FQDN è il nome di dominio completo per il piano di controllo del cluster del carico di lavoro.

Con l'overlay presente, creare il cluster.

Dopo aver creato il cluster, eseguire la procedura Configurazione delle prenotazioni DHCP dei nodi e del record DNS dell'endpoint (solo vSphere) per creare un record DNS.

Prima di creare ogni cluster aggiuntivo con un endpoint del nome di dominio completo, modificare l'impostazione CONTROLPLANE-FQDN nell'overlay in base alle esigenze.

Risoluzione del dominio .local

Nei sistemi Linux moderni, i tentativi di risolvere i nomi host che hanno un suffisso di dominio che termina con .local possono non riuscire. Questo problema si verifica perché systemd-networkd, il resolver DNS nella maggior parte delle distribuzioni di Linux, tenta di risolvere il dominio .local tramite DNS multi-cast (mDNS), non tramite i server DNS standard.

Per configurare la risoluzione del dominio .local in un cluster basato sulla classe, utilizzare le variabili di configurazione CONTROL_PLANE_NODE_SEARCH_DOMAINS e WORKER_NODE_SEARCH_DOMAINS.

Per risolvere questo problema noto, aggiungere una riga searchDomains con il suffisso del dominio locale alla fine dei file vsphere-overlay-dns-control-plane.yaml e vsphere-overlay-dns-workers.yaml nella directory ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/.

Esempio per il file 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"]

Esempio per il file 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"]

Configurazione di NTP senza l'opzione DHCP 42 (vSphere)

L'autenticazione TLS nei cluster Tanzu Kubernetes Grid richiede una sincronizzazione precisa dell'ora. Nella maggior parte degli ambienti basati su DHCP, è possibile configurare la sincronizzazione utilizzando l'opzione DHCP 42.

Se si distribuiscono cluster legacy in un ambiente di vSphere che non dispone dell'opzione DHCP 42, utilizzare il codice di overlay come indicato di seguito per fare in modo che Tanzu Kubernetes Grid crei cluster con server NTP che mantengono la sincronizzazione:

Per configurare NTP in un cluster basato sulla classe, utilizzare la variabile di configurazione NTP_SERVERS.

Nella directory ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, creare un nuovo file .yaml oppure aumentare un file di overlay esistente con il codice seguente, sostituendo l'esempio time.google.com con il server NTP desiderato:

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

Etichette dei nodi personalizzati

Quando il cluster legacy viene creato, l'overlay assegna etichette persistenti ai nodi del cluster. Ciò è utile perché le etichette che vengono applicate manualmente tramite kubectl non rimangono quando i nodi vengono sostituiti.

Vedere Variabili aggiuntive negli overlay ytt.

Per configurare etichette di nodi personalizzate per i nodi del piano di controllo in un cluster basato sulla classe, utilizzare la variabile di configurazione CONTROL_PLANE_NODE_LABELS.

Nella directory ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, creare un nuovo file .yaml oppure aumentare un file di overlay esistente con il codice seguente.

Per le etichette dei nodi del piano di controllo, configurare le sezioni initConfiguration e joinConfiguration in modo che le etichette vengano applicate al primo nodo creato e a tutti i nodi aggiunti dopo:

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

In cui NODE-LABELS è un elenco separato da virgole di stringhe chiave/valore di etichetta che include node-type=control-plane, ad esempio "examplekey1=labelvalue1,examplekey2=labelvalue2".

Per le etichette dei nodi 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

In cui NODE-LABELS è un elenco separato da virgole di stringhe chiave/valore di etichetta che include node-type=worker, ad esempio "examplekey1=labelvalue1,examplekey2=labelvalue2".

Disattivazione dell'host Bastion in AWS

Per un overlay di esempio che disattivi l'host Bastion per i cluster del carico di lavoro in AWS, vedere Disattivazione del server Bastion in AWS nel repository TKG Lab.

Nuovo Piano `nginx`

In questo esempio viene aggiunto e configurato un nuovo piano del cluster del carico di lavoro nginx che esegue un server nginx. Viene utilizzato Cluster Resource Set (CRS) per distribuire il server nginx nei cluster vSphere creati con la versione v1.7.1 di vSphere Cluster API Provider.

In .tkg/providers/infrastructure-vsphere/v1.7.1/, aggiungere un nuovo file cluster-template-definition-nginx.yaml con contenuti identici a quelli dei file cluster-template-definition-dev.yaml e cluster-template-definition-prod.yamlml:
```
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 presenza di questo file crea un nuovo piano e la CLI di tanzu analizza il nome del file per creare l'opzione nginx da passare a tanzu cluster create --plan.

In ~/.config/tanzu/tkg/providers/ytt/04_user_customizations/, creare un nuovo file deploy_service.yaml contenente:

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

In questo file, l'elemento condizionale #@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx": applica l'overlay che segue ai cluster del carico di lavoro con il piano nginx.

Se la directory 04_user_customizations non esiste già nella directory ytt di primo livello, crearla.

Variabili aggiuntive negli overlay `ytt`

Gli overlay applicano le loro configurazioni a tutti i cluster appena creati. Per personalizzare i cluster singolarmente con impostazioni di overlay diverse, è possibile combinare gli overlay con variabili personalizzate aggiunte alla configurazione del cluster.

In questo esempio viene illustrato come utilizzare variabili di configurazione aggiuntive del cluster per impostare etichette dei nodi personalizzate per cluster diversi.

Nota
dopo aver aggiornato la CLI di Tanzu, è necessario applicare nuovamente queste modifiche alla nuova directory ~/.config/tanzu/tkg/providers. La versione precedente verrà rinominata come backup con data e ora.

Etichette del nodo tramite variabile di configurazione

Se si aggiunge una variabile WORKER_NODE_LABELS nel file di configurazione predefinito e nel file di configurazione del cluster, è possibile creare nuovi cluster con etichette del nodo worker diverse.

Modificare ~/.config/tanzu/tkg/providers/config_default.yaml e aggiungere il valore predefinito della variabile personalizzata nella parte inferiore:
```
#! ---------------------------------------------------------------------
#! Custom variables
#! ---------------------------------------------------------------------

WORKER_NODE_LABELS: ""
```
Specificando il valore predefinito, si impedisce l'aggiunta di etichette indesiderate in un cluster il cui file di configurazione non include questa variabile.
Aggiungere quasi alla fine di ~/.config/tanzu/tkg/providers/ytt/lib/config_variable_association.star, sopra la parentesi di chiusura finale una riga che associa la nuova variabile a un tipo di provider.
```
"WORKER_NODE_LABELS": ["vsphere", "aws", "azure"],
}

end
```

Nella directory ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, creare un nuovo file .yaml oppure aumentare un file di overlay esistente con il codice seguente, che aggiunge la variabile WORKER_NODE_LABELS come valore di dati:

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

Per qualsiasi nuovo cluster del carico di lavoro, è ora possibile impostare WORKER_NODE_LABEL nel file della variabile di configurazione del cluster per applicarne il valore come etichetta in ogni nodo del cluster.
```
WORKER_NODE_LABELS: "workload-classification=production"
```

Modifica delle risorse nei cluster esistenti

Gli overlay ytt si applicano solo ai nuovi cluster del carico di lavoro basati sul piano distribuiti utilizzando la CLI di Tanzu connessa a un cluster di gestione autonomo. Per modificare le risorse di un cluster già esistente, è necessario modificarle nel cluster di gestione autonomo ed eseguirne il push al cluster del carico di lavoro, come descritto di seguito.

Modifica di NTP senza l'opzione DHCP 42 (vSphere)

Questa procedura assegna ai cluster esistenti la stessa modifica che l'overlay Configurazione di NTP senza l'opzione DHCP 42 (vSphere) applica ai nuovi cluster.

La modifica delle impostazioni di NTP in un cluster esistente richiede:

Creazione di una nuova risorsa KubeadmConfigTemplate che rifletta le nuove impostazioni
Aggiornamento di MachineDeployment in modo che i nodi worker puntino alla nuova risorsa
Aggiornamento della risorsa KubeadmControlPlane per aggiornare i nodi del piano di controllo
- Nelle versioni di Tanzu Kubernetes Grid precedenti alla versione 1.5 non è possibile aggiornare NTP nei nodi del piano di controllo.

Per modificare le impostazioni di NTP in un cluster esistente, eseguire le operazioni seguenti dal cluster di gestione e dallo spazio dei nomi contenente il cluster da modificare, denominato cluster1 in questo esempio:

Creare una nuova risorsa KubeadmConfigTemplate e aggiornare MachineDeployment per ogni coppia KubeadmConfigTemplate/MachineDeployment. Per un cluster del piano prod, eseguire questa operazione tre volte:
1. Creare la nuova risorsa KubeadmConfigTemplate per i nodi worker.
  - Individuare la risorsa KubeadmConfigTemplate esistente ed esportarla in un file yaml per la modifica.
```
kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate cluster1-md-0 -o yaml > cluster1-md-0.yaml
```
  - Modificare il file esportato aggiungendo una sezione ntp sotto la sezione spec.template.spec esistente e aggiungendo -v1 al campo name in metadata, supponendo che questo sia il primo aggiornamento:
```
metadata:
...
  name: cluster1-md-0-v1  # from cluster1-md-0
...
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```
  - Applicare il file yaml aggiornato per creare la nuova risorsa.
```
kubectl apply -f cluster1-md-0.yaml
```
2. Aggiornare la risorsa MachineDeployment in modo che punti alla risorsa KubeadmConfigTemplate appena creata.
  1. Individuare e modificare la risorsa MachineDeployment esistente per il cluster.
```
kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0
```
  2. Modificare il valore di spec.template.spec.bootstrap.configRef.name in base al nome della nuova risorsa 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. Salvare e chiudere il file. Viene attivata la ricreazione dei nodi worker.
Modificare la risorsa KubeadmControlPlane per i nodi del piano di controllo in modo che includa i server NTP.
1. Individuare e modificare la risorsa KubeadmControlPlane esistente per il cluster.
```
kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane
```
2. Modificare la sezione spec.kubeadmConfigSpec aggiungendo una nuova sezione ntp sotto. Salvare e chiudere il file.
```
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```