Kubernetes Pod Waste Audit: 5 kubectl Commands That Find Overpaying Fast

# Kubernetes Pod Waste Audit: 5 kubectl Commands That Find Overpaying Fast

Most Kubernetes cost waste does not start in the invoice. It starts in a YAML file where a pod requests 4 CPU and uses 180 millicores.

Cost tools help, but they are not the first move. The first move is to prove where requests, limits, idle namespaces, and orphaned workloads are creating waste. You can do that with five command-level checks.

This is written for mixed teams: the senior engineer who knows where the bodies are buried, and the junior engineer who needs a safe audit path without changing production.

1. Compare Requested Resources To Real Usage

Start with live usage:

kubectl top pods -A --containers

Then compare requests and limits:

kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory,CPU_LIM:.spec.containers[*].resources.limits.cpu,MEM_LIM:.spec.containers[*].resources.limits.memory'

The first command shows what containers are doing now. The second shows what the scheduler reserved. The waste is usually in the gap.

If a service consistently uses 200m CPU but requests 2 CPU, the cluster may need nodes for reservations rather than actual work.

2. Find Pods With No Requests

No requests is not "free." It means the scheduler has less information and the workload may be hard to place under pressure.

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{range .spec.containers[*]}{.name}{":"}{.resources.requests.cpu}{"/"}{.resources.requests.memory}{" "}{end}{"\n"}{end}' | grep '<none>\|:$'

Clean output is rare. Use the result to prioritize namespaces that need a default LimitRange or a review of deployment templates.

3. Find Idle Namespaces

Idle namespaces often survive because nobody wants to ask whether an old preview environment is still needed.

kubectl get deploy,statefulset,daemonset,job,cronjob -A

Then check recent activity:

kubectl get events -A --sort-by=.lastTimestamp | tail -100

If a namespace has workloads, no recent events, no owner, and no traffic, it belongs in a cleanup review.

4. Find Zombie Workloads

Zombie workloads are deployed, scheduled, and billed, but no product path depends on them.

kubectl get deploy -A -o custom-columns='NS:.metadata.namespace,DEPLOY:.metadata.name,REPLICAS:.spec.replicas,READY:.status.readyReplicas,AGE:.metadata.creationTimestamp'

Look for old deployments with replicas but no clear service owner. Then connect them to services and ingress:

kubectl get svc,ingress -A

If a deployment has replicas and no route, it may be a background worker, a forgotten service, or waste. The point is to assign ownership before resizing or deleting.

5. Check Horizontal Autoscaler Reality

An HPA does not save money if requests are wrong.

kubectl get hpa -A
kubectl describe hpa -A

If CPU utilization is based on requested CPU, an oversized request can make a busy workload look idle. Rightsizing requests often improves autoscaling behavior before any node-level change.

What To Put In The Audit Report

Keep the report simple:

|---|---|---|---|

Leadership does not need raw terminal output. It needs dollars, owners, and a low-risk order of operations.

Safe Order Of Operations

Do not resize everything in one pull request.

1. Export the current workload specs. 2. Pick one low-risk namespace. 3. Reduce requests, not limits, first. 4. Watch p95 latency, restarts, throttling, and queue depth. 5. Apply the pattern to the next namespace only after the first one holds.

For venture-backed SaaS teams, this is the difference between FinOps theater and operational savings. A cost dashboard can show waste. A scoped rightsizing plan removes it without waking up the incident channel.

Service CTA

TechSaaS helps teams audit Kubernetes spend, rightsize workloads, and build repeatable FinOps dashboards without destabilizing production.

Service page: https://techsaas.cloud/services