1.4. 服务网格部署模型


Red Hat OpenShift Service Mesh 支持几种不同的部署模型,它们可以以不同的方式组合以满足您的业务需求。

1.4.1. 单网格部署模型

最简单的 Istio 部署模型是一个网格。

网格中的服务名称必须是唯一的,因为 Kubernetes 只允许一个服务在 mynamespace 命名空间中被命名为 myservice。但是,工作负载实例可以共享一个通用身份,因为服务帐户名称可以在同一个命名空间中的工作负载之间共享

1.4.2. 单租赁部署模型

在 Istio 中,租户是为一组部署的工作负载共享共同访问权限和特权的用户组。您可以使用租户在不同的团队之间提供一定程度的隔离。您可以使用 istio.io 或服务资源的 NetworkPoliciesAuthorizationPoliciesexportTo 注解来隔离对不同租户的访问。

从 Red Hat OpenShift Service Mesh 版本 1.0 开始,单租户、集群范围的 Service Mesh control plane 配置已弃用。Red Hat OpenShift Service Mesh 默认为多租户模型。

1.4.3. 多租户部署模型

Red Hat OpenShift Service Mesh 安装了一个 ServiceMeshControlPlane,它默认配置为多租户。Red Hat OpenShift Service Mesh 使用多租户 Operator 来管理 Service Mesh control plane 生命周期。在网格内,命名空间用于租期。

Red Hat OpenShift Service Mesh 使用 ServiceMeshControlPlane 资源来管理网格安装,该安装范围默认限制为包含资源的命名空间。您可以使用 ServiceMeshMemberRollServiceMeshMember 资源在网格中包含额外的命名空间。命名空间只能包含在单个网格中,多个网格也可以安装到单个 OpenShift 集群中。

典型的服务网格部署使用单一 Service Mesh control plane 来配置网格中服务间的通信。Red Hat OpenShift Service Mesh 支持"软多租户",其中每个租户有一个 control plane 和一个网格,并且集群中可以有多个独立的 control plane。多租户部署指定可以访问 Service Mesh 的项目,并将 Service Mesh 与其他 control plane 实例隔离。

集群管理员在所有 Istio control plane 间获得控制和可见性,而租户管理员只能控制其特定的 Service Mesh、Kiali 和 Jaeger 实例。

您可以授予团队权限,以便仅将工作负载部署到给定的命名空间或一组命名空间。如果服务网格管理员授予 mesh-user 角色,用户可以创建一个 ServiceMeshMember 资源来将命名空间添加到 ServiceMeshMemberRoll

1.4.4. Multimesh 或联邦部署模型

Federation(联邦) 是一种部署模型,可让您在不同管理域中管理的单独网格间共享服务和工作负载。

Istio 多集群模型需要在网格和远程访问独立网格所在的所有 Kubernetes API 服务器之间具有高度信任。Red Hat OpenShift Service Mesh 联邦针对 Service Mesh 的多集群实施,该方法假设网格之间的信任最小

联邦网格(federated mesh) 是作为单个网格组成的一组网格。每个网格中的服务可以是独特的服务,例如通过从另一个网格中导入服务的网格添加服务,可以为网格中的相同服务提供额外的工作负载,提供高可用性或两者的组合。加入联邦的所有网格都保持单独管理,您必须明确配置要导出哪些服务并从联邦中的其他网格导入。证书生成、指标和追踪集合等支持功能在其各自网格中保持本地。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.