Actualizar una versión de Tanzu Kubernetes después de convertir la especificación del clúster a la API v1alpha2 de TKGS

Después de convertir automáticamente una especificación de clúster de Tanzu Kubernetes al formato de API v1alpha2, para realizar una actualización gradual del clúster de Tanzu Kubernetes, que normalmente se realiza cambiando la versión de Tanzu Kubernetes, es posible que deba realizar algún procesamiento previo de la especificación del clúster para evitar errores.

Conversión automática de especificaciones de clústeres

Para actualizar el entorno de vSphere with Tanzu a la API v1alpha2 de servicio Tanzu Kubernetes Grid, actualice el clúster supervisor donde se ejecuta el servicio.

Una vez que servicio Tanzu Kubernetes Grid ejecuta la API v1alpha2, el sistema convierte automáticamente todas las especificaciones del clúster de Tanzu Kubernetes existentes del formato v1alpha1 al formato v1alpha2. Durante el proceso de conversión automática, el sistema crea y rellena los campos esperados para cada manifiesto del clúster. Desusos y adiciones de la API enumera los campos de especificación del clúster que son nuevos y obsoletos en la API v1alpha2.

Para actualizar la versión de Tanzu Kubernetes para un clúster cuyo manifiesto se ha convertido automáticamente al formato v1alpha2, debe realizar un procesamiento previo manual para evitar errores. Ejemplos de actualización del clúster enumera varias opciones.

Desusos y adiciones de la API

En la tabla se enumeran los ajustes de especificación del clúster que están obsoletos en la API v1alpha2 y que se reemplazan por una nueva configuración.

Configuración obsoleta	Nueva configuración	Comentarios
`spec.distribution.version` `spec.distribution.fullVersion`	`spec.topology.controlPlane.tkr.refernece.name` `spec.topology.nodePools[*].tkr.reference.name`	Debe utilizar el formato TKR NAME. Consulte los ejemplos.
`spec.topology.workers`	`spec.topology.nodePools[*]`	En un clúster convertido, el bloque `spec.topology.workers` se convierte en `spec.topology.nodePools[0]`. La primera entrada de la lista de `nodePools` es `name: workers`.
`spec.topology.controlPlane.count` `spec.topology.workers.count`	`spec.topology.controlPlane.replicas` `spec.topology.nodePools[*].replicas`	`count` se reemplaza con `replicas`
`spec.topology.controlPlane.class` `spec.topology.workers.class`	`spec.topology.controlPlane.vmClass` `spec.topology.nodePools[*].vmClass`	`class` se reemplaza con `vmClass`
N/C	`spec.topology.nodePools[*].labels`	Valores de par de claves opcionales para organizar y categorizar objetos; las etiquetas se propagan a los nodos creados
N/C	`spec.topology.nodePools[*].taints`	Manchas opcionales para registrar los nodos; las manchas definidas por el usuario se propagan a los nodos creados

Se requiere el formato TKR NAME

Además de que los campos spec.distribution.version están obsoletos, no se admite el formato DISTRIBUTION para especificar la versión de Tanzu Kubernetes. Esto significa que no se pueden utilizar los siguientes formatos de cadena para hacer referencia a la versión de destino: 1.21.2+vmware.1-tkg.1.ee25d55, 1.21.2 y 1.21.

Al hacer referencia a la versión de Tanzu Kubernetes en una especificación de clúster de API v1alpha2, debe utilizar el formato TKR NAME, no el formato obsoleto DISTRIBUTION. A pesar de que el formato obsoleto se muestra en la columna ACTUALIZACIONES DISPONIBLES, el único formato admitido es el que aparece en la columna TKR NAME.

kubectl get tanzukubernetescluster
NAMESPACE        NAME            CONTROL PLANE   WORKER   TKR NAME                             AGE    READY   TKR COMPATIBLE   UPDATES AVAILABLE
tkgs-cluster-1   test-cluster    3               3        v1.21.2---vmware.1-tkg.1.ee25d55     38h    True    True             [1.21.2+vmware.1-tkg.1.ee25d55]

Usar kubectl edit para actualizar una especificación de clúster

Si necesita realizar modificaciones en una especificación de clúster para que cumpla con la API v1alpha2 de TKGS, utilice el método kubectl edit. No intente utilizar el método kubectl patch para este tipo de actualización. Consulte Métodos para editar el manifiesto del clúster. Para configurar kubectl con un editor, consulte Especificar un editor de texto predeterminado para Kubectl.

Ejemplos de actualización del clúster

Debido a que cambiar spec.distribution.version es la forma más común de activar una actualización gradual del clúster (consulte Actualizar clústeres de Tanzu Kubernetes), y este campo está obsoleto en la API v1alpha2, existen algunas consideraciones que se deben tener en cuenta y algunas recomendaciones de procesamiento previo que se deben seguir para evitar posibles problemas de actualización del clúster.

Los siguientes ejemplos demuestran cómo actualizar la versión de un clúster de Tanzu Kubernetes que se aprovisionó mediante la API v1alpha1 a un sistema que ejecuta la API v1alpha2.

Ejemplo de actualización de clúster 1: Usar una sola referencia de TKR NAME en el plano de control

El enfoque recomendado es eliminar todos los bloques nodePools[*].tkr.reference.name de la especificación convertida y actualizar controlPlane.tkr.reference.name con el TKR NAME de la versión de destino. En este caso, la misma versión de Tanzu Kubernetes se propaga a todos los nodos nodePools[*].

En el futuro, las versiones de Tanzu Kubernetes pueden ser diferentes entre controlPlane y nodePools[*]. Actualmente, sin embargo, todas las versiones de un clúster deben coincidir, por lo que basta con colocar una sola referencia de TKR NAME en controlPlane.

Por ejemplo:

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example1
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium

Ejemplo de actualización de clúster 2: Usar una referencia de TKR NAME para cada grupo de nodos

El segundo ejemplo es colocar TKR NAME en el bloque tkr.reference.name para las topologías controlPlane y nodePools[*].

Este enfoque tiene la ventaja de estar listo para futuras versiones cuando la versión de Tanzu Kubernetes puede ser diferente en todos los grupos de nodos. Actualmente, deben coincidir.

Por ejemplo:

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example2
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55

Ejemplo de actualización de clúster 3: Usar campos de distribución obsoletos

La opción final es utilizar los campos obsoletos spec.distribution.fullVersion y spec.distribution.version, y eliminar manualmente todos los bloques tkr.reference.name. Debe incluir ambos campos con uno con el formato TKR NAME y el otro anulado. No se admiten accesos directos de versiones como v1.21.2 y v1.21.

Nota: Para la versión de Tanzu Kubernetes en Ubuntu, no se admite el uso de spec.distribution.version.

En el siguiente ejemplo, se utiliza fullVersion con TKR NAME y un valor nulo (vacío) en el campo version. Se eliminan todas las entradas tkr.reference.name.

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3a
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: v1.21.2---vmware.1-tkg.1.ee25d55
    version: ""
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium

Como alternativa, puede utilizar el campo version con TKR NAME y un valor nulo (vacío) en el campo fullVersion. Aunque esté utilizando el campo version, no se admiten accesos directos de versiones. Se eliminan todas las entradas tkr.reference.name.

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3b
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: ""
    version: v1.21.2---vmware.1-tkg.1.ee25d55
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium