Jamadar was designed to clean up Kubernetes resources that remained after temporary work was finished. Its documented supported target is namespaces, selected using age and annotation rules. That can be useful for controlling abandoned test environments, but a namespace can contain an entire application and its storage claims. The controller cannot infer that old means disposable, so the ownership and exclusion rules must be established before it receives permission to delete anything.
Current guidance
The recovered entry identifies Stakater’s Jamadar controller. Its README describes polling for resources based on age and annotations, but the documented supported-resource list names namespaces. Do not read the general cluster-cleanup description as proof that every Kubernetes object type is implemented or that “unused” means unimportant.
Namespace deletion is a destructive action that can remove many applications and dependent objects at once. Review the configured age, restrictedNamespaces and annotation convention against the actual namespaces in the cluster. A missing annotation could represent an onboarding mistake rather than consent to delete production data. Evaluate selection rules against an inventory before granting delete permissions.
The repository documents logging and Slack actions, but this review did not establish a current compatibility or security-maintenance commitment. Test only disposable namespaces first, including one with finalizers and persistent-volume claims, and verify both the selected and excluded cases. Keep backup and retention policies independent of the cleanup schedule. If replacing Jamadar, reproduce its intended ownership policy rather than copying its timers into another controller without checking deletion semantics.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub does not mark stakater/Jamadar archived or disabled; this does not establish active maintenance, support or compatibility. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-25T04:18:15+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
A kubernetes controller which cleans up cluster left-overs.
WHY NAME JAMADAR?
Jamadar, an Urdu word, is used for Sweepers/Cleaners in Pakistan. This Jamadar will keep your cluster clean and sweep away the left overs of your cluster and will act as you want it to.
Problem
Dangling/Redundant resources take a lot of space and memory in a cluster. So we want to delete these unneeded resources depending upon the age and pre-defined annotations. e.g. I would like to delete namespaces that were without a specific annotation and are almost a month old and would like to take action whenever that happens.
Solution
Jamadar is a Kubernetes controller that can poll at configured time intervals and watch for dangling resources that are an ‘X’ time period old and don’t have a specific annotation, and will delete them and take corresponding actions.
Configuring
First of all you need to modify configs/config.yaml file. Following are the available options that you can use to customize Jamadar:
| Key | Description |
|---|---|
| polltimeinterval | The time interval after which the controller will poll and look for dangling resources, The value can be in “ms”, “s”, “m”, “h” or even combined like 2h45m |
| age | The time period that a dangling resource has been created e.g. delete only resources that are 7 days old, The value can be in “d”, “w”, “m”, “y”, Combined format is not supported |
| resources | The resources that you want to be taken care of by Jamadar, e.g. namespaces, pods, etc |
| actions | The Array of actions that you want to take, e.g. send message to Slack, etc |
Supported Resources
Currently we are supporting the following dangling resources,
- namespaces
We will be adding support for other Resources as well in the future
Supported Actions
Currently we are supporting following Actions with their Parameters,
- Default: No parameters needed, it will just log to console the details.
- Slack: you need to provide token and Channel Name as Parameters in the yaml file
We will be adding support for other Actions as well in the future
Deploying to Kubernetes
You have to first clone or download the repository contents. The kubernetes deployment and files are provided inside deployments/kubernetes/manifests folder.
Deploying through kubectl
You can deploy Jamadar by running the following kubectl commands:
kubectl apply -f configmap.yaml -n <namespace>
kubectl apply -f rbac.yaml -n <namespace>
kubectl apply -f deployment.yaml -n <namespace>
Helm Charts
Or alternatively if you configured helm on your cluster, you can deploy Jamadar via helm chart located under deployments/kubernetes/chart/Jamadar folder.
The post Jamadar appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →