Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : ✔️ AKS Automatic ✔️ AKS Standard
L’exécution de charges de travail GPU sur AKS nécessite une configuration appropriée et une validation continue pour garantir que les ressources de calcul sont accessibles, sécurisées et utilisées de manière optimale. Cet article décrit les meilleures pratiques pour la gestion des nœuds avec GPU, la validation des configurations et la réduction des interruptions de charge de travail.
Pour la plupart des charges de travail AKS de production, AKS Automatic est la valeur par défaut recommandée. AKS Automatic fournit une base prête pour la production avec des opérations préconfigurées, des protections de sécurité et une disponibilité des pods garantie par SLA, aidant ainsi les équipes à réduire la surcharge opérationnelle de la plateforme au quotidien.
Choisir AKS Automatic ou AKS Standard pour les charges de travail GPU
Utilisez les conseils suivants comme point de départ :
| Scénario | Chemin recommandé | Pourquoi |
|---|---|---|
| La plupart des charges de travail sur GPU en production | AKS Automatic | Des paramètres par défaut prêts pour la production, des garde-fous intégrés et une réduction de la charge liée aux opérations du cluster. |
| Chemin plus rapide du déploiement à la production stable | AKS Automatic | Opérations de cluster préconfigurées et comportement de démarrage prévisible via le contrat SLA de préparation des pods. |
| Personnalisation avancée de la plateforme et contrôle opérationnel explicite | AKS Standard | Une plus grande flexibilité pour le cycle de vie des pools de nœuds personnalisés et l’optimisation de la plateforme. |
| Exigences en matière d’architecture de plateforme spécialisée et non par défaut | AKS Standard | Contrôle manuel du comportement et de la configuration de l’infrastructure. |
Pour plus d’informations, consultez Présentation de Azure Kubernetes Service (AKS) Automatique.
Ce qu’AKS Automatic fournit pour les charges de travail GPU de production
AKS Automatic permet d’établir une base de référence opérationnelle forte pour les charges de travail GPU de production en fournissant :
- Valeurs par défaut prêtes pour la production pour la configuration du cluster.
- Bonnes pratiques et garanties intégrées.
- État de préparation du pod garanti par un SLA pour un démarrage prévisible.
- Des opérations de gestion du cluster qui réduisent les tâches manuelles du jour 2.
Ces valeurs par défaut de plateforme ne remplacent pas les meilleures pratiques au niveau de la charge de travail, telles que les contrôles de placement, les vérifications de validation et les stratégies d’isolation décrites dans cet article.
Les charges de travail GPU, telles que l’entraînement du modèle IA, l’inférence en temps réel, les simulations et le traitement vidéo, dépendent souvent des suivants :
- Pilote GPU correct et compatibilité d'exécution.
- Planification précise des ressources GPU.
- Accès aux périphériques matériels GPU à l'intérieur des conteneurs.
Des erreurs de configuration peuvent entraîner des coûts élevés, des échecs de tâches inattendus ou une sous-utilisation du GPU.
Appliquer le placement de la charge de travail du GPU
Par défaut, le planificateur AKS place les pods sur n’importe quel nœud disponible avec suffisamment de processeur et de mémoire. Sans contrôles de placement de charge de travail, deux problèmes peuvent se produire :
- Le planificateur peut placer des charges de travail GPU sur des nœuds sans GPU, ce qui entraîne l’échec du démarrage des charges de travail.
- Les charges de travail à usage général peuvent occuper des nœuds GPU, gaspiller des ressources coûteuses.
Pour garantir un placement correct :
Appliquez un taint à vos nœuds GPU en utilisant une clé comme
[gpu-vendor].com/gpu: NoSchedule(par exemple,nvidia.com/gpu: NoSchedule). Ce taint empêche la planification de workloads sans GPU sur ces nœuds.Ajoutez une tolérance correspondante dans la spécification de votre pod de charge de travail GPU afin qu'elle puisse être planifiée sur les nœuds GPU contaminés.
Définissez les demandes et limites des ressources GPU dans votre pod pour garantir que le planificateur réserve la capacité GPU. Par exemple:
resources: limits: [gpu-vendor].com/gpu: 1Définissez les requêtes et les limites de ressources GPU dans votre pod, pour garantir que le respecter réserve la capacité GPU, par exemple.
Cette approche garantit que seules les charges de travail compatibles GPU atterrissent sur les nœuds GPU et ont accès aux ressources de calcul spécialisées dont elles ont besoin.
Dans AKS Automatic, les garde-fous de plateforme sont préconfigurés par défaut. Vous appliquez toujours des contrôles de placement au niveau de la charge de travail pour appliquer un comportement de planification GPU strict.
Valider l’installation du pilote GPU et la préparation du runtime
Avant de déployer des charges de travail GPU de production, vérifiez toujours que vos pools de nœuds GPU sont :
- Équipé de pilotes GPU compatibles.
- Hébergement d'un DaemonSet de plug-ins de périphérique Kubernetes sain.
- Exposer
[gpu-vendor].com/gpucomme une ressource planifiable.
Vous pouvez confirmer la version actuelle du pilote exécutée sur vos pools de nœuds GPU avec l'interface de gestion système (SMI) associée au fournisseur de GPU.
La commande suivante s'exécute nvidia-smi à partir de l'intérieur du pod de déploiement du plug-in de votre périphérique GPU, pour vérifier l'installation du pilote et la préparation de l'exécution sur un pool de nœuds compatible GPU NVIDIA :
kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi
Votre sortie doit ressembler à l’exemple suivant :
+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx Driver Version: 570.xx.xx CUDA Version: 12.x|
...
...
Répétez la kubectl exec commande de chaque pool de nœuds GPU pour confirmer que la version du pilote est installée sur vos nœuds.
Sur vos pools de nœuds compatibles GPU AMD, déployez également les composants GPU AMD et exécutez la commande amd-smi dans le pod du plug-in de périphérique ROCm pour confirmer la version du pilote installée.
Maintenez les nœuds compatibles GPU à jour avec la dernière image du système d'exploitation du nœud
Pour garantir les performances, la sécurité et la compatibilité de vos charges de travail GPU sur AKS, il est essentiel de maintenir vos pools de nœuds GPU à jour avec les dernières images de système d'exploitation de nœud recommandées. Ces mises à jour sont essentielles car elles :
- Incluent les derniers pilotes GPU de qualité production, remplaçant toutes les versions obsolètes ou en fin de vie (EOL).
- Sont entièrement testés pour la compatibilité avec votre version actuelle de Kubernetes.
- Corrigent les vulnérabilités connues identifiées par les fournisseurs de GPU.
- Intègrent les dernières améliorations du système d’exploitation et de l’exécution des conteneurs pour une stabilité et une efficacité accrues.
Mettez à niveau vos pools de nœuds GPU vers la dernière image de système d’exploitation de nœud recommandée publiée par AKS, soit en définissant le canal de mise à niveau automatique , soit via la mise à niveau manuelle. Vous pouvez surveiller et suivre les dernières versions d'images de nœuds à l'aide du suivi des versions AKS.
Pour la plupart des scénarios de production, commencez par AKS Automatic comme base de référence par défaut. Si vous utilisez AKS Standard, configurez explicitement les canaux de mise à niveau et les fenêtres de maintenance.
Séparer les charges de travail GPU lors de l'utilisation de clusters partagés
Si un seul cluster AKS avec des pools de nœuds GPU exécute plusieurs types de charges de travail GPU, telles que la formation de modèles, l'inférence en temps réel ou le traitement par lots, il est important de séparer ces charges de travail pour :
- Éviter les interférences accidentelles ou les conflits de ressources entre différents types de charges de travail.
- Améliorer la sécurité et maintenir les limites de conformité.
- Simplifier la gestion et la surveillance de l’utilisation des ressources GPU par catégorie de charge de travail.
Vous pouvez isoler les charges de travail GPU au sein d’un seul cluster AKS en utilisant des espaces de noms et des stratégies réseau. Cela permet une gouvernance plus claire grâce à des quotas, des limites et des configurations de journalisation spécifiques à la charge de travail.
Exemple de scénario
Considérez un cluster AKS hébergeant deux types de charges de travail GPU différents qui n’ont pas besoin de communiquer entre eux :
- Charges de travail d’entraînement : travaux d’entraînement de modèles IA nécessitant beaucoup de ressources.
- Charges de travail d’inférence : services d’inférence en temps réel sensibles à la latence.
Vous pouvez utiliser les étapes suivantes pour séparer les deux charges de travail :
Créez des espaces de noms dédiés par type de charge de travail à l’aide de la commande
kubectl create namespace.kubectl create namespace gpu-training kubectl create namespace gpu-inferenceÉtiquetez les pods de charge de travail GPU par type, comme indiqué dans l'exemple suivant :
metadata: namespace: gpu-training labels: workload: trainingAppliquez des stratégies réseau pour isoler le trafic entre les types de charges de travail. Le manifeste suivant bloque toutes les entrées et sorties de l'espace de noms
gpu-training(sauf autorisation explicite) :apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-cross-namespace namespace: gpu-training spec: podSelector: {} policyTypes: - Ingress - Egress ingress: [] egress: []
Cette stratégie :
- S'applique à tous les pods de l'espace de noms
gpu-training. - Refuse tout le trafic entrant et sortant par défaut, prenant en charge une isolation forte.
Ce modèle améliore la clarté, le contrôle et la sécurité dans les environnements GPU partagés, en particulier lorsque les types de charge de travail ont des profils d'exécution, des niveaux de risque ou des exigences opérationnelles différents.
Optimiser l'utilisation des ressources sur les nœuds GPU à l'aide du GPU multi-instance (MIG)
Différentes charges de travail GPU ont des besoins en mémoire différents. Des déploiements plus petits, tels que NVIDIA A100 40 Go, n’ont peut-être pas besoin d’un GPU entier. Cependant, une charge de travail unique monopolise par défaut la ressource GPU même lorsqu'elle est sous-utilisée.
AKS prend en charge l'optimisation des ressources sur les nœuds GPU en les divisant en tranches plus petites à l'aide d'un GPU multi-instance (MIG), afin que les équipes puissent planifier des tâches plus petites plus efficacement. En savoir plus sur les tailles de GPU prises en charge et comment démarrer avec les GPU multi-instances sur AKS.
Utiliser des disques de données NVMe éphémères comme cache hautes performances
Pour les charges de travail IA s’exécutant sur des machines virtuelles GPU dans AKS, un accès rapide et fiable au stockage temporaire est essentiel pour optimiser les performances d’apprentissage et d’inférence. Les disques de données NVMe éphémères fournissent un stockage à débit élevé et à faible latence directement attaché à l’hôte de machine virtuelle, ce qui les rend idéaux pour les scénarios tels que la mise en cache des jeux de données, le stockage de points de contrôle intermédiaires et les pondérations de modèle, ou la fourniture d’un espace de travail pour le prétraitement et l’analytique des données.
Lors du déploiement de pools de nœuds avec GPU pour les charges de travail IA, configurez des disques de données NVMe éphémères pour servir de cache hautes performances ou d’espace de travail. Cette approche permet d’éliminer les goulots d’étranglement des E/S, d’accélérer les opérations gourmandes en données et de s’assurer que vos ressources GPU ne sont pas en attente de données.
Azure prend en charge les disques de données NVMe éphémères sur un large éventail de familles de machines virtuelles GPU Azure. Selon la taille de la machine virtuelle GPU, elle dispose de jusqu’à huit disques de données NVMe éphémères, pour une capacité combinée maximale de 28 Tio. Pour obtenir des configurations détaillées sur les tailles de machine virtuelle, reportez-vous à la documentation de la série ND H100 v5 ou à la documentation sur la taille de machine virtuelle pour votre famille GPU choisie.
Pour simplifier l’approvisionnement et la gestion, utilisez Stockage Conteneur Azure, qui peut détecter et orchestrer automatiquement des disques NVMe éphémères pour vos charges de travail Kubernetes.
Les scénarios recommandés sont les suivants :
- Mise en cache de jeux de données volumineux et de checkpoints de modèle pour l’apprentissage et l’inférence IA.
- Mise en cache des pondérations de modèle pour l’inférence IA. Par exemple, le modèle d'hébergement KAITO en tant qu'artefacts OCI sur NVMe local.
- Fournir un espace de stockage temporaire rapide pour les travaux par lots et les pipelines de données.
Important
Les données sur les disques NVMe éphémères sont temporaires et seront perdues si la machine virtuelle est libérée ou redéployée. Utilisez ces disques uniquement pour les données non critiques, temporaires et stockez des informations importantes sur les solutions de stockage Azure persistantes.
Pour plus d’informations sur les disques de données NVMe éphémères, consultez les meilleures pratiques pour les disques de données NVMe éphémères dans AKS.
Contenu connexe
Pour en savoir plus sur les charges de travail AKS et GPU, consultez les articles suivants :
- Introduction à Azure Kubernetes Service (AKS) automatique
- Créer un cluster automatique AKS
- Créez un pool de nœuds compatible GPU sur votre cluster AKS.
- Surveillez les charges de travail du GPU à l'aide de l'exportateur NVIDIA DCGM autogéré.
- Mettez automatiquement à l'échelle vos charges de travail GPU en fonction des métriques GPU courantes avec l'exportateur KEDA et DCGM.