Orphaned resources

Orphaned Resources lists PersistentVolumes that no workload uses but that still cost money, such as a volume with reclaimPolicy: Retain left behind after its StatefulSet and claim were deleted.

What counts as orphaned

A PersistentVolume is orphaned when it exists, costs money, and has no bound claim. It is usually left behind by a StatefulSet or a one-off PVC that was deleted while the volume was kept. AWS gp3, gp2 and io1 volumes are common, as are GCP pd-balanced and pd-ssd and Azure managed disks.

Orphaned Resources covers PersistentVolumes only. It does not list load balancers, ConfigMaps or other objects.

Orphans come from the agent's standard cluster scan, with no extra configuration. The agent reads PersistentVolume and PersistentVolumeClaim objects on every snapshot, so deletions show up within minutes.

Why orphans accumulate

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

1. reclaimPolicy: Retain on StatefulSet PVs. Kubernetes won't delete the data when a pod restarts, and the volume also survives namespace deletion and a full StatefulSet teardown. If nobody cleans up afterward, the volume stays.
2. 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 has a Cleanup safety rating: how confident Kubeadapt is that the volume is safe to delete.

Each row shows which of those conditions applied, and whether the volume has recent data or snapshots.

What the page shows

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

• Total Reclaimable Savings: the monthly cost of every orphaned volume on the page.
• Orphaned Resources: the total count.
• Old Resources (>90d): volumes older than 90 days. These are the easiest wins.
• Safe to Clean Up: volumes rated Safe.

The table lists resource name, namespace, storage class, age, cleanup safety, last claim name and monthly cost. Filter by namespace, 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 sort by age. Volumes older than 90 days are the safest, highest-savings rows.
2. For each row, check the last claim name and namespace: the row remembers what was bound there. If the original team is still around, confirm with them 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.

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 does 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 load balancers or other objects. Only PersistentVolumes are listed.

Next steps

• Cost attribution: find the team that owns the orphan before you delete it.