A scale-from-zero workflow works for some workloads and later one class of pods remains pending despite enough node templates existing.
A Karpenter or autoscaler scale-from-zero path stalls
The pod becomes schedulable after mutation, yet the provisioning decision was already made against the pre-mutated spec.
Scenario
What to check first
- Identify the primary failure signal in the The Pod Learned the Right Toleration After the Provisioner Had Already Given Up scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Compare pre- and post-admission pod specs before editing node pools or taints.
Questions worth viewing together
Community-field Kubernetes problem inspired by autoscaler and webhook discussions where provisioning never saw the post-mutation toleration set. Provisioning decisions can be made on an earlier pod shape than the one you inspect later.
Teams often blame autoscaler capacity when admission mutation is what changed the scheduling contract after the decision point.
Any admission mutation that affects scheduling should be validated against scale-from-zero provisioning logic.
Similar cases seen in the field