Container Service for Kubernetes:Scheduling FAQ

Como evitar falhas na inicialização de Pods por falta de endereços IP em um vSwitch?

O agendador nativo do Kubernetes não visualiza os endereços IP disponíveis em um nó. Pods agendados em nós com recursos de IP esgotados falham na inicialização, gerando frequentemente muitos Pods anormais.

O ACK Scheduler resolve essa questão com o agendamento ciente de IP. Ele lê a anotação k8s.aliyun.com/max-available-ip em cada nó para limitar a quantidade de Pods que exigem um IP independente. Se um nó ficar sem recursos de IP, o ACK Scheduler define uma condição SufficientIP no status do nó, impedindo o agendamento de novos Pods dependentes de IP nesse local.

O add-on kube-scheduler ativa esse recurso automaticamente. Seu cluster deve atender aos seguintes requisitos:

• O cluster deve ser um cluster gerenciado ACK Pro Edition com Terway v1.5.7 ou posterior. Consulte Crie um cluster gerenciado ACK.

• A versão do kube-scheduler deve atender aos seguintes requisitos:

Qual é a política de agendamento padrão do ACK Scheduler?

O ACK Scheduler segue a mesma política padrão do agendador do Kubernetes da comunidade. O agendamento envolve duas etapas:

• **Filtragem:** Elimina os nós onde o Pod não pode executar. Se nenhum nó passar pela filtragem, o Pod permanecerá não agendável.

• **Pontuação:** Classifica os nós restantes e seleciona o mais adequado para o Pod.

Todos os plug-ins de filtragem e pontuação ativados na versão mais recente do ACK Scheduler estão listados em kube-scheduler.

Como evitar o agendamento de Pods em nós com alta utilização de recursos?

O agendador nativo do Kubernetes utiliza solicitações de recursos, e não a utilização real. Isso pode sobrecarregar alguns nós enquanto outros permanecem ociosos. O ACK oferece três abordagens:

• Defina solicitações e limites de recursos precisos. Use a análise de perfil de recursos para obter recomendações de especificação de contêineres com base no uso histórico.

• Ative o agendamento ciente de carga. O ACK Scheduler considera a carga real do nó, analisa dados históricos, estima os requisitos dos Pods recebidos e aloca os Pods em nós com menor utilização. Consulte Agendamento ciente de carga.

• Ative o desescalonamento de hotspots ciente de carga. Conforme o tráfego e as cargas de trabalho mudam, alguns nós podem ficar sobrecarregados. O desescalonador do ACK detecta hotspots e remove Pods para restaurar o equilíbrio. Consulte Uso do desescalonamento de hotspots ciente de carga.

Um novo nó foi adicionado ao cluster. Por que os Pods não são agendados nele?

Verifique os itens a seguir nesta ordem:

1. Status do nó: O agendador ignora nós com status NotReady. Aguarde até que o nó esteja Ready.

2. Restrições de agendamento no Pod: Verifique se existem regras de nodeSelector, nodeAffinity ou podAffinity no Pod, ou se há taints no nó que o Pod não tolera.

3. Desequilíbrio nas solicitações de recursos: O agendador usa as solicitações de recursos, não a utilização real. Se os nós existentes tiverem capacidade solicitada livre suficiente, o novo nó poderá permanecer sem uso. Consulte Como evitar o agendamento de Pods em nós com alta utilização de recursos?.

Por que o agendamento falha por insuficiência de CPU ou memória mesmo com baixa utilização geral do cluster?

O agendador avalia os recursos solicitados, e não o consumo real. Um nó com baixo uso de CPU pode parecer "cheio" se seus Pods tiverem solicitações de recursos elevadas. O agendamento falha quando nenhum nó individual possui capacidade solicitada suficiente para o novo Pod, mesmo que a utilização geral do cluster esteja baixa.

Consulte Como evitar o agendamento de Pods em nós com alta utilização de recursos?.

O que preciso saber antes de usar o desescalonamento no ACK? Ele reinicia os Pods?

O ACK fornece o desescalonamento por meio do Koordinator Descheduler. Considere dois pontos importantes:

• O desescalonamento apenas remove Pods. O Koordinator Descheduler remove Pods em execução, mas não os recria. O controlador de carga de trabalho (Deployment, StatefulSet etc.) cuida da recriação, e o agendador aloca o novo Pod.

• Mantenha réplicas suficientes. O Pod antigo é removido antes que o novo seja iniciado. Garanta que sua carga de trabalho tenha replicas suficientes para permanecer disponível durante a remoção.

Consulte Desescalonamento.

Como agendar uma aplicação em um nó específico?

Adicione um rótulo ao nó de destino e um nodeSelector correspondente à especificação do Pod da sua aplicação. Consulte Agendar uma aplicação em um nó específico.

Em um Deployment, como agendar um número específico de Pods para ECS e outro para ECI?

Use o UnitedDeployment para definir subconjuntos separados para ECS e ECI. Por exemplo, defina replicas: 10 no subconjunto ECS e replicas: 10 no subconjunto ECI. Consulte Dimensionar cargas de trabalho com base no UnitedDeployment.

Como garantir alta disponibilidade para os Pods de uma carga de trabalho durante o agendamento?

Use podAntiAffinity para distribuir os Pods entre zonas ou nós. Por exemplo, a configuração a seguir agenda Pods com o rótulo security=S2 em zonas diferentes. Se a restrição não puder ser atendida, o agendador recorrerá a outros nós.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone

A documentação do Kubernetes também aborda afinidade e anti-afinidade de Pods e restrições de distribuição de topologia de Pods.

Como migrar do ack-descheduler para o Koordinator Descheduler?

O add-on ack-descheduler foi descontinuado. Migre para o Koordinator Descheduler seguindo as mesmas etapas usadas para o Kubernetes Descheduler. Consulte Migrar do Kubernetes Descheduler para o Koordinator Descheduler e [\[Aviso\] Migração do ack-descheduler](t2735863.xdita#).

O add-on ack-descheduler no marketplace do ACK é baseado no Kubernetes Descheduler open source. As versões 0.20.0 e 0.27.1 correspondem às respectivas versões open source.

Por que nem todos os Pods de um lote são agendados no nó com menor carga?

Alocar todos os novos Pods no nó com menor carga criaria um hotspot. O plug-in de agendamento ciente de carga ajusta a pontuação de um nó quando ele possui Pods recém-agendados cuja utilização ainda não foi reportada, evitando concentração excessiva e equilibrando a carga entre os nós.

Além da carga do nó, quais outros fatores afetam os resultados do agendamento?

O agendador do Kubernetes utiliza vários plug-ins — regras de afinidade, restrições de distribuição de topologia, entre outros — que contribuem para a classificação final dos nós. Ajuste os pesos de pontuação dos plug-ins de acordo com suas necessidades.

Após atualizar o agendador, o recurso de agendamento ciente de carga que usa o protocolo antigo ainda é suportado?

O protocolo antigo exige a anotação alibabacloud.com/loadAwareScheduleEnabled: "true" nos Pods. O ACK Scheduler mantém compatibilidade retroativa; portanto, a atualização não interrompe os Pods existentes. Após a atualização, mude para a política global de agendamento ciente de carga para evitar o gerenciamento de anotações por Pod.

As tabelas a seguir resumem o suporte ao protocolo por versão do cluster.

Após ativar a configuração de CPU Burst, por que meus Pods ainda sofrem limitação?

Várias condições podem fazer com que a limitação de CPU persista:

• Formato de configuração incorreto. Uma política de CPU Burst mal configurada não surte efeito. Verifique o formato. Consulte Configuração avançada de parâmetros.

• Utilização de CPU no limite. Se o uso real de CPU atingir o limite de cfsQuotaBurstPercent, a limitação persistirá devido à insuficiência de recursos físicos de CPU. Ajuste os valores de solicitação e limite para corresponder às necessidades reais.

• Latência no ajuste de cpu.cfs_quota_us. O CPU Burst modifica cpu.cfs_quota_us e cpu.cfs_burst_us. O valor de cpu.cfs_quota_us atualiza somente após o ack-koordinator detectar a limitação, o que introduz um atraso. Já o valor de cpu.cfs_burst_us é definido imediatamente. Para obter melhores resultados, use este recurso com o Alibaba Cloud Linux.

• Limiar de segurança do nó acionado. O CPU Burst redefine cpu.cfs_quota_us para a linha de base se a utilização do nó exceder o limiar sharePoolThresholdPercent. Ajuste o limiar conforme suas necessidades.

O Alibaba Cloud Linux é obrigatório para a política de CPU Burst?

Não. O CPU Burst funciona em todos os kernels do Alibaba Cloud Linux e CentOS. O Alibaba Cloud Linux é recomendado porque o ack-koordinator aproveita recursos no nível do kernel para oferecer uma elasticidade de CPU mais refinada. Consulte Ativar o recurso CPU Burst na interface cgroup v1.

Por que o uso de memória aumenta repentinamente após uma aplicação usar recursos Batch?

Para contêineres com limite de memória Batch (kubernetes.io/batch-memory), o ack-koordinator define o limite de memória do cgroup após a inicialização do contêiner. Se a aplicação ler o limite do cgroup na inicialização — antes de o ack-koordinator aplicá-lo — ela poderá alocar mais memória do que o previsto. O sistema operacional não recupera essa memória imediatamente, então o limite só é imposto quando o uso cai abaixo dele.

Para resolver isso, ajuste a aplicação para manter-se abaixo do limite Batch ou garanta que o parâmetro de limite de memória seja definido antes da inicialização da aplicação.

Visualize o limite atual de memória (em bytes) dentro do contêiner:

# The unit is bytes.
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
# Expected output.
1048576000

Por que o desempenho diminui e a limitação de CPU aumenta após ampliar o número de núcleos de CPU?

O recurso de overcommitment dinâmico de recursos do protocolo legado ack-slo-manager será suportado após a atualização para o ack-koordinator?

Sim. O ack-koordinator é compatível. O protocolo antigo usa dois componentes na especificação do Pod:

• A anotação alibabacloud.com/qosClass

• O recurso alibabacloud.com/reclaimed nas solicitações e limites

O ack-koordinator reconhece ambos os protocolos e calcula as solicitações e a disponibilidade de recursos de forma uniforme. Atualize o add-on sem precisar modificar imediatamente as configurações existentes dos Pods.

O suporte ao protocolo antigo termina em 30 de julho de 2023. Atualize os parâmetros de recursos para a versão mais recente o quanto antes.

A tabela a seguir mostra o suporte ao protocolo por versão do agendador e do ack-koordinator:

O recurso CPU Burst do protocolo legado ack-slo-manager será suportado após a atualização para o ack-koordinator?

Sim. O protocolo antigo utiliza a anotação alibabacloud.com/cpuBurst. O ack-koordinator é totalmente compatível e lida com a atualização de forma transparente.

O suporte ao protocolo antigo termina em 30 de julho de 2023. Atualize para o protocolo atual o quanto antes.

O recurso CPU QoS do protocolo legado ack-slo-manager será suportado após a atualização para o ack-koordinator?

Sim. O protocolo antigo (versão 0.8.0 e anteriores) ativa o CPU QoS por meio da anotação alibabacloud.com/qosClass. O ack-koordinator mantém a compatibilidade e suporta a migração gradual para o protocolo koordinator.sh.

A compatibilidade retroativa termina em 30 de julho de 2023. Migre seus Pods para o novo protocolo prontamente.

O recurso de QoS de memória de contêiner será suportado após a atualização do protocolo legado ack-slo-manager para o ack-koordinator?

Sim. O protocolo antigo (versão 0.8.0 e anteriores) usa as anotações alibabacloud.com/qosClass e alibabacloud.com/memoryQOS. O ack-koordinator mantém compatibilidade retroativa com ambas.

A compatibilidade retroativa termina em 30 de julho de 2023. Migre para o protocolo atual o quanto antes.

A utilização do nó atingiu o limiar, mas os Pods não estão sendo removidos. O que fazer?

Por que o desescalonador reinicia frequentemente?

Isso geralmente indica que o ConfigMap do desescalonador está ausente ou mal configurado. Corrija o ConfigMap e reinicie o desescalonador. Consulte Parâmetros de configuração avançada.

Como usar o agendamento ciente de carga e o desescalonamento de hotspots juntos?

Ative ambos os recursos e alinhe seus limiares. Quando a carga de um nó exceder highThresholds, os Pods serão removidos. Defina loadAwareThreshold com o mesmo valor de highThresholds para evitar que os Pods removidos sejam reagendados no mesmo nó sobrecarregado — algo especialmente importante em clusters com poucos nós e utilização semelhante.

Consulte Usar agendamento ciente de carga e Descrição da política.

Qual algoritmo de utilização o desescalonador usa?

O desescalonador calcula a média de utilização em uma janela contínua e aciona a ação apenas quando a média excede o limiar por um período prolongado (padrão: ~10 minutos). Os cálculos de memória excluem o cache de páginas, que o sistema operacional pode recuperar. Em contraste, o comando kubectl top node inclui o cache de páginas. Para visualizar a linha de base de memória do desescalonador, use o Alibaba Cloud Prometheus.

Durante um teste de estresse com wrk, o resultado mostra "Socket errors: connect 54,". O que fazer?

O cliente wrk esgotou as conexões TCP. Ative a reutilização de conexões TCP na máquina de teste de estresse.

1. Verifique se a reutilização de conexões TCP está ativada:

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   Uma saída de 0 ou 2 indica que a reutilização de TCP não está totalmente ativada.

2. Ative a reutilização de conexões TCP:

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. Execute novamente o teste wrk. A mensagem Socket errors: connect 54, ... não deve mais aparecer.

Esses comandos aplicam-se apenas à máquina de teste de estresse. Após o teste, restaure a configuração original com sysctl -w net.ipv4.tcp_tw_reuse=<original_value> .

Por que nenhum dado é exibido na seção de benefícios de colocation do cluster na aba k8s-reclaimed-resource?

1. Verifique se o ack-koordinator está instalado:

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

   2. Clique no nome do cluster. No painel de navegação à esquerda, escolha Applications > Helm.

   3. Na página Helm, verifique se o ack-koordinator está listado. Caso contrário, instale-o. Consulte Instale e gerencie add-ons.

2. Se o painel de colocation não mostrar dados, verifique se a métrica kube_node_labels está sendo coletada:

   1. Faça login no console ARMS.

   2. No painel de navegação à esquerda, escolha Managed Service for Prometheus > Instances.

   3. Selecione a região, clique em no nome da instância do Prometheus e clique em Metric Management.

   4. Clique em Metrics, pesquise por kube_node_labels e verifique se a métrica possui dados.

Posso usar instâncias preemptíveis baseadas em Arm?

Sim. Consulte Usar instâncias spot.

Quais são as limitações de usar nós baseados em Arm em um cluster ACK?

Na página Add-ons, apenas as seguintes categorias de add-ons suportam a arquitetura Arm:

• Componentes principais

• Logs e monitoramento

• Armazenamento

• Rede

Add-ons do marketplace não suportam a arquitetura Arm.