kube-cleanup-operator

kube-cleanup-operator automates removal of workload objects that match configured cleanup rules. Its supported modes include finished Jobs and selected Pod states, which can help control the accumulation of temporary work in a cluster. The rules need to match the reason for cleanup: a completed test Job differs from a Pending Pod that cannot find capacity. Keeping enough logs and status for diagnosis matters before the source objects are deleted.

Current guidance

The lwolf/kube-cleanup-operator README describes deleting completed Jobs and pods, as well as configurable handling of Pending, Evicted and orphaned pods. That is broader than the recovered completed-Jobs-only summary. Each deletion mode has a different operational consequence and should be enabled deliberately.

For completed Jobs alone, Kubernetes provides ttlSecondsAfterFinished through the TTL-after-finished controller. It deletes a finished Job and its dependent objects after the configured period while respecting lifecycle constraints such as finalizers. That native mechanism does not replace every pod-cleanup behavior in this operator.

Preserve logs and job status long enough for diagnosis before deleting their source objects. Review namespace scope, successful versus failed retention and what qualifies as orphaned; a stuck Pending pod can indicate a capacity or scheduling problem that deletion would conceal. Test the exact policy against disposable examples and exclude critical workloads. Select the controller image and chart independently, and check the current API permissions instead of assuming an old chart’s broad RBAC is necessary. Cleanup success is not evidence that the underlying failure was resolved.