Mecanismos de dimensionamento de nós

Pré-requisitos

Antes de usar a função de dimensionamento de nó, deve instalar o complemento autoscaler da v1.13.8 ou posterior.

Como funciona o autoscaler

O autoscaler passa por dois processos.

• Expansão: o autoscaler verifica todos os pods não agendados a cada 10 segundos e seleciona um pool de nós que atenda aos requisitos de expansão com base na política definida.
  

  Quando o autoscaler verifica pods não agendados em busca de expansões, ele usa o algoritmo de agendamento consistente com a versão da comunidade do Kubernetes para cálculo de agendamento simulado. Se kube-schedulers não embutidas ou outras políticas de agendamento da comunidade não de Kubernetes forem usadas para agendamento de aplicações, quando o autoscaler for usado para expandir a capacidade de tais aplicações, a capacidade pode deixar de ser expandida ou pode ser expandida mais do que o esperado devido a algoritmos de agendamento inconsistentes.

• Redução: o autoscaler verifica todos os nós a cada 10 segundos. Se o número de solicitações de pods em um nó for menor que a porcentagem definida pelo usuário para redução, o autoscaler simula se os pods no nó podem ser migrados para outros nós. Se sim, o nó será removido após uma janela de tempo ocioso.
  Quando um nó de cluster fica ocioso por um período (10 minutos por padrão), o dimensionamento de cluster é acionado e o nó é excluído automaticamente. No entanto, um nó não pode ser excluído de um cluster se os seguintes pods existirem:

  • Pods que não atendem aos requisitos específicos definidos nos Orçamentos de interrupção de pods (PodDisruptionBudget)
  • Pods que não podem ser programados para outros nós devido a restrições, como políticas de afinidade e antiafinidade
  • Pods que têm a anotação cluster-autoscaler.kubernetes.io/safe-to-evict: 'false'
  • Pods (exceto aqueles criados por DaemonSets no namespace do kube-system) que existem no namespace do kube-system no nó
  • Pods que não são criados pelo controlador (Implementação/ReplicaSet/tarefa/StatefulSet)

  

  Quando um nó atende às condições de dimensionamento, o Autoscaler adiciona a mancha DeletionCandidateOfClusterAutoscaler ao nó com antecedência para evitar que pods sejam programados para o nó. Após a desinstalação do complemento Autoscaler, se a mancha ainda existir no nó, exclua-a manualmente.

Arquitetura do autoscaler

Figura 1 mostra a arquitetura do autoscaler e seus módulos principais:

Figura 1 Arquitetura do autoscaler

Descrição

• Estimator: avalia o número de nós a serem adicionados a cada pool de nós para hospedar pods não agendáveis.
• Simulator: localiza os nós que atendem às condições de reduzir no cenário de redução.
• Expander: seleciona um nó ideal do pool de nós selecionado pelo estimador com base na política definida pelo usuário no cenário de expansão. Atualmente, o Expander possui as seguintes políticas:

  Tabela 1 Políticas de Expander apoiadas pelo CCE

  Política	Descrição	Cenário de aplicação	Exemplo
  Random	Seleciona aleatoriamente um pool de nós programável para executar a expansão.	Esta política é normalmente utilizada como uma cópia de segurança básica para outras políticas complexas. Utilize esta política apenas se as outras políticas não puderem ser utilizadas.	Suponha que o dimensionamento automático esteja ativado para os pools de nós 1 e 2 no cluster e que o limite superior de expansão não seja atingido. A política para dimensionar o número de réplicas de uma carga de trabalho é a seguinte: Os pods pendentes acionam o autoscaler para determinar o processo de expansão. O autoscaler simula a fase de agendamento e avalia que os pods pendentes podem ser programados para os nós adicionados em ambos os pools de nós 1 e 2. O autoscaler seleciona aleatoriamente o pool de nós 1 ou o pool de nós 2 para expansão.
  most-pods	Uma política combinada. Tem precedência sobre a política aleatória. Seleciona preferencialmente o pool de nós que pode agendar a maioria dos pods após a expansão. Se vários pools de nós atenderem à condição, a política random será usada para tomar decisões adicionais.	Esta política baseia-se no número máximo de pods que podem ser agendados.	Suponha que o dimensionamento automático esteja ativado para os pools de nós 1 e 2 no cluster e que o limite superior de dimensionamento não seja atingido. A política para dimensionar o número de réplicas de uma carga de trabalho é a seguinte: Os pods pendentes acionam o autoscaler para determinar o processo de expansão. O autoscaler simula a fase de agendamento e avalia que alguns pods pendentes podem ser agendados para os nós adicionados nos pools de nós 1 e 2. O autoscaler avalia que o pool de nós 1 pode agendar 20 novos pods e o pool de nós 2 pode agendar apenas 10 novos pods após a expansão. Portanto, o autoscaler seleciona o pool de nós 1 para dimensionamento.
  least-waste	Uma política combinada. Tem precedência sobre a política aleatória. O autoscaler avalia a taxa geral de alocação de CPU ou memória dos pools de nós e seleciona o pool de nós com o mínimo de desperdício de CPU ou memória. Se vários pools de nós atenderem à condição, a política random será usada para tomar decisões adicionais.	Esta política usa a pontuação mínima de resíduo de recursos de CPU ou memória como critério de seleção. A fórmula para calcular a pontuação mínima de resíduos (wastedScore) é a seguinte: wastedCPU = (número total de CPUs dos nós a serem expandidos – número total de CPUs dos pods a serem agendados)/número total de CPUs dos nós a serem expandidos wastedMemory = (tamanho total de memória dos nós a serem expandidos – tamanho total de memória dos pods a serem agendados)/tamanho total de memória dos nós a serem expandidos wastedScore = wastedCPU + wastedMemory	Suponha que o dimensionamento automático esteja ativado para os pools de nós 1 e 2 no cluster e que o limite superior de dimensionamento não seja atingido. A política para dimensionar o número de réplicas de uma carga de trabalho é a seguinte: Os pods pendentes acionam o autoscaler para determinar o processo de expansão. O autoscaler simula a fase de agendamento e avalia que alguns pods pendentes podem ser agendados para os nós adicionados nos pools de nós 1 e 2. O autoscaler avalia que a pontuação mínima de desperdício do pool de nós 1 após a expansão é menor do que a do pool de nós 2. Portanto, o autoscaler seleciona o pool de nós 1 para expansão.
  priority	Uma política combinada. As prioridades para as políticas são as seguintes: priority > least-waste > random. É uma política least-waste aprimorada configurada com base no pool de nós ou na prioridade do grupo de dimensionamento. Se vários pools de nós atenderem à condição, a política least-waste será usada para a tomada de decisões posteriores.	Essa política permite configurar e gerenciar as prioridades de pools de nós ou grupos de dimensionamento por meio do console ou da API, enquanto a política least-waste pode reduzir a taxa de desperdício de recursos em cenários comuns. Essa política tem uma aplicabilidade mais ampla e é usada como a política de seleção padrão.	Suponha que o dimensionamento automático esteja ativado para os pools de nós 1 e 2 no cluster e que o limite superior de expansão não seja atingido. A política para dimensionar o número de réplicas de uma carga de trabalho é a seguinte: Os pods pendentes acionam o autoscaler para determinar o processo de expansão. O autoscaler simula a fase de agendamento e avalia que alguns pods pendentes podem ser agendados para os nós adicionados nos pools de nós 1 e 2. O autoscaler avalia que o pool de nós 1 tem uma prioridade mais alta do que o pool de nós 2. Portanto, o autoscaler seleciona o pool de nós 1 para expansão.