This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Implementar un clúster de carga de trabajo en hardware especializado

Tanzu Kubernetes Grid admite la implementación de clústeres de carga de trabajo en tipos específicos de hosts habilitados para GPU en vSphere 7.0 y versiones posteriores.

Implementar un clúster de carga de trabajo habilitado para GPU

Para utilizar un nodo con una GPU en un clúster de carga de trabajo de vSphere, debe habilitar el modo de acceso directo PCI. Esto permite que el clúster acceda a la GPU directamente, sin pasar por el hipervisor ESXi, lo que proporciona un nivel de rendimiento similar al rendimiento de la GPU en un sistema nativo. Cuando se utiliza el modo de acceso directo PCI, cada dispositivo GPU está dedicado a la máquina virtual (VM) del clúster de carga de trabajo de vSphere.

Nota

Para agregar nodos habilitados para GPU a los clústeres existentes, utilice el comando tanzu cluster node-pool set.

Requisitos previos

Procedimiento

Para crear un clúster de carga de trabajo de hosts habilitados para GPU, siga estos pasos para habilitar el acceso directo a PCI, crear una imagen de máquina personalizada, crear un archivo de configuración del clúster y versión Tanzu Kubernetes, implementar el clúster de carga de trabajo e instalar un operador de GPU mediante Helm.

  1. Agregue los hosts ESXi con las tarjetas GPU al vSphere Client.

  2. Habilite el acceso directo PCI y registre los identificadores de GPU de la siguiente manera:

    1. En el vSphere Client, seleccione el host ESXi de destino en el clúster GPU.
    2. Seleccione Configurar (Configure) > Hardware > Dispositivos PCI (PCI Devices).
    3. Seleccione la pestaña Todos los dispositivos PCI.
    4. Seleccione la GPU de destino de la lista.
    5. Haga clic en Alternar acceso directo.
    6. En Información general (General Information), registre el ID de dispositivo y el ID de proveedor (resaltados en verde en la imagen a continuación). Los identificadores son los mismos para las tarjetas GPU idénticas. Los necesitará para el archivo de configuración del clúster.

    La interfaz de vSphere Client que muestra una lista de dispositivos PCI. Debajo de la lista, la ubicación de los identificadores de dispositivo y de proveedor se resalta con un cuadro verde.

  3. Cree un archivo de configuración del clúster de carga de trabajo mediante la plantilla en Plantilla de clúster de carga de trabajo e incluya las siguientes variables:

    ...
VSPHERE_WORKER_PCI_DEVICES: "0x<VENDOR-ID>:0x<DEVICE-ID>"
VSPHERE_WORKER_CUSTOM_VMX_KEYS: 'pciPassthru.allowP2P=true,pciPassthru.RelaxACSforP2P=true,pciPassthru.use64bitMMIO=true,pciPassthru.64bitMMIOSizeGB=<GPU-SIZE>'
VSPHERE_IGNORE_PCI_DEVICES_ALLOW_LIST: "<BOOLEAN>"
VSPHERE_WORKER_HARDWARE_VERSION: vmx-17
WORKER_ROLLOUT_STRATEGY: "RollingUpdate"

    Donde:

    Nota

    Solo puede utilizar un tipo de GPU por máquina virtual. Por ejemplo, no puede utilizar NVIDIA V100 y NVIDIA Tesla T4 en una sola máquina virtual, pero puede usar varias instancias de GPU con el mismo identificador de proveedor y el mismo identificador de dispositivo.

    La CLI de tanzu no permite actualizar la especificación WORKER_ROLLOUT_STRATEGY en MachineDeployment. Si la actualización del clúster se bloquea debido a que los dispositivos PCI no están disponibles, VMware sugiere editar la estrategia MachineDeployment mediante la CLI de kubectl. La estrategia de lanzamiento se define en spec.strategy.type.

    Para obtener una lista completa de variables que puede configurar para clústeres habilitados para GPU, consulte Clústeres habilitados para GPU en Referencia de variables del archivo de configuración.

  4. Cree el clúster de carga de trabajo ejecutando:

    tanzu cluster create -f CLUSTER-CONFIG-NAME

    Donde CLUSTER-CONFIG-NAME es el nombre del archivo de configuración del clúster que creó en los pasos anteriores.

  5. Agregue el repositorio de Helm NVIDIA:

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
&& helm repo update

  6. Instale el operador de GPU NVIDIA:

    helm install --kubeconfig=./KUBECONFIG  --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator

    Donde KUBECONFIG es el nombre y la ubicación de kubeconfig para el clúster de carga de trabajo. Para obtener más información, consulte Recuperar clúster de carga de trabajo kubeconfig.

    Para obtener información sobre los parámetros de este comando, consulte Instalar el operador de GPU en la documentación de NVIDIA.

  7. Asegúrese de que el operador de GPU NVIDIA se esté ejecutando:

    kubectl --kubeconfig=./KUBECONFIG  get pods -A

    Los resultados son similares a:

    NAMESPACE         NAME                                                              READY   STATUS     RESTARTS   AGE
gpu-operator      gpu-feature-discovery-szzkr                                       1/1     Running     0         6m18s
gpu-operator      gpu-operator-1676396573-node-feature-discovery-master-7795vgdnd   1/1     Running     0         7m7s
gpu-operator      gpu-operator-1676396573-node-feature-discovery-worker-bq6ct       1/1     Running     0         7m7s
gpu-operator      gpu-operator-84dfbbfd8-jd98f                                      1/1     Running     0         7m7s
gpu-operator      nvidia-container-toolkit-daemonset-6zncv                          1/1     Running     0         6m18s
gpu-operator      nvidia-cuda-validator-2rz4m                                       0/1     Completed   0         98s
gpu-operator      nvidia-dcgm-exporter-vgw7p                                        1/1     Running     0         6m18s
gpu-operator      nvidia-device-plugin-daemonset-mln6z                              1/1     Running     0         6m18s
gpu-operator      nvidia-device-plugin-validator-sczdk                              0/1     Completed   0         22s
gpu-operator      nvidia-driver-daemonset-b7flb                                     1/1     Running     0         6m38s
gpu-operator      nvidia-operator-validator-2v8zk                                   1/1     Running     0         6m18s

Probar el clúster de GPU

Para probar el clúster habilitado para GPU, cree un manifiesto del pod para el ejemplo cuda-vector-add de la documentación de Kubernetes e impleméntelo. El contenedor descargará, ejecutará y realizará un cálculo CUDA con la GPU.

  1. Cree un archivo con el nombre cuda-vector-add.yaml y agregue lo siguiente:

    apiVersion: v1
kind: Pod
metadata:
 name: cuda-vector-add
spec:
 restartPolicy: OnFailure
 containers:
   - name: cuda-vector-add
     # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile
     image: "registry.k8s.io/cuda-vector-add:v0.1"
     resources:
       limits:
         nvidia.com/gpu: 1 # requesting 1 GPU

  2. Aplique el archivo:

    kubectl apply -f cuda-vector-add.yaml

  3. Ejecute:

    kubectl get po cuda-vector-add

    Los resultados son similares a:

    cuda-vector-add   0/1     Completed   0          91s

  4. Ejecute:

    kubectl logs cuda-vector-add

    Los resultados son similares a:

    [Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done

Implementar un clúster de carga de trabajo en un sitio de Edge

Tanzu Kubernetes Grid v1.6+ es compatible con la implementación de clústeres de carga de trabajo en hosts VMware ESXi de Edge. Puede utilizar este enfoque si desea ejecutar muchos clústeres de Kubernetes en diferentes ubicaciones administradas por un clúster de administración central.

Topología: Puede ejecutar clústeres de carga de trabajo de edge en producción con un solo nodo del plano de control y solo uno o dos hosts. Sin embargo, si bien esto utiliza menos CPU, memoria y ancho de banda de red, no tiene las mismas características de resistencia y recuperación de los clústeres Tanzu Kubernetes Grid de producción estándar. Para obtener más información, consulte Arquitectura de referencia de la solución edge de VMware Tanzu 1.0.

Registro local: Para minimizar los retrasos de comunicación y maximizar la resistencia, cada clúster de edge debe tener su propio registro de contenedor de Harbor local. Para obtener una descripción general de esta arquitectura, consulte Registro de contenedores en Descripción general de la arquitectura. Para instalar un registro de Harbor local, consulte Implementar un registro de Harbor sin conexión en vSphere.

Tiempos de espera: Además, cuando un clúster de carga de trabajo de edge tiene su clúster de administración remoto en un centro de datos principal, es posible que deba ajustar ciertos tiempos de espera para permitir que el clúster de administración tenga tiempo suficiente para conectarse con las máquinas del clúster de carga de trabajo. Para ajustar estos tiempos de espera, consulte Ampliar tiempos de espera de clústeres Edge para gestionar una mayor latencia a continuación.

Ampliar tiempos de espera de clústeres Edge para gestionar una mayor latencia

Si el clúster de administración administra de forma remota clústeres de carga de trabajo que se ejecutan en sitios Edge o administra más de 20 clústeres de carga de trabajo, puede ajustar los tiempos de espera específicos para que la API del clúster no bloquee ni elimine máquinas que puedan estar desconectadas temporalmente o que tarden más de 12 minutos en comunicarse con su clúster de administración remoto, especialmente si la infraestructura no está aprovisionada.

Existen tres ajustes que puede ajustar para dar a los clústeres edge más tiempo para comunicarse con su plano de control:

  • MHC_FALSE_STATUS_TIMEOUT: Amplíe el valor predeterminado 12m a, por ejemplo, 40m para evitar que el controlador MachineHealthCheck recree la máquina si su estado en Ready permanece en False durante más de 12 minutos. Para obtener más información sobre las comprobaciones de estado de las máquinas, consulte Configurar comprobaciones de estado de la máquina para clústeres de Tanzu Kubernetes.

  • NODE_STARTUP_TIMEOUT: Amplíe el valor predeterminado de 20m a, por ejemplo, 60m para evitar que el controlador MachineHealthCheck bloquee que las nuevas máquinas se unan al clúster porque tardaron más de 20 minutos en iniciarse, considerando que están en mal estado.

  • etcd-dial-timeout-duration: Amplíe el valor predeterminado de 10m a, por ejemplo, 40s en el manifiesto capi-kubeadm-control-plane-controller-manager para evitar que los clientes etcd del clúster de administración presenten errores antes de tiempo al examinar el estado de etcd en los clústeres de carga de trabajo. El clúster de administración utiliza su capacidad para conectarse con etcd como una barra de medir para el estado de la máquina. Por ejemplo:

    1. En un terminal, ejecute:

      kubectl edit  capi-kubeadm-control-plane-controller-manager -n capi-system

    2. Cambie el valor de --etcd-dial-timeout-duration:

      - args:
     - --leader-elect
     - --metrics-bind-addr=localhost:8080
     - --feature-gates=ClusterTopology=false
     - --etcd-dial-timeout-duration=40s
     command:
     - /manager
     image: projects.registry.vmware.com/tkg/cluster-api/kubeadm-control-plane-controller:v1.0.1_vmware.1

Además, debe tener en cuenta lo siguiente:

  • capi-kubedm-control-plane-manager : Si de alguna manera se "separa" de los clústeres de carga de trabajo, es posible que deba devolverlo en un nuevo nodo para que pueda supervisar etcd en los clústeres de carga de trabajo correctamente.

  • Todas las configuraciones Pinniped en TKG asumen que los clústeres de carga de trabajo están conectados al clúster de administración. En casos de desconexión, debe asegurarse de que los pods de carga de trabajo utilicen cuentas administrativas o de servicio para comunicarse con el servidor de API en los sitios de edge. De lo contrario, la desconexión del clúster de administración interferirá con los sitios de edge que puedan autenticarse a través de Pinniped en los servidores de API de carga de trabajo locales.

check-circle-line exclamation-circle-line close-line
Scroll to top icon