Descubre y Gestiona Eventos con el Registro de Eventos

En el dinámico mundo de la computación sin servidor y las arquitecturas basadas en eventos, la gestión eficiente de eventos es crucial. Knative Eventing ofrece una solución robusta para esto, y una de sus piezas clave es el Registro de Eventos. Pero, ¿cuál es el propósito fundamental del Registro de Eventos y cómo puede beneficiarte?

¿Qué es el Registro de Eventos?

El Registro de Eventos, en el contexto de Knative Eventing, es esencialmente un catálogo centralizado de tipos de eventos disponibles para ser consumidos desde Brokers o Channels. Imagina una biblioteca donde no solo se almacenan libros, sino también la descripción detallada de cada uno, facilitando a los lectores (en este caso, los consumidores de eventos) encontrar exactamente lo que necesitan. Este registro se materializa mediante objetos EventType, los cuales contienen toda la información necesaria para que un consumidor pueda crear un Trigger (desencadenador) sin necesidad de recurrir a mecanismos externos o información fuera de banda.

Antes de sumergirnos en los detalles, es importante tener una comprensión básica de conceptos fundamentales de Knative Eventing como Brokers, Triggers, Fuentes de Eventos y la especificación CloudEvents, especialmente la sección de Context Attributes. Estos conceptos son los bloques de construcción sobre los que se asienta el Registro de Eventos.

Objetos EventType: La Clave del Registro

Los objetos EventType son las representaciones concretas de un tipo de evento específico que puede ser consumido desde un Broker o un Channel. Piensa en ellos como la ficha catalográfica de un evento. Estos eventos pueden ser variados, desde mensajes de Apache Kafka hasta notificaciones de pull requests de GitHub. La información contenida en los objetos EventType se almacena en el datastore del clúster, constituyendo el registro persistente.

Echemos un vistazo a un ejemplo simplificado de un archivo YAML de EventType:

apiVersion: eventing.knative.dev/v1beta2 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: reference : apiVersion: eventing.knative.dev/v1 kind: Broker name: default status : conditions : - status: "True" type: ReferenceExists - status: "True" type: Ready 

Aunque el campo metadata.name es orientativo y no autoritativo (generalmente generado automáticamente), los campos cruciales para los consumidores son spec y status. Estos campos proveen la información esencial para crear Triggers, como el origen (source) y el tipo del evento, y si la Referencia (Broker o Channel) está disponible para recibir eventos.

Campos Clave de Objetos EventType

Para comprender mejor la estructura de los objetos EventType, la siguiente tabla detalla los campos más importantes dentro de las secciones spec y status:

Poblando el Registro de Eventos

El Registro de Eventos puede ser poblado de dos maneras principales: manualmente o automáticamente. La opción automática suele ser más sencilla, aunque está limitada a ciertos tipos de fuentes de eventos.

Registro Manual

El registro manual implica la creación y aplicación de archivos YAML de EventType directamente en el clúster, de la misma manera que se gestionan otros recursos de Kubernetes. Para realizar el registro manual:

1. Crea un archivo YAML de EventType, asegurándote de incluir los campos requeridos (consulta la sección “Objetos EventType: La Clave del Registro”).
2. Aplica el YAML utilizando el comando: kubectl apply -f <event-type.yaml>

Este método te da control total sobre los EventTypes registrados, pero puede ser más laborioso y propenso a errores, especialmente si tienes un gran número de tipos de eventos.

Registro Automático

Para simplificar el proceso, Knative Eventing también soporta el registro automático de EventTypes. En este caso, los EventTypes se crean automáticamente cuando se instancia una fuente de eventos. Esto reduce significativamente la carga administrativa y asegura que el registro se mantenga actualizado con las fuentes de eventos disponibles.

Fuentes de Eventos con Soporte para Registro Automático

Knative ofrece soporte para el registro automático de EventTypes para las siguientes fuentes de eventos:

• PingSource
• ApiServerSource
• GithubSource
• GcpPubSubSource
• KafkaSource
• AwsSqsSource

Es importante destacar que Knative soporta la creación automática de EventTypes para fuentes que cumplen con el tipo Sources Duck type, lo que permite la extensibilidad a otras fuentes personalizadas.

Procedimiento para el Registro Automático

Para habilitar el registro automático, simplemente aplica el archivo YAML de tu fuente de eventos utilizando el comando:

kubectl apply -f <event-source.yaml>

Una vez que la fuente de eventos se instancia, los EventTypes correspondientes se añadirán automáticamente al registro.

Ejemplo: Registro Automático con KafkaSource

Consideremos el siguiente ejemplo de KafkaSource que poblará el registro:

apiVersion: sources.knative.dev/v1 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 

El campo topics en este ejemplo se utiliza para generar el campo source del EventType.

Después de ejecutar kubectl apply con este YAML, la KafkaSource llamada kafka-source-sample se instanciará, y se añadirán dos EventTypes al registro, uno por cada tema (topic) especificado: knative-demo y news.

Descubriendo Eventos en el Registro

Una de las principales ventajas del Registro de Eventos es la capacidad de descubrir fácilmente los diferentes tipos de eventos que los Brokers pueden consumir. Esto facilita la creación de Triggers precisos y evita tener que adivinar o buscar manualmente los tipos de eventos disponibles.

Para visualizar la lista de EventTypes registrados en un namespace específico, puedes usar el siguiente comando:

kubectl get eventtypes -n <namespace>

Por ejemplo, usando el namespace default en un clúster de pruebas, la salida podría ser similar a:

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 

Esta salida muestra siete objetos EventType diferentes en el registro del namespace default. Asume que las fuentes de eventos que emiten estos eventos tienen un Broker como su destino (sink).

Visualizando el YAML de un Objeto EventType

Para inspeccionar el YAML completo de un objeto EventType específico, utiliza el siguiente comando, reemplazando <name> con el nombre del EventType (columna NAME en la salida del registro):

kubectl get eventtype <name> -o yaml

Por ejemplo:

kubectl get eventtype dev.knative.source.github.push-34cnb -o yaml

Esto te proporcionará el YAML completo del objeto EventType, permitiéndote analizar todos sus detalles.

Suscribiéndose a Eventos Descubiertos

Una vez que has descubierto los tipos de eventos disponibles en los Brokers, puedes crear Triggers para suscribirte a eventos específicos de tu interés. Los Triggers actúan como filtros, permitiéndote recibir solo los eventos que cumplen con ciertos criterios definidos.

Aquí tienes algunos ejemplos de Triggers que se suscriben a eventos utilizando coincidencias exactas en los atributos type o source, basados en la salida de registro mostrada anteriormente:

Ejemplos de Triggers

Suscripción a Pushes de GitHub desde Cualquier Origen

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 

Este Trigger se activará para cualquier evento de tipo dev.knative.source.github.push, independientemente del repositorio de GitHub que origine el push. Si se registran nuevas fuentes para este tipo de evento, este Trigger también las consumirá automáticamente.

Suscripción a Pull Requests de GitHub del Repositorio knative/eventing

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 

Este Trigger es más específico, ya que se suscribe únicamente a eventos de tipo dev.knative.source.github.pull_request que provienen del repositorio de GitHub https://github.com/knative/eventing.

Suscripción a Mensajes de Kafka Enviados al Tema knative-demo

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 

Este Trigger se activa para mensajes de Kafka de tipo dev.knative.kafka.event originados en el tema knative-demo dentro de la KafkaSourcekafka-sample.

Suscripción a Mensajes de PubSub del Proyecto GCP knative al Tema 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 

Este último ejemplo se suscribe a mensajes de Google Cloud Pub/Sub originados en el tema testing dentro del proyecto knative. Es importante notar que en el ejemplo de salida del registro, el Broker asociado a este EventType se marcaba como “no listo” (BrokerIsNotReady). En este caso, el suscriptor de este Trigger no podrá consumir eventos hasta que el Broker esté en estado Ready.

Beneficios Clave del Registro de Eventos

El Registro de Eventos ofrece múltiples ventajas para la gestión de eventos en Knative Eventing:

• Descubrimiento Sencillo de Eventos: Permite a los consumidores descubrir de manera fácil y centralizada los tipos de eventos disponibles.
• Simplificación de la Suscripción: Facilita la creación de Triggers al proporcionar toda la información necesaria sobre los EventTypes.
• Reducción de la Complejidad: Elimina la necesidad de mecanismos externos o información fuera de banda para la gestión de tipos de eventos.
• Automatización: El registro automático, cuando es compatible con la fuente de eventos, reduce la carga administrativa y asegura que el registro esté siempre actualizado.
• Centralización: Consolida la información de EventTypes en un único lugar, mejorando la visibilidad y la gestión general de eventos.

Conclusión

El Registro de Eventos es un componente fundamental de Knative Eventing que simplifica significativamente la gestión y el consumo de eventos. Al proporcionar un catálogo centralizado y fácilmente accesible de EventTypes, facilita el descubrimiento de eventos y la creación de Triggers precisos. Ya sea mediante registro manual o automático, el Registro de Eventos optimiza el flujo de trabajo basado en eventos, permitiendo a los desarrolladores enfocarse en la lógica de sus aplicaciones en lugar de en la complejidad de la infraestructura de eventos. En definitiva, el Registro de Eventos es una herramienta poderosa para construir y gestionar arquitecturas basadas en eventos de manera eficiente y escalable con Knative Eventing.