Wissensprüfung - Container und AI-Plattform
Ein Team, das eine öffentlich zugängliche Web-Ebene auf einen Managed Kubernetes-Public-Cluster migriert, erklärt einen Service vom Typ LoadBalancer und geht davon aus, dass es jetzt einen hochverfügbaren, Quell-IP-erhaltenden externen Load Balancer-Äquivalent zum Managed Network Load Balancer hat, der anderswo im Besitz verwendet wird. Der Architekt widerspricht. Warum ist diese Annahme falsch, und wie ist die richtige Methode, um den Workload zu veröffentlichen?
Auf Managed Kubernetes stellt ein LoadBalancer-Service keinen gemanagten externen Lastenausgleich bereit. IONOS reserviert eine statische öffentliche IP und hängt sie als sekundäre IP an einen Worker-Node an, und kube-proxy NATs den Datenverkehr zum Ziel-Pod, sodass es keine Hochverfügbarkeit gibt, die Quell-IP verloren geht, es sei denn, externalTrafficPolicy ist auf Local eingestellt, und die Durchsatzleistung ist auf die öffentliche Obergrenze dieses einzelnen Node begrenzt. Die Produktions-Eingabe wird durch die separate Bereitstellung eines Load Balancer und das Ausführen eines In-Cluster-Eingangs-Controllers erstellt, da Manifestdateien keinen gemanagten Lastenausgleich automatisch bereitstellen. Die Skalierung des Pools oder die Änderung von externalTrafficPolicy wandelt den einzelnen Eingangs-Node nicht in einen gemanagten Multi-Node-L4-Lastenausgleich um.
Ein kostbewusstes Team, das Batch-Jobs auf einem Managed Kubernetes Cluster ausführt, möchte, dass der Node-Pool über Nacht auf null Knoten fällt, wenn keine Jobs ausgeführt werden, und es möchte auch, dass die Steuerungsereignisse des Cluster in die zentrale Logging Service neben den Anwendungsprotokollen fließen. Der Architekt erklärt, dass beide Erwartungen mit den Plattformgrenzen kollidieren. Welche Aussage beschreibt diese Grenzen korrekt?
Die Autoskalierungs-Untergrenze auf dem Managed Kubernetes beträgt einen warmen Node; es gibt keine Skalierung auf null, so dass eine Batch-Konstruktion davon ausgehen muss, dass mindestens ein Node immer ausgeführt wird und berechnet wird. Separat davon werden Steuerungsereignisse nicht durch die Logging Service bereitgestellt, so dass eine zentrale Beobachtbarkeit der gemanagten Steuerungsebene nicht verfügbar ist und die Sichtbarkeit aus internen Cluster-Signalen bezogen werden muss. Diese Grenzen sind unabhängig vom Cluster-Typ und werden nicht durch das Umschalten der Analyse oder der Audit-Exportfunktion freigeschaltet.
Ein Architekt entwirft ein privates Managed Kubernetes Cluster für einen regulierten Workload und listet die Voraussetzungen auf. Der Build ist für ein privates Cluster, dessen Daten-Ebene isoliert werden muss, dessen API-Server nur von dem Operations-Team erreichbar bleiben muss und dessen Knoten über ein zweites VDC kommunizieren müssen. Welche Menge von Entscheidungen ist korrekt?
Private Cluster isolieren die Daten-Ebene, nicht den API-Endpunkt, so dass der API-Server immer noch erreichbar ist und mit einer IP-Allowlist geschützt werden muss. Die beiden Netzwerkabhängigkeiten, ein NAT-Gateway für Egress und eine Cross-Connect für Cross-VDC-Node-Verkehr, müssen vor dem Bau des Cluster existieren, und der Node-Pool-Typ ist nach der Erstellung nicht mehr änderbar, so dass er von vornherein korrekt gewählt werden muss. Sicherheitsgruppen binden an Worker-NICs und nicht an ein Cluster-Objekt, und die Platzierung der Steuerungsebene in der Region ist es, was die Souveränität bewahrt.
Ein Plattformteam möchte den Zugriff auf sein Container-Registrierung auf die gleiche Weise regeln, wie es seine Cloud-Konten regelt, indem es Rollen wie lesenden Entwickler, Pipeline-Pusher und Administrator definiert und menschliche Benutzer und Gruppen diesen Rollen zuweist. Sie möchten auch eine anonyme öffentliche Pull-Ebene für Open-Source-Images. Der Architekt erklärt, dass das Registrierungssystem nicht so funktioniert. Was ist das korrekte Regierungsmodell?
Das Container-Registrierungssystem bietet einen tokenbasierten Zugriff ohne RBAC und ohne Rollen-zu-Benutzer-Zuweisungen, so dass es keine IAM-Rollenvererbung und keine öffentliche, anonyme Pull-Ebene gibt. Die Regulierung wird durch Token-Discipline durchgesetzt: ein eng gefasster Token pro Pipeline-Stage, mit Ablauf und Rotation, und Token werden gelöscht anstelle von deaktiviert, wenn sie ausgemustert werden. Die Ablenker erfinden RBAC, eine öffentliche Pull-Ebene und eine Deaktivierungsaktion, die der Dienst nicht bereitstellt.
Ein Unternehmen möchte generative Künstliche Intelligenz (KI) zu einer regulierten, inländischen Anwendung hinzufügen und muss alle Verarbeitungen in Deutschland durchführen, das Ausführen und Patchen von GPU-Infrastruktur vermeiden und über seine vorhandenen OpenAI-Client-Bibliotheken integrieren. Es benötigt auch den Abruf über einen privaten Korpus. Welcher Ansatz passt zur Standardplattform des Unternehmens und seiner aktuellen Ausrichtung?
Die verwaltete Inferenz auf dem Modell-Hub ist der Standard für das Unternehmen: eine OpenAI-kompatible API mit Token-Preisen, ein zustandsloser Dienst und eine Verarbeitung, die in Deutschland erfolgt, was die Last des Ausführens und Patchens von GPU-Servern beseitigt. Für den Abruf ist das dauerhafte Muster kundenseitig erstellt, unter Verwendung von Embeddings aus dem Hub, Vektoren, die in Managed PostgreSQL gespeichert sind, und dem Korpus in Object Storage, wobei das veraltete, verwaltete Vektor-Speicher-Feature bewusst vermieden wird. Die Weiterleitung an eine US-Region verletzt die Anforderung der inländischen Verarbeitung, und das Selbst-Hosting von Tag eins an übernimmt SLA- und Redundanz-Verantwortungen, die die Anforderungen nicht verlangt haben.
Ein Kunde deployt ein Open-Source-Modell auf dem AI Model Hub und fragt, wie die Verantwortlichkeiten nach dem EU-KI-Gesetz zugewiesen werden, einschließlich des Falls, in dem IONOS ein Modell modifiziert, zum Beispiel durch Quantisierung. Welche Zuweisung ist korrekt?
Nach dem EU-KI-Gesetz 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 unmodifizierten Open-Source-Modelle auf dem Hub handelt IONOS als Vertrieb oder Zwischenhändler, aber wenn IONOS ein Modell modifiziert, zum Beispiel durch Quantisierung, übernimmt es die Transparenzverpflichtungen des KI-Anbieters für diese Modifizierung. Die Staatenlosigkeit und die Inlandsverarbeitung sind Souveränitätseigenschaften und befreien keine der Parteien vom Gesetz.