Back to Blog
Best Practices

Detect Kubernetes Waste in Under 5 Minutes With the KorPro Inspector

A step-by-step walkthrough: install the KorPro Inspector into your EKS, GKE, or AKS cluster with a single Helm command and get your first orphan report before your coffee gets cold.

KorPro Team
March 10, 2026
8 min read
KubernetesCost OptimizationKorPro InspectorHelmEKSGKEAKSFinOps

How much are you spending on Kubernetes resources that nobody is using?

Most teams have a rough guess. A few ConfigMaps here, maybe some old PVCs from a decommissioned service. The honest answer is: almost nobody knows for certain, because actually finding orphaned resources across a live cluster — accounting for dependency chains, transitive references, and cost attribution — is genuinely hard to do manually.

This post shows you how to get that answer in under 5 minutes using the KorPro Inspector.

What the Inspector Actually Does

The KorPro Inspector is a lightweight Go agent that you deploy inside your Kubernetes cluster as a CronJob. Once installed, it:

  1. Performs an RBAC pre-check to confirm it has the permissions it needs.
  2. Lists every resource across all namespaces (or a specified subset).
  3. Builds a dependency graph to map which resources reference which.
  4. Identifies both direct orphans (resources not referenced by anything) and transitive orphans (resources that become orphaned because their parent workload is itself unused).
  5. Enriches every finding with a cost estimate for GKE, EKS, and AKS.
  6. Computes cluster health, efficiency, and security scores.
  7. Posts the findings to your KorPro dashboard over HTTPS and exits.

The whole thing takes 1–3 minutes on a typical cluster. Then the pod terminates and resource usage returns to zero.

Prerequisites

You need:

  • kubectl pointed at the cluster you want to scan
  • Helm 3+ installed locally
  • A KorPro account (free tier available — sign up here)

That's it. No IAM roles, no service account JSON files, no cloud credentials.

Step 1: Get Your License Key

Sign in to your KorPro dashboard and navigate to Settings → Inspector.

You'll see your license key and a pre-filled install command ready to copy. The key looks like a UUID and acts as your authentication token to the KorPro API — it has no cloud provider access.

Step 2: Install With Helm

One command installs everything the Inspector needs:

bash
helm install korpro-inspector oci://ghcr.io/kortechnologies/charts/korpro-inspector \ --namespace korpro-system \ --create-namespace \ --set licenseKey="<your-license-key>"

Helm will create:

  • A Namespace (korpro-system)
  • A ClusterRole with read-only get and list permissions
  • A ServiceAccount bound to that ClusterRole
  • A Secret storing your license key
  • A CronJob scheduled to run every 6 hours

Verify it's installed:

bash
kubectl get cronjobs -n korpro-system

You should see:

NAME                 SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
korpro-inspector     0 */6 * * *   False     0        <none>          12s

Step 3: Trigger Your First Scan Now

Don't wait 6 hours. Kick off an immediate scan by creating a one-shot Job from the CronJob:

bash
kubectl create job korpro-first-scan \ --from=cronjob/korpro-inspector \ -n korpro-system

Follow the logs in real time:

bash
kubectl logs -n korpro-system \ -l job-name=korpro-first-scan \ --follow

A healthy scan looks something like this:

[KorPro Inspector] Starting scan...
[KorPro Inspector] RBAC pre-check: OK
[KorPro Inspector] Scanning namespace: default (47 resources)
[KorPro Inspector] Scanning namespace: production (213 resources)
[KorPro Inspector] Scanning namespace: staging (89 resources)
[KorPro Inspector] Building dependency graph...
[KorPro Inspector] Direct orphans detected: 34
[KorPro Inspector] Transitive orphans detected: 12
[KorPro Inspector] Enriching with cost data (provider: aws, region: us-east-1)...
[KorPro Inspector] Estimated monthly waste: $847.20
[KorPro Inspector] Posting findings to dashboard...
[KorPro Inspector] Done. Cluster: my-prod-cluster | Health: 71 | Efficiency: 58

Step 4: View Results in the Dashboard

Within a minute or two of the scan completing, your cluster appears in the dashboard under Settings → Inspector → Connected Clusters.

Navigate to the Clusters page to see:

  • Full orphan list broken down by resource type, namespace, and cost
  • Direct vs. transitive orphan classification so you know what's safe to delete independently and what needs a specific cleanup order
  • Dependency graph showing why each transitive orphan was flagged
  • Cluster health score (0–100) across efficiency, security, and hygiene dimensions
  • Cost breakdown by resource type and namespace

What Does a Transitive Orphan Look Like?

Here's a real-world example. You decommissioned a payment-service Deployment 3 months ago. The Deployment is gone — but you left behind:

  • A ConfigMap named payment-service-config (direct orphan — not mounted anywhere)
  • A Secret named payment-db-credentials (direct orphan — not mounted anywhere)
  • A Service named payment-service (direct orphan — no selector matches)
  • A PersistentVolumeClaim named payment-data-pvc with ReclaimPolicy: Retain (the PV still exists and is still billing you)

The PVC is a transitive orphan: it was provisioned by the StatefulSet that supported the payment service. The StatefulSet is gone, making the PVC unreachable — but it persists and costs money.

KorPro surfaces these in dependency order, showing you the parent context so you understand why each resource is flagged, not just that it is.

Typical Results: What Teams Find

Based on clusters we've analyzed, here's what a typical production cluster reveals on the first scan:

Resource TypeTypical Orphan RateCommon Root Cause
ConfigMaps25–40%Feature flags from decommissioned services
Secrets15–30%API keys from removed integrations
Services10–20%Services outliving their Deployments
PVCs5–15%Retained volumes from deleted StatefulSets
Deployments5–10%Staging/testing workloads never cleaned up
ServiceAccounts20–35%Created for one-off scripts or jobs

The monthly cost impact varies by cluster size and cloud provider, but $500–$3,000/month in recoverable waste on a mid-sized production cluster is common. Larger clusters with many namespaces and long deployment histories can have significantly more.

Don't Have Helm? Use the CLI Binary

If you want a one-shot scan without installing anything into the cluster, the Inspector ships as a standalone binary:

Linux / macOS:

bash
curl -fsSL https://github.com/KorTechnologies/korpro-inspector-releases/releases/latest/download/install.sh | sh

Windows (PowerShell):

powershell
irm https://github.com/KorTechnologies/korpro-inspector-releases/releases/latest/download/install.ps1 | iex

The binary reads from your current kubectl context. No cluster modifications, no CronJob, no RBAC changes — just a scan and a report.

Configuring the CronJob Schedule

By default, the CronJob runs every 6 hours (0 */6 * * *). You can change this at install time:

bash
helm install korpro-inspector oci://ghcr.io/kortechnologies/charts/korpro-inspector \ --namespace korpro-system \ --create-namespace \ --set licenseKey="<your-key>" \ --set cronjob.schedule="0 2 * * *" # Daily at 2am

Or scan only specific namespaces:

bash
--set scanner.namespaces="{production,staging}"

The Scan History View

Every scan creates a record. The dashboard's Scan History view shows:

  • Per-scan orphan counts and cost estimates over time
  • Health, efficiency, and security score trends
  • Which resources were cleaned up between scans (the delta)
  • Failed scan logs (failed scans never overwrite the previous valid data)

This gives you a continuous cleanup progress tracker. If your team deleted 20 orphaned ConfigMaps last week, the next scan confirms they're gone and shows any new ones that appeared.

Troubleshooting in 30 Seconds

RBAC errors in the logs? The Inspector prints the exact ClusterRole YAML it needs. Copy it, apply it, re-run the scan.

Cluster name is wrong in the dashboard? The Inspector auto-detects the name from node metadata. Override it:

bash
--set scanner.clusterName="my-cluster"

Want to scan a second cluster? Run the same helm install command in the second cluster's context. Each cluster gets its own Inspector install. They all report to the same dashboard, keyed by cluster name.

What Happens to the Old Cloud Provider Setup Pages?

If you previously used KorPro's cloud credentials model, you can disconnect those cloud providers from the Settings page. The Inspector does not require them — it connects using only the in-cluster Kubernetes API, which it accesses directly from within the cluster without any external network calls to cloud provider control planes.

Conclusion

The KorPro Inspector turns a question that used to require days of manual auditing — "what's actually wasted in this cluster?" — into a 5-minute task that runs automatically every 6 hours. No cloud credentials. No complex IAM setup. No persistent agent.

Helm install, trigger the first scan, and you'll have your first cost and waste report before you've finished reading this sentence twice.


Run Your First Scan Today

Create a free KorPro account to get your license key, install the Inspector, and see your first findings. Free tier includes 1 cluster with basic resource detection. No credit card required. Questions or want to walk through the setup with your team? Contact us and we'll help you get there.

Stop Wasting Kubernetes Resources

Ready to Clean Up Your Clusters?

KorPro automatically detects unused resources, orphaned secrets, and wasted spend across all your Kubernetes clusters. Start optimizing in minutes.

Written by

KorPro Team

View All Posts