第 6 章 将应用程序连接到服务
6.1. Service Binding Operator 发行注记
Service Binding Operator 由一个控制器和附带的自定义资源定义 (CRD) 组成,用于服务绑定。它管理工作负载的数据平面并提供支持服务。Service Binding Controller 读取由后备服务的 control plane 提供的数据。然后,它会根据通过 ServiceBinding
资源指定的规则将这些数据到工作负载。
使用 Service Binding Operator,您可以:
- 将工作负载与 Operator 管理的后备服务绑定。
- 自动配置绑定数据。
- 为服务提供商提供低接触管理经验,以调配和管理对服务的访问。
- 通过一致、声明性的服务绑定方法增强开发生命周期,消除群集环境中的差异。
Service Binding Operator 的自定义资源定义 (CRD) 支持以下 API:
-
使用
binding.operators.coreos.com
API 组的服务绑定。 -
服务绑定 (Spec API) 与
servicebinding.io
API 组。
6.1.1. 支持列表
下表中的一些功能是技术预览。它们并不适用于在生产环境中使用。
在下表中,被标记为以下状态的功能:
- TP: 技术预览
- GA: 正式发行
请参阅红帽门户网站中关于对技术预览功能支持范围的信息:
Service Binding Operator | API 组和支持状态 | OpenShift 版本 | |
---|---|---|---|
版本 |
|
| |
1.3.3 | GA | GA | 4.9-4.12 |
1.3.1 | GA | GA | 4.9-4.11 |
1.3 | GA | GA | 4.9-4.11 |
1.2 | GA | GA | 4.7-4.11 |
1.1.1 | GA | TP | 4.7-4.10 |
1.1 | GA | TP | 4.7-4.10 |
1.0.1 | GA | TP | 4.7-4.9 |
1.0 | GA | TP | 4.7-4.9 |
6.1.2. 使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。这些更改将在即将发行的几个发行本中逐渐实施。详情请查看 Red Hat CTO Chris Wright 信息。
6.1.3. Service Binding Operator 1.3.3 发行注记
Service Binding Operator 1.3.3 现在包括在 OpenShift Container Platform 4.9、4.10、4.11 和 4.12 中。
6.1.3.1. 修复的问题
-
在此次更新之前,为 Service Binding Operator 记录了一个安全漏洞
CVE-2022-41717
。在这个版本中修复了CVE-2022-41717
错误,并将 v0.0.0-20220906165146-f3363e06e74c 中的golang.org/x/net
软件包更新为 v0.4.0。APPSVC-1256 - 在此次更新之前,只有在相应资源在其他置备服务丢失时设置了 "servicebinding.io/provisioned-service: true" 注解时,才会检测到 Provisioned Services。在这个版本中,检测机制会根据 "status.binding.name" 属性正确识别所有 Provisioned Services。APPSVC-1204
6.1.4. Service Binding Operator 1.3.1 发行注记
Service Binding Operator 1.3.1 现在包括在 OpenShift Container Platform 4.9、4.10 和 4.11 中。
6.1.4.1. 修复的问题
-
在此次更新之前,为 Service Binding Operator 记录了一个安全漏洞
CVE-2022-32149
。在这个版本中修复了CVE-2022-32149
错误,并将golang.org/x/text
软件包从 v0.3.7 更新至 v0.3.8。APPSVC-1220
6.1.5. Service Binding Operator 1.3 发行注记
Service Binding Operator 1.3 现在包括在 OpenShift Container Platform 4.9、4.10 和 4.11 上。
6.1.5.1. 删除的功能
- 在 Service Binding Operator 1.3 中,Operator Lifecycle Manager (OLM) 描述符功能已被删除,以改进资源利用率。作为 OLM 描述符的替代选择,您可以使用 CRD 注解来声明绑定数据。
6.1.6. Service Binding Operator 1.2 发行注记
Service Binding Operator 1.2 现在包括在 OpenShift Container Platform 4.7、4.8、4.9、4.10 和 4.11 上。
6.1.6.1. 新功能
本节重点介绍 Service Binding Operator 1.2 中的新内容:
-
通过将
optional
标志值设为true
,启用 Service Binding Operator 以考虑注解中的可选字段。 -
支持
servicebinding.io/v1beta1
资源。 - 通过公开相关绑定 secret 而无需存在工作负载,可以改进可绑定服务的可用性。
6.1.6.2. 已知问题
- 目前,当您在 OpenShift Container Platform 4.11 上安装 Service Binding Operator 时,Service Binding Operator 的内存占用量会高于预期限制。但是,使用低的情况下,内存占用量保留在环境或方案的预期范围内。与 OpenShift Container Platform 4.10 相比,在压力下,平均和最大内存占用率都显著提高。这个问题也会在以前的 Service Binding Operator 版本中识别。当前没有解决此问题的方法。APPSVC-1200
-
默认情况下,投射文件的权限设置为 0644。Service Binding Operator 无法因为 Kubernetes 中的一个错误而设置特定权限,这会导致在服务需要特定权限(如
0600
)时出现问题。作为临时解决方案,您可以修改程序代码或正在工作负载资源中运行的应用程序,将文件复制到/tmp
目录中并设置适当的权限。APPSVC-1127 在单一命名空间安装模式中安装 Service Binding Operator 当前存在一个已知问题。因为缺少一些命名空间范围的访问控制 (RBAC) 规则,应用程序可能无法成功绑定到 Service Binding Operator 可自动探测和绑定到的、几个已知的 Operator 支持的服务。当发生这种情况时,它会生成类似以下示例的错误消息:
错误信息示例
`postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden: User "system:serviceaccount:my-petclinic:service-binding-operator" cannot get resource "postgresclusters" in API group "postgres-operator.crunchydata.com" in the namespace "my-petclinic"`
临时解决方案 1:在
all namespaces
安装模式中安装 Service Binding Operator。这样,会存在适当的集群范围的 RBAC 规则,绑定会成功。临时解决方案 2:如果无法在
all namespaces
安装模式下安装 Service Binding Operator,在安装了 Service Binding Operator 的命名空间中安装以下角色绑定:示例:用于 Crunchy Postgres Operator 的角色绑定
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: service-binding-crunchy-postgres-viewer subjects: - kind: ServiceAccount name: service-binding-operator roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: service-binding-crunchy-postgres-viewer-role
根据规格,当更改
ClusterWorkloadResourceMapping
资源时,Service Binding Operator 必须使用早期版本的ClusterWorkloadResourceMapping
资源来删除被项目的绑定数据。目前,当更改ClusterWorkloadResourceMapping
资源时,Service Binding Operator 会使用ClusterWorkloadResourceMapping
资源的最新版本来删除绑定数据。因此,{servicebinding-title} 可能会错误地删除绑定数据。作为临时解决方案,请执行以下步骤:-
删除使用对应
ClusterWorkloadResourceMapping
资源的所有ServiceBinding
资源。 -
修改
ClusterWorkloadResourceMapping
资源。 -
重新应用您之前在第 1 步中删除的
ServiceBinding
资源。
-
删除使用对应
6.1.7. Service Binding Operator 1.1.1 发行注记
Service Binding Operator 1.1.1 现在包括在 OpenShift Container Platform 4.7、4.8、4.9 和 4.10 上。
6.1.7.1. 修复的问题
-
在此次更新之前,在 Service Binding Operator Helm chart 中记录了一个安全漏洞
CVE-2021-38561
。在这个版本中,CVE-2021-38561
错误,并将golang.org/x/text
软件包从 v0.3.6 更新至 v0.3.7。APPSVC-1124 -
在此次更新之前,Developer Sandbox 用户没有足够权限来读取
ClusterWorkloadResourceMapping
资源。因此,Service Binding Operator 会阻止所有服务绑定成功。在这个版本中,Service Binding Operator 会为任何经过身份验证的主体(包括 Developer Sandbox 用户)包含适当的基于角色的访问控制(RBAC)规则。这些 RBAC 规则允许 Service Binding Operatorget
,list
, 和watch
Developer Sandbox 用户的ClusterWorkloadResourceMapping
资源,并成功处理服务绑定。APPSVC-1135
6.1.7.2. 已知问题
在单一命名空间安装模式中安装 Service Binding Operator 当前存在一个已知问题。因为缺少一些命名空间范围的访问控制 (RBAC) 规则,应用程序可能无法成功绑定到 Service Binding Operator 可自动探测和绑定到的、几个已知的 Operator 支持的服务。当发生这种情况时,它会生成类似以下示例的错误消息:
错误信息示例
`postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden: User "system:serviceaccount:my-petclinic:service-binding-operator" cannot get resource "postgresclusters" in API group "postgres-operator.crunchydata.com" in the namespace "my-petclinic"`
临时解决方案 1:在
all namespaces
安装模式中安装 Service Binding Operator。这样,会存在适当的集群范围的 RBAC 规则,绑定会成功。临时解决方案 2:如果无法在
all namespaces
安装模式下安装 Service Binding Operator,在安装了 Service Binding Operator 的命名空间中安装以下角色绑定:示例:用于 Crunchy Postgres Operator 的角色绑定
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: service-binding-crunchy-postgres-viewer subjects: - kind: ServiceAccount name: service-binding-operator roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: service-binding-crunchy-postgres-viewer-role
目前,当您修改
ClusterWorkloadResourceMapping
资源时,Service Binding Operator 不会实施正确的行为。作为临时解决方案,请执行以下步骤:-
删除使用对应
ClusterWorkloadResourceMapping
资源的所有ServiceBinding
资源。 -
修改
ClusterWorkloadResourceMapping
资源。 -
重新应用您之前在第 1 步中删除的
ServiceBinding
资源。
-
删除使用对应
6.1.8. Service Binding Operator 1.1 发行注记
Service Binding Operator 现在包括在 OpenShift Container Platform 4.7、4.8、4.9 和 4.10 中。
6.1.8.1. 新功能
本节重点介绍 Service Binding Operator 1.1 中的新内容:
服务绑定选项
- 工作负载资源映射:精确定义需要针对辅助工作负载投射绑定数据的位置。
- 使用标签选择器绑定新工作负载。
6.1.8.2. 修复的问题
- 在此次更新之前,使用标签选择器提取工作负载的服务绑定不会将数据绑定到与给定标签选择器匹配的新工作负载中。因此,Service Binding Operator 无法定期绑定这些新工作负载。在这个版本中,服务绑定将数据绑定到与给定标签选择器匹配的新工作负载。Service Binding Operator 现在定期尝试查找和绑定这些新工作负载。APPSVC-1083
6.1.8.3. 已知问题
在单一命名空间安装模式中安装 Service Binding Operator 当前存在一个已知问题。因为缺少一些命名空间范围的访问控制 (RBAC) 规则,应用程序可能无法成功绑定到 Service Binding Operator 可自动探测和绑定到的、几个已知的 Operator 支持的服务。当发生这种情况时,它会生成类似以下示例的错误消息:
错误信息示例
`postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden: User "system:serviceaccount:my-petclinic:service-binding-operator" cannot get resource "postgresclusters" in API group "postgres-operator.crunchydata.com" in the namespace "my-petclinic"`
临时解决方案 1:在
all namespaces
安装模式中安装 Service Binding Operator。这样,会存在适当的集群范围的 RBAC 规则,绑定会成功。临时解决方案 2:如果无法在
all namespaces
安装模式下安装 Service Binding Operator,在安装了 Service Binding Operator 的命名空间中安装以下角色绑定:示例:用于 Crunchy Postgres Operator 的角色绑定
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: service-binding-crunchy-postgres-viewer subjects: - kind: ServiceAccount name: service-binding-operator roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: service-binding-crunchy-postgres-viewer-role
目前,当您修改
ClusterWorkloadResourceMapping
资源时,Service Binding Operator 不会实施正确的行为。作为临时解决方案,请执行以下步骤:-
删除使用对应
ClusterWorkloadResourceMapping
资源的所有ServiceBinding
资源。 -
修改
ClusterWorkloadResourceMapping
资源。 -
重新应用您之前在第 1 步中删除的
ServiceBinding
资源。
-
删除使用对应
6.1.9. Service Binding Operator 1.0.1 发行注记
Service Binding Operator 现在包括在 OpenShift Container Platform 4.7、4.8 和 4.9 中。
Service Binding Operator 1.0.1 支持 OpenShift Container Platform 4.9 及之后的版本运行:
- IBM Power 系统
- IBM Z 和 LinuxONE
Service Binding Operator 1.0.1 的自定义资源定义(CRD)支持以下 API:
-
使用
binding.operators.coreos.com
API 组的服务绑定。 服务绑定(Spec API 技术预览),使用
servicebinding.io
API 组。重要带有
servicebinding.io
API 组的 Service Binding (Spec API Tech Preview) 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
6.1.9.1. 支持列表
这个版本中的一些功能当前还处于技术预览状态。它们并不适用于在生产环境中使用。
在下表中,功能被标记为以下状态:
- TP: 技术预览
- GA: 正式发行
请参阅红帽门户网站中关于对技术预览功能支持范围的信息:
功能 | Service Binding Operator 1.0.1 |
---|---|
| GA |
| TP |
6.1.9.2. 修复的问题
-
在此次更新之前,从 CR 的
postgresql.k8s.enterpriesedb.io/v1
API 的Cluster
自定义资源(CR)中绑定数据值,从 CR 的.metadata.name
字段收集主机
绑定值。收集的绑定值是不正确的主机名,正确的主机名在.status.writeService
字段中可用。在这个版本中,Service Binding Operator 用来公开后备服务 CR 的绑定数据值的注解现在被修改为从.status.writeService
字段收集主机
绑定值。Service Binding Operator 使用这些修改的注解来将正确的主机名注入到主机
和供应商
绑定中。APPSVC-1040 -
在这个更新之前,当您绑定
postgres-operator.crunchydata.com/v1beta1
API 的PostgresCluster
CR 时,绑定数据值不包括数据库证书的值。因此,应用程序无法连接到数据库。在这个版本中,对 Service Binding Operator 用来从后备服务 CR 中公开绑定数据的注解的修改现在包含数据库证书。Service Binding Operator 使用以下修改后的注解来生成正确的ca.crt
、tls.crt
和tls.key
证书文件。APPSVC-1045 -
在此次更新之前,当绑定
pxc.percona.com
API 的PerconaXtraDBCluster
自定义资源(CR)时,绑定数据值不包括端口
和数据库
值。这些绑定值与其他已注入的绑定值是应用程序成功连接到数据库服务所需的值。在这个版本中,Service Binding Operator 用来公开服务 CR 的绑定数据值的注解现在被修改为项目额外的端口
和数据库
绑定值。Service Binding Operator 使用以下修改后的注解来生成完整的、应用程序用于成功连接到数据库服务所需的绑定值。APPSVC-1073
6.1.9.3. 已知问题
目前,当您在单一命名空间安装模式下安装 Service Binding Operator 时,因为缺少一些命名空间范围的访问控制(RBAC)规则,所以应用程序可能无法成功绑定到 Service Binding Operator 可自动探测和绑定到的、几个已知的 Operator 支持的服务。另外,还会生成以下出错信息:
错误信息示例
`postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden: User "system:serviceaccount:my-petclinic:service-binding-operator" cannot get resource "postgresclusters" in API group "postgres-operator.crunchydata.com" in the namespace "my-petclinic"`
临时解决方案 1:在
all namespaces
安装模式中安装 Service Binding Operator。这样,会存在适当的集群范围的 RBAC 规则,绑定会成功。临时解决方案 2:如果无法在
all namespaces
安装模式下安装 Service Binding Operator,在安装了 Service Binding Operator 的命名空间中安装以下角色绑定:示例:用于 Crunchy Postgres Operator 的角色绑定
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: service-binding-crunchy-postgres-viewer subjects: - kind: ServiceAccount name: service-binding-operator roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: service-binding-crunchy-postgres-viewer-role
6.1.10. Service Binding Operator 1.0 发行注记
Service Binding Operator 现在包括在 OpenShift Container Platform 4.7、4.8 和 4.9 中。
Service Binding Operator 1.0 的自定义资源定义 (CRD) 支持以下 API:
-
使用
binding.operators.coreos.com
API 组的服务绑定。 服务绑定(Spec API 技术预览),使用
servicebinding.io
API 组。重要带有
servicebinding.io
API 组的 Service Binding (Spec API Tech Preview) 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
6.1.10.1. 支持列表
这个版本中的一些功能当前还处于技术预览状态。它们并不适用于在生产环境中使用。
在下表中,功能被标记为以下状态:
- TP: 技术预览
- GA: 正式发行
请参阅红帽门户网站中关于对技术预览功能支持范围的信息:
功能 | Service Binding Operator 1.0 |
---|---|
| GA |
| TP |
6.1.10.2. 新功能
Service Binding Operator 1.0 支持 OpenShift Container Platform 4.9 及之后的版本运行:
- IBM Power 系统
- IBM Z 和 LinuxONE
本节重点介绍了 Service Binding Operator 1.0 中的新功能:
公开服务的绑定数据
- 根据 CRD、自定义资源 (CR) 或资源中的注解。
- 基于 Operator Lifecycle Manager (OLM) 描述符中存在的描述符。
- 支持置备的服务
工作负载投射
- 使用卷挂载以文件形式预测绑定数据。
- 绑定数据作为环境变量的投射。
服务绑定选项
- 在与工作负载命名空间不同的命名空间中绑定后备服务。
- 项目绑定数据到特定的容器工作负载。
- 自动检测来自后备服务 CR 拥有的资源的绑定数据。
- 编写来自公开绑定数据的自定义绑定数据。
-
支持非
PodSpec
兼容工作负载资源。
安全性
- 支持基于角色的访问控制 (RBAC)。