À propos de GKE Hypercluster

De nombreux clients GKE exécutent des charges de travail d'IA/de ML à grande échelle ou possèdent une propriété intellectuelle (PI) sensible, comme des pondérations de modèles propriétaires. Ce document décrit une architecture d'infrastructure qui exécute des conteneurs sur des instances distantes pouvant s'exécuter dans plusieurs régions et gérées par des nœuds de votre cluster. Cette infrastructure associée, y compris les différentes images et fonctionnalités du système d'exploitation (OS), est appelée GKE Hypercluster.

GKE Hypercluster s'adresse aux clients qui souhaitent bénéficier d'une sécurité et d'une évolutivité supérieures aux limites de GKE ou d'AI Hypercomputer, et qui sont prêts à accepter une friction opérationnelle accrue pour atteindre ces objectifs.

Quand utiliser GKE Hypercluster

Par défaut, les clusters GKE sont conçus pour répondre aux exigences de la plupart des charges de travail d'IA de production, y compris celles qui ont des exigences particulières en termes de sécurité et d'évolutivité. Par exemple, GKE est compatible avec les cas d'utilisation suivants :

  • Exécutez des GPU sur des nœuds Confidential Google Kubernetes Engine et accédez aux modules d'informatique confidentielle basés sur du matériel ou aux vTPM depuis vos charges de travail.
  • Utilisez Workload Identity Federation for GKE afin de limiter l'accès aux données chiffrées à des identités autorisées spécifiques.
  • Déployez des nœuds TPU et GPU en fonction de la capacité disponible à l'aide de ComputeClasses et de la création automatique de pools de nœuds.
  • Contrôlez et observez tout accès par le personnel Google à l'aide d'Access Approval, Access Transparency et GKE control plane authority.

L'infrastructure associée dans GKE Hypercluster est conçue pour des cas d'utilisation spécifiques en termes de sécurité et d'évolutivité qui nécessitent des capacités allant au-delà des limites existantes de l'architecture GKE typique. Par conception, certaines fonctionnalités, capacités de dépannage et d'observabilité de GKE ne sont pas disponibles pour l'infrastructure associée. Cette infrastructure modifie l'architecture de cluster GKE typique pour répondre aux cas d'utilisation spécialisés suivants :

  • Protéger les modèles et les requêtes contre les menaces internes : empêchez vos administrateurs de plate-forme et le personnel Google d'accéder aux pondérations de modèles propriétaires ou aux requêtes et réponses d'inférence sensibles. Les composants d'IA ne sont déchiffrés que dans des environnements attestés et vérifiables.

  • Exécuter des charges de travail d'IA dans plusieurs régions : déployez des charges de travail à une échelle qui dépasse les limites de scaling des nœuds compatibles. Créez et utilisez une infrastructure d'accélérateurs dans n'importe quelle région disposant de capacité disponible, y compris dans des zones ou régions autres que celles du cluster.

Fonctionnement

Comme décrit dans l'architecture des clusters GKE, un cluster en mode Standard dispose d'un plan de contrôle régional ou zonal qui dessert l'API Kubernetes et gère tous les nœuds et pools de nœuds du cluster. Tous les nœuds d'un cluster utilisent un réseau VPC spécifique, qui peut également être utilisé par d'autres ressources Google Cloud . Chaque nœud GKE exécute différents composants système tels que les agents de nœud kubelet, les agents de journalisation et de métriques, ainsi que d'autres composants Kubernetes et GKE.

En revanche, GKE Hypercluster utilise des instances appelées runners associés qui ne sont pas enregistrées en tant qu'objets Node dans le serveur d'API Kubernetes. Ces instances présentent les propriétés suivantes :

  • Aucun agent Kubernetes et un ensemble minimal de composants GKE.
  • Images d'OS spécialisées en fonction du cas d'utilisation. Aucune image de nœud GKE.
  • Les instances utilisent un réseau VPC distinct et dédié.

Les runners associés sont gérés par des nœuds de contrôle dans le cluster qui associent le runner au cluster. Les nœuds de contrôle exécutent des composants système tels que les processus kubelet. Un même nœud de contrôle peut être associé à plusieurs exécuteurs. Ces exécuteurs associés sont conçus pour exécuter des charges de travail à très grande échelle, comme une tâche d'entraînement qui nécessite plus de puissance que ce que le centre de données de la région de votre cluster peut fournir.

Lors de la configuration de l'infrastructure, vous créez des runners avec une configuration spécifique en fonction de votre cas d'utilisation, puis vous associez les instances à des nœuds de contrôle dédiés dans votre cluster. L'API Kubernetes n'a besoin de gérer que les nœuds de contrôle, car les instances de runner associées ne disposent pas de kubelet et ne génèrent pas de trafic de serveur d'API. Lorsque vous créez vos instances de runner associées, vous pouvez les configurer de l'une des manières suivantes :

  • Configuration par défaut : par défaut, les instances associées sont des VM Compute Engine qui exécutent une image Container-Optimized OS. Les administrateurs de plate-forme et le personnel d'urgence, comme les ingénieurs en fiabilité des sites, peuvent accéder aux instances à l'aide de SSH. Ces instances sont idéales lorsque vous souhaitez conserver un accès administrateur à l'infrastructure.
  • Configuration scellée : certaines charges de travail d'IA traitent des données sensibles, telles que des pondérations de modèles propriétaires et des requêtes chiffrées. Dans les situations où vous devez protéger vos composants d'IA contre tout accès, y compris celui du personnel Google et de vos propres administrateurs, vous pouvez configurer vos instances de runner associées en mode scellé. Ces instances scellées présentent les propriétés suivantes :
    • Utilisez une image OS minimale.
    • Utilisez l'enclave Titanium Intelligence pour les TPU et NVIDIA Confidential Computing pour les GPU.
    • Effectuez l'attestation au niveau de la charge de travail et du micrologiciel.
    • Valider les signatures des images de conteneurs.
    • Empêchez tout accès administratif aux instances et aux conteneurs.

Quelle que soit la configuration que vous utilisez, les instances n'incluent pas la plupart des composants et fonctionnalités inclus dans les nœuds GKE, tels que les paramètres d'exécution TPU spécifiques à GKE ou les agents de journalisation et de surveillance GKE.

À propos de la configuration par défaut

Par défaut, les instances que vous créez pour GKE Hypercluster sont conçues pour exécuter des charges de travail de production tout en fournissant des mécanismes similaires à ceux des nœuds GKE classiques à des fins de dépannage et d'intervention d'urgence. Les instances s'exécutent sur des types de machines Compute Engine et utilisent une image Container-Optimized OS. En cas d'incidents tels que des perturbations ou des plantages, vos administrateurs peuvent accéder directement aux instances pour résoudre les problèmes. Contrairement aux nœuds Kubernetes, les instances n'exécutent pas la plupart des composants système qui activent les fonctionnalités Kubernetes et GKE, ce qui se traduit par davantage de ressources allouables sur chaque instance.

Vous pouvez créer des instances dans n'importe quelle région Google Cloud , puis les associer à des nœuds de contrôle de votre cluster. Les nœuds de contrôle exécutent de nombreuses fonctions du plan de contrôle Kubernetes, en gérant le cycle de vie des charges de travail déployées.

À propos de la configuration scellée

Si votre cas d'utilisation principal consiste à protéger vos composants contre tout accès, vous pouvez configurer vos runners associés pour qu'ils utilisent une configuration scellée. Les instances obtenues présentent alors les propriétés de sécurité suivantes :

  • Chaque instance est un environnement d'exécution sécurisé (TEE) basé sur des technologies spécifiques :
  • Les instances exécutent une image d'OS minimaliste, basée sur Container-Optimized OS, qui désactive l'accès SSH, empêche l'accès au shell du conteneur et exécute un agent d'attestation.
  • Vous définissez une règle qui spécifie exactement les charges de travail pouvant s'exécuter sur les instances. Par exemple, vous pouvez exiger que les charges de travail utilisent des résumés d'images de conteneurs signés ou qu'elles disposent d'une spécification de pod spécifique.
  • Un agent d'attestation envoie des mesures de micrologiciel et de charge de travail à Google Cloud Attestation et renvoie des jetons de résultats de revendications d'attestation vérifiables.

Les instances qui en résultent fournissent des environnements restreints et validés dans lesquels seul le code approuvé peut s'exécuter et les données sensibles sont traitées dans des enclaves sécurisées basées sur le matériel. Les informations d'attestation renvoyées par les instances permettent de vérifier que les charges de travail exécutent du code approuvé et sont déployées sur les instances appropriées.

Vous pouvez utiliser ces instances scellées pour protéger vos modèles, requêtes et réponses chiffrés de différentes manières :

  • Pondérations du modèle :

    1. Chiffrez les pondérations du modèle à l'aide d'une clé Cloud HSM dans Cloud KMS.
    2. Stockez les pondérations de modèle chiffrées dans Cloud Storage.
    3. N'accordez l'accès en lecture au bucket qu'aux charges de travail attestées.
    4. N'accordez l'accès à la clé de déchiffrement qu'aux charges de travail attestées.

  • Requêtes et réponses :

    1. Chiffrez les requêtes et les réponses à l'aide d'une clé Cloud HSM dans Cloud KMS.
    2. N'accordez l'accès au déchiffrement qu'aux charges de travail attestées.
    3. Exigez une preuve d'attestation lorsque vous envoyez des données chiffrées entre des charges de travail.

La configuration scellée est une couche de sécurité facultative pour vos instances de runner associées. Comme pour la configuration par défaut, vous pouvez créer les instances scellées dans n'importe quelle région et zone. Toutefois, les propriétés de sécurité des instances scellées signifient que les administrateurs et le personnel Google ne peuvent pas accéder aux instances hôtes pour résoudre les problèmes.

Critères d'éligibilité

GKE Hypercluster est conçu pour des cas d'utilisation spécifiques de l'IA/du ML qui ne peuvent pas être satisfaits par l'architecture et les fonctionnalités de cluster GKE classiques. Les clients qui utilisent GKE Hypercluster ont des exigences de sécurité et d'évolutivité atypiques. Les hyperclusters GKE ne sont disponibles que pour les clients GKE éligibles. Pour vérifier si vous êtes éligible et demander l'accès, contactez l'équipe chargée de votre compte.