# Vertical scaling: PRA and PRP

Vertical scaling changes CPU or memory resources per pod. Choose between explicit lifecycle profiles and continuous utilization-based resizing.

[![Horizontal scaling changes pod count; PRA follows utilization and PRP applies lifecycle profiles, both changing container resources.](https://docs.kedify.io/assets/images/docs/vertical-scaling-modes.svg)](https://docs.kedify.io/assets/images/docs/vertical-scaling-modes.svg)

Scroll to exploreDiagram description

Horizontal autoscaling changes the number of pods. PRA continuously changes container resources using measured utilization. PRP applies predefined resources after a lifecycle event and delay. PRA and PRP leave replica count unchanged; Insights provides recommendations for explicit review.

## Vertical Scaling vs Horizontal Scaling

Horizontal scaling changes replica count; vertical scaling changes resources within a pod. A memory-heavy process may need more per-pod capacity even when adding replicas does not help. Both require node capacity and workload readiness. [Insights](https://docs.kedify.io/features/insights/) is advisory rather than a vertical controller.

## When to use Pod Resource Profile (PRP)

Use [PRP](https://docs.kedify.io/features/pod-resource-profiles/) for explicit resource transitions at startup, container readiness or ScaledObject activation/deactivation. Choose it when you know the desired resource profile for a lifecycle state. Try [keeping a small warm pod](https://docs.kedify.io/how-to/prp-shrink-pod-instead-of-scale-to-zero/) when retaining a process avoids expensive cold starts.

## When to use Pod Resource Autoscaler (PRA)

Use [PRA](https://docs.kedify.io/features/pod-resource-autoscaler/) for continuous adjustment based on CPU/memory utilization, with bounds, sampling and cooldown. Try the [load-generator walkthrough](https://docs.kedify.io/how-to/pra-vertical-scaling-with-load-generator/) to inspect decisions and resize events before wider rollout.

## PRP and PRA Together

Assign one writer to each container resource field. PRP and PRA must not repeatedly write the same requests/limits fields; last-writer patch behavior causes conflicting control loops. Include GitOps, dashboard actions and other vertical controllers in the ownership map. When combining vertical scaling with a CPU-utilization HPA, changing requests also changes the utilization percentage at unchanged CPU usage.

[![At steady 200m CPU usage, a request increase from 250m to 500m changes CPU utilization from 80% to 40%, altering the HPA input.](https://docs.kedify.io/assets/images/docs/pra-hpa-utilization.svg)](https://docs.kedify.io/assets/images/docs/pra-hpa-utilization.svg)

Scroll to exploreDiagram description

For one representative container using a steady 200m CPU, raising the CPU request from 250m to 500m changes utilization from 80 percent to 40 percent. A CPU-utilization HPA therefore receives a different percentage even though application usage is unchanged. With a 60 percent target, the values are above then below target; replica decisions still depend on the complete HPA configuration and metrics.

Use a field-level ownership map before combining controllers. For example, one container could use this split:

| Container field | Runtime owner | Configuration rule |
| --- | --- | --- |
| `requests.cpu` | PRA | Configure only `policy.cpu.requests` for PRA. |
| `requests.memory` | PRP | Include only `requests.memory` in PRP `newResources`. |
| `limits.cpu` | Fixed workload configuration | Neither PRA nor PRP changes this field. |
| `limits.memory` | Fixed workload configuration | Neither PRA nor PRP changes this field. |

This is an ownership example, not a ready-to-apply policy. Keep requests within limits, preserve the Pod’s QoS class, and verify resize feasibility. Check dashboard actions, GitOps and any other vertical controller for writes to these same live fields; a different timer does not resolve conflicting ownership.

## Vertical Scaling How-To

Both controllers need supported Kubernetes in-place resize behavior, permissions and feasible resources. QoS constraints, container resize policy and node capacity can defer or prevent a change; some changes can restart a container. Use the [PRP warm-pod guide](https://docs.kedify.io/how-to/prp-shrink-pod-instead-of-scale-to-zero/) or [PRA load test](https://docs.kedify.io/how-to/pra-vertical-scaling-with-load-generator/) to inspect resource changes, then [diagnose failed resizes](https://docs.kedify.io/troubleshooting/vertical-scaling/).

For reviewed changes to Helm or GitOps resource settings, use [Insights recommendations](https://docs.kedify.io/features/insights/) and [apply them through source](https://docs.kedify.io/how-to/apply-recommendations-to-source/).

---
Canonical: https://docs.kedify.io/scalers/vertical-scalers/
Source: src/content/docs/scalers/vertical-scalers.md
Documentation index: https://docs.kedify.io/llms.txt