Todos os produtos
Search

Este produto

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

    Central de documentação

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

    Última atualização: Sep 21, 2026

    O agendamento personalizado por prioridade para recursos elásticos permite definir a ordem de agendamento dos pods em diferentes tipos de recursos e node pools. Crie um ResourcePolicy para estabelecer essa ordem: durante o scale-out, o sistema agenda os pods nas unidades de recurso na sequência definida; durante o scale-in, a remoção ocorre na ordem inversa.

    Aviso

    Não use rótulos reservados pelo sistema, como alibabacloud.com/compute-class ou alibabacloud.com/compute-qos, nos seletores de rótulos da carga de trabalho (por exemplo, o campo spec.selector.matchLabels de um Deployment). O sistema pode modificar esses rótulos durante o agendamento por prioridade. Essa modificação causa reconstruções frequentes de pods e afeta a estabilidade.

    Pré-requisitos

    Certifique-se de atender aos seguintes requisitos:

    • Um cluster gerenciado ACK Pro edition, versão 1.20.11 ou posterior (Atualize manualmente um cluster).

    • Uma versão do kube-scheduler compatível com a versão do seu cluster ACK (kube-scheduler).

      Versão do ACK

      Versão do scheduler

      1.20

      v1.20.4-ack-7.0 ou posterior

      1.22

      v1.22.15-ack-2.0 ou posterior

      1.24 ou posterior

      Todas as versões suportadas

    • (Obrigatório para recursos ECI) O add-on ack-virtual-node está implantado no seu cluster ack-virtual-node o componente está implantado no seu cluster (Use ECI in ACK).

    Notas de uso

    • Ordenação de melhor esforço: Este recurso usa uma política BestEffort. A redução de escala (scale-in) de pods não segue estritamente a ordem inversa do agendamento em todos os casos.

    • A partir da versão v1.x.x-aliyun-6.4 do scheduler, o valor padrão de ignorePreviousPod mudou para false e o de ignoreTerminatingPod para true. Os objetos ResourcePolicy existentes e as atualizações subsequentes não sofrem impacto.

    • Este recurso entra em conflito com o pod-deletion-cost e não é possível usá-los em conjunto.

    • Não é possível usar este recurso com o agendamento elástico do Elastic Container Instance (ECI) por meio do ElasticResource (Use ElasticResource for elastic scheduling of ECI pods).

    • O campo max está disponível apenas em clusters da versão 1.22 ou posterior com o scheduler na versão 5.0 ou posterior.

    • Quando usado com node pools elásticos, este recurso pode levar os node pools a criar nós inválidos. Para evitar isso, inclua o node pool elástico em uma unidade e não defina max para essa unidade.

    • Se a versão do seu scheduler for anterior à 5.0 ou a versão do seu cluster for 1.20 ou anterior, os pods existentes antes da criação do ResourcePolicy são os primeiros a sofrer scale-in.

    • Se a versão do seu scheduler for anterior à 6.1 ou a versão do seu cluster for 1.20 ou anterior, não modifique um ResourcePolicy até que todos os pods associados estejam completamente excluídos.

    • Ao usar este recurso com auto-scaling, é necessário utilizar elasticidade instantânea. Caso contrário, o Cluster Autoscaler pode acionar um dimensionamento incorreto do node pool.

    Crie um ResourcePolicy

    Defina um ResourcePolicy com esta estrutura YAML:

    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

    Campos de spec

    Campo

    Descrição

    selector

    Seleciona pods com rótulos correspondentes no mesmo namespace. Se estiver vazio, corresponde a todos os pods.

    strategy

    Estratégia de agendamento. Somente prefer é compatível.

    units

    Lista ordenada de unidades de agendamento. O scale-out segue a ordem da lista; o scale-in a inverte.

    Campos de units

    Campo

    Descrição

    resource

    Tipo de recurso. Valores válidos: ecs, eci, elastic (clusters 1.24+ com scheduler 6.4.3+), acs (clusters 1.26+ com scheduler 6.7.1+).

    nodeSelector

    Seleciona nós nesta unidade por rótulo.

    max

    Número máximo de réplicas de pods para esta unidade. Disponível no scheduler 5.0+.

    maxResources

    Recursos máximos para pods nesta unidade. Disponível no scheduler 6.9.5+.

    podLabels

    Rótulos adicionados aos pods agendados para esta unidade. O sistema contabiliza apenas pods com esses rótulos para esta unidade.

    podAnnotations

    Anotações adicionadas aos pods agendados para esta unidade. O sistema contabiliza apenas pods com essas anotações para esta unidade.
    O tipo de recurso elastic está em processo de descontinuação. Em vez disso, use node pools com auto-scaling definindo k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" em podLabels .
    O tipo acs adiciona os rótulos alibabacloud.com/compute-class: default e alibabacloud.com/compute-class: general-purpose aos pods por padrão. Substitua-os especificando valores diferentes em podLabels . Se alpha.alibabacloud.com/compute-qos-strategy for especificado em podAnnotations , o sistema não adiciona o rótulo alibabacloud.com/compute-class: default .
    Os tipos acs e eci adicionam tolerâncias para taints de nós virtuais por padrão. O sistema as adiciona internamente — elas não aparecem na spec do pod, e é possível agendar os pods para nós virtuais sem configuração adicional de tolerância.
    Importante

    Em versões do scheduler anteriores à 6.8.3, não é possível usar várias unidades acs simultaneamente.

    Se os podLabels de uma unidade incluírem k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" , ou se a contagem de pods for menor que max , o scheduler mantém o pod na unidade atual até o atendimento de uma condição. Defina a duração da espera em whenTryNextUnits . O sistema não aplica o rótulo k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" ao pod, e ele não é necessário para a contagem de pods.

    Campos de configuração avançada

    Campo

    Disponível a partir de

    Descrição

    preemptPolicy

    Scheduler v6.1

    Controla quando o sistema tenta a preempção entre as unidades. BeforeNextUnit: tenta a preempção sempre que uma unidade falha. AfterAllUnits (padrão): tenta a preempção apenas após a falha de todas as unidades. Não se aplica ao ACS (Ative a preempção).

    ignorePreviousPod

    Scheduler v6.1

    Quando true, o sistema exclui os pods criados antes do ResourcePolicy da contagem de pods. Use em conjunto com max.

    ignoreTerminatingPod

    Scheduler v6.1

    Quando true, o sistema exclui os pods no estado Terminating da contagem de pods. Use em conjunto com max.

    matchLabelKeys

    Scheduler v6.2

    Agrupa pods por valores de rótulo e aplica max por grupo. O sistema rejeita pods sem um rótulo declarado. Use em conjunto com max.

    whenTryNextUnits

    Cluster 1.24+, scheduler 6.4+

    Define quando um pod passa para a próxima unidade (políticas whenTryNextUnits).

    Políticas whenTryNextUnits

    Política

    Passa para a próxima unidade quando...

    Mais indicado para

    LackResourceOrExceedMax (padrão)

    A unidade atual fica sem recursos ou a contagem de pods atinge max

    A maioria dos casos de uso gerais

    ExceedMax

    max e maxResources não estão definidos, ou a contagem de pods atinge max, ou a adição do pod atual excederia maxResources

    Priorizar o auto-scaling de node pools em vez do ECI

    TimeoutOrExceedMax

    (1) max está definido e a contagem de pods é menor que max, ou maxResources está definido e o uso atual mais os recursos do pod atual é menor que maxResources; ou (2) max não está definido e podLabels contêm k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" — em ambos os casos, se a unidade não tiver recursos suficientes, o pod aguarda até timeout antes de passar

    Scale-out de node pool com fallback para ECI após o tempo limite

    LackResourceAndNoTerminating

    Os recursos são insuficientes (ou max é atingido) e nenhum pod na unidade atual está em Terminating

    Atualizações contínuas (rolling updates) — evita que novos pods transbordem para a próxima unidade durante o encerramento dos pods antigos

    O timeout se aplica apenas quando policy é TimeoutOrExceedMax. Padrão: 15 minutos. Não há suporte para unidades ACS (limitado apenas por max).

    Importante

    Se o node pool com auto-scaling não conseguir criar nós por muito tempo, ExceedMax pode manter os pods em Pending indefinidamente. Atualmente, o Cluster Autoscaler não respeita o limite max no ResourcePolicy, portanto, o número real de instâncias criadas pode exceder max. Esse problema será corrigido em uma versão futura.

    Importante

    Com TimeoutOrExceedMax, se um nó for criado durante o período de tempo limite, mas ainda não estiver Ready, e o pod não tolerar o taint NotReady, o sistema ainda agenda o pod para o ECI.

    Exemplos de cenários

    Os resultados são de melhor esforço — a remoção no scale-in pode não reverter estritamente a ordem de agendamento.

    Priorizar um node pool em relação a outro

    Objetivo: Implantar um Deployment em dois node pools — Pool A primeiro, Pool B como excedente. Durante o scale-in, remova os pods do Pool B primeiro.

    Neste exemplo, os nós cn-beijing.10.0.3.137 e cn-beijing.10.0.3.138 pertencem ao Pool A, e cn-beijing.10.0.6.47 e cn-beijing.10.0.6.46 pertencem ao Pool B. Todos os nós têm 2 vCPUs e 4 GB de memória.

    1. Crie um ResourcePolicy que defina a ordem de agendamento dos node pools. Substitua os valores de nodepool-id pelos IDs reais dos seus node pools na página Node Management > Node Pools (Crie e gerencie um node pool).

      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. Crie um Deployment. O rótulo do pod app: nginx deve corresponder ao selector no 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. Aplique o Deployment e verifique o posicionamento dos pods.

      1. Aplique os arquivos YAML.

        kubectl apply -f nginx.yaml

        Saída esperada:

        deployment.apps/nginx created

      2. Verifique os nós em que os pods estão agendados.

        kubectl get pods -o wide

        Saída esperada:

        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>

        Ambos os pods estão nos nós do Pool A, conforme o esperado.

    4. Escale para quatro réplicas e verifique o excedente no Pool B.

      1. Escale o Deployment.

        kubectl scale deployment nginx --replicas 4

      2. Verifique o posicionamento dos pods.

        kubectl get pods -o wide

        Saída esperada:

        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>

        Os dois novos pods são alocados nos nós do Pool B, pois o Pool A atingiu a capacidade máxima.

    5. Reduza a escala para duas réplicas e verifique se o sistema remove os pods do Pool B primeiro.

      1. Reduza a escala do Deployment.

        kubectl scale deployment nginx --replicas 2

      2. Verifique o status dos pods.

        kubectl get pods -o wide

        Saída esperada:

        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>

        O sistema remove os pods do Pool B primeiro — o inverso da ordem de agendamento.

    Usar ECS por assinatura primeiro, depois ECS por pagamento conforme o uso e, por fim, fallback para ECI

    Objetivo: Minimizar custos preenchendo primeiro a capacidade do ECS por assinatura, depois o ECS por pagamento conforme o uso e, finalmente, o ECI. Durante o scale-in, remova os pods na ordem inversa: ECI primeiro, depois ECS por pagamento conforme o uso e, por fim, ECS por assinatura.

    Neste exemplo, todos os nós têm 2 vCPUs e 4 GB de memória.

    1. Rotule os nós por tipo de faturamento. Ao usar node pools, configure os rótulos no nível do node pool.

      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. Crie um ResourcePolicy que ordene as unidades por tipo de faturamento.

      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. Crie um Deployment com duas 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. Aplique e verifique o posicionamento inicial nos nós de ECS por assinatura.

      1. Aplique os arquivos YAML.

        kubectl apply -f nginx.yaml

      2. Verifique o posicionamento dos pods.

        kubectl get pods -o wide

        Saída esperada:

        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>

        Ambos os pods estão em nós de ECS por assinatura.

    5. Aumente a escala para verificar o excedente para o ECS por pagamento conforme o uso e, em seguida, para o ECI.

      1. Escale para quatro réplicas e verifique o posicionamento dos pods.

        kubectl scale deployment nginx --replicas 4
        kubectl get pods -o wide

        Saída esperada:

        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>

        O sistema agenda os pods excedentes para nós de ECS por pagamento conforme o uso.

      2. Escale para seis réplicas e verifique o posicionamento dos pods.

        kubectl scale deployment nginx --replicas 6
        kubectl get pods -o wide

        Saída esperada:

        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>

        Com toda a capacidade do ECS esgotada, o sistema agenda os pods restantes para o ECI (nós virtual-kubelet).

    6. Reduza a escala para verificar a ordem inversa de remoção.

      1. Reduza a escala para quatro réplicas. O sistema remove os pods do ECI primeiro.

        kubectl scale deployment nginx --replicas 4
        kubectl get pods -o wide

        Saída esperada:

        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>

        O sistema remove os pods do ECI primeiro.

      2. Reduza a escala para duas réplicas. O sistema remove os pods do ECS por pagamento conforme o uso em seguida.

        kubectl scale deployment nginx --replicas 2
        kubectl get pods -o wide

        Saída esperada:

        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. Após a conclusão da exclusão, apenas os pods do ECS por assinatura permanecem.

        kubectl get pods -o wide

        Saída esperada:

        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>

    Solução de problemas

    Os pods ficam presos em Pending após a aplicação de um ResourcePolicy

    O scheduler pode não associar o ResourcePolicy aos pods corretos. Verifique se o selector corresponde exatamente aos rótulos dos pods da sua carga de trabalho. Se o seletor usar um rótulo reservado pelo sistema (como alibabacloud.com/compute-class), o sistema pode modificá-lo, quebrando a associação.

    Confirme também se a versão do seu kube-scheduler atende ao requisito mínimo para a versão do seu cluster (consulte Pré-requisitos).

    O scale-in não segue a ordem inversa esperada

    Este recurso é de melhor esforço. Não há garantia de remoção estrita na ordem inversa — por exemplo, quando a preempção está ativa ou quando vários pods se tornam elegíveis para remoção simultaneamente.

    Caso seja necessária uma ordenação mais rigorosa, verifique a configuração whenTryNextUnits.policy e considere LackResourceAndNoTerminating para cenários de atualização contínua (rolling update).

    O ResourcePolicy entra em conflito com pod-deletion-cost

    Se as anotações pod-deletion-cost estiverem configuradas em pods na mesma carga de trabalho, os dois recursos entrarão em conflito. Remova as anotações pod-deletion-cost antes de aplicar um ResourcePolicy.

    O node pool cria nós inesperados quando usado com node pools elásticos

    Quando um node pool com auto-scaling está em uma unidade com max definido, o Cluster Autoscaler pode criar mais nós do que max porque não lê o limite max do ResourcePolicy. Para evitar isso, inclua o node pool elástico em uma unidade e não defina max para essa unidade.

    Próximos passos

    Referências