支持控制台（Console）开发人员开始试用联系人

2.3. Service Mesh 和 Istio 的不同

警告

查看不再支持的 Red Hat OpenShift Service Mesh 发行版本的文档。

Service Mesh 版本 1.0 和 1.1 control plane 不再被支持。有关升级服务网格 control plane 的详情，请参阅 升级 Service Mesh。

有关特定 Red Hat OpenShift Service Mesh 发行版本的支持状态的信息，请参阅产品生命周期页面。

Red Hat OpenShift Service Mesh 安装与上游 Istio 社区安装有许多不同。当在 OpenShift Container Platform 上进行部署时，为了解决问题、提供额外功能或处理不同之处，对 Red Hat OpenShift Service Mesh 的修改有时是必须的。

Red Hat OpenShift Service Mesh 的当前发行版本与当前上游 Istio 社区发行版本的不同：

2.3.1. 多租户安装

上游 Istio 采用单一租户方法，Red Hat OpenShift Service Mesh 支持集群中的多个独立的 control plane。Red Hat OpenShift Service Mesh 使用多租户 Operator 来管理 control plane 生命周期。

Red Hat OpenShift Service Mesh 默认安装多租户 control plane。您可以指定可以访问 Service Mesh 的项目，并将 Service Mesh 与其他 control plane 实例隔离。

2.3.1.1. 多租户和集群范围的安装

多租户安装和集群范围安装之间的主要区别在于使用的权限范围。组件不再使用集群范围的 Role Based Access Control（RBAC）资源 ClusterRoleBinding。

ServiceMeshMemberRoll members 列表中的每个项目都将为每个与 control plane 部署关联的服务帐户都有一个 RoleBinding，每个 control plane 部署只会监视这些成员项目。每个成员项目都有一个 maistra.io/member-of 标签，其中 member-of 值是包含 control plane 安装的项目。

Red Hat OpenShift Service Mesh 配置每个成员项目以确保自身、control plane 和其它成员项目间的网络连接。具体的配置根据 OpenShift Container Platform 软件定义网络 (SDN) 的配置而有所不同。更多详情请参阅“关于 OpenShift SDN”。

如果 OpenShift Container Platform 集群被配置为使用 SDN 插件：

  • NetworkPolicy: Red Hat OpenShift Service Mesh 在每个成员项目中创建一个 NetworkPolicy 资源，允许从其它成员和 control plane 到 pod 的入站网络数据。如果从 Service Mesh 中删除了一个成员，则这个 NetworkPolicy 资源会从项目中删除。

    注意

    这也限制了到成员项目的入站网络数据。如果需要来自非成员项目的入站网络数据，则需要创建一个 NetworkPolicy 来允许这些流量通过。

  • Multitenant: Red Hat OpenShift Service Mesh 将每个成员项目的 NetNamespace 加入到 control plane 项目的 NetNamespace （相当于运行 oc adm pod-network join-projects --to control-plane-project member-project）。如果您从 Service Mesh 中删除一个成员，它的 NetNamespace 与 control plane 分离（相当于运行 oc adm pod-network is isolatedate-projects member-project）。
  • Subnet：没有执行其他配置。

2.3.1.2. 集群范围内的资源

上游 Istio 会依赖于两个集群范围的资源。MeshPolicy 和 ClusterRbacConfig。它们与多租户集群不兼容并已被替换，如下所述。

  • ServiceMeshPolicy 替换了用于配置 control-plane-wide 验证策略的 MeshPolicy。这必须与 control plane 在同一个项目中创建。
  • ServicemeshRbacConfig 替换 ClusterRbacConfig 以配置基于 control-plane 范围角色的访问控制。这必须与 control plane 在同一个项目中创建。

2.3.2. Istio 和 Red Hat OpenShift Service Mesh 之间的区别

Red Hat OpenShift Service Mesh 安装与 Istio 安装在多个方面都有所不同。当在 OpenShift Container Platform 上进行部署时，为了解决问题、提供额外功能或处理不同之处，对 Red Hat OpenShift Service Mesh 的修改有时是必须的。

2.3.2.1. 命令行工具

Red Hat OpenShift Service Mesh 的命令行工具是 oc。  Red Hat OpenShift Service Mesh 不支持 istioctl。

2.3.2.2. 自动注入

上游 Istio 社区安装会在您标记的项目中自动将 sidecar 注入 pod。

Red Hat OpenShift Service Mesh 不会自动将 sidecar 注入任何 pod，而是要求您选择使用没有标记项目的注解注入。这个方法需要较少的权限，且不会与其他 OpenShift 功能冲突，比如 builder pod。要启用自动注入，您可以指定 sidecar.istio.io/inject 注解，如自动 sidecar 注入部分所述。

2.3.2.3. Istio 基于角色的访问控制功能

Istio 基于角色的访问控制 (RBAC) 提供了可用来控制对某个服务的访问控制机制。您可以根据用户名或者指定一组属性来识别对象，并相应地应用访问控制。

上游 Istio 社区安装提供的选项包括：标头精确匹配、匹配标头中的通配符，或匹配标头中包括的特定前缀或后缀。

Red Hat OpenShift Service Mesh 使用正则表达式来扩展与请求标头匹配的功能。使用正则表达式指定 request.regex.headers 的属性键。

上游 Istio 社区匹配请求标头示例

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.headers[<header>]: "value"

Red Hat OpenShift Service Mesh 使用正则表达式匹配请求标头

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: httpbin-client-binding
  namespace: httpbin
spec:
  subjects:
  - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    properties:
      request.regex.headers[<header>]: "<regular expression>"

2.3.2.4. OpenSSL

Red Hat OpenShift Service Mesh 将 BoringSSL 替换为 OpenSSL。OpenSSL 是包含安全套接字层 (SSL) 和传输层 (TLS) 协议的开源实现的软件库。Red Hat OpenShift Service Mesh Proxy 二进制代码动态地将 OpenSSL 库（libssl 和 libcrypto）与底层的 Red Hat Enterprise Linux 操作系统进行链接。

2.3.2.5. 组件修改

  • maistra-version 标签已添加到所有资源中。
  • 所有 Ingress 资源都已转换为 OpenShift Route 资源。
  • Grafana、Tracing(Jaeger)和 Kiali 会被默认启用，并通过 OpenShift 路由公开。
  • Godebug 已从所有模板中删除
  • istio-multi ServiceAccount 和 ClusterRoleBinding 已被删除，同时也删除了 istio-reader ClusterRole。

2.3.2.6. Envoy、Secret Discovery Service 和证书

  • Red Hat OpenShift Service Mesh 不支持基于 QUIC 的服务。
  • Red Hat OpenShift Service Mesh 目前还不支持使用 Istio 的 Secret Discovery Service (SDS) 功能部署 TLS 证书。Istio 的实施取决于使用 hostPath 挂载的 nodeagent 容器。

2.3.2.7. Istio Container Network Interface (CNI) 插件

Red Hat OpenShift Service Mesh 包括 CNI 插件，它为您提供了配置应用程序 pod 网络的替代方法。CNI 插件替代了 init-container 网络配置，可在不需要提高访问权限的情况下赋予服务帐户和项目对安全上下文约束 (SCC) 的访问。

2.3.2.8. Istio 网关的路由

Istio 网关的 OpenShift 路由在 Red Hat OpenShift Service Mesh 中被自动管理。每次在 service mesh 中创建、更新或删除 Istio 网关时，都会自动创建、更新或删除 OpenShift 路由。

名为 Istio OpenShift Routing (IOR) 的 Red Hat OpenShift Service Mesh control plane 组件可以用来同步网关路由。如需更多信息，请参阅自动路由创建。

2.3.2.8.1. catch-all 域

不支持 Catch-all（"*"）。如果在网关定义中找到一个，Red Hat OpenShift Service Mesh 将创建路由，但会依赖于 OpenShift 来创建一个默认主机名。这意味着新创建的路由不是 catch all ("*") 路由，而是使用 <route-name> [-<project>].<suffix> 格式的主机名。如需有关默认主机名的工作方式以及集群管理员如何自定义它的更多信息，请参阅 OpenShift 文档。

2.3.2.8.2. 子域

支持子域（例如："*.domain.com"）。但是，OpenShift Container Platform 中不默认启用此功能。这意味着，Red Hat OpenShift Service Mesh 将使用子域创建路由，但只有在 OpenShift Container Platform 被配置为启用它时才有效。

2.3.2.8.3. 传输层安全性

支持传输层安全性（TLS）。这意味着，如果网关包含 tls 部分，OpenShift Route 将配置为支持 TLS。

其他资源

2.3.3. Kiali 和服务网格

通过 OpenShift Container Platform 上的 Service Mesh 安装 Kiali 与社区 Kiali 安装不同。为了解决问题、提供额外功能或处理不同之处，这些不同有时是必须的。

  • Kiali 已被默认启用。
  • 默认启用 Ingress 。
  • 对 Kiali ConfigMap 进行了更新。
  • 对 Kiali 的 ClusterRole 设置进行了更新。
  • 不要编辑 ConfigMap，因为您的更改可能会被 Service Mesh 或 Kiali Operator 覆盖。Kiali Operator 管理的文件有 kiali.io/ 标签或注解。更新 Operator 文件应仅限于具有 cluster-admin 权限的用户。如果使用 Red Hat OpenShift Dedicated，则更新 Operator 文件应该仅限于具有 dedicated-admin 权限的用户。

2.3.4. 分布式追踪和服务网格

使用 OpenShift Container Platform 上的 Service Mesh 安装分布式追踪平台 (Jaeger) 与社区 Jaeger 安装不同。为了解决问题、提供额外功能或处理不同之处，这些不同有时是必须的。

  • Service Mesh 默认启用分布式追踪。
  • 为 Service Mesh 默认启用 ingress 。
  • Zipkin 端口名称已改为 jaeger-collector-zipkin（从 http）
  • 当选择 production 或 streaming 部署选项时，Jaeger 会默认使用 Elasticsearch 作为存储。
  • Istio 的社区版本提供了一个通用的 “tracing” 路由。Red Hat OpenShift Service Mesh 使用由 Red Hat OpenShift distributed tracing Platform (Jaeger) Operator 安装的 "jaeger" 路由，并已受到 OAuth 的保护。
  • Red Hat OpenShift Service Mesh 为 Envoy proxy 使用 sidecar，Jaeger 也为 Jaeger agent 使用 sidecar。这两个 sidecar 是单独配置的，不应该相互混淆。proxy sidecar 会创建和 pod 的入站和出站相关的 span。agent sidecar 收到应用程序提供的 span ，并将其发送到 Jaeger 收集器。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.