v2.9.19: No Agent Cloud Cost Optimization for Kubernetes

Container platforms changed how teams ship software, but they did not make waste disappear. In many environments, Kubernetes simply moved cloud waste behind a scheduler, a namespace, or a storage claim.

That is the reason v2.9.19 matters. Cloud Waste Scanner now supports local-first Kubernetes and container waste scanning. The implementation is deliberately practical: it runs through local kubectl, uses the kubeconfig and context you choose, keeps data on your machine, and returns evidence that an operator can review without installing a SaaS collector inside the cluster.

This is not a cosmetic checkbox. Kubernetes is where many teams now hide expensive infrastructure decisions: node pools sized for last quarter's launch, PersistentVolumes left behind after namespace cleanup, public LoadBalancer services that nobody owns, and replica settings that drift from current traffic. A monthly cloud bill rarely explains those relationships. A cluster dashboard rarely connects them to cross-cloud waste. CWS now helps bridge that gap with no agent cloud cost optimization for platform teams that need evidence before cleanup.

What shipped in v2.9.19

The new scan lane adds Kubernetes as a first-class local scan target. Community users can run the workflow from the app, and automation users can drive it through the Local API. The current implementation is intentionally read-only and evidence-oriented, making it a practical no agent cloud cost optimization path for teams that need cloud governance tools and cloud cost optimization for DevOps without installing a collector.

Why we chose local kubectl instead of a hosted collector

There are powerful Kubernetes cost tools that deploy agents, exporters, or SaaS-connected collectors. Those tools can be valuable when the goal is continuous allocation, chargeback, or deep namespace economics. CWS is solving a different immediate problem: evidence-first waste discovery that respects the operator trust boundary.

The v2.9.19 Kubernetes lane uses your local kubectl environment. That means:

• Your kubeconfig remains on your workstation or controlled jump host.
• The scan uses the Kubernetes permissions already granted to that context.
• The output is generated locally and can be reviewed before being shared.
• No in-cluster agent is required for this scan lane.
• No hosted inventory plane receives your cluster object list.

What kinds of waste can this reveal?

The first Kubernetes release focuses on practical signals that often show up in real platform operations. It is not trying to replace a full allocation engine. It is trying to answer a simpler question: what should the platform team inspect this week because it may still be billing, exposing risk, or lacking an owner?

1. Orphaned PersistentVolumes after migrations

A team migrates a service from one namespace to another. The old Deployment is gone. The old PVC is deleted. But the backing PV is still present, or the cloud disk behind it still exists. Kubernetes often makes storage safe by default; safety can become spend if nobody follows through.

CWS can read PV and PVC state, then help the operator review which volumes no longer map cleanly to live workloads. In a combined cloud-plus-Kubernetes review, that evidence can be compared against cloud-side disks and snapshots.

2. Node baseline drift in managed clusters

Managed Kubernetes teams often set a node-pool minimum during a launch week and forget to lower it after traffic normalizes. The cluster is healthy, dashboards look green, and the waste hides as a baseline floor.

v2.9.19 builds on the earlier EKS/GKE/AKS node-pool signal work by making Kubernetes local scan context visible in the same operating story. The team can now review cluster object signals and cloud-side capacity posture together instead of treating them as separate audits.

3. LoadBalancer services that nobody owns

A Kubernetes Service of type LoadBalancer can create a real cloud-side load balancer. If the service remains after the application is retired, the cloud bill may keep moving even when no developer recognizes the name in the provider console.

CWS highlights these service-level review candidates so platform teams can ask the right ownership question before deleting anything: is this still attached to a live application path, or is it a leftover exposure and spend item?

4. Replica drift and owner gaps

Not every Kubernetes waste signal is a direct invoice line. Some are governance failures that lead to waste later: unlabeled workloads, missing owner hints, replicas set above current operational need, or namespace patterns that make chargeback impossible.

CWS surfaces these as execution context. The goal is not automatic deletion. The goal is to create a concrete review list for platform teams and application owners.

Case study: the migration that left storage behind

Consider a SaaS team that recently moved a reporting service from an older namespace into a new platform-managed namespace. The migration was successful. Customers saw no downtime. The engineering team closed the ticket.

Three weeks later, the cloud bill still showed higher-than-expected storage spend. The provider console listed several disks with names that looked like Kubernetes artifacts. The platform team could not confidently answer whether those disks were safe to delete because the application team had already moved on.

With the new CWS workflow, the review looked like this:

1. The operator selected the production kubeconfig and context in CWS.
2. CWS ran a local read-only Kubernetes scan through kubectl.
3. The scan listed PVs, PVCs, workloads, pods, services, and owner-related metadata.
4. The team compared old namespace storage claims with current workload state.
5. CWS generated findings and an action-plan view for review, not blind deletion.
6. The platform owner exported the evidence and assigned two cleanup actions: confirm one PV, snapshot one disk for safety, and delete the confirmed orphan after approval.

The important part was not that a tool said "delete this." The important part was that the team finally had evidence across the Kubernetes layer and the cloud resource layer. That evidence shortened a review that might have taken hours of console clicking and Slack archaeology.

How to run a Kubernetes scan

The desktop flow is designed for operators who already use kubectl. You provide a kubeconfig path and, optionally, a specific context. CWS validates the request, runs the local scan, and stores the latest Kubernetes inventory and findings locally.

POST /v1/k8s/scans
Authorization: Bearer YOUR_LOCAL_API_TOKEN
Content-Type: application/json

{
  "kubeconfig_path": "~/.kube/config",
  "kube_context": "prod-us-east"
}

You can also include Kubernetes in a broader scan request:

POST /v1/scans
Authorization: Bearer YOUR_LOCAL_API_TOKEN
Content-Type: application/json

{
  "selected_accounts": ["aws-prod", "gcp-platform"],
  "include_kubernetes": true,
  "kubeconfig_path": "~/.kube/config",
  "kube_context": "prod-us-east"
}

After the scan, the Local API exposes inventory and review endpoints:

• GET /v1/k8s/contexts for kubeconfig contexts.
• GET /v1/k8s/findings for Kubernetes waste findings.
• GET /v1/k8s/nodes, /pods, /workloads, /services, /persistent-volumes, and /persistent-volume-claims for inventory review.
• GET /v1/reports/k8s-governance for a governance summary.
• GET /v1/reports/k8s-action-plan for an execution-oriented cleanup plan.
• GET /v1/mcp/tools/k8s-governance and /v1/mcp/tools/k8s-action-plan for MCP-ready automation payloads.

Who benefits first?

This release is especially useful for teams that already run Kubernetes but do not want another always-on collector just to answer weekly hygiene questions. It fits several situations:

• Platform teams that need a fast read-only review before a cleanup meeting.
• SaaS teams that migrated services and need to verify leftover PVs, services, and node baselines.
• Security-sensitive teams that cannot send kubeconfig, cluster inventory, or cloud account data to a hosted SaaS by default.
• FinOps operators who need Kubernetes evidence next to cloud-side waste evidence.
• SMB engineering teams that need practical cleanup evidence without deploying a full enterprise cost allocation stack.

Current boundaries and what comes next

We should be explicit about the boundary. v2.9.19 uses local kubectl. It is not yet a direct kube-apiserver SDK client. It does not attempt to replace specialized allocation tools such as Kubecost or OpenCost for deep chargeback. It is focused on local-first evidence collection, waste review, and practical governance output.

The next Team and Enterprise work is about workflow, not just more scan calls:

• Shared owner queues for Kubernetes findings.
• Recurring closure history for platform teams.
• Namespace/team mapping for accountability.
• Deeper HPA, request/limit, and drift analysis.
• Optional alignment with allocation context for finance review.
• Procurement and compliance packaging for larger organizations.

FinOps Execution Insight

• Kubernetes waste is not only a cluster problem. It often becomes cloud waste through disks, load balancers, node baselines, and ownership drift.
• Local-first scanning changes the security conversation. Teams can inspect Kubernetes evidence without installing a hosted collector or exporting kubeconfig data.
• The right first outcome is a cleanup queue, not blind automation. v2.9.19 gives operators evidence, governance summaries, and action plans so humans can close waste safely.

Where to read next

For route-level details, read the Kubernetes API reference. For a runnable workflow, use Playbook 10: Kubernetes and Container Waste Scan. For the public capability record, see the Release Ledger and Roadmap.