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.
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.
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.
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 à :
ytt
> Interactive PlaygroundPour 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.
ytt
spécifiques au fournisseur et à la version. Par exemple, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0
.
base-template.yaml
contient des espaces réservés intégralement majuscules tels que "${CLUSTER_NAME}"
et ne doit pas être modifié.overlay.yaml
est adapté aux valeurs de superposition dans base-template.yaml
.ytt
à l'échelle du fournisseur. Par exemple, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt
.
ytt
de niveau supérieur, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt
.
/04_user_customizations
pour les configurations prioritaires sur n'importe quel sous-répertoire ytt
de numérotation inférieure.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 :
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 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.
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'
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.
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"]
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
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"
.
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.
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 v0.7.6.
Dans .tkg/providers/infrastructure-vsphere/v0.7.6/
, 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/v0.7.6/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.
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.
Remarqueaprè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.
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"
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.
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 :
KubeadmConfigTemplate
pour refléter les nouveaux paramètres.MachineDeployment
pour que les nœuds worker pointent vers la nouvelle ressource.KubeadmControlPlane
pour mettre à jour les nœuds du plan de contrôle.
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 :
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
Mettez à jour la ressource MachineDeployment
pour qu'elle pointe vers la ressource KubeadmConfigTemplate
récemment créée.
Recherchez et modifiez la ressource MachineDeployment
existante pour le cluster.
kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0
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
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.
Recherchez et modifiez la ressource KubeadmControlPlane
existante pour le cluster.
kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane
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