Skip to content


Switch branches/tags

Latest commit


Failed to load latest commit information.
Latest commit message
Commit time


Kube-events revolves around Kubernetes Event, covering multi-dimensional processing of them, such as emitting events to sinks, issuing notifications and generating alerts. In some of these dimensions, configurable filtering rules are provided to meet different business needs.

Kube-events contains two major business components, Exporter and Ruler. Exporter watches Kubernetes Event and emits events to sinks. Ruler receives events, filters them by rules, then issues notifications or processes them as alerts which will eventually be sent to alertmanager or webhooks.

Another component called Operator is responsible for the desired state of the previous business components. This relies on the following three crds to achieve:

  • Exporter, which defines a desired Exporter deployment. Operator ensures at all times that a Exporter matching the resource definition is running.
  • Ruler, which defines a desired Ruler deployment. The Operator ensures at all times that a Ruler matching the resource definition is running.
  • Rule, which defines a desired Rule set, which will be used to filter events by Ruler.

To learn more about the CRDs introduced by the kube-events have a look at the design doc.

The architecture diagram is as follows:


Install quickly kube-events into your kubernetes cluster with the following commands:

kubectl apply -f
kubectl apply -f

Or install it by helm chart.

Videos & blogs

K8s events exporting, filtering, alerting and notification in multi-tenant env



Rule is used to define filtering rules for events. Each Rule instance can be configured with a set of rules. When configuring these instances, set a label called to distinguish the scope of rules, to meet the needs of multi-tenancy.

  • cluster
    This level of Rule does not need to specify the namespace when it is configured, it will be stored in the namespace which the operator belongs to. Filtering rules in it will be applied to the events of the entire cluster.
  • namespace When configuring a Rule instance at this level, you need to specify the namespace. Rules in it will be applied to the events whose involvedObject.namespace equals to the namespace which this Rule instance belongs to.
  • workspace This is an intermediate level of scope control. It will act on events of multiple namespaces. It needs to be specified a label called, which will be used to select the namespaces with the same label. Rules in it will be applied to the events whose involvedObject.namespace is in these selected namespaces. (It will be stored in the same namespace to the cluster-level instances)


Exporter component is configured by Exporter. Exporter currently supports output events to stdout and webhook. In fact, Ruler component is such a webhook.

If you want to collect events from the exporter's stdout and output them to a specific place, fluentbit is a good choice. To achieve this, by fluentbit-operator which provides flexibility and convenience of fluentbit configuration, just add some Input/Filter/Output plugins as needed. For example, the following provides plugins which will finally output events to es:

kind: Input
  name: tail-events
  namespace: kubesphere-logging-system
  labels: "true" "events"
    tag: kube_events
    path: /var/log/containers/*_kubesphere-logging-system_events-exporter*.log
    parser: docker
    refreshIntervalSeconds: 10
    memBufLimit: 5MB
    skipLongLines: true
    db: /fluent-bit/tail/pos-events.db
    dbSync: Normal
kind: Output
  name: es-events
  namespace: kubesphere-logging-system
  labels: "true" "events"
  match: kube_events
    host: elasticsearch-logging-data.kubesphere-logging-system.svc
    port: 9200
    logstashPrefix: ks-logstash-events
    logstashFormat: true
kind: Filter
  name: filter-events
  namespace: kubesphere-logging-system
  labels: "true" "events"
  match: kube_events
  - parser:
      keyName: log
      parser: json


Ruler component is configured by Ruler. Ruler component filters the received events through rules and may generate event notifications or alerts. Alert messages can be configured to be sent to the alertmanager service.

And webhooks can be also configured to receive these notifications or alerts.