Kubernetes - Por que meu Pod fica em Pending?

Seu Pod está em Pending, mas o kubectl top nodes mostra a CPU quase parada? Neste vídeo, eu reproduzo esse cenário num laboratório com kind e mostro por que isso acontece, e como esse comportamento pode inflar a sua conta de cloud. O ponto central: o scheduler do Kubernetes decide onde colocar cada Pod pelos requests, e não pelo uso real. Se os requests estão superdimensionados (ou se você definiu só o limit, e o Kubernetes copiou esse valor para o request), o cluster parece cheio estando ocioso. Na nuvem, o autoscaler cria nós novos para Pods que não usam nada. 📌 Neste vídeo: O paradoxo: nós ociosos e Pods em Pending Request x Limit Como o scheduler decide (filtragem e pontuação) O cenário do laboratório com kind Reproduzindo o problema A conta do scheduler em um worker Por que isso pesa na nuvem Rightsizing, bin packing e autoscaler Comandos usados no lab: kubectl top nodes kubectl get pods -o wide kubectl describe pod [pod-em-pending] kubectl describe node worker kubectl get pod [pod] -o yaml 💡 Para levar para o seu ambiente: Compare o request dos Pods com o uso real Defina o request explicitamente, não só o limit Confira o Pod criado, não só o manifest aplicado 🔗 Links: Blog IceNex (tutoriais e labs de infraestrutura, DevOps, Kubernetes e SRE): https://www.icenex.io E-books, templates e checklists de arquitetura, cloud, DevOps, dentre outros: https://store.icenex.io Landora, para criar a landing page do seu negócio: https://landora.icenex.io E você, como define os requests dos seus Pods hoje: teste de carga, recomendação do VPA, histórico de métricas ou um "chute calibrado"? Conta nos comentários. #Kubernetes #FinOps #DevOps