En este tema se describe cómo utilizar superposiciones ytt
para configurar clústeres de carga de trabajo heredados y basados en planes implementados por Tanzu Kubernetes Grid (TKG) para establecer las propiedades del clúster y del objeto subyacente que no se pueden establecer mediante variables de configuración en un archivo de configuración de clúster, como se indica en Configurar un clúster implementado por supervisor con un archivo de configuración para clústeres de TKC o Referencia de variables del archivo de configuración para clústeres basados en planes.
Para obtener información sobre cómo descargar e instalar ytt
, consulte Instalar Carvel Tools.
Las superposiciones ytt
no son necesarias ni compatibles con los basados en clases, para los cuales todas las propiedades configurables se pueden establecer en un nivel alto dentro del propio objeto de Cluster
simplificado. Si la CLI de Tanzu detecta ytt
en su máquina al ejecutar tanzu cluster create
para un clúster basado en clases, se produce un error It seems like you have done some customizations to the template overlays.
Para la configuración avanzada de clústeres de carga de trabajo basados en planes y en TKC, para establecer propiedades de objeto que no se puedan establecer en las variables de configuración del clúster, puede personalizar los archivos de configuración del plan de clúster, clúster basado en planes y TKC en el directorio local ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere
de cualquier máquina de arranque.
Puede personalizar estas configuraciones agregando o modificando archivos de configuración directamente o mediante superposiciones ytt
.
Personalizar directamente los archivos de configuración es más sencillo, pero si le resulta cómodo con superposiciones ytt
, le permiten personalizar configuraciones en diferentes ámbitos y administrar varios archivos de configuración modulares, sin editar de forma destructiva los valores de configuración ascendentes y heredados. Las superposiciones ytt
solo se aplican a los nuevos clústeres de cargas de trabajo basadosen planes y TKC, creados con la CLI de Tanzu.
Para obtener más información sobre cómo funcionan y tienen prioridad las diversas formas de configuración del clúster, consulte Acerca de la configuración de clústeres basadosen planes y TKC en Acerca de Tanzu Kubernetes Grid.
ytt
Los comportamientos y las convenciones del procesamiento de ytt
incluyen:
Prioridad: ytt
atraviesa la profundidad de los directorios primero en orden alfabético de nombre de archivo y sobrescribe la configuración duplicada a medida que continúa. Cuando hay definiciones duplicadas, el último que ytt
procesa tiene prioridad.
Tipos de superposición: los diferentes tipos de superposición de ytt
cambian o establecen diferentes elementos:
Los archivos de valores de datos establecen o modifican valores de configuración sin modificar las estructuras de objetos. Estos incluyen archivos de la lista de materiales (BoM) y, por convención, archivos con data
en sus nombres de archivo.
Los archivos de superposición realizan cambios en las definiciones de estructura de objetos. Por convención, estos archivos tienen overlay
en sus nombres de archivo.
Para obtener más información sobre ytt
, incluidos ejemplos de superposición y una herramienta de validador interactivo, consulte:
ytt
> InteractivoPara clústeres basadosen planes y TKC, el directorio ~/.config/tanzu/tkg/providers/
de la máquina de arranque incluye directorios ytt
y archivos overlay.yaml
en diferentes niveles, lo que le permite definir los ajustes de configuración en cada nivel.
ytt
específicos de la versión y del proveedor. Por ejemplo, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0
.
base-template.yaml
contiene marcadores de posición de mayúsculas como "${CLUSTER_NAME}"
y no se deben editar.overlay.yaml
se adapta a los valores superpuestos en base-template.yaml
.ytt
en todo el proveedor. Por ejemplo, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt
.
ytt
de nivel superior, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt
.
/04_user_customizations
para las configuraciones que tengan prioridad sobre cualquier subdirectorio ytt
menor.ytt
Esta sección contiene superposiciones para personalizar clústeres de carga de trabajo basados en planes implementados por un clúster de administración independiente y para crear nuevos planes de clúster.
Limitaciones:
ytt
para modificar los clústeres de carga de trabajo. No se admite el uso de superposiciones ytt
para modificar clústeres de administración independientes.Los siguientes ejemplos muestran cómo utilizar archivos de superposición de configuración para personalizar los clústeres de carga de trabajo y crear un nuevo plan de clúster.
Para una superposición que personalice los certificados de confianza en un clúster, consulte Configurar clústeres con varios registros de confianza en el tema Administrar secretos y certificados del clúster.
En este ejemplo, se agregan uno o varios servidores de nombres personalizados a los nodos de plano de control y de trabajo en clústeres de Tanzu Kubernetes Grid legac7 en vSphere. Desactiva la resolución de DNS desde DHCP para que los servidores de nombres personalizados tengan prioridad.
Para configurar servidores de nombres personalizados en un clúster basado en clases, utilice las variables de configuración CONTROL_PLANE_NODE_NAMESERVERS
y WORKER_NODE_NAMESERVERS
.
Dos archivos de superposición se aplican a los nodos del plano de control y los otros dos se aplican a los nodos de trabajo. Agregue los cuatro archivos al directorio ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/
.
Los archivos de superposición difieren dependiendo de si sus nodos se basan en imágenes de máquina de Ubuntu o Photon. No necesita archivos de superposición de DHCP para Ubuntu.
Una línea en cada archivo overlay-dns
establece las direcciones del servidor de nombres. El siguiente código muestra un solo servidor de nombres, pero puede especificar varios servidores de nombres como una lista, por ejemplo nameservers: ["1.2.3.4","5.6.7.8"]
.
Archivo 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"]
Archivo 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"]
Archivo 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'
Archivo 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'
Para crear clústeres de carga de trabajo en vSphere con NSX Advanced Load Balancer que están configurados con VSPHERE_CONTROL_PLANE_ENDPOINT
establecido en un FQDN en lugar de una dirección IP, cree un archivo de superposición en el directorio .config/tanzu/tkg/providers/infrastructure-vsphere/ytt/
, como fqdn-cert-api.yaml
, con el contenido del siguiente modo:
#@ 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
Donde CONTROLPLANE-FQDN
es el FQDN del plano de control del clúster de carga de trabajo.
Con la superposición en su lugar, cree el clúster.
Después de crear el clúster, siga el procedimiento Configurar las reservas de DHCP del nodo y el registro de DNS de endpoint (solo vSphere) para crear un registro de DNS.
Antes de crear cada clúster adicional con un endpoint de FQDN, modifique el ajuste CONTROLPLANE-FQDN
en la superposición según sea necesario.
En los sistemas Linux modernos, se puede producir un error al intentar resolver nombres de host que tengan un sufijo de dominio que termine en .local
. Este problema se produce debido a que systemd-networkd
, el solucionador de DNS en la mayoría de las distribuciones de Linux, intenta resolver el dominio .local
a través de DNS multi-cast (mDNS), no a través de servidores DNS estándar.
Para configurar la resolución de dominio .local
en un clúster basado en clases, utilice las variables de configuración CONTROL_PLANE_NODE_SEARCH_DOMAINS
y WORKER_NODE_SEARCH_DOMAINS
.
Para solucionar este problema conocido en los clústeres heredados, agregue una línea searchDomains
con el sufijo de su dominio local al final de los archivos vsphere-overlay-dns-control-plane.yaml
y vsphere-overlay-dns-workers.yaml
en el directorio ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/
.
Ejemplo del archivo 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"]
Ejemplo del archivo 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"]
La autenticación TLS en clústeres de Tanzu Kubernetes Grid requiere una sincronización de hora precisa. En la mayoría de los entornos basados en DHCP, puede configurar la sincronización mediante la opción 42 de DHCP.
Si va a implementar clústeres heredados en un entorno de vSphere que no tiene la opción DHCP 42, utilice el código superpuesto de la siguiente manera para que Tanzu Kubernetes Grid cree clústeres con servidores NTP que mantengan la sincronización
Para configurar NTP en un clúster basado en clases, utilice la variable de configuración NTP_SERVERS
.
En ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/
, cree un nuevo archivo .yaml
o aumente un archivo de superposición existente con el siguiente código, cambiando el time.google.com
de ejemplo al servidor NTP deseado:
#@ 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
Esta superposición asigna etiquetas persistentes a los nodos del clúster cuando se crea el clúster heredado. Esto resulta útil porque las etiquetas aplicadas manualmente a través de kubectl
no se conservan al reemplazar los nodos.
Consulte Variables Extra en superposiciones ytt
.
Para configurar etiquetas de nodo personalizadas para los nodos del plano de control en un clúster basado en clases, utilice la variable de configuración CONTROL_PLANE_NODE_LABELS
.
En el directorio ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/
, cree un nuevo archivo .yaml
o amplíe un archivo de superposición existente con el siguiente código.
Para las etiquetas de nodo del plano de control, configure las secciones initConfiguration
y joinConfiguration
para que las etiquetas se apliquen al primer nodo creado y a todos los nodos que se unan despué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
Donde NODE-LABELS
es una lista separada por comas de cadenas clave/valor de etiqueta que incluye node-type=control-plane
, por ejemplo, "examplekey1=labelvalue1,examplekey2=labelvalue2"
.
Para las etiquetas de nodo de trabajador:
#@ 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
Donde NODE-LABELS
es una lista separada por comas de cadenas clave/valor de etiqueta que incluye node-type=worker
, por ejemplo, "examplekey1=labelvalue1,examplekey2=labelvalue2"
.
Para ver un ejemplo de superposición que desactiva el host bastión para los clústeres de carga de trabajo en AWS, consulte Desactivar Bastion Server on AWS en el repositorio TKG Lab.
nginx
En este ejemplo, se agrega y configura un nuevo plan de clúster de carga de trabajo nginx
que ejecuta un servidor nginx. Utiliza el conjunto de recursos del clúster (Cluster Resource Set, CRS) para implementar el servidor nginx en clústeres de vSphere creados con la versión 1.7.1. del proveedor de API del clúster de vSphere.
En .tkg/providers/infrastructure-vsphere/v1.7.1/
, agregue un nuevo archivo cluster-template-definition-nginx.yaml
con contenido idéntico a los archivos cluster-template-definition-dev.yaml
y 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 presencia de este archivo crea un nuevo plan y la CLI tanzu
analiza su nombre de archivo para crear la opción nginx
pasar a tanzu cluster create --plan
.
En ~/.config/tanzu/tkg/providers/ytt/04_user_customizations/
, cree un nuevo archivo deploy_service.yaml
que contenga:
#@ 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
En este archivo, el #@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx":
aplica la superposición que aparece a continuación a los clústeres de carga de trabajo con el plan nginx
.
Si el directorio 04_user_customizations
aún no existe en el directorio de nivel superior ytt
, créelo.
ytt
Las superposiciones aplican sus configuraciones a todos los clústeres recién creados. Para personalizar los clústeres de forma individual con diferentes ajustes de superposición, puede combinar superposiciones con variables personalizadas que agregue a la configuración del clúster.
En este ejemplo se muestra cómo utilizar variables de configuración de clúster adicionales para establecer etiquetas de nodo personalizadas para distintos clústeres.
NotaDespués de actualizar la CLI de Tanzu, debe volver a aplicar estos cambios al nuevo directorio
~/.config/tanzu/tkg/providers
. Se cambiará el nombre de la versión anterior como una copia de seguridad con marca de tiempo.
Al agregar una variable WORKER_NODE_LABELS
a los archivos de configuración predeterminados y de configuración del clúster, se pueden crear nuevos clústeres con etiquetas de nodo de trabajo diferentes.
Edite ~/.config/tanzu/tkg/providers/config_default.yaml
y agregue la variable personalizada predeterminada en la parte inferior:
#! ---------------------------------------------------------------------
#! Custom variables
#! ---------------------------------------------------------------------
WORKER_NODE_LABELS: ""
Si se establece este valor predeterminado, se evita que se agreguen etiquetas no deseadas a un clúster si su archivo de configuración no tiene esta variable.
Agregue una línea cerca del final de ~/.config/tanzu/tkg/providers/ytt/lib/config_variable_association.star
, encima del paréntesis de cierre final, que asocie la nueva variable con un tipo de proveedor.
"WORKER_NODE_LABELS": ["vsphere", "aws", "azure"],
}
end
En el directorio ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/
, cree un nuevo archivo .yaml
o aumente un archivo de superposición existente con el siguiente código, lo que agrega la variable WORKER_NODE_LABELS
como un valor de datos:
#@ 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
Para cualquier clúster de carga de trabajo nuevo, ahora puede establecer WORKER_NODE_LABEL
en su archivo de variable de configuración del clúster para aplicar su valor como etiqueta a cada nodo del clúster.
WORKER_NODE_LABELS: "workload-classification=production"
Las superposiciones ytt
solo se aplican a los nuevos clústeres de carga de trabajo basados en planes que se implementan mediante la CLI de Tanzu que inició sesión en un clúster de administración independiente. Para modificar los recursos de un clúster que ya existe, debe modificarlos en el clúster de administración independiente y enviarlos al clúster de carga de trabajo como se describe a continuación.
Este procedimiento proporciona a los clústeres existentes la misma modificación que la Configurar NTP sin la opción DHCP 42 (vSphere) superposición se aplica a los clústeres nuevos.
Para modificar la configuración de NTP en un clúster existente, es necesario:
KubeadmConfigTemplate
para reflejar la nueva configuraciónMachineDeployment
para que los nodos de trabajo apunten al nuevo recursoKubeadmControlPlane
para actualizar los nodos del plano de control
Para modificar la configuración de NTP en un clúster existente, ejecute lo siguiente desde el clúster de administración y desde el espacio de nombres que contiene el clúster que se va a modificar, denominado cluster1
en este ejemplo:
Cree un nuevo recurso KubeadmConfigTemplate
y actualice el MachineDeployment
para cada par KubeadmConfigTemplate
/MachineDeployment
. Para un clúster del plan prod
, hágalo tres veces:
Cree el nuevo recurso KubeadmConfigTemplate
para los nodos de trabajo.
Busque el KubeadmConfigTemplate
y expórtelo a un archivo yaml
para editarlo.
kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate cluster1-md-0 -o yaml > cluster1-md-0.yaml
Para editar el archivo exportado, agregue una sección ntp
debajo del campo spec.template.spec
existente y anexe -v1
al campo name
en metadata
suponiendo que esta es la primera actualización:
metadata:
...
name: cluster1-md-0-v1 # from cluster1-md-0
...
kubeadmConfigSpec:
ntp:
enabled: true
servers:
- time.google.com
Aplique el archivo yaml
actualizado para crear el nuevo recurso.
kubectl apply -f cluster1-md-0.yaml
Actualice el recurso MachineDeployment
para que apunte al recurso KubeadmConfigTemplate
.
Busque y edite el recurso MachineDeployment
existente para el clúster.
kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0
Edite el valor spec.template.spec.bootstrap.configRef.name
para establecer el nuevo nombre del recurso KubeadmConfigTemplate
.
spec:
template:
...
spec:
bootstrap:
configRef:
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
name: cluster1-md-0-v1 # from cluster1-md-0
Guarde y salga del archivo, lo que activa la nueva creación de los nodos de trabajo.
Edite el recurso KubeadmControlPlane
para que los nodos del plano de control incluyan los servidores NTP.
Busque y edite el recurso KubeadmControlPlane
existente para el clúster.
kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane
Edite la sección spec.kubeadmConfigSpec
agregando una nueva sección ntp
inferior. Guarde y salga del archivo.
kubeadmConfigSpec:
ntp:
enabled: true
servers:
- time.google.com