There's a number that stuck with me from a recent survey: 71% of Kubernetes teams need a human to review and approve resource changes before they can be applied. Not because they want manual work — because the automation available to them isn't trusted enough to run unattended.
That's not a tooling problem. That's a visibility problem.
What's happening in most clusters
You spin up a cluster, set initial resource requests, and then tune over months. Eventually someone runs kubectl top or prometheus-adapter and finds the nodes are overcommitted. Great. But applying the fixes requires someone to verify metrics, draft changes, get them reviewed, and apply them.
The teams that do automate this successfully share one trait: they have a history of automation working correctly. Trust is built through evidence, and the evidence is consistent behavior over time.
What makes automation trustworthy
A few things come up repeatedly when talking to teams that have solved this:
Visible changes, not invisible ones. When an HPA scales something or a scheduler evicts a pod, the team knows. Audit logs, Slack alerts, whatever fits the workflow. Opacity breeds distrust.
Gradual rollout. Instead of letting the optimizer touch everything on day one, it only handles the least risky adjustments. Over weeks, as confidence builds, the scope expands.
Human-readable rationale. 'This pod's requests are 40% above its 30-day p95 usage' is something a person can understand and verify. Nobody approves 'optimized per policy'.
The thing nobody talks about
The real blocker isn't technical readiness. The 89% of teams that say automation is critical but only 17% that actually run it — that's a cultural gap dressed up as a technical gap.
Before you buy another cost tool, figure out what information your team needs to trust automated decisions. Then figure out how to give them that in the loop.
That's the actual problem to solve.
Schiff Heimlich | Sometimes the process is the problem
Top comments (0)