Container Service for Kubernetes:Configure priority-based scheduling for elastic resources

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: test
  namespace: default
spec:
  selector:
    key1: value1
  strategy: prefer
  units:
  - nodeSelector:
      unit: first
    podLabels:
      key1: value1
    podAnnotations:
      key1: value1
    resource: ecs
  - nodeSelector:
      unit: second
    max: 10
    resource: ecs
  - resource: eci
  # Optional advanced configuration
  preemptPolicy: AfterAllUnits
  ignorePreviousPod: false
  ignoreTerminatingPod: true
  matchLabelKeys:
  - pod-template-hash
  whenTryNextUnits:
    policy: TimeoutOrExceedMax
    timeout: 1m

Champs spec

Champs units

Le type de ressource elastic est obsolète. Utilisez plutôt des pools de nœuds Auto Scaling en définissant k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" dans podLabels .

Le type acs ajoute par défaut les étiquettes alibabacloud.com/compute-class: default et alibabacloud.com/compute-class: general-purpose aux pods. Vous pouvez remplacer ces valeurs en spécifiant des valeurs différentes dans podLabels . Si alpha.alibabacloud.com/compute-qos-strategy est spécifié dans podAnnotations , l'étiquette alibabacloud.com/compute-class: default n'est pas ajoutée.

Les types acs et eci ajoutent par défaut des tolérations pour les taints des nœuds virtuels. Ces tolérations sont ajoutées en interne — elles n'apparaissent pas dans la spécification du pod, et les pods peuvent être planifiés sur des nœuds virtuels sans configuration supplémentaire de tolération.

Si les podLabels d'une unité incluent k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" , ou si le nombre de pods est inférieur à max , le planificateur maintient le pod dans l'unité actuelle jusqu'à ce qu'une condition soit remplie. Définissez la durée d'attente dans whenTryNextUnits . L'étiquette k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" n'est pas appliquée au pod et n'est pas requise pour le comptage des pods.

Champs de configuration avancée

Politiques whenTryNextUnits

Le paramètre timeout s'applique uniquement lorsque policy est défini sur TimeoutOrExceedMax. Valeur par défaut : 15 minutes. Non pris en charge pour les unités ACS (limité uniquement par max).

Prioriser un pool de nœuds par rapport à un autre

Objectif : Déployer un Deployment sur deux pools de nœuds — Pool A en priorité, Pool B en débordement. Lors d'un scale-in, supprimez d'abord les pods du Pool B.

Dans cet exemple, les nœuds cn-beijing.10.0.3.137 et cn-beijing.10.0.3.138 appartiennent au Pool A, tandis que cn-beijing.10.0.6.47 et cn-beijing.10.0.6.46 appartiennent au Pool B. Tous les nœuds disposent de 2 vCPU et de 4 Go de mémoire.

1. Créez une ResourcePolicy définissant l'ordre d'ordonnancement des pools de nœuds. Remplacez les valeurs nodepool-id par les ID réels de vos pools de nœuds, disponibles sur la page Node Management > Node Pools (Créer et gérer un pool de nœuds).

   apiVersion: scheduling.alibabacloud.com/v1alpha1
   kind: ResourcePolicy
   metadata:
     name: nginx
     namespace: default
   spec:
     selector:
       app: nginx # Must match the pod label in the Deployment below
     strategy: prefer
     units:
     - resource: ecs
       nodeSelector:
         alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058****
     - resource: ecs
       nodeSelector:
         alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****

2. Créez un Deployment. L'étiquette du pod app: nginx doit correspondre au selector de la ResourcePolicy.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx # Must match the ResourcePolicy selector
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 2
             requests:
               cpu: 2

3. Appliquez le Deployment et vérifiez le placement des pods.

   1. Appliquez les fichiers YAML.

      kubectl apply -f nginx.yaml

      Résultat attendu :

      deployment.apps/nginx created

   2. Vérifiez sur quels nœuds les pods sont planifiés.

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          17s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-k****   1/1     Running   0          17s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>

      Comme prévu, les deux pods se trouvent sur des nœuds du Pool A.

4. Effectuez un scale-out vers quatre réplicas et vérifiez le débordement vers le Pool B.

   1. Mettez à l'échelle le Deployment.

      kubectl scale deployment nginx --replicas 4

   2. Vérifiez le placement des pods.

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS    RESTARTS   AGE    IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          101s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-k****   1/1     Running   0          101s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>
      nginx-9cdf7bbf9-m****   1/1     Running   0          18s    172.29.113.156   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-x****   1/1     Running   0          18s    172.29.113.89    cn-beijing.10.0.6.46    <none>           <none>

      Les deux nouveaux pods débordent sur les nœuds du Pool B, car le Pool A a atteint sa capacité maximale.

5. Effectuez un scale-in vers deux réplicas et vérifiez que les pods du Pool B sont supprimés en premier.

   1. Mettez à l'échelle le Deployment.

      kubectl scale deployment nginx --replicas 2

   2. Vérifiez l'état des pods.

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running       0          2m41s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-k****   1/1     Running       0          2m41s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>
      nginx-9cdf7bbf9-m****   0/1     Terminating   0          78s     172.29.113.156   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-x****   0/1     Terminating   0          78s     172.29.113.89    cn-beijing.10.0.6.46    <none>           <none>

      Les pods du Pool B sont supprimés en premier, conformément à l'ordre inverse de l'ordonnancement.

Utiliser d'abord ECS Subscription, puis ECS Pay-As-You-Go, avec repli sur ECI

Objectif : Minimiser les coûts en remplissant d'abord la capacité ECS Subscription, puis ECS Pay-As-You-Go, et enfin ECI. Lors d'un scale-in, supprimez les pods dans l'ordre inverse : ECI d'abord, puis ECS Pay-As-You-Go, puis ECS Subscription.

Dans cet exemple, tous les nœuds disposent de 2 vCPU et de 4 Go de mémoire.

1. Étiquetez les nœuds par type de facturation. Si vous utilisez des pools de nœuds, configurez les étiquettes au niveau du pool de nœuds.

   kubectl label node cn-beijing.10.0.3.137 paidtype=subscription
   kubectl label node cn-beijing.10.0.3.138 paidtype=subscription
   kubectl label node cn-beijing.10.0.6.46 paidtype=pay-as-you-go
   kubectl label node cn-beijing.10.0.6.47 paidtype=pay-as-you-go

2. Créez une ResourcePolicy ordonnant les unités par type de facturation.

   apiVersion: scheduling.alibabacloud.com/v1alpha1
   kind: ResourcePolicy
   metadata:
     name: nginx
     namespace: default
   spec:
     selector:
       app: nginx # Must match the pod label in the Deployment below
     strategy: prefer
     units:
     - resource: ecs
       nodeSelector:
         paidtype: subscription
     - resource: ecs
       nodeSelector:
         paidtype: pay-as-you-go
     - resource: eci

3. Créez un Deployment avec deux réplicas.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx # Must match the ResourcePolicy selector
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 2
             requests:
               cpu: 2

4. Appliquez la configuration et vérifiez le placement initial sur les nœuds Subscription.

   1. Appliquez les fichiers YAML.

      kubectl apply -f nginx.yaml

   2. Vérifiez le placement des pods.

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          66s   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          66s   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

      Les deux pods se trouvent sur des nœuds Subscription.

5. Effectuez un scale-out pour vérifier le débordement vers ECS Pay-As-You-Go, puis vers ECI.

   1. Mettez à l'échelle vers quatre réplicas et vérifiez le placement des pods.

      kubectl scale deployment nginx --replicas 4

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS    RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   1/1     Running   0          16s     172.29.113.155   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running   0          3m48s   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-f****   1/1     Running   0          16s     172.29.113.88    cn-beijing.10.0.6.46    <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          3m48s   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

      Les pods en débordement sont planifiés sur des nœuds Pay-As-You-Go.

   2. Mettez à l'échelle vers six réplicas et vérifiez le placement des pods.

      kubectl scale deployment nginx --replicas 6

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS    RESTARTS   AGE     IP               NODE                           NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   1/1     Running   0          3m10s   172.29.113.155   cn-beijing.10.0.6.47           <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running   0          6m42s   172.29.112.215   cn-beijing.10.0.3.137          <none>           <none>
      nginx-9cdf7bbf9-f****   1/1     Running   0          3m10s   172.29.113.88    cn-beijing.10.0.6.46           <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          6m42s   172.29.113.23    cn-beijing.10.0.3.138          <none>           <none>
      nginx-9cdf7bbf9-s****   1/1     Running   0          36s     10.0.6.68        virtual-kubelet-cn-beijing-j   <none>           <none>
      nginx-9cdf7bbf9-v****   1/1     Running   0          36s     10.0.6.67        virtual-kubelet-cn-beijing-j   <none>           <none>

      Toute la capacité ECS étant épuisée, les pods restants sont planifiés sur ECI (nœuds virtual-kubelet).

6. Effectuez un scale-in pour vérifier l'ordre de suppression inverse.

   1. Mettez à l'échelle vers quatre réplicas. Les pods ECI sont supprimés en premier.

      kubectl scale deployment nginx --replicas 4

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                           NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   1/1     Running       0          4m59s   172.29.113.155   cn-beijing.10.0.6.47           <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running       0          8m31s   172.29.112.215   cn-beijing.10.0.3.137          <none>           <none>
      nginx-9cdf7bbf9-f****   1/1     Running       0          4m59s   172.29.113.88    cn-beijing.10.0.6.46           <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running       0          8m31s   172.29.113.23    cn-beijing.10.0.3.138          <none>           <none>
      nginx-9cdf7bbf9-s****   1/1     Terminating   0          2m25s   10.0.6.68        virtual-kubelet-cn-beijing-j   <none>           <none>
      nginx-9cdf7bbf9-v****   1/1     Terminating   0          2m25s   10.0.6.67        virtual-kubelet-cn-beijing-j   <none>           <none>

      Les pods ECI sont supprimés en premier.

   2. Mettez à l'échelle vers deux réplicas. Les pods ECS Pay-As-You-Go sont ensuite supprimés.

      kubectl scale deployment nginx --replicas 2

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   0/1     Terminating   0          6m43s   172.29.113.155   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running       0          10m     172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-f****   0/1     Terminating   0          6m43s   172.29.113.88    cn-beijing.10.0.6.46    <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running       0          10m     172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

   3. Une fois la terminaison achevée, seuls les pods ECS Subscription subsistent.

      kubectl get pods -o wide

      Résultat attendu :

      NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          11m   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          11m   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

Les pods restent bloqués en état Pending après l'application d'une ResourcePolicy

Il se peut que le planificateur n'associe pas la ResourcePolicy aux bons pods. Vérifiez que le selector correspond exactement aux étiquettes des pods de votre charge de travail. Si le sélecteur utilise une étiquette réservée par le système (comme alibabacloud.com/compute-class), le système risque de la modifier, rompant ainsi l'association.

Confirmez également que la version de votre kube-scheduler respecte les exigences minimales pour la version de votre cluster (voir Prérequis).

Le scale-in ne suit pas l'ordre inverse attendu

Cette fonctionnalité fonctionne au mieux. L'ordre de suppression inverse strict n'est pas garanti — par exemple, lorsque la préemption est active ou lorsque plusieurs pods deviennent éligibles à la suppression simultanément.

Si vous avez besoin d'un ordonnancement plus strict, vérifiez le paramètre whenTryNextUnits.policy et envisagez d'utiliser LackResourceAndNoTerminating pour les scénarios de mise à jour progressive.

Conflit entre ResourcePolicy et pod-deletion-cost

Si des annotations pod-deletion-cost sont configurées sur les pods de la même charge de travail, les deux fonctionnalités entrent en conflit. Supprimez les annotations pod-deletion-cost avant d'appliquer une ResourcePolicy.

Le pool de nœuds crée des nœuds inattendus lorsqu'il est utilisé avec des pools de nœuds élastiques

Lorsqu'un pool de nœuds Auto Scaling se trouve dans une unité avec max défini, le Cluster Autoscaler peut créer plus de nœuds que la valeur max car il ne lit pas la limite max depuis la ResourcePolicy. Pour éviter cela, incluez le pool de nœuds élastique dans une unité et ne définissez pas max pour cette unité.