Every long-lived setup collects leftovers. One example is a directory of YAML that no Kustomization (a Flux object that says what to deploy) points at. Another is a ServiceMonitor (a rule that tells Prometheus what to scrape) from a chart that you uninstalled long ago. There is also a 50 GiB volume that nothing mounts, and a database that you hibernated "for now". The assistant looks at git and the cluster side by side. It proves what is unused and gives you an issue. It never deletes anything itself.
An orphan is a break in the chain between what is written down and what runs. The assistant checks the chain from both ends. One end is YAML in git that nothing deploys. The other end is live objects that nothing in git declares.
Each direction is a separate, rule-based scan. No AI model (LLM) decides whether something is an orphan.
The daily wiring audit computes the closure of every Flux Kustomization over the repository tree. The closure is the set of files that the Kustomization reaches. Flux never applies files outside that closure, however correct they look.
Sometimes the fix is a one-line stitch into a parent
kustomization.yaml. Then you get a draft merge request (MR). A whole
unreferenced directory becomes an issue, because only you know
whether it is future work or a forgotten copy.
Every four hours the assistant checks the cluster side the other way. It looks at ServiceMonitors, PodMonitors, PrometheusRules and NetworkPolicies. It reports in an issue any that no scanned repository declares and no live HelmRelease manages.
A leftover NetworkPolicy still shapes traffic. A stale PrometheusRule still pages. That is why these are worth finding.
prune: false keeps alive Live
Flux only removes deleted objects when a Kustomization has
prune: true. With prune off, deleting a file in git leaves
the object running. The assistant compares each Kustomization's own
applied inventory with the live objects that carry its labels.
An object must show up as orphaned on three consecutive runs. Only then
does the assistant report it, in one digest per cluster. The assistant never proposes
flipping prune. That is your call.
The relic census lists PersistentVolumeClaims older than a threshold (90 days by default). It checks them against every live pod and every workload template. This includes CronJobs and Deployments scaled to zero, so a paused consumer still counts as a consumer.
The assistant matches StatefulSet claims to their ordinals. It leaves alone a volume reserved by a StatefulSet parked at zero replicas. The relic census is built and tested, but it is opt-in and not yet switched on in production.
A CloudNativePG cluster with hibernation on keeps its storage and
costs money. The census looks for any reference to its
-rw, -r or -ro services in
pod and workload env, args, commands and volumes.
If nothing references the cluster, the assistant reports it as a relic. It does not read Secret and ConfigMap contents, and the issue says so.
An orphan claim is a claim of absence. So every read behind it must be complete. Sometimes a list of HelmReleases, pods or workloads is denied, cut short or malformed. Then the scan withholds the verdict for that cluster and logs why. It does not report everything as unused.
You can put a skip annotation on anything that you want left alone. The scan will not mention it again.
Planned: resources whose declared owner or team no longer exists. Also planned: environments that drifted apart from their siblings. One example is a file that was identical in staging and production until someone changed only one copy.
Planned: an estimated monthly cost next to each relic, so you can sort the list by what cleanup is worth. Until then, the issue shows the size and storage class, not a price.
clusters/production/apps.yaml → path: ./apps/production apps/production/kustomization.yaml ✓ shop/orders-api/ ✓ shop/checkout-web/ ✓ payments/ ✗ apps/production/shop/reports-worker/ # 3 files, in no resources: list ✗ apps/production/legacy-search/ # 7 files, whole directory unreferenced
status.inventory # what Flux applied last reconcile shop_orders-api_apps_Deployment shop_orders-api__Service shop_checkout-web_apps_Deployment live, labelled kustomize.toolkit.fluxcd.io/name=apps shop/orders-api Deployment in inventory shop/checkout-web Deployment in inventory shop/promo-banner Ingress not in inventory shop/promo-banner Service not in inventory
metadata: annotations: cnpg.io/hibernation: "on" # consumer search in pods and workload templates auth-db-rw 0 references auth-db-r 0 references auth-db-ro 0 references # the live auth service connects to auth-db-v2-rw
# planned: sibling drift apps/staging/shop/orders-api/configmap.yaml sha 3f1c… apps/production/shop/orders-api/configmap.yaml sha 9a07… # identical until last month
Orphans and relics arrive as issues, not merge requests. Deleting data is a decision, not a diff. This is an illustrative example of the relic digest. It has the same shape as the digest that the census writes.
Two PersistentVolumeClaims on prod-eu are older than 90 days. No live pod mounts them. No workload template references them, including suspended CronJobs and StatefulSets scaled to zero.
Is this retained data still needed? Or should you consider it for garbage collection after you verify consumers and recovery requirements? This is an issue-only advisory. The assistant proposes no destructive action.
| PVC | Age | Phase | Storage class | Size |
|---|---|---|---|---|
platform/data-auth-postgresql-0 | 1,280 days | Bound | ssd | 50Gi |
shop/import-scratch | 412 days | Bound | standard | 200Gi |
Both rows: no PVC mount reference found in live pods or workload pod templates.
kubectl cp, a migration plan) still expects the data.The same set of volumes produces one issue, not one per run. A new unattached volume starts a new digest.
An orphan report is a claim that something is unused. Every guard below exists because a wrong one costs data.
prune: false leftovers on three consecutive runs, so it does not report an object that is mid-rollout.prune on. That stays an operator decision.prune: false leftover digest from Flux inventories