Bangun Workflow Berbasis Event dengan Knative Broker-Trigger di ACK - ACK

Knative Eventing menggunakan model Broker-Trigger untuk mengarahkan dan memfilter event antar layanan. Tutorial ini menerapkan sistem berbasis event yang lengkap di ACK: sebuah Knative Service yang menerima event, Broker yang mengarahkannya, Trigger yang menghubungkan keduanya, serta perintah curl yang mengirim event pertama secara end-to-end.

Cara kerja

Knative Eventing menerima event dari sistem eksternal dan meneruskannya secara internal menggunakan standar CloudEvents. Model Broker-Trigger berada di pusat arsitektur ini: Broker menerima event dari sumber apa pun, dan setiap Trigger berlangganan ke Broker tersebut, menerapkan filter opsional, lalu mengirimkan event yang sesuai ke Service downstream.

Arsitektur ini terdiri dari enam komponen:

Event source — asal event, seperti pembaruan database atau layanan messaging cloud.
Ingress — menerima event eksternal ke dalam kluster Knative.
Channel — meneruskan event dalam model Broker-Trigger. Channel yang didukung mencakup ApsaraMQ for Kafka, NATS Streaming, dan InMemoryChannel. Nilai default-nya adalah InMemoryChannel.
Broker — mengarahkan event dari berbagai sumber sesuai dengan Trigger yang dikonfigurasi. Mendukung backend seperti NATS dan ApsaraMQ for Kafka.
Trigger — menentukan cara event diarahkan ke Service tertentu. Setiap Trigger memiliki filter event dan target Service; hanya event yang cocok yang diteruskan.
Service — prosesor akhir yang menjalankan logika bisnis setelah menerima event dari Trigger.

Prasyarat

Sebelum memulai, pastikan Anda telah:

Menginstal Knative Serving. Lihat Deploy Knative.
Menginstal Knative Eventing. Lihat Deploy Knative Eventing.

Langkah 1: Deploy Knative Service

Deploy event-display, yaitu Knative Service yang menerima event dan mencetak isinya ke log. Setelah langkah ini, Anda akan memiliki Service yang sedang berjalan dan siap mengonsumsi event.

Buat file bernama event-display.yaml dengan konten berikut:

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

Deploy Service tersebut:
```
kubectl apply -f event-display.yaml
```

Verifikasi bahwa Service sudah siap:

kubectl get ksvc

Output yang diharapkan mirip dengan:

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

Nilai READY sebesar True menegaskan bahwa Service sedang berjalan dan siap menerima event. Jika Service tidak mencapai status Ready, jalankan perintah berikut untuk mendiagnosis:

kubectl describe ksvc event-display

Langkah 2: Buat Broker dan Trigger

Buat Broker bernama default dan Trigger bernama my-service-trigger. Setelah langkah ini, setiap event yang dikirim ke Broker akan secara otomatis diarahkan ke Service event-display.

Buat Broker

Buat file bernama broker.yaml dengan konten berikut:

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

Deploy Broker tersebut:
```
kubectl apply -f broker.yaml
```
Verifikasi bahwa Broker sudah siap:
```
kubectl get broker
```
Output yang diharapkan mirip dengan:
```
NAME      URL                                                                        AGE   READY   REASON
default   http://broker-ingress.knative-eventing.svc.cluster.local/default/default   9s    True
```
Bidang URL menunjukkan lokasi pengiriman event ke Broker ini. Nilai READY sebesar True menegaskan bahwa Broker telah dikonfigurasi dengan benar. Jika Broker tidak mencapai status Ready, jalankan perintah berikut untuk mendiagnosis:
```
kubectl describe broker default
```

Buat Trigger

Buat file bernama trigger.yaml dengan konten berikut:
```
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
```
Trigger ini tidak memiliki bidang filter, sehingga meneruskan semua event yang dikirim ke Broker default ke event-display. Menghilangkan filter berguna untuk pengujian dan debugging. Di lingkungan produksi, tambahkan filter untuk mengarahkan hanya jenis event tertentu.
Deploy Trigger tersebut:
```
kubectl apply -f trigger.yaml
```
Verifikasi bahwa Trigger sudah siap:
```
kubectl get trigger
```
Output yang diharapkan mirip dengan:
```
NAME                 BROKER    SUBSCRIBER_URI                                   AGE   READY   REASON
my-service-trigger   default   http://event-display.default.svc.cluster.local   22s   True
```
Nilai READY sebesar True menegaskan bahwa Trigger telah berlangganan dengan benar ke Broker dan akan meneruskan event ke event-display. Jika Trigger tidak mencapai status Ready, jalankan perintah berikut untuk mendiagnosis:
```
kubectl describe trigger my-service-trigger
```

Langkah 3: Kirim event dan verifikasi pengiriman

Kirim event uji ke Broker dan pastikan event-display menerimanya serta mencatatnya di log. Langkah ini menggunakan kubectl port-forward untuk mengekspos titik akhir internal Broker secara lokal, lalu mengirim permintaan HTTP POST berformat CloudEvents.

Teruskan port ingress Broker ke mesin lokal Anda:

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

Di terminal terpisah, kirim permintaan POST ke 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."}'

Tanggapan yang diharapkan diakhiri dengan:

< HTTP/1.1 202 Accepted

Tanggapan 202 Accepted menegaskan bahwa Broker telah menerima permintaan dan menerima event untuk diproses.

Dapatkan nama Pod event-display:

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

Output yang diharapkan mirip dengan:

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

Lihat log Pod untuk memastikan event telah dikirimkan:

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

Output yang diharapkan mirip dengan:

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."
  }

Log tersebut menegaskan bahwa event-display telah menerima CloudEvent dari Broker dan mencetak seluruh isinya, termasuk header CloudEvents dan muatan JSON.

Langkah selanjutnya

Tambahkan filter ke Trigger Anda untuk mengarahkan hanya jenis event tertentu. Lihat Trigger filtering.
Ganti InMemoryChannel dengan ApsaraMQ for Kafka atau NATS Streaming untuk persistensi event tingkat produksi.
Deploy Trigger tambahan untuk menyebarkan event ke beberapa Service sekaligus.