Ejemplos del aprovisionamiento de clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1

La API de servicio Tanzu Kubernetes Grid proporciona valores predeterminados inteligentes y una gama de opciones para personalizar clústeres de Tanzu Kubernetes. Consulte los ejemplos para aprovisionar clústeres de varios tipos con configuraciones y personalizaciones diferentes para satisfacer sus necesidades.

YAML mínimo para el aprovisionamiento de un clúster de Tanzu Kubernetes

El siguiente ejemplo de YAML es la configuración mínima necesaria para invocar servicio Tanzu Kubernetes Grid y aprovisionar un clúster de Tanzu Kubernetes que utiliza todas las opciones de configuración predeterminadas.

Las características del YAML mínimo de ejemplo incluyen:

La versión de versión de Tanzu Kubernetes, que aparece como v1.19, se resolverá en la distribución más reciente que coincida con esa versión secundaria, por ejemplo, v1.19.7+vmware.1-tkg.1.xxxxxx. Consulte Comprobar la compatibilidad del clúster de Tanzu Kubernetes para actualizar.
La clase de máquina virtual best-effort-<size> no tiene reservas. Para obtener más información, consulte Clases de máquina virtual para clústeres de Tanzu Kubernetes.
El clúster no incluye almacenamiento persistente para los contenedores. Si es necesario, se establece en spec.settings.storage. Consulte el ejemplo de almacenamiento a continuación.
Es posible que algunas cargas de trabajo, como Helm, requieran una spec.settings.storage.defaultClass. Consulte el ejemplo de almacenamiento a continuación.
No se especificó la sección spec.settings.network. Esto significa que el clúster utiliza la siguiente configuración de red predeterminada:
- CNI predeterminada: antrea
- CIDR de pod predeterminado: 192.168.0.0/16
- CIDR de servicios predeterminados: 10.96.0.0/12
- Dominio de servicio predeterminado: cluster.local
Nota: El rango de IP predeterminado para los pods es 192.168.0.0/16. Si esta subred ya está en uso, debe especificar un rango de CIDR diferente. Consulte los ejemplos de redes personalizadas que aparecen a continuación.

apiVersion: run.tanzu.vmware.com/v1alpha1      #TKGS API endpoint
kind: TanzuKubernetesCluster                   #required parameter
metadata:
  name: tkgs-cluster-1                         #cluster name, user defined
  namespace: tgks-cluster-ns                   #vsphere namespace
spec:
  distribution:
    version: v1.20                             #Resolves to latest TKR 1.20
  topology:
    controlPlane:
      count: 1                                 #number of control plane nodes
      class: best-effort-medium                #vmclass for control plane nodes
      storageClass: vwt-storage-policy         #storageclass for control plane
    workers:
      count: 3                                 #number of worker nodes
      class: best-effort-medium                #vmclass for worker nodes
      storageClass: vwt-storage-policy         #storageclass for worker nodes

Clúster con discos y parámetros de almacenamiento independientes

En el siguiente ejemplo de YAML se muestra cómo aprovisionar un clúster con discos y parámetros de almacenamiento independientes para los nodos de trabajo y el plano de control del clúster.

Al usar discos y parámetros de almacenamiento independientes para los datos de renovación alta, se minimiza la sobrecarga de lectura-escritura relacionada con el uso de los clones vinculados, entre otras ventajas. Existen dos casos prácticos principales:

Personalizar el rendimiento del almacenamiento en nodos del plano de control para la base de datos de etcd
Personalizar el tamaño del disco para las imágenes de contenedor en los nodos de trabajo

El ejemplo tiene las siguientes características:

La configuración de spec.topology.controlPlane.volumes especifica el volumen independiente para la base de datos de etcd.
La configuración de spec.topology.workers.volumes especifica el volumen independiente para las imágenes de contenedor.
mountPath: /var/lib/containerd para las imágenes de contenedor es compatible con las versiones 1.17 de Tanzu Kubernetes y otras posteriores.

apiVersion: run.tanzu.vmware.com/v1alpha1      
kind: TanzuKubernetesCluster                   
metadata:
  name: tkgs-cluster-5                         
  namespace: tgks-cluster-ns                   
spec:
  distribution:
    version: v1.20                            
  topology:
    controlPlane:
      count: 3                                 
      class: best-effort-medium                 
      storageClass: vwt-storage-policy
      volumes:
        - name: etcd
          mountPath: /var/lib/etcd
          capacity:
            storage: 4Gi       
    workers:
      count: 3                                 
      class: best-effort-medium                 
      storageClass: vwt-storage-policy        
      volumes:
        - name: containerd
          mountPath: /var/lib/containerd
          capacity:
            storage: 16Gi

Clúster con una red Antrea personalizada

En el siguiente YAML se muestra cómo aprovisionar un clúster de Tanzu Kubernetes con rangos de redes personalizadas para la CNI de Antrea.

Debido a que se aplica la configuración de red personalizada, se requiere el parámetro cni.name aunque se utilice la CNI de Antrea predeterminada.
- Nombre de CNI: antrea
- CIDR de pods personalizados: 193.0.2.0/16
- CIDR de servicios personalizados: 195.51.100.0/12
- Dominio de servicio personalizado: managedcluster.local
Los bloques CIDR personalizados no pueden superponerse con el clúster supervisor. Para obtener más información, consulte Parámetros de configuración para clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: tkg-cluster-3-antrea
  namespace: tkgs-cluster-ns
spec:
  distribution:
    version: v1.20
  topology:
    controlPlane:
      class: guaranteed-medium
      count: 3
      storageClass: vwt-storage-policy
    workers:
      class: guaranteed-medium
      count: 5
      storageClass: vwt-storage-policy
  settings:
    network:
      cni:
        name: antrea                       #Use Antrea CNI
      pods:
        cidrBlocks:
        - 193.0.2.0/16                     #Must not overlap with SVC
      services:
        cidrBlocks:
        - 195.51.100.0/12                  #Must not overlap with SVC
      serviceDomain: managedcluster.local

Clúster con una red Calico personalizada

El siguiente YAML demuestra cómo aprovisionar un clúster de Tanzu Kubernetes con una red Calico personalizada.

Calico no es la CNI predeterminada, por lo que se nombra de forma explícita en el manifiesto. Para cambiar la CNI predeterminada en el nivel de servicio, consulte Ejemplos de configuración de la API de servicio Tanzu Kubernetes Grid v1alpha1.
- Nombre de CNI: calico
- CIDR de pods personalizados: 198.51.100.0/12
- CIDR de servicios personalizados: 192.0.2.0/16
- Dominio de servicio personalizado: managedcluster.local
La red utiliza rangos de CIDR personalizados, y no los predeterminados. Estos rangos no deben superponerse con el clúster supervisor. Consulte Parámetros de configuración para clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1.

apiVersion: run.tanzu.vmware.com/v1alpha1    
kind: TanzuKubernetesCluster                 
metadata:
  name: tkgs-cluster-2                                
  namespace: tkgs-cluster-ns                     
spec:
  distribution:
    version: v1.20                              
  topology:
    controlPlane:
      count: 3                                                        
      class: guaranteed-large                  
      storageClass: vwt-storage-policy        
    workers:
      count: 5                                                      
      class: guaranteed-xlarge                           
      storageClass: vwt-storage-policy      
  settings:
    network:
      cni:
        name: calico                           #Use Calico CNI for this cluster
      services:
        cidrBlocks: ["198.51.100.0/12"]        #Must not overlap with SVC
      pods:
        cidrBlocks: ["192.0.2.0/16"]           #Must not overlap with SVC
      serviceDomain: managedcluster.local

Clúster con clases de almacenamiento y una clase predeterminada para volúmenes persistentes

El siguiente ejemplo de YAML demuestra cómo aprovisionar un clúster con clases de almacenamiento para el aprovisionamiento dinámico de PVC y una clase de almacenamiento predeterminada.

La opción spec.settings.storage.classes especifica dos clases de almacenamiento para el almacenamiento persistente de los contenedores en el clúster.
Se especifica spec.settings.storage.defaultClass. Algunas aplicaciones requieren una clase predeterminada. Por ejemplo, si desea utilizar Helm o Kubeapps como la defaultClass a la que hacen referencia muchos gráficos.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: default-storage-spec
  namespace: tkgs-cluster-ns
spec:
  topology:
    controlPlane:
      count: 3
      class: best-effort-medium
      storageClass: vwt-storage-policy
    workers:
      count: 3
      class: best-effort-medium
      storageClass: vwt-storage-policy
  distribution:
    version: v1.20
  settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["198.51.100.0/12"]
      pods:
        cidrBlocks: ["192.0.2.0/16"]
      serviceDomain: "tanzukubernetescluster.local"
    storage:
      classes: ["gold", "silver"]              #Array of named PVC storage classes
      defaultClass: silver                     #Default PVC storage class

Clúster con un servidor proxy

Puede utilizar un servidor proxy con un clúster de Tanzu Kubernetes individual si se aplica la configuración del servidor proxy al manifiesto del clúster.

Tenga en cuenta las siguientes características:

La sección spec.settings.network.proxy especifica la configuración del proxy HTTP(s) para este clúster de Tanzu Kubernetes.
La sintaxis de ambos valores del servidor proxy es http://<user>:<pwd>@<ip>:<port>.
Los endpoints específicos no se convierten automáticamente en proxy, incluidos localhost y 127.0.0.1, y los CIDR de pod y de servicio para clústeres de Tanzu Kubernetes. No es necesario incluirlos en el campo noProxy.
El campo noProxy acepta una matriz de CIDR para que no sea proxy. Obtenga los valores necesarios de la red de carga de trabajo del clúster supervisor. Consulte la imagen en Parámetros de configuración para clústeres de Tanzu Kubernetes mediante la API de servicio Tanzu Kubernetes Grid v1alpha1.
Si se configura un proxy global en TkgServiceConfiguration, esa información de proxy se propaga al manifiesto del clúster después de la implementación inicial del clúster. La configuración global del proxy se agrega al manifiesto del clúster solo si no hay ningún campo de configuración de proxy presente cuando se crea el clúster. En otras palabras, la configuración por clúster tiene prioridad y sobrescribirá la configuración global del proxy.

apiVersion: run.tanzu.vmware.com/v1alpha1    
kind: TanzuKubernetesCluster                 
metadata:
  name: tkgs-cluster-with-proxy                                
  namespace: tkgs-cluster-ns                     
spec:
  distribution:
    version: v1.20                              
  topology:
    controlPlane:
      count: 3                                                        
      class: guaranteed-medium                  
      storageClass: vwt-storage-policy        
    workers:
      count: 5                                                      
      class: guaranteed-xlarge                           
      storageClass: vwt-storage-policy       
  settings:
    storage:
      classes: ["gold", "silver"]              
      defaultClass: silver                     
    network:
      cni:
        name: antrea 
      pods:
        cidrBlocks:
        - 193.0.2.0/16
      services:
        cidrBlocks:
        - 195.51.100.0/12           
      serviceDomain: managedcluster.local
      proxy:
        httpProxy: http://10.186.102.224:3128  #Proxy URL for HTTP connections
        httpsProxy: http://10.186.102.224:3128 #Proxy URL for HTTPS connections
        noProxy: [10.246.0.0/16,192.168.144.0/20,192.168.128.0/20] #SVC Pod, Egress, Ingress CIDRs

Clúster con certificados personalizados para TLS

De forma similar a cómo puede especificar trust.additionalTrustedCAs en TkgServiceConfiguration (consulte Parámetros de configuración para la API v1alpha1 de servicio Tanzu Kubernetes Grid), puede incluir trust.additionalTrustedCAs en spec.settings.network en la especificación del TanzuKubernetesCluster. Por ejemplo:

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-with-custom-certs-tls
  namespace: tkgs-cluster-ns
spec:
  topology:
    controlPlane:
      count: 3
      class: guaranteed-medium
      storageClass: vwt-storage-profile
    workers:
      count: 3
      class: guaranteed-large
      storageClass: vwt-storage-profile
  distribution:
    version: 1.20.2
  settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["198.51.100.0/12"]
      pods:
        cidrBlocks: ["192.0.2.0/16"]
      serviceDomain: "managedcluster.local"
      trust:
        additionalTrustedCAs:
          - name: custom-selfsigned-cert-for-tkc
            data: |
              LS0aaaaaaaaaaaaaaabase64...

El clúster que hereda o no la configuración global de la especificación TkgServiceConfiguration

Nota: Las siguientes configuraciones de clúster de ejemplo requieren la versión 7.0U2a de vCenter Server y otras versiones posteriores y, al menos, la versión 1.18.10 de clúster supervisor.

Para aprovisionar un clúster de Tanzu Kubernetes que hereda una configuración global de la TkgServiceConfiguration, configure el clúster con la configuración global no especificada o anulada.

Por ejemplo, si desea configurar un clúster que herede la configuración del proxy, podría utilizar cualquiera de los siguientes métodos:

Opción 1: Incluir la configuración del proxy en la especificación del clúster:

...
settings:
  network:
    cni:
      name: antrea
    services:
      cidrBlocks: ["198.51.100.0/12"]
    pods:
      cidrBlocks: ["192.0.2.0/16"]
    serviceDomain: "tanzukubernetescluster.local"

Opción 2: Incluir la configuración del proxy en la especificación, pero establecer explícitamente su valor en null:

settings:
  network:
    proxy: null

Para aprovisionar un clúster de Tanzu Kubernetes que no herede el valor predeterminado de la TkgServiceConfiguration, configure la especificación del clúster con todos los elementos incluidos pero vacíos.

Por ejemplo, si la TkgServiceConfiguration tiene un proxy global configurado y desea aprovisionar un clúster que no herede la configuración global del proxy, incluya la siguiente sintaxis en la especificación del clúster:

...
settings:
  network:
    proxy:
      httpProxy: ""
      httpsProxy: ""
      noProxy: null

Clúster que utiliza una biblioteca de contenido local

Para aprovisionar un clúster de Tanzu Kubernetes en un entorno aislado, cree un clúster con la imagen de máquina virtual sincronizada desde una biblioteca de contenido local.

Para aprovisionar un clúster con una imagen de la biblioteca de contenido local, debe introducir esa imagen en la especificación del clúster. Para el valor distribution.version, puede introducir el nombre completo de la imagen o, si ha mantenido el formato de nombre del directorio de la imagen, puede acortarlo a la versión de Kubernetes. Si desea utilizar un número de versión completo, reemplace ----- por +. Por ejemplo, si tiene una imagen OVA llamada photon-3-k8s-v1.20.2---vmware.1-tkg.1.1d4f79a, se aceptan los siguientes formatos.

spec:
  distribution:
    version: v1.20

spec:
  distribution:
    version: v1.20.2

spec:
  distribution:
    version: v1.20.2+vmware.1-tkg.1

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
    name: tgks-cluster-9
    namespace: tkgs-cluster-ns
spec:
   topology:
       controlPlane:
           count: 3
           class: best-effort-medium
           storageClass: vwt-storage-policy
       workers:
           count: 3
           class: best-effort-medium
           storageClass: vwt-storage-policy
   distribution:
        version: v1.20.2         
   settings:
        network:
          cni:
              name: antrea 
          services:
             cidrBlocks: ["198.51.100.0/12"]
          pods:
             cidrBlocks: ["192.0.2.0/16"]