Use Hpa and Vpa Together
You can use hpa and vpa together by assigning them to different metrics. Never let both tools scale on CPU or memory at the same time. Teams often set up both scalers to save money and handle traffic spikes. Still, broad cluster roles let anyone change these scaling rules by mistake. One bad edit can cause pods to restart in an endless loop. How to use hpa and vpa together without conflicts Horizontal Pod Autoscaler adds or removes pod copies based on current load. Vertical Pod Autoscaler cha
Hpa: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You can use hpa and vpa together by assigning them to different metrics. Never let both tools scale on CPU or memory at the same time. Teams often set up both scalers to save money and handle traffic spikes. Still, broad cluster roles let anyone change these scaling rules by mistake. One bad edit can cause pods to restart in an endless loop.
How to use hpa and vpa together without conflicts
Horizontal Pod Autoscaler adds or removes pod copies based on current load. Vertical Pod Autoscaler changes the CPU and memory limits of existing pods. If both tools watch CPU usage, they will fight each other. When CPU spikes, one tool adds pods while the other resizes them. This conflict causes constant pod restarts and unstable app performance.
To fix this, separate the metrics that each tool watches. Let the horizontal scaler watch custom metrics like requests per second. You can also let it watch queue length from an external system. Then, set the vertical scaler to manage CPU and memory limits. Another safe path is running the vertical scaler in recommendation mode only. In that mode, it reads usage data and suggests new resource limits. It never restarts pods on its own while the horizontal scaler runs.
Why you should separate scaling metrics in your cluster
Traffic patterns and resource needs do not always grow at the same rate. An app might receive many small web requests that need more pod copies. At the same time, background jobs might need more memory per pod. Splitting metrics lets each scaler solve one specific problem without interference.
Before you apply both scalers, check your pod disruption budgets. Vertical scaling often deletes and recreates pods to apply new resource sizes. Your app needs enough running copies to survive these brief restarts. Always test the combined setup in a staging cluster under real load first.
Hpa: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native cluster roles solve and what they miss
Native Kubernetes roles control who can log in and view cluster objects. You can grant a team permission to read or write autoscaler rules. This setup stops random users from entering the cluster without a valid key. It gives you a basic check on who holds admin rights.
Still, static roles only decide who logs in to the cluster API. They do not inspect what individual commands or edits do in flight. An engineer with broad edit rights can still break production scaling rules. They might set both scalers to watch CPU during an urgent fix. They might also run commands that read sensitive data from running pods. Native roles cannot pause a risky command for a quick peer review. They also fail to mask sensitive fields like emails or card numbers in output.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can both scalers watch CPU and memory at the same time?
No, you should never point both tools at CPU or memory together. They will react to the same spike and cause pod thrashing. Use custom traffic metrics for horizontal scaling and resource metrics for vertical scaling.
What is the safest way to start using both autoscalers?
Turn on the vertical scaler in recommendation mode while horizontal scaling runs. It will calculate ideal CPU and memory sizes without restarting your pods. Your team can review those numbers and update deployment files during planned maintenance.
How do we stop bad autoscaler edits during an incident?
Remove broad cluster edit roles from daily user accounts right away. Require peer approval for commands that change scaling rules in production. Log every command and output so your team can audit all changes later.