Transformez votre capacité GPU en une offre commerciale de Kubernetes managé

Un neocloud est un fournisseur de services cloud dont l’offre repose sur la capacité de calcul GPU dédiée à l’IA, plutôt que sur le calcul généraliste. La plupart ont commencé par louer à l’heure des serveurs GPU bare metal et enrichissent désormais leur offre avec des services Kubernetes managés, du GPU à la demande (GPU-as-a-service) et, dans certains cas, des services d’inférence, afin de proposer aux entreprises clientes une plateforme plutôt que de simples serveurs. Cette évolution augmente les revenus potentiels par heure de GPU, tout en renforçant les attentes des clients à l’égard du réseau sous-jacent.

L’isolation s’effectue à plusieurs niveaux. Les espaces de noms et le contrôle d’accès basé sur les rôles délimitent ce que chaque locataire peut gérer, tandis que les clusters virtuels ajoutent un plan de contrôle par locataire. L’isolation au niveau du réseau, généralement assurée par EVPN-VXLAN avec une VRF dédiée par locataire, maintient le trafic de chaque locataire dans son propre domaine de routage à l’entrée et à la sortie du cluster. Des politiques d’entrée, de sortie et de pare-feu propres à chaque locataire, appliquées à la périphérie du cluster, régissent ensuite les ressources auxquelles chacun peut accéder.

La location de serveurs bare metal porte sur des serveurs entiers, sur lesquels le locataire installe et exploite sa propre pile logicielle. Le GPU en tant que service et Kubernetes managé y ajoutent une couche de plateforme : ordonnancement, mise en réseau, isolation des locataires, gestion des flux entrants et sortants, et support. Le fournisseur assume davantage de responsabilités et peut facturer un tarif horaire par GPU plus élevé. De leur côté, les entreprises locataires attendent de plus en plus cette plateforme, plutôt que de simples serveurs.

Attribuez à chaque locataire son propre chemin de sortie. Un trafic sortant propre à chaque locataire, avec des adresses sources stables, permet aux systèmes externes d’autoriser un locataire en fonction de son adresse, évite que le trafic d’un locataire semble provenir d’un autre et facilite la journalisation et l’audit des connexions sortantes par destination. Les politiques réseau Kubernetes sont utiles, mais elles s’appliquent au niveau des pods et des blocs d’adresses IP au sein du cluster.

Non. BIG-IP Next for Kubernetes s’exécute sur les processeurs standard de l’hôte, où sont également assurés l’isolation des locataires ainsi que le traitement du trafic entrant et sortant. Les DPU NVIDIA BlueField déchargent l’hôte du traitement du chemin de données et appliquent les politiques en dehors du système d’exploitation de l’hôte. Cette approche devient intéressante à mesure que le nombre de locataires augmente et que les cœurs de l’hôte gagnent en valeur en tant que capacité commercialisable. Les résultats mesurés en mode DPU ne sont pas transposables aux déploiements sur hôte.