I'm currently in the process of tidying up our Kubernetes clusters and I've noticed a lot of ConfigMaps and Secrets that seem to be obsolete. However, I'm hesitant to just delete them. You know how it goes—teams change their configurations, Helm releases can become outdated, but the old ConfigMaps and Secrets remain because `kubectl apply` doesn't automatically prune them. Since Kubernetes' garbage collection only kicks in when `ownerReferences` are properly set, these resources tend to accumulate over time. I'm curious about the best strategies for managing this situation.
Is manual cleanup feasible, or is that too overwhelming? Would custom scripts be a better option, like searching through all manifests for references? Or should we just leave them be since storage isn't too costly? I'm particularly worried about edge cases, such as Secrets used for Ingress TLS or `imagePullSecrets`, which can be tricky to keep track of compared to standard volume mounts. Anyone have a reliable process that avoids the risky 'scream testing' method (deleting and hoping for no complaints)?
4 Answers
I’ve taken a more radical approach—create a new cluster without granting anyone the ability to manually create resources. Manage everything via GitOps instead. By keeping ephemeral resources in the same namespace as what they belong to, their cleanup becomes automatic when that resource is undeployed. This limits human error and enforces correct practices. My trick? I rebuild the clusters quarterly, making it easy to ensure everything's in order and preventing unwanted resources from lingering.
We're implementing a GitOps approach using Argo CD, which helps a lot with this issue. It continuously reconciles every resource tied to an app, including ConfigMaps and Secrets, with what's outlined in our Git repositories. This means I can easily see what's in use and what’s currently deployed; plus, I get alerts if anything gets out of sync. It really removes the guesswork and lets us manage our resources with confidence.
Agreed! It’s nice to have that level of control.
Check out this GitHub repo: https://github.com/yonahd/kor. It offers some interesting tools for managing your clusters and might help with cleaning up those orphaned resources.
Thanks for sharing! It looks promising. Have you personally used it to streamline your processes?
Nice find! Definitely worth a look.
With GitOps, any orphaned resources should ideally not exist. It emphasizes having a clean state for your resources.
That sounds really efficient! I love the idea of having everything tracked like that.