This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Configuración de clústeres heredados con ytt

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.

Descripción general

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 basados​en 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 basados​en planes y TKC en Acerca de Tanzu Kubernetes Grid.

Comportamiento y convenciones 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:

Clústeres y planes de clústeres

Para clústeres basados​en 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.

  • Directorios de ytt específicos de la versión y del proveedor. Por ejemplo, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0.
    • Configuraciones específicas para la versión de API del proveedor.
    • El archivo base-template.yaml contiene marcadores de posición de mayúsculas como "${CLUSTER_NAME}" y no se deben editar.
    • El archivo overlay.yaml se adapta a los valores superpuestos en base-template.yaml.
  • Directorios ytt en todo el proveedor. Por ejemplo, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
    • Configuraciones de todo el proveedor que se aplican a todas las versiones.
  • Directorio de ytt de nivel superior, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
    • Configuraciones entre proveedores.
    • Organizado en directorios numerados y procesado en orden numérico.
    • Puede crear un subdirectorio /04_user_customizations para las configuraciones que tengan prioridad sobre cualquier subdirectorio ytt menor.

Superposiciones 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:

  • Solo puede utilizar superposiciones 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.
  • Las superposiciones de clústeres de carga de trabajo solo se aplican al crear el clúster y no modifican los clústeres existentes. Consulte Modificar recursos en clústeres existentes para obtener información sobre cómo modificar los clústeres existentes.

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.

Servidores de nombres en vSphere

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'

Endpoint de plano de control de FQDN con NSX ALB

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.

Resolver dominio.local

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

Configurar NTP sin la opción 42 de DHCP (vSphere)

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

Etiquetas de nodo personalizadas

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.

  1. 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".

Desactivar host bastión en AWS

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.

Nuevo plan 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.

  1. 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.

  2. 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.

Variables adicionales en superposiciones 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.

Nota

Despué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.

Etiquetas de nodo a través de la variable de configuración

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.

  1. 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.

  2. 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

  3. 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

  4. 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"

Modificar recursos en clústeres existentes

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.

Modificar NTP sin la opción 42 de DHCP (vSphere)

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:

  • Crear un nuevo recurso KubeadmConfigTemplate para reflejar la nueva configuración
  • Actualizar MachineDeployment para que los nodos de trabajo apunten al nuevo recurso
  • Actualizar el recurso KubeadmControlPlane para actualizar los nodos del plano de control
    • No es posible actualizar NTP en los nodos del plano de control en las versiones de Tanzu Kubernetes Grid anteriores a la versión 1.5.

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:

  1. 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:

    1. 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

    2. Actualice el recurso MachineDeployment para que apunte al recurso KubeadmConfigTemplate.

      1. Busque y edite el recurso MachineDeployment existente para el clúster.

        kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0

      2. 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

      3. Guarde y salga del archivo, lo que activa la nueva creación de los nodos de trabajo.

  2. Edite el recurso KubeadmControlPlane para que los nodos del plano de control incluyan los servidores NTP.

    1. Busque y edite el recurso KubeadmControlPlane existente para el clúster.

      kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane

    2. 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
check-circle-line exclamation-circle-line close-line
Scroll to top icon