Send your first event with Knative Eventing - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

O Knative Eventing usa o modelo Broker-Trigger para rotear e filtrar eventos entre serviços. Este tutorial implanta um sistema completo orientado a eventos no ACK: um Knative Service que recebe eventos, um Broker que os roteia, um Trigger que conecta ambos e um comando curl que envia o primeiro evento de ponta a ponta.

Como funciona

O Knative Eventing ingere eventos de sistemas externos e os encaminha internamente usando o padrão CloudEvents. O modelo Broker-Trigger é central nessa arquitetura: o Broker recebe eventos de qualquer origem, e cada Trigger se inscreve nesse Broker, aplica um filtro opcional e despacha os eventos correspondentes para um Service downstream.

A arquitetura consiste em seis componentes:

Origem do evento — fonte dos eventos, como uma atualização de banco de dados ou um serviço de mensagens em nuvem.
Ingress — recebe eventos externos no cluster Knative.
Channel — encaminha eventos dentro do modelo Broker-Trigger. Os canais compatíveis incluem ApsaraMQ for Kafka, NATS Streaming e InMemoryChannel. O padrão é o InMemoryChannel.
Broker — roteia eventos de diferentes origens conforme os Triggers configurados. Compatível com backends como NATS e ApsaraMQ for Kafka.
Trigger — define o roteamento de eventos para um Service específico. Cada Trigger possui um filtro de eventos e um Service de destino; apenas os eventos correspondentes são encaminhados.
Service — processador final que executa a lógica de negócios após receber eventos de um Trigger.

Pré-requisitos

Antes de começar, verifique se você tem:

Knative Serving instalado. Consulte Implantar o Knative.
Knative Eventing instalado. Consulte Implantar o Knative Eventing.

Etapa 1: Implantar um Knative Service

Implante o event-display, um Knative Service que recebe eventos e imprime o conteúdo nos logs. Após esta etapa, você terá um Service em execução pronto para consumir eventos.

Crie um arquivo chamado event-display.yaml com o seguinte conteúdo:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-display
  namespace: default
spec:
  template:
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/event-display:v1028

Implante o Service:
```
kubectl apply -f event-display.yaml
```

Verifique se o Service está pronto:

kubectl get ksvc

A saída esperada é semelhante a:

NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
event-display   http://event-display.default.example.com   event-display-00001   event-display-00001   True

Um valor READY igual a True confirma que o Service está em execução e pronto para receber eventos. Se o Service não atingir o estado Ready, execute o comando a seguir para diagnosticar:

kubectl describe ksvc event-display

Etapa 2: Criar um Broker e um Trigger

Crie um Broker chamado default e um Trigger chamado my-service-trigger. Após esta etapa, qualquer evento enviado ao Broker será roteado automaticamente para o Service event-display.

Criar um Broker

Crie um arquivo chamado broker.yaml com o seguinte conteúdo:

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: default

Implante o Broker:
```
kubectl apply -f broker.yaml
```
Verifique se o Broker está pronto:
```
kubectl get broker
```
A saída esperada é semelhante a:
```
NAME      URL                                                                        AGE   READY   REASON
default   http://broker-ingress.knative-eventing.svc.cluster.local/default/default   9s    True
```
O campo URL indica onde enviar eventos para este Broker. Um valor READY igual a True confirma que o Broker está configurado corretamente. Se o Broker não atingir o estado Ready, execute o comando a seguir para diagnosticar:
```
kubectl describe broker default
```

Criar um Trigger

Crie um arquivo chamado trigger.yaml com o seguinte conteúdo:
```
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: my-service-trigger
spec:
  broker: default
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display
```
Este Trigger não possui o campo filter , portanto, encaminha todos os eventos enviados ao Broker default para o event-display . Omitir o filtro é útil para testes e depuração. Em produção, adicione um filtro para rotear apenas tipos específicos de eventos.
Implante o Trigger:
```
kubectl apply -f trigger.yaml
```
Verifique se o Trigger está pronto:
```
kubectl get trigger
```
A saída esperada é semelhante a:
```
NAME                 BROKER    SUBSCRIBER_URI                                   AGE   READY   REASON
my-service-trigger   default   http://event-display.default.svc.cluster.local   22s   True
```
Um valor READY igual a True confirma que o Trigger está inscrito corretamente no Broker e encaminhará eventos para o event-display. Se o Trigger não atingir o estado Ready, execute o comando a seguir para diagnosticar:
```
kubectl describe trigger my-service-trigger
```

Etapa 3: Enviar um evento e verificar a entrega

Envie um evento de teste para o Broker e confirme se o event-display o recebe e registra nos logs. Esta etapa usa kubectl port-forward para expor localmente o endpoint interno do Broker e, em seguida, envia uma solicitação HTTP POST formatada como CloudEvents.

Encaminhe a porta de ingresso do Broker para sua máquina local:

kubectl port-forward svc/broker-ingress -n knative-eventing 8080:80

Em um terminal separado, envie uma solicitação POST para o Broker:

curl -v "http://localhost:8080/default/default" \
   -X POST \
   -H "Ce-Id: 536808d3-88be-4077-9d7a-a3f162705f79" \
   -H "Ce-Specversion: 1.0" \
   -H "Ce-Type: dev.knative.samples.helloworld" \
   -H "Ce-Source: dev.knative.samples/helloworldsource" \
   -H "Content-Type: application/json" \
   -d '{"msg":"Hello World from the curl pod."}'

A resposta esperada termina com:

< HTTP/1.1 202 Accepted

Uma resposta 202 Accepted confirma que o Broker recebeu a solicitação e aceitou o evento para processamento.

Obtenha o nome do pod event-display:

kubectl get pods --namespace=default | grep event-display

A saída esperada é semelhante a:

event-display-00001-deployment-766f7b9fd6-gfcz5   2/2     Running   0          3m43s

Visualize os logs do pod para confirmar a entrega do evento:

kubectl logs event-display-00001-deployment-766f7b9fd6-gfcz5

A saída esperada é semelhante a:

Defaulted container "user-container" out of: user-container, queue-proxy
☁️  cloudevents.Event
Context Attributes,
  specversion: 1.0
  type: dev.knative.samples.helloworld
  source: dev.knative.samples/helloworldsource
  id: 536808d3-88be-4077-9d7a-a3f162705f79
  datacontenttype: application/json
Extensions,
  knativearrivaltime: 2024-10-28T11:48:56.929517041Z
Data,
  {
    "msg": "Hello World from the curl pod1."
  }

O log confirma que o event-display recebeu o CloudEvent do Broker e imprimiu todo o seu conteúdo, incluindo os cabeçalhos CloudEvents e o payload JSON.

Próximos passos

Adicione um filtro ao Trigger para rotear apenas tipos específicos de eventos. Consulte Filtragem de Trigger.
Substitua o InMemoryChannel pelo ApsaraMQ for Kafka ou NATS Streaming para obter persistência de eventos adequada para produção.
Implante Triggers adicionais para distribuir eventos para múltiplos Services.