全部产品
Search
文档中心

Container Service for Kubernetes:Gunakan Knative Eventing untuk mengirim event pertama

更新时间:Jun 26, 2025

Knative Eventing menyediakan kemampuan event-driven yang kuat untuk aplikasi serverless melalui model Broker-Trigger. Komponen ini mendukung pengalihan dan penyaringan event serta dapat digunakan untuk mengatur alur event yang kompleks. Model Broker-Trigger sangat cocok untuk aplikasi yang merespons pemicu eksternal atau internal, seperti pengiriman notifikasi otomatis berdasarkan perilaku pengguna atau pemrosesan aliran data dari berbagai sumber. Topik ini menjelaskan cara membangun arsitektur event-driven sederhana menggunakan Knative Eventing, termasuk penyebaran layanan, mekanisme pengiriman pesan, dan verifikasi fitur.

Cara kerjanya

Knative Eventing menyediakan model event komprehensif yang berinteraksi dengan berbagai sistem event eksternal. Setelah event diterima, mereka dialihkan secara internal menggunakan standar Cloud Events dan diproses melalui model event-driven Broker-Trigger.

Seperti yang ditunjukkan pada gambar berikut, dalam arsitektur event-driven Knative, Broker bertindak sebagai perantara untuk transmisi pesan, sedangkan Trigger secara otomatis memulai alur kerja berdasarkan kondisi tertentu. Prinsip model event-driven Broker-Trigger adalah memiliki Trigger berlangganan dan menyaring event dari Broker, lalu mengirimkan event ke layanan terkait untuk dikonsumsi.

  1. Sumber Event: Asal mula event, yang bisa berasal dari sistem internal seperti pembaruan database, atau layanan eksternal seperti layanan pesan cloud.

  2. Ingress: Menerima event eksternal ke dalam kluster Knative.

  3. Saluran: Dalam Knative Eventing, model Broker-Trigger memerlukan pemilihan saluran yang sesuai untuk meneruskan event. Saluran pengalihan event yang didukung mencakup ApsaraMQ for Kafka, NATS Streaming, dan InMemoryChannel. Saluran default adalah InMemoryChannel.

  4. Broker: Bertindak sebagai perantara event, mengarahkan event dari berbagai sumber sesuai dengan konfigurasi Trigger. Broker dapat mengimplementasikan alur event dan logika pemrosesan yang kompleks, mendukung berbagai protokol dan layanan event backend seperti NATS dan ApsaraMQ for Kafka, sehingga manajemen dan distribusi event menjadi lebih fleksibel dan efisien.

  5. Trigger: Menentukan bagaimana event dirutekan ke layanan tertentu. Setiap Trigger terkait dengan filter event, biasanya berdasarkan tipe atau konten event, serta target Layanan. Hanya event yang sesuai dengan kriteria filter yang dikirim ke Layanan yang ditentukan.

  6. Layanan: Prosesor akhir dari event. Setelah menerima event yang dirutekan oleh Trigger, ia mengeksekusi logika bisnis yang sesuai.

Prasyarat

Knative Serving dan Knative Eventing telah diinstal. Untuk informasi lebih lanjut, lihat Deploy and manage Knative dan Deploy Knative Eventing.

Berikut ini menjelaskan proses membangun sistem event-driven dasar menggunakan framework Knative Eventing, termasuk pembuatan, transmisi, dan konsumsi event.

Langkah 1: Deploy Layanan Knative

Bagian ini menggunakan event-display sebagai contoh Layanan Knative. Tanggung jawab utama event-display adalah menerima event dan mencetak isinya.

  1. Gunakan template YAML berikut untuk membuat Layanan Knative:

    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
  2. Deploy Layanan Knative.

    kubectl apply -f event-display.yaml
  3. Verifikasi apakah Layanan Knative telah dibuat.

    kubectl get ksvc

    Output yang diharapkan:

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

Langkah 2: Buat Broker dan Trigger

Buat Broker bernama default dan Trigger bernama my-service-trigger. Trigger memastikan bahwa event yang tidak ditangani secara eksplisit dirutekan ke Layanan event-display yang dideploy di Langkah 1.

  1. Buat Broker.

    1. Gunakan template YAML berikut untuk membuat Broker:

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

      kubectl  apply -f broker.yaml
    3. Verifikasi apakah Broker telah dibuat.

      kubectl  get broker

      Output yang diharapkan:

      NAME      URL                                                                        AGE   READY   REASON
      default   http://broker-ingress.knative-eventing.svc.cluster.local/default/default   9s    True    

      Output menampilkan informasi dan URL Broker. URL menunjukkan ke mana event harus dikirim.

  2. Buat Trigger.

    1. Buat Trigger dengan kode sampel di bawah ini.

      Berlangganan ke Broker default untuk merutekan event ke Layanan event-display.

      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

      my-service-trigger yang dibuat oleh template YAML sebelumnya terhubung ke default Broker dan menentukan event-display Service sebagai subscriber. Ini berarti bahwa semua event yang dikirim ke default Broker, asalkan tidak ada Trigger lain yang ditentukan untuk menanganinya, akan diteruskan ke event-display Service.

    2. Deploy Trigger.

      kubectl apply -f trigger.yaml
    3. Verifikasi apakah Trigger telah dibuat.

      kubectl  get trigger

      Output yang diharapkan:

      NAME                 BROKER    SUBSCRIBER_URI                                   AGE   READY   REASON
      my-service-trigger   default   http://event-display.default.svc.cluster.local   22s   True    

      Output menunjukkan bahwa Trigger siap, yang berarti bahwa Trigger telah dikonfigurasi dengan benar dan dapat menerima serta merutekan event.

Langkah 3: Kirim event dan verifikasi apakah Layanan dapat menerima event

Simulasikan pemicu event dengan mengirim permintaan HTTP POST langsung ke Broker dari sumber eksternal. Gunakan perintah curl untuk mengirim permintaan dengan header CloudEvents tertentu ke Broker, dan verifikasi apakah Layanan event-display menerima pesan ini dan mencetaknya sesuai harapan.

  1. Ambil alamat permintaan event dari Broker menggunakan broker-ingress.knative-eventing. Dengan mengirim permintaan event ke Broker, pastikan bahwa Layanan Broker dalam sistem Knative Eventing dikonfigurasi dengan benar dan dapat menerima event.

    1. Gunakan fungsi port-forward dari kubectl untuk meneruskan port Layanan internal dalam kluster ke mesin lokal, memungkinkan akses ke Layanan tersebut.

       kubectl port-forward svc/broker-ingress -n knative-eventing 8080:80
    2. Gunakan perintah curl untuk mengirim permintaan POST ke port lokal 8080 untuk memverifikasi bahwa Layanan dapat menerima dan memproses permintaan dengan benar.

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

      Output yang diharapkan:

      Catatan: Penggunaan -X atau --request tidak diperlukan, POST sudah disimpulkan.
      *   Mencoba 127.0.0.1:8080...
      * Terhubung ke localhost (127.0.0.1) port 8080 (#0)
      > POST /default/default HTTP/1.1
      > Host: localhost:8080
      > User-Agent: curl/8.1.2
      > Accept: */*
      > Ce-Id: 53****3-88be-4077-9d7a-a3f162******9
      > Ce-Specversion: 1.0
      > Ce-Type: dev.knative.samples.helloworld
      > Ce-Source: dev.knative.samples/helloworldsource
      > Content-Type: application/json
      > Content-Length: 40
      > 
      < HTTP/1.1 202 Accepted
      < Allow: POST, OPTIONS
      < Date: Tue, 15 Oct 2024 09:36:42 GMT
      < Content-Length: 0
      < 
      * Koneksi #0 ke host localhost ditinggalkan utuh

      Output yang diharapkan mengonfirmasi bahwa Layanan telah menerima permintaan POST yang dikirim ke http://localhost:8080/default/default dan telah mengembalikan status kode 202 Accepted, yang menunjukkan bahwa permintaan telah diterima.

  2. Periksa log pod event-display untuk mengonfirmasi sumber event.

    1. Ambil detail tentang pod event-display dan lihat log-nya.

      kubectl get pods --namespace=default | grep event-display
      # Outputnya adalah sebagai berikut:
      event-display-00001-deployment-766f7b9fd6-gfcz5   2/2     Running   0          3m43s
    2. Lihat log.

      kubectl logs event-display-00001-deployment-766f7b9fd6-gfcz5 
      # Output log adalah sebagai berikut:
      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."
        }

      Output yang diharapkan menunjukkan bahwa aplikasi yang berjalan di Kubernetes menerima event CloudEvents dari sumber Hello World Sampel Knative, dan mencetak isi dari event tersebut.