Una guía paso a paso de los eventos de Knative

En un artículo anterior, expliqué cómo crear una pequeña aplicación con Knative, que es un proyecto de código abierto que agrega componentes a Kubernetes para su implementación, ejecución y administración. sin servidor, nativo de la nube aplicaciones En este artículo, explicaré los eventos de Knative, una forma de crear, enviar y verificar eventos en su entorno nativo de la nube.

Los eventos se pueden generar a partir de muchas fuentes en su entorno y pueden resultar confusos de administrar o definir. Dado que Knative sigue el Eventos en la nube especificación, le permite tener un punto común de abstracción para su entorno, donde los eventos se definen de acuerdo con una especificación.

Este artículo explica cómo instalar Knative eventing versión 0.20.0 y cómo crear, desencadenar y verificar eventos. Como hay muchos pasos involucrados, le sugiero que mire el mío repositorio GitHub para revisar este artículo con los archivos.

Índice

Establece tu configuración

Este tutorial utiliza minicubo con Kubernetes 1.19.0. También realiza algunos cambios en la configuración del entorno Minikube.

Comandos de preconfiguración de Minikube:

$ minikube config set kubernetes-version v1.19.0
$ minikube config set memory 4000
$ minikube config set cpus 4

Antes de iniciar Minikube, ejecute los siguientes comandos para asegurarse de que su configuración permanezca e inicie Minikube:

$ minikube delete
$ minikube start

Instalar eventos Knative

Instale las definiciones de recursos personalizadas (CRD) de Knative eventing mediante kubectl. A continuación se muestra el comando y un fragmento de la salida:

$ kubectl apply --filename https://github.com/knative/eventing/releases/download/v0.20.0/eventing-crds.yamlcustomresourcedefinition.apiextensions.k8s.io/apiserversources.sources.knative.dev created
customresourcedefinition.apiextensions.k8s.io/brokers.eventing.knative.dev created
customresourcedefinition.apiextensions.k8s.io/channels.messaging.knative.dev created
customresourcedefinition.apiextensions.k8s.io/triggers.eventing.knative.dev created

Luego, instale los componentes principales usando kubectl:

$ kubectl apply --filename https://github.com/knative/eventing/releases/download/v0.20.0/eventing-core.yaml
namespace/knative-eventing created
serviceaccount/eventing-controller created
clusterrolebinding.rbac.authorization.k8s.io/eventing-controller created

Dado que está ejecutando una versión independiente del servicio de eventos de Knative, debe instalar el canal en la memoria para pasar los eventos. Usando kubectl, ejecute:

$ kubectl apply --filename https://github.com/knative/eventing/releases/download/v0.20.0/in-memory-channel.yaml

Instale el intermediario, que utiliza canales y realiza el enrutamiento de eventos:

$ kubectl apply --filename https://github.com/knative/eventing/releases/download/v0.20.0/mt-channel-broker.yaml
clusterrole.rbac.authorization.k8s.io/knative-eventing-mt-channel-broker-controller created
clusterrole.rbac.authorization.k8s.io/knative-eventing-mt-broker-filter created

A continuación, cree un espacio de nombres y agregue un pequeño intermediario; este intermediario enruta los eventos a los disparadores. Cree su espacio de nombres usando kubectl:

$ kubectl create namespace eventing-test
namespace/eventing-test created

Ahora cree un pequeño corredor llamado default en su espacio de nombres. El siguiente es el YAML de mi corredor.yaml archivo (que se puede encontrar en mi repositorio de GitHub):

apiVersion: eventing.knative.dev/v1
kind: broker
metadata:
  name: default
  namespace: eventing-test

Luego aplique su archivo de intermediario usando kubectl:

$ kubectl create -f broker.yaml
   broker.eventing.knative.dev/default created

Verifique que todo esté en funcionamiento (debería ver la salida de confirmación) después de ejecutar el comando:

$ kubectl -n eventing-test get broker default                                                              
NAME      URL                                                                              AGE    READY   REASON
default   http://broker-ingress.knative-eventing.svc.cluster.local/eventing-test/default   3m6s   True

Necesitará esta URL de la salida del corredor más adelante para el envío del evento, así que guárdela.

Crear consumidores de eventos

Ahora que todo está instalado, puede comenzar a configurar los componentes para que funcionen con eventos.

En primer lugar, debe crear consumidores de eventos. Creará dos consumidores en este tutorial: hola pantalla Y exhibición de despedida. Tener dos consumidores le permite ver cómo dirigirse a un consumidor por mensaje de evento.

El código YAML de la pantalla Hello:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-display
spec:
  replicas: 1
  selector:
    matchLabels: &labels
      app: hello-display
  template:
    metadata:
      labels: *labels
    spec:
      Contenedores:
        - name: event-display
          image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display---

kind: Service
apiVersion: v1
metadata:
  name: hello-display
spec:
  selector:
    app: hello-display
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

El código YAML de la pantalla de despedida:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: goodbye-display
spec:
  replicas: 1
  selector:
    matchLabels: &labels
      app: goodbye-display
  template:
    metadata:
      labels: *labels
    spec:
      Contenedores:
        - name: event-display

          # Source code: https://github.com/knative/eventing-contrib/tree/master/cmd/event_display
          image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display---

kind: Service
apiVersion: v1
metadata:
  name: goodbye-display
spec:
  selector:
    app: goodbye-display
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Las diferencias en YAML entre los dos consumidores están en el app Y metadata name secciones. Aunque ambos consumidores están en los mismos puertos, puede apuntar a uno al generar un evento. Cree consumidores usando kubectl:

$ kubectl -n eventing-test apply -f hello-display.yaml

deployment.apps/hello-display created

service/hello-display created$ kubectl -n eventing-test apply -f goodbye-display.yaml
deployment.apps/goodbye-display created
service/goodbye-display created

Verifique que las distribuciones se estén ejecutando después de aplicar los archivos YAML:

$ kubectl -n eventing-test get deployments hello-display goodbye-display
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
hello-display     1/1     1            1           2m4s
goodbye-display   1/1     1            1           34s

Crear disparador

Ahora debe crear los disparadores, que definen los eventos que recibe el consumidor. Puede definir disparadores para usar cualquier filtro de sus eventos en la nube. El corredor recibe los eventos del activador y los envía al consumidor correcto. Esta serie de ejemplos crea dos disparadores con diferentes definiciones. Por ejemplo, puede enviar eventos con el tipo de atributo greeting al hello-display consumidor.

El código greeting-trigger.yaml:

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: hello-display
spec:
  broker: default
  filter:
    attributes:
      type: greeting
  subscriber:
    ref:
     apiVersion: v1
     kind: Service
     name: hello-display

Para crear el primer disparador, aplica tu archivo YAML:

$ kubectl -n eventing-test apply -f greeting-trigger.yaml
trigger.eventing.knative.dev/hello-display created

Luego, crea el segundo disparador usando sendoff-trigger.yaml. Esto envía cualquier cosa con el atributo source sendoff para usted goodbye-display consumidor.

El código sendoff-trigger.yaml:

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: goodbye-display
spec:
  broker: default
  filter:
    attributes:
      source: sendoff
  subscriber:
    ref:
      apiVersion: v1
      kind: Service
      name: goodbye-display

Luego, aplique su segunda definición de activador al clúster:

$ kubectl -n eventing-test apply -f sendoff-trigger.yaml
trigger.eventing.knative.dev/goodbye-display created

Confirme que todo está bien obteniendo sus disparadores del clúster usando kubectl:

$ kubectl -n eventing-test get triggers
NAME              BROKER    SUBSCRIBER_URI                                            AGE   READY   
goodbye-display   default   http://goodbye-display.eventing-test.svc.cluster.local/   24s   True    
hello-display     default   http://hello-display.eventing-test.svc.cluster.local/     46s   True

Crear un productor de eventos

Crea un pod que puedas usar para publicar eventos. Esta es una distribución de pod simple con acceso curl y SSH a su disposición enviar eventos usando curl. Dado que solo se puede acceder al intermediario desde el clúster donde está instalado el evento de Knative, el pod debe estar en el clúster; esta es la única forma de enviar eventos al clúster. Utilizar el productor-de-eventos.yaml archivo con este código:

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: curl
  name: curl
spec:
  Contenedores:
    - image: radial/busyboxplus:curl
      imagePullPolicy: IfNotPresent
      name: curl
      resources: {}
      stdin: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      tty: true

Luego, implemente el pod usando kubectl:

$ kubectl -n eventing-test apply -f event-producer.yaml
pod/curl created

Para verificar, obtenga la distribución y asegúrese de que el pod esté en funcionamiento:

$ kubectl get pods -n eventing-test
NAME                               READY   STATUS    RESTARTS   AGE
curl                               1/1     Running   0          8m13s

Enviar algunos eventos

Dado que este artículo ha sido tan pesado en la configuración, supongo que estará feliz de finalmente poder publicar algunos eventos y probar sus servicios. Los eventos deben pasarse internamente al clúster. Por lo general, los eventos se definen en torno a las aplicaciones dentro del clúster y se originan en esas aplicaciones. Pero este ejemplo enviará eventos manualmente desde su pod nombrado acurrucarse.

Comience iniciando sesión en el pod:

$ kubectl -n eventing-test attach curl -it

Una vez que haya iniciado sesión, verá un resultado similar a:

Defaulting container name to curl.
Use 'kubectl describe pod/curl -n eventing-test' to see all of the Contenedores in this pod.
If you don't see a command prompt, try pressing enter.
[ [email protected]:/ ]$

Ahora, genera un evento usando curl. Esto requiere algunas definiciones adicionales y requiere la URL del intermediario generada durante la instalación. Este ejemplo envía un saludo al corredor:

curl -v "http://broker-ingress.knative-eventing.svc.cluster.local/eventing-test/default" 
  -X POST 
  -H "Ce-Id: say-hello" 
  -H "Ce-Specversion: 1.0" 
  -H "Ce-Type: greeting" 
  -H "Ce-Source: not-sendoff" 
  -H "Content-Type: application/json" 
  -d '{"msg":"Hello Knative!"}'

Ce es la abreviatura de CloudEvent, que es el Especificación estandarizada de CloudEventos que sigue Knative. También es necesario conocer el ID del evento (útil para comprobar que se ha entregado), el tipo, la fuente (que debe especificar que no es un sendoff para que no vaya a la fuente definida en el disparador de envío) y un mensaje.

Cuando ejecuta el comando, esta debería ser la salida (y debería obtener un 202 Aceptado respuesta):

> POST /eventing-test/default HTTP/1.1
> User-Agent: curl/7.35.0
> Host: broker-ingress.knative-eventing.svc.cluster.local
> Accept: */*
> Ce-Id: say-hello
> Ce-Specversion: 1.0
> Ce-Type: greeting
> Ce-Source: not-sendoff
> Content-Type: application/json
> Content-Length: 24
>
< HTTP/1.1 202 Accepted
< Date: Sun, 24 Jan 2021 22:25:25 GMT
< Content-Length: 0

202 significa que el disparador lo envió a hola pantalla consumidor (debido a la definición).

Luego, envíe una segunda definición al exhibición de despedida consumidor con este nuevo comando curl:

curl -v "http://broker-ingress.knative-eventing.svc.cluster.local/eventing-test/default" 
  -X POST 
  -H "Ce-Id: say-goodbye" 
  -H "Ce-Specversion: 1.0" 
  -H "Ce-Type: not-greeting" 
  -H "Ce-Source: sendoff" 
  -H "Content-Type: application/json" 
  -d '{"msg":"Goodbye Knative!"}'

Esta vez es un sendoff y no un saludo basado en la definición de activación de la sección de configuración anterior. Está dirigido a la exhibición de despedida consumidor.

Su salida debería verse así, con otro 202 devuelto:

> POST /eventing-test/default HTTP/1.1
> User-Agent: curl/7.35.0
> Host: broker-ingress.knative-eventing.svc.cluster.local
> Accept: */*
> Ce-Id: say-goodbye
> Ce-Specversion: 1.0
> Ce-Type: not-greeting
> Ce-Source: sendoff
> Content-Type: application/json
> Content-Length: 26
>
< HTTP/1.1 202 Accepted
< Date: Sun, 24 Jan 2021 22:33:00 GMT
< Content-Length: 0

¡Felicitaciones, ha enviado dos eventos!

Antes de pasar a la siguiente sección, salga del pod escribiendo Salida.

Consulta los eventos

Ahora que se publicaron los eventos, ¿cómo sabe que los recibieron los consumidores correctos? Acudir a cada consumidor y comprobarlo en las bitácoras.

Comience con el hola pantalla consumidor::

$ kubectl -n eventing-test logs -l app=hello-display --tail=100

No hay mucho en ejecución en este clúster de ejemplo, por lo que solo debería ver un evento:

☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: greeting
  source: not-sendoff
  id: say-hello
  datacontenttype: application/json
Extensions,
  knativearrivaltime: 2021-01-24T22:25:25.760867793Z
Data,
  {
    "msg": "Hello Knative!"
  }

Confirmaste el hola pantalla consumidor recibió el evento! Ahora echa un vistazo a la exhibición de despedida consumidor y asegúrese de que el otro mensaje lo hizo.

Comience ejecutando el mismo comando pero con exhibición de despedida:

$ kubectl -n eventing-test logs -l app=goodbye-display --tail=100
☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: not-greeting
  source: sendoff
  id: say-goodbye
  datacontenttype: application/json
Extensions,
  knativearrivaltime: 2021-01-24T22:33:00.515716701Z
Data,
  {
    "msg": "Goodbye Knative!"
  }

Parece que ambos eventos han llegado a sus posiciones correctas. ¡Felicitaciones, has trabajado oficialmente con Knative eventing!

Ronda de bonificación: envíe un evento a múltiples consumidores

Entonces, ha enviado eventos a cada consumidor usando curl, pero ¿qué sucede si desea enviar un evento a ambos consumidores? Esto usa un comando curl similar pero con algunos ajustes interesantes. En disparadores anteriores, cada uno se definía con un atributo diferente. El gatillo de saludo tenía un atributo typey el disparador de envío tenía un atributo source. Esto significa que puede realizar una llamada curl y enviarla a ambos consumidores.

Aquí hay un ejemplo curl de una definición para enviar un evento a ambos consumidores:

curl -v "http://broker-ingress.knative-eventing.svc.cluster.local/eventing-test/default" 
  -X POST 
  -H "Ce-Id: say-hello-goodbye" 
  -H "Ce-Specversion: 1.0" 
  -H "Ce-Type: greeting" 
  -H "Ce-Source: sendoff" 
  -H "Content-Type: application/json" 
  -d '{"msg":"Hello Knative! Goodbye Knative!"}'

Como puede ver, la definición de este comando curl ha cambiado para establecer el source por exhibición de despedida y el type por hola pantalla.

Aquí hay un resultado de ejemplo de cómo se ven los eventos después de que se envían.

Salida de evento enviada:

> POST /eventing-test/default HTTP/1.1
> User-Agent: curl/7.35.0
> Host: broker-ingress.knative-eventing.svc.cluster.local
> Accept: */*
> Ce-Id: say-hello-goodbye
> Ce-Specversion: 1.0
> Ce-Type: greeting
> Ce-Source: sendoff
> Content-Type: application/json
> Content-Length: 41
>
< HTTP/1.1 202 Accepted
< Date: Sun, 24 Jan 2021 23:04:15 GMT
< Content-Length: 0

Salida de pantalla alta (que muestra dos eventos):

$ kubectl -n eventing-test logs -l app=hello-display --tail=100
☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: greeting
  source: not-sendoff
  id: say-hello
  datacontenttype: application/json
Extensions,
  knativearrivaltime: 2021-01-24T22:25:25.760867793Z
Data,
  {
    "msg": "Hello Knative!"
  }
☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: greeting
  source: sendoff
  id: say-hello-goodbye
  datacontenttype: application/json
Extensions,
  knativearrivaltime: 2021-01-24T23:04:15.036352685Z
Data,
  {
    "msg": "Hello Knative! Goodbye Knative!"
  }

Salida de pantalla de despedida (incluso con dos eventos):

$ kubectl -n eventing-test logs -l app=goodbye-display --tail=100
☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: not-greeting
  source: sendoff
  id: say-goodbye
  datacontenttype: application/json
Extensions,
  knativearrivaltime: 2021-01-24T22:33:00.515716701Z
Data,
  {
    "msg": "Goodbye Knative!"
  }
☁️  cloudevents.Event
Validation: valid
Context Attributes,
  specversion: 1.0
  type: greeting
  source: sendoff
  id: say-hello-goodbye
  datacontenttype: application/json
Extensions,
  knativearrivaltime: 2021-01-24T23:04:15.036352685Z
Data,
  {
    "msg": "Hello Knative! Goodbye Knative!"
  }

Como puede ver, el evento fue para ambos consumidores según la definición de su erizo. Si es necesario enviar un evento a más de un lugar, puede escribir definiciones para enviarlo a más de un consumidor.

¡Darle una oportunidad!

Los eventos internos en eventos en la nube son bastante fáciles de rastrear si se encuentran en una ubicación predefinida de su elección. ¡Diviértete viendo hasta dónde puedes llegar con los eventos en tu clúster!

Artículos de interés