How to Capture Kubernetes Events with Knative Eventing: A Step‑by‑Step Guide

Background

Event‑driven architecture is a core feature of serverless platforms, enabling pay‑as‑you‑go consumption. Knative Eventing consists of three main components: Event Sources, the event processing model, and event consumers. This guide demonstrates how to capture Kubernetes events using the Broker/Trigger model and forward them to a Knative Service.

Prerequisites

Knative version >= 0.5

Knative Serving installed

Knative Eventing installed

Step 1: Create a Service Account

A ServiceAccount is needed to grant the ApiServerSource permission to read Kubernetes events.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: events-sa
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: event-watcher
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: k8s-ra-event-watcher
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: event-watcher
subjects:
- kind: ServiceAccount
  name: events-sa
  namespace: default

Apply the manifest:

kubectl apply --filename serviceaccount.yaml

Step 2: Define the ApiServerSource

The ApiServerSource watches Kubernetes events and forwards them to a Broker.

apiVersion: sources.eventing.knative.dev/v1alpha1
kind: ApiServerSource
metadata:
  name: testevents
  namespace: default
spec:
  serviceAccountName: events-sa
  mode: Resource
  resources:
  - apiVersion: v1
    kind: Event
  sink:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Broker
    name: default

Apply the source:

kubectl apply --filename k8s-events.yaml

Step 3: Deploy an Event‑Display Service

Use the open‑source knative-sample/event-display project to build a simple service that prints received events.

package main
import (
    "context"
    "fmt"
    "log"
    cloudevents "github.com/cloudevents/sdk-go"
    "github.com/knative-sample/event-display/pkg/kncloudevents"
)

func display(event cloudevents.Event) {
    fmt.Printf("Hello World:
")
    fmt.Printf("cloudevents.Event
%s", event.String())
}

func main() {
    c, err := kncloudevents.NewDefaultClient()
    if err != nil {
        log.Fatal("Failed to create client, ", err)
    }
    log.Fatal(c.StartReceiver(context.Background(), display))
}

Build the container image and push it to a registry, then create the Knative Service:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: event-display
  namespace: default
spec:
  template:
    spec:
      containers:
      - image: {yourrepo}/{yournamespace}/event-display:latest

Apply the service definition:

kubectl apply --filename service.yaml

Step 4: Create a Broker

Label the namespace to enable automatic Broker creation:

kubectl label namespace default knative-eventing-injection=enabled

The Eventing controller will create a default Broker in the namespace.

Step 5: Create a Trigger

The Trigger connects the Broker to the event‑display Service, acting as a filter (here no filter is applied).

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: testevents-trigger
  namespace: default
spec:
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: event-display

Apply the Trigger:

kubectl apply --filename trigger.yaml

Verification

Generate a Kubernetes event by creating and deleting a pod:

kubectl run busybox --image=busybox --restart=Never -- ls
kubectl delete pod busybox

Check that the Knative Service received the event:

kubectl get pods
kubectl logs -l serving.knative.dev/service=event-display -c user-container

The logs should show a CloudEvent similar to:

Hello World:
☁️  CloudEvent: valid ✅
Context Attributes,
  SpecVersion: 0.2
  Type: dev.knative.apiserver.resource.add
  Source: https://.../default/broker/default
  ... (event payload) ...

Conclusion

By following these steps you have learned how Knative Eventing captures Kubernetes events, processes them through the Broker/Trigger model, and delivers them to a consumer Service. You can now extend this pattern to custom event sources, third‑party messaging systems, or integrate alerting mechanisms such as email or DingTalk.