Implement workload scaling based on the UnitedDeployment controller provided by Kruise - Container Service for Kubernetes

UnitedDeployment est une ressource personnalisée OpenKruise qui gère plusieurs charges de travail homogènes comme un seul objet en les regroupant dans des unités appelées Subsets. Au lieu de maintenir des fichiers YAML distincts pour chaque Deployment ou StatefulSet, définissez un unique UnitedDeployment avec un Subset par groupe cible : le contrôleur se charge de l'ordonnancement, des mises à jour et de la répartition des réplicas entre tous les sous-ensembles.

Associé à l'Horizontal Pod Autoscaler (HPA), UnitedDeployment permet une mise à l'échelle ordonnée sur des ressources de calcul hétérogènes : les pods sont créés du moins coûteux au plus coûteux, et supprimés dans l'ordre inverse, optimisant ainsi automatiquement les coûts.

Pour consulter la référence API complète, reportez-vous à la documentation UnitedDeployment sur le site web d'OpenKruise.

Types de charges de travail pris en charge

UnitedDeployment prend en charge StatefulSet, Advanced StatefulSet, CloneSet et Deployment. Pour plus de détails, consultez la rubrique Utiliser OpenKruise pour déployer des applications cloud natives.

Prérequis

Avant de commencer, assurez-vous d'avoir :

Le module complémentaire ack-kruise installé. Pour plus d'informations, consultez la rubrique Gérer les modules complémentaires
Le module complémentaire ACK Virtual Node, fourni par défaut avec ECI. Pour plus d'informations, consultez la rubrique Gérer les modules complémentaires
Un client kubectl connecté au cluster ACK. Pour plus d'informations, consultez la rubrique Obtenir le fichier kubeconfig d'un cluster et s'y connecter avec kubectl

Cas d'utilisation

Cette rubrique couvre trois scénarios courants :

Mise à l'échelle ordonnée avec des ressources mixtes — Utilisez HPA pour mettre à l'échelle les pods sur des instances ECS en abonnement, des instances spot et des ECI, selon un ordre de priorité.
Déploiement inter-zones — Répartissez les pods sur plusieurs zones de disponibilité pour garantir une haute disponibilité.
Colocalisation ECS et ECI — Privilégiez les instances Elastic Compute Service (ECS) pour l'ordonnancement et basculez vers les ECI en cas de pics de trafic.

Scénario 1 : Utiliser UnitedDeployment avec HPA pour une mise à l'échelle ordonnée

Important

OpenKruise 1.5.0 est requis. Pour plus d'informations, consultez les notes de version d'OpenKruise.

Lorsqu'un cluster comporte plusieurs types de nœuds, configurez un Subset par type de ressource dans le fichier YAML UnitedDeployment. Utilisez le champ maxReplicas pour limiter le nombre de pods sur chaque sous-ensemble. Lorsque HPA déclenche une mise à l'échelle, le contrôleur remplit les sous-ensembles dans l'ordre indiqué : la montée en charge s'effectue du premier au dernier sous-ensemble, tandis que la descente en charge suit l'ordre inverse.

Pour intégrer HPA, définissez scaleTargetRef dans la spécification HPA afin de cibler UnitedDeployment (et non le Deployment sous-jacent).

Règles de mise à l'échelle :

Montée en charge : les sous-ensembles sont remplis selon l'ordre défini dans topology.subsets.
Descente en charge : les pods sont supprimés dans l'ordre inverse (le dernier sous-ensemble en premier).

Cet exemple configure un cluster doté de deux pools de nœuds : le pool A (instances ECS en abonnement) et le pool B (instances spot). La priorité d'ordonnancement est la suivante : instance ECS en abonnement > instance spot > ECI. Si les nœuds d'un type prioritaire ne sont pas disponibles, le contrôleur bascule vers le type suivant.

Créez le fichier test.yaml avec le contenu suivant. Le fichier définit un UnitedDeployment utilisant un deploymentTemplate. Trois sous-ensembles sont configurés :

subset-a : 1 réplica sur le pool de nœuds A (instances ECS en abonnement), sélectionné via l'étiquette ID du pool de nœuds.
subset-b : 1 réplica sur le pool de nœuds B (instances spot), sélectionné via l'étiquette ID du pool de nœuds.
subset-c : 3 réplicas sur les nœuds virtuels ECI, sélectionnés via l'étiquette type=virtual-kubelet et une tolérance.

apiVersion: apps.kruise.io/v1alpha1
kind: UnitedDeployment
metadata:
  name: ud-nginx
spec:
  replicas: 6
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: ud-nginx
  template:
    deploymentTemplate:
      metadata:
        labels:
          app: ud-nginx
      spec:
        selector:
          matchLabels:
            app: ud-nginx
        template:
          metadata:
            labels:
              app: ud-nginx
          spec:
            containers:
            - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0
              name: nginx
  topology:
    subsets:
    - name: subset-a
      nodeSelectorTerm:
        matchExpressions:
        - key: alibabacloud.com/nodepool-id
          operator: In
          values:
          - np92019eec42004d878fcdc990fcb9****   # Replace with the ID of Node Pool A.
      replicas: 1
    - name: subset-b
      nodeSelectorTerm:
        matchExpressions:
        - key: alibabacloud.com/nodepool-id
          operator: In
          values:
          - np011de1f2de3d48bd8a92a015fc5c****  # Replace with the ID of Node Pool B.
      replicas: 1
    - name: subset-c
      nodeSelectorTerm:
        matchExpressions:
        - key: type
          operator: In
          values:
          - virtual-kubelet
      tolerations:
      - key: virtual-kubelet.io/provider
        operator: Exists
      replicas: 3
  updateStrategy:
    manualUpdate:
      partitions:
        subset-a: 0
        subset-b: 0
        subset-c: 0
    type: Manual

Déployez le UnitedDeployment :

kubectl apply -f test.yaml

Résultat attendu :

uniteddeployment.apps.kruise.io/ud-nginx created

Vérifiez que les pods s'exécutent sur les nœuds appropriés :

kubectl get pod -o wide

Résultat attendu :

NAME                                       READY   STATUS    RESTARTS   AGE   IP               NODE                            NOMINATED NODE   READINESS GATES
ud-nginx-subset-a-7lbtd-5b5bd77549-5bw6l   1/1     Running   0          73s   192.XX.XX.126    cn-hangzhou.10.XX.XX.131       <none>           <none>
ud-nginx-subset-b-nvvfw-5c9bcd6766-lv6sp   1/1     Running   0          73s   192.XX.XX.239    cn-hangzhou.10.XX.XX.132      <none>           <none>
ud-nginx-subset-c-m78fd-7796b66fd8-7p52j   1/1     Running   0          73s   192.XX.XX.130    virtual-kubelet-cn-hangzhou-h   <none>           <none>
ud-nginx-subset-c-m78fd-7796b66fd8-fd7f7   1/1     Running   0          73s   192.XX.XX.129    virtual-kubelet-cn-hangzhou-h   <none>           <none>
ud-nginx-subset-c-m78fd-7796b66fd8-mn4qb   1/1     Running   0          73s   192.XX.XX.131    virtual-kubelet-cn-hangzhou-h   <none>           <none>

Les pods sont répartis sur les trois sous-ensembles tels que définis dans la topologie.

Scénario 2 : Déployer des applications sur plusieurs zones de disponibilité

Le déploiement sur plusieurs zones de disponibilité protège les applications contre les pannes au niveau d'une zone. Étiquetez chaque nœud avec sa zone, puis configurez un Subset par zone à l'aide de sélecteurs d'étiquettes. Le contrôleur planifie les pods de chaque sous-ensemble dans la zone correspondante.

Étiquetez chaque nœud avec sa zone. Les commandes suivantes ajoutent des étiquettes de zone à trois nœuds situés dans différentes zones de disponibilité :

kubectl label node cn-beijing.10.XX.XX.131 node=zone-a
node/cn-beijing.10.80.20.131 labeled # Adds node=zone-a to node 10.XX.XX.131.
kubectl label node cn-beijing.10.XX.XX.132 node=zone-b
node/cn-beijing.10.80.20.132 labeled  # Adds node=zone-b to node 10.XX.XX.132.
kubectl label node cn-beijing.10.XX.XX.133 node=zone-c
node/cn-beijing.10.80.20.133 labeled  # Adds node=zone-c to node 10.XX.XX.133.

Créez le fichier test.yaml avec le contenu suivant. Le fichier définit un UnitedDeployment utilisant un statefulSetTemplate. La section subsets associe chaque zone à un sous-ensemble :

subset-a : 1 réplica sur le nœud étiqueté node=zone-a.
subset-b : 50 % du total des réplicas sur le nœud étiqueté node=zone-b.
subset-c : les réplicas restants (sans comptage explicite) sur le nœud étiqueté node=zone-c.

apiVersion: apps.kruise.io/v1alpha1
kind: UnitedDeployment
metadata:
  name: sample-ud
spec:
  replicas: 6
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: sample
  template:
    statefulSetTemplate:
      metadata:
        labels:
          app: sample
      spec:
        selector:
          matchLabels:
            app: sample
        template:
          metadata:
            labels:
              app: sample
          spec:
            containers:
            - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0
              name: nginx
  topology:
    subsets:
    - name: subset-a
      nodeSelectorTerm:
        matchExpressions:
        - key: node
          operator: In
          values:
          - zone-a
      replicas: 1
    - name: subset-b
      nodeSelectorTerm:
        matchExpressions:
        - key: node
          operator: In
          values:
          - zone-b
      replicas: 50%
    - name: subset-c
      nodeSelectorTerm:
        matchExpressions:
        - key: node
          operator: In
          values:
          - zone-c
  updateStrategy:
    manualUpdate:
      partitions:
        subset-a: 0
        subset-b: 0
        subset-c: 0
    type: Manual

Déployez le UnitedDeployment :

kubectl apply -f test.yaml

Résultat attendu :

uniteddeployment.apps.kruise.io/sample-ud created

Vérifiez que les pods et les StatefulSets sont créés dans les trois zones :

kubectl get pod

Résultat attendu :

NAME                                     READY   STATUS    RESTARTS   AGE
sample-ud-subset-a-cplwg-0               1/1     Running   0          6m5s
sample-ud-subset-b-rj7kt-0               1/1     Running   0          6m4s
sample-ud-subset-b-rj7kt-1               1/1     Running   0          5m49s
sample-ud-subset-b-rj7kt-2               1/1     Running   0          5m43s
sample-ud-subset-c-g6jvx-0               1/1     Running   0          6m5s
sample-ud-subset-c-g6jvx-1               1/1     Running   0          5m51s

kubectl get statefulset

Résultat attendu :

NAME                       READY   AGE
sample-ud-subset-a-cplwg   1/1     7m34s
sample-ud-subset-b-rj7kt   3/3     7m34s
sample-ud-subset-c-g6jvx   2/2     7m34s

Les pods et les StatefulSets s'exécutent sur des nœuds dans la zone A, la zone B et la zone C.

Scénario 3 : Colocaliser des applications sur des instances ECS et des ECI

Lors des pics de trafic, vous devez garantir à la fois la disponibilité des ressources et la maîtrise des coûts. UnitedDeployment répond à ce besoin en privilégiant les instances ECS pour l'ordonnancement et en basculant automatiquement vers les ECI lorsque la capacité ECS est saturée. Lors de la réduction de capacité, le contrôleur supprime d'abord les pods ECI avant les pods ECS.

L'exemple suivant configure un UnitedDeployment avec deux sous-ensembles : l'un pour les instances ECS (limité à 4 réplicas) et l'autre pour les ECI (illimité). Un HPA ajuste le nombre total de réplicas entre 4 et 10 en fonction de l'utilisation du CPU.

Comportement d'ordonnancement :

Lorsque le nombre total de réplicas est inférieur ou égal à 4 : tous les pods s'exécutent sur des instances ECS.
Lorsque le nombre total de réplicas est compris entre 4 et 10 : les pods excédentaires s'exécutent sur des ECI.
Lors de la réduction de capacité : les pods ECI sont supprimés avant les pods ECS.

Créez le fichier test.yaml avec le contenu suivant. Le fichier définit un UnitedDeployment avec un deploymentTemplate et deux sous-ensembles, suivi d'un HPA ciblant le UnitedDeployment :

Sous-ensemble ecs : maxReplicas: 4 — accepte jusqu'à 4 pods.
Sous-ensemble eci : maxReplicas: null — accepte tous les pods restants.
HPA : cible directement le UnitedDeployment, avec minReplicas: 4 et maxReplicas: 10.

apiVersion: apps.kruise.io/v1alpha1
kind: UnitedDeployment
metadata:
  name: ud-nginx
spec:
  replicas: 6
  selector:
    matchLabels:
      app: sample
  template:
  # statefulSetTemplate or advancedStatefulSetTemplate or cloneSetTemplate or deploymentTemplate
    deploymentTemplate:
      metadata:
        labels:
          app: sample
      spec:
        selector:
          matchLabels:
            app: sample
        template:
          metadata:
            labels:
              app: sample
          spec:
            containers:
            - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0
              name: nginx
              resources:
                requests:
                  cpu: "500m"
  topology:
    subsets:
    - name: ecs
      maxReplicas: 4
    - name: eci
      maxReplicas: null

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: united-deployment-hpa
spec:
  scaleTargetRef:
    apiVersion: apps.kruise.io/v1alpha1
    kind: UnitedDeployment
    name: ud-nginx  # Replace with the name of the UnitedDeployment.
  minReplicas: 4
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Déployez le UnitedDeployment et le HPA :

kubectl apply -f test.yaml

Résultat attendu :

horizontalpodautoscaler.autoscaling/united-deployment-hpa created

Vérifiez la répartition des pods :

kubectl get pod -o wide

Résultat attendu :

NAME                                  READY   STATUS    RESTARTS       AGE   IP               NODE                       NOMINATED NODE   READINESS GATES
ud-nginx-eci-dxfbz-864bdb77b-2d4t9    1/1     Running   0             3m9s   192.XX.XX.129   cn-hangzhou.192.XX.XX.120   <none>           <none>
ud-nginx-eci-dxfbz-864bdb77b-zppfh    1/1     Running   0             3m9s   192.XX.XX.11    cn-hangzhou.192.XX.XX.251   <none>           <none>
ud-nginx-ecs-5lm7r-868c4ccd5d-5mlgh   1/1     Running   0             3m9s   192.XX.XX.4     cn-hangzhou.192.XX.XX.251   <none>           <none>
ud-nginx-ecs-5lm7r-868c4ccd5d-6bdkz   1/1     Running   0             3m9s   192.XX.XX.145   cn-hangzhou.192.XX.XX.32    <none>           <none>
ud-nginx-ecs-5lm7r-868c4ccd5d-dnsfl   1/1     Running   0             3m9s   192.XX.XX.150   cn-hangzhou.192.XX.XX.20    <none>           <none>
ud-nginx-ecs-5lm7r-868c4ccd5d-mrzwc   1/1     Running   0             3m9s   192.XX.XX.128   cn-hangzhou.192.XX.XX.120   <none>           <none>

Les 4 premiers réplicas s'exécutent sur des instances ECS ; les 2 restants s'exécutent sur des ECI.

Après le déclenchement d'une réduction de capacité par le HPA, vérifiez que les pods ECI sont supprimés en premier :

kubectl get pod -o wide

Résultat attendu :

NAME                                  READY   STATUS    RESTARTS       AGE    IP              NODE                        NOMINATED NODE   READINESS GATES
ud-nginx-ecs-5lm7r-868c4ccd5d-5mlgh   1/1     Running   0             8m14s   192.168.8.4     cn-hangzhou.192.168.8.251   <none>           <none>
ud-nginx-ecs-5lm7r-868c4ccd5d-6bdkz   1/1     Running   0             8m14s   192.168.6.145   cn-hangzhou.192.168.6.32    <none>           <none>
ud-nginx-ecs-5lm7r-868c4ccd5d-dnsfl   1/1     Running   0             8m14s   192.168.6.150   cn-hangzhou.192.168.6.20    <none>           <none>
ud-nginx-ecs-5lm7r-868c4ccd5d-mrzwc   1/1     Running   0             8m14s   192.168.5.128   cn-hangzhou.192.168.5.120   <none>           <none>

Le nombre de réplicas est passé de 6 à 4. Les deux pods ECI ont été supprimés ; les 4 pods restants s'exécutent tous sur des instances ECS.

Étapes suivantes

Pour ajouter des nœuds sur plusieurs zones lors d'une montée en charge, consultez la rubrique Implémenter une mise à l'échelle rapide sur plusieurs zones.
Pour la mise à l'échelle automatique des nœuds lorsque la capacité du cluster ne peut pas satisfaire les exigences d'ordonnancement des pods, consultez la rubrique Mise à l'échelle des nœuds.