Tanzu Kubernetes Grid prend en charge le déploiement de clusters de charge de travail sur des types spécifiques d'hôtes compatibles GPU sur vSphere 7.0 et versions ultérieures.
Pour utiliser un nœud avec un GPU dans un cluster de charge de travail vSphere, vous devez activer le mode relais PCI. Cela permet au cluster d'accéder au GPU directement, en contournant l'hyperviseur ESXi, ce qui fournit un niveau de performance semblable à celui du GPU sur un système natif. Lorsque le mode relais PCI est utilisé, chaque périphérique GPU est dédié à une machine virtuelle (VM) dans le cluster de charge de travail vSphere.
RemarquePour ajouter des nœuds compatibles GPU aux clusters existants, utilisez la commande
tanzu cluster node-pool set
.
Pour créer un cluster de charge de travail avec des hôtes compatibles GPU, procédez de la manière suivante pour activer le relais PCI, créer une image de machine personnalisée, créer un fichier de configuration de cluster et une version de Tanzu Kubernetes, déployer le cluster de charge de travail et installer un opérateur GPU avec Helm.
Ajoutez les hôtes ESXi avec les cartes GPU à votre instance de vSphere Client.
Activez le relais PCI et enregistrez les ID de GPU comme suit :
GPU
.Créez un fichier de configuration de cluster de charge de travail à l'aide du modèle dans Modèle de cluster de charge de travail et incluez les variables suivantes :
...
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"
Où :
<VENDOR-ID>
et <DEVICE-ID>
correspond à l'ID de fournisseur et à l'ID de périphérique que vous avez enregistrés à une étape précédente. Par exemple, si l'ID de fournisseur est 10DE
et que l'ID de périphérique est 1EB8
, la valeur est "0x10DE:0x1EB8"
.<GPU-SIZE>
correspond à la taille totale de mémoire tampon de trame (en Go) de tous les GPU du cluster arrondie à la puissance de deux suivante.
pciPassthru.64bitMMIOSizeGB=128
.<BOOLEAN>
est défini sur false
si vous utilisez le GPU NVIDIA Tesla T4 et true
si vous utilisez le GPU NVIDIA V100.<VSPHERE_WORKER_HARDWARE_VERSION>
est la version matérielle de la machine virtuelle vers laquelle nous voulons mettre à niveau la machine. La version minimale requise pour les nœuds GPU doit être 17.WORKER_ROLLOUT_STRATEGY
est défini sur RollingUpdate
si vous disposez de périphériques PCI supplémentaires pouvant être utilisés par les nœuds worker lors des mises à niveau. Sinon, utilisez OnDelete
.RemarqueVous ne pouvez utiliser qu'un seul type de GPU par machine virtuelle. Par exemple, vous ne pouvez pas utiliser NVIDIA V100 et NVIDIA Tesla T4 sur une seule machine virtuelle, mais vous pouvez utiliser plusieurs instances de GPU avec les mêmes ID de fournisseur et ID de périphérique.
La CLI
tanzu
n'autorise pas la mise à jour de la spécificationWORKER_ROLLOUT_STRATEGY
sur leMachineDeployment
. Si la mise à niveau du cluster est bloquée en raison de périphériques PCI non disponibles, VMware suggère de modifier la stratégieMachineDeployment
à l'aide de la CLIkubectl
. La stratégie de déploiement est définie dansspec.strategy.type
.
Pour obtenir la liste complète des variables que vous pouvez configurer pour les clusters compatibles GPU, reportez-vous à la section Clusters compatibles GPU dans Référence de variable de fichier de configuration.
Créez le cluster de charge de travail en exécutant :
tanzu cluster create -f CLUSTER-CONFIG-NAME
Où CLUSTER-CONFIG-NAME
est le nom du fichier de configuration du cluster que vous avez créé dans les étapes précédentes.
Ajoutez le référentiel NVIDIA Helm suivant :
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
&& helm repo update
Installez l'opérateur NVIDIA GPU :
helm install --kubeconfig=./KUBECONFIG --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator
Où KUBECONFIG
est le nom et l'emplacement du fichier kubeconfig
de votre cluster de charge de travail. Pour plus d'informations, reportez-vous à la section Récupérer le cluster de charge de travail kubeconfig
.
Pour plus d'informations sur les paramètres de cette commande, reportez-vous à la section Installer l'opérateur GPU dans la documentation NVIDIA.
Assurez-vous que l'opérateur NVIDIA GPU est en cours d'exécution :
kubectl --kubeconfig=./KUBECONFIG get pods -A
Le résultat est semblable à ce qui suit :
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
Pour tester votre cluster compatible GPU, créez un manifeste d'espace pour l'exemple cuda-vector-add
dans la documentation Kubernetes et déployez-le. Le conteneur téléchargera, exécutera et effectuera un calcul CUDA avec le GPU.
Créez un fichier nommé cuda-vector-add.yaml
et ajoutez ce qui suit :
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
Appliquez le fichier :
kubectl apply -f cuda-vector-add.yaml
Exécutez ce qui suit :
kubectl get po cuda-vector-add
Le résultat est semblable à ce qui suit :
cuda-vector-add 0/1 Completed 0 91s
Exécutez ce qui suit :
kubectl logs cuda-vector-add
Le résultat est semblable à ce qui suit :
[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
Tanzu Kubernetes Grid v1.6 et versions ultérieures prend en charge le déploiement de clusters de charge de travail sur les hôtes ESXi VMware du dispositif Edge. Vous pouvez utiliser cette approche pour exécuter de nombreux clusters Kubernetes dans différents emplacements tous gérés par un cluster de gestion central.
Topologie : Vous pouvez exécuter des clusters de charge de travail Edge en production avec un nœud de plan de contrôle unique et un ou deux hôtes seulement. Cependant, bien que cela utilise moins de CPU, de mémoire et de bande passante réseau, vous n'avez pas les mêmes caractéristiques de résilience et de récupération que les clusters Tanzu Kubernetes Grid de production standard. Pour plus d'informations, reportez-vous à la section Architecture de référence de la solution VMware Tanzu Edge 1.0.
Registre local : Pour réduire les délais de communication et maximiser la résilience, chaque cluster Edge doit disposer de son propre registre de conteneur Harbor local. Pour obtenir un aperçu de cette architecture, reportez-vous à la section Registre de conteneur dans Présentation de l'architecture. Pour installer un registre Harbor local, reportez-vous à la section Déployer un registre Harbor hors ligne sur vSphere.
Délais d'attente : En outre, lorsqu'un cluster de charge de travail Edge dispose de son cluster de gestion distant dans un centre de données principal, vous devrez peut-être ajuster certains délais d'attente pour laisser au cluster de gestion suffisamment de temps afin de se connecter aux machines du cluster de charge de travail. Pour ajuster ces délais d'attente, reportez-vous à la section Extension des délais d'attente pour les clusters Edge afin de gérer une latence plus élevée ci-dessous.
Si votre cluster de gestion gère à distance des clusters de charge de travail s'exécutant sur des sites Edge ou gère à distance plus de 20 clusters de charge de travail, vous pouvez ajuster des délais d'attente spécifiques afin que l'API de cluster ne bloque pas ou ne supprime pas les machines qui peuvent être temporairement hors ligne ou qui prennent plus de 12 minutes pour communiquer avec leur cluster de gestion à distance, en particulier si votre infrastructure est sous-provisionnée.
Voici trois paramètres que vous pouvez ajuster pour donner à vos clusters Edge un délai supplémentaire pour communiquer avec leur plan de contrôle :
MHC_FALSE_STATUS_TIMEOUT
: Augmentez la valeur par défaut de 12m
pour, par exemple, 40m
, afin d'empêcher le contrôleur MachineHealthCheck
de recréer la machine si sa condition Ready
reste False
pendant plus de 12 minutes. Pour plus d'informations sur les contrôles de santé de la machine, reportez-vous à la section Configurer les contrôles de santé de la machine pour les clusters Tanzu Kubernetes.
NODE_STARTUP_TIMEOUT
: Augmentez la valeur par défaut de 20m
pour, par exemple, 60m
empêcher le contrôleur MachineHealthCheck
de bloquer l'accès au cluster pour de nouvelles machines lorsqu'elles ont mis plus de 20 minutes à démarrer, ce qu'il considère comme défectueux.
etcd-dial-timeout-duration
: Étendez la valeur par défaut de 10m
à 40s
(par exemple) dans le manifeste capi-kubeadm-control-plane-controller-manager
pour empêcher l'échec prématuré des clients etcd
sur le cluster de gestion lors de l'analyse de la santé de etcd
sur les clusters de charge de travail. Le cluster de gestion utilise sa capacité à se connecter à etcd
comme critère pour la santé de la machine. Par exemple :
Dans un terminal, exécutez :
kubectl edit capi-kubeadm-control-plane-controller-manager -n capi-system
Modifiez la valeur 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
En outre, vous voudrez noter les éléments suivants :
capi-kubedm-control-plane-manager : S'il devient « séparé » des clusters de charge de travail d'une manière ou d'une autre, vous devrez peut-être le faire rebondir vers un nouveau nœud, afin qu'il puisse surveiller correctement etcd
dans les clusters de charge de travail.
Les configurations Pinniped dans TKG supposent toutes que vos clusters de charge de travail sont connectés à votre cluster de gestion. En cas de déconnexion, vous devez vous assurer que les espaces de charge de travail utilisent des comptes administratifs ou de service pour communiquer avec le serveur d'API sur vos sites Edge. Dans le cas contraire, la déconnexion du cluster de gestion interférera avec la capacité de vos sites Edge à s'authentifier via Pinniped sur leurs serveurs d'API de charge de travail locaux.