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

Defina uma ResourcePolicy para agendar pods em nós ECS e no ACS por ordem de prioridade. Durante o scale-out, os pods são alocados primeiro nos recursos de maior prioridade; durante o scale-in, os pods de menor prioridade são removidos primeiro.

Importante

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

Limites

O uso conjunto com pod-deletion-cost não oferece suporte ao scale-in em ordem inversa.
O parâmetro max exige Kubernetes 1.26+ e versão do scheduler 6.7+.
Ao usar pools de nós elásticos, inclua os pools nas unidades e não especifique o parâmetro max. Caso contrário, nós inválidos poderão ser adicionados.

Use o agendamento de recursos baseado em prioridade

Configure a prioridade e a ordem de alocação dos pods entre os tipos de recurso. Configurar agendamento de recursos baseado em prioridade.

Pré-requisitos

Crie um cluster ACK Pro executando Kubernetes 1.26 ou posterior. Atualizar a versão do Kubernetes de um cluster ACK.

As versões necessárias 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 das diferentes versões do scheduler, consulte Container Service for Kubernetes:kube-scheduler.
Ative o poder de computação do ACS para o cluster ACK Pro. Usar o poder de computação do ACS em clusters ACK Pro.

Exemplo: agendamento combinado de ECS e ACS

Este exemplo agenda pods em ECS por assinatura, ECS por pagamento conforme o uso e ACS, nessa ordem de prioridade. No scale-in, os pods são removidos na ordem inversa. Cada nó possui 2 vCPUs e 4 GB de memória.

Adicione labels para diferenciar os métodos de faturamento nos 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 da label do nó
- paidtype=subscription: nós ECS por assinatura
  
  paidtype=pay-as-you-go: nós ECS por pagamento conforme o uso

Crie a seguinte ResourcePolicy:

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 computing power. 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 a alocação 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 foram alocados em nós por assinatura (paidtype=subscription label).

Escale horizontalmente a aplicação nginx.

Escale para quatro réplicas:

kubectl scale deployment nginx --replicas 4

Saída esperada:

deployment.apps/nginx scaled

Verifique a alocação 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>

Os novos pods foram alocados em nós por pagamento conforme o uso (paidtype=pay-as-you-go label), pois os nós com a paidtype=subscription label atingiram a capacidade máxima.

Escale para seis réplicas:

kubectl scale deployment nginx --replicas 6

Saída esperada:

deployment.apps/nginx scaled

Verifique a alocação 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 esgotou-se. Os novos pods foram agendados no ACS (nó virtual-kubelet).

Reduza a escala da aplicação 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 os pods são removidos na ordem inversa da prioridade de agendamento: primeiro do ACS, depois dos nós ECS por pagamento conforme o uso 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>

Os pods nos nós por pagamento conforme o uso (paidtype=pay-as-you-go label) foram encerrados.

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 nos nós com a paidtype=subscription label permanecem ativos.

Referências

Ao implantar cargas de trabalho 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 oferecem suporte a vários cenários de dimensionamento. Consulte Usar o poder de computação do ACS em clusters ACK Pro.
Para jobs distribuídos, use o agendamento nativo do Kubernetes para espalhar cargas de trabalho entre zonas visando alta disponibilidade, ou confine-as a zonas específicas via afinidade para obter alto desempenho. Consulte Agendamento por Afinidade de Nó.