Clústeres en Azure

En este tema se describen las formas de configurar clústeres de carga de trabajo de Tanzu Kubernetes Grid (TKG) para que utilicen funciones específicas de Microsoft Azure y que no se pueden configurar por completo en el archivo de configuración plano del clúster o las especificaciones de objetos de estilo Kubernetes.

Para obtener información sobre cómo configurar clústeres de carga de trabajo en Azure mediante especificaciones de objetos y archivos de configuración, consulte Archivos de configuración del clúster de Azure.

Clústeres privados de Azure

De forma predeterminada, los clústeres de carga de trabajo y administración de Azure son públicos. Sin embargo, también puede configurarlos para que sean privados, lo que significa que su servidor de API utiliza un equilibrador de carga interno (ILB) de Azure y, por lo tanto, solo se puede acceder a él desde la propia VNet o VNet emparejadas del clúster.

Para que un clúster de Azure sea privado, incluya lo siguiente en su archivo de configuración:

Establezca AZURE_ENABLE_PRIVATE_CLUSTER en true.
(Opcional) Establezca AZURE_FRONTEND_PRIVATE_IP en una dirección interna para el equilibrador de carga del clúster.
- Esta dirección debe estar dentro del rango de su subred del plano de control y no debe utilizarse en otro componente.
- Si no se establece, el valor predeterminado de esta dirección será 10.0.0.100.
Establezca AZURE_VNET_NAME, AZURE_VNET_CIDR, AZURE_CONTROL_PLANE_SUBNET_NAME, AZURE_CONTROL_PLANE_SUBNET_CIDR, AZURE_NODE_SUBNET_NAME y AZURE_NODE_SUBNET_CIDR a la VNet y las subredes que utiliza para otros clústeres privados de Azure.
- Debido a que no se puede acceder a los clústeres privados de Azure fuera de su VNet, el clúster de administración y todos los clústeres de carga de trabajo y servicios compartidos que administre deben estar en la misma VNet privada.
- La máquina de arranque, donde se ejecuta la CLI de Tanzu para crear y utilizar clústeres privados, también debe estar en la misma VNet privada.
(Opcional) Establezca AZURE_ENABLE_CONTROL_PLANE_OUTBOUND_LB y AZURE_ENABLE_NODE_OUTBOUND_LB en true si necesita que los nodos de trabajo y plano de control puedan acceder a Internet a través de una conexión a Internet de Azure.
- Los clústeres privados de Azure crean una dirección IP pública para cada servicio de Kubernetes de tipo equilibrador de carga de forma predeterminada. Para configurar el servicio del equilibrador de carga para que, en su lugar, utilice una dirección IP privada, agregue la siguiente anotación al manifiesto de la implementación:
```
---
metadata:
annotations:
  service.beta.kubernetes.io/azure-load-balancer-internal: "true"
```

Para obtener más información, consulte Endpoint del servidor de API en la documentación de Azure del proveedor de API del clúster.

Clústeres en diferentes cuentas de Azure

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 de Azure alternativa, diferente de la que se utiliza para implementar su clúster de administración, haga lo siguiente:

Cree la cuenta de Azure alternativa. Utilice los detalles de esta cuenta para crear un AzureClusterIdentity en un paso posterior. Para obtener información sobre cómo crear una cuenta de entidad de servicio de Azure, consulte Cómo hacer: Utilizar el portal para crear una aplicación de Azure AD y una entidad de servicio que pueda acceder a los recursos en la documentación de Azure.
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
type: Opaque
data:
  clientSecret: CLIENT-SECRET
```
Donde:
- SECRET-NAME es el nombre secreto de la contraseña del cliente.
- CLIENT-SECRET es el secreto de cliente de su identidad de entidad de servicio. El secreto de cliente debe tener codificación Base64.
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: AzureClusterIdentity
metadata:
  name: EXAMPLE-IDENTITY
  namespace: EXAMPLE-NAMESPACE
spec:
  type: ManualServicePrincipal
  tenantID: AZURE-TENANT-ID
  clientID: CLIENT-ID
  clientSecret: {"name":"SECRET-NAME","namespace":"default"}
  allowedNamespaces:
    list:
    - CLUSTER-NAMESPACE-1
    - CLUSTER-NAMESPACE-1
```
Donde:
- EXAMPLE-IDENTITY es el nombre que se utilizará para AzureClusterIdentity.
- EXAMPLE-NAMESPACE es el espacio de nombres de AzureClusterIdentity.
- AZURE-TENANT-ID es el identificador de tenant de Azure.
- CLIENT-ID es el identificador de cliente (también conocido como AppID) para la aplicación de Azure AD.
- SECRET-NAME es el nombre secreto de la contraseña del cliente.
- CLUSTER-NAMESPACE-1 y CLUSTER-NAMESPACE-2 son espacios de nombres de Kubernetes desde los que los clústeres pueden usar identidades. Estos espacios de nombres se pueden seleccionar mediante una matriz de espacios de nombres.
Utilice el archivo para crear el objeto AzureClusterIdentity:
```
kubectl apply -f identity.yaml
```

El clúster de administración ahora puede implementar clústeres de carga de trabajo en la cuenta alternativa mediante el nuevo objeto AzureClusterIdentity.

Para crear clústeres de carga de trabajo que utilicen la cuenta de Azure alternativa, incluya las siguientes variables en el archivo de configuración del clúster:

AZURE_IDENTITY_NAME: EXAMPLE-IDENTITY
AZURE_IDENTITY_NAMESPACE: EXAMPLE-NAMESPACE

Donde:

EXAMPLE-IDENTITY es el nombre que se utilizará para AzureClusterIdentity.
EXAMPLE-NAMESPACE es el espacio de nombres de AzureClusterIdentity.

Después de crear el clúster de carga de trabajo, inicie sesión en el portal de Azure con la cuenta alternativa. Debería ver el clúster en ejecución.

Clústeres habilitados para GPU

Existen dos formas de implementar clústeres de carga de trabajo habilitados para GPU NVIDIA en Azure:

Crear un clúster de carga de trabajo con trabajadores de GPU e instalar manualmente un operador y una directiva de GPU en el clúster
(Vista previa técnica) Configure el clúster de administración con un ClusterResourceSet (CRS) para crear automáticamente uno o varios clústeres de carga de trabajo habilitados para GPU

En las siguientes subsecciones se explican estos dos enfoques y cómo probar los clústeres habilitados para GPU.

Implementar y habilitar GPU en un solo clúster

Para implementar un clúster de carga de trabajo y configurarlo manualmente para aprovechar las máquinas virtuales de GPU NVIDIA disponibles en Azure:

En el archivo de configuración para el clúster, establezca AZURE_NODE_MACHINE_TYPE, para los nodos de trabajo, en un tipo de máquina virtual compatible con GPU, como Standard_NC4as_T4_v3.
- Para los tipos de máquinas virtuales de GPU en Azure, consulte Tamaños de máquina virtual optimizados para GPU en la documentación de Azure.
Implemente el clúster con el archivo de configuración del clúster:
```
tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG
```
Donde MY-GPU-CLUSTER es un nombre que se le otorga al clúster.
Instale una directiva de clúster de GPU y un operador de GPU en el clúster:
1. Establezca el contexto kubectl context al clúster, si aún no es el contexto actual.
2. Descargue los recursos de GPU de NVIDIA necesarios del repositorio de Azure del proveedor de API del clúster y guárdelos en el directorio actual:
  - Definición de recursos de directiva de clúster de GPU
  - Componentes del operador de GPU
3. Aplique la directiva del clúster:
```
kubectl apply clusterpolicy-crd.yaml
```
4. Aplique el operador de GPU:
```
kubectl apply gpu-operator-components.yaml
```
Ejecute kubectl get pods -A. Debería ver listas de pods de gpu-operator- en el espacio de nombres default y nvidia- en el espacio de nombres gpu-operator-resources.

Configure el clúster de administración para implementaciones de clústeres de GPU (vista previa técnica)

Nota
Esta función se encuentra en el estado de vista previa técnica no compatible; consulte Estados de funciones de TKG.

Puede configurar el clúster de administración para crear automáticamente clústeres de carga de trabajo habilitados para GPU cuando agregue gpu: nvidia a las etiquetas del manifiesto del clúster. Para ello, instale un ClusterResourceSet (CRS) y actívelo de la siguiente manera:

Para configurar el clúster de administración para crear clústeres de GPU:
1. Busque el Intercambio de ejemplo de VMware {code} para GPU CRS para TKG y descargue el archivo gpu-crs.yaml para Tanzu Kubernetes Grid v1.4.
2. Establezca el contexto de kubectl en el contexto de clúster de administración:
```
kubectl config use-context my-management-cluster-admin@my-management-cluster
```
3. Aplique el archivo CRS al clúster de administración mediante la opción --server-side para controlar el gran tamaño de los datos de ConfigMap:
```
kubectl apply -f gpu-crs.yaml --server-side
```
Para crear un clúster de carga de trabajo de GPU:
1. En el archivo de configuración para el clúster, establezca AZURE_NODE_MACHINE_TYPE, para los nodos de trabajo, en un tipo de máquina virtual compatible con GPU, como Standard_NC4as_T4_v3.
  - Para los tipos de máquinas virtuales de GPU en Azure, consulte Tamaños de máquina virtual optimizados para GPU en la documentación de Azure.
2. Utilice tanzu cluster create con la opción --dry-run para generar un manifiesto de implementación desde el archivo de configuración del clúster:
```
tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG --dry-run > MY-GPU-CLUSTER-MANIFEST
```
  Donde MY-GPU-CLUSTER es un nombre que se le otorga al clúster.
3. Cree el clúster pasándolo a kubectl apply:
```
kubectl apply -f MY-GPU-CLUSTER-MANIFEST
```
4. Ejecute kubectl get pods -A. Debería ver listas de pods de gpu-operator- en el espacio de nombres default y nvidia- en el espacio de nombres gpu-operator-resources.

Probar clústeres habilitados para GPU

Para probar un clúster habilitado para GPU:

Pruebe el procesamiento de GPU ejecutando la prueba de adición de vectores CUDA VectorAdd en la documentación de NVIDIA.
Pruebe el operador de GPU:
1. Escale verticalmente el recuento de nodos de trabajo del clúster de carga de trabajo:
```
tanzu cluster scale MY-GPU-CLUSTER -w 2
```
2. Vuelva a ejecutar kubectl get pods -A. Debería ver más pods gpu-operator- y nvidia- en la lista para los nodos agregados.