Molti clienti GKE eseguono carichi di lavoro di AI/ML su larga scala o possiedono proprietà intellettuale (IP) 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 in 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 ComputeClass 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 altre funzionalità di GKE non sono disponibili per l'infrastruttura collegata. Questa infrastruttura modifica la tipica architettura dei cluster GKE per soddisfare i seguenti casi d'uso specializzati:
Proteggi i modelli e le query dalle minacce interne: impedisci l'accesso ai pesi dei modelli proprietari o alle query e alle risposte di inferenza sensibili da parte degli amministratori della tua piattaforma e del 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 va oltre i limiti di scalabilità dei nodi supportati. Crea e utilizza l'infrastruttura dell'acceleratore in qualsiasi regione con capacità disponibile, incluse le posizioni 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 control plane regionale o di zona che gestisce l'API Kubernetes e tutti i nodi e i node pool del 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 agenti dei nodi kubelet, agenti di logging e 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 i 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 workload di AI elaborano dati sensibili, come i pesi dei modelli proprietari e le query criptate. Nelle situazioni in cui
devi proteggere le tue risorse 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 bloccate hanno le seguenti proprietà:
- Utilizza un'immagine sistema operativo minima.
- 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 di GKE.
Informazioni sulla configurazione predefinita
Per impostazione predefinita, le istanze che crei per GKE Hypercluster sono progettate per l'esecuzione di workload di produzione, fornendo al contempo meccanismi simili ai 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 sistema operativo 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 eseguono molte delle funzioni del control plane di 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 tutti gli accessi, puoi configurare i runner collegati in modo che utilizzino una configurazione sigillata, che genera istanze con le seguenti proprietà di sicurezza:
- Ogni istanza è un Trusted Execution Environment (TEE) basato su tecnologie specifiche:
- Le TPU utilizzano l'enclave Titanium Intelligence, che fa parte della piattaforma Private AI Compute.
- Le GPU utilizzano NVIDIA Confidential Computing per proteggere i dati mentre sono in uso.
- Le istanze eseguono un'immagine sistema operativo minima, 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 workload possono essere eseguiti sulle istanze. Ad esempio, puoi richiedere che i workload utilizzino digest di immagini container firmati o che abbiano una specifica Pod specifica.
- Un agente di attestazione invia le misurazioni del firmware e dei workload a Google Cloud Attestation e restituisce i token dei risultati delle attestazioni verificabili.
Le istanze risultanti forniscono ambienti con restrizioni e convalidati in cui può essere eseguito solo il codice approvato e i dati sensibili vengono elaborati in enclave sicure basate su hardware. Le informazioni di attestazione restituite dalle istanze verificano che i workload eseguano il codice approvato e siano di cui è stato eseguito il deployment nelle istanze corrette.
Puoi utilizzare queste istanze sealed per proteggere i modelli, le query e le risposte criptati nei seguenti modi:
Pesi del modello:
- Cripta i pesi del modello utilizzando una chiave Cloud HSM in Cloud KMS.
- Archivia i pesi del modello criptati in Cloud Storage.
- Concedi l'accesso in lettura al bucket solo ai carichi di lavoro attestati.
- Concedi l'accesso alla chiave di decrittografia solo ai workload attestati.
Query e risposte:
- Cripta query e risposte utilizzando una chiave Cloud HSM in Cloud KMS.
- Concedi l'accesso alla decriptografia solo ai carichi di lavoro attestati.
- 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 sealed 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 di AI/ML specifici che non possono essere soddisfatti dall'architettura e dalle funzionalità tipiche dei 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 la tua idoneità e richiedere l'accesso, contatta il team dedicato all'account.