Clústeres en vSphere

En las siguientes secciones se describe cómo configurar clústeres de carga de trabajo de Tanzu Kubernetes Grid (TKG) para que utilicen funciones específicas de vSphere con un clúster de administración independiente. Las funciones no se pueden configurar por completo en el archivo de configuración plano del clúster o en la especificación de objeto de estilo Kubernetes.

Para obtener información sobre cómo configurar clústeres de carga de trabajo en vSphere mediante especificaciones de objetos y archivos de configuración, consulte:

Implementar un clúster con una imagen OVA personalizada

Si utiliza una sola imagen OVA personalizada para cada versión de Kubernetes con el fin de implementar clústeres en un sistema operativo, importe el archivo OVA en vSphere y, a continuación, especifíquelo para tanzu cluster create con la opción --tkr.

Sin embargo, si utiliza varias imágenes OVA personalizadas para la misma versión de Kubernetes, el valor --tkr es ambiguo. Esto sucede cuando los archivos OVA para la misma versión de Kubernetes:

Tenga diferentes sistemas operativos, por ejemplo, creados pormake build-node-ova-vsphere-ubuntu-1804, make build-node-ova-vsphere-photon-3 ymake build-node-ova-vsphere-rhel-7.
Tienen el mismo nombre, pero residen en carpetas de vCenter diferentes.

Para resolver esta ambigüedad, establezca la opción VSPHERE_TEMPLATE en la imagen OVA deseada antes de ejecutar tanzu cluster create:

Si el nombre de la imagen de la plantilla de OVA es único, establezca VSPHERE_TEMPLATE solo en el nombre de la imagen.
Si varias imágenes comparten el mismo nombre, establezca VSPHERE_TEMPLATE en la ruta de acceso de inventario completa de la imagen en vCenter. Esta ruta sigue el formato /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE, donde:
- MY-DC es el centro de datos que contiene la imagen de plantilla de OVA.
- MY-FOLDER-PATH es la ruta de acceso a la imagen desde el centro de datos, como se muestra en la vista de Máquinas virtuales y plantillas de vCenter.
- MY-IMAGE es el nombre de la imagen.
Por ejemplo:
```
VSPHERE_TEMPLATE: "/TKG_DC/vm/TKG_IMAGES/ubuntu-2004-kube-v1.29.9-vmware.1"
```
Puede determinar manualmente la ruta de acceso de inventario completa de vCenter de la imagen o utilizar la CLI govc:
1. Instale govc. Para obtener instrucciones de instalación, consulte el repositorio govmomi en GitHub.
2. Establezca variables de entorno para que govc acceda a vCenter:
  - export GOVC_USERNAME=VCENTER-USERNAME
  - export GOVC_PASSWORD=VCENTER-PASSWORD
  - export GOVC_URL=VCENTER-URL
  - export GOVC_INSECURE=1
3. Ejecute govc find / -type m y busque el nombre de la imagen en la salida, que enumera los objetos por sus rutas de inventario completas.

Para obtener más información sobre las imágenes OVA personalizadas, consulte Compilar imágenes de máquinas.

Implementar un clúster con etiquetas de región y zona para CSI

Puede especificar una región y una zona para el clúster de carga de trabajo, a fin de integrarla con las etiquetas de zona y región configuradas para vSphere CSI (Cloud Storage Interface). Para los clústeres que abarcan varias zonas, esto permite que los nodos de trabajo encuentren y utilicen almacenamiento compartido, incluso si se ejecutan en zonas que no tienen pods de almacenamiento, por ejemplo, en una red de acceso de radio de telecomunicaciones (RAN).

Para implementar un clúster de carga de trabajo con etiquetas de zona y región que habiliten el almacenamiento compartido con vSphere CSI:

Cree etiquetas en vCenter Server:
1. Cree categorías de etiquetas en vCenter Server siguiendo Crear y editar una categoría de etiqueta. Por ejemplo, k8s-region y k8s-zone.
2. Siga Crear y editar una etiqueta de vSphere para crear etiquetas dentro de las categorías de región y zona en el centro de datos, como se muestra en esta tabla:
  
  Categoría Etiquetas
  
  k8s-zone zone-a
  zone-b
  zone-c
  
  k8s-region region-1

Categoría	Etiquetas
`k8s-zone`	`zone-a` `zone-b` `zone-c`
`k8s-region`	`region-1`

Cree las etiquetas correspondientes a los clústeres y en el centro de datos siguiendo Asignar o quitar una etiqueta de vSphere como se indica en la tabla.


Objetos vSphere	Etiquetas
`datacenter`	`region-1`
`cluster1`	`zone-a`
`cluster2`	`zone-b`
`cluster3`	`zone-c`

Para habilitar zonas y regiones personalizadas para un vSphere controlador CSI del clúster de carga de trabajo, establezca las variables VSPHERE_REGION y VSPHERE_ZONE en el archivo de configuración del clúster en las etiquetas anteriores. Por ejemplo:
```
VSPHERE_REGION: region-1
VSPHERE_ZONE: zone-a
```
Cuando la CLI de Tanzu crea un clúster de carga de trabajo con estas variables configuradas, etiqueta cada nodo del clúster con las claves de topología failure-domain.beta.kubernetes.io/zone y failure-domain.beta.kubernetes.io/region.
Ejecute tanzu cluster create para crear el clúster de carga de trabajo, como se describe en Crear un clúster TKC o basado en un plan.
Después de crear el clúster y con el contexto kubectl establecido en el clúster, puede comprobar las etiquetas de región y zona mediante una de las siguientes acciones:
- Ejecute kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region y confirme que el resultado enumera los nodos del clúster.
- Ejecute kubectl get csinodes -o jsonpath='{range .items\[\*\]}{.metadata.name} {.spec}{"\\n"}{end}' y confirme que la región y la zona estén habilitadas en vsphere-csi.

Para obtener más información sobre cómo configurar vSphere CSI, consulte Controlador vSphere csi: Implementación con topología.

Clústeres en diferentes cuentas de vSphere

Tanzu Kubernetes Grid puede ejecutar clústeres de carga de trabajo en varias cuentas de plataformas de destino, por ejemplo, para dividir el uso de la nube entre diferentes equipos o aplicar diferentes perfiles de seguridad a las cargas de trabajo de producción, realización de copias intermedias y desarrollo.

Para implementar clústeres de carga de trabajo en una cuenta de entidad de servicio vSphere alternativa, diferente de la que se utiliza para implementar su clúster de administración, haga lo siguiente:

Establezca el contexto de kubectl en su clúster de administración:
```
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
```
Donde MY-MGMT-CLUSTER es el nombre del clúster de administración.
Cree un archivo secret.yaml con el siguiente contenido:
```
apiVersion: v1
kind: Secret
metadata:
  name: SECRET-NAME
  namespace: CAPV-MANAGER-NAMESPACE
stringData:
  username: VSPHERE-USERNAME
  password: VSPHERE-PASSWORD
```
Donde:
- SECRET-NAME es un nombre que se le otorga al secreto de cliente.
- CAPV-MANAGER-NAMESPACE es el espacio de nombres donde se ejecuta el pod capv-manager. Predeterminado: capv-system.
- VSPHERE-USERNAME y VSPHERE-PASSWORD son credenciales de inicio de sesión que habilitan el acceso a la cuenta de vSphere alternativa.
Utilice el archivo para crear el objeto Secret:
```
kubectl apply -f secret.yaml
```
Cree un archivo identity.yaml con el siguiente contenido:
```
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereClusterIdentity
metadata:
  name: EXAMPLE-IDENTITY
spec:
  secretName: SECRET-NAME
  allowedNamespaces:
    selector:
      matchLabels: {}
```
Donde:
- EXAMPLE-IDENTITY es el nombre que se utilizará para el objeto. VSphereClusterIdentity.
- SECRET-NAME es el nombre que ha dado al secreto de cliente anteriormente.
Utilice el archivo para crear el objeto VsphereClusterIdentity:
```
kubectl apply -f identity.yaml
```

El clúster de administración ahora puede implementar clústeres de carga de trabajo en la cuenta alternativa.

Para implementar un clúster de carga de trabajo en la cuenta:

Cree un manifiesto del clúster ejecutando tanzu cluster create --dry-run.

Edite la definición VSphereCluster en el manifiesto para establecer el valor de spec.identityRef.name para su objeto VSphereClusterIdentity en el EXAMPLE-IDENTITY creado anteriormente:

...
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
 name: new-workload-cluster
spec:
 identityRef:
   kind: VSphereClusterIdentity
   name: EXAMPLE-IDENTITY
...

Ejecute kubectl apply -f my-cluster-manifest.yaml para crear el clúster de carga de trabajo.

Después de crear el clúster de carga de trabajo, inicie sesión en vSphere con las credenciales de cuenta alternativas. Debería verlo en ejecución.

Para obtener más información, consulte Administración de identidades en el repositorio de vSphere del proveedor de API del clúster.

Implementar un clúster de que utiliza un clúster de almacenes de datos

Nota
Esta función no funciona según lo esperado. Si etiqueta varios almacenes de datos en un clúster de almacenes de datos como base para la directiva de almacenamiento de un clúster de carga de trabajo, el clúster de carga de trabajo utiliza solo uno de los almacenes de datos.

Para permitir que un clúster de carga de trabajo utilice un clúster de almacenes de datos en lugar de un solo almacén de datos, configure una directiva de almacenamiento que tenga como destino todos los almacenes de datos dentro del clúster de almacenes de datos de la siguiente manera:

Cree una etiqueta y asóciela con los almacenes de datos relevantes:
1. Siga los procedimientos descritos en Etiquetas de vSphere para crear categorías de etiquetas en vCenter Server. Asegúrese de que la categoría tenga Datastore como un tipo de objeto asociable.
2. Siga los otros procedimientos descritos en Etiquetas de vSphere para crear una etiqueta dentro de la categoría creada en el paso anterior y asociar la nueva etiqueta con todos los almacenes de datos que pertenecen al clúster de almacenes de datos.
Siga Crear una directiva de almacenamiento de máquina virtual para la colocación basada en etiquetas para crear una directiva de almacenamiento basada en etiquetas.
En el archivo de configuración del clúster:
- Establezca VSPHERE_STORAGE_POLICY_ID en el nombre de la directiva de almacenamiento creada en el paso anterior.
- Asegúrese de que no se haya establecido VSPHERE_DATASTORE. La configuración de VSPHERE_DATASTORE anularía la configuración de la directiva de almacenamiento.

Implementar un clúster de carga de trabajo de varios sistemas operativos

Para implementar un clúster de carga de trabajo con varios sistemas operativos que tenga nodos de trabajo basados en Linux y Windows, cree una imagen de máquina Windows personalizada, implemente un clúster de carga de trabajo de Windows y, a continuación, agregue una MachineDeployment de Linux para convertir el clúster de carga de trabajo solo de Windows en un clúster de varios sistemas operativos.

Los clústeres de varios sistemas operativos pueden alojar cargas de trabajo de Linux y Windows mientras se ejecutan componentes de TKG basados en Linux en los nodos de trabajo.

Cree una imagen de máquina de Windows siguiendo todos los procedimientos descritos en Imágenes de máquina personalizadas de Windows.
Cree un archivo YAML, por ejemplo,win-osimage.yaml para agregar una OSImage en el clúster de administración que apunte a la plantilla cuando creó una imagen de máquina de Windows.

Puede utilizar el siguiente archivo YAML de ejemplo. Cambie el valor spec.image.ref.template a la ubicación de la plantilla de Windows que creó. La ruta de acceso es específica del entorno de vSphere.
```
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
 name: v1.25.7---vmware.2-tkg.1-windows
spec:
 image:
   ref:
     template: /dc0/vm/windows-2019-kube-v1.25.7+vmware.2-tkg.1
     version: v1.25.7+vmware.2-tkg.1-windows
   type: ova
 kubernetesVersion: v1.25.7+vmware.2
 os:
   arch: amd64
   name: windows
   type: windows
   version: "2019"
```
Ejecute kubectl apply -f win-osimage.yaml para agregar la OSImage.
Agregue la versión de TKR a spec.osImages para que la resolución de TKR y la validación de webhook se produzcan correctamente. Utilice el siguiente comando para agregar la versión de TKR a spec.osImages.
```
$ kubectl edit tkr v1.25.7---vmware.2-tkg.1
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
  name: v1.25.7---vmware.2-tkg.1
spec:
  bootstrapPackages:
  # Keep the other packages listed here.
  - name: tkg-windows.tanzu.vmware.com.0.29.0+vmware.1
  osImages:
  # Keep the other images listed here.
  - name: v1.25.7---vmware.2-tkg.1-windows
```
En TKR, habilite el paquete tkg-windows agregando un nuevo elemento en spec.bootstrapPackages. El paquete se puede encontrar en el repositorio oficial con tanzu package available list tkg-windows.tanzu.vmware.com. A continuación se muestra un ejemplo de un TKR de funcionamiento:
Cree una especificación de objeto de clúster basada en clases ejecutando el siguiente comando:
```
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
```
Donde: * WINDOWS-CLUSTER es el nombre del clúster de Windows. * CLUSTER-CONFIG es el nombre del archivo de configuración.

Añada la nueva clase de implementación de máquina tkg-worker al objeto del clúster enmy-cluster-spec.yaml. Asegúrese de que la anotación sea correcta para que TKG pueda buscar el objeto OSImage.

Puede agregar la nueva especificación tkg-worker a spec.workers.machineDeployments similar al siguiente ejemplo:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: WINDOWS-CLUSTER
spec:
  workers:
    machineDeployments:
    - class: tkg-worker
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=photon
        name: md-0-l
        replicas: 1
    - class: tkg-worker-windows
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=windows
        name: md-0
        replicas: 1

Ejecute el siguiente comando para implementar el clúster de varios sistemas operativos:

tanzu cluster create my-cluster -f my-cluster-spec.yaml

Los nodos se etiquetan y se contaminan con la información del sistema operativo en Etiquetas, anotaciones y contaminaciones conocidas.

Nota
No se admite la copia de seguridad ni la restauración de clústeres de carga de trabajo de varios sistemas operativos.

Confiabilidad de CNI de Windows Antrea

La red de HNS no es persistente en Windows. Después de reiniciar el nodo de Windows, se elimina la red HNS creada por antrea-agent y la extensión Open vSwitch se deshabilita de forma predeterminada. Por lo tanto, una vez que se reinicie el nodo de Windows, elimine los puertos y el puente de OVS obsoletos. Puede utilizar el script de ayuda Clean-AntreaNetwork.ps1 para limpiar el puente OVS.

Utilice uno de los siguientes métodos para instalar el script de ayuda:

Instalación manual
Instalación automatizada

Instalación manual

Para instalar manualmente el script de ayuda en cada nodo de carga de trabajo aislado:

Descargue el script de instalación Clean-AntreaNetwork.ps1 desde este ejemplo de código. El script de instalación descargado snippet.ps1 instala Clean-AntreaNetwork.ps1.
Acceda mediante SSH al nodo de y ejecute el siguiente comando.
```
powershell snippet.ps1
```

Instalación automatizada

Para crear un ClusterClass que instale automáticamente el script de ayuda en cada nodo de carga de trabajo nuevo:

Siga los pasos descritos en Crear un ClusterClass para crear el objeto ClusterClass personalizado.
Aplique la revisión de este ejemplo de código mediante YTT y aplique la especificación en el clúster de administración:
```
ytt -f custom-cluster-class.yaml -f snippet.yaml | kubectl apply -f -
```

Notas sobre la seguridad del grupo de puertos distribuidos

Si implementa clústeres de Windows o MultiOS, debe asegurarse de que los grupos de puertos distribuidos tengan ciertas directivas de seguridad establecidas en Reject. Por ejemplo, si el modo promiscuo está establecido en Accept, los nodos pueden alternar entre los estados Ready y NotReady.

En el vSphere Client, seleccione la red que utiliza para los nodos de Windows, vaya a Conmutador virtual distribuido (virtual Distributed Switch) > Directiva de seguridad de grupo de puertos distribuido (Distributed Portgroup Security Policy) y establezca estas directivas en Reject:

Modo promiscuo
Cambios de dirección MAC
Transmisiones falsificadas