Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Implement rapid elastic scaling across multiple zones

Dernière mise à jour :Aug 11, 2026

Les architectures haute disponibilité reposent sur une répartition équilibrée des charges de travail entre plusieurs zones. Cette rubrique explique comment utiliser le composant ack-autoscaling-placeholder pour mettre en œuvre une mise à l'échelle élastique rapide et consciente des zones dans les clusters ACK. Cette approche garantit que les nouveaux nœuds ajoutés lors d'un scale-out sont déployés simultanément dans les zones appropriées.

Prérequis

Fonctionnement

Le problème

Lorsqu'un pool de nœuds est configuré avec des vSwitches provenant de plusieurs zones au sein d'un même groupe de mise à l'échelle, le Cluster Autoscaler ne peut pas déterminer quelle zone spécifique nécessite de nouveaux nœuds. Par conséquent, les instances issues du scale-out risquent de se concentrer dans une seule zone plutôt que d'être réparties uniformément. Cette situation contredit l'objectif d'un déploiement multi-zones.

image

La solution

ACK résout ce problème grâce au composant ack-autoscaling-placeholder, qui utilise la redondance des ressources pour transformer la mise à l'échelle élastique multi-zones en un scaling dirigé de pools de nœuds concurrents. Pour en savoir plus, consultez la rubrique Utiliser ack-autoscaling-placeholder pour mettre à l'échelle les pods en quelques secondes. Le mécanisme s'articule autour de trois étapes :

  1. Créez un pool de nœuds par zone avec un libellé de zone. Chaque pool de nœuds reçoit un libellé identifiant la zone à laquelle il appartient.

  2. Déployez des pods de substitution (placeholder) à l'aide de nodeSelector. Le composant ack-autoscaling-placeholder planifie un pod de substitution dans chaque zone en fonction du libellé de zone. Ces pods utilisent une PriorityClass dont le poids est inférieur à celui des pods d'application.

  3. Les pods d'application préemptent les pods de substitution. Lorsque des pods d'application sont en attente (Pending), ils remplacent les pods de substitution de priorité inférieure sur les nœuds existants. Les pods de substitution déplacés passent alors eux-mêmes à l'état Pending. Comme ces pods utilisent une planification basée sur nodeSelector (plutôt que sur antiAffinity), le Cluster Autoscaler identifie la zone exacte requise par chaque pod de substitution en attente et déclenche un scale-out dirigé vers les pools de nœuds appropriés de manière concurrente.

Flux de mise à l'échelle

La figure suivante illustre le fonctionnement d'une mise à l'échelle simultanée sur deux zones avec cette architecture.

image

  1. Le composant ack-autoscaling-placeholder crée un pod de substitution dans chaque zone. Ces pods bénéficient d'une priorité de planification inférieure à celle des pods d'application réels.

  2. Lorsque les pods d'application passent à l'état Pending, ils préemptent rapidement les pods de substitution et sont déployés sur les nœuds existants de chaque zone. Les pods de substitution préemptés passent alors à l'état Pending.

  3. Étant donné que les pods de substitution sont planifiés via nodeSelector, le Cluster Autoscaler peut effectuer un scale-out simultané vers les zones correspondantes.

Étape 1 : Créer un pool de nœuds pour chaque zone et configurer un libellé de nœud personnalisé

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

  2. Sur la page Clusters, repérez le cluster à gérer et cliquez sur son nom. Dans le volet de navigation de gauche, sélectionnez Nodes > Node Pools.

  3. Cliquez sur Create Node Pool et configurez le pool de nœuds selon les instructions. Cet exemple crée un pool de nœuds nommé auto-zone-I avec l'Auto Scaling activé dans la zone I. Le tableau ci-dessous décrit uniquement les paramètres clés. Pour plus de détails, consultez la rubrique Créer et gérer un pool de nœuds. Le pool de nœuds est créé lorsque son statut affiche Active dans la liste des pools de nœuds.

    **Parameter** **Description**
    Node Pool Name auto-zone-I
    Scaling Mode Sélectionnez Auto pour activer l'Auto Scaling.
    vSwitch Sélectionnez un vSwitch dans la zone I.
    Node Labels Définissez la Key du libellé de nœud sur available_zone et la Value sur i.
  4. Répétez les étapes précédentes pour créer un pool de nœuds avec l'Auto Scaling activé pour chaque zone nécessitant cette fonctionnalité.

    Node pools across multiple zones

Vérification : Dans la liste des pools de nœuds, vérifiez que chaque pool spécifique à une zone présente un statut Active et que le libellé de zone est correctement appliqué.

Étape 2 : Déployer ack-autoscaling-placeholder et configurer les Deployments de substitution

Déployer le composant

  1. Dans le volet de navigation de gauche de la console ACK, sélectionnez Marketplace > Marketplace.

  2. Recherchez ack-autoscaling-placeholder et cliquez dessus. Sur la page ack-autoscaling-placeholder, cliquez sur Deploy.

  3. Sélectionnez un cluster dans la liste déroulante Cluster et un namespace dans la liste déroulante Namespace, puis cliquez sur Next. Choisissez une version de chart dans la liste déroulante Chart Version, configurez les parameters, puis cliquez sur OK. Une fois le composant déployé, accédez à Applications > Helm dans le volet de navigation de gauche. Vérifiez que l'application est à l'état Deployed.

Mettre à jour la release Helm avec les Deployments de substitution

  1. Dans le volet de navigation de gauche de la page des détails, sélectionnez Applications > Helm.

  2. Sur la page Helm, cliquez sur Update dans la colonne Actions correspondant à ack-autoscaling-placeholder-default.

  3. Dans le panneau Update Release, mettez à jour le fichier YAML en suivant l'exemple ci-dessous, puis cliquez sur OK. Déployez un placeholder pour chaque zone et définissez un Deployment de substitution pour chacune d'elles. Cet exemple crée des Deployments de substitution dans les zones I, K et H. Chaque entrée de la liste deployments suit la même structure. La première entrée est entièrement annotée ; les suivantes ne diffèrent que par les valeurs name et nodeSelector. Le tableau suivant résume les champs à modifier pour chaque zone : Une fois la mise à jour réussie, des Deployments de substitution sont créés pour chaque zone.

    Champ Zone I Zone K Zone H
    name ack-place-holder-I ack-place-holder-K ack-place-holder-H
    nodeSelector {"avaliable_zone":i} {"avaliable_zone":k} {"avaliable_zone":h}
       deployments:
       # --- Zone I placeholder ---
       - affinity: {}
         annotations: {}
         containers:
         - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
           imagePullPolicy: IfNotPresent
           name: placeholder
           resources:
             requests:
               cpu: 3500m     # CPU request for each placeholder pod.
               memory: 6      # Memory request for each placeholder pod.
         imagePullSecrets: {}
         labels: {}
         name: ack-place-holder-I             # Deployment name. Use a unique suffix per zone.
         nodeSelector: {"avaliable_zone":i}   # Must match the node label key and value from Step 1.
         replicaCount: 10                     # Number of placeholder pods per zone.
         tolerations: []
    
       # --- Zone K placeholder (same structure, different zone) ---
       - affinity: {}
         annotations: {}
         containers:
         - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
           imagePullPolicy: IfNotPresent
           name: placeholder
           resources:
             requests:
               cpu: 3500m
               memory: 6
         imagePullSecrets: {}
         labels: {}
         name: ack-place-holder-K
         nodeSelector: {"avaliable_zone":k}
         replicaCount: 10
         tolerations: []
    
       # --- Zone H placeholder (same structure, different zone) ---
       - affinity: {}
         annotations: {}
         containers:
         - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
           imagePullPolicy: IfNotPresent
           name: placeholder
           resources:
             requests:
               cpu: 3500m
               memory: 6
         imagePullSecrets: {}
         labels: {}
         name: ack-place-holder-H
         nodeSelector: {"avaliable_zone":h}
         replicaCount: 10
         tolerations: []
    
       fullnameOverride: ""
       nameOverride: ""
       podSecurityContext: {}
       priorityClassDefault:
         enabled: true
         name: default-priority-class
         value: -1

    Placeholder Deployments created

Vérification : Accédez à Applications > Helm et vérifiez que ack-autoscaling-placeholder-default affiche l'état Deployed avec la configuration mise à jour.

Étape 3 : Créer une PriorityClass pour la charge de travail

La PriorityClass de la charge de travail doit avoir une valeur supérieure à celle de la PriorityClass des placeholders (-1), afin que les pods d'application puissent préempter les pods de substitution. Deux options s'offrent à vous :

  • Option A : PriorityClass nommée -- Attribuez-la explicitement à des charges de travail spécifiques via priorityClassName.

  • Option B : PriorityClass globale -- S'applique automatiquement à tous les pods qui ne spécifient pas de PriorityClass.

Option A : PriorityClass nommée

  1. Créez un fichier nommé priorityClass.yaml et copiez-y le contenu suivant :

       apiVersion: scheduling.k8s.io/v1
       kind: PriorityClass
       metadata:
         name: high-priority
       value: 1000000              # The priority value. Must be higher than the default priority value (-1) of the placeholder pods created in Step 2.
       globalDefault: false
       description: "This priority class should be used for XYZ service pods only."

Option B : PriorityClass globale

Si vous n'avez pas besoin d'une PriorityClass distincte pour chaque pod, vous pouvez configurer une PriorityClass globale par défaut. Une fois appliquée, les pods sans PriorityClass spécifiée adoptent automatiquement cette valeur de priorité, et la préemption prend effet immédiatement.

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: global-high-priority
   value: 1                              # The priority value. Must be higher than the default priority value (-1) of the placeholder pods created in Step 2.
   globalDefault: true
   description: "This priority class should be used for XYZ service pods only."

Appliquer la PriorityClass

  1. Créez la PriorityClass. Résultat attendu :

       kubectl apply -f priorityClass.yaml
       priorityclass.scheduling.k8s.io/high-priority created
Vérification : Exécutez kubectl get priorityclass et vérifiez que high-priority (ou global-high-priority ) apparaît dans la liste avec la valeur de priorité correcte.

Étape 4 : Créer une charge de travail

Cet exemple utilise la zone I.

  1. Créez un fichier nommé workload.yaml et copiez-y le contenu suivant :

       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: placeholder-test
         labels:
           app: nginx
       spec:
         replicas: 1
         selector:
           matchLabels:
             app: nginx
         template:
           metadata:
             labels:
               app: nginx
           spec:
             nodeSelector:                        # Rules used to select nodes.
               avaliable_zone: "i"
             priorityClassName: high-priority     # The PriorityClass configured in Step 3. Optional if global configuration is enabled.
             containers:
             - name: nginx
               image: nginx:1.7.9
               ports:
               - containerPort: 80
               resources:
                 requests:
                   cpu: 3                         # The resource request of the workload.
                   memory: 5
  2. Déployez la charge de travail. Résultat attendu : Après le déploiement, sur la page Workloads > Pods, vous constatez que la PriorityClass de la charge de travail est supérieure à celle des pods de substitution. Le pod de substitution s'exécute sur le nœud issu du scale-out et déclenche une mise à l'échelle concurrente par le Cluster Autoscaler en préparation du prochain événement de scaling. Accédez à Nodes > Nodes. Sur la page Nodes, vérifiez que le pod de la charge de travail s'exécute sur le nœud qui hébergeait auparavant le pod de substitution.

       kubectl apply -f workload.yaml
       deployment.apps/placeholder-test created

    Workload deployed

    Workload pod placement

Vérification : Sur la page Workloads > Pods , vérifiez que le pod de la charge de travail est en état Running et que le pod de substitution déplacé a déclenché un scale-out des nœuds dans la zone correcte.