A recent survey hit on something I see all the time in cluster work: teams know they need automation, but 71% still require human review before any resource changes get applied. The 48% who said visibility and transparency would increase trust in automation? That's the actual problem.
When you're asking someone to approve a change they can't verify, you're not going to get buy-in. This isn't about trust in the automation algorithm. It's about trust in the person asking them to approve it blindly.
The Typical Breakdown
You've got a team running Kubernetes. Someone writes a script to right-size resource requests based on actual usage. It looks at historical CPU and memory patterns, spits out new resource specs, and... gets stuck in approval limbo because no one understands why the automation thinks a pod needs 200m CPU instead of 500m.
The reviewer sees: spec.containers[0].resources.requests.cpu: 500m → 200m
The automation sees: 6 weeks of P95 usage at 180m, with headroom for burst
No visibility into the reasoning = no approval.
What Actually Helps
1. Output the analysis, not just the result
Instead of:
apiVersion: v1
kind: Pod
spec:
containers:
- name: app
resources:
requests:
cpu: 200m
Generate:
# Analysis for app pod (namespace: production)
# Current request: 500m CPU, 512Mi memory
#
# Usage data (30 days):
# CPU P50: 120m | P95: 175m | P99: 210m
# Memory P50: 280Mi | P95: 420Mi | P99: 480Mi
#
# Recommendation: 250m CPU, 512Mi memory
# Rationale: P95 usage is 175m, recommending 250m for headroom
# Memory looks fine at current 512Mi (P99 is 480Mi)
apiVersion: v1
kind: Pod
spec:
containers:
- name: app
resources:
requests:
cpu: 250m
2. Diff-friendly output
Format recommendations as patches or diffs that are easy to review in Git:
# kubectl-automation-analyze namespace production --format=diff
- apiVersion: v1
kind: Deployment
metadata:
name: app
spec:
template:
spec:
containers:
- name: app
resources:
requests:
- cpu: 500m
+ cpu: 250m
3. Dry-run by default
Never apply automatically. Even if your team trusts the automation, give them the option to review. A --auto-approve flag they can enable after watching it run for a week does more for adoption than any documentation.
The Real Takeaway
The automation gap exists because we treat "more automation" as the goal. But if your team can't see what the automation is doing, they'll default to manual review every time.
The fix isn't better algorithms. It's better output. Give people the data, show your work, and let them make an informed decision. That's not less automation - that's automation people actually use.
