DEV.co
Open-Source Observability · robusta-dev

krr

KRR is a CLI tool that analyzes your Kubernetes cluster's actual resource usage via Prometheus and recommends optimized CPU/memory requests and limits. It runs locally or in-cluster and can automatically apply recommendations, helping teams reduce cloud costs by identifying and eliminating resource over-provisioning.

Source: GitHub — github.com/robusta-dev/krr
4.6k
GitHub stars
279
Forks
Python
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryrobusta-dev/krr
Ownerrobusta-dev
Primary languagePython
LicenseMIT — OSI-approved
Stars4.6k
Forks279
Open issues126
Latest releasev1.28.0 (2025-12-31)
Last updated2026-06-23
Sourcehttps://github.com/robusta-dev/krr

What krr is

KRR queries Prometheus metrics (container_cpu_usage_seconds_total, container_memory_working_set_bytes, kube-state-metrics) to calculate resource recommendations using pluggable strategies. It supports multiple data sources (Prometheus, Thanos, Victoria Metrics, managed services) and outputs recommendations in JSON, CSV, Markdown, or via integrations (Slack, k9s, web UI, Azure Blob Storage).

Quickstart

Get the krr source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/robusta-dev/krr.gitcd krr# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Kubernetes Cost Optimization

Right-size CPU/memory requests across workloads based on observed usage patterns. Typical savings of 69% CPU and 18% memory overallocation per Sysdig study.

Rapid Assessment Without Agent Overhead

Get resource recommendations immediately via CLI without deploying a controller inside the cluster. Useful for one-off audits or teams that prefer minimal cluster footprint.

Multi-Prometheus Environment Support

Connect to managed Prometheus services (AWS, Azure, GCP), Grafana Cloud, Coralogix, or self-hosted Prometheus/Thanos/Mimir from a single tool.

Implementation considerations

  • Ensure Prometheus has adequate retention (14 days default) and contains required metrics; kube-prometheus-stack ships all prerequisites.
  • For in-cluster scheduling (weekly Slack reports), deploy as a CronJob with appropriate RBAC and Prometheus access credentials.
  • Review KRR's extensible strategy system if default CPU/memory models don't match your workload patterns; custom strategies are added via Python.
  • Auto-Apply mode (Enforcer) requires separate deployment and testing; start with recommendations-only mode to validate accuracy.
  • Free SaaS UI (Robusta platform) offers visualization and explainability; optional but useful for understanding recommendation rationale.

When to avoid it — and what to weigh

  • Requires Automatic Pod Restart Integration — KRR provides recommendations; automatic scaling via HPA is listed as future support. VPA auto-applies changes—KRR's Auto-Apply mode (Enforcer) is separate and requires additional setup.
  • No Prometheus Metrics Available — KRR requires Prometheus 2.26+, kube-state-metrics, and cAdvisor. Clusters without these metrics (or historical metric retention <14 days) cannot generate accurate recommendations.
  • Custom Resource Recommendations Needed Now — GPU and other custom resource support is marked as future work. Current release supports only CPU and memory.
  • Real-Time Dashboard for Continuous Monitoring — KRR is a point-in-time analyzer, not a continuous monitoring solution. For ongoing dashboards, use Grafana, Datadog, or built-in Kubernetes monitoring.

License & commercial use

MIT License. Permits commercial use, modification, and distribution with attribution and no warranty. No restrictions on proprietary applications or closed-source deployment.

MIT is a permissive OSI-approved license with no restrictions on commercial use. KRR can be deployed in for-profit enterprises without license concerns. However, review any SaaS integration (Robusta platform, HolmesGPT) terms separately for commercial use and data handling.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityModerate
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

Requires read access to Prometheus metrics and Kubernetes API (via kubeconfig or in-cluster service account) to enumerate pods/workloads. Network access to Prometheus and optional SaaS platform should be isolated per security policy. No agents run in cluster for CLI mode, reducing attack surface. Auto-Apply mode (Enforcer) requires patch/update permissions on workloads—scope and RBAC must be carefully restricted. Third-party SaaS integration (Robusta platform) involves external data transmission; review data handling policies.

Alternatives to consider

Kubernetes VPA (Vertical Pod Autoscaler)

Native Kubernetes controller; auto-applies recommendations and continuous monitoring. Requires cluster deployment and VPA object per workload; slower to produce initial results.

Sysdig / Datadog / New Relic FinOps

Commercial platforms offering cost analysis, right-sizing recommendations, and dashboarding. Broader feature set and support; higher cost; vendor lock-in risk.

Custom Prometheus PromQL + Grafana Dashboards

Build bespoke recommendations by querying Prometheus directly. Full control and no external dependencies; requires in-house expertise and ongoing maintenance.

Software development agency

Build on krr with DEV.co software developers

Use KRR to analyze your cluster's resource usage and get actionable right-sizing recommendations. Start with a local CLI run—no cluster changes required.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

krr FAQ

Can KRR work without installing anything in my cluster?
Yes. Run KRR as a CLI on your local machine or CI/CD pipeline; it only needs network access to Prometheus and kubeconfig. In-cluster deployment (CronJob) is optional for automated reporting.
How often should I run KRR?
Default analysis window is 14 days of Prometheus history. Run weekly or monthly for periodic audits; or deploy in-cluster as a CronJob for automated reporting. Frequency depends on workload volatility.
Does KRR automatically patch my deployments?
No by default. KRR generates recommendations in JSON/CSV/UI. Optional Auto-Apply mode (KRR Enforcer) can patch resources; requires separate deployment and testing.
What if I don't have all required Prometheus metrics?
KRR requires container_cpu_usage_seconds_total, container_memory_working_set_bytes, and kube-state-metrics. Without all three, it still works but only considers running pods, not historical data.

Custom software development services

DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If krr is part of your open-source observability roadmap, our team can implement, customize, migrate, and maintain it.

Optimize Your Kubernetes Costs Today

Use KRR to analyze your cluster's resource usage and get actionable right-sizing recommendations. Start with a local CLI run—no cluster changes required.