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

    customresourcedefinition.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

    Subir