目次
編集 3.2Channels & Subscriptions
前文
一言、慎重に探索したほうがいいです。
今日は、Eventing に関するナレッジ ポイントを整理しました. この記事が、読者が Knative Eventing について予備的に理解するのに役立つことを願っています.
記事タグの色の説明:
- 黄：重要な見出し
- 赤: 結論を示すために使用
- 緑: 第 1 レベルの引数をマークするために使用されます
- 青: 二次引数をマークするために使用されます
1. 基本紹介
Kubernetes ユーザーが開発段階と展開段階でサービス間の疎結合を実現する場合、さまざまなイベント メカニズムを介してイベントを渡す必要があることがよくあります.クラウド ネイティブ メッセージ通信のニーズのほとんどを解決するために、Knative は Eventing コンポーネントを提供します.
特徴：
- サービス開発と展開の疎結合
- 各種イベント配信に対応
- イベント プロデューサーとイベント コンシューマーは互いに独立しています。
サービス間の相互運用性を確保する
サードパーティ サービスのドッキングをサポート イベント システム
2. コンポーネント
イベンティングは主に
- イベント ソース
- イベント処理（フロー）
- イベント コンシューマ
それは3つの部分で構成されています。
2.1 イベントソース (イベントソース)
ソースはイベントのソースであり、イベントが生成される場所と、イベントが対象のオブジェクトに配信される方法を定義する方法です
- イベント生成
- イベント配信
現在、次の 8 つのイベント ソースがサポートされています。
ApiserverSource : ApiserverSource は、Kubernetes リソースが作成または更新されるたびに新しいイベントを発生させます
GitHubSource : GitHubSource は、 GitHub が動作するときに新しいイベントを発生させます
GcpPubSubSource : GCP クラウド プラットフォームの Pub/Sub サービスが新しいイベントをトリガーします
AwsSqsSource : AWS クラウド プラットフォーム SQS サービスが新しいイベントをトリガーします
ContainerSource : ContainerSource は、イベントが生成されるコンテナをインスタンス化します
CronJobSource : CronJob を介してイベントを生成します
KafkaSource : Kafkaイベントを受け取り、新しいイベントをトリガーします
CamelSource : Camel 関連のコンポーネント イベントを受け取り、新しいイベントをトリガーします
2.2 イベント処理（フロー）
以前の Knative は、次のイベントの受信と処理をサポートしています。
受信：ダイレクトイベント受信
イベント ソースを介して単一のイベント コンシューマーに直接転送します。消費処理のための Knative Service または Kubernetes Service の直接呼び出しをサポートしています。このようなシナリオでは、呼び出されたサービスが利用できない場合、イベント ソースが再試行メカニズムを担当します。
転送: イベント チャネル (チャネル) とイベント サブスクリプション (サブスクリプション) を介してイベント処理を転送します。
この場合、チャネルを使用してイベントが失われたりバッファリングされたりしないようにすることができ、サブスクリプションを使用してイベントをサブスクライブし、複数のコンシューマーの処理要件を満たすことができます。
フィルタリング: ブローカーとトリガーによるイベント消費とフィルタリング メカニズムをサポートします。
2.3 イベント コンシューマ (イベント コンシューマ)
イベントをさまざまなタイプのサービスに送信して消費するという要件を満たすために、Knative Eventing は、複数の k8s リソースを介して 2 つの共通インターフェースを定義します。
- Addressable interface :イベントの送受信に使用できるHTTP 要求アドレスを提供し、status.address.hostname フィールドで定義されます。特殊なケースとして、Kubernetes Service オブジェクトは Addressable インターフェースも実装できます。
- Callable interface : HTTP 経由で配信されたイベントを受け取り、変換します。これらの返されたイベントは、外部イベント ソースからのイベントと同じ方法でさらに処理できます。
現在、Knative は、Knative Service または Kubernetes Service を介したイベントの消費をサポートしています。
また、イベント コンシューマの場合、どのイベントをコンシュームできるかを事前に知るにはどうすればよいでしょうか?
イベント ソースはチャネルに送信され、サービスはそれらを処理する準備ができていますが、現在、チャネルからサービスに送信されたイベントを取得する方法はありません。この目的のために、Knative はサブスクリプション機能を設計しました。サブスクリプションは、チャネルとサービスの間のリンクであり、以下に示すように、システム全体でイベントを管理する方法を Knative に指示します。
要約:
Knative のサービスは、イベントとリクエストがどのように取得されるかを気にしません。
- Ingress ゲートウェイからの HTTP リクエストを取得できます
- チャネルから送信されたイベントを取得できます
取得方法に関係なく、サービスは HTTP 要求のみを受け入れます。
これは、Knative における重要な分離方法です。
サブスクリプションやチャネルを作成したり、内部でサービスにイベントを送信したりするのではなく、コードがアーキテクチャに書き込まれるようにします。
3. 建築様式
次の 3 つのアーキテクチャ パターンがあります。
- ソースからサービスへ
- チャンネルとサブスクリプション
- ブローカーとトリガー
3.1 ソースからサービスへ
ソースから個々のサービス(Knative サービスまたはコア Kubernetes サービスを含むアドレス指定可能なエンドポイント) への直接配信。
この場合、宛先サービスが利用できない場合、ソースはイベントの再試行またはキューイングを担当します。
3.2チャンネルとサブスクリプション
Knative イベント システムは、チャネルとサブスクリプションを通じて、さまざまなバックエンド (インメモリ、Kafka、GCP PubSub など) に接続してイベントをソースできるチャネルを定義します。
各チャネルは、シンク サービスの形式で 1 人以上のサブスクライバーを持つことができます。
図に示すように、サブスクライバーはイベント メッセージを受信し、必要に応じて処理できます。チャネル内の各メッセージは CloudEvent としてフォーマットされ、さらに処理するためにチェーン内で他のサブスクライバーに送信されます。
チャネルおよびサブスクリプションの使用パターンでは、メッセージをフィルタリングできません。
3.3 ブローカーとトリガー
Broker は一連のイベントを提供します。これは属性を通じて選択できます。
イベントを受信し、1 つ以上の一致するトリガーによって定義されたサブスクライバーに転送します。
Trigger は、アドレス指定可能なオブジェクトに渡す必要があるイベント プロパティのフィルターを記述します。
トリガーは必要な数だけ作成できます。
3.4 その他
高レベルのイベント構造:
場合によっては、一連のコラボレーション機能を一緒に使用することが望ましい場合があります。これらのユース ケースには、Knative Eventing が 2 つの追加リソースを提供します。
- Sequence は、 機能の順序付きリストを定義する方法を提供します。
- Parallel は、 イベント ブランチのリストを定義する方法を提供します。
特に順序付きリストと分岐リストについては、後で記事を書きます
4. まとめ
Knative は Build を使用してクラウド ネイティブの「ソース コードからコンテナーまで」のイメージ ビルド機能を提供し、Serving を介してコンテナーをデプロイして共通のサービス モデルを提供し、Eventing を使用してグローバルなイベント サブスクリプション、配信、および管理機能を提供し、イベント ドリブンを実現します。これは、Knative によって提示された標準のサーバーレス オーケストレーション フレームワークです。
- ビルド イメージ ビルド
- サービング コンテナの展開
- イベンティング イベントのグローバル サブスクリプション、配信、管理