Container Won't Schedule? Check Node Resources First

You're running a container orchestrator—Kubernetes, Docker Swarm, or Nomad. You push a job, and it just sits there. Pending. No progress. Maybe you see events like 0/3 nodes are available or pod failed to allocate. Happens most often when you're scaling up a service or deploying after a reboot. I had a client last month whose entire Node.js app cluster stalled because one node ran out of memory while another had disk pressure.

What's Actually Happening?

The orchestrator assigns containers to nodes based on available resources—CPU, memory, disk space, and sometimes GPU. If no node has enough free of any of these, the container stays pending. It's not a bug. It's the cluster saying "I literally can't fit this." The most common culprit? Resource limits. You set a memory limit of 1GB for a container, but each node only has 512MB free. Or you forgot to set CPU requests, so the container gets starved.

The Fix: Step by Step

1. Check pod events. Run kubectl describe pod <pod-name> (K8s) or docker service ps <service-name> (Swarm). Look for warnings like Insufficient memory or node(s) had taint. Real example: a client's event said 0/3 nodes are available: 3 node(s) had taint {node.kubernetes.io/disk-pressure: }—one node had a nearly full disk.
2. Check node health. Use kubectl top nodes to see CPU and memory usage. Or df -h on each node for disk space. If a node shows DiskPressure or MemoryPressure, free up resources. Clear old logs: sudo journalctl --vacuum-size=200M. Remove unused images: docker image prune -a.
3. Remove taints if they don't apply. Taints are like "this node is special" markers. If your node has node.kubernetes.io/disk-pressure, you can remove it with kubectl taint nodes <node-name> node.kubernetes.io/disk-pressure-. But only do this after fixing the disk issue. Otherwise, it comes back.
4. Adjust resource requests and limits. Open your deployment YAML. Set requests.memory and requests.cpu to realistic values. For example, if a container needs 512MB, set memory: 512Mi. Don't set limits way higher than requests—that wastes cluster space. A simple fix: requests: memory: "256Mi" cpu: "250m".
5. Scale nodes or add more. If you're maxed out, add another worker node. In cloud setups, enable auto-scaling. For bare metal, you might need to add a machine or move some containers.

Still Stuck? Check These

• Pod anti-affinity rules. If you have rules that prevent pods from running on the same node, the scheduler might have no valid target. Check your pod's affinity section.
• Node selectors. If you set nodeSelector: disktype: ssd and no node has that label, the container won't schedule. Run kubectl get nodes --show-labels to verify.
• Resource quota. Namespace quotas can block scheduling even if nodes have capacity. kubectl describe quota -n your-namespace shows limits.
• Version mismatch. If nodes run different orchestrator versions, the scheduler might refuse to place containers. Upgrade all nodes to match.

Remember: 90% of scheduling failures are resource-related. Don't overthink it. Check node capacity, fix disk pressure, and tighten your resource requests. That's the real fix.