search

hjacobs / kube-janitor

Clean up (delete) Kubernetes resources after a configured TTL (time to live)
GNU General Public License v3.0
473 stars 40 forks source link

Additional rule matching with janitor/ttl? #19

Open CookieComputing opened 5 years ago

CookieComputing commented 5 years ago

Are there any plans on adding additional rule matching (e.g. whitelisting a specific instance of a resource, etc.) alongside the janitor/ttl annotation, or is the design based on the premise that if the resource is included and there is an annotation, it will be removed? Or is this the case that rule matching will always be used in the situation when an annotation isn't marked?

hjacobs commented 5 years ago

@CookieComputing can you describe your use case? I don't fully understand what you are trying to achieve/solve.

CookieComputing commented 5 years ago

I was wondering about the case where a user mistakenly applies the janitor/ttl annotation to one of their resources. If a pod or PVC, for example, was annotated by a script that a user had left running accidentally, is there any fall back mechanism for them? Or should extreme caution with the annotation be exercised?

hjacobs commented 5 years ago

@CookieComputing I think it depends on the use case: "with great power comes great responsibility". For me there are two different topics here:

1) "Human error": The impact of kube-janitor can be limited by restricting it by resources or namespaces. There are other "dangerous" things you can do with full access to the Kubernetes API, so I would generally recommend production changes only via git and CI/CD (or even GitOps). 2) Additional conditions together with TTL annotation: I could imagine use cases where a user wants to express something like "apply TTL of X to this resource, but only if it has state Y" (e.g. to only delete Pods which are not in "Running" phase anymore)