2.4. Service Mesh 和 Istio 的比较

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

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

2.4.1. Red Hat OpenShift Service Mesh control plane

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

2.4.2. Red Hat OpenShift Service Mesh 中的多租户和集群范围安装的比较

多租户安装和集群范围安装之间的主要区别在于 control plane 部署使用的权限范围,比如 Galley 和 Pilot。组件不再使用集群范围的 RBAC(Role Based Access Control)资源 ClusterRoleBinding ,而是依赖项目范围内的 binding

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

Red Hat OpenShift Service Mesh 配置每个成员项目以确保自身、control plane 和其它成员项目间的网络连接。具体的配置根据 OpenShift 软件定义的网络 (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.4.3. 自动注入

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

Red Hat OpenShift Service Mesh 不会自动将 sidecar 注入任何 pod,而要求您指定 sidecar.istio.io/inject 注解,如“自动 sidecar 注入”部分所示。

2.4.4. 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.4.5. 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.4.6. Istio Container Network Interface (CNI) 插件

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

2.4.7. 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.4.8. Kiali 和服务网格

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

  • Kiali 已被默认启用。
  • 默认启用 Ingress 。
  • 对 Kiali ConfigMap 进行了更新。
  • 对 Kiali 的 ClusterRole 设置进行了更新。
  • 用户不应该手动编辑 ConfigMap 或 Kiali 自定义资源文件,因为这些更改可能会被 Service Mesh 或 Kiali 覆盖。所有在 Red Hat OpenShift Service Mesh 上运行的 Kiali 配置都是在 ServiceMeshControlPlane 自定义资源文件中进行的,且只有有限的配置选项。更新 operator 文件应该仅限于具有 cluster-admin 权限的用户。

2.4.9. Jaeger 和 服务网格

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

  • Service Mesh 默认启用 Jaeger。
  • 为 Service Mesh 默认启用 ingress 。
  • Zipkin 端口名称已改为 Jaeger-collector-zipkin(从 http)
  • Jaeger 默认使用 Elasticsearch 作为存储。
  • Istio 的社区版本提供了一个通用的 “tracing” 路由。Red Hat OpenShift Service Mesh 使用由 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 收集器。