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

UnitedDeployment es un recurso personalizado de OpenKruise que gestiona múltiples cargas de trabajo homogéneas como un solo objeto al agruparlas en unidades denominadas Subsets. En lugar de mantener archivos YAML separados para cada Deployment o StatefulSet, defina un único UnitedDeployment con un Subset por grupo objetivo; el controlador se encarga de la programación, las actualizaciones y la distribución de réplicas en todos los subconjuntos.

En combinación con Horizontal Pod Autoscaler (HPA), UnitedDeployment permite un escalado ordenado en recursos de cómputo mixtos: los pods se escalan horizontalmente desde los más económicos hasta los más costosos, y se reducen en orden inverso, lo que optimiza los costos de forma automática.

Para consultar la referencia completa de la API, visite la documentación de UnitedDeployment en el sitio web de OpenKruise.

Tipos de carga de trabajo compatibles

UnitedDeployment es compatible con StatefulSet, Advanced StatefulSet, CloneSet y Deployment. Para obtener más detalles, consulte Uso de OpenKruise para desplegar aplicaciones nativas de la nube.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

El complemento ack-kruise instalado. Para obtener más información, consulte Manage add-ons
El complemento ACK Virtual Node, que viene preinstalado con ECI. Para obtener más información, consulte Manage add-ons
Un cliente kubectl conectado al clúster de ACK. Para obtener más información, consulte Obtención del kubeconfig del clúster y conexión mediante kubectl

Casos de uso

Este tema aborda tres escenarios comunes:

Escalado ordenado con recursos mixtos: utilice HPA para escalar pods entre instancias ECS de suscripción, instancias spot e instancias ECI según un orden de prioridad.
Despliegue multizona: distribuya los pods en varias zonas de disponibilidad para garantizar alta disponibilidad.
Coubicación de ECS y ECI: priorice las instancias de Elastic Compute Service (ECS) para la programación y desborde hacia instancias ECI durante los picos de tráfico.

Escenario 1: Uso de UnitedDeployment con HPA para escalado ordenado

Importante

Se requiere OpenKruise 1.5.0. Para obtener más información, consulte las notas de versión de OpenKruise.

Cuando un clúster cuenta con varios tipos de nodos, configure un Subset por tipo de recurso en el archivo YAML de UnitedDeployment. Utilice el campo maxReplicas para limitar el número de pods en cada subconjunto. Cuando HPA activa el escalado, el controlador llena los subconjuntos en el orden indicado: escala horizontalmente desde el primero hasta el último, y reduce en orden inverso.

Para integrar HPA, establezca scaleTargetRef en la especificación de HPA para que apunte a UnitedDeployment (no al Deployment subyacente).

Reglas de escalado:

Escalado horizontal: los subconjuntos se llenan en el orden definido en topology.subsets.
Reducción: los pods se eliminan en orden inverso (primero el último subconjunto).

Este ejemplo configura un clúster con dos node pools: Node Pool A (instancias ECS de suscripción) y Node Pool B (instancias spot). La prioridad de programación es: instancia ECS de suscripción > instancia spot > ECI. Cuando los nodos de un tipo de mayor prioridad no están disponibles, el controlador recurre al siguiente tipo.

Cree el archivo test.yaml con el siguiente contenido. El archivo define un UnitedDeployment mediante una deploymentTemplate. Se configuran tres subconjuntos:

subset-a: 1 réplica en el Node Pool A (instancias ECS de suscripción), seleccionada mediante la etiqueta de ID del node pool.
subset-b: 1 réplica en el Node Pool B (instancias spot), seleccionada mediante la etiqueta de ID del node pool.
subset-c: 3 réplicas en nodos virtuales ECI, seleccionadas mediante la etiqueta type=virtual-kubelet y su tolerancia correspondiente.

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

Despliegue el UnitedDeployment:

kubectl apply -f test.yaml

Salida esperada:

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

Compruebe que los pods se estén ejecutando en los nodos correctos:

kubectl get pod -o wide

Salida esperada:

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>

Los pods se distribuyen en los tres subconjuntos tal como se definió en la topología.

Escenario 2: Despliegue de aplicaciones en varias zonas de disponibilidad

El despliegue en varias zonas de disponibilidad protege las aplicaciones ante fallos a nivel de zona. Asigne una etiqueta de zona a cada nodo y configure un Subset por zona mediante selectores de etiquetas. El controlador programa los pods de cada subconjunto en la zona correspondiente.

Asigne una etiqueta de zona a cada nodo. Los siguientes comandos agregan etiquetas de zona a tres nodos en distintas zonas de disponibilidad:

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.

Cree el archivo test.yaml con el siguiente contenido. El archivo define un UnitedDeployment mediante una statefulSetTemplate. La sección subsets asigna cada zona a un subconjunto:

subset-a: 1 réplica en el nodo con la etiqueta node=zone-a.
subset-b: 50 % del total de réplicas en el nodo con la etiqueta node=zone-b.
subset-c: réplicas restantes (sin conteo explícito) en el nodo con la etiqueta 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

Despliegue el UnitedDeployment:

kubectl apply -f test.yaml

Salida esperada:

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

Compruebe que los pods y los StatefulSets se hayan creado en las tres zonas:

kubectl get pod

Salida esperada:

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

Salida esperada:

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

Los pods y los StatefulSets se están ejecutando en nodos de la Zona A, Zona B y Zona C.

Escenario 3: Coubicación de aplicaciones en instancias ECS e instancias ECI

Durante los picos de tráfico, se requiere tanto disponibilidad de recursos como control de costos. UnitedDeployment resuelve esta necesidad al priorizar las instancias ECS para la programación y desbordar automáticamente hacia instancias ECI cuando se agota la capacidad de ECS. Durante la reducción, el controlador elimina primero los pods de ECI antes que los de ECS.

El siguiente ejemplo configura un UnitedDeployment con dos subconjuntos: uno para instancias ECS (limitado a 4 réplicas) y otro para instancias ECI (sin límite). Un HPA ajusta el número total de réplicas entre 4 y 10 según la utilización de CPU.

Comportamiento de programación:

Cuando el total de réplicas es 4 o menos: todos los pods se ejecutan en instancias ECS.
Cuando el total de réplicas está entre 4 y 10: los pods excedentes se ejecutan en instancias ECI.
Durante la reducción: los pods de ECI se eliminan antes que los de ECS.

Cree el archivo test.yaml con el siguiente contenido. El archivo define un UnitedDeployment con una deploymentTemplate y dos subconjuntos, seguido de un HPA que apunta al UnitedDeployment:

Subconjunto ecs: maxReplicas: 4 — absorbe hasta 4 pods.
Subconjunto eci: maxReplicas: null — absorbe los pods restantes.
HPA: apunta directamente al UnitedDeployment, con minReplicas: 4 y 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

Despliegue el UnitedDeployment y el HPA:

kubectl apply -f test.yaml

Salida esperada:

horizontalpodautoscaler.autoscaling/united-deployment-hpa created

Verifique la distribución de los pods:

kubectl get pod -o wide

Salida esperada:

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>

Las primeras 4 réplicas se encuentran en instancias ECS; las 2 restantes están en instancias ECI.

Una vez que el HPA active una reducción, compruebe que los pods de ECI se eliminen primero:

kubectl get pod -o wide

Salida esperada:

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>

El número de réplicas se redujo de 6 a 4. Ambos pods de ECI se eliminaron; los 4 pods restantes se ejecutan en instancias ECS.

Pasos siguientes

Para agregar nodos en distintas zonas durante el escalado horizontal, consulte Implementación de escalado rápido en múltiples zonas.
Para el escalado automático de nodos cuando la capacidad del clúster no satisface los requisitos de programación de pods, consulte Escalado de nodos.