Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Déployer des charges de travail Autopilot sur l'architecture Arm

Autopilot

Cette page explique comment configurer vos déploiements Autopilot pour Google Kubernetes Engine (GKE) afin de demander des nœuds qui s'appuient sur l'architecture Arm.

À propos de l'architecture Arm dans Autopilot

Les clusters Autopilot proposent des classes de calcul pour les charges de travail qui nécessitent des exigences matérielles spécifiques. Certaines de ces classes de calcul sont compatibles avec plusieurs architectures de processeur, telles que amd64 et arm64.

Cas d'utilisation des nœuds Arm

Les nœuds à l'architecture Arm offrent des performances plus économiques que les nœuds x86 similaires. Vous devez sélectionner Arm pour vos charges de travail Autopilot dans les situations suivantes :

Votre environnement repose sur l'architecture Arm pour créer et tester.
Vous développez des applications pour des appareils Android qui s'exécutent sur des processeurs Arm.
Vous utilisez des images multi-arch et souhaitez optimiser les coûts lors de l'exécution de vos charges de travail.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la gcloud components update commande. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Consultez les exigences et les limites concernant les nœuds Arm.

Conditions requises

Pour utiliser la ComputeClass autopilot-arm, assurez-vous que votre cluster exécute GKE version 1.35.3-gke.1389000 ou ultérieure.
Pour utiliser des fonctionnalités telles que la valeur par défaut intelligente (en spécifiant uniquement le kubernetes.io/arch: arm64 libellé), la autopilot-arm-spot ComputeClass ou la autopilot-arm ComputeClass dans les clusters GKE Standard qui utilisent des ComputeClasses Autopilot, votre cluster doit exécuter la version 1.36.0-gke.3302001 ou ultérieure.
Vérifiez que vous disposez d'un quota pour les C4A, N4A, ou Tau T2A types de machines Compute Engine.
Assurez-vous de disposer d'un pod avec une image de conteneur créée pour l'architecture Arm.

Demander des nœuds Arm dans Autopilot

Pour indiquer à Autopilot d'exécuter vos pods sur des nœuds Arm, spécifiez l'un des sélecteurs suivants (en fonction de votre type et de votre version de GKE) à l'aide d'un nodeSelector ou d'une règle d'affinité de nœud :

Dans les clusters Autopilot (valeur par défaut intelligente) : spécifiez uniquement le type d'architecture :
- kubernetes.io/arch: arm64
Si votre charge de travail s'exécute sur un cluster Autopilot, cette option sélectionne la plate-forme Arm à usage général.
Dans les clusters Autopilot ou les clusters Standard qui utilisent des ComputeClasses Autopilot (ComputeClass uniquement) : spécifiez la ComputeClass :
- cloud.google.com/compute-class: autopilot-arm (ou autopilot-arm-spot)
La sélection de cette classe planifie votre charge de travail sur la plate-forme Arm optimisée pour les conteneurs (ou sa variante de VM Spot) et ajoute automatiquement le sélecteur kubernetes.io/arch: arm64 requis au pod lors de l'admission.
Sélection explicite (anciennes versions de GKE) : dans les clusters Autopilot exécutant la version 1.35.3-gke.1389000 ou ultérieure, mais antérieure à la version 1.36.0-gke.3302001, spécifiez les deux sélecteurs suivants pour sélectionner la plate-forme Arm à usage général. Cette combinaison est également compatible avec les versions plus récentes de GKE pour assurer la rétrocompatibilité :
- cloud.google.com/compute-class: autopilot-arm
- kubernetes.io/arch: arm64
Pour les charges de travail ayant des exigences matérielles spécifiques : spécifiez l'une des options suivantes :
- kubernetes.io/arch: arm64 dans un cluster Standard. Par défaut, GKE place les pods sur des types de machines C4A.
- cloud.google.com/machine-family: ARM_MACHINE_SERIES. Remplacez ARM_MACHINE_SERIES par une série de machines Arm telle que C4A, N4A, ou T2A. GKE place les pods sur la série spécifiée.

Par défaut, l'utilisation de l'un des libellés, à l'exception de Performance, permet à GKE de placer d'autres pods sur le même nœud si la capacité est disponible sur ce nœud. Pour demander un nœud dédié pour chaque pod, ajoutez le libellé cloud.google.com/compute-class: Performance à votre fichier manifeste, en plus des libellés d'architecture ou de famille de machines. Pour en savoir plus, consultez Optimiser les performances des pods Autopilot en choisissant une série de machines.

Vous pouvez également utiliser le libellé Scale-Out avec le libellé arm64 pour demander T2A. Vous pouvez également demander une architecture Arm pour les pods Spot.

Lorsque vous déployez votre charge de travail, Autopilot effectue les opérations suivantes :

Provisionne automatiquement les nœuds Arm pour exécuter vos pods.
Rejette automatiquement les nouveaux nœuds afin d'éviter que les pods non Arm soient planifiés sur ces nœuds.
Ajoute automatiquement une tolérance à vos pods Arm afin de permettre la planification sur les nouveaux nœuds.

Exemple de requête pour l'architecture Arm

Les exemples de spécifications suivants montrent comment utiliser un sélecteur de nœud ou une règle d'affinité de nœud pour demander une architecture Arm dans Autopilot.

nodeSelector

L'exemple de fichier manifeste suivant demande un nœud Arm optimisé pour les conteneurs Autopilot à l'aide de la valeur par défaut intelligente :

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:
        kubernetes.io/arch: arm64
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

Vous pouvez également demander la plate-forme Arm optimisée pour les conteneurs en spécifiant explicitement la autopilot-arm (ou autopilot-arm-spot pour les VM Spot) ComputeClass :

...
    spec:
      nodeSelector:
        cloud.google.com/compute-class: autopilot-arm
...

Pour demander du matériel spécifique au lieu de nœuds optimisés pour les conteneurs Autopilot, remplacez les ComputeClasses ou ajoutez cloud.google.com/machine-family: C4A à votre sélecteur.

nodeAffinity

Vous pouvez utiliser l'affinité de nœuds pour demander des nœuds Arm.

L'exemple de fichier manifeste suivant demande un nœud Arm optimisé pour les conteneurs Autopilot à l'aide de la valeur par défaut intelligente :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      terminationGracePeriodSeconds: 25
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi
            ephemeral-storage: 1Gi
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64

Pour demander du matériel spécifique au lieu de nœuds optimisés pour les conteneurs Autopilot, remplacez kubernetes.io/arch par des règles d'affinité de famille de machines spécifiques ou demandez des classes telles que Performance ou Scale-Out.

Recommandations

Créez et utilisez des images multi-arch dans le cadre de votre pipeline. Les images multi-arch garantissent que vos pods s'exécutent même s'ils sont placés sur des nœuds x86.
Demandez explicitement des classes d'architecture et de calcul dans vos fichiers manifestes de charge de travail. Si vous ne le faites pas, Autopilot utilise l'architecture par défaut de la classe de calcul sélectionnée, qui peut ne pas être Arm.

Disponibilité

Vous pouvez déployer des charges de travail Autopilot sur l'architecture Arm dans les régions suivantes : us-east1, us-west1, europe-west1, europe-west2, europe-west4, asia-southeast1 et us-central1.

Dépannage

Pour obtenir des informations sur les erreurs courante et le dépannage, consultez la section Résoudre les problèmes liés aux charges de travail Arm.