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 :
Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Vérifiez que vous disposez d'un quota pour les types de machines Compute Engine C4A 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, spécifiez l'un des libellés suivants dans un nodeSelector ou une règle d'affinité de nœuds :
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.
cloud.google.com/machine-family: ARM_MACHINE_SERIES.
Remplacez ARM_MACHINE_SERIES par une série de machines Arm, comme C4A ou T2A. GKE place les pods sur la série spécifiée.
Par défaut, l'utilisation de l'un ou l'autre de ces libellés permet à GKE de placer d'autres pods sur le même nœud si la capacité est disponible. Pour demander un nœud dédié pour chaque pod, ajoutez le libellé cloud.google.com/compute-class:
Performance à votre fichier manifeste. 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 montre comment demander des nœuds Arm dans un sélecteur de nœud :
Vous pouvez utiliser l'affinité de nœuds pour demander des nœuds Arm. Vous pouvez également spécifier le type d'affinité de nœuds à utiliser :
requiredDuringSchedulingIgnoredDuringExecution : doit utiliser la classe et l'architecture de calcul spécifiées.
preferredDuringSchedulingIgnoredDuringExecution : utilise la classe et l'architecture de calcul spécifiées de la manière la plus optimale possible. Par exemple, si un nœud x86 existant peut être alloué, GKE place votre pod sur le nœud x86 au lieu de provisionner un nouveau nœud Arm. À moins d'utiliser un fichier manifeste d'image multi-arch, votre pod plante. Nous vous recommandons vivement de demander explicitement l'architecture spécifique que vous souhaitez.
L'exemple de fichier manifeste suivant requiert la classe Performance et les nœuds Arm :
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 lesGoogle Cloud qui la prennent en charge. Pour en savoir plus, consultez la section Régions et zones disponibles.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/01 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/01 (UTC)."],[],[],null,["# Deploy Autopilot workloads on Arm architecture\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview)\n\n*** ** * ** ***\n\nThis page shows you how to configure your Google Kubernetes Engine (GKE)\nAutopilot deployments to request nodes that are backed by Arm\narchitecture.\n\nAbout Arm architecture in Autopilot\n-----------------------------------\n\nAutopilot clusters offer\n[*compute classes*](/kubernetes-engine/docs/concepts/autopilot-compute-classes)\nfor workloads that have specific hardware requirements. Some of these compute\nclasses support multiple CPU architectures, such as `amd64` and `arm64`.\n\nUse cases for Arm nodes\n-----------------------\n\nNodes with Arm architecture offer more cost-efficient performance than similar\nx86 nodes. You should select Arm for your Autopilot workloads in\nsituations such as the following:\n\n- Your environment relies on Arm architecture for building and testing.\n- You're developing applications for Android devices that run on Arm CPUs.\n- You use multi-arch images and want to optimize costs while running your workloads.\n\nBefore you begin\n----------------\n\nBefore you start, make sure that you have performed the following tasks:\n\n- Enable the Google Kubernetes Engine API.\n[Enable Google Kubernetes Engine API](https://console.cloud.google.com/flows/enableapi?apiid=container.googleapis.com)\n- If you want to use the Google Cloud CLI for this task, [install](/sdk/docs/install) and then [initialize](/sdk/docs/initializing) the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running `gcloud components update`. **Note:** For existing gcloud CLI installations, make sure to set the `compute/region` [property](/sdk/docs/properties#setting_properties). If you use primarily zonal clusters, set the `compute/zone` instead. By setting a default location, you can avoid errors in the gcloud CLI like the following: `One of [--zone, --region] must be supplied: Please specify location`. You might need to specify the location in certain commands if the location of your cluster differs from the default that you set.\n\n\u003c!-- --\u003e\n\n- Review the [requirements and limitations for Arm\n nodes](/kubernetes-engine/docs/concepts/arm-on-gke#arm-requirements-limitations).\n- Ensure that you have quota for the [C4A](/compute/docs/general-purpose-machines#c4a_series) or [Tau T2A](/compute/docs/general-purpose-machines#t2a_machines) Compute Engine machine types.\n- Ensure that you have a Pod with a container image that's built for Arm architecture.\n\nHow to request Arm nodes in Autopilot\n-------------------------------------\n\nTo tell Autopilot to run your Pods on Arm nodes, specify one of the\nfollowing labels in a\n[nodeSelector](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)\nor [node\naffinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)\nrule:\n\n- `kubernetes.io/arch: arm64`. GKE places Pods on `C4A` machine types by default for clusters running version 1.31.3-gke.1056000 and later. If the cluster is running an earlier version, GKE places Pods on `T2A` machine types.\n- `cloud.google.com/machine-family: `\u003cvar translate=\"no\"\u003eARM_MACHINE_SERIES\u003c/var\u003e. Replace \u003cvar translate=\"no\"\u003eARM_MACHINE_SERIES\u003c/var\u003e with an Arm machine series like `C4A` or `T2A`. GKE places Pods on the specified series.\n\nBy default, using either of the labels lets GKE place other Pods\non the same node if there's availability capacity on that node. To request a\ndedicated node for each Pod, add the `cloud.google.com/compute-class:\nPerformance` label to your manifest. For details, see [Optimize\nAutopilot Pod performance by choosing a machine\nseries](/kubernetes-engine/docs/how-to/performance-pods).\n\nOr, you can use the `Scale-Out` label with the `arm64` label to request `T2A`.\nYou can also request Arm architecture for [Spot Pods](/kubernetes-engine/docs/how-to/autopilot-spot-pods).\n\nWhen you deploy your workload, Autopilot does the following:\n\n1. Automatically provisions Arm nodes to run your Pods.\n2. Automatically taints the new nodes to prevent non-Arm Pods from being scheduled on those nodes.\n3. Automatically adds a toleration to your Arm Pods to allow scheduling on the new nodes.\n\nExample request for Arm architecture\n------------------------------------\n\nThe following example specifications show you how to use a node selector or a\nnode affinity rule to request Arm architecture in Autopilot. \n\n### nodeSelector\n\nThe following example manifest shows you how to request Arm nodes in a\nnodeSelector: \n\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: nginx-arm\n spec:\n replicas: 3\n selector:\n matchLabels:\n app: nginx-arm\n template:\n metadata:\n labels:\n app: nginx-arm\n spec:\n nodeSelector:\n cloud.google.com/compute-class: Performance\n kubernetes.io/arch: arm64\n containers:\n - name: nginx-arm\n image: nginx\n resources:\n requests:\n cpu: 2000m\n memory: 2Gi\n\n### nodeAffinity\n\nYou can use\n[node affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)\nto request Arm nodes. You can also specify the type of node affinity to use:\n\n- `requiredDuringSchedulingIgnoredDuringExecution`: Must use the specified compute class and architecture.\n- `preferredDuringSchedulingIgnoredDuringExecution`: Use the specified compute class and architecture on a best-effort basis. For example, if an existing x86 node is allocatable, GKE places your Pod on the x86 node instead of provisioning a new Arm node. Unless you're using a multi-arch image manifest, your Pod will crash. We strongly recommend that you explicitly request the specific architecture that you want.\n\nThe following example manifest *requires* the `Performance` class and Arm\nnodes: \n\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: nginx-arm\n spec:\n replicas: 3\n selector:\n matchLabels:\n app: nginx-arm\n template:\n metadata:\n labels:\n app: nginx-arm\n spec:\n terminationGracePeriodSeconds: 25\n containers:\n - name: nginx-arm\n image: nginx\n resources:\n requests:\n cpu: 2000m\n memory: 2Gi\n ephemeral-storage: 1Gi\n affinity:\n nodeAffinity:\n requiredDuringSchedulingIgnoredDuringExecution:\n nodeSelectorTerms:\n - matchExpressions:\n - key: cloud.google.com/compute-class\n operator: In\n values:\n - Performance\n - key: kubernetes.io/arch\n operator: In\n values:\n - arm64\n\nRecommendations\n---------------\n\n- [Build and use multi-arch images](/kubernetes-engine/docs/how-to/build-multi-arch-for-arm) as part of your pipeline. Multi-arch images ensure that your Pods run even if they're placed on x86 nodes.\n- Explicitly request architecture and compute classes in your workload manifests. If you don't, Autopilot uses the default architecture of the selected compute class, which might not be Arm.\n\nAvailability\n------------\n\nYou can deploy Autopilot workloads on Arm architecture in\nGoogle Cloud locations that support Arm architecture. For details, see\n[Available regions and zones](/compute/docs/regions-zones#available).\n\nTroubleshooting\n---------------\n\nFor common errors and troubleshooting information, refer to\n[Troubleshooting Arm workloads](/kubernetes-engine/docs/troubleshooting/troubleshooting-arm-workloads).\n\nWhat's next\n-----------\n\n- [Learn more about Autopilot cluster architecture](/kubernetes-engine/docs/concepts/autopilot-architecture).\n- [Learn about the lifecycle of Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/).\n- [Learn about the available Autopilot compute classes](/kubernetes-engine/docs/concepts/autopilot-compute-classes).\n- [Read about the default, minimum, and maximum resource requests for each\n platform](/kubernetes-engine/docs/concepts/autopilot-resource-requests)."]]