How to set initial resource requests and limits for mixed Kubernetes workloads?

[Evelyn.W]

I'm a platform engineer setting up a new Kubernetes deployment for a set of microservices that have varying resource needs, from CPU-intensive batch jobs to memory-hungry API servers. I'm struggling with designing the right resource requests and limits to ensure stability without wasting cluster capacity. Our current approach of guessing and adjusting based on monitoring feels inefficient and has already caused a few pods to be evicted. For teams running mixed workloads in production, what's your methodology for determining initial requests and setting sane limits? How do you handle autoscaling effectively, and are there any tools or practices you use to continuously right-size your deployments based on actual usage patterns over time?

[Jacob7]

Here's a practical baseline you can start with. First, observe actual usage for a couple weeks and set each container's requests to roughly the 60th–70th percentile of observed usage. Set limits at 1.2–1.5x your peak observed usage to provide headroom without waste. Enable a per-namespace LimitRange and a ResourceQuota to prevent runaway consumption. Use HPA to scale CPU (target ~60–70%), and for memory-heavy pods, pair conservative memory limits with a monitoring plan and consider nearby VPA recommendations in a staging namespace before production. The key is to base adjustments on solid telemetry and a predictable review cadence rather than gut feel.

[Olivia.T]

Reply 2
Categorize workloads into CPU-heavy batch jobs and memory-heavy API services, and tune differently. For CPU-bound pods, lean on HPA with a CPU target around 60–70%. For memory-heavy workloads, rely on generous requests and limits and consider a cautious VPA (in monitoring mode first) to learn how memory needs evolve. Be mindful that aggressive memory scaling can cause restarts; prefer stability with ample headroom and good GC/tuning where possible. Also set up alerts for sustained memory pressure and OOM events so you don’t miss a creeping issue.

[RonaldBH]

Reply 3
Autoscaling reality check: enable a Cluster Autoscaler and use multiple node pools so you can hand-pick hardware for different workloads. Tie scale-out to queue/backlog or CPU credit usage, and set sane max-nodes limits to avoid budget shocks. Don’t forget a PodDisruptionBudget for critical services and a warm-up period on new nodes so workloads land smoothly. If you’re using HPA and VPA together, run tests in a staging namespace to avoid disruptive shifts in production.

[LunaA]

Reply 4
To keep things fair and stable across teams, put governance in place: namespaces with ResourceQuotas, LimitRanges, and a documented policy for requests/limits. Label workloads by criticality and apply QA gates before lifting limits. Consider a “golden path” for mission-critical services (guaranteed resources) and a “best-effort” pool for nonessential tasks. Add a simple runbook for when a pod gets evicted (check node capacity, pod QoS, and whether limits match actual usage).

[NatalieS]

Reply 5
Tools and techniques I’ve found useful: Goldilocks for automatically recommending resource requests/limits, Kubecost for ongoing cost-aware optimization, and Prometheus/Grafana dashboards to track CPU/memory usage and QoS mix. For adaptive scaling, look at Keda for event-driven scaling or the Kubernetes Horizontal/Vertical Autoscalers with custom metrics. If you have long-running batch jobs, consider a separate namespace with batch-oriented autoscaling and a capped pool to prevent interference with API pods.

[Noah26]

Reply 6
Two-week starter plan: Week 1, instrument and baseline (collect 1–2 weeks of metrics and set initial requests/limits). Week 2, enforce LimitRange/ResourceQuota and deploy a CPU-focused HPA; start a staging namespace with a VPA in monitoring mode. Week 3, simulate loads and test scale-out using Cluster Autoscaler; tune thresholds and max scale. Week 4, introduce KEDA or custom metrics for event-driven scaling if needed, and implement dashboards for ongoing right-sizing. If you share your cluster size, workload mix, and any autoscale constraints, I can tailor a concrete ramp plan.