La API v1beta1 se puede utilizar para crear un clúster con una red de pods enrutables. Para ello, se reemplaza el clúster predeterminado con configuraciones personalizadas para AntreaConfig y VSphereCPIConfig.

Acerca de las redes de pods enrutables mediante la API v1beta1

El siguiente ejemplo de YAML demuestra cómo utilizar la API v1beta1 para aprovisionar un clúster con una función RoutablePod de Antrea habilitada. Este ejemplo se basa en el ejemplo de v1beta1: clúster predeterminado.

Para habilitar la función RoutablePod, el clúster requiere AntreaConfig y VSphereCPIConfig con una configuración especial.

AntreaConfig debe establecer trafficEncapMode: noEncap y noSNAT: true.

VSphereCPIConfig debe establecer antreaNSXPodRoutingEnabled: true, mode: vsphereParavirtualCPI y 
tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

El nombre de AntreaConfig debe tener el mismo formato que <cluster-name>-antrea-package. El nombre de VSphereCPIConfig debe tener el formato <cluster-name>-vsphere-cpi-package.

Una vez que se hayan creado los archivos de configuración, se crea el objeto de especificación del clúster que hace referencia a los archivos de configuración. Durante la creación del clúster, los archivos de configuración se utilizarán para aprovisionar el clúster y sobrescribir la configuración predeterminada.

Crear una red de pods enrutables: configuración de Supervisor

Para crear una red de pods enrutables se requiere la configuración en el Supervisor y en el clúster de TKG.
Nota: El Supervisor debe configurarse con NSX para usar redes de pods enrutables. No se pueden utilizar pods enrutables con redes de VDS.
Para configurar una red de pods enrutables en Supervisor:
  1. Cree un nuevo espacio de nombres de vSphere.

    Consulte Crear un espacio de nombres de vSphere para alojar clústeres de Servicio TKG.

  2. Seleccione la opción de casilla de verificación para Anular configuración de red de supervisor.

    Consulte Anular la configuración de la red de cargas de trabajo para un espacio de nombres de vSphere para obtener instrucciones.

  3. Configure la red de pods enrutables de la siguiente manera.
    Campo Descripción
    Modo NAT Anule la selección de esta opción para deshabilitar la traducción de direcciones de red (NAT).
    Red de espacio de nombres

    Rellene este campo con una subred IP enrutable con el formato Dirección IP/Bits (p. ej., 10.0.0.6/16).

    NCP creará uno o varios grupos de direcciones IP a partir de los bloques de IP especificados para la red.

    Como mínimo, debe especificar un tamaño de subred /23. Por ejemplo, si especifica una subred enrutable /23 con un prefijo de subred /28, obtendrá 32 subredes que deberían ser suficientes para un clúster de 6 nodos. Una subred /24 con un prefijo /28 solo obtendrá 2 subredes, que no son suficientes.

    Atención: Asegúrese de que la subred de IP enrutable que agregue no se superponga con el CIDR de servicios que asigna las direcciones IP para los nodos de clúster. Puede comprobar el CIDR de servicios en Supervisor > Configurar > Red > Red de cargas de trabajo.
    Prefijo de subred de espacio de nombres

    Especifique un prefijo de subred con el formato /28, por ejemplo.

    El prefijo de subred se utiliza para dividir la subred del pod para cada nodo de la red de espacio de nombres.

  4. Haga clic en Crear para crear la red de pods enrutables.

Crear una red de pods enrutables: configuración de un clúster de TKG

El siguiente ejemplo de YAML muestra cómo configurar un clúster v1beta1 con una red de pods enrutables.

Como se muestra en el siguiente ejemplo, debe eliminar la sección spec.clusterNetwork.pod de la especificación del clúster, ya que cloud-provider-vsphere asignará las direcciones IP del pod.
Nota: El ejemplo se proporciona como un único archivo YAML, pero se puede separar en archivos individuales. Si hace esto, debe crearlos en orden: primero los recursos personalizados de AntreaConfig y VSphereCPIConfig y después el clúster de target-cluster. 
---
apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: AntreaConfig
metadata:
 name: target-cluster-antrea-package
spec:
 antrea:
   config:
     defaultMTU: ""
     disableUdpTunnelOffload: false
     featureGates:
       AntreaPolicy: true
       AntreaProxy: true
       AntreaTraceflow: true
       Egress: false
       EndpointSlice: true
       FlowExporter: false
       NetworkPolicyStats: false
       NodePortLocal: false
     noSNAT: true
     tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384
     trafficEncapMode: noEncap
---
apiVersion: cpi.tanzu.vmware.com/v1alpha1
kind: VSphereCPIConfig
metadata:
 name: target-cluster-vsphere-cpi-package
spec:
 vsphereCPI:
   antreaNSXPodRoutingEnabled: true
   insecure: false
   mode: vsphereParavirtualCPI
   tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
 name: target-cluster
spec:
 clusterNetwork:
   services:
     cidrBlocks: ["198.51.100.0/12"]
   serviceDomain: "cluster.local"
 topology:
   class: tanzukubernetescluster
   version: v1.25.7---vmware.3-fips.1-tkg.1
   controlPlane:
     replicas: 3
   workers:
     machineDeployments:
       - class: node-pool
         name: node-pool-1
         replicas: 3
   variables:
     - name: vmClass
       value: guaranteed-medium
     - name: storageClass
       value: tkg2-storage-policy