Skip to content

Stop Paying for Resources Your Pods Don't Need

If you manage Kubernetes infrastructure at scale, you already know the pattern. Development teams request CPU and memory "just to be safe." Nobody wants their app to OOM. Nobody wants to get paged at 2am because a pod got throttled. So requests get padded and they stay padded.

The result? Clusters are full of pods consuming far less than what they've been allocated. Nodes are running hot on paper but idle in practice. And the platform team responsible for cost governance across dozens of clusters, projects, and namespaces has no easy way to prove it.

Introducing App Resizing

Rafay's new App Resizing feature (introduced with 4.1 release) gives centralized platform teams the data that they need to identify over-provisioned workloads and make a compelling, evidence-backed case for rightsizing them.

The workflow is simple: trigger a report on-demand through the UI, or schedule it to run periodically via API. As illustrated below, reports can be initiated by a Platform Admin directly from the UI or automated via API with scope defined across projects, clusters, namespaces, and time period.

App Resizing Workflow Figure 1: App Resizing workflow — from trigger to output

Rafay collects granular CPU and memory utilization metrics with up to 30 days of retention, and generates a per-pod comparison of:

Metric Description
Configured Requests What the pod was allocated
P90 Usage Usage at the 90th percentile
P95 Usage Usage at the 95th percentile
Peak Usage Highest recorded usage over the selected period

Reports can be scoped to specific clusters, namespaces, or projects, giving platform teams the flexibility to focus on the noisiest offenders first — or run a broad sweep across the entire organization.

Each report is exported as a ZIP file containing one CSV per cluster, making it easy to share with application teams or feed into a broader cost management workflow.

Built for the Platform Team, Shared with Everyone

The real power of App Resizing isn't just in generating the data — it's in what you do with it.

Platform teams can share reports directly with development and application teams to kick off rightsizing conversations with hard numbers rather than guesswork. Instead of asking a team to "review their resource requests," you can hand them a CSV that shows their pod has been consuming 15% of its requested memory for the past 30 days.

That's a very different conversation.

Generated Reports List Figure 2: Generated App Resizing reports, ready to download and share

How It Works: End to End

Platform Admin (UI)  ──┐
                        ├──▶  Configure Scope  ──▶  Metrics DB  ──▶  ZIP Report
Automated via API   ──┘       (Projects /                             (1 CSV per
                               Clusters /                              cluster)
                               Namespaces /
                               Time Period)
                                                                         │
                                              ┌──────────────────────────┤
                                              ▼          ▼               ▼
                                         End Users   Cost Savings   Platform Team
                                        (resize pods) (reclaim capacity) (at scale)

What's Next

This release focuses on insight and reporting. A future release will add the ability to auto-resize workloads applying rightsizing recommendations automatically, initially targeted at test and non-production clusters where the risk threshold is lower.

📋 Note: App Resizing requires the Rafay Prometheus stack to be enabled for metrics collection.