Simulation du partage de GPU multi-locataire avec Kamaji et HAMi

Les ingénieurs de plateforme sont souvent confrontés à un compromis difficile entre l'efficacité des ressources et l'isolation des locataires lors de la gestion de charges de travail GPU. Une récente démonstration par Anish Bista montre comment la combinaison de Kamaji et HAMi permet aux équipes de partager des GPU physiques en toute sécurité tout en maintenant des plans de contrôle distincts. Cette approche utilise du matériel simulé pour valider l'architecture avant de s'engager dans une infrastructure coûteuse.

Ce qui s'est passé

L'article détaille un environnement de laboratoire reproductible construit sur un seul hôte Linux utilisant des conteneurs Docker. L'objectif était de prouver que deux projets open source, Kamaji et HAMi, peuvent fonctionner ensemble pour résoudre le problème de sous-utilisation des GPU dans les clusters Kubernetes multi-locataires. Traditionnellement, attribuer une carte GPU complète à un pod qui n'a besoin que d'une fraction de sa mémoire entraîne un gaspillage important. Inversement, partager un cluster entre plusieurs équipes aboutit souvent à une isolation faible et à des risques de sécurité.

Bista a construit un cluster de gestion en utilisant kind (Kubernetes in Docker) pour héberger Kamaji. Au sein de cette couche de gestion, deux plans de contrôle de locataires séparés ont été créés sous forme de pods. Chaque locataire disposait de son propre nœud de travail, également exécuté sous forme de conteneur, qui rejoignait le réseau et exécutait les composants HAMi. La configuration comprenait deux locataires simulés : tenant-a avec un NVIDIA A100 simulé et tenant-b avec deux cartes NVIDIA L4 simulées. Le laboratoire a réussi huit tests, confirmant que chaque locataire pouvait planifier des charges de travail GPU fractionnées sans voir les ressources ou les pods appartenant à l'autre.

Comment cela fonctionne

Kamaji répond à la surcharge du plan de contrôle en exécutant le serveur API Kubernetes et le magasin de données etcd de chaque locataire sous forme de pods au sein d'un cluster de gestion central. Cela élimine le besoin de machines dédiées au plan de contrôle pour chaque équipe. HAMi, quant à lui, opère au niveau de la planification et des périphériques. Il permet aux pods de demander des tranches spécifiques d'un GPU, définies par la mémoire en mégaoctets et le pourcentage de calcul, plutôt que de revendiquer une carte entière. Cela permet à plusieurs pods provenant de différentes applications de coexister sur un seul GPU physique.

Le point d'intégration critique implique le chemin de communication entre le serveur API du locataire et le webhook HAMi. Puisque le serveur API s'exécute dans le cluster de gestion mais que le webhook réside sur les nœuds de travail du locataire, la connexion doit traverser un tunnel Konnectivity. Le laboratoire a confirmé que ce mécanisme de proxy inverse fonctionne correctement, permettant au serveur API d'appeler l'environnement du locataire pour les décisions de planification. Pour tester cela sans matériel physique, l'auteur a utilisé le plugin de périphérique fictif de HAMi, qui ignore l'interaction avec le pilote et enregistre une capacité GPU factice via des annotations de nœud.

Détails clés

• Le laboratoire a tourné sur un seul hôte avec 4 cœurs CPU, 8 Go de RAM et 20 Go d'espace disque.
• Tenant-a était configuré avec un NVIDIA A100 simulé de 80 Go, tandis que tenant-b disposait de deux cartes NVIDIA L4 simulées de 24 Go.
• Le réseau IPv6 dans kind a provoqué des échecs de pool MetalLB, nécessitant une inspection manuelle du sous-réseau IPv4 pour corriger la configuration de la passerelle.
• Les pods GPU fictifs ont initialement échoué en raison de la contention de verrouillage de nœud, car le plugin fictif ne libère pas automatiquement les verrous après l'allocation.
• L'annotation manuelle des pods et des nœuds était nécessaire pour simuler l'étape de finalisation du plugin de périphérique dans l'environnement fictif.
• La configuration prouve le câblage et la logique de planification, mais ne valide pas les limites de mémoire réelles ni les performances CUDA.

Pourquoi c'est important

Pour les développeurs logiciels et les ingénieurs de plateforme, cette architecture offre une voie pour réduire significativement les coûts cloud associés aux instances GPU. En permettant l'allocation fractionnée, les organisations peuvent regrouper davantage de charges de travail sur moins de cartes, améliorant les taux d'utilisation sans sacrifier les avantages de sécurité des plans de contrôle isolés. La possibilité de tester cette pile complète à l'aide de matériel simulé signifie que les équipes peuvent valider leur conception de plateforme et leurs pipelines CI/CD avant d'acheter des nœuds GPU coûteux.

De plus, l'intégration réussie de Kamaji et HAMi démontre que les exigences complexes multi-locataires ne nécessitent pas nécessairement du code de liaison personnalisé ou des solutions propriétaires. L'utilisation de tunnels standard comme Konnectivity garantit que le plan de contrôle peut gérer de manière sécurisée des nœuds de travail distribués. Cette modularité permet aux équipes d'adopter ces outils de manière incrémentale, en commençant par la simulation et en passant au matériel de production avec confiance dans les mécanismes de planification sous-jacents.

Ce que vous pouvez faire

• Reproduire l'environnement de laboratoire en utilisant kind et Kamaji pour tester l'isolation des plans de contrôle multi-locataires sur du matériel local.
• Utiliser le plugin de périphérique fictif de HAMi pour valider les politiques de planification et la logique de quota sans avoir besoin de GPU NVIDIA physiques.
• Inspecter manuellement les sous-réseaux réseau Docker si vous rencontrez des problèmes liés à IPv6 avec MetalLB dans les clusters kind.
• Mettre en œuvre des étapes manuelles de libération de verrou dans les environnements de test pour contourner les limitations du plugin fictif pendant le développement.
• Vérifier la connectivité du tunnel Konnectivity entre vos serveurs API du cluster de gestion et les webhooks des nœuds de travail des locataires.
• Prévoir tôt l'intégration de plugins de périphériques réels, car les configurations fictives n'appliquent pas les limites réelles de mémoire ou de calcul.