Kubernetes (any distribution)

In-cluster waste and posture, wherever it runs.

Cluster waste lives in the gap between what pods request and what they use: requests set far above real consumption, namespaces nobody runs anything in, PersistentVolumeClaims orphaned by deleted workloads, deployments scaled to zero but never cleaned up.

Nuvozy reads the cluster directly with a read-only ServiceAccount token, pairs requests against metrics-server usage, and infers the hosting cloud from node providerIDs, so right-sizing recommendations land where the spend is.

Requests ≫ usage

The biggest container waste: pods reserving far more CPU/memory than they ever use.

Posture too

Privileged pods, hostPath mounts, and latest-tag images flagged alongside the waste.

Any distro

EKS, GKE, AKS, or self-managed: the same read-only in-cluster pass.

What we scan on Kubernetes

A representative sample of the Kubernetes checks, grouped by service domain. Cost waste and security risk are surfaced in the same read-only pass. The complete, searchable list is further down this page.

Workload right-sizing

Requests vs real usage from metrics-server.

Over-requested CPU / memory

Pods reserving far more than they consume.

Missing limits

Workloads with no resource ceilings.

Single-replica & zombie deployments

No redundancy, or scaled-down but never removed.

Idle & orphaned

Namespaces, PVCs, DaemonSets, pending pods.

Idle namespaces

Namespaces with no active workloads.

Orphaned PersistentVolumeClaims

Storage claims left by deleted workloads.

Pending pods & DaemonSet spread

Stuck scheduling and unnecessary DaemonSets.

Posture

Pod-security and image hygiene.

Privileged & hostPath pods

Containers with host-level access or mounts.

latest-tag images

Non-pinned images that undermine reproducibility.

Every check we run on Kubernetes

All 11 checks, generated directly from the scanner so this list matches what actually runs. Search for a service to see whether your stack is covered.

  • Compute

    Heavy DaemonSet overhead

    DaemonSets requesting a large share of the smallest node's CPU. Per-node overhead multiplies across every node in the pool.

  • Compute uses metrics

    Over-requested containers

    Containers reserving far more CPU/memory than they actually use (needs metrics-server). Trapped capacity you pay for via larger node pools.

  • Compute

    Pending pods

    Pods stuck in the Pending phase. Typically unschedulable for lack of CPU/memory/nodes. Signals capacity pressure or bad requests.

  • Governance

    Containers without requests/limits

    Containers missing CPU/memory requests or limits. Breaks scheduler bin-packing and blast-radius isolation.

  • Governance

    Deployments scaled to zero

    Deployments currently at 0 replicas. Often forgotten leftovers. Review and delete (in-cluster scan can't see 30-day history).

  • Governance

    Idle namespaces

    Namespaces with no running pods. Empty, or holding only completed/failed jobs. Candidate cleanup to cut clutter and quota.

  • Governance

    Mutable :latest image tags

    Containers running images tagged ':latest' or with no tag at all. Non-reproducible. Restarts can silently pull a different build.

  • Governance

    Single-replica prod workloads

    Deployments in production-looking namespaces running with replicas=1. No redundancy; a node drain causes downtime.

  • Security

    Privileged containers

    Containers running privileged. Full access to host devices and kernel capabilities. A container escape becomes a node compromise.

  • Security

    hostPath volume mounts

    Pods mounting node host paths. Couples the pod to the node and can expose sensitive host files. A common privilege-escalation path.

  • Storage

    Orphaned PersistentVolumeClaims

    PVCs that are Bound but mounted by no pod, or in Released/Lost phase. The backing PersistentVolume keeps billing on the cloud disk.

Checks marked opt-in use a paid or billing-data cloud API and never run unless you switch them on. A default scan uses only free APIs.

How you connect

A read-only ServiceAccount token

Apply the provided manifest to create a read-only ServiceAccount, then paste its token, your cluster's API server endpoint, and CA certificate. Nuvozy reads over that endpoint with get/list/watch only and never writes to the cluster. The API server must be reachable from Nuvozy.

Read-only (get/list/watch). No mutating verbs.

How the dollars are calculated

Right-sizing is expressed in requested vs used resources; dollar mapping follows the hosting cloud inferred from node providerIDs.

Every finding is backed by the raw cloud API response it came from, with a confidence score and the pricing source labelled, no black-box numbers.

Scan your Kubernetes estate free

Connect a read-only serviceaccount token and run a read-only scan. Findings come priced in real dollars with a fix and the evidence for each.

Start scanning free

Other clouds we scan

AWS GCP Azure Alibaba Cloud Oracle Cloud