Informazioni su GKE Hypercluster

Molti clienti GKE eseguono carichi di lavoro di AI/ML su larga scala o possiedono proprietà intellettuale (PI) sensibile, come i pesi dei modelli proprietari. Questo documento descrive un'architettura dell'infrastruttura che esegue container su istanze remote che possono essere eseguite in più regioni e sono gestite dai nodi del cluster. Questa infrastruttura collegata, incluse le varie immagini e funzionalità del sistema operativo (OS), è denominata GKE Hypercluster.

GKE Hypercluster è destinato ai clienti che desiderano sicurezza e scalabilità oltre i limiti di GKE o AI Hypercomputer e sono disposti ad accettare un maggiore attrito operativo per raggiungere questi obiettivi.

Quando utilizzare GKE Hypercluster

Per impostazione predefinita, i cluster GKE sono progettati per soddisfare i requisiti della maggior parte dei workload di AI di produzione, inclusi quelli con requisiti speciali di sicurezza e scalabilità. Ad esempio, GKE supporta casi d'uso come i seguenti:

  • Esegui GPU su nodi Confidential Google Kubernetes Engine e accedi a vTPM o a moduli Confidential Computing basati su hardware dai tuoi carichi di lavoro.
  • Utilizza Workload Identity Federation for GKE per limitare l'accesso ai dati criptati a identità autorizzate specifiche.
  • Esegui il deployment di nodi TPU e GPU in base alla capacità disponibile utilizzando ComputeClasses e la creazione automatica del pool di nodi.
  • Controlla e osserva qualsiasi accesso da parte del personale Google utilizzando Approvazione accesso, Access Transparency e GKE control plane authority.

L'infrastruttura collegata in GKE Hypercluster è progettata per casi d'uso specifici di sicurezza e scalabilità che richiedono funzionalità che vanno oltre i limiti esistenti della tipica architettura GKE. Per progettazione, alcune funzionalità di osservabilità, risoluzione dei problemi e funzionalità di GKE non sono disponibili per l'infrastruttura collegata. Questa infrastruttura modifica la tipica architettura del cluster GKE per soddisfare i seguenti casi d'uso specializzati:

  • Proteggi modelli e query da minacce interne: impedisci l'accesso a pesi del modello proprietari o a query e risposte di inferenza sensibili da parte di amministratori della piattaforma e personale di Google. Gli asset AI vengono decriptati solo in ambienti attestati e verificabili.

  • Esegui workload AI in più regioni: esegui il deployment dei workload su una scala che supera i limiti di scalabilità dei nodi supportati. Crea e utilizza l'infrastruttura dell'acceleratore in qualsiasi regione con capacità disponibile, incluse le località al di fuori della regione o della zona del cluster.

Come funziona

Come descritto in Architettura del cluster GKE, un cluster in modalità Standard ha un piano di controllo regionale o di zona che gestisce l'API Kubernetes e tutti i nodi e i pool di nodi nel cluster. Tutti i nodi di un cluster utilizzano una rete VPC specifica, che potrebbe essere utilizzata anche da altre risorse Google Cloud . Ogni nodo GKE esegue vari componenti di sistema, come gli agenti dei nodi kubelet, gli agenti di logging e delle metriche e altri componenti Kubernetes e GKE.

Al contrario, GKE Hypercluster utilizza istanze denominate runner collegati che non sono registrate come oggetti Node nel server API Kubernetes. Queste istanze hanno le seguenti proprietà:

  • Nessun agente Kubernetes e un insieme minimo di componenti GKE.
  • Immagini del sistema operativo specializzate in base al caso d'uso. Nessuna immagine dei nodi GKE.
  • Le istanze utilizzano una rete VPC dedicata separata.

I runner collegati sono gestiti dai nodi di controllo nel cluster che collegano il runner al cluster. I nodi di controllo eseguono componenti di sistema come i processi kubelet. Un singolo nodo di controllo può essere collegato a più runner. Questi runner collegati sono progettati per eseguire carichi di lavoro su larga scala, ad esempio un job di addestramento che richiede più potenza di quella che può fornire il data center nella regione del cluster.

Durante la configurazione dell'infrastruttura, crei runner con una configurazione specifica in base al tuo caso d'uso, quindi colleghi le istanze ai nodi di controllo dedicati nel cluster. L'API Kubernetes deve gestire solo i nodi di controllo, perché le istanze runner collegate non hanno un kubelet e non generano traffico del server API. Quando crei le istanze runner collegate, puoi configurarle in uno dei seguenti modi:

  • Configurazione predefinita: per impostazione predefinita, le istanze collegate sono VM Compute Engine che eseguono un'immagine Container-Optimized OS. Gli amministratori della piattaforma e il personale di emergenza come gli SRE possono accedere alle istanze utilizzando SSH. Queste istanze sono ideali quando vuoi mantenere l'accesso amministratore all'infrastruttura.
  • Configurazione sigillata: alcuni carichi di lavoro AI elaborano dati sensibili, come pesi del modello proprietari e query criptate. Nelle situazioni in cui devi proteggere i tuoi asset AI da qualsiasi accesso, incluso quello del personale di Google e dei tuoi amministratori, puoi configurare le istanze del runner collegato in modalità sigillata. Queste istanze sigillate hanno le seguenti proprietà:
    • Utilizza un'immagine sistema operativo minimale.
    • Utilizza l'enclave Titanium Intelligence per le TPU e NVIDIA Confidential Computing per le GPU.
    • Esegui l'attestazione a livello di workload e firmware.
    • Convalida le firme delle immagini container.
    • Impedisci l'accesso amministrativo a istanze e container.

Indipendentemente dalla configurazione che utilizzi, le istanze non includono molti dei componenti e delle funzionalità inclusi nei nodi GKE, come i parametri di runtime TPU specifici di GKE o gli agenti di logging e monitoraggio GKE.

Informazioni sulla configurazione predefinita

Per impostazione predefinita, le istanze create per GKE Hypercluster sono progettate per l'esecuzione di carichi di lavoro di produzione e forniscono meccanismi simili a quelli dei tipici nodi GKE per la risoluzione dei problemi e la risposta alle emergenze. Le istanze vengono eseguite su tipi di macchine Compute Engine e utilizzano un'immagine di Container-Optimized OS. Durante incidenti come interruzioni o arresti anomali, gli amministratori possono accedere direttamente alle istanze per risolvere i problemi. A differenza dei nodi Kubernetes, le istanze non eseguono molti dei componenti di sistema che abilitano le funzionalità di Kubernetes e GKE, il che si traduce in un maggior numero di risorse allocabili su ogni istanza.

Puoi creare istanze in qualsiasi regione Google Cloud e poi collegarle ai nodi di controllo del cluster. I nodi di controllo svolgono molte delle funzioni del control plane Kubernetes, gestendo il ciclo di vita dei workload di cui è stato eseguito il deployment.

Informazioni sulla configurazione sigillata

Se il tuo caso d'uso principale è proteggere i tuoi asset da qualsiasi accesso, puoi configurare i runner collegati in modo che utilizzino una configurazione sigillata, il che comporta istanze con le seguenti proprietà di sicurezza:

  • Ogni istanza è un Trusted Execution Environment (TEE) basato su tecnologie specifiche:
  • Le istanze eseguono un'immagine del sistema operativo minimale, basata su Container-Optimized OS, che disabilita l'accesso SSH, impedisce l'accesso alla shell del container ed esegue un agente di attestazione.
  • Definisci una policy che specifica esattamente quali carichi di lavoro possono essere eseguiti sulle istanze. Ad esempio, puoi richiedere che i workload utilizzino i digest delle immagini container firmate o che abbiano una specifica Pod.
  • Un agente di attestazione invia le misurazioni del firmware e del workload ad Google Cloud Attestation e restituisce token di risultati di attestazione verificabili.

Le istanze risultanti forniscono ambienti con restrizioni e convalidati in cui possono essere eseguiti solo codici approvati e i dati sensibili vengono elaborati in enclave sicure basate su hardware. Le informazioni di attestazione restituite dalle istanze verificano che i workload eseguano codice approvato e vengano implementati sulle istanze corrette.

Puoi utilizzare queste istanze sigillate per proteggere i tuoi modelli, query e risposte criptati nei seguenti modi:

  • Pesi del modello:

    1. Cripta i pesi del modello utilizzando una chiave Cloud HSM in Cloud KMS.
    2. Archivia i pesi del modello criptati in Cloud Storage.
    3. Concedi l'accesso in lettura al bucket solo ai workload attestati.
    4. Concedi l'accesso alla chiave di decrittografia solo ai workload attestati.

  • Query e risposte:

    1. Cripta query e risposte utilizzando una chiave Cloud HSM in Cloud KMS.
    2. Concedi l'accesso alla decriptografia solo ai carichi di lavoro attestati.
    3. Richiedi la prova dell'attestazione quando invii dati criptati tra i carichi di lavoro.

La configurazione sigillata è un livello di sicurezza facoltativo per le istanze runner collegate. Analogamente alla configurazione predefinita, puoi creare le istanze sigillate in qualsiasi regione e zona. Tuttavia, le proprietà di sicurezza delle istanze sigillate impediscono agli amministratori e al personale di Google di accedere alle istanze host per la risoluzione dei problemi.

Idoneità

GKE Hypercluster è progettato per casi d'uso specifici di AI/ML che non possono essere soddisfatti dalla tipica architettura e dalle funzionalità del cluster GKE. I clienti che utilizzano GKE Hypercluster hanno requisiti di sicurezza e scalabilità atipici. GKE Hypercluster è disponibile solo per i clienti GKE idonei. Per verificare se hai l'idoneità e per richiedere l'accesso, contatta il team dedicato al tuo account.