事件注册表

Knative事件定义了一个EventType对象，以使消费者更容易发现他们可以从代理使用的事件类型。

The event registry maintains a catalog of event types that each Broker can consume. The event types stored in the registry contain all required information for a consumer to create a Trigger without resorting to some other out-of-band mechanism.

This topic provides information about how you can populate the event registry, how to discover events using the registry, and how to leverage that information to subscribe to events of interest.

Note

Before using the event registry, it is recommended that you have a basic understanding of Brokers, Triggers, Event Sources, and the CloudEvents spec (particularly the Context Attributes section).

关于EventType对象

EventType objects represent a type of event that can be consumed from a Broker, such as Kafka messages or GitHub pull requests. EventType objects are used to populate the event registry and persist event type information in the cluster datastore.

The following is an example EventType YAML that omits irrelevant fields:

apiVersion: eventing.knative.dev/v1beta1
kind: EventType
metadata:
  name: dev.knative.source.github.push-34cnb
  namespace: default
  labels:
    eventing.knative.dev/sourceName: github-sample
spec:
  type: dev.knative.source.github.push
  source: https://github.com/knative/eventing
  schema:
  description:
  broker: default
status:
  conditions:
    - status: "True"
      type: BrokerExists
    - status: "True"
      type: BrokerReady
    - status: "True"
      type: Ready

For the full specification for an EventType object, see the EventType API reference.

The metadata.name field is advisory, that is, non-authoritative. It is typically generated using generateName to avoid naming collisions. metadata.name is not needed when you create Triggers.

For consumers, the fields that matter the most are spec and status. This is because these fields provide the information you need to create Triggers, which is the source and type of event and whether the Broker is ready to receive events.

The following table has more information about the spec and status fields of EventType objects:

Field	Description	Required or optional
spec.type	Refers to the CloudEvent type as it enters into the event mesh. Event consumers can create Triggers filtering on this attribute. This field is authoritative.	Required
spec.source	Refers to the CloudEvent source as it enters into the event mesh. Event consumers can create Triggers filtering on this attribute.	Required
spec.schema	A valid URI with the EventType schema such as a JSON schema or a protobuf schema.	Optional
spec.description	A string describing what the EventType is about.	Optional
spec.broker	Refers to the Broker that can provide the EventType.	Required
status	Tells consumers, or cluster operators, whether the EventType is ready to be consumed or not. The readiness is based on the Broker being ready.	Optional

用事件填充注册表

You can populate the registry with EventType objects manually or automatically. Automatic registration can be the easier method, but it only supports a subset of event sources.

手动注册

For manual registration, the cluster configurator applies EventTypes YAML files the same as with any other Kubernetes resource.

To apply EventTypes YAML files manually:

1. Create an EventType YAML file. For information about the required fields, see About EventType objects.

2. Apply the YAML by running the command:

   kubectl apply -f <event-type.yaml>
   

自动登记

Because manual registration might be tedious and error-prone, Knative also supports registering EventTypes automatically. EventTypes are created automatically when an event source is instantiated.

支持自动注册

Knative supports automatic registration of EventTypes for the following event sources:

• CronJobSource
• ApiServerSource
• GithubSource
• GcpPubSubSource
• KafkaSource
• AwsSqsSource

Knative only supports automatic creation of EventTypes for sources that have a Broker as their sink.

自动登记程序

• To register EventTypes automatically, apply your event source YAML file by running the command:

  kubectl apply -f <event-source.yaml>
  

After your event source is instantiated, EventTypes are added to the registry.

示例:使用KafkaSource自动注册

Given the following KafkaSource sample to populate the registry:

apiVersion: sources.knative.dev/v1beta1
kind: KafkaSource
metadata:
  name: kafka-sample
  namespace: default
spec:
  bootstrapServers:
   - my-cluster-kafka-bootstrap.kafka:9092
  topics:
   - knative-demo
   - news
  sink:
    apiVersion: eventing.knative.dev/v1
    kind: Broker
    name: default

The topics field in the above example is used to generate the EventType source field.

After running kubectl apply using the above YAML, the KafkaSource kafka-source-sample is instantiated, and two EventTypes are added to the registry because there are two topics.

使用注册表发现事件

Using the registry, you can discover the different types of events that Broker event meshes can consume.

查看您可以订阅的所有事件类型

• To see a list of event types in the registry that are available to subscribe to, run the command:

  kubectl get eventtypes -n <namespace>
  

  Example output using the default namespace in a testing cluster:

  NAME                                         TYPE                                    SOURCE                                                               SCHEMA        BROKER     DESCRIPTION     READY     REASON
  dev.knative.source.github.push-34cnb         dev.knative.source.github.push          https://github.com/knative/eventing                                                default                    True
  dev.knative.source.github.push-44svn         dev.knative.source.github.push          https://github.com/knative/serving                                                 default                    True
  dev.knative.source.github.pullrequest-86jhv  dev.knative.source.github.pull_request  https://github.com/knative/eventing                                                default                    True
  dev.knative.source.github.pullrequest-97shf  dev.knative.source.github.pull_request  https://github.com/knative/serving                                                 default                    True
  dev.knative.kafka.event-cjvcr                dev.knative.kafka.event                 /apis/v1/namespaces/default/kafkasources/kafka-sample#news                         default                    True
  dev.knative.kafka.event-tdt48                dev.knative.kafka.event                 /apis/v1/namespaces/default/kafkasources/kafka-sample#knative-demo                 default                    True
  google.pubsub.topic.publish-hrxhh            google.pubsub.topic.publish             //pubsub.googleapis.com/knative/topics/testing                                     dev                        False     BrokerIsNotReady
  

  This example output shows seven different EventType objects in the registry of the default namespace. It assumes that the event sources emitting the events reference a Broker as their sink.

查看EventType对象的YAML

• To see the YAML for an EventType object, run the command:

  kubectl get eventtype <name> -o yaml
  

  Where <name> is the name of an EventType object and can be found in the NAME column of the registry output. For example, dev.knative.source.github.push-34cnb.

For an example EventType YAML, see About EventType objects earlier on this page.

关于订阅事件

After you know what events can be consumed from the Brokers' event meshes, you can create Triggers to subscribe to particular events.

Here are a some example Triggers that subscribe to events using exact matching on type or source, based on the registry output mentioned earlier:

• Subscribes to GitHub pushes from any source:

  apiVersion: eventing.knative.dev/v1
  kind: Trigger
  metadata:
   name: push-trigger
   namespace: default
  spec:
   broker: default
   filter:
     attributes:
       type: dev.knative.source.github.push
   subscriber:
     ref:
       apiVersion: serving.knative.dev/v1
       kind: Service
       name: push-service
  

  Note

  As the example registry output mentioned, only two sources, the knative/eventing and knative/serving GitHub repositories, exist for that particular type of event. If later on new sources are registered for GitHub pushes, this Trigger is able to consume them.

• Subscribes to GitHub pull requests from the knative/eventing GitHub repository:

  apiVersion: eventing.knative.dev/v1
  kind: Trigger
  metadata:
   name: gh-knative-eventing-pull-trigger
   namespace: default
  spec:
   broker: default
   filter:
     attributes:
       type: dev.knative.source.github.pull_request
       source: https://github.com/knative/eventing
   subscriber:
     ref:
       apiVersion: serving.knative.dev/v1
       kind: Service
       name: gh-knative-eventing-pull-service
  

• Subscribes to Kafka messages sent to the knative-demo topic:

  apiVersion: eventing.knative.dev/v1
  kind: Trigger
  metadata:
   name: kafka-knative-demo-trigger
   namespace: default
  spec:
   broker: default
   filter:
     attributes:
       type: dev.knative.kafka.event
       source: /apis/v1/namespaces/default/kafkasources/kafka-sample#knative-demo
   subscriber:
     ref:
       apiVersion: serving.knative.dev/v1
       kind: Service
       name: kafka-knative-demo-service
  

• Subscribes to PubSub messages from GCP's knative project sent to the testing topic:

  apiVersion: eventing.knative.dev/v1
  kind: Trigger
  metadata:
   name: gcp-pubsub-knative-testing-trigger
   namespace: default
  spec:
   broker: dev
   filter:
     attributes:
       source: //pubsub.googleapis.com/knative/topics/testing
   subscriber:
     ref:
       apiVersion: serving.knative.dev/v1
       kind: Service
       name: gcp-pubsub-knative-testing-service
  

  Note

  The example registry output mentioned earlier lists this Broker's readiness as false. This Trigger's subscriber cannot consume events until the Broker becomes ready.

下一步

Knative代码示例是一个有用的资源，可以更好地理解一些事件源。 记住，如果您想在注册表中自动注册eventtype，则必须将源指向代理。