Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Schedule Arm and multi-architecture workloads to Arm virtual nodes

Dernière mise à jour :Aug 11, 2026

Par défaut, les clusters ACK et les clusters ACK Serverless planifient toutes les charges de travail sur des nœuds virtuels x86. Si votre cluster dispose à la fois de nœuds virtuels Arm et non-Arm, utilisez la planification native de Kubernetes (nodeSelector ou nodeAffinity) pour déployer les charges de travail exclusivement compatibles avec l'architecture Arm sur des nœuds virtuels Arm, et privilégier les nœuds Arm pour les images multi-architectures.Les clusters ACK et permettent de planifier des charges de travail dédiées à l'architecture Arm ou multi-architectures sur des nœuds virtuels Arm. Par défaut, toutes les charges de travail sont planifiées sur des nœuds virtuels x86.

Prérequis

Remarques

Pour les clusters exécutant une version de Kubernetes antérieure à la 1.24, ajoutez une toleration pour la taint kubernetes.io/arch=arm64:NoSchedule lorsque vous utilisez nodeSelector ou nodeAffinity afin de planifier des charges de travail sur des nœuds Arm. Les clusters Kubernetes 1.24 et versions ultérieures reconnaissent automatiquement la taint kubernetes.io/arch=arm64:NoSchedule ; l'ajout d'une toleration n'est donc pas requis.

Facturation

Types d'instances ECS basés sur l'architecture ARM et tarifs associés :

Étape 1 : Ajouter des nœuds virtuels Arm

Créez un nœud virtuel Arm en modifiant la ConfigMap eci-profile à l'aide de l'une des méthodes suivantes. Consultez la rubrique Configurer eci-profile.

Console

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Configurations > ConfigMaps.

  3. Dans la liste déroulante Namespace, sélectionnez kube-system. Recherchez eci-profile et cliquez sur Edit. Définissez enableLinuxArm64Node sur true, puis cliquez sur OK.

    Remarque

    Si aucun vSwitch de votre cluster ne se trouve dans une zone compatible avec les instances basées sur l'architecture Arm, créez-en un dans une zone prise en charge et ajoutez son ID au champ vSwitchIds . Consultez la rubrique Créer et gérer des vSwitches.

    Après environ 30 secondes, le nœud virtuel virtual-kubelet-<zoneId>-linux-arm64 apparaît sur la page Nodes .

Kubectl

Prérequis

Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour s'y connecter.

Procédure

Modifiez la ConfigMap :

kubectl edit configmap eci-profile -n kube-system
  1. Définissez le paramètre enableLinuxArm64Node sur true.

  2. Définissez le paramètre vSwitchIds . Assurez-vous qu'au moins un vSwitch figurant dans la liste vSwitchIds se trouve dans une zone compatible avec les instances basées sur l'architecture Arm.

    Remarque

    Si aucun vSwitch de votre cluster ne se trouve dans une zone compatible avec les instances basées sur l'architecture Arm, créez-en un dans une zone prise en charge et ajoutez son ID au champ vSwitchIds . Consultez la rubrique Créer et gérer des vSwitches.

    Après environ 30 secondes, le nœud virtuel virtual-kubelet-<zoneId>-linux-arm64 apparaît sur la page Nodes .

Étape 2 : Planifier sur un nœud virtuel Arm

Planifier des charges de travail dédiées à l'architecture Arm

Si un cluster contient à la fois des nœuds Arm et non-Arm, et que l'application prend uniquement en charge l'architecture Arm, planifiez-la sur des nœuds Arm pour éviter les échecs de démarrage. Tous les nœuds Arm portent le libellé kubernetes.io/arch=arm64 . Utilisez nodeSelector ou nodeAffinity pour les cibler.

nodeSelector

Ajoutez le code nodeSelector suivant à la spécification du pod pour cibler les nœuds virtuels Arm. Tous les nœuds virtuels Arm d'un cluster ACK ou d'un possèdent le libellé arm64 .

nodeSelector:
  kubernetes.io/arch: arm64 # Specify an Arm node.

L'exemple de fichier YAML suivant déploie une application sans état sur un nœud virtuel Arm.

Développer pour afficher le fichier YAML

Remarque

Le fichier YAML ci-dessous ajoute une tolérance pour la taint kubernetes.io/arch=arm64:NoSchedule . Si votre cluster est un cluster ACK Pro exécutant Kubernetes 1.24 ou une version ultérieure, le planificateur ACK reconnaît automatiquement cette taint et vous n'avez pas besoin d'ajouter la tolérance.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: only-arm
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        kubernetes.io/arch: arm64 # Specify an Arm node.
      tolerations:
      # Tolerate the taint of the virtual node.
        - key: virtual-kubelet.io/provider
          operator: Exists
          effect: NoSchedule
      # Tolerate the taint on the Arm virtual node.
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule
      containers:
      - name: nginx
        image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0

nodeAffinity

Prérequis

La fonctionnalité de planification des nœuds virtuels est activée pour le cluster , et les versions du cluster et des composants satisfont aux exigences.

Exemple

Ajoutez le code nodeAffinity suivant à la spécification du pod pour cibler les nœuds Arm portant le libellé kubernetes.io/arch=arm64 .

Avec cette contrainte, le planificateur tolère automatiquement la taint kubernetes.io/arch=arm64:NoSchedule .

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/arch
          operator: In
          values:
          - arm64

L'exemple de fichier YAML suivant déploie une application sans état sur un nœud virtuel Arm.

Développer pour afficher le fichier YAML

Remarque

Le fichier YAML ci-dessous ajoute une tolérance pour la taint kubernetes.io/arch=arm64:NoSchedule . Si votre cluster est un cluster ACK Pro exécutant Kubernetes 1.24 ou une version ultérieure, le planificateur ACK reconnaît automatiquement cette taint et vous n'avez pas besoin d'ajouter la tolérance.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: only-arm
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64
      tolerations:
       # Tolerate the taint of the virtual node.
        - key: virtual-kubelet.io/provider
          operator: Exists
          effect: NoSchedule
       # Tolerate the taint on the Arm virtual node.
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule         
      containers:
      - name: nginx
        image: nginx

Planifier des images multi-architectures

Prérequis

La fonctionnalité de planification des nœuds virtuels est activée pour le cluster , et les versions du cluster et des composants satisfont aux exigences.

Exemple

Les clusters ACK et les clusters ACK Serverless planifient par défaut toutes les charges de travail sur des nœuds virtuels x86 et restent en attente de capacité x86 lorsque les ressources x86 sont insuffisantes. et planifient par défaut toutes les charges de travail sur des nœuds virtuels x86 et continuent d'attendre des ressources x86 lorsqu'elles sont insuffisantes. Pour les images multi-architectures, configurez la planification inter-architectures afin d'utiliser à la fois des nœuds x86 et Arm.

Configurez l'affinité de nœud pour planifier préférentiellement les charges de travail sur des nœuds virtuels Arm ou x86. Si les ressources préférées sont insuffisantes, le planificateur bascule vers l'autre architecture.

      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64

Privilégier l'architecture Arm

Exemple de fichier YAML pour une charge de travail planifiée préférentiellement sur un nœud virtuel Arm :

Développer pour afficher le fichier YAML

Remarque

Le fichier YAML ci-dessous ajoute une tolérance pour la taint kubernetes.io/arch=arm64:NoSchedule . Si votre cluster est un cluster ACK Pro exécutant Kubernetes 1.24 ou une version ultérieure, le planificateur ACK reconnaît automatiquement cette taint et vous n'avez pas besoin d'ajouter la tolérance.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: arm-prefer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      # Tolerate the taint of the virtual node.
      - key: virtual-kubelet.io/provider
        operator: Exists
        effect: NoSchedule
      # Tolerate the taint on the Arm virtual node.
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule
      # Preferentially schedule the workload to a node that uses the Arm architecture.
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64
      containers:
      - name: my-container
        image: nginx

Privilégier l'architecture x86

Développer pour afficher le fichier YAML

Remarque

Le fichier YAML ci-dessous ajoute une tolérance pour la taint kubernetes.io/arch=arm64:NoSchedule . Si votre cluster est un cluster ACK Pro exécutant Kubernetes 1.24 ou une version ultérieure, le planificateur ACK reconnaît automatiquement cette taint et vous n'avez pas besoin d'ajouter la tolérance.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: amd-prefer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      # Tolerate the taint of the virtual node.
      - key: virtual-kubelet.io/provider
        operator: Exists
        effect: NoSchedule
      # Tolerate the taint on the Arm virtual node.
      - key: kubernetes.io/arch
        operator: Equal
        value: arm64
        effect: NoSchedule     
      # Preferentially schedule the workload to a node that uses the x86 architecture.
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values:
                - amd64
      containers:
      - name: my-container
        image: nginx

FAQ

Priorité de planification des nœuds Arm et x86

Le planificateur de cluster priorise par défaut les instances ECS par rapport aux nœuds virtuels. Sans personnalisation des pondérations du plug-in de scoring, les pods peuvent toujours être planifiés sur des instances ECS x86, même si nodeAffinity est configuré pour privilégier les nœuds Arm. Les paramètres nodeAffinity décrits dans cette rubrique garantissent uniquement la priorité entre les architectures de nœuds virtuels (Arm par rapport à x86), et non entre les nœuds virtuels et les instances ECS.

Puis-je utiliser des instances Spot Arm ?

Oui. Consultez la rubrique Utiliser des instances Spot .

Configuration réseau pour les nœuds virtuels Arm

Après la création d'un cluster ACK ou d'un , définissez le champ vSwitchIds dans eci-profile pour inclure un vSwitch situé dans une zone compatible avec les instances basées sur l'architecture Arm.

Quelles sont les limites liées à l'utilisation de nœuds basés sur l'architecture Arm dans un cluster ACK ?

Les modules complémentaires de l'App Marketplace ne sont pas pris en charge sur l'architecture Arm. Dans le Component Center, seules les catégories suivantes sont prises en charge :

  • Composants principaux

  • Journalisation et surveillance

  • Stockage

  • Réseau

Références