Crear una ClusterClass personalizada

En este tema se describe cómo crear su propio recurso ClusterClass personalizado para un clúster de administración independiente de Tanzu Kubernetes Grid (TKG), utilizarlo para crear clústeres de carga de trabajo basados en clases y trabajar con clústeres que se basan en la ClusterClass personalizada.

Para basar un clúster en un ClusterClass, establezca su spec.topology.class en el nombre ClusterClass.

Estos procedimientos no se aplican a TKG con un supervisor de vSphere with Tanzu.

Precaución

La ClusterClass personalizada es una función experimental de Kubernetes según la documentación de la API del clúster ascendente. Debido a la variedad de personalizaciones disponibles con la ClusterClass personalizada, VMware no puede probar ni validar todas las personalizaciones posibles. Los clientes son responsables de probar, validar y solucionar los problemas que puedan surgir en sus clústeres ClusterClass personalizados. Los clientes pueden abrir tickets de soporte relacionados con sus clústeres ClusterClass personalizados. Sin embargo, el soporte de VMware tan solo puede ayudar dentro de unos límites y no puede garantizar la resolución de todos los problemas que se abran para los clústeres ClusterClass personalizados. Los clientes deben tener en cuenta estos riesgos antes de implementar clústeres ClusterClass personalizados en entornos de producción. Para crear clústeres de carga de trabajo mediante el recurso ClusterClass predeterminado, siga los procedimientos descritos en Pasos para la implementación del clúster.

Requisitos

Para crear una ClusterClass personalizada, debe ytt, imgpkg la CLI de Tanzu y kubectl de forma local. Para obtener información sobre cómo descargar e instalar ytt y imgpkg, consulte Instalar carvel Tools.

Opciones: Plantillas frente a nueva especificación de objeto

Para crear un ClusterClass personalizado, VMware recomienda comenzar con el manifiesto ClusterClass o las plantillas YTT predeterminadas existentes que se describen en Crear un manifiesto ClusterClass base. Cuando se publica una nueva versión del objeto ClusterClass predeterminado, por ejemplo, con una nueva versión de TKG, puede aplicar la superposición a la nueva versión para implementar las mismas personalizaciones. Los procedimientos de este tema describen este método de creación de un objeto ClusterClass personalizado.

Para escribir un objeto ClusterClass completamente nuevo sin usar una plantilla existente, siga el procedimiento descrito en Escribir una ClusterClass en la documentación de la API del clúster.

Crear un manifiesto ClusterClass base

Puede crear un manifiesto ClusterClass base basado en el manifiesto ClusterClass predeterminado o en las plantillas YTT que Tanzu Kubernetes Grid proporciona. Todos los clústeres personalizados que cree deben basarse en este manifiesto ClusterClass base. El proceso tiene 3 pasos:

1. Obtenga el manifiesto ClusterClass predeterminado o las plantillas YTT para la plataforma de destino.
2. Utilice el manifiesto de ClusterClass predeterminado o las plantillas YTT para generar un manifiesto ClusterClass base personalizado que incluya información sobre la infraestructura.
3. Utilice este manifiesto ClusterClass base como la plantilla a partir de la que crear los clústeres personalizados.

Existen tres métodos en los que puede crear un manifiesto ClusterClass base para los clústeres.

• Método 1: Obtenga el manifiesto base de un clúster de administración directamente. Este es el método más sencillo. Cuando se implementa un clúster de administración, se genera automáticamente un manifiesto base predeterminado. Este manifiesto base incluye la configuración de infraestructura que proporcionó al implementar el clúster de administración. Puede utilizarlo como un manifiesto ClusterClass base directamente.
• Método 2: Obtenga plantillas de YTT de la CLI de Tanzu (avanzado). Al instalar la CLI de Tanzu, las plantillas YTT se instalan en el equipo. Para crear un manifiesto base a partir de estas plantillas YTT, debe crear una superposición de YTT que proporcione la configuración de la infraestructura.
• Método 3: Obtenga plantillas YTT del registro de imágenes de TKG (avanzado). También puede obtener las plantillas YTT del registro de imágenes de TKG. Para crear un manifiesto base a partir de estas plantillas YTT, debe crear una superposición de YTT que proporcione la configuración de la infraestructura.

Importante

Los métodos 2 y 3 son para usuarios avanzados que necesitan satisfacer los siguientes casos prácticos:

• Desea generar definiciones de ClusterClass personalizadas para el sistema de CI sin implementar un clúster de administración independiente.
• Desea que los clústeres de carga de trabajo utilicen una infraestructura diferente a los clústeres de administración.

Método 1: Obtenga el manifiesto base de un clúster de administración directamente.

En Tanzu Kubernetes Grid 2.3.0 y versiones posteriores, después de implementar un clúster de administración, puede encontrar el manifiesto ClusterClass predeterminado en la carpeta ~/.config/tanzu/tkg/clusterclassconfigs.

Para ver el manifiesto de las plataformas de destino en las que implementó un clúster de administración, ejecute el siguiente comando:

tree ~/.config/tanzu/tkg/clusterclassconfigs/

Por ejemplo, si implementó un clúster de administración en vSphere, verá el siguiente archivo YAML.

.config/tanzu/tkg/clusterclassconfigs/
└── tkg-vsphere-default-v1.1.1.yaml
 
1 directory, 1 file

El manifiesto generado contiene información sobre la plataforma de destino que se extrajo de la implementación del clúster de administración. Puede utilizar esto como el manifiesto base para la creación de ClusterClass personalizada directamente. Para ver los siguientes pasos, consulte Personalizar el manifiesto ClusterClass base.

Método 2: Obtenga plantillas YTT de la CLI de Tanzu

Después de instalar la CLI de Tanzu v0.90.1 o una versión posterior, pero antes de implementar un clúster de administración, puede encontrar las plantillas YTT para clusterClass predeterminada en la carpeta ~/.config/tanzu/tkg/providers/infrastructure-<provider name>/<provider version>/cconly. Puede utilizar estas plantillas para crear un manifiesto base para la creación personalizada de ClusterClass.

1. Para buscar las plantillas, ejecute el comando adecuado para su plataforma de destino.

   vSphere

   tree ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
   

   Verá los siguientes archivos YAML.

   .config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   
   1 directory, 3 files
   

   AWS

   tree ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
   

   Verá los siguientes archivos YAML.

   .config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   

   Azure

   tree ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
   

   Verá los siguientes archivos YAML.

   .config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   

2. Cree un archivo de valor de datos YTT llamado user_input.yaml con el siguiente contenido.

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   

3. Añada valores de configuración apropiados para su plataforma de destino para user_input.yaml.

   Puede utilizar los valores de configuración que utilizó cuando implementó una implementación de clúster de administración. Por ejemplo, un archivo user_input.yaml para vSphere será similar al siguiente:

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   ENABLE_MHC: true
   ENABLE_MHC_CONTROL_PLANE: true
   ENABLE_MHC_WORKER_NODE: true
   MHC_UNKNOWN_STATUS_TIMEOUT: 5m
   MHC_FALSE_STATUS_TIMEOUT: 12m
   MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
   MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
   NODE_STARTUP_TIMEOUT: 20m
   VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
   VSPHERE_DATACENTER: /dc0
   VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
   VSPHERE_FOLDER: /dc0/vm
   VSPHERE_NETWORK: /dc0/network/VM Network
   VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
   VSPHERE_SERVER: xxx.xxx.xxx.xxx
   VSPHERE_USERNAME: [email protected]
   VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
   VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
   VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
   VSPHERE_WORKER_MEM_MIB: "8192"
   VSPHERE_WORKER_NUM_CPUS: "4"
   VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.1"       # change it to the version in TKG BOM
   NAMESPACE: "tkg-system"                       # DO NOT change it
   

4. Utilice ytt para generar el manifiesto ClusterClass base para la plataforma de destino.

   vSphere

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

   AWS

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

   Azure

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

Ahora que generó un manifiesto base para la infraestructura, para los siguientes pasos, consulte Personalizar el manifiesto ClusterClass base.

Método 3: Obtenga plantillas YTT del registro de imágenes de TKG

Las plantillas YTT de la ClusterClass predeterminada también se pueden descargar del repositorio de imágenes de TKG. Puede utilizar estas plantillas para crear un manifiesto base para la creación personalizada de ClusterClass.

1. Extraiga las plantillas YTT de la imagen providerTemplate en el registro oficial de TKG.

   Para TKG v2.4.0, la etiqueta de imagen providerTemplate es v0.31.0. Para encontrar la versión de la etiqueta en el archivo de lista de materiales de TKG, busque providerTemplateImage.

   imgpkg pull -i projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates:v0.31.0 -o providers
   

   Verá resultados similares al siguiente:

   Pulling image 'projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates@sha256:b210d26c610800f5da4b3aa55bfbc8ffae9275fa2c4073a2b1332e2045a6e1da'
   Extracting layer 'sha256:3ba336232c0e616b2b6c8f263593497c5a059a645f4c6137ea0eb658f4a8538a' (1/1)
   
   Succeeded
   

   Los archivos de plantilla YAML se descargan en una carpeta providers.

2. Cree un archivo de valor de datos YTT llamado user_input.yaml con el siguiente contenido.

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   

3. Añada valores de configuración apropiados para su plataforma de destino para user_input.yaml.

   Puede utilizar los valores de configuración que utilizó cuando implementó una implementación de clúster de administración. Por ejemplo, un archivo user_input.yaml para vSphere será similar al siguiente:

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   ENABLE_MHC: true
   ENABLE_MHC_CONTROL_PLANE: true
   ENABLE_MHC_WORKER_NODE: true
   MHC_UNKNOWN_STATUS_TIMEOUT: 5m
   MHC_FALSE_STATUS_TIMEOUT: 12m
   MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
   MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
   NODE_STARTUP_TIMEOUT: 20m
   VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
   VSPHERE_DATACENTER: /dc0
   VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
   VSPHERE_FOLDER: /dc0/vm
   VSPHERE_NETWORK: /dc0/network/VM Network
   VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
   VSPHERE_SERVER: xxx.xxx.xxx.xxx
   VSPHERE_USERNAME: [email protected]
   VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
   VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
   VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
   VSPHERE_WORKER_MEM_MIB: "8192"
   VSPHERE_WORKER_NUM_CPUS: "4"
   VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.1"       # change it to the version in TKG BOM
   NAMESPACE: "tkg-system"                       # DO NOT change it
   

4. Utilice ytt para generar el manifiesto ClusterClass base para la plataforma de destino.

   vSphere

   ytt -f providers/infrastructure-vsphere/v1.7.0/cconly -f providers/config_default.yaml -f user_input.yaml
   

   AWS

   ytt -f providers/infrastructure-aws/v2.1.3/cconly -f providers/config_default.yaml -f user_input.yaml
   

   Azure

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

Ahora que generó un manifiesto base para la infraestructura, para los siguientes pasos, consulte Personalizar el manifiesto ClusterClass base.

Personalice el manifiesto base de ClusterClass

Para personalizar el manifiesto de ClusterClass, cree archivos de superposición ytt junto con el manifiesto. El siguiente ejemplo muestra cómo modificar un parámetro de kernel de Linux en la definición ClusterClass.

1. Cree una carpeta custom estructurada de la siguiente manera:

   tree custom
   custom
   |-- overlays
       |-- filter.yaml
       |-- kernels.yaml
   

2. Edite custom/overlays/kernels.yaml.

   Por ejemplo, agreguenfConntrackMax como una variable y defina una revisión para él que agregue su valor al parámetro del kernel net.netfilter.nf_conntrack_max para nodos del plano de control.

   Esta superposición anexa un comando al campo preKubeadmCommands, para escribir la configuración en sysctl.conf. Para que ese ajuste surta efecto, puede anexar el comando sysctl -p para aplicar este cambio. Las definiciones predeterminadas de ClusterClass son inmutables, por lo que esta superposición también cambia el nombre de la ClusterClass personalizada y todas sus plantillas agregando -extended.

   cat custom/overlays/kernels.yaml
   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.subset({"kind":"ClusterClass"})
   ---
   apiVersion: cluster.x-k8s.io/v1beta1
   kind: ClusterClass
   metadata:
     name: tkg-vsphere-default-v1.1.1-extended
   spec:
     variables:
     - name: nfConntrackMax
       required: false
       schema:
         openAPIV3Schema:
           type: string
     patches:
     - name: nfConntrackMax
       enabledIf: '{{ not (empty .nfConntrackMax) }}'
       definitions:
         - selector:
             apiVersion: controlplane.cluster.x-k8s.io/v1beta1
             kind: KubeadmControlPlaneTemplate
             matchResources:
               controlPlane: true
           jsonPatches:
             - op: add
               path: /spec/template/spec/preKubeadmCommands/-
               valueFrom:
                 template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
             - op: add
               path: /spec/template/spec/preKubeadmCommands/-
               value: sysctl -p
   

3. Elimine los recursos que no desea cambiar.

   En este ejemplo, todas las plantillas están diseñadas para compartirse entre la instancia de ClusterClass personalizada y predeterminada, de modo que todas se eliminen. También puede crear una plantilla personalizada basada en la plantilla predeterminada de la misma manera, en cuyo caso asegúrese de que no se excluya kind.

   cat custom/overlays/filter.yaml
   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.not_op(overlay.subset({"kind": "ClusterClass"})),expects="0+"
   ---
   #@overlay/remove
   

4. Utilice el manifiesto ClusterClass predeterminado para generar la ClusterClass base.

   ytt -f tkg-vsphere-default-v1.1.1.yaml -f custom/overlays/filter.yaml > default_cc.yaml
   

5. Generar la ClusterClass personalizada.

   ytt -f tkg-vsphere-default-v1.1.1.yaml -f custom/ > custom_cc.yaml
   

6. (Opcional) Compruebe la diferencia entre la ClusterClass predeterminada y la personalizada para confirmar que se aplicaron los cambios.

   diff default_cc.yaml custom_cc.yaml
   

   Verá resultados similares al siguiente:

   4c4
   <   name: tkg-vsphere-default-v1.1.1
   ---
   >   name: tkg-vsphere-default-v1.1.1-extended
   638a639,643
   >   - name: nfConntrackMax
   >     required: false
   >     schema:
   >       openAPIV3Schema:
   >         type: string
   2607a2613,2628
   >   - name: nfConntrackMax
   >     enabledIf: '{{ not (empty .nfConntrackMax) }}'
   >     definitions:
   >     - selector:
   >         apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   >         kind: KubeadmControlPlaneTemplate
   >         matchResources:
   >           controlPlane: true
   >       jsonPatches:
   >       - op: add
   >         path: /spec/template/spec/preKubeadmCommands/-
   >         valueFrom:
   >           template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
   >       - op: add
   >         path: /spec/template/spec/preKubeadmCommands/-
   >         value: sysctl -p
   

En este ejemplo, puede ver que -extended se agregó al nombre del clúster.

Instalar ClusterClass personalizada en el clúster de administración

Para permitir que su clúster de administración use su ClusterClass personalizada, instálelo aplicando el nuevo manifiesto.

1. Aplique el manifiesto de ClusterClass.

   kubectl apply -f custom_cc.yaml
   

   Debe ver el siguiente resultado.

   clusterclass.cluster.x-k8s.io/tkg-vsphere-default-v1.1.1-extended created
   

2. Compruebe si la ClusterClass personalizada se propagó al espacio de nombres predeterminado, por ejemplo:

   kubectl get clusterclass
   

   Debe ver el siguiente resultado.

   NAME                                  AGE
   tkg-vsphere-default-v1.1.1            2d23h
   tkg-vsphere-default-v1.1.1-extended   11s
   

Generar manifiesto de clúster de carga de trabajo personalizado

Después de crear la instancia de ClusterClass personalizada, puede utilizarla para crear un nuevo clúster de carga de trabajo que incluya la personalización.

1. Ejecute tanzu cluster create con la opción --dry-run para generar un manifiesto de clúster a partir de un archivo de configuración de clúster estándar.

   tanzu cluster create --file workload-1.yaml --dry-run > default_cluster.yaml
   

2. Cree una superposición de ytt o edite el manifiesto del clúster directamente.

   La opción recomendada es crear una superposición de ytt (por ejemplo, cluster_overlay.yaml) para hacer lo siguiente:

   • Reemplace el valor topology.class con el nombre de la ClusterClass personalizada
   • Añada las variables personalizadas al bloque variables, con un valor predeterminado

   Al igual que con la modificación de especificaciones de objetos ClusterClass, el uso de una superposición de la siguiente manera permite aplicar automáticamente los cambios a los objetos nuevos cada vez que hay una nueva versión de clúster ascendente.

   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.subset({"kind":"Cluster"})
   ---
   apiVersion: cluster.x-k8s.io/v1beta1
   kind: Cluster
   spec:
     topology:
       class: tkg-vsphere-default-v1.1.1-extended
       variables:
       - name: nfConntrackMax
         value: "1048576
   

3. Genere el manifiesto custom_cluster.yaml:

   ytt -f default_cluster.yaml -f cluster_overlay.yaml > custom_cluster.yaml
   

4. (Opcional) Al igual que con la ClusterClass anterior, puede ejecutar diff para comparar el manifiesto del clúster de clase personalizada con un clúster basado en clases predeterminado, por ejemplo:

   diff custom_cluster.yaml default_cluster.yaml
   

   Verá resultados similares al siguiente:

   <     class: tkg-vsphere-default-v1.1.1
   ---
   >     class: tkg-vsphere-default-v1.1.1-extended
   142a143,144
   >     - name: nfConntrackMax
   >       value: "1048576"
   

Crear un clúster personalizado

Cree un clúster de carga de trabajo personalizado basado en el manifiesto personalizado generado anteriormente de la siguiente manera.

1. Cree el clúster.

   tanzu cluster create -f custom_cluster.yaml
   

2. Compruebe las propiedades del objeto creado.

   Por ejemplo, con la modificación del kernel anterior, recupere el objeto KubeadmControlPlane y confirme que la configuración del kernel está establecida:

   kubectl get kcp workload-1-jgwd9 -o yaml
   

   Verá resultados similares al siguiente:

   apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   kind: KubeadmControlPlane
   ...
       preKubeadmCommands:
       - hostname "{{ ds.meta_data.hostname }}"
       - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
       - echo "127.0.0.1   localhost" >>/etc/hosts
       - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
       - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
       - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
       - sysctl -p
   ...
   

3. Inicie sesión en un nodo de plano de control y confirme que su sysctl.conf se haya modificado:

   capv@workload-1-jgwd9:~$ sudo cat /etc/sysctl.conf
   ...
   net.ipv6.neigh.default.gc_thresh3=16384
   fs.file-max=9223372036854775807
   net.netfilter.nf_conntrack_max=1048576
   

Actualizar clústeres personalizados

Si creó clústeres personalizados con una versión anterior, puede actualizarlos a la versión más reciente de TKG.

Preparar para actualizar los clústeres

Antes de actualizar los clústeres, hay que realizar los pasos de preparación.

1. Antes de actualizar el clúster de administración, cree clústeres de prueba con la versión del manifiesto personalizado que creó para la versión anterior.

   Por ejemplo, cree un clúster personalizado llamado test-upgrade.

2. Obtenga información sobre las versiones de ClusterClass disponibles con el clúster de administración de TKG 2.2.

   kubectl get clusterclass
   

   Si creó los clústeres personalizados con TKG v2.2.0, la versión de ClusterClass debe ser 1.0.0. Por ejemplo:

   NAME                                  AGE
   tkg-vsphere-default-extended-v1.0.0   21m
   tkg-vsphere-default-v1.0.0            10d
   

3. Obtenga la información sobre las versiones de ClusterClass que se ejecutan en el clúster de test-upgrade.

   kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
   

   Los resultados deben ser tkg-vsphere-default-extended-v1.0.0 .

4. Siga las instrucciones en Actualizar clústeres de administración independientes para actualizar el clúster de administración a TKG 2.4.

5. Obtenga información sobre la versión ClusterClass disponible después de actualizar el clúster de administración a la versión 2.4.

   kubectl get cluster mgmt-cluster-name -n tkg-system -o jsonpath='{.spec.topology.class}'
   

   El resultado debe ser tkg-vsphere-default-v1.1.1 si el clúster de administración se ejecuta en vSphere.

6. Siga los procedimientos en Crear un manifiesto de clase de clúster básico y Personalizar su manifiesto de ClusterClass base para crear una nueva versión de su manifiesto de ClusterClass.
   • Por ejemplo, asigne el nombre ClusterClass personalizado tkg-vsphere-default-v1.1.1-extended e incluya las mismas variables personalizadas que en la versión anterior tkg-vsphere-default-extended-v1.0.0.
   • Asígnele un nombre al nuevo custom_cc.yaml de superposición.

7. Instalar la nueva ClusterClass personalizada en el clúster de administración.

   kubectl apply -f custom_cc.yaml
   

8. Obtenga información sobre las versiones de ClusterClass que ahora están disponibles con el clúster de administración.

   kubectl get clusterclass
   

   Se deben mostrar tanto las versiones anteriores como las versiones más recientes.

   NAME                                  AGE
   tkg-vsphere-default-extended-v1.0.0   61m
   tkg-vsphere-default-v1.0.0            10d
   tkg-vsphere-default-v1.1.1            25m
   tkg-vsphere-default-v1.1.1-extended   15s
   

Realizar la actualización

Después de realizar los pasos de preparación, puede probar la actualización en el clúster de prueba antes de actualizar los clústeres de producción.

1. Vuelva a base el clúster test-upgrade de la versión anterior de la ClusterClass personalizada a la nueva.

   kubectl patch cluster test-upgrade --type merge -p '{"spec": {"topology": {"class": "tkg-vsphere-default-v1.1.1-extended"}}}'   
   

   Los resultados deben ser cluster.cluster.x-k8s.io/test-upgrade patched .

2. Obtenga la información sobre la versión ClusterClass que se está ejecutando en el clúster de test-upgrade.

   kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
   

   Los resultados deben ser tkg-vsphere-default-v1.1.1-extended . Anteriormente, era tkg-vsphere-default-extended-v1.0.0.

3. Espere varios minutos y ejecute kubectl get cluster hasta que vea que UpdatesAvailable se actualizó a true.

   kubectl get cluster test-upgrade -o yaml
   

   Cuando esté listo, debería aparecer un mensaje similar al siguiente en la salida:

   ...
   status:
     conditions:
   ...
     - lastTransitionTime: "2023-06-19T09:59:21Z"
       message: '[v1.25.9+vmware.1-tkg.1-20230609 v1.26.4+vmware.1-tkg.1-20230609]'
       status: "True"
       type: UpdatesAvailable
     controlPlaneReady: true
     infrastructureReady: true
     observedGeneration: 5
     phase: Provisioned
   

4. Actualice el clúster de test-upgrade.

   tanzu cluster upgrade test-upgrade    
   

5. Compruebe las propiedades del objeto creado.

   Por ejemplo, con la modificación del kernel descrita en el ejemplo anterior, recupere el objeto KubeadmControlPlane y confirme que la configuración del kernel está establecida:

   kubectl get kcp test-upgrade-nsc6d -o yaml
   

   Verá resultados similares al siguiente:

   apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   kind: KubeadmControlPlane
   ...
       preKubeadmCommands:
       - hostname "{{ ds.meta_data.hostname }}"
       - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
       - echo "127.0.0.1   localhost" >>/etc/hosts
       - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
       - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
       - sed -i 's|".*/pause|"projects-stg.registry.vmware.com/tkg/pause|' /etc/containerd/config.toml
       - systemctl restart containerd
       - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
       - sysctl -p  
   

Actualizar clústeres de producción

Si la actualización de prueba se realizó correctamente, repita los pasos de Realizar la actualización en los clústeres de producción.

Nota

Si se produce algún error durante la actualización, puede revertir volviendo a equilibrar el clúster de la nueva versión de ClusterClass personalizada a la versión anterior.

Vuelva a base un clúster predeterminado para utilizar una ClusterClass personalizada

Si creó clústeres con la ClusterClass predeterminada y desea actualizarlos para utilizar una ClusterClass personalizada, utilice kubectl para editar el objeto Cluster:

• Cambie spec.topology.class al nombre del manifiesto de ClassClass personalizada.
• Modifique spec.topology.variables para anexar las variables personalizadas.

Vuelva a base un clúster personalizado para utilizar la ClusterClass predeterminada

Si desea revertir a una nueva versión de la ClusterClass predeterminada:

• Cambie spec.topology.class a la nueva versión de la ClusterClass predeterminada.
• Modifique spec.topology.variables para eliminar las variables personalizadas. Es posible que deba agregar nuevas variables definidas en la nueva versión de ClusterClass predeterminada.