Architecture de LLM sur OpenShift : résolution des SCC et de l'identité hybride

Les architectes d'entreprise connaissent la réalité du déploiement sur Red Hat OpenShift: kubectl n'applique pas simplement des manifestes standard. Que vous utilisiez sur site, sur Satellite IBM Cloud, ou via Azure Red Hat OpenShift (ARO), les primitives de sécurité, en particulier les contraintes de contexte de sécurité (SCC), vont immédiatement briser les déploiements standard de Kubernetes en amont.

TrueFoundry fonctionne comme une superposition d'orchestration. Nous découplons l'expérience des développeurs de la complexité de l'infrastructure, ce qui vous permet de déployer des LLM tout en respectant les limites strictes de l'écosystème Red Hat. Cet article explique comment nous nous intégrons au réseau d'OpenShift, IBM Cloud IAM, et watsonx.ai.

Le modèle de déploiement : architecture à plans divisés

Nous utilisons une architecture à plans divisés pour répondre aux exigences de résidence des données. Vous contrôlez strictement Plan de calcul; nous gérons les métadonnées dans le Plan de contrôle.

1. Plan de contrôle (SaaS ou VPC) : Gère la gestion des identités, les catalogues de modèles et la planification des tâches.
2. Plan de calcul (votre cluster) : L'agent TrueFoundry s'exécute directement sur votre Plateforme de conteneurs Red Hat OpenShift.

L'agent initie une connexion WebSocket sortante uniquement avec le plan de contrôle. Vous n'ouvrez pas les ports de pare-feu entrants. Cela répond aux exigences de sécurité strictes ou de haute sécurité courantes dans les secteurs de la finance et de la santé.

Figure 1 : TrueFoundry fonctionne dans le plan de calcul local, en respectant le périmètre sécurisé.

Sécurité : automatisation des SCC et du RBAC

Le point de friction dans OpenShift est l'application de Contraintes liées au contexte de sécurité (SCC). Contrairement à Kubernetes en amont, OpenShift empêche les pods de s'exécuter en tant que root ou d'accéder aux chemins hôtes par défaut.

Gestion de Restricted-V2

Nous concevons l'agent TrueFoundry pour qu'il fonctionne dans le SCC v2 restreint.

• Injection UID : Nous ne codons pas en dur les noms d'utilisateur. L'agent détecte la plage d'UID annotée de l'espace de noms et injecte dynamiquement l'ID RunAsUser correct dans la spécification du pod d'inférence lors de l'exécution.
• Abstraction du volume : Nous contournons les exigences de HostPath en utilisant des réclamations de volume persistantes (PVC) soutenues par IBM Cloud Block Storage ou vSphere CSI pour les configurations sur site.

Fédération des identités : IBM Cloud IAM

Les informations d'identification codées en dur dans des secrets constituent un risque de sécurité. Pour les déploiements sur IBM Cloud, nous mettons en œuvre la fédération des identités à l'aide Profils fiables IBM Cloud.

Cela permet à vos charges de travail OpenShift de prendre une identité dynamique. Le pod échange son jeton de compte de service localisé contre un jeton IBM Cloud IAM, accordant un accès temporaire à IBM Cloud Object Storage (COS) ou IBM Key Protect.

Figure 2 : Flux d'authentification utilisant des profils fiables pour éliminer les informations d'identification statiques à longue durée de vie.

Mise en réseau : intégration à OpenShift Routes

Les ressources Kubernetes Ingress standard nécessitent souvent une traduction dans les environnements Red Hat. TrueFoundry s'intègre directement à Contrôleur d'entrée OpenShift (HAProxy).

• Entrée : Lorsque vous déployez un modèle, nous provisionnons automatiquement une route OpenShift, en gérant la terminaison SSL à la périphérie.
• Sortie avec interstice d'air : Pour les environnements déconnectés, nous prenons en charge l'extraction d'images depuis l'intérieur Red Hat Quay registres. Vous pouvez pré-mettre en cache les pondérations des modèles dans un magasin interne compatible S3 afin d'éliminer les dépendances à Internet lors de l'exécution.

Calcul : planification du GPU et Watsonx.ai

Nous interagissons avec Opérateur GPU NVIDIA pour gérer l'accélération matérielle.

Partitionnement MIG

Pour les clusters A100 ou H100, nous prenons en charge Carte graphique multi-instance NVIDIA (MIG). Le planificateur TrueFoundry identifie les profils MIG disponibles et cible les pods vers la bonne partition logique, augmentant ainsi la densité d'utilisation du matériel sans configuration d'affinité manuelle.

La passerelle unifiée

Pour les équipes utilisant watsonx.ai d'IBM, nous fournissons une passerelle IA unifiée.

• Traduction du protocole : Les développeurs utilisent un schéma standard compatible avec OpenAI. La passerelle gère la transformation vers l'API watsonx.ai.
• Télémétrie unifiée : Nous enregistrons les demandes destinées à des modèles auto-hébergés (Llama 3, Mistral) et à des modèles SaaS (Granite, Watsonx) dans un seul volet pour des raisons d'observabilité des coûts et des audits.

Figure 3 : La passerelle unifie le trafic entre les pods auto-hébergés et les services IBM gérés.

Comparaison opérationnelle

Le tableau ci-dessous décrit les changements opérationnels spécifiques lors de la superposition de TrueFoundry sur OpenShift natif.

Continuité architecturale

L'intégration de TrueFoundry à IBM Cloud et Red Hat OpenShift vous permet de maintenir la posture de conformité stricte de l'écosystème Red Hat tout en accélérant le déploiement des modèles. Vous conservez la résidence des données sur OpenShift, que ce soit sur site ou dans le cloud IBM, et vous offrez à vos équipes d'ingénierie une interface unifiée qui fait abstraction des contraintes d'infrastructure sous-jacentes.

‍