我的 LFX 导师项目经历：跨命名空间事件链接功能 ¶

发布日期：2024-07-16 , 修订日期：2024-07-26

我的 LFX 导师项目经历：跨命名空间事件链接功能¶

作者：王奕洁，LFX'24 学员

Cross Namespace Event Links

在过去三个月里，我有幸参与了 LFX 导师项目。我的具体项目名为 CNCF - Knative 事件：跨命名空间事件链接，我的建议功能路线图在这里。随着学期结束，我想花点时间回顾一下我的旅程，与大家分享。

功能描述¶

在多租户场景中，一些用例可能需要将代理和通道与它们发送事件到的服务分离到不同的命名空间中。虽然这种设置在使用事件的团队可以访问代理和通道所在的命名空间时可以正常工作，但并非总是如此。为了解决这个问题，提议为触发器和订阅（事件链接）提供一个新功能，让它们可以与它们引用的代理或通道位于不同的命名空间中。LFX 导师项目给了我将这一新颖且高度需要的功能变为现实的机会。

对于具体实现，我使用基于角色的访问控制 (RBAC) 来安全地管理权限。创建了一个新的 RBAC 动词 knsubscribe，允许用户订阅特定代理/通道。此外，我使用主体访问审核来确保只有授权用户才能创建和管理这些跨命名空间事件链接。

根据新的更改，控制平面和数据平面进行了相应调整，以确保功能平稳执行。创建了单元测试以确保功能按预期工作，并添加了 E2E 测试以确认资源之间的事件传递。所有更改都位于功能标志之后，允许用户根据需要启用/禁用此功能。

使用跨命名空间事件链接功能¶

此功能计划在 1.15 版本中作为 alpha 功能发布，目前仅支持使用 InMemoryChannels 的 InMemoryChannel 和 MTChannelBasedBroker。以下是最终用户如何在 Knative 事件中使用跨命名空间引用

启用功能标志¶

所有实现都位于功能标志 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

或者，可以使用具有必要凭据的用户。如果对集群中具有较少权限的不同用户的凭据进行验证更容易，并且对该用户进行角色绑定，这可能更容易。

在目标命名空间中创建角色：使用动词 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 后，现在可以创建引用跨命名空间资源的事件源和接收器。以下是如何为触发器引用另一个命名空间中的代理的示例

触发器订阅另一个命名空间中的代理：由于启用了功能标志，因此可以将代理添加到 Trigger 规范中的 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 事件中启用跨命名空间引用，设置必要的 RBAC 权限，并创建引用另一个命名空间中的代理的触发器。此设置增强了事件驱动应用程序的灵活性，使事件链接跨越不同的命名空间成为可能。

项目经历¶

我仍然记得在申请该项目之前第一次浏览功能路线图文档，当时几乎什么都不懂。现在这个功能即将完成，这段导师项目经历非常有见地。

该项目最突出的方面之一是它提供了大量与 Knative 事件社区互动的机会。最初，我犹豫是否要提问，担心会暴露我的缺乏经验。然而，当我开始更多地参与讨论并注意到社区成员多么乐于助人时，我获得了更大的信心。此外，我对开源的协作性质有了更深的了解，我很高兴成为社区中的一员。

这段经历并非没有技术挑战。一个主要的挑战是将此新功能与现有基础设施集成，这会导致意想不到的问题。例如，修改函数需要确保调用此函数的所有代码部分仍然正常运行。此外，最初浏览庞大的 Knative 事件代码库令人不知所措。理解架构设计，例如端到端 (e2e) 测试的运行方式，需要一些时间，但这是一个宝贵的学习过程，它提高了我的解决问题的能力和技术知识。

在项目结束时，我取得了重大的里程碑：我打开了 7 个问题并合并了 11 个 PR。对于一个以有限软件经验进入该项目的个人来说，这些成就对我来说尤其有意义。

最后评论¶

最后，我要感谢 Calum Murray 和 Pierangelo Di Pilato 给予我这次机会，信任我实施这项功能，并在整个旅程中给予我指导和帮助。没有你们的帮助和支持，这一切都不可能实现。

几年后，我可能不记得自己写过的具体代码，但我永远不会忘记我的单元测试首次通过时的兴奋之情，以及看到这个功能一步步实现的满足感。这段经历拓宽了我的职业前景，我期待着未来为开源社区做出更多贡献。