TrueFoundry auf Azure strukturieren: Control Plane und Compute Integration

Die Einrichtung einer Generative AI-Plattform auf Microsoft Azure erfordert das Zusammenfügen verschiedener Compute-, Identitäts- und AI-Primitive. Sie stellen rohe Kapazitäten über Azure Kubernetes Service (AKS) und Spot VMs bereit, verwalten Identitäten über Entra ID und leiten Anfragen an Azure OpenAI weiter. Reibung entsteht, wenn Ihre Infrastruktur-Teams diese Verbindungen für jede neue Modell-Bereitstellung manuell orchestrieren müssen.

TrueFoundry wird als Infrastruktur-Overlay innerhalb Ihres Azure-Abonnements bereitgestellt. Wir übernehmen den Bereitstellungslebenszyklus, die Identitätsföderation und die automatische Skalierung. Dieser Beitrag erläutert die genauen Integrationsmuster, die wir zur Verbindung von TrueFoundry mit Azure verwenden, einschließlich Split-Plane-Bereitstellung, Netzwerkgrenzen und Workload-Identitätsmechanismen.

Bereitstellungsmodell: Split-Plane-Architektur

Wir verwenden eine Split-Plane-Architektur, um die Workload-Ausführung vom Plattform-Management zu isolieren. Wenn Sie Plattformen auf Amazon EKS aufbauen, wird Ihnen dieses Modell bekannt vorkommen: Sie trennen die Steuerungsebene (Control Plane) von der Datenebene (Data Plane).

• Die Control Plane: Fungiert als API-Server und Metadaten-Speicher. Sie enthält Bereitstellungsmanifeste, RBAC-Konfigurationen und Telemetriedaten.
• Die Compute Plane: Läuft innerhalb Ihres AKS-Clusters. Sie besteht aus dem TrueFoundry-Agenten, lokalen Controllern sowie Ihren eigentlichen Modellgewichten und GPUs.

Wir verbinden die beiden Ebenen über einen sicheren, reinen Ausgehend-gRPC-Stream (gRPC) oder WebSocket. Der clusterseitige Agent leitet die Verbindung zur Control Plane ein, um Manifeste abzurufen und Protokolle zu übermitteln. Sie müssen keine eingehenden Ports in Ihren VNET Network Security Groups öffnen. Ihr VNET blockiert externen Ingress aus dem Internet standardmäßig.

‍

Abb. 1: Die Split-Plane-Architektur isoliert die Datenverarbeitung innerhalb des Kunden-VNETs.

Netzwerktopologie und Datenfluss

Wir konfigurieren das Netzwerk der Compute Plane unter Verwendung von Azure CNI für eine direkte IP-Zuweisung auf Pod-Ebene. Ihre Compute-Ressourcen verbleiben in privaten Subnetzen.

Ingress und Egress

• Eingehender Datenverkehr (Inbound): Anwendungs-Traffic trifft auf ein Azure Application Gateway oder einen Standard-internen Load Balancer. Das Gateway terminiert TLS und leitet den Datenverkehr an das Istio Ingress Gateway weiter, das innerhalb von AKS läuft.
• Ausgehender Datenverkehr (Outbound): AKS-Worker-Nodes leiten ausgehende Aufrufe über ein Azure NAT Gateway. Sie nutzen diesen Pfad, um Images aus der Azure Container Registry abzurufen und die Control Plane abzufragen.

Private Endpoint-Integration

Für strenge Compliance-Vorgaben leiten wir den Datenverkehr über Azure Private Link. Verbindungen von Ihren Inferenz-Pods zu Azure OpenAI, Key Vault und Blob Storage verlaufen vollständig über das Microsoft-Backbone.

‍

Abb. 2: Netzwerkdatenfluss mit Details zu Ingress und privater Konnektivität zu Azure PaaS.

Identitätsföderation: Entra Workload ID

Hartcodierte statische Secrets und Service Principals verursachen erheblichen Rotationsaufwand. Wir authentifizieren Workloads dynamisch über Microsoft Entra Workload ID. Wenn Sie AWS-Umgebungen verwalten, ist dies das Azure-Äquivalent zu AWS IAM Roles for Service Accounts (IRSA).

Wenn Sie eine Pipeline bereitstellen, führen wir folgende Sequenz aus:

1. Erstellung des Service Accounts: Wir stellen einen Kubernetes Service Account im Namespace des Workloads bereit.
2. Föderation: Wir verknüpfen diesen Service Account mit einer benutzerseitig zugewiesenen Managed Identity in Entra ID.
3. Token-Austausch: Der Pod fordert ein signiertes Token vom AKS OIDC Issuer an. Das Azure SDK tauscht dieses Token über den OpenID Connect-Endpunkt gegen ein Entra-Access-Token aus.
4. Ressourcenzugriff: Der Pod verwendet dieses Token, um Modelle aus dem Blob Storage abzurufen oder Azure OpenAI aufzurufen.

Wir verwenden DefaultAzureCredential im Anwendungscode. Dadurch wird der Zugriffsradius strikt auf die RBAC-Berechtigungen beschränkt, die dieser spezifischen Managed Identity erteilt wurden.

‍

Abb. 3: Der Authentifizierungsablauf von Entra Workload ID.

Compute-Orchestrierung: Spot VM-Integration

Die Ausführung kontinuierlicher Inferenz auf On-Demand-VMs führt häufig zu höheren Basiskosten. Wir integrieren uns direkt in AKS-Knotenpools, um Azure Spot Virtual Machines zu orchestrieren (ähnlich der Nutzung von Amazon EC2 Spot Instances).

Wir verwalten Spot-Kapazitäten nach folgender Logik:

• Bereitstellung: Wir erstellen sekundäre Knotenpools mit priority=Spot und eviction-policy=Delete.
• Eviction-Handling: Unser Controller fragt den Azure Instance Metadata Service ab. Wenn wir eine Räumungsbenachrichtigung (eine 30-Sekunden-Warnung) erkennen, sperren (cordon) wir den Knoten und veranlassen den Kubernetes Cluster Autoscaler, den Pod auf einen On-Demand-Fallback-Knoten neu zu terminieren.

Für Teams, die batch inference oder fehlertolerante API-Bereitstellung ausführen, kann dieses Setup – ähnlich wie der Einsatz von Karpenter auf AWS – die Compute-Instanzkosten je nach Flexibilität der Workloads um bis zu 80 % reduzieren.

Das AI Gateway: Vereinheitlichung von Modellen

Die Verwaltung verschiedener API-Schlüssel und Token-Per-Minute-Limits (TPM) über mehrere Azure-Regionen hinweg erzeugt betrieblichen Aufwand. Das TrueFoundry AI Gateway abstrahiert dies. Ähnlich wie beim Routing von Anfragen über Amazon Bedrock greifen Entwickler auf einen einzigen internen API-Endpunkt zu.

• Intelligentes Routing: Wir verteilen Anfragen per Load Balancing über Azure-Regionen hinweg. Wenn East US Ihre Anfrage per Rate-Limit drosselt, versucht das Gateway es erneut über West Europe.
• Failover: Bei einem Azure PaaS-Ausfall kann das Gateway den Datenverkehr auf eine Llama 3- oder Mistral-Instanz umleiten, die direkt auf Ihrer AKS Compute Plane gehostet wird.

Kompatibilität mit Infrastructure as Code

Wir orientieren uns an Standard-GitOps- und Infrastructure-as-code-Praktiken (IaC). Sie stellen die zugrundeliegende Azure-Umgebung mithilfe unserer gewarteten Terraform-Module bereit.

Ihr Terraform-State verwaltet die VNETs, den AKS-Cluster, die OIDC-Issuer und die zugrundeliegenden PostgreSQL-Datenbanken. Das TrueFoundry-Overlay wird einfach auf diese nativen Ressourcen gemappt, wodurch Ihre Infrastruktur auditierbar und konform bleibt.

Betriebsvergleich

Zusammenfassung

Die Bereitstellung von TrueFoundry auf Azure isoliert Ihre Compute- und Datenausführung, während wir den Anwendungslebenszyklus verwalten. Sie behalten die direkte Kontrolle über Ihre VNETs, NSGs und Datenresidenzgrenzen. Wir übernehmen die Orchestrierung. Indem wir die komplexe Verbindung zwischen AKS, Entra ID und Azure OpenAI abstrahieren, ermöglichen wir Ihren Engineering-Teams, sich auf die Bereitstellung von Modellen zu konzentrieren, anstatt sich mit der Infrastruktur zu befassen.

‍