×

Istio 和 Red Hat OpenShift 服务网格之间的区别

服务网格和 Istio 的以下功能有所不同。

命令行工具

Red Hat OpenShift 服务网格的命令行工具是 oc。Red Hat OpenShift 服务网格不支持 istioctl

安装和升级

Red Hat OpenShift 服务网格不支持 Istio 安装配置文件。

Red Hat OpenShift 服务网格不支持服务网格的蓝绿升级。

自动注入

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

Red Hat OpenShift 服务网格不会自动将 sidecar 注入任何 Pod,但您必须使用注释选择加入注入,而无需标记项目。此方法需要的权限较少,并且不会与其他 OpenShift Container Platform 功能(如构建器 Pod)冲突。要启用自动注入,请指定 sidecar.istio.io/inject 标签或注释,如“自动 sidecar 注入”部分所述。

表 1. Sidecar 注入标签和注释设置
上游 Istio Red Hat OpenShift 服务网格

命名空间标签

支持“已启用”和“已禁用”

支持“已禁用”

Pod 标签

支持“true”和“false”

支持“true”和“false”

Pod 注释

仅支持“false”

支持“true”和“false”

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

Istio 基于角色的访问控制 (RBAC) 提供了一种机制,您可以使用它来控制对服务的访问。您可以通过用户名或指定一组属性来识别主体,并相应地应用访问控制。

上游 Istio 社区安装包含执行精确标头匹配、匹配标头中的通配符或检查包含特定前缀或后缀的标头的选项。

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

上游 Istio 社区匹配请求标头示例
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-usernamepolicy
spec:
  action: ALLOW
  rules:
    - when:
        - key: 'request.regex.headers[username]'
          values:
            - "allowed.*"
  selector:
    matchLabels:
      app: httpbin

OpenSSL

Red Hat OpenShift Service Mesh 使用 OpenSSL 替换 BoringSSL。OpenSSL 是一个软件库,包含安全套接字层 (SSL) 和传输层安全 (TLS) 协议的开源实现。Red Hat OpenShift Service Mesh 代理二进制文件动态链接来自底层 Red Hat Enterprise Linux 操作系统的 OpenSSL 库 (libssl 和 libcrypto)。

外部工作负载

Red Hat OpenShift Service Mesh 不支持外部工作负载,例如在裸机服务器上 OpenShift 外部运行的虚拟机。

虚拟机支持

您可以使用 OpenShift Virtualization 将虚拟机部署到 OpenShift。然后,您可以将网格策略(例如 mTLS 或 AuthorizationPolicy)应用于这些虚拟机,就像网格中的任何其他 Pod 一样。

组件修改

  • 已向所有资源添加了maistra-version标签。

  • 所有 Ingress 资源都已转换为 OpenShift Route 资源。

  • Grafana、分布式跟踪 (Jaeger) 和 Kiali 默认启用,并通过 OpenShift 路由公开。

  • Godebug 已从所有模板中删除。

  • istio-multi ServiceAccount 和 ClusterRoleBinding 已被删除,istio-reader ClusterRole 也已删除。

Envoy 过滤器

Red Hat OpenShift Service Mesh 不支持 EnvoyFilter 配置,除非在文档中明确说明。由于与底层 Envoy API 紧密耦合,因此无法保持向后兼容性。EnvoyFilter 修补程序对 Istio 生成的 Envoy 配置的格式非常敏感。如果 Istio 生成的配置发生更改,则可能会破坏 EnvoyFilter 的应用。

Envoy 服务

Red Hat OpenShift Service Mesh 不支持基于 QUIC 的服务。

Istio 容器网络接口 (CNI) 插件

Red Hat OpenShift Service Mesh 包含 CNI 插件,它为您提供了一种配置应用程序 Pod 网络的替代方法。CNI 插件替换了init-container网络配置,无需向服务帐户和项目授予对具有提升权限的安全上下文约束 (SCC) 的访问权限。

默认情况下,Istio 容器网络接口 (CNI) Pod 会在所有 OpenShift Container Platform 节点上创建。要排除在特定节点中创建 CNI Pod,请将maistra.io/exclude-cni=true标签应用于该节点。添加此标签会从节点中删除任何先前部署的 Istio CNI Pod。

全局 mTLS 设置

Red Hat OpenShift Service Mesh 创建一个PeerAuthentication资源,用于启用或禁用网格内的相互 TLS 身份验证 (mTLS)。

网关

Red Hat OpenShift Service Mesh 默认安装入口和出口网关。您可以使用以下设置在ServiceMeshControlPlane (SMCP) 资源中禁用网关安装

  • spec.gateways.enabled=false 禁用入口和出口网关。

  • spec.gateways.ingress.enabled=false 禁用入口网关。

  • spec.gateways.egress.enabled=false 禁用出口网关。

运营商会注释默认网关,以指示它们是由 Red Hat OpenShift Service Mesh 运营商生成和管理的。

多集群配置

Red Hat OpenShift Service Mesh 对多集群配置的支持仅限于跨多个集群的网格联合。

自定义证书签名请求 (CSR)

您无法将 Red Hat OpenShift Service Mesh 配置为通过 Kubernetes 证书颁发机构 (CA) 处理 CSR。

Istio 网关的路由

Istio 网关的 OpenShift 路由在 Red Hat OpenShift Service Mesh 中自动管理。每次在服务网格内创建、更新或删除 Istio 网关时,都会创建、更新或删除 OpenShift 路由。

名为 Istio OpenShift Routing (IOR) 的 Red Hat OpenShift Service Mesh 控制平面组件会同步网关路由。有关更多信息,请参阅自动路由创建。

通配符域名

不支持通配符域名 ("*")。如果在网关定义中找到通配符域名,Red Hat OpenShift Service Mesh *将*创建路由,但将依赖 OpenShift 创建默认主机名。这意味着新创建的路由*不会*是通配符 ("*") 路由,而是将具有 <route-name>[-<project>].<suffix> 形式的主机名。有关默认主机名的工作方式以及cluster-admin如何自定义它的更多信息,请参阅 OpenShift Container Platform 文档。如果您使用 Red Hat OpenShift Dedicated,请参阅 Red Hat OpenShift Dedicated 的dedicated-admin角色。

子域名

支持子域名(例如: "*.domain.com")。但是,此功能在 OpenShift Container Platform 中默认情况下未启用。这意味着 Red Hat OpenShift Service Mesh *将*使用子域名创建路由,但只有在 OpenShift Container Platform 配置为启用它时才有效。

传输层安全

支持传输层安全 (TLS)。这意味着,如果网关包含tls部分,则 OpenShift 路由将配置为支持 TLS。

其他资源

多租户安装

上游 Istio 采用单租户方法,而 Red Hat OpenShift Service Mesh 支持集群内多个独立的控制平面。Red Hat OpenShift Service Mesh 使用多租户运营商来管理控制平面的生命周期。

Red Hat OpenShift Service Mesh 默认安装多租户控制平面。您可以指定可以访问服务网格的项目,并将服务网格与其他控制平面实例隔离开。

多租户与集群范围安装

多租户安装和集群范围安装的主要区别在于 istod 使用的权限范围。这些组件不再使用集群范围的基于角色的访问控制 (RBAC) 资源ClusterRoleBinding

ServiceMeshMemberRoll members 列表中的每个项目都将拥有与控制平面部署关联的每个服务帐户的RoleBinding,并且每个控制平面部署将只监视这些成员项目。每个成员项目都添加了一个maistra.io/member-of标签,其中member-of值是包含控制平面安装的项目。

Red Hat OpenShift Service Mesh 会配置每个成员项目,以确保其自身、控制平面和其他成员项目之间的网络访问,方法是在每个成员项目中创建一个NetworkPolicy资源,允许来自其他成员和控制平面的所有 Pod 的入口流量。如果您从服务网格中删除成员,则此NetworkPolicy资源将从项目中删除。

这也将入口流量限制为仅限成员项目。如果您需要来自非成员项目的入口流量,则需要创建一个NetworkPolicy来允许该流量通过。

集群范围资源

上游 Istio 依赖两个集群范围的资源:MeshPolicyClusterRbacConfig。这些资源与多租户集群不兼容,已按如下所述进行替换。

  • ServiceMeshPolicy 替换了 MeshPolicy,用于配置控制平面范围内的身份验证策略。此资源必须在与控制平面相同的项目中创建。

  • ServicemeshRbacConfig 替换了 ClusterRbacConfig,用于配置控制平面范围内的基于角色的访问控制。此资源必须在与控制平面相同的项目中创建。

Kiali 和服务网格

在 OpenShift Container Platform 上通过服务网格安装 Kiali 与社区版 Kiali 安装方式存在多种差异。这些修改有时是必要的,用于解决问题、提供额外功能或处理在 OpenShift Container Platform 上部署时的差异。

  • Kiali 已默认启用。

  • Ingress 已默认启用。

  • Kiali 的 ConfigMap 已更新。

  • Kiali 的 ClusterRole 设置已更新。

  • 请勿编辑 ConfigMap,因为您的更改可能会被服务网格或 Kiali Operator 覆盖。Kiali Operator 管理的文件具有 kiali.io/ 标签或注释。更新 Operator 文件应仅限于拥有 cluster-admin 权限的用户。如果您使用 Red Hat OpenShift Dedicated,则更新 Operator 文件应仅限于拥有 dedicated-admin 权限的用户。

分布式追踪和服务网格

在 OpenShift Container Platform 上通过服务网格安装分布式追踪平台 (Jaeger) 与社区版 Jaeger 安装方式存在多种差异。这些修改有时是必要的,用于解决问题、提供额外功能或处理在 OpenShift Container Platform 上部署时的差异。

  • 服务网格已默认启用分布式追踪。

  • 服务网格已默认启用 Ingress。

  • Zipkin 端口名称已从 http 更改为 jaeger-collector-zipkin

  • 当您选择 productionstreaming 部署选项时,Jaeger 默认使用 Elasticsearch 进行存储。

  • 社区版 Istio 提供了一个通用的“tracing”路由。Red Hat OpenShift Service Mesh 使用由 Red Hat OpenShift 分布式追踪平台 (Jaeger) Operator 安装的“jaeger”路由,并且该路由已受到 OAuth 保护。

  • Red Hat OpenShift Service Mesh 使用 Envoy 代理的 sidecar,Jaeger 也使用 Jaeger 代理的 sidecar。这两个 sidecar 是单独配置的,不应混淆。代理 sidecar 创建与 Pod 的入口和出口流量相关的跨度。代理 sidecar 创建与 Pod 的入站和出站流量相关的 span。agent sidecar 接收应用程序发出的 span 并将其发送到 Jaeger Collector。