1.5. Service Mesh 和 Istio 的不同
Red Hat OpenShift Service Mesh 与 Istio 安装的不同之处在于提供额外功能或在 OpenShift Container Platform 上部署时处理不同之处。
1.5.1. Istio 和 Red Hat OpenShift Service Mesh 之间的区别
Service Mesh 和 Istio 中的以下功能不同。
1.5.1.1. 命令行工具
Red Hat OpenShift Service Mesh 的命令行工具是 oc
。 Red Hat OpenShift Service Mesh 不支持 istioctl
。
1.5.1.2. 安装和升级
Red Hat OpenShift Service Mesh 不支持 Istio 安装配置集。
Red Hat OpenShift Service Mesh 不支持 service mesh 的 Canary 升级。
1.5.1.3. 自动注入
上游 Istio 社区安装会在您标记的项目中自动将 sidecar 注入 pod。
Red Hat OpenShift Service Mesh 不会自动将 sidecar 注入任何 pod,而是要求您选择使用没有标记项目的注解注入。这个方法需要较少的权限,且不会与其他 OpenShift Container Platform 功能冲突,比如 builder pod。要启用自动注入,请指定 sidecar.istio.io/inject
标签或注解,如自动 sidecar 注入部分所述。
上游 Istio | Red Hat OpenShift Service Mesh | |
---|---|---|
命名空间标签 | 支持"启用"和"禁用" | 支持"禁用" |
Pod 标签 | 支持 "true" 和 "false" | 支持 "true" 和 "false" |
Pod 注解 | 只支持 "false" | 支持 "true" 和 "false" |
1.5.1.4. 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
1.5.1.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 操作系统进行链接。
1.5.1.6. 外部工作负载
Red Hat OpenShift Service Mesh 不支持外部工作负载,如在裸机服务器上运行的虚拟机。
1.5.1.7. 虚拟机支持
您可以使用 OpenShift Virtualization 将虚拟机部署到 OpenShift。然后,您可以将网格策略(如 mTLS 或 AuthorizationPolicy)应用到这些虚拟机,就像其它属于网格的 pod 一样。
1.5.1.8. 组件修改
- maistra-version 标签已添加到所有资源中。
- 所有 Ingress 资源都已转换为 OpenShift Route 资源。
- Grafana、分布式追踪(Jaeger)和 Kiali 会被默认启用,并通过 OpenShift 路由公开。
- Godebug 已从所有模板中删除
-
istio-multi
ServiceAccount 和 ClusterRoleBinding 已被删除,同时也删除了istio-reader
ClusterRole。
1.5.1.9. Envoy 过滤器
Red Hat OpenShift Service Mesh 不支持 EnvoyFilter
配置,除非明确记录。由于与底层 Envoy API 紧密耦合,因此无法保持向后兼容性。EnvoyFilter
补丁对 Istio 生成的 Envoy 配置格式非常敏感。如果 Istio 生成的配置有变化,则代表可能会破坏 EnvoyFilter
的应用程序。
1.5.1.10. Envoy 服务
Red Hat OpenShift Service Mesh 不支持基于 QUIC 的服务。
1.5.1.11. Istio Container Network Interface (CNI) 插件
Red Hat OpenShift Service Mesh 包括 CNI 插件,它为您提供了配置应用程序 pod 网络的替代方法。CNI 插件替代了 init-container
网络配置,可在不需要提高访问权限的情况下赋予服务帐户和项目对安全上下文约束 (SCC) 的访问。
1.5.1.12. 全局 mTLS 设置
Red Hat OpenShift Service Mesh 创建一个 PeerAuthentication
资源,在网格内启用或禁用 Mutual TLS 身份验证 (mTLS)。
1.5.1.13. 网关
Red Hat OpenShift Service Mesh 默认安装入口和出口网关。您可以使用以下设置在 ServiceMeshControlPlane
(SMCP) 资源中禁用网关安装:
-
spec.gateways.enabled=false
可禁用入口和出口网关。 -
spec.gateways.ingress.enabled=false
禁用入口网关。 -
spec.gateways.egress.enabled=false
禁用出口网关。
Operator 注解了默认网关,以指示它们由 Red Hat OpenShift Service Mesh Operator 生成并管理。
1.5.1.14. 多集群配置
Red Hat OpenShift Service Mesh 对多集群配置的支持仅限于跨多个集群的服务网格的联邦。
1.5.1.15. 自定义证书签名请求 (CSR)
您无法将 Red Hat OpenShift Service Mesh 配置为通过 Kubernetes 证书颁发机构 (CA) 处理 CSR。
1.5.1.16. Istio 网关的路由
Istio 网关的 OpenShift 路由在 Red Hat OpenShift Service Mesh 中被自动管理。每次在 service mesh 中创建、更新或删除 Istio 网关时,都会自动创建、更新或删除 OpenShift 路由。
名为 Istio OpenShift Routing (IOR) 的 Red Hat OpenShift Service Mesh control plane 组件可以用来同步网关路由。如需更多信息,请参阅自动路由创建。
1.5.1.16.1. catch-all 域
不支持 Catch-all("*")。如果在网关定义中找到一个,Red Hat OpenShift Service Mesh 将创建路由,但会依赖于 OpenShift 来创建一个默认主机名。这意味着新创建的路由不是 catch all ("*") 路由,而是使用 <route-name> [-<project>].<suffix>
格式的主机名。如需有关默认主机名的工作方式以及 cluster-admin
如何自定义它的更多信息,请参阅 OpenShift Container Platform 文档。如果使用 Red Hat OpenShift Dedicated,请参阅 Red Hat OpenShift Dedicated 的 dedicated-admin
角色。
1.5.1.16.2. 子域
支持子域(例如:"*.domain.com")。但是,OpenShift Container Platform 中不默认启用此功能。这意味着,Red Hat OpenShift Service Mesh 将使用子域创建路由,但只有在 OpenShift Container Platform 被配置为启用它时才有效。
1.5.1.16.3. 传输层安全性
支持传输层安全性(TLS)。这意味着,如果网关包含 tls
部分,OpenShift Route 将配置为支持 TLS。
其他资源
1.5.2. 多租户安装
上游 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 实例隔离。
1.5.2.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:没有执行其他配置。
1.5.2.2. 集群范围内的资源
上游 Istio 会依赖于两个集群范围的资源。MeshPolicy
和 ClusterRbacConfig
。它们与多租户集群不兼容并已被替换,如下所述。
- ServiceMeshPolicy 替换了用于配置 control-plane-wide 验证策略的 MeshPolicy。这必须与 control plane 在同一个项目中创建。
- ServicemeshRbacConfig 替换 ClusterRbacConfig 以配置基于 control-plane 范围角色的访问控制。这必须与 control plane 在同一个项目中创建。
1.5.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
权限的用户。
1.5.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 收集器。