Knative Eventing 入門（Kubernetes Novice Tokyo #11 発表資料）

© 2021 NTT DATA Corporation
Knative Eventing 入門
2021年6月22日
NTTデータ
北村卓也

© 2021 NTT DATA Corporation 2
自己紹介
北村卓也 (twitter:@ch03121)
・所属：NTTデータ
・仕事：BtoBなサービスのインフラ構築/運用
Kubernetesの勉強中
・趣味：化石・鉱物採集
↑岩手県で採集してきた水晶

アジェンダ
1. Knative Eventing 概要
2. Eventingのカスタムリソース紹介
3．BrokerとTriggerを活用したイベント配信例
4. まとめ

注意
・掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を
代表するものではありません。
・記載されている会社名、商品名、又はサービス名は、
各社の登録商標又は商標です。

Knative Eventing 概要

Knativeとは
Kubernetesにけおけるサーバーレスアプリケーションのデプロイ・管理のプロセスを簡略化するOSS。
GCPのCloudRunの基盤にも活用されている。
<ユースケース>
 サーバーレスアプリケーションを、異なるプラットフォーム(各種クラウド、オンプレミス)に同じ仕組みで動かしたい
・Knativeが動作するKubernetes上であれば、アプリケーションを改修せずに
異なるプラットフォームでデプロイ、動作可能
・サーバーレスの欠点であるクラウドベンダへのロックインを回避できる
 Kubernetes上でイベントドリブンなアプリケーションを実行したい
・イベントの検知や配信の仕組みはKnativeに任せられるので、アプリケーション側での実装が不要。
・様々なイベントソース(AWS SQS、Apache Kafka、FTPアップロード等)が利用可能

Knativeとは
 ServingとEventingという2つのコンポーネントで構成されている。
それぞれ個別にインストール、使用することが可能。
• Serving
Kubernetes上へのコンテナデプロイを簡略化。
オートスケーリング(ゼロスケール可)、デプロイした構成のリビジョン管理などを実現。
• Eventing
イベントを契機にkubernetes上で処理を実行できるようにしてくれる。
イベントソース(GithubWebhooks、Kafka等)とコンシューマ(Kubernetes、KnativeのService等)の
関連付けの抽象化を行う。
Kubernetes Novice Tokyo #9のセッション
「KnativeでKubernetesをラクにする」(@mochizuki875)
をご覧ください！

Eventingとは
イベントの検知、Kubernetes上のアプリケーションへの配信を行うコンポーネント
・Event Producerの違いをEventingが吸収してくれるので、アプリケーション側での個別実装が不要。
・クラウドベンダのマネジメントサービスを使わずに、イベントドリブンな処理を実装できる(ベンダロックイン回避)。
Knative
Eventing
Event Producer
Kubernetes上の
アプリケーション
(Service)
イベント例)
・メッセージキュー(OSS、クラウド…)へのパブリッシュ
・KubernetesAPIserver
・FTPアップロード
・Githubへのプッシュ
イベント検知/取得イベント配信
CloudEvents仕様

(補足) CloudEvents
 イベントデータを記述するための共通仕様。
Cloud Native Computing Foundation(CNCF)が推進。
2019年にversio1.0に到達。
 クラウド内でのイベント記述仕様はクラウドベンダ毎に異なる。
マルチクラウド構成の場合、クラウド間でのイベントのやり取りも想定される。
→イベントの記述仕様を標準化して、クラウド間連携の運用性を高める。
 CloudEvents仕様を採用しているサービス、OSS
・Google Cloud Eventarc ・Azure Event Grid
・Alibaba Cloud EventBridge ・Vmware Event Broker Appliance
・Knative ・OpenFaaS
etc…
※ https://cloudevents.io/

(補足) CloudEvents
 CloudEvents仕様に必須の属性は以下。
これらをHTTPリクエストのヘッダに入れる必要がある。
・ce-specversion：CloudEventsのバージョン。
・ce-type：イベントタイプ。ルーティングやモニタリング、
ポリシー適用などに使われる属性。
・ce-source：イベントの発生元。
・ce-id：プロデューサーの範囲内で一意であるID。
POST /event HTTP/1.0
Host: example.com
Content-Type: application/json
ce-specversion: 1.0
ce-type: repo.newItem
ce-source: http://bigco.com/repo
ce-id: 610b6dd4-c85d-417b-b58f-3771e532
{
"action": "newItem",
"itemID": "93"
}
↓CloudEventsに準拠したHTTPリクエストの例
※https://github.com/cloudevents/spec

Eventingのカスタムリソース

Eventing カスタムリソース
Event
Producer
Event
consumer
Source
Trigger(1)
Service
(APP-2)
Service
(APP-1)
Broker
Trigger(2)
Subscription(1)
Subscription(2)
Channel
フィルタ
検知/取得配信
配信
配信
Eventingをインストールすると、カスタムリソース定義が作成される。
それらカスタムリソースを使用することで、イベントドリブンな処理を実現できる。
フィルタ

Source
・イベントを検知し、Sink(配信先)に配信するリソース。配信する際は、CloudEvents仕様に変換を行う。
・Producer(イベント発生元)に対応する様々なリソースが存在し、
Event Producerに応じて選択、作成する。
例)
APIServerSource：K8sのリソース操作を検知してイベント発行
KafkaSource：ApacheKafkaのメッセージを検知してイベント発行
PingSource：定期的にイベントを生成する
AwsSqsSource：AWS SQSのメッセージを検知してイベント発行
・右の例は、「my-cluster-kafka-bootstrap.kafka:9092」
というApache Kafkaの「my-topic」にメッセージが登録されたら、
「event-display」Serviceに配信するKafkaSource。
apiVersion: sources.knative.dev/v1beta1
kind: KafkaSource
metadata:
name: kafka-source
spec:
consumerGroup: knative-group
bootstrapServers:
- my-cluster-kafka-bootstrap.kafka:9092
topics:
- my-topic
sink:
ref:
apiVersion: v1
kind: Service
name: event-display

例：Sourceのみ使用する場合
Event
consumer
Service
(APP-2)
Event
Producer
Service
(APP-1)
Source
検知/取得
Sourceが指定できる配信先(sink)は1つだけ。また、配信失敗時はイベントが消失する。
イベントの発生を検知して
イベント内容をCloudEvents仕様の
HTTPリクエストに変換して、配信する
配信
POST /event HTTP/1.0
Host: example.com
Content-Type: application/json
ce-specversion: 1.0
ce-type: repo.newItem
ce-source: http://bigco.com/repo
ce-id: 610b6dd4-c85d-417b-b58f-3771e532
{
"action": "newItem",
"itemID": "93"
}

Channel
・イベントの保存と、配信を行う。以下から選択して実装する。
・In-Memory Channel →シンプルでインストールも楽だが、永続性はないので、開発用
・Apache Kafka Channel
・NATS Channel
・Google Cloud Pub/Sub Channel
※作成例
# cat channel.yaml
apiVersion: messaging.knative.dev/v1beta1
kind: InMemoryChannel
metadata:
name: channel
# kubectl apply -f channel.yaml
inmemorychannel.messaging.knative.dev/channel created
# kubectl get channel
NAME URL AGE READY REASON
inmemorychannel.messaging.knative.dev/channel http://channel-kn-channel.default.svc.cluster.local 2m4s True
プロダクション環境で使う場合は、これらを検討

Subscription
・Channelと配信先(subscriber)の紐づけを定義する。
配信のリトライ設定も可能。
・右の例は、「eventinghello-ch」というchannelにあるイベントを
「eventinghello」というKnativeServiceに送るSubscription。
・subscriberはchannelにすることもできるので、
以下のような複雑な制御も可能。
kind: Subscription
metadata:
name: eventinghelloa-sub
spec:
channel:
kind: Channel
name: eventinghello-ch
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: eventinghello
※https://medium.com/google-cloud/knative-eventing-delivery-methods-79d4ebe30a68

例：Channel、Subscriptionを導入した場合
多数の配信先(subscriber)がイベントを受け取ることができる。
また、配信失敗時にイベントは消失せず、再配信が試行される。
Event
Producer
Event
consumer
Source
Service
(APP-2)
Service
(APP-1)
Subscription(1)
Subscription(2)
Channel
検知/取得配信
配信
配信
イベントをChannelに配信
イベントを保存した上で、
subscriptionに定義された
subscriberへ配信

Broker
・イベントを保存した上で
Triggerによって定義されたフィルタリングを行い、
配信するリソース。
・基本的な実装であるMT-Channel-based Brokerは
内部的にChannelを利用するので、
Channelと同様、実装をin-memory、Kafka等から選択して
「config-br-defaults」Configmapに設定しておく必要がある。
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
name: default
namespace: default
annotations:
eventing.knative.dev/broker.class: MTChannelBasedBroker
spec:
config:
apiVersion: v1
kind: ConfigMap
name: config-br-default-channel
namespace: knative-eventing
delivery:
deadLetterSink:
ref:
kind: Service
namespace: example-namespace
name: example-service
apiVersion: v1
uri: example-uri
retry: 5
backoffPolicy: exponential
backoffDelay: "2007-03-01T13:00:00Z/P1Y2M10DT2H30M"

Trigger
・Brokerでのフィルタリングと配信先を定義するリソース。
HTTPヘッダ(CloudEvents属性/拡張属性)での完全一致フィルタリングをサポートしている。
・右の例は、「default」brokerにある、
typeが「dev.knative.foo.bar」かつmyextensionが
「my-extension-value」のイベントのみ、
「my-service」Serviceに配信する場合。
・filterはAND条件なので、OR条件を使いたい場合は、
Triggerが複数必要。
・subscriberは複数定義できないので、同じフィルタ条件で
複数のsubscriberに配信したい場合は、Triggerが複数必要。
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
name: my-service-trigger
spec:
broker: default
filter:
attributes:
type: dev.knative.foo.bar
myextension: my-extension-value
subscriber:
ref:
apiVersion: v1
kind: Service
name: my-service

Broker、TriggerとChannel、Subscriptionの関係
・Brokerを作成すると、使用するChannelが自動作成される。
# kubectl get broker
default http://broker-ingress.knative-eventing.svc.cluster.local/default/default 6s True
inmemorychannel.messaging.knative.dev/default-kne-trigger http://default-kne-trigger-kn-channel.default.svc.cluster.local
6m55s True
# kubectl get trigger
NAME BROKER SUBSCRIBER_URI AGE READY REASON
trigger1 default http://service1.default.svc.cluster.local 8s True
# kubectl get subscription
NAME AGE READY REASON
default-trigger1-50178dee-e2ed-4ed7-b77e-21752093d629 14s True
・Triggerを作成すると、必要なSubscriptionが自動作成される。

例：Broker、Triggerを導入した場合
イベントを、その属性に応じてフィルタリングし、適切なsubscriberへ配信できる。
イベントはChannelに保存されているため、配信失敗時にイベントは消失せず、再配信が試行される。
Event
Producer
Event
consumer
Source
Trigger(1)
Service
(APP-2)
Service
(APP-1)
Broker
Trigger(2)
Subscription(1)
Subscription(2)
Channel
フィルタ
検知/取得配信
配信
配信
フィルタ
イベントをBrokerに配信
Channelにイベントを保存した上で、
Triggerに定義された条件に従って
subscriberへ配信

Broker、Trigger導入のメリット
・複雑なイベント配信を行う場合、Broker、Triggerを使うことでリソースの作成、管理が簡単になる。
※https://github.com/meteatamel/knative-tutorial/blob/master/docs/complexdeliverywithreply.md
※https://github.com/meteatamel/knative-tutorial/blob/master/docs/brokertrigger.md
■Brokerを使わない場合
Sourceからのイベント配信用と、Service2からService3への
連携用の2つのchannelが必要になる。
また、Subscriptionもユーザ側で作成することになる。
→管理が大変
■Brokerを使う場合
Triggerの設定によって、1つのBrokerで様々な配信を行える。
Subscriptionも自動で作成してくれる。
→Triggerを管理するだけでOK

カスタムリソースまとめ
Event
Producer
Event
consumer
Source
Trigger(1)
Service
(APP-2)
Service
(APP-1)
Broker
Trigger(2)
Subscription(1)
Subscription(2)
Channel
フィルタ
検知/取得配信
配信
配信
以下のカスタムリソースを使用することで、イベントドリブンな処理を実現できる。
フィルタ

カスタムリソースまとめ
Event
Producer
Event
consumer
Source
Trigger(1)
Service
(APP-2)
Service
(APP-1)
Broker
Trigger(2)
Subscription(1)
Subscription(2)
Channel
フィルタ
検知/取得配信
配信
配信
以下のカスタムリソースを使用することで、イベントドリブンな処理を実現できる。
フィルタ
イベントを検知して、
CloudEvents形式の
HTTPリクエスト
に変換する
CloudEvents形式のリクエストを
アプリケーションに配信する
・1つのイベントを複数の宛先に送信する
・リクエスト内容に応じた宛先に配信する

BrokerとTriggerを
活用したイベント配信例

BrokerとTriggerを活用したイベント配信例
Brokerにce-typeの異なるイベントを送信し、Triggerの設定に従って配信先が振り分けられることを確認する。
・「ce-type:aloha」のイベント→「eventingaloha」Serviceに配信
・「ce-type:bonjour」のイベント→「eventingbonjour」Serviceに配信
※Sourceの代わりにcurlを使って、手動でイベントをBrokerに配信している。
curlコマンド
Trigger
(aloha)
Service
(eventingaloha)
Broker
Trigger
(bonjour)
Subscription
Subscription
Channel
フィルタ
配信
配信
配信
フィルタ
①Broker宛てに、CloudEvents仕様で
HTTPリクエストを送信
Service
(eventingbonjour)
②ce-typeの値に応じて、
適切なServiceにイベントを配信
※https://redhat-developer-demos.github.io/knative-tutorial/knative-tutorial/index.html
③受け取ったイベントを確認
※受け取ったイベントを出力するだけのAP

配信先となるPodを作成し、ClusterIPで公開する。
# kubectl get service eventingaloha
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
eventingaloha ClusterIP 10.104.233.136 <none> 80/TCP 5m17s
# kubectl get service eventingbonjour
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
eventingbonjour ClusterIP 10.99.168.47 <none> 80/TCP 5m21
# kubectl get pod
NAME READY STATUS RESTARTS AGE
eventingaloha-v1-deployment-794c9dcdcd-sh5c2 1/1 Running 0 6m1s
eventingbonjour-v1-deployment-7ccf8f4f74-jsqfq 1/1 Running 0 6m1s

Brokerを作成する。
※sugar-controllerというKnativeの拡張機能により、「eventing.knative.dev/injection=enabled」という
labelを付けたnamespaceにBrokerが自動作成される。
# kubectl label namespace default eventing.knative.dev/injection=enabled
namespace/default labeled
# kubectl get broker
default http://broker-ingress.knative-eventing.svc.cluster.local/default/default 4s True
Brokerのエンドポイント。
ここにPOSTすればイベントをBrokerに登録できる。

「ce-type:aloha」のイベントを「eventingaloha」Serviceに配信するTriggerを作成
# cat trigger-aloha.yaml
apiVersion: eventing.knative.dev/v1beta1
kind: Trigger
metadata:
name: aloha
spec:
filter:
attributes:
type: aloha
subscriber:
ref:
apiVersion: v1
kind: Service
name: eventingaloha
# kubectl apply -f trigger-aloha.yaml
trigger.eventing.knative.dev/aloha created
# kubectl get trigger aloha
aloha default http://eventingaloha.default.svc.cluster.local/ 14s True

「ce-type:bonjour」のイベントを「eventingbonjour」Serviceに配信するTriggerを作成
# cat trigger-bonjour.yaml
apiVersion: eventing.knative.dev/v1beta1
kind: Trigger
metadata:
name: bonjour
spec:
filter:
attributes:
type: bonjour
subscriber:
ref:
apiVersion: v1
kind: Service
name: eventingbonjour
# kubectl apply -f trigger-bonjour.yaml
trigger.eventing.knative.dev/bonjour created
# kubectl get trigger bonjour
bonjour default http://eventingbonjour.default.svc.cluster.local/ 6s True

BrokerとTriggerを作成したので、ChannelとSubscriptionが自動的に作成されている。
inmemorychannel.messaging.knative.dev/default-kne-trigger http://default-kne-trigger-kn-channel.default.svc.cluster.local 3m51s True
# kubectl get subscription
NAME AGE READY REASON
default-aloha-ab84b7e5-a363-43fb-90c8-e2e5c5fcd926 4m32s True
default-bonjour-9c99f6e7-b97e-4909-a519-7c9c00b2f24f 101s True

Brokerへイベントを登録するためのPodを起動してログインする。
# cat curler.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
run: curler
name: curler
spec:
containers:
- name: curler
image: fedora:29
tty: true
# kubectl apply -f curler.yaml
pod/curler created
# kubectl exec -it curler -- /bin/bash

type:alohaのイベントをBrokerに対しHTTP POSTすると、 eventingalohaのみにイベントが届く。
[root@curler /]# curl -v "http://broker-ingress.knative-eventing.svc.cluster.local/default/default"
-X POST
-H "Ce-Id: say-hello"
-H "Ce-Specversion: 1.0"
-H "Ce-Type: aloha"
-H "Ce-Source: mycurl"
-H "Content-Type: application/json"
-d '{"key":"from a curl"}'
# kubectl logs eventingaloha-v1-deployment-794c9dcdcd-sh5c2 -f
2021-06-06 11:09:17,838 INFO [eventing-hello] (executor-thread-1) ce-id=say-hello
2021-06-06 11:09:17,840 INFO [eventing-hello] (executor-thread-1) ce-source=mycurl
2021-06-06 11:09:17,840 INFO [eventing-hello] (executor-thread-1) ce-specversion=1.0
2021-06-06 11:09:17,841 INFO [eventing-hello] (executor-thread-1) ce-time=null
2021-06-06 11:09:17,841 INFO [eventing-hello] (executor-thread-1) ce-type=aloha
2021-06-06 11:09:17,842 INFO [eventing-hello] (executor-thread-1) content-type=application/json
2021-06-06 11:09:17,843 INFO [eventing-hello] (executor-thread-1) content-length=21
2021-06-06 11:09:17,843 INFO [eventing-hello] (executor-thread-1) POST:{"key":"from a curl"}
Eventingaloha Podのログを確認すると、POSTしたイベントが届いていることが確認できる。

type:bonjourのイベントをBrokerに対しHTTP POSTすると、 eventingbonjourのみにイベントが届く。
[root@curler /]# curl -v "http://broker-ingress.knative-eventing.svc.cluster.local/default/default"
-X POST
-H "Ce-Id: say-hello"
-H "Ce-Specversion: 1.0"
-H "Ce-Type: bonjour"
-H "Ce-Source: mycurl"
-H "Content-Type: application/json"
-d '{"key":"from a curl"}'
# kubectl logs eventingbonjour-v1-deployment-7ccf8f4f74-jsqfq –f
2021-06-06 11:12:46,406 INFO [eventing-hello] (executor-thread-1) ce-id=say-hello
2021-06-06 11:12:46,406 INFO [eventing-hello] (executor-thread-1) ce-source=mycurl
2021-06-06 11:12:46,407 INFO [eventing-hello] (executor-thread-1) ce-specversion=1.0
2021-06-06 11:12:46,408 INFO [eventing-hello] (executor-thread-1) ce-time=null
2021-06-06 11:12:46,408 INFO [eventing-hello] (executor-thread-1) ce-type=bonjour
2021-06-06 11:12:46,409 INFO [eventing-hello] (executor-thread-1) content-type=application/json
2021-06-06 11:12:46,409 INFO [eventing-hello] (executor-thread-1) content-length=21
2021-06-06 11:12:46,409 INFO [eventing-hello] (executor-thread-1) POST:{"key":"from a curl"}
Eventing bonjour Podのログを確認すると、POSTしたイベントが届いていることが確認できる。

ChannelやBrokerの実体はknative-eventing namespaceにあるPodなので、
これらのPodログを確認すると、配信の状況や配信先が分かる。
※Channelについてはimc-dispatcher、
Brokerはmt-broker-ingress、mt-broker-filterを見る。
# kubectl get pod -n knative-eventing
NAME READY STATUS RESTARTS AGE
eventing-controller-bc75b6c59-f876r 1/1 Running 0 19d
eventing-webhook-ff58dfd96-lxvjf 1/1 Running 0 19d
imc-controller-5676bcf5b7-lhhrv 1/1 Running 0 19d
imc-dispatcher-88b5494f6-748t2 1/1 Running 0 19d
mt-broker-controller-bbb65f58f-g2k5x 1/1 Running 0 19d
mt-broker-filter-5c79bbf754-xz26t 1/1 Running 0 19d
mt-broker-ingress-dc4b5d9d9-22nrl 1/1 Running 0 19d
pingsource-mt-adapter-75754554d-9hdxc 1/1 Running 0 19d
sugar-controller-7cc844bff6-5ltd6 1/1 Running 0 19d

まとめ

まとめ
・Eventingはイベントの検知、CloudEventsへの変換、配信を行う。
アプリケーションはCloudEvents仕様のHTTPリクエストを受けるだけでよい。
・Kubernetes上であれば、同じ仕組みでイベントドリブンな処理を実装できる。
これにより、サーバーレスアプリケーションのポータビリティが向上する。
・Knativeの最新バージョンはv0.23で、まだ正式リリース(v1)には到達していない。
プロダクション環境へ導入するのであれば商用Knative製品(※)がよいと思う。
※Google Cloud Run for Anthos、Red Hat Openshift Serverlessなど

まとめ
※触ってみるなら以下がおすすめ
- Googleの方が公開しているチュートリアル(https://github.com/meteatamel/knative-tutorial)
→最新バージョン(v0.23)まで対応している
- Redhatのチュートリアル(https://redhat-developer-demos.github.io/knative-tutorial/knative-tutorial/index.html)
→少しバージョンが古い(v0.19)が、Apache Kafkaとの連携もカバー

(参考) CloudEvent traces
トレース機能を有効化することで、Evetingコンポーネントの通信を可視化できる(Zipkin 、Jaegerに対応)。
以下はzipkinの表示例。
※https://knative.dev/docs/eventing/accessing-traces/

(参考) CNCFによるサーバレスに関する調査結果
※https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf

(参考) Source
Knativeコミュニティで開発されているSourceが多数ある。自作することも可能。
※ https://knative.dev/docs/eventing/sources/#knative-sources

(参考) Eventing カスタムリソース
Eventingをインストールすると、以下のCRD(カスタムリソース定義)が作成される。
# kubectl api-resources --api-group=sources.knative.dev
NAME SHORTNAMES APIGROUP NAMESPACED KIND
apiserversources sources.knative.dev true ApiServerSource
containersources sources.knative.dev true ContainerSource
pingsources sources.knative.dev true PingSource
sinkbindings sources.knative.dev true SinkBinding
# kubectl api-resources --api-group=messaging.knative.dev
channels ch messaging.knative.dev true Channel
inmemorychannels imc messaging.knative.dev true InMemoryChannel
subscriptions sub messaging.knative.dev true Subscription
# kubectl api-resources --api-group=eventing.knative.dev
brokers eventing.knative.dev true Broker
eventtypes eventing.knative.dev true EventType
triggers eventing.knative.dev true Trigger

Knative Eventing 入門（Kubernetes Novice Tokyo #11 発表資料）

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Knative Eventing 入門（Kubernetes Novice Tokyo #11 発表資料）

Similaire à Knative Eventing 入門（Kubernetes Novice Tokyo #11 発表資料） (20)

Plus de NTT DATA Technology & Innovation

Plus de NTT DATA Technology & Innovation (20)

Dernier

Dernier (6)

Knative Eventing 入門（Kubernetes Novice Tokyo #11 発表資料）