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, in der Container auf Remote-Instanzen ausgeführt werden, 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 bei GKE oder AI Hypercomputer benötigen und bereit sind, dafür einen erhöhten Betriebsaufwand in Kauf zu nehmen.

Wann sollte GKE Hypercluster verwendet werden?

GKE-Cluster sind standardmäßig so konzipiert, dass sie die Anforderungen der meisten KI-Produktionsarbeitslasten 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 können Sie den Zugriff auf verschlüsselte Daten auf bestimmte autorisierte Identitäten beschränken.
  • TPU- und GPU-Knoten basierend auf der verfügbaren Kapazität bereitstellen, indem Sie Compute-Klassen und die automatische Erstellung von Knotenpools verwenden.
  • Mit Zugriffsgenehmigung, Access Transparency und GKE Control Plane Authority können Sie den Zugriff von Google-Mitarbeitern 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 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 Anfragen vor Insider-Bedrohungen schützen: Verhindern Sie den Zugriff auf proprietäre Modellgewichte oder sensible Inferenzanfragen und ‑antworten durch Ihre eigenen Plattformadministratoren und Google-Mitarbeiter. KI-Assets werden nur in bestätigten und überprüfbaren Umgebungen entschlüsselt.

  • KI-Arbeitslasten regionsübergreifend ausführen: Stellen Sie Arbeitslasten in einem Umfang bereit, der über die unterstützten Knoten-Skalierungslimits hinausgeht. Sie können Beschleunigerinfrastruktur in jeder Region mit verfügbarer Kapazität erstellen und verwenden, auch an Standorten außerhalb der Clusterregion oder ‑zone.

Funktionsweise

Wie in 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 möglicherweise auch von anderen Google Cloud Ressourcen verwendet wird. 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 werden in GKE-Hyperclustern Instanzen namens linked runners verwendet, die nicht als Node-Objekte im Kubernetes-API-Server registriert sind. Diese Instanzen haben die folgenden Eigenschaften:

  • Keine Kubernetes-Agents und eine minimale Anzahl von GKE-Komponenten.
  • Spezialisierte Betriebssystemimages 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 Steuerknoten werden Systemkomponenten wie die kubelet-Prozesse ausgeführt. Ein einzelner Steuerknoten 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.

Während der Einrichtung der Infrastruktur erstellen Sie Runner mit einer bestimmten Konfiguration basierend auf Ihrem Anwendungsfall und verknüpfen die Instanzen dann mit dedizierten Steuerungsknoten in Ihrem Cluster. Die Kubernetes API muss nur die Steuerungsknoten verwalten, da die verknüpften Runner-Instanzen keine kubelet haben und keinen API-Server-Traffic generieren. Wenn Sie die 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 Administratorzugriff auf die Infrastruktur behalten möchten.
  • Abgeschottete Konfiguration: Bei einigen KI-Arbeitslasten werden sensible Daten verarbeitet, z. B. proprietäre Modellgewichte und verschlüsselte Anfragen. 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 abgeschlossenen Modus konfigurieren. Diese versiegelten Instanzen haben die folgenden Eigenschaften:
    • Verwenden Sie ein minimales Betriebssystemimage.
    • Verwenden Sie die Titanium Intelligence-Enclave für TPUs und NVIDIA Confidential Computing für GPUs.
    • Arbeitslast- und Firmware-Attestierung durchführen.
    • Container-Image-Signaturen validieren.
    • Verhindern Sie jeglichen administrativen Zugriff auf Instanzen und Container.

Unabhängig von der verwendeten Konfiguration enthalten die Instanzen viele der Komponenten und Funktionen, die in GKE-Knoten enthalten sind, nicht, 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 Notfallmaßnahmen. Die Instanzen werden auf Compute Engine-Maschinentypen ausgeführt und verwenden ein Container-Optimized OS-Image. Bei Vorfällen wie Unterbrechungen 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 nicht viele der Systemkomponenten ausgeführt, die Kubernetes- und GKE-Funktionen ermöglichen. Dadurch sind auf jeder Instanz mehr zuweisbare Ressourcen verfügbar.

Sie können Instanzen in einer beliebigen Google Cloud Region erstellen und diese Instanzen dann mit den Steuerknoten in Ihrem Cluster verknüpfen. Die Kontrollknoten führen viele der Funktionen der Kubernetes-Steuerungsebene aus und verwalten den Lebenszyklus der bereitgestellten Arbeitslasten.

Versiegelte 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 versiegelte Konfiguration verwenden. Dies führt zu 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. Es deaktiviert den SSH-Zugriff, verhindert den Zugriff auf die Container-Shell und führt einen Attestierungs-Agent aus.
  • 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 für Arbeitslasten signierte Container-Image-Digests oder eine bestimmte Pod-Spezifikation erforderlich sind.
  • Ein Attestierungs-Agent sendet Firmware- und Arbeitslastmessungen an Google Cloud Attestation und gibt überprüfbare Attestierungsansprüche als Ergebnis-Tokens zurück.

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

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

  • Modellgewichtungen:

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

  • Anfragen und Antworten:

    1. Anfragen und Antworten mit einem Cloud HSM-Schlüssel in Cloud KMS verschlüsseln
    2. Entschlüsselungszugriff nur für bestätigte Arbeitslasten gewähren.
    3. Nachweis der Attestierung beim Senden verschlüsselter Daten zwischen Arbeitslasten erforderlich machen.

Die versiegelte Konfiguration ist eine optionale Sicherheitsebene für Ihre verknüpften Runner-Instanzen. Ähnlich wie bei der Standardkonfiguration können Sie die versiegelten Instanzen in jeder Region und Zone erstellen. Aufgrund der Sicherheitseigenschaften der versiegelten 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-Clusterfunktionen nicht abgedeckt werden können. Kunden, die GKE Hypercluster verwenden, haben atypische 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 die Voraussetzungen erfüllen und Zugriff beantragen können.