Kubernetes produces events when things happen to workloads, such as a Pod failing to schedule or an image failing to download. Eventrouter watched those event resources and forwarded them to another system for storage and querying. It was useful for retaining operational clues beyond a short-lived view in the cluster. This entry concerns Heptio's archived Kubernetes collector, not the unrelated programming class described in part of the recovered text.
Deployment and operating notes
The chart metadata points to Heptio’s Eventrouter, now under vmware-archive. It watches Kubernetes Event resources and forwards them to a sink; it is not the generic Subscribe/Publish programming class described in part of the recovered text. The upstream design also states that storage and querying belong to the sink, not Eventrouter itself.
If replacing it, define which Kubernetes event API, namespaces and destinations must be covered, along with retention and access controls. Events are operational observations rather than a complete audit trail, and repeated events may be aggregated or expire before a collector sees them. Test a controlled scheduling failure and recovery, then verify timestamps, reason, involved object and duplicates in the destination. Preserve the existing field mapping if dashboards or alerts depend on it. Run the replacement briefly with duplication understood, then remove the old watcher’s permissions. No universal drop-in successor was established; choose a supported event receiver in the logging or telemetry system already responsible for retention.
Historical upstream link check · 2026-10-09
The recorded upstream address redirects to https://github.com/vmware-archive/eventrouter and returned HTTP 200 on 2026-10-09. GitHub marks vmware-archive/eventrouter as archived. This confirms the repository's read-only archive state; any successor or supported distribution needs separate evidence. GitHub resolves the old repository identity to vmware-archive/eventrouter. 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-09T22:49:11+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
eventrouter simple introspective kubernetes service that forwards events to a specified sink. EventRouter is a class for broadcasting messages to subscribers. Clients of the EventRouter register themselves by calling Subscribe and passing in the even they are interested in along with a delegate to be called back when the event is received. Events are published via the Publish method which allows arbitrary data to be passed along with the event to be interpreted by the event receiver. Events do not have to be pre-defined.
Publish and Subscribe methods also have an optional id parameter which will filter the events a receiver gets to just those that match the provided event and id. Subscribing to an event with no id will result in receiving all events of the specified type.
Goals
This project has several objectives, which include:
- Persist events for the longer period of time to allow for system debugging
- Allows operators to forward events to other systems (s) for archiving/ML/introspection/etc.
- It should be relatively low overhead
- Support for multiple sinks should be configurable
NOTE:
By default, eventrouter is configured to leverage existing EFK stacks by outputting wrapped json object which is easy to index in elastic search.
Non-Goals:
This service does not provide a querable extension, that is a responsibility of the sink
This service does not serve as a storage layer, that is also the responsibility of the sink
The post Eventrouter appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →