APRENDER. PRATICAR. EVOLUIR.Localizar a fase da falha
Um pedido de criação pode ser recusado antes de produzir um Pod, ou ser aceite e ficar sem colocação. O laboratório apresenta ambos os resultados. No primeiro caso, o cliente recebe Forbidden por uma restrição de admissão e a consulta seguinte confirma que o objeto não existe. No segundo, existe um Pod Pending com PodScheduled=false e motivo Unschedulable. Estas diferenças orientam a investigação: não se procura um crash de processo quando nenhum processo arrancou, nem se altera o scheduler para resolver uma quota que rejeita a criação. Guarda a mensagem concreta e verifica a existência do objeto no contexto e namespace certos.
Selector sem node correspondente
O Pod placement pede um label de pool que não existe no único node do ensaio. O scheduler mantém o objeto Pending e a mensagem refere incompatibilidade de node affinity ou selector. O guião não altera labels do node para forçar sucesso. Primeiro tenta mudar o nodeSelector do Pod existente e observa a rejeição desse campo nesta operação. Depois remove apenas o Pod sintético e cria uma declaração corrigida que corresponde ao hostname do node; a aplicação arranca. Esta substituição controlada serve o laboratório. Num Deployment real, a mudança deve incidir no template gerido e respeitar o plano de rollout e disponibilidade.
Um pedido maior do que a capacidade
Outro Pod pede mais uma CPU do que o allocatable total observado no node. A memória e a imagem mantêm-se pequenas, mas o scheduler indica Insufficient cpu e não atribui node. O processo não é executado e não se tenta consumir a quantidade pedida. O objetivo é testar a decisão de colocação, não saturar o computador. Requests são compromissos usados nessa decisão; um gráfico de utilização instantânea baixo não elimina a insuficiência de capacidade pedida. Compara ainda restrições de colocação e recursos já comprometidos. Uma redução de request só deve seguir medição e aprovação apropriadas, evitando tornar o manifesto executável à custa de um orçamento irrealista.
Defaults que passam a fazer parte do objeto
Num segundo namespace, um LimitRange fornece request de CPU de 50m e limit de 100m aos contentores sem esses valores. A memória recebe request de 32Mi e limit de 64Mi. O guião lê o Pod guardado e confirma os valores acrescentados durante admissão. Assim, o YAML inicialmente enviado pode não mostrar todos os recursos que contam depois. O mesmo LimitRange define máximo de CPU de 200m; um Pod com limit de 250m é recusado e não fica criado. Confirma defaults e limites efetivos antes de atribuir uma diferença ao scheduler, à aplicação ou ao gerador de manifestos.
Quota agregada e libertação de orçamento
A ResourceQuota limita requests.cpu a 100m no namespace do ensaio. O primeiro Pod consome 50m desse orçamento; o segundo, criado sem recursos explícitos, recebe os defaults e leva o uso a 100m. O terceiro pede outros 50m e recebe exceeded quota. Não fica Pending: não existe. Depois de remover o primeiro Pod e observar uso de 50m, o guião volta a criar o terceiro, que arranca sem aumentar a quota. A contagem representa requests aceites no âmbito configurado, não CPU medida. A libertação de orçamento no namespace também não garante capacidade física ou elegibilidade em todos os nodes de outro ambiente.
Planear a entrega com o orçamento efetivo
Num cenário fictício de migração de uma API, três réplicas estáveis podem caber no orçamento e uma réplica adicional de rollout pode não caber. Usa requests efetivos depois dos defaults, número de réplicas durante a transição e recursos de outros workloads no mesmo âmbito. Identifica também quem aprova alterações à quota e como se confirma capacidade elegível. O ensaio não mede uma carga de produção nem executa um rollout com surge; fornece observações pequenas para construir esse raciocínio. A passagem para RUN deve incluir restrições, sinais de falha, responsáveis e a ação prevista quando admissão ou agendamento impedem o progresso.
kubectl --context OWNED -n LAB get pod placement -o json
kubectl --context OWNED -n LAB describe pod placement
kubectl --context OWNED -n LAB get resourcequota,limitrange -o yaml
# Compare the rejection message, object existence and PodScheduled condition.
# Quota usage is not a measurement of instantaneous CPU utilization.Dois Pods com requests de 50m preenchem uma quota de 100m; o terceiro é rejeitado antes de existir, mesmo que o node tenha capacidade.
Armadilhas comuns
Forbidden como RBAC em todos os casos; Pending como falta de CPU; quota como reserva física; alterar diretamente campos imutáveis do Pod.
Tópicos relacionados: Recursos e agendamento · Acesso mínimo para suporte
Relaciona cada falha com a fase correta: autorização e admissão, colocação, arranque e aceitação funcional.
Referência: Resource quotas · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed