Eraser is an Apache-2.0 licensed Kubernetes operator, written in Go, that helps Kubernetes administrators remove a list of non-running container images from all nodes in a cluster.

What it is

Eraser is a Kubernetes operator that cleans container images off Kubernetes nodes. Rather than treating the images sitting in a node's container runtime as untouchable, it gives an administrator a declarative way to say which non-running images should go away, and then carries that removal out across every node in the cluster. The project is written in Go and released under the Apache-2.0 licence, with its documentation, quick-start guide and demo hosted on a dedicated site. It sits firmly in the Kubernetes and cloud-native ecosystem: it adopts the CNCF Code of Conduct, is tagged for the CNCF topic, and maintains a #eraser channel on the Kubernetes Slack alongside a public mailing list and biweekly community meetings.

The concrete problem it solves is image accumulation on nodes. Container images pulled for workloads that have since stopped or been rescheduled stay resident on the node, occupying disk and lingering long after the pod that needed them is gone. Historically that cleanup is manual and node-by-node: an administrator logs into each host and prunes images by hand, which does not scale and is easy to forget. Eraser replaces that per-node manual pruning with a cluster-scoped, list-driven operation, so a single declared set of images is removed uniformly from all nodes. In the registry's taxonomy it falls under Security & Privacy / Threat Detection & Response, and its topic list places it in the image-security and vulnerability-scanner neighbourhood.

Key capabilities

• Removes a supplied list of non-running images from every Kubernetes node in a cluster, which is the project's stated core behaviour.
• Runs as a Kubernetes operator, so cleanup is managed from inside the cluster rather than by ad-hoc scripts run against individual nodes.
• Operates on non-running images only, leaving images backing live workloads in place.
• Carries image-security and vulnerability-scanner topics alongside a Trivy tag, positioning it in the scanning and hardening workflow rather than outside it.
• Publishes first-party documentation, including a quick-start guide and separate development setup instructions for contributors.
• Shows third-party quality and licence signals: an OpenSSF Best Practices badge, an OpenSSF Scorecard badge, and a FOSSA licence-compliance badge.
• Offers real community participation paths through the mailing list, biweekly community meetings, #eraser on Kubernetes Slack, and a hacktoberfest topic.

Who uses it and how

• Kubernetes administrators and platform teams who are accountable for node disk usage and want image cleanup handled centrally instead of host by host.
• Security teams working with image scanning who already know which images are stale or unwanted and need them removed from the nodes, not just flagged.
• Cluster operators running heterogeneous nodes, where the same cleanup has to happen consistently across every node in one action rather than as a separate manual job per host.
• Contributors and evaluators who use the repository's demo, quick-start guide and development setup instructions to trial the operator before adopting it.

Getting started

The README does not list a package name, container image or manifest; it directs readers to the quick-start guide in the Eraser documentation at https://eraser-dev.github.io/eraser/docs/quick-start, with development setup instructions at https://eraser-dev.github.io/eraser/docs/setup.

How it compares

The facts here do not provide a list of paid products that Eraser replaces, so a cost or licence comparison cannot honestly be drawn. What the topic list does show is a shared neighbourhood with image security tooling such as Trivy: scanning identifies images of concern, while Eraser handles the removal of non-running images from nodes. Beyond that adjacency, no direct equivalent is named in the supplied facts.

When to use it — and when not to

Eraser is a good fit when image bloat on nodes is a recurring operational problem and the team is already comfortable running operators inside the cluster. Prospective adopters should note that the README is deliberately short: it carries no install command, image reference or configuration details, so all operational specifics must be read from the external documentation site, and anyone who needs a pinned release artifact should confirm versioning before committing. The project also shows 82 open issues, and it is narrowly scoped — it removes non-running images and does not, on the stated description, scan for or remediate vulnerabilities itself, so it complements rather than replaces a scanner.