Shulou(Shulou.com)06/01 Report--

How to implement a Registry event registration mechanism in Knative Eventing? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Background

As event consumers, it is impossible to know which events can be consumed beforehand, and if they can obtain which Broker provides which events in some way, then event consumers can easily consume events through these Broker. It is under this background that Registry is proposed. Through the Registry mechanism, consumers can subscribe to specific Broker events through Trigger.

Appeal

Each Registry corresponds to a Namespace as the boundary of resource isolation

Registry includes a list of event types to provide an event discovery mechanism through which we can decide which Ready events to consume

Since events eventually need to be subscribed through Trigger, the event type information needs to include the information needed to create the Trigger.

Implementation defines EventType CRD resources

Define CRD resources of type EventType. Example yaml:

ApiVersion: eventing.knative.dev/v1alpha1kind: EventTypemetadata: name: com.github.pullrequest namespace: defaultspec: type: com.github.pull_request source: github.com schema: / / github.com/schemas/pull_request description: "GitHub pullrequest" broker: default

Name: it needs to conform to k8s naming convention when setting.

Type: follow the CloudEvent type setting.

Source: follow the CloudEvent source setting.

Schema: it can be JSON schema, protobuf schema, etc. Optional.

Description: event description, optional.

Broker: the Broker of the provided EventType.

Event registration and discovery

1. Create EventType

In general, we create EventType to implement the registration of events in two ways.

1.1 automatic registration through Event event source instance

Based on the event source instance, create an EventType through the event source controller to register:

ApiVersion: sources.eventing.knative.dev/v1alpha1kind: GitHubSourcemetadata: name: github-source-sample namespace: defaultspec: eventTypes:-push-pull_request ownerAndRepository: my-other-user/my-other-repo accessToken: secretKeyRef: name: github-secret key: accessToken secretToken: secretKeyRef: name: github-secret key: secretToken sink: apiVersion: eventing.knative.dev/v1alpha1kind: Broker name: default

By running the yaml information above, the GitHubSource event source controller can create two EventType for registration: event type dev.knative.source.github.push and event type dev.knative.source.github.pull_request, where source is github.com and Broker named default. The details are as follows:

ApiVersion: eventing.knative.dev/v1alpha1kind: EventTypemetadata: generateName: dev.knative.source.github.push- namespace: default owner: # Owned by github-source-samplespec: type: dev.knative.source.github.push source: github.com broker: default---apiVersion: eventing.knative.dev/v1alpha1kind: EventTypemetadata: generateName: dev.knative.source.github.pullrequest- namespace: default owner: # Owned by github-source-samplespec: type: dev.knative.source.github.pull_request source: github.com broker: default

Here are two points to note:

Avoid name conflicts by automatically generating default names. Whether it should be generated when the code (in this case, the GithubSource controller) creates the event type needs to be further discussed.

We added dev.knative.source.github to spec.type. Prefix, which also needs further discussion to determine whether it is reasonable or not.

1.2 Manual registration

Register directly by creating EventType CR resources, such as:

ApiVersion: eventing.knative.dev/v1alpha1kind: EventTypemetadata: name: org.bitbucket.repofork namespace: defaultspec: type: org.bitbucket.repo:fork source: bitbucket.org broker: dev description: "BitBucket fork"

In this way, you can register the name org.bitbucket.repofork, type as org.bitbucket.repo:fork, source as bitbucket.org, and EventType that belongs to dev Broker.

two。 Get event registration for Registry

Event consumers can obtain the event registration list for Registry in the following ways:

$kubectl get eventtypes-n default

NAME TYPE SOURCE SCHEMA BROKER DESCRIPTION READY REASONorg.bitbucket.repofork org.bitbucket.repo:fork bitbucket.org Dev BitBucket fork False BrokerIsNotReadycom.github.pullrequest com.github.pull_request github.com/ / github.com/schemas/pull_request default GitHub pullrequest True dev.knative.source.github.push-34cnb dev.knative.source.github.push github.com Default True dev.knative.source.github.pullrequest-86jhv dev.knative.source.github.pull_request github.com default True

3.Trigger subscription event

Finally, based on the event registration list information, the event consumer creates a corresponding Trigger to monitor the consumption of the EventType in the Registry.

Trigger example:

ApiVersion: eventing.knative.dev/v1alpha1kind: Triggermetadata: name: my-service-trigger namespace: defaultspec: filter: sourceAndType: type: dev.knative.source.github.push source: github.com subscriber: ref: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: my-service other

For Registry, the following problems may be involved:

Registry is a Trigger subscription event, does it include the handling of Event Source event sources?

A: the original intention of Registry is to enable consumers to discover and consume events, so it mainly allows users to create Trigger for event subscription.

If you just create an Event Source and set up KnService for event consumption through Sink (without Trigger), can you also use Registry?

Answer: Registry is designed primarily for the Broker/Trigger event handling model, and we can find that the Broker field in EventType is required. If no event is sent to Broker, no EventType will be created to register with Registry. In terms of implementation, we can check whether the Sink type of Event Source is Broker, and if so, register EventType for it.

Whether resources can be filtered through the CloudEvents subject field

A: the EventType CRD resource will not contain the subject field because we believe that subject is a higher-level filtering setting. However, the community will follow through the advanced filtering rules. For example:

ApiVersion: eventing.knative.dev/v1alpha1kind: Triggermetadata: name: only-knativespec: filter: cel: expression: ce.subject.match ("/ knative/*") subscriber: ref: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: knative-events-processor after reading the above, have you mastered how to implement a Registry event registration mechanism in Knative Eventing? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.