Container Service for Kubernetes:Use load-aware scheduling

Pré-requisitos

• O ack-koordinator 1.1.1-ack.1 ou posterior está instalado. Para mais informações, consulte ack-koordinator (FKA ack-slo-manager).

• A versão do agendador ACK instalado, kube-scheduler, corresponde à versão do Kubernetes do cluster. As seguintes correspondências de versão são necessárias para ativar o agendamento com base em carga.

  Versão do Kubernetes	Versão do agendador ACK
  ≥ 1.26	Todas as versões
  1.24	≥ 1.24.6-ack-4.0
  1.22	≥ 1.22.15-ack-4.0

Faturamento

A instalação e o uso do componente ack-koordinator são gratuitos. No entanto, podem ocorrer custos nos seguintes cenários:

• O ack-koordinator é um componente não gerenciado que consome recursos dos nós worker após a instalação. Configure as solicitações de recursos para cada módulo durante a instalação.

• Por padrão, o ack-koordinator expõe métricas de monitoramento para recursos como perfilamento de recursos e agendamento refinado no formato Prometheus. Se você selecionar a opção Enable Prometheus monitoring metrics for ack-koordinator e utilizar o Managed Service for Prometheus, essas métricas serão cobradas como métricas personalizadas. As taxas variam conforme fatores como o tamanho do cluster e a quantidade de aplicações. Antes de ativar esse recurso, leia Faturamento de instâncias do Prometheus para entender o nível gratuito e os preços das métricas personalizadas. Para monitorar e gerenciar o uso de recursos, use a consulta de uso.

Limites

• Somente clusters ACK Pro oferecem suporte ao agendamento com base em carga. Para mais informações, consulte Criar um cluster ACK Pro.

Introdução ao agendamento com base em carga

O recurso de agendamento com base em carga do agendador ACK kube-scheduler foi desenvolvido com base na estrutura de agendamento do Kubernetes. Enquanto o agendador do Kubernetes agenda pods nos nós com base na alocação de recursos, o agendador do ACK executa essa tarefa considerando a carga real dos nós. Após a ativação do agendamento com base em carga, o sistema analisa estatísticas históricas de utilização e direciona os pods para nós menos carregados, garantindo o balanceamento de carga. Isso evita falhas em aplicações ou nós causadas por sobrecarga.

A figura a seguir ilustra as diferenças entre o agendador do Kubernetes e o agendador do ACK ao agendar um pod. "Requested" indica os recursos solicitados pelos pods no nó, enquanto "Usage" representa os recursos efetivamente em uso. Apenas os recursos em utilização são considerados no cálculo da carga do nó. Nesse cenário, o agendador do ACK escolhe o Nó B porque ele apresenta menor carga.

Com o tempo, mudanças no ambiente do cluster, no tráfego ou nas solicitações às cargas de trabalho podem desequilibrar a distribuição de carga entre os nós. Para evitar esse problema, o ack-koordinator fornece o recurso de desagendamento de hotspots com base em carga. A combinação do agendamento com base em carga com o desagendamento de hotspots permite alcançar um balanceamento ideal entre os nós. Para mais detalhes sobre o desagendamento de hotspots, consulte Usar desagendamento com base em hotspots para balancear cargas de nós.

Como funciona

O agendamento com base em carga é implementado pelo kube-scheduler em conjunto com o ack-koordinator. O ack-koordinator coleta e relata métricas de utilização de recursos dos nós. O agendador do ACK calcula pontuações para cada nó com base nessa utilização e ordena os nós conforme as pontuações obtidas. Assim, o agendador prioriza o envio de novos pods para nós com menor carga. Para mais informações sobre a arquitetura do ack-koordinator, consulte Arquitetura do ack-koordinator.

Políticas de agendamento

Etapa 1: Ativar o agendamento com base em carga

1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Components and Add-ons.

3. Na página Add-ons, localize Kube Scheduler e clique em Configuration no cartão Kube Scheduler.

4. Na caixa de diálogo Kube Scheduler Parameters, configure os parâmetros conforme descrito na tabela a seguir e clique em OK.

   A tabela a seguir descreve os principais parâmetros. Para mais informações sobre outros parâmetros e as versões de componentes necessárias, consulte Container Service for Kubernetes:kube-scheduler e Parâmetros personalizados do kube-scheduler.

   Parâmetro	Tipo	Descrição	Valor válido	Exemplo
   loadAwareThreshold	O valor consiste nos campos resourceName e resourceWeight.	Define o limiar para filtragem de nós.	resourceName: Os valores válidos são cpu e memory. threshold: Valores válidos variam de 0 a 100. Por padrão, este parâmetro fica vazio, o que desativa a filtragem de nós.	resourceName: cpu threshold: 80
   loadAwareResourceWeight	O valor consiste nos campos resourceName e resourceWeight.	Especifica o peso do recurso usado para calcular a pontuação do nó na ordenação. Este parâmetro fica disponível após selecionar Specifies whether to enable load-aware node scoring during pod scheduling.	resourceName: O esquema do parâmetro resourceName é validado. Os valores só podem ser cpu ou memory. resourceWeight: Valores válidos são inteiros entre 1 e 100. Valor padrão: cpu=1, memory=1.	resourceName: cpu resourceWeight: 1
   loadAwareAggregatedUsageAggregationType	enum	Define o tipo de agregação de dados para as estatísticas. Valores válidos: avg: calcula o valor médio. p50: calcula 50% das estatísticas. p90, p95 e p99: calculam, respectivamente, 90%, 95% e 99% das estatísticas.	avg p50 p90 p95 p99 Valor padrão: avg.	p90

   No painel de navegação à esquerda da página de detalhes do cluster, clique em Cluster Information. Se o status do cluster na aba Basic Information mudar para Running, o agendamento com base em carga estará ativado.

Etapa 2: Testar o agendamento com base em carga

O exemplo a seguir utiliza um cluster composto por três nós. Cada nó possui 4 núcleos e 16 GiB de memória.

1. Crie um arquivo chamado stress-demo.yaml e copie o código abaixo para ele:

   Show YAML content:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: stress-demo
     namespace: default
     labels:
       app: stress-demo
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: stress-demo
     template:
       metadata:
         name: stress-demo
         labels:
           app: stress-demo
       spec:
         containers:
           - args:
               - '--vm'
               - '2'
               - '--vm-bytes'
               - '1600M'
               - '-c'
               - '2'
               - '--vm-hang'
               - '2'
             command:
               - stress
             image: polinux/stress
             imagePullPolicy: Always
             name: stress
             resources:
               limits:
                 cpu: '2'
                 memory: 4Gi
               requests:
                 cpu: '2'
                 memory: 4Gi
         restartPolicy: Always

2. Execute o comando a seguir para criar um pod. Após a criação do pod, aumente a carga de um nó.

   kubectl create -f stress-demo.yaml
   # Expected output
   deployment.apps/stress-demo created

3. Execute o comando abaixo e monitore o status do pod até que ele atinja o estado Running:

   kubectl get pod -o wide

   Saída esperada:

   NAME                           READY   STATUS    RESTARTS   AGE   IP           NODE                    NOMINATED NODE   READINESS GATES
   stress-demo-7fdd89cc6b-g****   1/1     Running   0          82s   10.XX.XX.112   cn-beijing.10.XX.XX.112   <none>           <none>

   O pod stress-demo-7fdd89cc6b-g**** foi agendado no nó cn-beijing.10.XX.XX.112.

   Aguarde 3 minutos. Certifique-se de que o pod foi inicializado e que a carga do nó aumentou.

4. Execute o comando a seguir para consultar a carga de cada nó:

   kubectl top node

   Saída esperada:

   NAME                    CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.10.XX.XX.110   92m          2%     1158Mi          9%
   cn-beijing.10.XX.XX.111   77m          1%     1162Mi          9%
   cn-beijing.10.XX.XX.112   2105m        53%    3594Mi          28%

   O nó cn-beijing.10.XX.XX.111 apresenta a menor carga entre todos os nós. Já o nó cn-beijing.10.XX.XX.112 possui a maior carga. Isso indica um desequilíbrio na distribuição de carga entre os nós.

5. Crie um arquivo chamado nginx-with-loadaware.yaml e copie o seguinte código para ele:

   Show YAML content:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-with-loadaware
     namespace: default
     labels:
       app: nginx
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 500m
             requests:
               cpu: 500m

6. Execute o comando abaixo para criar os pods:

   kubectl create -f nginx-with-loadaware.yaml
   # Expected output
   deployment/nginx-with-loadawre created

7. Execute o comando a seguir para verificar se os pods foram agendados:

   kubectl get pods | grep nginx

   Saída esperada:

   nginx-with-loadaware-5646666d56-2****   1/1     Running   0          18s   10.XX.XX.118   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-7****   1/1     Running   0          18s   10.XX.XX.115   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-k****   1/1     Running   0          18s   10.XX.XX.119   cn-beijing.10.XX.XX.110   <none>           <none>
   nginx-with-loadaware-5646666d56-q****   1/1     Running   0          18s   10.XX.XX.113   cn-beijing.10.XX.XX.111   <none>           <none>
   nginx-with-loadaware-5646666d56-s****   1/1     Running   0          18s   10.XX.XX.120   cn-beijing.10.XX.XX.111   <none>           <none>
   nginx-with-loadaware-5646666d56-z****   1/1     Running   0          18s   10.XX.XX.116   cn-beijing.10.XX.XX.111   <none>           <none>

   A saída anterior demonstra que, após ativar o agendamento com base em carga, o cluster monitora a utilização dos nós e aplica uma política de agendamento para distribuir os pods em nós diferentes do nó cn-beijing.10.XX.XX.112.

Próximos passos

Modificar configurações de agendamento com base em carga

1. Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Components and Add-ons.

3. Na página Add-ons, localize Kube Scheduler e clique em Configuration no cartão Kube Scheduler.

4. Na caixa de diálogo Kube Scheduler Parameters, modifique os parâmetros relacionados ao agendamento com base em carga e clique em OK.

   No painel de navegação à esquerda da página de detalhes do cluster, clique em Cluster Information. Se o status do cluster na aba Basic Information mudar para Running, as configurações de agendamento com base em carga terão sido modificadas.

Desativar o agendamento com base em carga

1. Na caixa de diálogo Kube Scheduler Parameters, desmarque Specifies whether to enable load-aware node scoring during pod scheduling, remova os parâmetros loadAwareResourceWeight e loadAwareThreshold e clique em OK.

2. No painel de navegação à esquerda da página de detalhes do cluster, clique em Cluster Information. Se o status do cluster na aba Basic Information mudar para Running, o agendamento com base em carga estará desativado.

Perguntas frequentes

Por que nenhum pod é agendado no nó com menor carga após a criação de um lote de pods?

Se o agendador direcionar todos os pods para o nó com menor carga, esse nó se tornará um hotspot.

Para evitar esse problema, caso um nó receba novos pods cujos dados de utilização de recursos ainda não tenham sido relatados, o plug-in de agendamento com base em carga ajusta adequadamente a pontuação desse nó.

Além da carga dos nós, quais fatores podem influenciar os resultados do agendamento com base em carga?

O agendador do Kubernetes é composto por vários plug-ins. Alguns deles, como os plug-ins de afinidade e topologia, são responsáveis pela pontuação e ordenação dos nós. A classificação final resulta da ação conjunta desses plug-ins. Ajuste os pesos das pontuações atribuídas por cada plug-in conforme as necessidades do seu negócio.

O recurso de agendamento com base em carga, habilitado via protocolo de versão anterior, continua funcionando após a atualização da versão do agendador?

Para utilizar o recurso de agendamento com base em carga através de um protocolo de versão anterior, adicione a anotação alibabacloud.com/loadAwareScheduleEnabled: "true" às configurações do pod.

A tabela a seguir detalha a compatibilidade entre diferentes versões de protocolo e versões de componentes.