This is a cache of https://docs.openshift.com/container-platform/4.3/serverless/event_sources/serverless-apiserversource.html. It is a snapshot of the page at 2024-11-26T02:33:47.364+0000.
Using ApiServerSource - Event sources | Serverless applications | OpenShift Container Platform 4.3
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Using ApiServerSource

ApiServerSource is an event source that can be used to connect an event sink, such as a Knative service, to the Kubernetes API server. ApiServerSource watches for Kubernetes events and forwards them to the Knative Eventing broker.

Both of the following procedures require you to create YAML files.

If you change the names of the YAML files from those used in the examples, you must ensure that you also update the corresponding cli commands.

Using the ApiServerSource with the Knative cli (kn)

This section describes the steps required to create an ApiServerSource using kn commands.

Prerequisites

  • You must have OpenShift Serverless, the Knative Serving and Eventing components, and the kn cli installed.

Procedure

  1. Create a service account, role, and role binding for the ApiServerSource.

    You can do this by creating a file named authentication.yaml and copying the following sample code into it:

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: events-sa
  namespace: default (1)

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: event-watcher
  namespace: default (1)
rules:
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - get
      - list
      - watch

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k8s-ra-event-watcher
  namespace: default (1)
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: event-watcher
subjects:
  - kind: ServiceAccount
    name: events-sa
    namespace: default (1)
    1 Change this namespace to the namespace that you have selected for installing ApiServerSource.

    If you want to re-use an existing service account with the appropriate permissions, you must modify the authentication.yaml for that service account.

    Create the service account, role binding and cluster binding:

    $ oc apply -f authentication.yaml

  2. Create an ApiServerSource that uses a broker as an event sink:

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource

  3. To check that the ApiServerSource is set up correctly, create a Knative service that dumps incoming messages to its log:

    $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

  4. Create a trigger to filter events from the default broker to the service:

    $ kn trigger create <trigger_name> --sink svc:<service_name>

  5. Create events by launching a Pod in the default namespace:

    $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

  6. Check that the controller is mapped correctly by inspecting the output generated by the following command:

    $ kn source apiserver describe <source_name>
    Example output
    Name:                mysource
Namespace:           default
Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
Age:                 3m
ServiceAccountName:  events-sa
Mode:                Resource
Sink:
  Name:       default
  Namespace:  default
  Kind:       Broker (eventing.knative.dev/v1alpha1)
Resources:
  Kind:        event (v1)
  Controller:  false
Conditions:
  OK TYPE                     AGE REASON
  ++ Ready                     3m
  ++ Deployed                  3m
  ++ SinkProvided              3m
  ++ SufficientPermissions     3m
  ++ EventTypesProvided        3m
Verification steps

You can verify that the Kubernetes events were sent to Knative by looking at the message dumper function logs.

  1. Get the Pods:

    $ oc get pods

  2. View the message dumper function logs for the Pods:

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container
    Example output
    ☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: dev.knative.apiserver.resource.update
  datacontenttype: application/json
  ...
Data,
  {
    "apiVersion": "v1",
    "involvedObject": {
      "apiVersion": "v1",
      "fieldPath": "spec.containers{hello-node}",
      "kind": "Pod",
      "name": "hello-node",
      "namespace": "default",
       .....
    },
    "kind": "Event",
    "message": "Started container",
    "metadata": {
      "name": "hello-node.159d7608e3a3572c",
      "namespace": "default",
      ....
    },
    "reason": "Started",
    ...
  }

Deleting the ApiServerSource using the Knative cli (kn)

This section describes the steps used to delete the ApiServerSource, trigger, service, service account, cluster role, and cluster binding using kn and oc commands.

Prerequisites

  • You must have the kn cli installed.

Procedure

  1. Delete the trigger:

    $ kn trigger delete <trigger_name>

  2. Delete the service:

    $ kn service delete <service_name>

  3. Delete the event source:

    $ kn source apiserver delete <source_name>

  4. Delete the service account, cluster role, and cluster binding:

$ oc delete -f authentication.yaml

Using the ApiServerSource with the YAML method

This guide describes the steps required to create an ApiServerSource using YAML files.

Prerequisites

  • You will need to have a Knative Serving and Eventing installation.

  • You will need to have created the default broker in the same namespace as the one defined in the ApiServerSource YAML file.

Procedure

  1. To create a service account, role, and role binding for the ApiServerSource, create a file named authentication.yaml and copy the following sample code into it:

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: events-sa
  namespace: default (1)

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: event-watcher
  namespace: default (1)
rules:
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - get
      - list
      - watch

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k8s-ra-event-watcher
  namespace: default (1)
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: event-watcher
subjects:
  - kind: ServiceAccount
    name: events-sa
    namespace: default (1)
    1 Change this namespace to the namespace that you have selected for installing ApiServerSource.

    If you want to re-use an existing service account with the appropriate permissions, you must modify the authentication.yaml for that service account.

    After you have created the authentication.yaml file, apply it:

    $ oc apply -f authentication.yaml

  2. To create an ApiServerSource event source, create a file named k8s-events.yaml and copy the following sample code into it:

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

    After you have created the k8s-events.yaml file, apply it:

    $ oc apply -f k8s-events.yaml

  3. To check that the ApiServerSource is set up correctly, create a Knative service that dumps incoming messages to its log.

    Copy the following sample YAML into a file named service.yaml:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-display
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2

    After you have created the service.yaml file, apply it:

    $ oc apply -f service.yaml

  4. To create a trigger from the default broker that filters events to the service created in the previous step, create a file named trigger.yaml and copy the following sample code into it:

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

    After you have created the trigger.yaml file, apply it:

    $ oc apply -f trigger.yaml

  5. To create events, launch a Pod in the default namespace:

    $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

  6. To check that the controller is mapped correctly, enter the following command and inspect the output:

    $ oc get apiserversource.sources.knative.dev testevents -o yaml
    Example output
    apiVersion: sources.knative.dev/v1alpha1
kind: ApiServerSource
metadata:
  annotations:
  creationTimestamp: "2020-04-07T17:24:54Z"
  generation: 1
  name: testevents
  namespace: default
  resourceVersion: "62868"
  selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
  uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
spec:
  mode: Resource
  resources:
  - apiVersion: v1
    controller: false
    controllerSelector:
      apiVersion: ""
      kind: ""
      name: ""
      uid: ""
    kind: Event
    labelSelector: {}
  serviceAccountName: events-sa
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1beta1
      kind: Broker
      name: default
Verification steps

To verify that the Kubernetes events were sent to Knative, you can look at the message dumper function logs.

  1. Get the Pods:

    $ oc get pods

  2. View the message dumper function logs for the Pods:

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container
    Example output
    ☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: dev.knative.apiserver.resource.update
  datacontenttype: application/json
  ...
Data,
  {
    "apiVersion": "v1",
    "involvedObject": {
      "apiVersion": "v1",
      "fieldPath": "spec.containers{hello-node}",
      "kind": "Pod",
      "name": "hello-node",
      "namespace": "default",
       .....
    },
    "kind": "Event",
    "message": "Started container",
    "metadata": {
      "name": "hello-node.159d7608e3a3572c",
      "namespace": "default",
      ....
    },
    "reason": "Started",
    ...
  }

Deleting the ApiServerSource

This section describes how to delete the ApiServerSource, trigger, service, service account, cluster role, and cluster binding by deleting their YAML files.

Procedure

  1. Delete the trigger:

    $ oc delete -f trigger.yaml

  2. Delete the service:

    $ oc delete -f service.yaml

  3. Delete the event source:

    $ oc delete -f k8s-events.yaml

  4. Delete the service account, cluster role, and cluster binding:

    $ oc delete -f authentication.yaml