6.2. 了解 Service Binding Operator


应用程序开发人员需要访问支持的服务,以构建和连接工作负载。连接工作负载以支持服务始终是一个挑战,因为每个服务提供商建议以不同方式访问其机密并在工作负载中使用它们。此外,手动配置和维护这种工作负载和后备服务组合,使得流程变得繁琐、效率低下且容易出错。

Service Binding Operator 可让应用程序开发人员将工作负载与 Operator 管理的后备服务轻松绑定,而无需任何手动步骤来配置绑定连接。

6.2.1. 服务绑定术语

本节总结了服务绑定中使用的基本术语。

服务绑定

提供向工作负载提供服务的信息的操作表示。例如,在 Java 应用程序和它所需的数据库之间建立凭据交换。

后端服务

应用在网络上运行的任何服务或软件作为其正常操作的一部分。示例包括数据库、消息代理、带 REST 端点的应用、事件流、应用程序性能监控器 (APM) 或硬件安全模块 (HSM)。

工作负载(应用程序)

容器内运行的任何进程。示例包括 Spring Boot 应用、NodeJS Express 应用或 Ruby on Rails 应用。

绑定数据

有关用于配置集群中其他资源行为的服务的信息。示例包括凭证、连接详情、卷挂载或 secret。

绑定连接

任何在连接的组件(如可绑定后备服务)和需要支持服务的应用程序之间建立交互的连接。

6.2.2. 关于 Service Binding Operator

Service Binding Operator 由一个控制器和附带的自定义资源定义 (CRD) 组成,用于服务绑定。它管理工作负载的数据平面并提供支持服务。Service Binding Controller 读取由后备服务的 control plane 提供的数据。然后,它会根据通过 ServiceBinding 资源指定的规则将这些数据到工作负载。

因此,Service Binding Operator 通过自动收集和与工作负载共享绑定数据,使工作负载能够使用后备服务或外部服务。这个过程包括使后备服务绑定,并将工作负载和服务绑定在一起。

6.2.2.1. 使 Operator 管理的后备服务可绑定

要使服务可绑定,作为 Operator 供应商,您需要公开工作负载所需的绑定数据,以便与 Operator 提供的服务绑定。您可以在管理后备服务的 Operator CRD 中以注解或描述符形式提供绑定数据。

6.2.2.2. 将工作负载与后备服务绑定

通过将 Service Binding Operator 用作应用程序开发人员,您需要声明建立绑定连接的意图。您必须创建一个 ServiceBinding CR 来引用后端服务。此操作会触发 Service Binding Operator 将公开的绑定数据项目到工作负载中。Service Binding Operator 接收声明的意图,并将工作负载与后备服务绑定。

Service Binding Operator 的 CRD 支持以下 API:

  • 使用 binding.operators.coreos.com API 组的服务绑定
  • 服务绑定 (Spec API)servicebinding.io API 组。

使用 Service Binding Operator,您可以:

  • 将工作负载绑定到 Operator 管理的后备服务。
  • 自动配置绑定数据。
  • 为服务提供商提供低接触管理经验,以调配和管理对服务的访问。
  • 通过一致、声明性的服务绑定方法增强开发生命周期,消除群集环境中的差异。

6.2.3. 主要特性

  • 公开服务的绑定数据

    • 根据 CRD、自定义资源 (CR) 或资源中的注解。
  • 工作负载投射

    • 使用卷挂载以文件形式预测绑定数据。
    • 绑定数据作为环境变量的投射。
  • 服务绑定选项

    • 在与工作负载命名空间不同的命名空间中绑定后备服务。
    • 项目绑定数据到特定的容器工作负载。
    • 自动检测来自后备服务 CR 拥有的资源的绑定数据。
    • 编写来自公开绑定数据的自定义绑定数据。
    • 支持非PodSpec 兼容工作负载资源。
  • 安全性

    • 支持基于角色的访问控制 (RBAC)。

6.2.4. API 的不同

Service Binding Operator 的 CRD 支持以下 API:

  • 使用 binding.operators.coreos.com API 组的服务绑定
  • 服务绑定 (Spec API)servicebinding.io API 组。

这两个 API 组都有类似的功能,但它们并不完全一致。以下是这些 API 组之间的区别的完整列表:

功能binding.operators.coreos.com API 组支持servicebinding.io API 组支持备注

绑定到置备的服务

不适用 (N/A)

直接 secret 投射

不适用 (N/A)

作为文件绑定

  • servicebinding.io API 组的服务绑定的默认行为
  • 服务绑定 binding.operators.coreos.com API 组的参与功能

作为环境变量绑定

  • 服务绑定 binding.operators.coreos.com API 组的默认行为。
  • 服务绑定 servicebinding.io API 组的参与功能:环境变量和文件一起创建。

使用标签选择器选择工作负载

不适用 (N/A)

发现绑定资源 (.spec.detectBindingResources)

servicebinding.io API 组没有对应的功能。

命名策略

servicebinding.io API 组中没有当前的机制来解释命名策略使用的模板。

容器路径

部分

因为 binding.operators.coreos.com API 组中的服务绑定可以在 ServiceBinding 资源中指定映射行为,所以 servicebinding.io API 组无法完全支持对等的行为,而无需更多与工作负载相关的信息。

容器名称过滤

binding.operators.coreos.com API 组没有等同的功能。

Secret 路径

servicebinding.io API 组没有对应的功能。

备用绑定源(例如,从注解中绑定数据)

被 Service Binding Operator 允许

该规范需要支持从置备的服务和 secret 获取数据。但是,对规格的严格读取表示,支持其他绑定数据源。使用这个事实,Service Binding Operator 可以从各种源拉取绑定数据(例如,从注解中拉取绑定数据)。Service Binding Operator 在两个 API 组上支持这些源。

6.2.5. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.