GKE-Hypercluster

Viele GKE-Kunden führen umfangreiche KI-/ML-Arbeitslasten aus oder besitzen vertrauliches geistiges Eigentum (IP) wie proprietäre Modellgewichtungen. In diesem Dokument wird eine Infrastrukturarchitektur beschrieben, bei 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 Sicherheit und Skalierbarkeit über die Grenzen von GKE oder AI Hypercomputer hinaus 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-Hyperclustern ist für bestimmte Sicherheits- und Skalierbarkeitsanwendungsfälle konzipiert, die Funktionen erfordern, die über die bestehenden Grenzen der typischen GKE-Architektur hinausgehen. Bestimmte GKE-Beobachtbarkeits- und Fehlerbehebungsfunktionen 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 vertrauliche 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 die unterstützten Limits für die Knotenskalierung überschreitet. Sie können die 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 mit dem Namen 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 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 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 Infrastruktureinrichtung erstellen Sie Runner mit einer bestimmten Konfiguration, die auf Ihrem Anwendungsfall basiert, 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 keinen kubelet haben und keinen API-Server-Traffic generieren. Wenn Sie Ihre verknüpften Runner-Instanzen erstellen, können Sie die Instanzen 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.
  • 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 abgeschirmten Modus konfigurieren. Diese versiegelten Instanzen haben die folgenden Eigenschaften:
    • Verwenden Sie ein minimales Betriebssystem-Image.
    • 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 Administratorzugriff 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.

Informationen zur Standardkonfiguration

Standardmäßig sind die Instanzen, die Sie für GKE Hypercluster erstellen, für die Ausführung von Produktionsarbeitslasten konzipiert. Sie 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-Betriebssystem-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 viele der Systemkomponenten, die Kubernetes- und GKE-Features ermöglichen, nicht ausgeführt. 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 Steuerungsknoten 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 Container-Shell-Zugriff und führt einen Attestierungs-Agent aus.
  • Sie definieren eine Richtlinie, die genau festlegt, 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 Attestierungsanspruchsergebnis-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 Enclaves 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 attestierten 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 anfordern.

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

Der GKE-Hypercluster ist für bestimmte KI/ML-Anwendungsfälle konzipiert, die mit der typischen GKE-Clusterarchitektur und den entsprechenden Funktionen 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 um Zugriff anzufordern.