GKE-Hypercluster

Viele GKE-Kunden führen umfangreiche KI/ML-Arbeitslasten aus oder besitzen vertrauliches geistiges Eigentum wie proprietäre Modellgewichte. In diesem Dokument wird eine Infrastrukturarchitektur beschrieben, die Container auf Remote-Instanzen ausführt, die in mehreren Regionen ausgeführt werden können und von Knoten in Ihrem Cluster verwaltet werden. Diese verknüpfte Infrastruktur, einschließlich der verschiedenen Betriebssystem-Images und -Funktionen, wird als GKE Hypercluster bezeichnet.

GKE Hypercluster ist für Kunden gedacht, die mehr Sicherheit und Skalierbarkeit als mit GKE oder AI Hypercomputer benötigen und bereit sind, dafür mehr Betriebsaufwand in Kauf zu nehmen.

Wann sollte GKE Hypercluster verwendet werden?

Standardmäßig sind GKE-Cluster so konzipiert, dass sie die Anforderungen der meisten KI-Arbeitslasten in der Produktion erfüllen, einschließlich Arbeitslasten mit besonderen Sicherheits- und Skalierbarkeitsanforderungen. GKE unterstützt beispielsweise die folgenden Anwendungsfälle:

  • GPUs auf Confidential Google Kubernetes Engine-Knoten ausführen und von Ihren Arbeitslasten aus auf vTPMs oder hardwarebasierte Confidential Computing-Module zugreifen.
  • Mit Workload Identity Federation for GKE den Zugriff auf verschlüsselte Daten auf bestimmte autorisierte Identitäten beschränken.
  • TPU- und GPU-Knoten basierend auf der verfügbaren Kapazität mit ComputeClasses und der automatischen Erstellung von Knotenpools bereitstellen.
  • Jeden Zugriff durch Google-Mitarbeiter mit Access Approval, Access Transparency und der GKE-Steuerungsebene-Autorität steuern und beobachten.

Die verknüpfte Infrastruktur in GKE Hypercluster ist für bestimmte Sicherheits- und Skalierbarkeitsanwendungsfälle konzipiert, die Funktionen erfordern, die über die bestehenden Grenzen der typischen GKE-Architektur hinausgehen. Bestimmte GKE-Funktionen für Beobachtbarkeit und Fehlerbehebung sowie bestimmte Features sind für die verknüpfte Infrastruktur nicht verfügbar. Diese Infrastruktur ändert die typische GKE-Clusterarchitektur, um die folgenden speziellen Anwendungsfälle zu erfüllen:

  • Modelle und Abfragen vor Insider-Bedrohungen schützen: Zugriff auf proprietäre Modellgewichte oder vertrauliche Inferenzabfragen und -antworten durch Ihre eigenen Plattformadministratoren und Google-Mitarbeiter verhindern. KI-Assets werden nur in bestätigten und überprüfbaren Umgebungen entschlüsselt.

  • KI-Arbeitslasten regionsübergreifend ausführen: Arbeitslasten in einem Umfang bereitstellen, der über die unterstützten Limits für die Knotenskalierung hinausgeht. Beschleunigerinfrastruktur in jeder Region mit verfügbarer Kapazität erstellen und verwenden, auch an Standorten außerhalb der Clusterregion oder -zone.

Funktionsweise

Wie in der GKE-Clusterarchitektur beschrieben, hat ein Cluster im Standardmodus eine regionale oder zonale Steuerungsebene, die die Kubernetes API bereitstellt und alle Knoten und Knotenpools im Cluster verwaltet. Alle Knoten in einem Cluster verwenden ein bestimmtes VPC-Netzwerk, das auch von anderen Google Cloud Ressourcen verwendet werden kann. Auf jedem GKE-Knoten werden verschiedene Systemkomponenten ausgeführt, z. B. kubelet-Knoten-Agents, Logging- und Messwert-Agents sowie andere Kubernetes- und GKE-Komponenten.

Im Gegensatz dazu verwendet GKE Hypercluster Instanzen namens verknüpfte Runner, die nicht als Node-Objekte auf dem Kubernetes API-Server registriert sind. Diese Instanzen haben die folgenden Eigenschaften:

  • Keine Kubernetes-Agents und eine minimale Anzahl von GKE-Komponenten.
  • Spezielle Betriebssystem-Images basierend auf dem Anwendungsfall. Keine GKE-Knoten-Images.
  • Die Instanzen verwenden ein separates, dediziertes VPC-Netzwerk.

Die verknüpften Runner werden von Steuerungsknoten im Cluster verwaltet, die den Runner mit dem Cluster verknüpfen. Auf den Steuerungsknoten werden Systemkomponenten wie die kubelet-Prozesse ausgeführt. Ein einzelner Steuerungsknoten kann mit mehreren Runnern verknüpft werden. Diese verknüpften Runner sind für die Ausführung von Arbeitslasten in sehr großem Maßstab konzipiert, z. B. für einen Trainingsjob, der mehr Leistung erfordert, als das Rechenzentrum in Ihrer Clusterregion bereitstellen kann.

Bei der Infrastruktureinrichtung erstellen Sie Runner mit einer bestimmten Konfiguration basierend auf Ihrem Anwendungsfall und verknüpfen dann die Instanzen mit dedizierten Steuerungsknoten in Ihrem Cluster. Die Kubernetes API muss nur die Steuerungsknoten verwalten, da die verknüpften Runner-Instanzen kein kubelet haben und keinen API-Server-Traffic erzeugen. Wenn Sie Ihre verknüpften Runner-Instanzen erstellen, können Sie sie auf eine der folgenden Arten konfigurieren:

  • Standardkonfiguration: Standardmäßig sind die verknüpften Instanzen Compute Engine-VMs, auf denen ein Container-Optimized OS-Image ausgeführt wird. Plattformadministratoren und Notfallpersonal wie SREs können über SSH auf die Instanzen zugreifen. Diese Instanzen eignen sich gut, wenn Sie den Administratorzugriff auf die Infrastruktur beibehalten möchten.
  • Abgesicherte Konfiguration: Einige KI-Arbeitslasten verarbeiten vertrauliche Daten, wie proprietäre Modellgewichte und verschlüsselte Abfragen. Wenn Sie Ihre KI-Assets vor jeglichem Zugriff schützen müssen, auch vor dem Zugriff durch Google-Mitarbeiter und Ihre eigenen Administratoren, können Sie Ihre verknüpften Runner-Instanzen im abgesicherten Modus konfigurieren. Diese abgesicherten Instanzen haben die folgenden Eigenschaften:
    • Ein minimales Betriebssystem-Image verwenden.
    • Die Titanium Intelligence-Enklave für TPUs und NVIDIA Confidential Computing für GPUs verwenden.
    • Attestierung auf Arbeitslast- und Firmwareebene durchführen.
    • Signaturen von Container-Images validieren.
    • Jeglichen administrativen Zugriff auf Instanzen und Container verhindern.

Unabhängig von der verwendeten Konfiguration enthalten die Instanzen viele der Komponenten und Funktionen nicht, die in GKE-Knoten enthalten sind, z. B. GKE-spezifische TPU-Laufzeitparameter oder GKE-Logging- und Monitoring-Agents.

Standardkonfiguration

Standardmäßig sind die Instanzen, die Sie für GKE Hypercluster erstellen, für die Ausführung von Produktionsarbeitslasten konzipiert und bieten ähnliche Mechanismen wie typische GKE-Knoten für die Fehlerbehebung und Notfallreaktion. Die Instanzen werden auf Compute Engine-Maschinentypen ausgeführt und verwenden ein Container-Optimized OS-Image. Bei Vorfällen wie Ausfällen oder Abstürzen können Ihre Administratoren direkt auf die Instanzen zugreifen, um Probleme zu beheben. Im Gegensatz zu Kubernetes-Knoten werden auf den Instanzen viele der Systemkomponenten nicht ausgeführt, die Kubernetes- und GKE-Funktionen ermöglichen. Dadurch stehen auf jeder Instanz mehr zuweisbare Ressourcen zur Verfügung.

Sie können Instanzen in jeder Google Cloud Region erstellen und sie dann mit diesen Instanzen mit Steuerungsknoten in Ihrem Cluster verknüpfen. Die Steuerungsknoten übernehmen viele der Funktionen der Kubernetes-Steuerungsebene und verwalten den Lebenszyklus der bereitgestellten Arbeitslasten.

Abgesicherte Konfiguration

Wenn Ihr primärer Anwendungsfall darin besteht, Ihre Assets vor jeglichem Zugriff zu schützen, können Sie Ihre verknüpften Runner so konfigurieren, dass sie eine abgesicherte Konfiguration verwenden. Dadurch entstehen Instanzen mit den folgenden Sicherheitseigenschaften:

  • Jede Instanz ist eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE), die auf bestimmten Technologien basiert:
  • Auf den Instanzen wird ein minimales Betriebssystem-Image ausgeführt, das auf Container-Optimized OS basiert und den SSH-Zugriff deaktiviert, den Zugriff auf die Container-Shell verhindert und einen Attestierungs-Agent ausführt.
  • Sie definieren eine Richtlinie, in der genau festgelegt ist, welche Arbeitslasten auf den Instanzen ausgeführt werden können. Sie können beispielsweise festlegen, dass Arbeitslasten signierte Container-Image-Digests verwenden oder eine bestimmte Pod-Spezifikation haben müssen.
  • Ein Attestierungs-Agent sendet Firmware- und Arbeitslastmessungen an Google Cloud Attestation und gibt überprüfbare Attestierungsansprüche-Tokens zurück.

Die resultierenden Instanzen bieten eingeschränkte, validierte Umgebungen, in denen nur genehmigter Code ausgeführt werden kann und vertrauliche Daten in hardwarebasierten sicheren Enklaven verarbeitet werden. Die von den Instanzen zurückgegebenen Attestierungsinformationen bestätigen, dass auf den Arbeitslasten genehmigter Code ausgeführt wird und sie auf den richtigen Instanzen bereitgestellt werden.

Sie können diese abgesicherten Instanzen verwenden, um Ihre verschlüsselten Modelle, Abfragen und Antworten auf folgende Weise zu schützen:

  • Modellgewichte:

    1. Modellgewichte mit einem Cloud HSM-Schlüssel in Cloud KMS verschlüsseln.
    2. Verschlüsselte Modellgewichte in Cloud Storage speichern.
    3. Nur bestätigten Arbeitslasten Lesezugriff auf den Bucket gewähren.
    4. Nur bestätigten Arbeitslasten Zugriff auf den Entschlüsselungsschlüssel gewähren.

  • Abfragen und Antworten:

    1. Abfragen und Antworten mit einem Cloud HSM-Schlüssel in Cloud KMS verschlüsseln.
    2. Nur bestätigten Arbeitslasten Zugriff auf die Entschlüsselung gewähren.
    3. Beim Senden verschlüsselter Daten zwischen Arbeitslasten einen Attestierungsnachweis anfordern.

Die abgesicherte Konfiguration ist eine optionale Sicherheitsebene für Ihre verknüpften Runner-Instanzen. Ähnlich wie bei der Standardkonfiguration können Sie die abgesicherten Instanzen in jeder Region und Zone erstellen. Aufgrund der Sicherheitseigenschaften der abgesicherten Instanzen können Administratoren und Google-Mitarbeiter jedoch nicht auf Hostinstanzen zugreifen, um Fehler zu beheben.

Voraussetzungen

GKE Hypercluster ist für bestimmte KI/ML-Anwendungsfälle konzipiert, die mit der typischen GKE-Clusterarchitektur und den typischen GKE-Funktionen nicht erfüllt werden können. Kunden, die GKE Hypercluster verwenden, haben ungewöhnliche Sicherheits- und Skalierbarkeitsanforderungen. GKE Hypercluster ist nur für berechtigte GKE-Kunden verfügbar. Wenden Sie sich an Ihr Account-Management-Team, um zu prüfen, ob Sie berechtigt sind, und um Zugriff zu beantragen.