Mixed ECS and ACS pod scheduling in ACK Pro clusters - Container Compute Service: Central de Documentação do Alibaba Cloud

Defina uma ResourcePolicy para organizar os nós ECS e os recursos de computação do ACS em uma lista ordenada de níveis de agendamento. Os pods ocupam primeiro os níveis de maior prioridade durante o scale-out e liberam primeiro os níveis de menor prioridade durante o scale-in, o que permite controlar onde cada pod é executado.

Importante

No kube-scheduler v1.x.x-aliyun-6.4 e versões posteriores, por padrão, o parâmetro ignorePreviousPod de uma ResourcePolicy tem o valor False e o parâmetro ignoreTerminatingPod tem o valor True. Essa alteração e futuras atualizações não afetam as ResourcePolicies existentes que usam esses parâmetros.

Limites

Ao usar o agendamento prioritário baseado em ResourcePolicy com o pod-deletion-cost, não há garantia de scale-in em ordem inversa.
O parâmetro max exige o Kubernetes 1.26 ou superior e o scheduler na versão 6.7 ou superior.
Ao usar o agendamento prioritário baseado em ResourcePolicy com pools de nós elásticos, inclua os pools em uma das unidades e não especifique o parâmetro max. Caso contrário, o pool de nós elásticos pode falhar durante o scale-out de nós.

Use o agendamento de recursos baseado em prioridade

Para obter detalhes sobre o agendamento prioritário entre tipos de recursos, consulte Configurar o agendamento de recursos baseado em prioridade.

Pré-requisitos

É necessário ter um cluster ACK Pro executando o Kubernetes 1.26 ou posterior. Para saber mais sobre como atualizar, consulte Atualizar a versão do Kubernetes de um cluster ACK.

As versões exigidas do scheduler e do nó virtual dependem da versão do Kubernetes do cluster:

Versão do Kubernetes

Versão do scheduler

Versão do nó virtual

≥ 1.26

≥ 1.26.3-aliyun-6.7.0

≥ 2.13.0

Para mais informações sobre os recursos de diferentes versões do scheduler, consulte kube-scheduler.
Ative o poder de computação do ACS para o cluster ACK Pro. Para saber como ativar o poder de computação do ACS, consulte Usar o poder de computação do ACS em clusters ACK Pro.

Exemplo: agendamento misto de ECS e ACS

Este exemplo agenda pods em nós ECS por assinatura, nós ECS pay-as-you-go e ACS, nessa ordem de prioridade, para reduzir os custos de recursos. Durante o scale-in, a remoção dos pods ocorre na ordem inversa. Cada nó tem 2 vCPUs e 4 GB de memória.

Adicione labels para distinguir os métodos de cobrança dos nós. Em produção, use pools de nós para atribuir labels automaticamente.

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

Descrição do label do nó

paidtype=subscription: nós ECS por assinatura

paidtype=pay-as-you-go: nós ECS pay-as-you-go

Crie a seguinte ResourcePolicy para personalizar a ordem de agendamento dos pools de nós:

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

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                                           # The pod label must be the same as the one that you specified for the selector in the ResourcePolicy. 
        alibabacloud.com/compute-class: general-purpose      # The compute class of the ACS pod. Default value: general-purpose.
        alibabacloud.com/compute-qos: default                # The quality of service (QoS) class of the ACS pod. Default value: default.
    spec:
      containers:
      - name: nginx
        image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

Implante e verifique:

Aplique o manifesto:

kubectl apply -f nginx.yaml

Saída esperada:

deployment.apps/nginx created

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>

O cluster aloca os dois pods em nós por assinatura (paidtype=subscription label).

Aumente a escala do aplicativo nginx.

Escale para quatro réplicas:

kubectl scale deployment nginx --replicas 4

Saída esperada:

deployment.apps/nginx scaled

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-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 cluster aloca os novos pods em nós pay-as-you-go (paidtype=pay-as-you-go label) porque os nós com o paidtype=subscription label estão cheios.

Escale para seis réplicas:

kubectl scale deployment nginx --replicas 6

Saída esperada:

deployment.apps/nginx scaled

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-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>

A capacidade do ECS está esgotada. O cluster agenda os novos pods para o ACS (nó virtual-kubelet).

Reduza a escala do aplicativo nginx.

Escale para quatro réplicas:

kubectl scale deployment nginx --replicas 4

Saída esperada:

deployment.apps/nginx scaled

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-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>

A saída mostra que o sistema remove os pods na ordem inversa da prioridade de agendamento: primeiro do ACS, depois dos nós ECS pay-as-you-go e, por último, dos nós ECS por assinatura.

Escale para duas réplicas:

kubectl scale deployment nginx --replicas 2

Saída esperada:

deployment.apps/nginx scaled

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-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>

O sistema encerra os pods dos nós pay-as-you-go (paidtype=pay-as-you-go label).

Aguarde alguns minutos e verifique novamente:

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>

Somente os pods em nós com o paidtype=subscription label permanecem.

Referências

Ao implantar workloads em um cluster ACK, use tolerâncias e afinidade de nó para restringir o agendamento a recursos ECS ou ACS, ou para provisionar automaticamente o ACS quando o ECS for insuficiente. Diferentes políticas de agendamento atendem a diversos cenários de escalonamento. Consulte Usar o poder de computação do ACS em clusters ACK Pro.
Para jobs distribuídos, use o agendamento nativo do Kubernetes para distribuir workloads entre zonas e garantir alta disponibilidade, ou confine-os a zonas específicas por meio de afinidade para obter alto desempenho. Consulte Agendamento por afinidade de nós.