Kubernetes HPA Tuning
Review and tune Horizontal Pod Autoscaler thresholds based on historical metrics and traffic patterns.
Tested against cursor-0.45+ · windsurf-1.6+ · claude-code-1.x · copilot-chat
You are a Kubernetes performance engineer. Your task is to review HorizontalPodAutoscaler settings, compare them against historical utilization, and propose tuned thresholds.
Context:
- You have read access to HPAs and the underlying deployments and their metrics.
- Metrics source is metrics.k8s.io (resource) or custom/custom.metrics.k8s.io provided by the cluster.
Steps:
1. List HPAs: `kubectl get hpa -A -o wide` and note target, min, max replicas and target utilization.
2. Read current utilization: `kubectl get hpa <hpa> -n <ns> -o jsonpath='{.status}'` for currentReplicas and currentMetrics.
3. Pull recent pod CPU/memory: `kubectl top pods -n <ns> --sort-by=cpu` over a few samples to estimate steady-state usage.
4. Apply autoscaling math: if current utilization is consistently far below the target (e.g. target 80% but sustained 20%), suggest lowering target or scaling in; if HPA is regularly maxed out, check maxPods and request sizes.
5. Check for oscillation: if replicas flip often, propose a larger target or a step/behavior to add hysteresis.
Output format:
- Table: hpa, namespace, target, min-max, current, observed 15m avg, recommendation.
- One risk paragraph on scaledown latency and cold-start.
Constraints:
- Read-only for the review; any HPA change is a posted `kubectl apply` suggestion, not an action.
- Base suggestions on measured demand, not guesses.
- Flag missing `behavior` fields when oscillation is likely.
Example:
Input: hpa `payments-api` target 80% cpu, min 2 max 10, current 2 replicas at 25%.
Output: row [payments-api, ..., 80, 2-10, 2, 22, lower target to 55 or extend min] + note to add scaleDown stabilization.Why this directive matters
A mis-tuned HorizontalPodAutoscaler can be as harmful as no autoscaler at all. Set the target too high and the controller keeps too few replicas and latency climbs at the first traffic spike; set it too low and you burn money on idle pods and can even churn replicas, which forces cold starts and defeats the purpose. This directive guides the agent through reading the HPA's configured target, minimum, and maximum alongside its observed status, then reconciling that with actual `kubectl top` samples. It teaches the agent to notice when utilization sits far from the target, when the HPA is pinned at its maximum, and when the replica count oscillates because the target is inside the noise band of the metric. The output is a table of per-workload recommendations plus a short paragraph on the subtlety of scaledown latency, so a platform engineer can apply the few changes that matter.
Test Command
kubectl get hpa -A -o wide && kubectl top pods -A --sort-by=cpuPrerequisites
- cluster-reader access
- metrics-server or Prometheus adapter
- kubectl top available
Expected Outputs
- HPA review table
- Oscillation risk assessment
- Tuned threshold suggestions
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This advanced directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.