APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
O scheduler usa pedidos de recursos e restrições para escolher um node elegível. Um gráfico com CPU pouco utilizada não demonstra capacidade suficiente para novos pedidos já comprometidos. Requests e limits respondem a perguntas diferentes: colocação e partilha de recursos, por um lado, e limites de consumo, por outro. Em Linux, um limite de CPU pode causar throttling, enquanto falta de memória pode terminar um processo. Usa unidades explícitas: 500m de CPU corresponde a 0,5 CPU; 512Mi é uma quantidade de memória. Os exemplos desta aula usam pedidos por contentor, sem orçamento ao nível do Pod, init containers ou overhead adicional, para tornar a aritmética verificável.
Aplicação guiada
Num exercício fictício, um node tem 1800m disponíveis para novos pedidos e cada Pod pede 450m. Cabem quatro pelo critério de CPU, se memória e restantes condições também permitirem. Cinco excedem esse orçamento, mesmo durante um período de pouco uso. Quando PodScheduled é false, lê os eventos do scheduler antes de baixar requests. Um taint NoSchedule exige toleration correspondente; essa toleration remove uma restrição, mas não garante colocação nem seleciona exclusivamente o node. Labels, affinity, armazenamento e capacidade continuam relevantes. Se uma aplicação foi agendada mas espera pela imagem, aumentar capacidade não corrige necessariamente o problema. Pending inclui situações diferentes; distingue fase geral, condições e estado de cada contentor.
1800m / 450m = quatro Pods pelo critério de CPU; não é garantia de colocação global.
Armadilhas comuns
Utilização baixa como pedidos livres; toleration como reserva; Pending como causa única.
Tópicos relacionados: Workloads e estado desejado · Tráfego e probes · Configuração e dados
Decide com pedidos, capacidade e eventos da restrição efetiva.
Referência: Requests limits and scheduling · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed