Every long-lived estate collects leftovers: a directory of YAML that no Kustomization points at, a ServiceMonitor from a chart that was uninstalled a year ago, a 50 GiB volume nothing mounts, a database that was hibernated "for now". The assistant looks at git and the cluster side by side, proves what is unused, and hands 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 walks it from both ends: YAML in git that nothing deploys, and live objects that nothing in git declares.
Each direction is a separate, deterministic scan. No model decides whether something is an orphan.
The daily wiring audit computes the closure of every Flux Kustomization over the repository tree. Files outside that closure are never applied, however correct they look.
Where the fix is a one-line stitch into a parent
kustomization.yaml, you get a draft 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 cluster side is walked the other way. ServiceMonitors, PodMonitors, PrometheusRules and NetworkPolicies that are neither declared in a scanned repository nor managed by a live HelmRelease are reported as an issue.
A leftover NetworkPolicy still shapes traffic, and a stale PrometheusRule still pages. That is why these are worth finding.
prune: false keeps alive Live
Flux only garbage-collects when a Kustomization has
prune: true. With it 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 before
it is reported, 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) and checks them against every live pod and every workload template, including CronJobs and Deployments scaled to zero, so a paused consumer still counts as a consumer.
StatefulSet claims are matched to their ordinals: a volume reserved by a StatefulSet parked at zero replicas is left alone. Built and tested, opt-in, 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.
No reference anywhere and it is reported as a relic. Secret and ConfigMap contents are not read, and the issue says so.
An orphan claim is a claim of absence, so every read behind it must be complete. If listing HelmReleases, pods or workloads was denied, truncated or malformed, the scan withholds the verdict for that cluster and logs why, rather than report everything as unused.
Anything you want left alone can carry a skip annotation, and the scan will not mention it again.
Planned: resources whose declared owner or team no longer exists, and environments that drifted apart from their siblings (a file that is identical in staging and production today, changed in only one).
Planned: an estimated monthly cost next to each relic, so the list can be sorted by what cleanup is worth. Today the issue carries 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. Illustrative example of the relic digest, shaped like the one the census writes.
Two PersistentVolumeClaims on prod-eu are older than 90 days and are not mounted by any live pod or referenced by any workload template, including suspended CronJobs and StatefulSets scaled to zero.
Is this retained data still needed, or should it be considered for garbage collection after verifying consumers and recovery requirements? This is an issue-only advisory; no destructive action is proposed.
| 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 must be seen on three consecutive runs, so a mid-rollout object is not reported.prune on. That stays an operator decision.prune: false leftover digest from Flux inventories