Orphaned resources

You delete a StatefulSet on a Friday. The PersistentVolumeClaim went with it, but the PersistentVolume — provisioned with reclaimPolicy: Retain — stayed behind. Three months later, it's still on the bill. Orphaned Resources is where you find every one of those.

What counts as orphaned

A resource is orphaned when it exists, costs money, and has nothing claiming it. The two categories Kubeadapt tracks today:

• PersistentVolumes without a bound claim. Created by a StatefulSet or a one-off PVC that was deleted but kept the volume. AWS gp3, gp2, and io1 volumes are common; GCP pd-balanced, pd-ssd; Azure managed disks of every tier.
• Load balancers without backend targets. A Service of type LoadBalancer that pointed at a Deployment that no longer exists. The cloud LB stays provisioned, billed by the hour, doing nothing.

Both are surfaced through the agent's standard cluster scan; no extra configuration. The agent reads PersistentVolume, PersistentVolumeClaim, Service, and Endpoints objects every snapshot, so deletions show up within minutes and orphans surface as soon as the dangling resource has been unclaimed long enough to be unambiguous.

Why orphans accumulate

Three patterns drive most of what shows up on this page:

1. reclaimPolicy: Retain on StatefulSet PVs. It's the safe default — Kubernetes won't delete data when a pod restarts. The downside is the volume survives every form of cluster lifecycle event: namespace deletion, pod recreation, full StatefulSet teardown. If nobody runs cleanup afterward, the volume stays.
2. Ownership transfer. A team rebuilds a service in a new namespace, points DNS at the new Service, and forgets the old Service still has a LoadBalancer type. The old IP isn't routed anywhere, but the LB still costs $18–25 a month depending on provider.
3. Manual cleanup gaps. A team uses helm uninstall to remove a chart, but the chart's PVCs were marked helm.sh/resource-policy=keep. Helm leaves them, the user moves on.

None of these patterns are wrong on their own. They become a cost problem when the team that should clean up isn't the team that's monitoring the bill.

The cleanup-safety flag

Every row carries a cleanup_safety value that captures Kubeadapt's confidence that the resource is safe to delete. Values you'll see:

The cleanup_assessment.reason field on each row spells out which of those conditions applied. The has_recent_data and has_snapshots booleans give you the underlying signals directly.

What the page shows

Per-cluster page at Clusters → [cluster] → Orphaned Resources. Top of the page:

• Total Reclaimable Savings — sum of monthly_savings_potential across every row.
• Orphaned Resources — total count, all categories combined.
• Old Resources (>90d) — count of rows where age_days > 90. These are the easiest wins.
• Safe to Clean Up — count of rows with cleanup_safety = "safe".

The table lists resource name, namespace, resource type, storage class (for PVs), age, cleanup safety, last claim name, and monthly cost. Filter by namespace, resource type, storage class, or cleanup safety; search by name. Click a row for the full lifecycle record (when it was created, when the last claim was deleted, what the reclaim policy was).

Acting on a recommendation

Kubeadapt does not delete cloud resources. The cleanup happens through your usual operations path:

1. Filter to cleanup_safety = "safe" and age_days > 90. These are the safest, highest-savings rows.
2. For each PV row, check last_claim_name and last_claim_namespace — the row remembers what was bound there. If the original team is still in the org, confirm before deleting.
3. For PVs you want to keep but stop paying for, snapshot first (aws ec2 create-snapshot, gcloud compute snapshots create, az snapshot create) and then delete the volume. The snapshot is cold storage and costs a small fraction of an active volume.
4. For orphaned load balancers, deleting the Service of type LoadBalancer reclaims the cloud LB. Confirm no traffic is hitting the old IP first.

Once the resource is gone, the agent's next snapshot reflects the deletion and the row drops off the page.

What's not here

• No automated cleanup. Kubeadapt is read-only and will not delete cloud resources for you.
• No cross-cluster view. Orphans are listed per cluster. To see your fleet-wide orphan total, sum the Total Reclaimable Savings across clusters.
• No EBS-snapshot-only listing. The page tracks orphaned volumes; if you want to audit snapshots without the parent volumes, use your cloud provider's tools (AWS Trusted Advisor, GCP Recommender).
• No NAT gateway or NLB-specific costing. Load balancer rows aggregate every LB type the agent observes via the Service object; the cost is the LB's hourly rate, not a decomposed cross-AZ data transfer view.

Next steps

• Abandoned workloads — the same shape, but for live workloads that are no longer doing work.
• Cost attribution — find the team that owns the orphan before you delete it.