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 la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. 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.
Pour utiliser la ComputeClass autopilot-arm, assurez-vous que votre cluster exécute la version 1.35.3-gke.1389000 ou ultérieure de GKE.
Vérifiez que vous disposez d'un quota pour les types de machines Compute Engine C4A, N4A ou Tau T2A.
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, utilisez l'une des méthodes suivantes, en fonction de vos besoins. Vous les spécifiez à l'aide d'un nodeSelector ou d'une règle d'affinité de nœuds :

Pour les charges de travail à usage général : demandez la plate-forme Arm optimisée pour les conteneurs en spécifiant les deux éléments suivants :
- cloud.google.com/compute-class: autopilot-arm
- kubernetes.io/arch: arm64
Pour les charges de travail avec des exigences matérielles spécifiques : spécifiez l'une des options suivantes :
- kubernetes.io/arch: arm64. GKE place les pods sur des types de machines C4A par défaut pour les clusters exécutant la version 1.31.3-gke.1056000 et ultérieures. Si le cluster exécute une version antérieure, GKE place les pods sur des types de machines T2A.
  
  Remarque : Étant donné que GKE utilise par défaut la série de machines C4A pour les charges de travail Arm lorsqu'aucune classe de calcul n'est spécifiée, le fait de ne fournir que kubernetes.io/arch: arm64 place vos pods sur du matériel C4A spécifique plutôt que sur la plate-forme de pods optimisée pour les conteneurs Autopilot.
- cloud.google.com/machine-family: ARM_MACHINE_SERIES. Remplacez ARM_MACHINE_SERIES par une série de machines Arm, comme 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 :

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

Pour demander du matériel spécifique au lieu de nœuds optimisés pour les conteneurs Autopilot, remplacez autopilot-arm par Performance ou Scale-Out dans nodeSelector.

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 :

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: cloud.google.com/compute-class
                operator: In
                values:
                - autopilot-arm
              - 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 autopilot-arm par Performance ou Scale-Out dans les règles nodeAffinity.

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-west4 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.