Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Descheduling overview

Última atualização: Sep 21, 2026

Descheduling é o processo de reagendar pods que correspondem às regras de despejo em um nó para outro nó. Em cenários onde existem nós hotspot devido à desigualdade de recursos no cluster, ou quando pods não conseguem ser agendados conforme a política predefinida por causa de mudanças nos atributos dos nós, use o descheduling para otimizar o uso de recursos e direcionar os pods para os nós ideais. Isso garante a alta disponibilidade e a eficiência das cargas de trabalho no cluster.

Antes de começar

Recomendamos que você observe os itens a seguir antes de utilizar o descheduling.

Após ler este tópico, você terá acesso às seguintes informações sobre descheduling:

  • Os cenários de uso do descheduling.

  • O fluxo de trabalho do descheduling.

  • Termos relacionados ao descheduling, incluindo templates de descheduling, as políticas Deschedule e Balance, e os evictors DefaultEvictor e MigrationController.

Por que o descheduling é importante

O Kubernetes Scheduler agenda pods nos nós adequados com base no status atual do cluster. No entanto, esse status muda constantemente. Em alguns cenários, é necessário migrar pods em execução para outros nós. Exemplos:

  • As cargas de trabalho no cluster estão distribuídas de forma desigual. Alguns nós ficam sobrecarregados, o que compromete seu desempenho.

  • A utilização geral de recursos do cluster é baixa e você deseja remover alguns nós para reduzir custos. Para isso, é necessário migrar os pods desses nós para outros nós primeiro.

  • O cluster contém grandes quantidades de fragmentos de recursos. Como resultado, um nó pode não ter recursos ociosos suficientes, mesmo que o total de recursos do cluster ainda seja adequado. Nesse cenário, pods que solicitam grandes quantidades de recursos falham no agendamento, aumentando ainda mais os custos com recursos do cluster.

  • Taints ou rótulos são adicionados a um nó ou removidos dele. Nesse caso, alguns pods no nó deixam de corresponder à regra de affinity e precisam ser migrados para um nó cuja regra de affinity seja compatível com eles.

Por exemplo, uma aplicação pode ter cargas de trabalho variáveis em diferentes momentos. Durante os horários de pico, podem surgir nós hotspot, comprometendo ainda mais a qualidade do service da aplicação. Para resolver esse problema, o recurso de descheduling pode despejar pods com comportamento anômalo a fim de reduzir a carga do nó hotspot e garantir a qualidade do service.

Para atender a esse objetivo, o ack-koordinator disponibiliza um módulo de descheduling chamado Koordinator Descheduler, que é executado como um Deployment nos nós. O Koordinator Descheduler é desenvolvido com base no Descheduling Framework do Kubernetes Descheduler e é compatível com todas as políticas de descheduling do Kubernetes Descheduler. O Koordinator Descheduler também otimiza o descheduling de pods em termos de políticas de descheduling, métodos de despejo de pods, controle de tráfego de despejo e processos de despejo. Para obter mais informações sobre as diferenças entre o Koordinator Descheduler e o Kubernetes Descheduler, consulte Koordinator Descheduler and Kubernetes Descheduler.

Fluxo de trabalho do descheduling

O Koordinator Descheduler opera de forma periódica. Configure múltiplas políticas de descheduling para filtrar, verificar e despejar pods que atendam às condições de despejo. A figura a seguir ilustra o funcionamento do Koordinator Descheduler.

image
  1. Percorra os templates de descheduling e execute a política Deschedule ativada em cada template, em sequência.

    1. Obtenha informações sobre nós, cargas de trabalho e pods.

    2. Confronte os pods com as regras do Deschedule.

    3. Filtre, verifique e ordene os pods que atendem às regras de despejo.

    4. O pod evictor ativado no template de descheduling envia uma requisição de despejo de pod.

  2. Percorra os templates de descheduling novamente e execute a política Balance ativada em cada template, em sequência. O fluxo de trabalho é semelhante ao Passo 1.

As seções a seguir descrevem os termos utilizados no fluxo de trabalho do descheduling.

Template de descheduling

Configure um ou mais templates de descheduling para atender a diferentes requisitos. Em cada template, especifique a política de descheduling e o pod evictor a serem usados, defina o escopo de aplicação e configure parâmetros avançados para um tipo específico de pod.

O uso de políticas de descheduling permite aplicar diferentes políticas de despejo de pods em cenários distintos. Por exemplo, para despejar pods expirados com diferentes TTLs em namespaces diferentes, configure múltiplos templates de descheduling e defina um limiar de TTL para os pods em cada namespace.

Durante o processo de descheduling, o Koordinator Descheduler percorre todos os templates de descheduling e executa a política Deschedule em cada template. Após a execução de todas as políticas Deschedule, o Koordinator Descheduler percorre os templates novamente e executa a política Balance em cada template.

Políticas de descheduling: Deschedule e Balance

Há duas políticas de descheduling disponíveis: Deschedule e Balance. As políticas de descheduling identificam os pods a serem despejados. Para obter mais informações sobre como configurar as políticas de descheduling e os recursos suportados por cada política, consulte Apply the configuration.

  • Deschedule: o Koordinator Descheduler confronta cada pod com a restrição de agendamento atual e despeja os pods correspondentes em sequência. Por exemplo, o Koordinator Descheduler despeja pods que não correspondem à regra de node affinity ou anti-affinity, um após o outro.

  • Balance: o Koordinator Descheduler otimiza a distribuição de determinados pods ou de todos os pods no cluster e decide quais pods serão despejados. Por exemplo, o Koordinator Descheduler despeja pods de nós hotspot com base na utilização de recursos dos nós.

As políticas de descheduling são independentes entre si. O Koordinator Descheduler executa cada política para despejar pods com base em suas regras de despejo, filtrando, verificando e ordenando os pods correspondentes. Restrições como capacidade do cluster, utilização de recursos e número de réplicas são consideradas ao confrontar os pods com as regras de despejo. Após decidir quais pods serão despejados, o Koordinator Descheduler envia uma requisição ao pod evictor para efetuar o despejo.

Evictors e controle de despejo

Os evictors no Koordinator Descheduler são responsáveis pelo despejo de pods. Os seguintes evictors estão disponíveis: DefaultEvictor e MigrationController.

  • DefaultEvictor: um pod evictor básico que permite limitar o número máximo de pods a serem despejados. Use e configure o DefaultEvictor da mesma forma que no Kubernetes Descheduler. Para obter mais informações, consulte DefaultEvictor.

  • MigrationController: permite despejar e migrar pods de forma segura, além de rastrear o despejo de pods. Para obter mais informações sobre os parâmetros, consulte MigrationController.

Para obter mais informações sobre a diferença entre os dois evictors, consulte Enable the descheduling feature.

Ativar o descheduling

Para obter mais informações sobre como instale o componente ack-koordinator e ative o descheduling, consulte Enable the descheduling feature.

Configure também parâmetros avançados para o Koordinator Descheduler, templates de descheduling, plug-ins de política de descheduling e plug-ins de evictor em um ConfigMap. Para obter mais informações, consulte Configure advanced parameters.

Referências

  • Se você utiliza o Kubernetes Descheduler, recomendamos migrar para o Koordinator Descheduler. Para obter mais informações sobre as diferenças e o processo de migração para o Koordinator Descheduler, consulte Koordinator Descheduler and Kubernetes Descheduler.

  • O recurso de descheduling é desenvolvido com base no Koordinator Descheduler do componente ack-koordinator. Instale e use o componente ack-koordinator sem custo. No entanto, esse componente pode gerar cobranças em determinados cenários. Para obter mais informações, consulte Billing.