Implementar dimensionamento de carga de trabalho com o controlador UnitedDeployment fornecido pelo Kruise - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

O recurso personalizado UnitedDeployment do OpenKruise gerencia múltiplas cargas de trabalho homogêneas como um único objeto ao agrupá-las em unidades chamadas Subsets. Em vez de manter arquivos YAML separados para cada Deployment ou StatefulSet, defina um único UnitedDeployment com um Subset por grupo de destino. O controlador cuida do agendamento, das atualizações e da distribuição de réplicas entre todos os subsets.

Em conjunto com o Horizontal Pod Autoscaler (HPA), o UnitedDeployment permite o dimensionamento ordenado em recursos computacionais mistos: os pods escalam horizontalmente do recurso mais barato para o mais caro e reduzem na ordem inversa, o que otimiza custos automaticamente.

Para a referência completa da API, consulte a documentação do UnitedDeployment no site do OpenKruise.

Tipos de carga de trabalho suportados

O UnitedDeployment suporta StatefulSet, Advanced StatefulSet, CloneSet e Deployment. Para mais detalhes, consulte Usar o OpenKruise para implantar aplicações nativas da nuvem.

Pré-requisitos

Antes de começar, verifique se você possui:

O add-on ack-kruise instalado. Para mais informações, consulte Gerenciar add-ons
O add-on ACK Virtual Node, pré-instalado com o ECI. Para mais informações, consulte Gerenciar add-ons
Um cliente kubectl conectado ao cluster ACK. Para mais informações, consulte Obter o kubeconfig do cluster e conectar-se usando kubectl

Casos de uso

Este tópico aborda três cenários comuns:

Dimensionamento ordenado com recursos mistos — Use o HPA para escalar pods entre instâncias ECS por assinatura, instâncias spot e ECIs seguindo uma ordem de prioridade.
Implantação multizona — Distribua pods por várias zonas de disponibilidade para garantir alta disponibilidade.
Colocação de ECS e ECI — Priorize instâncias do Elastic Compute Service (ECS) no agendamento e utilize ECIs como overflow durante picos de tráfego.

Cenário 1: Usar UnitedDeployment com HPA para dimensionamento ordenado

Importante

É necessário ter o OpenKruise 1.5.0. Para mais informações, consulte as Notas de versão do OpenKruise.

Quando um cluster possui vários tipos de nó, configure um Subset por tipo de recurso no YAML do UnitedDeployment. Use o campo maxReplicas para limitar o número de pods em cada subset. Ao acionar o dimensionamento via HPA, o controlador preenche os subsets na ordem listada: escala horizontalmente do primeiro para o último subset e reduz na ordem inversa.

Para integrar o HPA, defina scaleTargetRef na especificação do HPA apontando para o UnitedDeployment (e não para o Deployment subjacente).

Regras de dimensionamento:

Scale-up: o preenchimento dos subsets segue a ordem definida em topology.subsets.
Scale-down: a remoção dos pods ocorre na ordem inversa (o último subset primeiro).

Este exemplo configura um cluster com dois pools de nós: Pool de Nós A (instâncias ECS por assinatura) e Pool de Nós B (instâncias spot). A prioridade de agendamento é: instância ECS por assinatura > instância spot > ECI. Se os nós de um tipo com maior prioridade estiverem indisponíveis, o controlador utilizará o próximo tipo disponível.

Crie o arquivo test.yaml com o conteúdo abaixo. O arquivo define um UnitedDeployment usando um deploymentTemplate. Três subsets estão configurados:

subset-a: 1 réplica no Pool de Nós A (instâncias ECS por assinatura), selecionada pelo rótulo de ID do pool de nós.
subset-b: 1 réplica no Pool de Nós B (instâncias spot), selecionada pelo rótulo de ID do pool de nós.
subset-c: 3 réplicas em nós virtuais ECI, selecionadas pelo rótulo type=virtual-kubelet e tolerância correspondente.

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

Implante o UnitedDeployment:

kubectl apply -f test.yaml

Saída esperada:

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

Verifique se os pods estão em execução nos nós corretos:

kubectl get pod -o wide

Saída 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>

Os pods estão distribuídos pelos três subsets conforme definido na topologia.

Cenário 2: Implantar aplicações em várias zonas de disponibilidade

A implantação em múltiplas zonas protege as aplicações contra falhas no nível da zona. Rotule cada nó com sua respectiva zona e configure um Subset por zona usando seletores de rótulo. O controlador agenda os pods de cada subset na zona correspondente.

Rotule cada nó com sua zona. Os comandos a seguir adicionam rótulos de zona a três nós em diferentes zonas de disponibilidade:

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.

Crie o arquivo test.yaml com o conteúdo abaixo. O arquivo define um UnitedDeployment usando um statefulSetTemplate. A seção subsets mapeia cada zona para um subset:

subset-a: 1 réplica no nó rotulado como node=zone-a.
subset-b: 50% do total de réplicas no nó rotulado como node=zone-b.
subset-c: réplicas restantes (sem contagem explícita) no nó rotulado como 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

Implante o UnitedDeployment:

kubectl apply -f test.yaml

Saída esperada:

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

Verifique se os pods e StatefulSets foram criados nas três zonas:

kubectl get pod

Saída 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

Saída 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

Os pods e StatefulSets estão em execução em nós nas Zonas A, B e C.

Cenário 3: Colocar aplicações em instâncias ECS e ECIs

Durante picos de tráfego, é essencial equilibrar disponibilidade de recursos e controle de custos. O UnitedDeployment resolve isso ao priorizar instâncias ECS no agendamento e direcionar automaticamente o excesso para ECIs quando a capacidade do ECS se esgota. Na redução de escala, o controlador remove os pods ECI antes dos pods ECS.

O exemplo a seguir configura um UnitedDeployment com dois subsets: um para instâncias ECS (limitado a 4 réplicas) e outro para ECIs (ilimitado). Um HPA ajusta o número total de réplicas entre 4 e 10 com base na utilização da CPU.

Comportamento de agendamento:

Total de réplicas até 4: todos os pods rodam em instâncias ECS.
Total de réplicas entre 4 e 10: os pods excedentes rodam em ECIs.
Na redução de escala: os pods ECI são removidos antes dos pods ECS.

Crie o arquivo test.yaml com o conteúdo abaixo. O arquivo define um UnitedDeployment com um deploymentTemplate e dois subsets, seguido por um HPA direcionado ao UnitedDeployment:

Subset ecs: maxReplicas: 4 — absorve até 4 pods.
Subset eci: maxReplicas: null — absorve quaisquer pods restantes.
HPA: aponta diretamente para o UnitedDeployment, com minReplicas: 4 e 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

Implante o UnitedDeployment e o HPA:

kubectl apply -f test.yaml

Saída esperada:

horizontalpodautoscaler.autoscaling/united-deployment-hpa created

Verifique a distribuição dos pods:

kubectl get pod -o wide

Saída 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>

As primeiras 4 réplicas estão em instâncias ECS; as 2 restantes estão em ECIs.

Após o HPA acionar uma redução de escala, verifique se os pods ECI foram removidos primeiro:

kubectl get pod -o wide

Saída 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>

O número de réplicas foi reduzido de 6 para 4. Ambos os pods ECI foram removidos; todos os 4 pods restantes rodam em instâncias ECS.

Próximos passos

Para adicionar nós em várias zonas durante o scale-out, consulte Implementar dimensionamento rápido em múltiplas zonas.
Para dimensionamento automático de nós quando a capacidade do cluster não atender aos requisitos de agendamento de pods, consulte Dimensionamento de nós.