Обзор

Регистр событий поддерживает каталог типов событий, которые могут быть получены из различных посредников (Brokers). Он вводит новый EventType CRD для сохранения информации о типах событий в хранилище данных кластера.

Перед началом

1. Изучите информацию о посредниках и триггерах.
2. Ознакомьтесь с спецификацией CloudEvents, особенно с разделом Контекстные атрибуты.
3. Ознакомьтесь с источниками событий.

Обнаружение событий с помощью регистра

С помощью регистра вы можете обнаружить различные типы событий, которые можно получить из сетей событий посредников. Регистр предназначен для использования в модели Broker/Trigger и направлен на помощь в создании триггеров.

Чтобы увидеть доступные типы событий для подписки, выполните следующую команду:

kubectl get eventtypes -n <namespace>Вот пример вывода выполнения вышеупомянутой команды с использованием пространства имен default в тестовом кластере. В следующем разделе мы обсудим, как был заполнен этот регистр.

NAME                                         TYPE                                    SOURCE                                                               SCHEMA        BROKER     ОПИСАНИЕ     ГОТОВ     ПРИЧИНА
dev.knative.source.github.push-34cnb         dev.knative.source.github.push          https://github.com/knative/eventing                                                default                    Да
dev.knative.source.github.push-44svn         dev.knative.source.github.push          https://github.com/knative/serving                                                 default                    Да
dev.knative.source.github.pullrequest-86jhv  dev.knative.source.github.pull_request  https://github.com/knative/eventing                                                default                    Да
dev.knative.source.github.pullrequest-97shf  dev.knative.source.github.pull_request  https://github.com/knative/serving                                                 default                    Да
dev.knative.kafka.event-cjvcr                dev.knative.kafka.event                 /apis/v1/namespaces/default/kafkasources/kafka-sample#news                         default                    Да
dev.knative.kafka.event-tdt48                dev.knative.kafka.event                 /apis/v1/namespaces/default/kafkasources/kafka-sample#knative-demo                 default                    Да
google.pubsub.topic.publish-hrxhh            google.pubsub.topic.publish             //pubsub.googleapis.com/knative/topics/testing                                     dev                        Нет     BrokerIsNotReady

Можно заметить, что в реестре пространства имен default существует семь различных типов событий (EventTypes). Давайте выберем первый из них и посмотрим, как выглядит YAML-файл EventType:```bash kubectl get eventtype dev.knative.source.github.push-34cnb -o yaml

Пропуская ненужные поля:

```yaml
apiVersion: eventing.knative.dev/v1
kind: EventType
metadata:
  name: dev.knative.source.github.push-34cnb
  namespace: default
  generateName: dev.knative.source.github.push-
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

С точки зрения потребителя, наиболее важными являются поля spec и status.

name является рекомендательным (неавторитетным), и мы обычно генерируем его (generateName), чтобы избежать конфликтов имен (например, два EventType, слушающих pull-запросы из двух разных репозиториев GitHub). Так как name и generateName не требуются для создания триггеров потребителями, мы отложим их обсуждение на поздний момент.

Что касается status, его основная цель — сообщить потребителям (или операторам кластера) о готовности EventType к использованию. Эта готовность основана на готовности брокера. Из примера видно, что EventType не готов к использованию, так как его брокер default не готов.

Давайте подробнее рассмотрим поля spec:

• type: является авторитетным. Это относится к типу CloudEvent, когда он входит в сеть событий. Это обязательное поле. Потребители событий могут (и в большинстве случаев делают) создавать триггеры, фильтруя по этому атрибуту.- source: относится к источнику CloudEvent, когда он поступает в сеть событий. Это обязательное поле. Потребители событий могут (и в большинстве случаев делают) создавать триггеры, фильтруя по этому атрибуту.- schema: это валидный URI схемы EventType. Это может быть JSON-схема, схема protobuf и т.д. Это необязательное поле.

• description: это строка, описывающая, что представляет собой EventType. Это необязательное поле.

• broker: указывает на брокер, который может предоставить EventType. Это обязательное поле.

Подписка на события

Теперь, когда вы знаете, какие события могут быть получены из сетей событий брокеров, вы можете создать триггеры для подписки на конкретные события. Вот несколько примеров триггеров, которые подписываются на события с точным соответствием по type и/или source, на основе вышеуказанного вывода реестра:

1. Подписывается на _push_ы GitHub из любого источника.

   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

   В соответствии с вышеуказанным выводом реестра, для данного типа события (knative's eventing и serving репозитории) существуют только два источника. Если в будущем будут зарегистрированы новые источники для _push_ов GitHub, этот триггер сможет их потреблять.

2. Подписывается на pull запросы GitHub из репозитория knative's eventing. ```yaml 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

   
   ```yaml
   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

3. Подписывается на сообщения PubSub из проекта knative GCP, отправленные в топик testing.

   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

   Уведомление: события не смогут быть получены подписчиком этого триггера до тех пор, пока посредник не станет готовым.

Заполнение реестра

Теперь, когда мы знаем, как находить события с помощью реестра и как мы можем использовать эту информацию для подписки на события интереса, давайте перейдем к следующей теме: как мы на самом деле заполняем реестр?

• Ручная регистрация

  Чтобы заполнить реестр, конфигуратор кластера может вручную зарегистрировать типы событий. Это означает, что конфигуратор может просто применить файлы YAML для типов событий, как и с любым другим ресурсом Kubernetes:

  kubectl apply -f <event_type.yaml>- Автоматическая регистрация

  Поскольку ручная регистрация может быть утомительной и подверженной ошибкам, мы также поддерживаем автоматическую регистрацию типов событий. Создание типов событий происходит при создании источника событий. В настоящее время мы поддерживаем автоматическую регистрацию типов событий для следующих источников событий:

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

  Давайте рассмотрим пример, в частности, образец KafkaSource, который мы использовали для заполнения реестра в нашем тестовом кластере. Ниже приведен пример yaml.

  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

  Если вас интересует больше информации о конфигурационных опциях для KafkaSource, пожалуйста, обратитесь к образцу KafkaSource.

  Для этой дискуссии важной информацией из приведенного выше yaml являются sink и topics. Мы замечаем, что sink имеет тип Broker. В настоящее время мы поддерживаем автоматическое создание типов событий только для источников, указывающих на посредников. Что касается topics, это то, что мы используем для генерации поля source типов событий, которое равно атрибуту источника CloudEvent. Когда вы kubectl apply этот yaml, источник событий kafka-source-sample будет создан, и два типа событий будут добавлены в реестр (так как есть два топика). Вы можете это увидеть в примере вывода реестра из предыдущих разделов.## Что дальше

Чтобы продолжить, установите Knative Eventing, если вы еще этого не сделали, и попробуйте экспериментировать с различными источниками событий в вашем кластере Knative.

1. Установка Knative в случае, если вы еще этого не делали.
2. Начало работы с eventing в случае, если вы еще этого не делали.
3. Примеры кода Knative — полезный ресурс для лучшего понимания некоторых источников событий (не забудьте указать их на Брокер, если вы хотите автоматическое регистрацию EventTypes в реестре).