Kubernetes API Event Driven Triggering of Tekton Pipelines

Posted: March 30th, 2021 | Author: | Filed under: Technology | Tags: , , , | No Comments »

Knative

Microservices emphasizes the use of decoupling different units of an overall system, and this is evident when operating in a Kubernetes environment. As we have seen thus far through the implementation of Tekton for our solution, the Pipeline and Triggers components are separate and are loosely connected as needed. In the world of Knative, and specifically Knative Eventing, the goal is to provide a decoupled relation between event producers and consumers. Events may originate from a variety of sources, both within a Kubernetes environment or externally and Event Sources are the KNative resource that links the producer to the consumer, also known as a Sink. Examples of Event Sources include PingSources which produce events based on a cron schedule, ContainerSources that can send events from a container, as well as a number of third party options. Another option is the APIServerSource Event Source which will send an event whenever a resource within Kubernetes is created, updated or deleted; perfectly satisfying our need to be notified whenever an Image resource is modified in order to trigger the Tekton pipeline.

Similar to a Tekton EventListener, a pod is created whenever a Knative Event Source is created in order to facilitate the communication between the producer and consumer. Since the APIServerSource communicates with the Kubernetes API server, the service account used within the pod must be granted appropriate rights for the resources that it is monitoring. To conform with the principle of least privilege, a separate service account will be created with appropriate rights to query the Kubernetes API to facilitate monitoring changes to Image resources. Since the Image resource is cluster scoped, a ClusterRole and ClusterRoleBinding will be created. To monitor Image resources, the following ClusterRole can be created to enable the appropriate rights needed by the Event Source:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: image-watcher
rules:
  - verbs:
      - get
      - list
      - watch
    apiGroups:
      - image.openshift.io
    resources:
      - images

Execute the following commands to create a new service account called image-watcher along with the necessary Role Based Access Control policies:

kubectl create -f knative/image-watcher-serviceaccount.yaml
kubectl create -f knative/image-watcher-clusterole.yaml
kubectl create -f knative/image-watcher-clusterolebinding.yaml

Next, create the APIServerSource which will define the resource to monitor along with the destination. The contents of the knative/image-watcher-apiserversource.yaml contain the desired configuration:

apiVersion: sources.knative.dev/v1
kind: ApiServerSource
metadata:
  name: image-watcher
spec:
  mode: Resource
  resources:
    - apiVersion: image.openshift.io/v1
      kind: Image
  serviceAccountName: image-watcher
  sink:
    uri: http://el-image-eventlistener:8080

Let’s break down the configuration of the APIServerSource resource defined above:

  • The image-watcher service account is used in the resulting pod that is started when an APIServerSource resource is created
  • resources are the Kubernetes API resources that will be monitored and in this case, only changes to Images will be monitored
  • mode determines the contents of the event that will be sent to the consumer. Mode can either be set as Reference or Resource. 
    • Reference – The kind, name and namespace of the resource
    • Resource – The contents of the modified resource
  • sink refers to the destination where events are sent. This can be defined as a Kubernetes service or a URI.

By default, Event Sources that have a sink reference of type service communicate on port 80. Since Tekton EventListener’s define their associated Service on port 8080, a uri reference will be used instead in order to provide additional flexibility.

By now, you may have noticed the term “events” being used previously in different portions of the conversation, but may wonder what this really means. An event in both Knative and Tekton ecosystems refers to CloudEvents,  a specification for describing event data in a common way. As systems are decomposed from one another, the ability to communicate using a consistent format enables the consumer not worry about the producer or the method in which they will transmit. The Tekton EventListener will listen for events and the APIServerSource will produce messages in a format that can be understood by both parties.

Add the APIServerSource to the cluster to complete the integration:

kubectl create -f knative/image-watcher-apiserversource.yaml

Check the status of the APIServerSource to confirm that it is ready

kubectl get apiserversource

NAME            SINK                                 AGE   READY   REASON
image-watcher   http://el-image-eventlistener:8080   14s   True

The Ready status of “True” indicates that the APIServerSource is successfully configured and monitoring for changes to Image resources.

1 2 3 4

Leave a Reply