私のLFXメンターシップ体験：クロスネームスペースイベントリンク機能 ¶

公開日： 2024-07-16 、修正日： 2024-07-26

私のLFXメンターシップ体験：クロスネームスペースイベントリンク機能¶

著者： Yijie Wang、LFX'24メンティー

Cross Namespace Event Links

過去3ヶ月間、私はLFXメンターシッププログラムに参加するという素晴らしい機会を得ました。私の特定のプロジェクトはCNCF - Knative Eventing：クロスネームスペースイベントリンクというタイトルで、提案された機能トラックはこちらです。期間が終了するので、私の旅路を振り返り、皆さんと共有したいと思います。

機能の説明¶

マルチテナントのシナリオでは、一部のユースケースで、イベントを送信するサービスとは異なる名前空間にブローカーとチャネルを分離する必要がある場合があります。この設定は、イベントを消費するチームがブローカーとチャネルが存在する名前空間にアクセスできる場合は機能しますが、常にそうとは限りません。この問題に対処するために、トリガーとサブスクリプション（イベントリンク）が、参照するブローカーまたはチャネルとは異なる名前空間に存在するという新しい機能が提案されました。LFXメンターシッププログラムは、この斬新で非常に要望の多かった機能を現実にする機会を与えてくれました。

具体的な実装として、アクセス許可を安全に管理するためにロールベースのアクセス制御（RBAC）を使用しました。特定のブローカー/チャネルをサブスクライブできるようにするための新しいRBAC動詞であるknsubscribeを作成しました。さらに、Subject Access Reviewsを使用して、承認されたユーザーのみがこれらのクロスネームスペースイベントリンクを作成および管理できるようにしました。

新しい変更に続いて、コントロールプレーンとデータプレーンを調整し、機能のスムーズな実行を可能にしました。機能が期待どおりに動作することを確認するためのユニットテストを作成し、リソース間のイベント配信を確認するためのE2Eテストを追加しました。すべての変更はフィーチャーフラグの背後に配置され、ユーザーがこの機能を必要に応じて有効/無効にできるようにしました。

クロスネームスペースイベントリンク機能の使用¶

この機能は、アルファ機能として1.15リリースで公開される予定であり、現在はInMemoryChannelおよびInMemoryChannelsを使用するMTChannelBasedBrokerでのみサポートされています。Knative Eventingでエンドユーザーがクロスネームスペース参照を使用する方法を以下に示します。

フィーチャーフラグの有効化¶

すべての実装は、フィーチャーフラグcross-namespace-event-linksの背後に配置されています。機能を有効にするには、dataスペックの下のconfig-features ConfigMapに追加し、フィーチャーフラグの値をenabledに設定します。たとえば、次のConfigMapエントリを追加することで機能を有効にできます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-features
  namespace: knative-eventing
  labels:
    eventing.knative.dev/release: devel
    knative.dev/config-propagation: original
    knative.dev/config-category: eventing
data:
  cross-namespace-event-links: enabled

ロールベースのアクセス制御（RBAC）の設定¶

RBACポリシーは、名前空間をまたいで対話するために異なるリソースに必要なアクセス許可を定義します。設定方法は次のとおりです。

サービスアカウントの作成またはユーザーの指定：イベントソースが存在する名前空間で、ターゲット名前空間のリソースへのアクセスに使用されるサービスアカウントを作成するか、ユーザーを指定します。

たとえば、サービスアカウントを作成するには

apiVersion: v1
kind: ServiceAccount
metadata:
  name: eventing-controller
  namespace: source-namespace

あるいは、必要な資格情報を持つユーザーを使用することもできます。権限の少ない別のユーザーにクラスタへの資格情報があるかどうかを確認し、そのユーザーへのRoleBindingを作成する方が簡単な場合があります。

ターゲット名前空間でのロールの作成：動詞knsubscribeを使用して、イベントソースがリソースと対話するために必要なアクセス許可を付与するロールを定義します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: broker-subscriber
rules:
- apiGroups:
   - eventing.knative.dev
  resources: 
   - brokers
  verbs: 
   - knsubscribe

ロールをサービスアカウントまたはユーザーにバインドする：ターゲット名前空間にロールバインディングを作成し、ロールをソース名前空間のサービスアカウントまたはユーザーにバインドします。

この例では、前に作成したサービスアカウントを使用します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eventing-controller-crossnamespace-subscriber
subjects:
- kind: ServiceAccount
  name: eventing-controller
  namespace: source-namespace
roleRef:
  kind: ClusterRole
  name: broker-subscriber
  apiGroup: rbac.authorization.k8s.io

クロスネームスペース参照の作成¶

RBACが構成されたので、名前空間をまたいでリソースを参照するイベントソースとシンクを作成できます。トリガーの別の名前空間でブローカーを参照する方法の例を以下に示します。

別の名前空間のブローカーをサブスクライブするトリガー：フィーチャーフラグが有効になっているため、ブローカーはトリガースペックのbrokerRefフィールドに、それ自身の独立した名前空間とともにを追加できます。

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: cross-namespace-trigger
  namespace: source-namespace
spec:
  brokerRef: 
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: target-broker
      namespace: target-namespace
  subscriber: 
      ref:
         apiVersion: serving.knative.dev/v1 
         kind: Service 
         name: my-service

クロスネームスペースイベントの検証¶

これらの手順に従うことで、Knative Eventingでクロスネームスペース参照を有効にし、必要なRBACアクセス許可を設定し、別の名前空間のブローカーを参照するトリガーを作成できます。この設定により、イベント駆動型アプリケーションの柔軟性が向上し、異なる名前空間間でイベントリンクが可能になります。

プログラムの経験¶

プログラムに応募する前に、最初に機能トラックドキュメントをざっと見たとき、ほとんど理解できなかったことを今でも覚えています。機能がほぼ完成した今、このメンターシップ体験は非常に洞察に満ちたものでした。

このプログラムの際立った側面の1つは、Knative Eventingコミュニティと交流する機会が豊富にあったことです。最初は、質問をすることが自分の経験不足をさらけ出すのではないかと躊躇していました。しかし、議論に参加するようになり、コミュニティメンバーがどれほど親切であるかに気づくにつれて、自信が深まりました。さらに、オープンソースの共同的な性質に対する理解を深めることができ、コミュニティの一員になれたことを嬉しく思います。

この経験には技術的な課題がないわけではありませんでした。大きな課題の1つは、この新機能を既存のインフラストラクチャに統合することであり、これにより予期せぬ問題が発生しました。たとえば、関数を変更するには、この関数を呼び出すコードのすべての部分が引き続き正しく動作することを確認する必要がありました。さらに、大規模なKnative Eventingコードベースをナビゲートすることは、最初は圧倒的でした。エンドツーエンド（e2e）テストの実行方法など、アーキテクチャ設計を理解するには時間がかかりましたが、問題解決スキルと技術知識を向上させる貴重な学習プロセスでした。

プログラムの終わりまでに、私は重要なマイルストーンを達成しました。 7つのissueを開き、11のPRをマージしました。ソフトウェアの経験が限られた状態でプログラムに参加した人にとって、これらの成果は特に意味のあるものです。

最後に¶

最後に、この機会を与えてくださり、この機能の実装を私に託してくださり、そしてこの旅路での指導とメンターシップに感謝の意を表します。 Calum MurrayとPierangelo Di Pilato。あなたの助けとサポートなしには、本当に不可能だったでしょう。

数年後には、自分が書いたコードの正確な行を覚えていないかもしれないが、ユニットテストが初めてパスしたときの爽快感や、この機能が段階的に実現していくのを見たときの満足感は、いつまでも覚えているだろう。この経験は私のキャリアの可能性を広げてくれ、今後もオープンソースコミュニティに貢献していきたいと思っています。