Wissensprüfung - Container und KI-Plattform
Ein Team, das eine öffentlich zugängliche Web-Ebene auf einen öffentlichen Managed Kubernetes-Cluster migriert, deklariert einen Service vom Typ LoadBalancer und geht davon aus, dass dieser nun einen hochverfügbaren externen Load Balancer mit Beibehaltung der Quell-IP bereitstellt, der dem Managed Network Load Balancer entspricht, der an anderen Stellen im Unternehmen verwendet wird. Der Architekt widerspricht. Warum ist diese Annahme falsch, und wie ist die korrekte Methode, um die Workload zu fronten?
Bei Managed Kubernetes provisioniert ein LoadBalancer-Service keinen verwalteten externen LB. IONOS CLOUD reserviert eine statische öffentliche IP und hängt sie als sekundäre IP an einen Worker-Knoten an. kube-proxy NATet den Traffic zum Ziel-Pod. Es gibt daher keine Hochverfügbarkeit, die Quell-IP geht verloren, es sei denn, externalTrafficPolicy ist auf Local gesetzt, und die Durchsatzrate ist auf das öffentliche Limit dieses einzelnen Knotens beschränkt. Der Produktions-Ingress wird erstellt, indem ein Load Balancer separat provisioniert und ein Ingress-Controller innerhalb des Clusters ausgeführt wird, da Manifeste keinen verwalteten LB automatisch provisionieren. Das Hochskalieren des Pools oder die Änderung von externalTrafficPolicy verwandelt den einzelnen Ingress-Knoten nicht in einen verwalteten L4-Balancer mit mehreren Knoten.
Ein kostenbewusstes Team, das Batch-Jobs in einem Managed Kubernetes-Cluster ausführt, möchte, dass der Node-Pool nachts auf null Nodes skaliert, wenn keine Jobs laufen. Außerdem soll die Ereignisse der Steuerungsebene des Clusters in den zentralen Logging Service fließen, neben den Anwendungslogs. Die Architektin erklärt, dass beide Erwartungen mit den Plattformgrenzen kollidieren. Welche Aussage beschreibt diese Grenzen korrekt?
Der Mindestwert des Autoscalers in Managed Kubernetes ist ein warmer Node. Es gibt keine Skalierung auf null, daher muss ein Batch-Design davon ausgehen, dass mindestens ein Node dauerhaft läuft und abgerechnet wird. Unabhängig davon werden Ereignisse der Steuerungsebene nicht über den Logging Service bereitgestellt. Eine zentrale Beobachtbarkeit der verwalteten Steuerungsebene ist daher nicht verfügbar, und die Sichtbarkeit muss aus Signalen innerhalb des Clusters bezogen werden. Diese Grenzen sind unabhängig vom Clustertyp und werden durch das Umschalten von Scanning oder Audit-Export nicht aufgehoben.
Ein Architekt entwirft ein privates Managed Kubernetes-Cluster für eine regulierte Arbeitslast und listet die Voraussetzungen auf. Der Aufbau betrifft ein privates Cluster, dessen Datenebene isoliert sein muss, dessen API-Server nur für das Betriebsteam erreichbar bleiben muss und dessen Knoten über ein zweites VDC kommunizieren müssen. Welche Kombination von Entscheidungen ist korrekt?
Private Cluster isolieren die Datenebene, nicht den API-Endpunkt, daher ist der API-Server weiterhin erreichbar und muss mit einer IP-Freigabeliste geschützt werden. Die beiden Netzwerkabhängigkeiten, ein NAT Gateway für den ausgehenden Datenverkehr und ein Cross-Connect für den Knotendatenverkehr zwischen VDCs, müssen vor dem Aufbau des Clusters vorhanden sein, und der Knotenpooltyp ist nach der Erstellung nicht änderbar, sodass er von Anfang an korrekt gewählt werden muss. Sicherheitsgruppen sind an Worker-NICs gebunden und nicht an ein Clusterobjekt, und die Platzierung der Steuerungsebene in der Region ist es, was die Souveränität bewahrt.
Ein Plattformteam möchte den Zugriff auf seine Container Registry auf dieselbe Weise verwalten wie den Zugriff auf seine Cloud-Konten, indem es Rollen wie read-only developer, pipeline-pusher und admin definiert und menschliche Benutzer sowie Gruppen an diese Rollen bindet. Es möchte außerdem eine anonyme öffentliche Pull-Ebene für Open-Source-Images. Die Architektin erklärt, dass die Registry nicht auf diese Weise funktioniert. Was ist das korrekte Governance-Modell?
Die Container Registry bietet ausschließlich Token-basierten Zugriff ohne RBAC und ohne Rollen-Benutzer-Bindungen. Daher gibt es keine IAM-Rollen-Erbschaft und keine öffentliche, anonyme Pull-Ebene. Die Governance wird durch Token-Disziplin durchgesetzt: ein eng umfasstes Token pro Pipeline-Stufe, mit Ablaufdatum und Rotation, und Tokens werden bei Außerdienststellung gelöscht, nicht deaktiviert. Die Ablenkungsoptionen erfinden RBAC, eine öffentliche Pull-Ebene und eine Deaktivierungsaktion, die der Dienst nicht bereitstellt.
Ein Unternehmen möchte generative KI in eine regulierte, inländische Anwendung integrieren und muss sicherstellen, dass alle Verarbeitungsschritte in Deutschland bleiben, das Betreiben und Patchen von GPU-Infrastruktur vermeiden und die Integration über die vorhandenen OpenAI-Client-Bibliotheken erfolgt. Darüber hinaus wird eine Retrieval-Funktion über einen privaten Korpus benötigt. Welcher Ansatz entspricht dem Enterprise-Standard der Plattform und ihrer aktuellen Ausrichtung?
Verwaltete Inferenz auf dem Model Hub ist der Enterprise-Standard: eine OpenAI-kompatible API mit Token-basierter Abrechnung, ein zustandsloser Dienst und eine Verarbeitung, die im Inland stattfindet. Dies eliminiert den Aufwand für das Betreiben und Patchen der GPU-Server. Für das Retrieval ist das nachhaltige Muster kundenseitig aufgebaut: Es verwendet Embeddings aus dem Hub, speichert Vektoren in Managed PostgreSQL und den Korpus in Object Storage. Dabei wird die verwaltete Vektor-Speicher-Funktion, die auf dem Abstellgleis liegt, bewusst vermieden. Das Leiten von Anfragen in eine US-Region verletzt die Inlandsanforderung, und das Selbst-Hosting ab dem ersten Tag übernimmt SLA- und Redundanzverantwortlichkeiten, die in den Anforderungen nicht gefordert wurden.
Ein Kunde deployt ein Open-Source-Modell auf dem AI Model Hub und fragt, wie die Verantwortlichkeiten nach dem EU AI Act verteilt sind, einschließlich des Falls, in dem IONOS CLOUD ein Modell modifiziert, beispielsweise durch Quantisierung. Welche Verteilung ist korrekt?
Gemäß dem EU AI Act ist der Kunde der Deployer oder der Anbieter seines eigenen KI-Systems und ist für seine eigene Risikobewertung verantwortlich. Für die Mehrheit der unveränderten Open-Source-Modelle auf dem Hub agiert IONOS CLOUD als Distributor oder Vermittler, aber wenn IONOS CLOUD ein Modell modifiziert, beispielsweise durch Quantisierung, übernimmt es die Transparenzpflichten eines KI-Anbieters für diese Modifikation. Statelessness und In-Country-Verarbeitung sind Souveränitätseigenschaften und befreien weder Partei vom Gesetz.