我的 LFX 指導經驗：跨命名空間事件連結功能 ¶

發布於：2024-07-16，修訂於：2024-07-26

我的 LFX 指導經驗：跨命名空間事件連結功能¶

作者：Yijie Wang，LFX'24 指導學員

Cross Namespace Event Links

在過去的三個月中，我有幸參與了 LFX 指導計畫。我的具體專案名稱為 CNCF - Knative Eventing：跨命名空間事件連結，我提出的功能追蹤在此。隨著學期即將結束，我想花點時間回顧我的旅程並與您分享。

功能描述¶

在多租戶情境中，某些用例可能需要在與其傳送事件的服務不同的命名空間中分隔 Broker 和通道。雖然如果使用事件的團隊可以存取 Broker 和通道所在的命名空間，此設定應該可以運作，但情況並非總是如此。為了解決這個問題，針對觸發器和訂閱（事件連結）提出了一項新功能，使其可以存在於與其參考的 Broker 或通道不同的命名空間中。LFX 指導計畫讓我能將這個新穎且備受要求的功能實現。

對於具體的實作，我使用基於角色的存取控制 (RBAC) 來安全地管理權限。建立了一個新的 RBAC 動詞 knsubscribe，以允許使用者訂閱特定的 Broker/通道。此外，我使用主體存取審查來確保只有經過授權的使用者才能建立和管理這些跨命名空間的事件連結。

在新的變更之後，控制平面和資料平面也進行了相應的調整，以實現該功能的順利執行。建立了單元測試以確保該功能按預期運作，並新增了一個 E2E 測試來確認資源之間的事件傳遞。所有變更都置於功能旗標之後，允許使用者根據需要啟用/停用此功能。

使用跨命名空間事件連結功能¶

此功能計畫在 1.15 版本中作為 Alpha 功能發布，目前僅支援使用 InMemoryChannels 的 InMemoryChannel 和 MTChannelBasedBroker。以下是終端使用者如何在 Knative Eventing 中使用跨命名空間參考的方式

啟用功能旗標¶

所有實作都置於功能旗標 cross-namespace-event-links 之後。要啟用功能，您可以將其新增至 config-features ConfigMap 下的 data 規格，並將功能旗標的值設定為 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 後，您現在可以建立參考跨命名空間資源的事件來源和接收器。以下是如何針對觸發器參考不同命名空間中的 Broker 的範例

觸發器訂閱另一個命名空間中的 Broker：由於已啟用功能旗標，因此可以將 Broker 新增至觸發器規格中的 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 權限，並建立參照其他命名空間中 Broker 的觸發器。這種設定增強了您的事件驅動應用程式的靈活性，實現跨不同命名空間的事件連結。

專案經驗¶

我仍然記得在申請這個專案之前第一次瀏覽功能追蹤文件時，幾乎完全看不懂。現在，隨著這個功能幾乎完成，這次的指導經驗非常有啟發性。

這個專案最突出的方面之一是，我有充足的機會與 Knative Eventing 社群互動。最初，我很猶豫要提出問題，擔心會暴露我的經驗不足。然而，當我開始更積極地參與討論，並注意到社群成員有多樂於助人時，我變得更加自信。此外，我對開源的協作本質有了更深的體會，並且我很高興能成為這個社群的一份子。

這個經驗並非沒有技術上的挑戰。其中一個主要的挑戰是將這個新功能與現有的基礎設施整合，這導致了一些意想不到的問題。例如，修改一個函數需要確保所有調用該函數的程式碼部分仍然能正確運作。此外，最初瀏覽龐大的 Knative Eventing 程式碼庫令人感到不知所措。理解架構設計，例如端對端（e2e）測試的運行方式，花了一些時間，但這是一個寶貴的學習過程，增強了我的問題解決能力和技術知識。

在專案結束時，我實現了重要的里程碑：我開啟了 7 個 issue 並合併了 11 個 PR。對於一個以有限的軟體經驗進入這個專案的人來說，這些成就對我來說特別有意義。

最終評論¶

最後，我要感謝 Calum Murray 和 Pierangelo Di Pilato 給我這個機會，信任我來實作這個功能，以及在整個過程中給予的指導和教導。沒有你們的幫助和支持，這一切真的不可能實現。

幾年後，我可能不會記得我寫過的確切程式碼，但我會永遠記得我的單元測試第一次通過時的興奮感，以及看到這個功能一步一步實現的滿足感。這次經驗開闊了我的職業前景，我期待未來能為開源社群做出更多貢獻。