Knative Eventing 入門

Transcript

1. © 2021 NTT DATA Corporation Knative Eventing 入門 2021年6月22日 NTTデータ 北村 卓也
2. © 2021 NTT DATA Corporation 2 自己紹介 北村 卓也 (twitter:@ch03121) ・所属：NTTデータ ・仕事：BtoBなサービスのインフラ構築/運用 Kubernetesの勉強中 ・趣味：化石・鉱物採集 ↑岩手県で採集してきた水晶
3. © 2021 NTT DATA Corporation 3 アジェンダ 1. Knative Eventing 概要 2. Eventingのカスタムリソース紹介 3．BrokerとTriggerを活用したイベント配信例 4. まとめ
4. © 2021 NTT DATA Corporation 4 注意 ・掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を 代表するものではありません。 ・記載されている会社名、商品名、又はサービス名は、 各社の登録商標又は商標です。
5. © 2021 NTT DATA Corporation 5 Knative Eventing 概要
6. © 2021 NTT DATA Corporation 6 Knativeとは Kubernetesにけおけるサーバーレスアプリケーションのデプロイ・管理のプロセスを簡略化するOSS。 GCPのCloudRunの基盤にも活用されている。 <ユースケース>  サーバーレスアプリケーションを、異なるプラットフォーム(各種クラウド、オンプレミス)に同じ仕組みで動かしたい ・Knativeが動作するKubernetes上であれば、アプリケーションを改修せずに 異なるプラットフォームでデプロイ、動作可能 ・サーバーレスの欠点であるクラウドベンダへのロックインを回避できる  Kubernetes上でイベントドリブンなアプリケーションを実行したい ・イベントの検知や配信の仕組みはKnativeに任せられるので、アプリケーション側での実装が不要。 ・様々なイベントソース(AWS SQS、Apache Kafka、FTPアップロード等)が利用可能
7. © 2021 NTT DATA Corporation 7 Knativeとは  ServingとEventingという2つのコンポーネントで構成されている。 それぞれ個別にインストール、使用することが可能。 • Serving Kubernetes上へのコンテナデプロイを簡略化。 オートスケーリング(ゼロスケール可)、デプロイした構成のリビジョン管理などを実現。 • Eventing イベントを契機にkubernetes上で処理を実行できるようにしてくれる。 イベントソース(GithubWebhooks、Kafka等)とコンシューマ(Kubernetes、KnativeのService等)の 関連付けの抽象化を行う。 Kubernetes Novice Tokyo #9のセッション 「KnativeでKubernetesをラクにする」(@mochizuki875) をご覧ください！
8. © 2021 NTT DATA Corporation 8 Eventingとは イベントの検知、Kubernetes上のアプリケーションへの配信を行うコンポーネント ・Event Producerの違いをEventingが吸収してくれるので、アプリケーション側での個別実装が不要。 ・クラウドベンダのマネジメントサービスを使わずに、イベントドリブンな処理を実装できる(ベンダロックイン回避)。 Knative Eventing Event Producer Kubernetes上の アプリケーション (Service) イベント例) ・メッセージキュー(OSS、クラウド…)へのパブリッシュ ・KubernetesAPIserver ・FTPアップロード ・Githubへのプッシュ イベント検知/取得 イベント配信 CloudEvents仕様
9. © 2021 NTT DATA Corporation 9 (補足) 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/
10. © 2021 NTT DATA Corporation 10 (補足) 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
11. © 2021 NTT DATA Corporation 11 Eventingのカスタムリソース
12. © 2021 NTT DATA Corporation 12 Eventing カスタムリソース Event Producer Event consumer Source Trigger(1) Service (APP-2) Service (APP-1) Broker Trigger(2) Subscription(1) Subscription(2) Channel フィルタ 検知/取得 配信 配信 配信 Eventingをインストールすると、カスタムリソース定義が作成される。 それらカスタムリソースを使用することで、イベントドリブンな処理を実現できる。 フィルタ
13. © 2021 NTT DATA Corporation 13 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
14. © 2021 NTT DATA Corporation 14 例：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" }
15. © 2021 NTT DATA Corporation 15 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 プロダクション環境で使う場合は、これらを検討
16. © 2021 NTT DATA Corporation 16 Subscription ・Channelと配信先(subscriber)の紐づけを定義する。 配信のリトライ設定も可能。 ・右の例は、「eventinghello-ch」というchannelにあるイベントを 「eventinghello」というKnativeServiceに送るSubscription。 ・subscriberはchannelにすることもできるので、 以下のような複雑な制御も可能。 apiVersion: messaging.knative.dev/v1beta1 kind: Subscription metadata: name: eventinghelloa-sub spec: channel: apiVersion: messaging.knative.dev/v1beta1 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
17. © 2021 NTT DATA Corporation 17 例：Channel、Subscriptionを導入した場合 多数の配信先(subscriber)がイベントを受け取ることができる。 また、配信失敗時にイベントは消失せず、再配信が試行される。 Event Producer Event consumer Source Service (APP-2) Service (APP-1) Subscription(1) Subscription(2) Channel 検知/取得 配信 配信 配信 イベントをChannelに配信 イベントを保存した上で、 subscriptionに定義された subscriberへ配信
18. © 2021 NTT DATA Corporation 18 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"
19. © 2021 NTT DATA Corporation 19 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
20. © 2021 NTT DATA Corporation 20 Broker、TriggerとChannel、Subscriptionの関係 ・Brokerを作成すると、使用するChannelが自動作成される。 # kubectl get broker NAME URL AGE READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/default/default 6s True # kubectl get channel NAME URL AGE READY REASON 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が自動作成される。
21. © 2021 NTT DATA Corporation 21 例：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へ配信
22. © 2021 NTT DATA Corporation 22 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
23. © 2021 NTT DATA Corporation 23 カスタムリソース まとめ Event Producer Event consumer Source Trigger(1) Service (APP-2) Service (APP-1) Broker Trigger(2) Subscription(1) Subscription(2) Channel フィルタ 検知/取得 配信 配信 配信 以下のカスタムリソースを使用することで、イベントドリブンな処理を実現できる。 フィルタ
24. © 2021 NTT DATA Corporation 24 カスタムリソース まとめ 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つのイベントを複数の宛先に送信する ・リクエスト内容に応じた宛先に配信する
25. © 2021 NTT DATA Corporation 25 BrokerとTriggerを 活用したイベント配信例
26. © 2021 NTT DATA Corporation 26 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
27. © 2021 NTT DATA Corporation 27 BrokerとTriggerを活用したイベント配信例 配信先となる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
28. © 2021 NTT DATA Corporation 28 BrokerとTriggerを活用したイベント配信例 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 NAME URL AGE READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/default/default 4s True Brokerのエンドポイント。 ここにPOSTすればイベントをBrokerに登録できる。
29. © 2021 NTT DATA Corporation 29 BrokerとTriggerを活用したイベント配信例 「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 NAME BROKER SUBSCRIBER_URI AGE READY REASON aloha default http://eventingaloha.default.svc.cluster.local/ 14s True
30. © 2021 NTT DATA Corporation 30 BrokerとTriggerを活用したイベント配信例 「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 NAME BROKER SUBSCRIBER_URI AGE READY REASON bonjour default http://eventingbonjour.default.svc.cluster.local/ 6s True
31. © 2021 NTT DATA Corporation 31 BrokerとTriggerを活用したイベント配信例 BrokerとTriggerを作成したので、ChannelとSubscriptionが自動的に作成されている。 # kubectl get channel NAME URL AGE READY REASON 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
32. © 2021 NTT DATA Corporation 32 BrokerとTriggerを活用したイベント配信例 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
33. © 2021 NTT DATA Corporation 33 BrokerとTriggerを活用したイベント配信例 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したイベントが届いていることが確認できる。
34. © 2021 NTT DATA Corporation 34 BrokerとTriggerを活用したイベント配信例 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したイベントが届いていることが確認できる。
35. © 2021 NTT DATA Corporation 35 BrokerとTriggerを活用したイベント配信例 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
36. © 2021 NTT DATA Corporation 36 まとめ
37. © 2021 NTT DATA Corporation 37 まとめ ・Eventingはイベントの検知、CloudEventsへの変換、配信を行う。 アプリケーションはCloudEvents仕様のHTTPリクエストを受けるだけでよい。 ・Kubernetes上であれば、同じ仕組みでイベントドリブンな処理を実装できる。 これにより、サーバーレスアプリケーションのポータビリティが向上する。 ・Knativeの最新バージョンはv0.23で、まだ正式リリース(v1)には到達していない。 プロダクション環境へ導入するのであれば商用Knative製品(※)がよいと思う。 ※Google Cloud Run for Anthos、Red Hat Openshift Serverlessなど
38. © 2021 NTT DATA Corporation 38 まとめ ※触ってみるなら以下がおすすめ - 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との連携もカバー
39. © 2021 NTT DATA Corporation
40. © 2021 NTT DATA Corporation 40 (参考) CloudEvent traces トレース機能を有効化することで、Evetingコンポーネントの通信を可視化できる(Zipkin 、Jaegerに対応)。 以下はzipkinの表示例。 ※https://knative.dev/docs/eventing/accessing-traces/
41. © 2021 NTT DATA Corporation 41 (参考) CNCFによるサーバレスに関する調査結果 ※https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf
42. © 2021 NTT DATA Corporation 42 (参考) Source Knativeコミュニティで開発されているSourceが多数ある。自作することも可能。 ※ https://knative.dev/docs/eventing/sources/#knative-sources
43. © 2021 NTT DATA Corporation 43 (参考) 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 NAME SHORTNAMES APIGROUP NAMESPACED KIND 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 NAME SHORTNAMES APIGROUP NAMESPACED KIND brokers eventing.knative.dev true Broker eventtypes eventing.knative.dev true EventType triggers eventing.knative.dev true Trigger