What this prompt does
This prompt makes the AI configure a Kubernetes Horizontal Pod Autoscaler for [app_name] in [namespace] on [cluster_type], scaling on real application signals rather than CPU alone. It builds CPU-based scaling between [min_replicas] and [max_replicas] at [cpu_target], adds a [memory_target] dimension, wires Prometheus Adapter to expose [custom_metrics] as scaling triggers, sets asymmetric scaling behavior, adds a PriorityClass, sets up VPA in recommendation mode, and provides a load test plus a Grafana query.
The structure works because it separates the metrics that drive scaling from the behavior that controls how scaling happens. Asymmetric stabilization windows — aggressive scale-up, conservative scale-down — are the detail that stops the autoscaler from flapping under bursty load. Exposing [custom_metrics] like request rate and queue depth lets pods scale on signals that move before CPU does, which is the whole point of going beyond the default HPA.
When to use it
- CPU is a lagging indicator for your workload and you need to scale on request rate or queue depth instead.
- Your service flaps between replica counts under bursty traffic and you want stable scaling behavior.
- You want a multi-metric HPA balancing both
[cpu_target]and[memory_target]. - You need to expose custom Prometheus metrics as autoscaling triggers via the Prometheus Adapter.
- You want
[app_name]pods protected from eviction during node pressure with a PriorityClass. - You want to validate the autoscaler with a real load test before trusting it in production.
Example output
Expect an HPA manifest (autoscaling/v2) with CPU and memory targets plus custom-metric references, a Prometheus Adapter config exposing [custom_metrics], a behavior block defining the asymmetric scale-up and scale-down windows, a PriorityClass definition, a VPA resource in recommendation-only mode, a k6 or hey command to generate load, and a Grafana query comparing replica count against request rate over time.
Pro tips
- Set the scale-down window much longer than scale-up; a 300s scale-down against a 15s scale-up is what prevents flapping when traffic is spiky.
- Choose
[custom_metrics]that genuinely lead CPU — queue depth and requests per second are strong picks because they rise before compute saturates. - Keep
[min_replicas]high enough to absorb a sudden spike during the scale-up window; scaling from too low a floor still causes a brief overload. - Run VPA in recommendation-only mode first and compare its suggestions against your current requests before changing anything — never run VPA and HPA on the same CPU metric simultaneously.
- Use the provided k6 or hey load test to confirm the HPA reacts as expected; tuning windows on paper is no substitute for watching it scale.
- Tune
[cpu_target]and[memory_target]together; if memory climbs faster than CPU, the memory target will become the effective trigger.
