À propos des classes de calcul "Équilibrée" et "Scale-Out" dans les clusters Autopilot

Vous pouvez utiliser les ComputeClasses Balanced et Scale-Out dans les clusters Google Kubernetes Engine (GKE) Autopilot pour exécuter des charges de travail nécessitant une capacité de calcul supplémentaire ou des configurations de processeur spécialisées. Cette page est destinée aux administrateurs de cluster qui souhaitent des options de calcul plus flexibles que celles fournies par la configuration de cluster Autopilot par défaut.

Présentation des ComputeClasses Balanced et Scale-Out

Par défaut, les pods des clusters GKE Autopilot s'exécutent sur une plate-forme de calcul optimisée pour les conteneurs. Cette plate-forme est idéale pour les charges de travail à usage général, telles que les serveurs Web et les jobs par lot à intensité moyenne. La plate-forme de calcul optimisée pour les conteneurs fournit une configuration matérielle fiable, évolutive 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), vous pouvez utiliser des ComputeClasses pour provisionner ce matériel.

Uniquement dans les clusters Autopilot, GKE fournit les ComputeClasses sélectionnées suivantes, qui vous permettent d'exécuter des pods nécessitant plus de flexibilité que la plate-forme de calcul optimisée pour les conteneurs par défaut :

  • Balanced : fournit une capacité maximale de processeur et de mémoire supérieure à celle de la plate-forme de calcul optimisée pour les conteneurs.
  • Scale-Out : désactive le multithreading simultané (SMT) et est optimisé pour le scaling horizontal.

Ces ComputeClasses ne sont disponibles que dans les clusters Autopilot. Semblable à la plate-forme de calcul optimisée pour les conteneurs par défaut, Autopilot gère le dimensionnement des nœuds et l'allocation des ressources en fonction de vos pods en cours d'exécution.

ComputeClasses personnalisées pour plus de flexibilité

Si les ComputeClasses équilibrées ou de scaling horizontal des clusters Autopilot ne répondent pas aux exigences de votre charge de travail, vous pouvez configurer vos propres ComputeClasses. Vous déployez des ressources personnalisées Kubernetes ComputeClass sur vos clusters avec des ensembles d'attributs de nœud que GKE utilise pour configurer de nouveaux nœuds dans le cluster. Ces ComputeClasses personnalisées peuvent, par exemple, vous permettre de déployer des charges de travail sur le même matériel que les ComputeClasses Balanced ou Scale-Out dans n'importe quel cluster GKE Autopilot ou Standard. Pour en savoir plus, consultez À propos des charges de travail en mode Autopilot dans GKE Standard.

Tarifs

Les pods qui utilisent les classes de calcul Balanced ou Scale-Out sont facturés en fonction des SKU suivants :

Pour en savoir plus, consultez la page Tarifs de GKE.

Détails techniques des types Équilibré et Scaling horizontal

Cette section décrit les types de machines et les cas d'utilisation des classes Balanced et Scale-Out. Si vous ne demandez pas de ComputeClass dans vos pods, Autopilot les place par défaut sur la plate-forme de calcul optimisée pour les conteneurs. La plate-forme de calcul optimisée pour les conteneurs utilise n'importe quelle série de machines de la famille de machines à usage général de Compute Engine, avec une préférence pour les types de machines redimensionnables. Étant donné que la série de machines sous-jacente n'est pas fixe, les performances par processeur varient en fonction de la série de machines sur laquelle GKE planifie votre pod.

De plus, la planification des pods avec stockage persistant associé dépend de la compatibilité du type de disque :

  • Anciens disques persistants : les pods auxquels sont associés d'anciens disques persistants (comme pd-standard) ne s'exécutent que sur les séries de machines compatibles, telles que E2.
  • Hyperdisk : les pods avec stockage de nouvelle génération associé (comme hyperdisk-balanced) s'exécutent sur des séries de machines plus récentes, telles que C3.
  • État "En attente" : si vous configurez explicitement un pod pour qu'il s'exécute sur une série de machines plus récente (par exemple, en utilisant des sélecteurs de nœuds pour demander des nœuds C3 ou en configurant une ComputeClass personnalisée), mais que vous associez un disque persistant ancien, le pod reste indéfiniment à l'état Pending. Cela se produit, car GKE ne trouve pas de nœud qui satisfait à la fois les contraintes de compatibilité du type de machine et du disque. Lorsque vous sélectionnez explicitement une série de machines, vous devez vous assurer de la compatibilité des PersistentVolumes et des disques.

Le tableau suivant fournit une présentation technique des ComputeClasses Balanced et Scale-Out.

ComputeClasses Balanced et Scale-Out
Balanced

Fournit une capacité de processeur et de mémoire supérieure aux limites maximales de la plate-forme de calcul optimisée pour les conteneurs. Fournit des plates-formes de processeur supplémentaires et la possibilité de définir des configurations de processeur minimales pour les pods, telles que Intel Ice Lake ou une version ultérieure.

  • Processeurs disponibles : AMD EPYC Milan, Intel Ice Lake, Intel Cascade Lake
  • Architecture disponible : amd64
  • Série de machines : N2 (processeurs Intel) ou série de machines N2D (processeurs AMD).

Utilisez la classe Balanced pour les applications telles que les suivantes :

  • Serveurs Web
  • Bases de données moyennes à grandes
  • Mise en cache
  • Flux et diffusion de contenus multimédias
  • Stockage Hyperdisk Throughput et Extreme
Scale-Out

Fournit un calcul monothread par cœur et un scaling horizontal.

  • Processeurs disponibles : Ampere Altra Arm ou AMD EPYC Milan
  • Architecture disponible : arm64 ou md64
  • Série de machines : T2A (Arm) ou T2D (x86).
  • Fonctionnalités supplémentaires :
    • Le SMT est désactivé. Un processeur virtuel équivaut donc à un cœur physique.
    • Vitesse d'horloge maximale de 3,5 GHz.

Utilisez la classe Scale-Out pour les applications telles que les suivantes :

  • Serveurs Web
  • Microservices conteneurisés
  • Traitement de journaux de données
  • Applications Java à grande échelle
  • Stockage Hyperdisk Throughput

Sélection de ComputeClass dans les charges de travail

Pour utiliser une ComputeClass pour une charge de travail GKE, vous sélectionnez la ComputeClass dans le fichier manifeste de la charge de travail à l'aide d'un sélecteur de nœuds pour l'étiquette cloud.google.com/compute-class.

L'exemple de fichier manifeste de déploiement suivant sélectionne une ComputeClass :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Replace with the name of a compute class
        cloud.google.com/compute-class: COMPUTE_CLASS 
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "1Gi"

Remplacez COMPUTE_CLASS par le nom d'une ComputeClass, par exemple Balanced ou Scale-Out. Vous ne pouvez sélectionner qu'une seule ComputeClass dans une charge de travail.

Lorsque vous déployez la charge de travail, GKE 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 étiquettes de nœud et des rejets aux nouveaux nœuds pour éviter que d'autres pods ne planifient ces nœuds. Les rejets sont propres à chaque ComputeClass. 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 ComputeClass Scale-Out pour un pod :

  1. Autopilot ajoute un rejet spécifique à Scale-Out pour ces nœuds.
  2. 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 ComputeClass dans la spécification de votre charge de travail, Autopilot planifie les pods sur les nœuds qui utilisent la plate-forme de calcul optimisée pour les conteneurs par défaut. La plupart des charges de travail à usage général peuvent s'exécuter sans problème sur cette plate-forme.

Si vous utilisez des ComputeClasses ou demandez des séries de machines spécifiques, assurez-vous que vos charges de travail n'utilisent pas de stockage incompatible. Par exemple, n'utilisez pas d'anciens types de volumes de disque persistant, tels que les volumes de disque persistant standard (pd-standard) ou de disque persistant SSD (pd-ssd), sur des séries de machines qui ne les acceptent pas. L'utilisation d'un stockage incompatible peut entraîner le maintien des pods à l'état Pending si GKE ne peut pas trouver ni provisionner un nœud qui répond à toutes les contraintes. Si un pod est planifié, mais que l'association ou l'installation du stockage échoue, le pod reste à l'état ContainerCreating. Pour en savoir plus sur la résolution des problèmes de compatibilité du stockage, consultez Charge de travail planifiée sur des séries de machines plus anciennes ou bloquée à l'état Pending en raison d'une incompatibilité de stockage.

Demander une architecture de processeur

Dans certains cas, vos charges de travail peuvent être créées pour une architecture spécifique, telle que Arm. La classe de calcul Scale-Out est compatible avec plusieurs architectures de processeur. Vous pouvez demander une architecture spécifique avec votre requête ComputeClass 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. Vous ne pouvez sélectionner qu'une seule architecture dans votre charge de travail. La ComputeClass que vous sélectionnez doit être compatible avec l'architecture que vous spécifiez.

Si vous ne demandez pas explicitement une architecture, Autopilot utilise l'architecture par défaut de la ComputeClass.

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.

Requêtes de ressources par défaut, minimales et maximales

Lorsque vous choisissez une ComputeClass 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 ComputeClass. Pour en savoir plus sur les requêtes par défaut, ainsi que sur les requêtes minimales et maximales pour chaque ComputeClass, consultez la page Requêtes et limites de ressources dans GKE Autopilot.

Étapes suivantes