Parámetros de configuración para clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1

La API declarativa de servicio Tanzu Kubernetes Grid expone varios parámetros para configurar clústeres de Tanzu Kubernetes. Consulte la lista y la descripción de todos los parámetros, y las directrices de uso para aprovisionar y personalizar los clústeres.

YAML con anotaciones para aprovisionar un clúster de Tanzu Kubernetes

El YAML con anotaciones enumera todos los parámetros disponibles para aprovisionar un clúster de Tanzu Kubernetes y tiene comentarios resumidos para cada campo.

Nota: El YAML con anotaciones no se valida para aprovisionar un clúster. Consulte los ejemplos para obtener instrucciones sobre ese tema: Ejemplos del aprovisionamiento de clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: <tanzu kubernetes cluster name>
  namespace: <vsphere namespace where the cluster will be provisioned>
spec:
  distribution:
    version: <tanzu kubernetes release version string: full, point, short>      
  topology:                               
    controlPlane:
      count: <integer either 1 or 3>
      class: <vm class bound to the target vsphere namespace>
      storageClass: <vsphere storage policy bound to the target vsphere namespace>
      volumes: #optional setting for high-churn control plane component (such as etcd)
        - name: <user-defined string>
          mountPath: </dir/path>
          capacity:
            storage: <size in GiB> 
    workers:                              
      count: <integer from 0 to 150>
      class: <vm class bound to the target vsphere namespace>
      storageClass: <vsphere storage policy bound to the target vsphere namespace>
      volumes: #optional setting for high-churn worker node component (such as containerd)
        - name: <user-defined string>
          mountPath: </dir/path>
          capacity:
            storage: <size in GiB>              
  settings: #all spec.settings are optional
    storage: #optional storage settings
      classes: [<array of kubernetes storage classes for dynamic pvc provisioning>]
      defaultClass: <default kubernetes storage class>
    network: #optional network settings
      cni: #override default cni set in the tkgservicesonfiguration spec
        name: <antrea or calico>
      pods: #custom pod network
        cidrBlocks: [<array of pod cidr blocks>]
      services: #custom service network
        cidrBlocks: [<array of service cidr blocks>]
      serviceDomain: <custom service domain>
      proxy: #proxy server for outbound connections
        httpProxy: http://<IP:PORT> 
        httpsProxy: http://<IP:PORT>
        noProxy: [<array of CIDRs to not proxy>]
      trust: #trust fields for custom public certs for tls
        additionalTrustedCAs:
          - name: <first-cert-name>
            data: <base64-encoded string of PEM encoded public cert 1>
          - name: <second-cert-name>
            data: <base64-encoded string of PEM encoded public cert 2>

Parámetros para aprovisionar clústeres de Tanzu Kubernetes

En la tabla se enumeran y describen todos los parámetros y los valores aceptables para aprovisionar un clúster de Tanzu Kubernetes. Para ver ejemplos, consulte Ejemplos de configuración de la API de servicio Tanzu Kubernetes Grid v1alpha1.

Tabla 1. Parámetros para aprovisionar clústeres de Tanzu Kubernetes
Nombre	Valor	Descripción
`apiVersion`	`run.tanzu.vmware.com/v1alpha1`	Especifica la versión de la API del servicio Tanzu Kubernetes Grid.
`kind`	`TanzuKubernetesCluster`	Especifica el tipo de recurso de Kubernetes que se debe crear. El único valor permitido es `TanzuKubernetesCluster` (distingue entre mayúsculas y minúsculas).
`metadata`	Sección para los metadatos del clúster	Incluye metadatos del clúster, como `name` y `namespace`. Estos son metadatos estándar de Kubernetes, por lo que puede utilizar `generateName` en lugar de `name`, agregar etiquetas y anotaciones, etc.
`name`	Una cadena definida por el usuario que acepta caracteres alfanuméricos y guiones (por ejemplo, `my-tkg-cluster-1`)	Especifica el nombre del clúster que se creará. Restricciones de nomenclatura actuales del clúster: El nombre debe tener 41 caracteres o menos. El nombre debe comenzar con una letra. El nombre puede contener letras, números y guiones. El nombre debe terminar con una letra o un número.
`namespace`	Una cadena definida por el usuario que acepta caracteres alfanuméricos y guiones (por ejemplo, `my-sns-1`)	Identifica el nombre del espacio de nombres de supervisor en el que se implementará el clúster. Esta es una referencia a un espacio de nombres de supervisor que existe en el clúster supervisor.
`spec`	Sección para las especificaciones técnicas del clúster	Incluye la especificación (expresada de manera declarativa) para el estado final del clúster, incluidas las instancias de `toplogy` del nodo y de `distribution` del software de Kubernetes.
`distribution`	Sección para especificar la versión de Tanzu Kubernetes Release	Indica la distribución del clúster: el software de clústeres de Tanzu Kubernetes instalado en el plano de control y los nodos de trabajo, incluido Kubernetes.
`version`	Una cadena alfanumérica con guiones que representa la versión de Kubernetes (por ejemplo, `v1.20.2+vmware.1-tkg.1`, `v1.20.2` o `v1.20`)	Especifica la versión de software de la distribución de Kubernetes que se instalará en los nodos del clúster mediante una notación de versión semántica. Puede especificar la versión completa o utilizar abreviaturas de versiones, como "version: v1.20.2", que se resuelve como la imagen más reciente que coincide con esa versión de revisión, o como "version: v1.20", que se resuelve como la versión de revisión que coincide más reciente. La versión resuelta se muestra como "fullVersion" en la descripción del clúster después de crearla.
`topology`	Sección para topologías de nodo del clúster	Incluye campos en los que se describen la cantidad, el propósito y la organización de nodos del clúster, así como los recursos asignados a cada uno. Los nodos del clúster se colocan en grupos en función de su propósito previsto: `control-plane` o `worker`. Cada grupo es homogéneo, tiene la misma asignación de recursos y utiliza el mismo almacenamiento.
`controlPlane`	Sección para la configuración del plano de control	Especifica la topología del plano de control del clúster, incluidos el número de nodos (`count`), el tipo de máquina virtual (`class`) y los recursos de almacenamiento asignados a cada nodo (`storageClass`).
`count`	Un entero igual a `1` o `3`	Especifica el número de nodos del plano de control. El plano de control debe tener un número impar de nodos.
`class`	Un elemento definido por el sistema en forma de cadena de un conjunto enumerado (por ejemplo, `guaranteed-small` o `best-effort-large`)	Especifica el nombre del elemento VirtualMachineClass que describe la configuración de hardware virtual que se utilizará en cada nodo del grupo. Esto controla el hardware disponible para el nodo (CPU y memoria), así como las solicitudes y los límites de dichos recursos. Consulte Clases de máquina virtual para clústeres de Tanzu Kubernetes.
`storageClass`	`node-storage` (por ejemplo)	Identifica la clase de almacenamiento que se utilizará para almacenar los discos que contienen los sistemas de archivos raíz de los nodos de plano de control. Ejecute `kubectl describe ns` en el espacio de nombres para ver las clases de almacenamiento disponibles. Las clases de almacenamiento disponibles para el espacio de nombres varían según el almacenamiento que establece el administrador de vSphere. Las clases de almacenamiento asociadas con el espacio de nombres de supervisor se replican en el clúster. En otras palabras, la clase de almacenamiento debe estar disponible en el espacio de nombres de supervisor para que sea un valor válido para este campo. Consulte Configurar y administrar los espacios de nombres de vSphere.
`volumes`	Configuración de almacenamiento opcional volúmenes: nombre: `string` mountPath: `/dir/path` capacidad almacenamiento: tamaño de GiB	Puede especificar parámetros de almacenamiento y disco independientes para etcd en los nodos del plano de control. Consulte el ejemplo Clúster con discos y parámetros de almacenamiento independientes.
`workers`	Sección para la configuración de nodos de trabajo	Especifica la topología de los nodos de trabajo del clúster, incluidos el número de nodos (`count`), el tipo de máquina virtual (`class`) y los recursos de almacenamiento asignados a cada nodo (`storageClass`).
`count`	Un entero entre 0 y 150 (por ejemplo, `1`, `2` o `7`)	Especifica la cantidad de nodos de trabajo del clúster. Se puede crear un clúster con cero nodos de trabajo, lo que permite que un clúster solo tenga nodos de plano de control. No hay ningún máximo absoluto para la cantidad de nodos de trabajo, pero 150 es un límite razonable. Nota: A un clúster aprovisionado con 0 nodos de trabajo no se le asigna ningún servicio de equilibrador de carga.
`class`	Un elemento definido por el sistema en forma de cadena de un conjunto enumerado (por ejemplo, `guaranteed-small` o `best-effort-large`)	Especifica el nombre del elemento VirtualMachineClass que describe la configuración de hardware virtual que se utilizará en cada nodo del grupo. Esto controla el hardware disponible para el nodo (CPU y memoria), así como las solicitudes y los límites de dichos recursos. Consulte Clases de máquina virtual para clústeres de Tanzu Kubernetes.
`storageClass`	`node-storage` (por ejemplo)	Identifica la clase de almacenamiento que se utilizará para almacenar los discos que contienen los sistemas de archivos raíz de los nodos de trabajo. Ejecute `kubectl describe ns` en el espacio de nombres para enumerar las clases de almacenamiento disponibles. Las clases de almacenamiento disponibles para el espacio de nombres varían según el almacenamiento que establece el administrador de vSphere. Las clases de almacenamiento asociadas con el espacio de nombres de supervisor se replican en el clúster. En otras palabras, la clase de almacenamiento debe estar disponible en el espacio de nombres de supervisor para que sea válida. Consulte Configurar y administrar los espacios de nombres de vSphere.
`volumes`	Configuración de almacenamiento opcional volúmenes: nombre: `string` mountPath: `/dir/path` capacidad almacenamiento: tamaño de GiB	Puede especificar parámetros de almacenamiento y disco independientes para las imágenes de contenedor en los nodos de trabajo. Consulte el ejemplo Clúster con discos y parámetros de almacenamiento independientes.
`settings`	Sección para la configuración específica del clúster; todas las `spec.settings` son opcionales	Identifica la información de configuración de tiempo de ejecución opcional del clúster, incluidos los detalles de la instancia de `network` del nodo y la instancia persistente de `storage` de los pods.
`storage`	Sección para especificar almacenamiento	Identifica las entradas de almacenamiento de volumen persistente (Persistent Volume, PV) para las cargas de trabajo de contenedor.
`classes`	Una matriz de una o varias cadenas definidas por el usuario (por ejemplo, `["gold", "silver"]`)	Especifica clases de almacenamiento de volumen persistente (Persistent Volume, PV) con nombre para las cargas de trabajo de contenedor. Las clases de almacenamiento asociadas con el espacio de nombres de supervisor se replican en el clúster. En otras palabras, la clase de almacenamiento debe estar disponible en el espacio de nombres de supervisor para que sea un valor válido. Consulte el ejemplo Clúster con clases de almacenamiento y una clase predeterminada para volúmenes persistentes.
`defaultClass`	`silver` (por ejemplo)	Especifica una clase de almacenamiento con nombre que se anotará como valor predeterminado en el clúster. Si no la especifica, no habrá ningún valor predeterminado. No se tienen que especificar una o varias instancias de `classes` para especificar una instancia de `defaultClass`. Es posible que algunas cargas de trabajo requieran una clase predeterminada, como Helm. Consulte el ejemplo Clúster con clases de almacenamiento y una clase predeterminada para volúmenes persistentes.
`network`	Marcador de sección para la configuración de redes	Especifica la configuración relacionada con la red del clúster.
`cni`	Marcador de sección para especificar la CNI	Identifica el complemento de interfaz de redes del contenedor (Container Networking Interface, CNI) del clúster. El valor predeterminado es Antrea, por lo que no es necesario especificarlo en los clústeres nuevos.
`name`	Cadena `antrea` o `calico`	Especifica la CNI que se utilizará. Las posibles opciones son Antrea y Calico. La configuración del sistema establece Antrea como la CNI predeterminada. El valor predeterminado de la CNI se puede cambiar. Si utiliza el valor predeterminado, no necesita especificar este campo.
`services`	Marcador de sección para especificar subredes de servicios de Kubernetes	Identifica la configuración de red de los servicios de Kubernetes. El valor predeterminado es 10.96.0.0/12.
`cidrBlocks`	Matriz `["198.51.100.0/12"]` (por ejemplo)	Especifica un rango de direcciones IP que se puede usar para los servicios de Kubernetes. El valor predeterminado es 10.96.0.0/12. No debe superponerse con la configuración elegida para el clúster supervisor. A pesar de que este campo es una matriz que permite varios rangos, de momento solo se permite un rango de IP único. Consulte los ejemplos de redes en Ejemplos del aprovisionamiento de clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1.
`pods`	Marcador de sección para especificar subredes de pods de Kubernetes	Especifica la configuración de red de los pods. El valor predeterminado es 192.168.0.0/16. El tamaño mínimo de bloque es /24.
`cidrBlocks`	Matriz `["192.0.2.0/16"]` (por ejemplo)	Especifica un rango de direcciones IP que se puede usar para los pods de Kubernetes. El valor predeterminado es 192.168.0.0/16. No debe superponerse con la configuración elegida para el clúster supervisor. El tamaño de la subred de pods debe ser igual o mayor que/24. A pesar de que este campo es una matriz que permite varios rangos, de momento solo se permite un rango de IP único. Consulte los ejemplos de redes en Ejemplos del aprovisionamiento de clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1.
`serviceDomain`	`"cluster.local"`	Especifica el dominio de servicio del clúster. El valor predeterminado es `cluster.local`.
`proxy`	Sección que especifica la configuración de proxy HTTP(s) para el clúster. Si se implementa, todos los campos son obligatorios.	Proporciona campos para la configuración del proxy especificado; se rellenará automáticamente si se configura un proxy global y no se configura un proxy de clúster individual. Consulte el ejemplo Clúster con un servidor proxy.
`httpProxy`	`http://<user>:<pwd>@<ip>:<port>`	Especifica una URL de proxy que se utilizará para crear conexiones HTTP fuera del clúster.
`httpsProxy`	`http://<user>:<pwd>@<ip>:<port>`	Especifica una URL de proxy que se utilizará para crear conexiones HTTPS fuera del clúster.
`noProxy`	Matriz de bloques CIDR que no utilizarán proxy, por ejemplo: `[10.246.0.0/16,192.168.144.0/20,192.168.128.0/20]`. Obtenga los valores necesarios de la red de carga de trabajo en el clúster supervisor: `Pod CIDRs`, `Ingress CIDRs` y `Egress CIDRs`. Consulte la imagen a continuación para ver los valores que se deben incluir en el campo de matriz `noProxy`.	No debe utilizar proxy con las subredes utilizadas por la red de carga de trabajo en el clúster supervisor para pods, entrada y salida. No es necesario incluir el CIDR de servicios del clúster supervisor en el campo `noProxy`. Los clústeres de Tanzu Kubernetes no interactúan con dichos servicios. Los endpoints `localhost` y `127.0.0.1` automáticamente no se usan como proxy. No es necesario que los agregue al campo `noProxy`. Los CIDR de pod y de servicio para los clústeres de Tanzu Kubernetes no se usan como proxy automáticamente. No es necesario que los agregue al campo `noProxy`. Consulte el ejemplo Clúster con un servidor proxy.
`trust`	Marcador de sección para los parámetros de `trust`.	No acepta datos.
`additionalTrustedCAs`	Acepta una matriz de certificados con `name` y `data` para cada uno.	No acepta datos.
`name`	Cadena	El nombre del certificado de TLS.
`data`	Cadena	La cadena codificada en base64 de un certificado público con codificación PEM.

Obtenga los valores de noProxy requeridos de la red de carga de trabajo del clúster supervisor como se muestra en la imagen.

La ventana Red de carga de trabajo con los valores de CIDR del pod, CIDR de ingreso y CIDR de egreso destacados.