Cette page décrit les classes de calcul que vous pouvez utiliser pour exécuter des charges de travail Google Kubernetes Engine (GKE) Autopilot avec des exigences matérielles spécifiques. Pour obtenir des instructions, reportez-vous à la section Exécuter des pods Autopod sur des classes de calcul spécifiques.
Présentation des classes de calcul Autopilot
Par défaut, les pods GKE Autopilot s'exécutent sur une plate-forme de calcul optimisée pour les charges de travail à usage général, telles que la diffusion Web et les tâches par lot à intensité moyenne. Cette plate-forme générale fournit une configuration matérielle fiable et économique capable de gérer les exigences de la plupart des charges de travail.
Si vous avez des charges de travail ayant des exigences matérielles spécifiques, telles que l'exécution de tâches de machine learning ou d'IA, l'exécution de bases de données à trafic élevé en temps réel, ou si vous avez besoin de plates-formes de processeur et d'architectures spécifiques, Autopilot propose des classes de calcul. Ces classes de calcul sont un sous-ensemble organisé de la série de machines Compute Engine. Elles offrent plus de flexibilité que la classe de calcul Autopilot par défaut. Par exemple, la classe de calcul Scale-Out utilise des VM qui désactivent le traitement multithread simultané et sont optimisées pour le scaling horizontal.
Vous pouvez demander des nœuds sauvegardés par des classes de calcul spécifiques en fonction des exigences de chacune de vos charges de travail. Semblable à la classe de calcul à usage général par défaut, Autopilot gère le dimensionnement et l'allocation des ressources des classes de calcul demandées en fonction de vos pods en cours d'exécution. Vous pouvez demander des classes de calcul au niveau du pod pour optimiser la rentabilité en choisissant la solution la mieux adaptée aux besoins de chaque pod.
Choisir une architecture de processeur spécifique
Si vos charges de travail sont conçues pour des plates-formes ou des architectures de processeur spécifiques, vous pouvez éventuellement sélectionner ces plates-formes ou architectures dans les spécifications de votre pod. Par exemple, si vous souhaitez que vos pods s'exécutent sur des nœuds utilisant l'architecture Arm, vous pouvez choisir arm64 dans la classe de calcul Scale-Out.
Tarifs
Les pods GKE Autopilot sont facturés en fonction des nœuds sur lesquels les pods sont programmés. Pour obtenir des informations sur les tarifs des charges de travail générales et des pods Spot sur des classes de calcul spécifiques, ainsi que sur les remises sur engagement d'utilisation, consultez la page Tarifs du mode Autopilot.
Les pods spot sur les classes de calcul à usage général ou spécialisées ne sont pas éligibles aux remises sur engagement d'utilisation.
Quand utiliser des classes de calcul spécifiques ?
Le tableau suivant fournit une présentation technique des classes de calcul compatibles avec Autopilot et des exemples de cas d'utilisation pour les pods exécutés sur chaque plate-forme. Si vous ne demandez pas de classe de calcul, Autopilot place vos pods sur la plate-forme de calcul à usage général, qui est conçue pour exécuter la plupart des charges de travail de manière optimale.
| Exigence de charge de travail | Classe de calcul | Description | Exemples de cas d'utilisation |
|---|---|---|---|
| Charges de travail ne nécessitant pas de matériel spécifique | Usage général |
Autopilot utilise la plate-forme de calcul à usage général si vous ne demandez pas explicitement une classe de calcul dans la spécification de votre pod. Vous ne pouvez pas sélectionner explicitement la plate-forme à usage général dans votre spécification. S'appuie sur la série de machines E2. |
|
| Charges de travail nécessitant des GPU | Accelerator |
Les types de GPU compatibles sont les suivants :
|
|
| Demandes de mémoire ou de processeur dépassant les limites maximales de la classe de calcul à usage général ou des plates-formes de processeur spécifiques | Balanced |
S'appuie sur la série de machines N2 (Intel) ou la série de machines N2D (AMD). |
|
| Charges de travail nécessitant une utilisation intensive des processeurs, telles que l'entraînement AI/ML ou le calcul hautes performances (HPC) | Performance |
Pour obtenir la liste des séries de machines Compute Engine disponibles avec la classe de calcul Performance, consultez la page Séries de machines compatibles. |
|
| Calcul monothread par cœur et scaling horizontal | Scale-Out |
S'appuie sur la série de machines Tau T2A (Arm) ou la série de machines Tau T2D (x86). |
|
Sélectionner une classe de calcul dans Autopilot
Pour obtenir des instructions détaillées, consultez la section Choisir les classes de calcul pour les pods Autopilot.
Pour indiquer à Autopilot de placer vos pods sur une classe de calcul spécifique, spécifiez le libellécloud.google.com/compute-class dans un sélecteur de nœuds ou une règle d'affinité de nœuds comme dans les exemples suivants :
nodeSelector
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-app
spec:
replicas: 3
selector:
matchLabels:
app: hello-app
template:
metadata:
labels:
app: hello-app
spec:
nodeSelector:
cloud.google.com/compute-class: "COMPUTE_CLASS"
containers:
- name: hello-app
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
resources:
requests:
cpu: "2000m"
memory: "2Gi"
Remplacez COMPUTE_CLASS par le nom de la classe de calcul en fonction de votre cas d'utilisation, par exemple Scale-Out.
Si vous sélectionnez Accelerator, vous devez également spécifier une GPU compatible. Pour en savoir plus, consultez la page Déployer des charges de travail GPU dans Autopilot. Si vous sélectionnez Performance, vous devez également sélectionner une série de machines Compute Engine dans le sélecteur de nœud. Pour obtenir des instructions, consultez la page Exécuter des charges de travail intensives de processeur avec des performances optimales.
nodeAffinity
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-app
spec:
replicas: 3
selector:
matchLabels:
app: hello-app
template:
metadata:
labels:
app: hello-app
spec:
terminationGracePeriodSeconds: 25
containers:
- name: hello-app
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
resources:
requests:
cpu: "2000m"
memory: "2Gi"
ephemeral-storage: "1Gi"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/compute-class
operator: In
values:
- "COMPUTE_CLASS"
Remplacez COMPUTE_CLASS par le nom de la classe de calcul en fonction de votre cas d'utilisation, par exemple Scale-Out. Si vous sélectionnez Accelerator, vous devez également spécifier une GPU compatible. Pour en savoir plus, consultez la page Déployer des charges de travail GPU dans Autopilot. Si vous sélectionnez Performance, vous devez également sélectionner une série de machines Compute Engine dans le sélecteur de nœud. Pour obtenir des instructions, consultez la page Exécuter des charges de travail intensives de processeur avec des performances optimales.
Lorsque vous déployez la charge de travail, Autopilot effectue les opérations suivantes :
- Provisionne automatiquement les nœuds sauvegardés par la configuration spécifiée pour exécuter vos pods.
- Ajoute automatiquement des rejets aux nouveaux nœuds pour éviter que d'autres pods ne planifient ces nœuds. Les rejets sont propres à chaque classe de calcul. Si vous sélectionnez également une architecture de processeur, GKE ajoute un rejet distinct unique à cette architecture.
- Ajoute automatiquement des tolérances correspondant aux rejets appliqués à vos pods déployés, ce qui permet à GKE de placer ces pods sur les nouveaux nœuds.
Par exemple, si vous demandez la classe de calcul Scale-Out pour un pod :
- Autopilot ajoute un rejet spécifique à
Scale-Outpour ces nœuds. - Autopilot ajoute une tolérance pour ce rejet aux pods
Scale-Out.
Les pods qui ne demandent pas Scale-Out ne recevront pas la tolérance. Par conséquent, GKE ne planifie pas ces pods sur les nœuds Scale-Out.
Si vous ne demandez pas explicitement une classe de calcul dans la spécification de votre charge de travail, Autopilot planifie les pods sur les nœuds qui utilisent la classe de calcul à usage général par défaut. La plupart des charges de travail peuvent s'exécuter sans problème sur la classe de calcul à usage général.
Demander une architecture de processeur
Dans certains cas, vos charges de travail peuvent être créées pour une architecture spécifique, telle que Arm. Certaines classes de calcul, telles que "Balanced" ou "Scale-Out", sont compatibles avec plusieurs architectures de processeur. Vous pouvez demander une architecture spécifique avec votre requête de classe de calcul en spécifiant un libellé dans votre sélecteur de nœud ou votre règle d'affinité de nœud, comme dans l'exemple suivant :
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-arm
spec:
replicas: 3
selector:
matchLabels:
app: nginx-arm
template:
metadata:
labels:
app: nginx-arm
spec:
nodeSelector:
cloud.google.com/compute-class: COMPUTE_CLASS
kubernetes.io/arch: ARCHITECTURE
containers:
- name: nginx-arm
image: nginx
resources:
requests:
cpu: 2000m
memory: 2Gi
Remplacez ARCHITECTURE par l'architecture de processeur de votre choix, telle que arm64 ou amd64.
Si vous ne demandez pas explicitement une architecture, Autopilot utilise l'architecture par défaut de la classe de calcul spécifiée.
Architecture Arm sur Autopilot
Autopilot accepte les requêtes pour les nœuds qui utilisent l'architecture de processeur Arm. Les nœuds Arm sont plus rentables que les nœuds x86 similaires tout en offrant des améliorations de performances. Pour savoir comment demander des nœuds Arm, consultez la page Déployer des charges de travail Autopilot sur l'architecture Arm.
Assurez-vous d'utiliser les images appropriées dans vos déploiements. Si vos pods utilisent des images Arm et que vous ne demandez pas de nœuds Arm, Autopilot planifie les pods sur les nœuds x86, et ceux-ci plantent. De même, si vous utilisez accidentellement des images x86, mais que vous demandez des nœuds Arm pour les pods, ceux-ci planteront.
Validations Autopilot pour les charges de travail de classes de calcul
Autopilot valide les fichiers manifestes de vos charges de travail pour s'assurer que les requêtes de classe de calcul et d'architecture dans votre sélecteur de nœud ou vos règles d'affinité de nœuds sont correctement formatées. Les règles suivantes s'appliquent :
- Une seule classe de calcul.
- Aucune classe de calcul non compatible.
- La version de GKE doit être compatible avec la classe de calcul.
- Pas plus d'une architecture sélectionnée.
- La classe de calcul doit être compatible avec l'architecture sélectionnée.
Si le fichier manifeste de votre charge de travail échoue à l'une de ces validations, Autopilot rejette la charge de travail.
Disponibilité régionale des classes de calcul
Le tableau suivant décrit les régions dans lesquelles des classes de calcul et des architectures de processeurs spécifiques sont disponibles :
| Disponibilité des classes de calcul | |
|---|---|
| Usage général | Toutes les régions |
Balanced |
Toutes les régions |
Performance |
Toutes les régions contenant une série de machines compatible. |
Scale-Out |
Toutes les régions contenant une série de machines Compute Engine correspondante. Pour afficher la disponibilité d'une série de machines spécifique, utilisez les filtres de la section Régions et zones disponibles. |
Si une classe de calcul est disponible dans une région spécifique, le matériel est disponible dans au moins deux zones de cette région.
Requêtes de ressources par défaut, minimales et maximales
Lorsque vous choisissez une classe de calcul pour vos charges de travail Autopilot, veillez à spécifier les requêtes de ressources qui répondent aux requêtes minimales et maximales de cette classe de calcul. Pour en savoir plus sur les requêtes par défaut, ainsi que sur les requêtes minimales et maximales pour chaque classe de calcul, consultez la page Requêtes et limites de ressources dans GKE Autopilot.
Étapes suivantes
- Découvrez comment sélectionner des classes de calcul spécifiques dans vos charges de travail Autopilot.
- Découvrez les requêtes de ressources par défaut, minimales et maximales pour chaque plate-forme.