Use o ack-co-scheduler para implementar o escalonamento de recursos multinível - : Central de Documentação do Alibaba Cloud

O escalonamento de recursos multinível otimiza a alocação de workloads implantados na nuvem e em redes on-premises em ambientes de nuvem híbrida. Esse recurso ajusta os recursos conforme as flutuações de tráfego e ajuda a garantir a alta disponibilidade das aplicações. Este tópico descreve como usar o ack-co-scheduler para configurar o escalonamento de recursos multinível.

Pré-requisitos

Seu cluster Kubernetes autogerenciado está conectado a um cluster registrado do ACK One.

A tabela a seguir lista as versões necessárias dos componentes do sistema.

Componente	Versão necessária
Kubernetes	1.18.8 ou posterior
Helm	3.0 ou posterior
Docker	19.03.5
SO	CentOS 7.6, CentOS 7.7, Ubuntu 16.04 e 18.04, e Alibaba Cloud Linux.

Informações de fundo

O escalonamento de recursos multinível estende o escalonamento baseado em prioridade para cenários de nuvem híbrida e permite o uso de recursos do tipo idc no agendamento de pods. O Container Service for Kubernetes (ACK) possibilita a configuração desse escalonamento por prioridade. Ao implantar ou escalar horizontalmente uma aplicação, use o recurso ResourcePolicy para definir os nós de destino dos pods e a ordem de seleção desses nós. Durante a redução de escala, o sistema remove os pods seguindo a sequência inversa. Para mais detalhes, consulte Escalonamento personalizado por prioridade para recursos elásticos.

Limites

O escalonamento de recursos baseado em prioridade é mutuamente exclusivo com o recurso de custo de exclusão de pod. Para saber mais sobre esse recurso, consulte Custo de exclusão de pod.
Não é possível usar simultaneamente o escalonamento baseado em prioridade e o escalonamento via Elastic Container Instance. Para obter mais informações sobre o escalonamento via Elastic Container Instance, consulte Usar recursos elásticos para implementar escalonamento via Elastic Container Instance (descontinuado).
Após modificar uma ResourcePolicy, apenas os pods agendados com base na versão atualizada seguem a nova regra de exclusão. Os pods criados sob a política original continuam sendo removidos conforme as diretrizes anteriores.
Ao combinar este recurso com pools de nós elásticos, nós inválidos podem ser adicionados aos pools. Certifique-se de incluir esses pools em unidades e não especifique o parâmetro max para elas.
Não modifique a ResourcePolicy antes que todos os pods correspondentes sejam excluídos.

Como configurar o escalonamento de recursos baseado em prioridade

Crie uma ResourcePolicy com o seguinte conteúdo:

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: xxx
  namespace: xxx
spec:
  selector:
    key1: value1
  strategy: prefer
  units:
  - resource: idc
    max: 3
  - resource: ecs
    nodeSelector:
      key2: value2
  - resource: ecs
    nodeSelector:
      key3: value3
  - resource: eci

selector: seletor usado para identificar pods em um namespace. A ResourcePolicy aplica-se apenas aos pods selecionados. Neste exemplo, são selecionados pods com o label key1=value1.
strategy: política de escalonamento. Defina o valor como prefer.
units: unidades agendáveis. Durante o scale-out, os pods são distribuídos aos nós respeitando a ordem decrescente de prioridade definida em units. No scale-in, a remoção ocorre em ordem crescente de prioridade.
- resource: tipo de recurso elástico. Tipos suportados: eci, ecs e idc.
- nodeSelector: seletor usado para filtrar nós que possuem um determinado label de node. Este parâmetro entra em vigor apenas quando o recurso está definido como ecs.
- : número máximo de instâncias implantáveis com esses recursos.

Instale componentes

Instale os seguintes componentes antes de usar o escalonamento de recursos multinível.

ack-virtual-node: opcional. Para usar ECI, instale o componente ack-virtual-node no cluster registrado.
ack-co-scheduler: permite criar CustomResources (CRs) do tipo ResourcePolicy para habilitar o escalonamento multinível.
Usar onectl
1. Instale e configure o onectl na máquina local. Para mais detalhes, consulte Gerencie clusters registrados com onectl.
2. Execute o comando a seguir para instalar os componentes ack-virtual-node e ack-co-scheduler:
  onectl addon install ack-virtual-node onectl addon install ack-co-scheduler
  Saída esperada:
  Addon ack-virtual-node, version **** installed. Addon ack-co-scheduler, version **** installed.
Usar o console
1. Faça login no console do ACK e clique em Clusters no painel de navegação à esquerda.
2. Na página Clusters, clique no nome do cluster desejado e selecione Operations > Add-ons no painel de navegação à esquerda.
3. Na página Add-ons, pesquise ack-virtual-node e ack-co-scheduler na caixa de pesquisa e clique em Install no canto inferior direito de cada cartão.
4. Na mensagem exibida, clique em OK.

Cenário 1: Escalonamento multinível baseado em prioridade

Crie uma ResourcePolicy com o seguinte modelo:

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: cost-balance-policy
spec:
  selector:
    app: nginx
  strategy: prefer
  units:
  - resource: idc
  - resource: ecs
    nodeSelector:
      alibabacloud.com/nodepool-id=np7b30bxxxxxxa3940936c19ea42b  # Replace with your actual node ID
  - resource: eci

Crie um Deployment que provisiona dois pods conforme o conteúdo a seguir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      annotations:
        addannotion: "true"
      labels:
        app: nginx      # The pod label must be the same as the one that you specified for the selector in the ResourcePolicy. 
    spec:
      schedulerName: ack-co-scheduler
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        resources:
          requests:
            cpu: 200m
          limits:
            cpu: 1

Execute o comando a seguir para implantar uma aplicação NGINX:
```
kubectl apply -f nginx.yaml
```
Execute o comando a seguir para escalar os pods horizontalmente:
```
kubectl scale deployment nginx --replicas 10
```
Saída esperada:
```
deployment.apps/nginx scaled
```

Execute o comando a seguir para consultar o status dos pods:

kubectl get pod -o wide

Saída esperada:

Clique para ver detalhes

NAME                          READY   STATUS   RESTARTS        AGE    IP             NODE                           NOMINATED NODE   READINESS GATES
nginx-load-85b845cffd-58bhb   1/1     Running   0              32s   10.100.XX.XX    idc-oneline-hz-work****         <none>           <none>
nginx-load-85b845cffd-7bv5h   1/1     Running   0              32s   10.200.XX.XX    virtual-kubelet-cn-****         <none>           <none>
nginx-load-85b845cffd-9bsz2   1/1     Running   0              32s   10.200.XX.XX    cn-hangzhou.10.200.XX.XX        <none>           <none>
nginx-load-85b845cffd-bh7bs   1/1     Running   0              32s   10.200.XX.XX    cn-hangzhou.10.200.XX.XX        <none>           <none>
nginx-load-85b845cffd-crqhv   1/1     Running   0              32s   10.100.XX.XX    idc-oneline-hz-work****         <none>           <none>
nginx-load-85b845cffd-crrnz   1/1     Running   0              32s   10.100.XX.XX    idc-oneline-hz-work****         <none>           <none>
nginx-load-85b845cffd-h8swv   1/1     Running   0              32s   10.200.XX.XX    cn-hangzhou.10.200.XX.XX        <none>           <none>
nginx-load-85b845cffd-hfdkv   1/1     Running   0              32s   10.200.XX.XX    virtual-kubelet-cn-****         <none>           <none>
nginx-load-85b845cffd-ttrhg   1/1     Running   0              32s   10.100.XX.XX    idc-oneline-hz-work****         <none>           <none>
nginx-load-85b845cffd-vf8lg   1/1     Running   0              32s   10.200.XX.XX    cn-hangzhou.10.200.XX.XX        <none>           <none>

Controle o número de réplicas da aplicação NGINX e visualize o resultado do escalonamento. A saída confirma que os pods obedecem à ResourcePolicy, seguindo esta ordem de prioridade de recursos: idc, ecs e eci.

Cenário 2: Escalonamento de recursos em ambientes de nuvem híbrida