我们很高兴地宣布红帽 OpenShift 服务网格 3.2 正式发布。此版本包括 Istio 环境模式的全面发布，这是一种无需 sidecar 即可部署服务网格的新方式，可显著降低使用服务网格的资源成本。这为零信任网络提供了一种低开销解决方案，具有轻量级的 pod 到 pod mTLS 加密和基于工作负载身份的授权策略，并能够根据需要添加更多高级功能。
此版本基于 Istio、Envoy 和 Kiali 项目，将 Istio 的版本更新为 1.27，将 Kiali 的版本更新为 2.17，并受红帽 OpenShift 4.18 及更高版本支持。
升级到 OpenShift 服务网格 3.2
如果您运行的是 OpenShift 服务网格 2.6 或更早版本，则必须升级到 OpenShift 服务网格 3.0、3.1 和 3.2。我们建议您立即迁移到 OpenShift 服务网格 3.0，因为 2.6 版本将于 2026 年 6 月 30 日停止维护 (EOL)（最近从 2026 年 3 月 12 日延长）。OpenShift 服务网格 3.0 文档 中提供了深入的迁移指南，包括对 OpenShift 服务网格 2.6 和 3.0 之间差异的分析。这篇博文介绍了如何使用 Kiali 控制台在 OpenShift 服务网格 2.6 和 3.0 之间进行迁移。
如需 OpenShift 服务网格 3 的实际应用示例以及完全配置的指标和 Kiali 控制台，请参阅此 解决方案模式。
无 sidecar 服务网格：Istio 的环境模式
此版本为 OpenShift 服务网格带来了对 Istio 环境模式 的普遍支持。Istio 的环境模式是一项重要的新功能，可在工作负载上启用服务网格功能，而无需 sidecar 代理。
使用 Istio 的传统数据平面架构（称为“sidecar 模式”）时，每个应用 pod 都需要一个 sidecar 代理容器来启用服务网格功能。虽然这构成了一种简单的架构，但在运行服务网格时会带来额外的开销，因为每个应用工作负载容器都需要代理容器。这也使得服务网格的采用变得复杂，因为 sidecar 代理必须作为应用和服务网格生命周期的一部分进行添加和更新。这意味着，在引入和更新服务网格时，都必须重新启动应用。
在 Istio 的环境模式架构中，数据平面被划分为两 2 个代理级别：ztunnel 和 waypoint，它们分别扮演不同的角色。
Ztunnel 代理
Ztunnel 是一种轻量级共享节点级代理，可在第 4 层拦截流量，以双向传输层安全 (mTLS) 加密、身份验证、遥测和简单的 L4 授权策略的形式提供安全防护（“Z”代表“零信任”），这些策略基于应用身份。它还提供基本的第 4 层（例如 TCP）级别的日志和指标，与所有服务网格指标一样，可以使用 Kiali 控制台进行查看。
事实上，ztunnel 是用 Rust 编写的，专门用于这种特殊用途，这使得它能够以最小的额外开销实现高性能代理。
虽然 ztunnel 作为节点级代理（即 Kubernetes DaemonSet）运行，但它会在每个 pod 的网络命名空间内实施流量重定向。这意味着，从网络隔离的角度来看，流量重定向和加密实际上发生在 pod 内，因此 pod 之间的流量隔离和加密得以维持。关于 ZTunnel 流量重定向的 Istio 文档 中对此进行了更详细的讨论，以及 Istio CNI 代理如何配置此流量重定向。
使用 Istio 的环境模式时，如果您只需要 ztunnel 提供的功能，那么它是您需要运行的唯一代理，从而形成一种非常节省资源的服务网格。
Waypoint 代理
如果用户需要应用级（第 7 层）服务网格功能，例如与 HTTP 或 gRPC 相关的遥测、流量管理和授权策略，他们可能会引入称为“waypoint”的额外代理。这些代理通常按命名空间部署，并带有一组密切相关的应用工作负载。
除了 ztunnel 已提供的功能外，Waypoint 代理还增加了以下功能：
- HTTP 路由和负载平衡、重试、超时、熔断、速率限制和故障注入
- 基于 L7 原语的丰富授权策略，例如请求类型或 HTTP 标头
- HTTP 指标、访问日志记录和跟踪
Waypoint 代理的管理方式与入口网关类似，作为独立的 Envoy 代理，并且同样可能与应用工作负载一起进行生命周期管理，而不是与服务网格控制平面或每个节点 ztunnel 一起进行生命周期管理。
Istio 的环境模式是否适合您？有哪些优点和缺点？
Istio 的环境模式仍在 Istio 社区中不断发展，目前是新服务网格安装的理想选择，因为在迁移或与 sidecar 模式结合使用时存在一些限制（有关此主题的更多信息，请参见下文）。
OpenShift 4.19 或更高版本应用于受支持的 Kubernetes 网关 API 自定义资源定义 (CRD)，建议用于配置入口网关，并且需要用于配置环境的 waypoint 代理。OpenShift 服务网格 4.18 及更早版本不包含也不提供对这些 CRD 的支持。
采用环境模式的一些优点和缺点包括：
显著降低资源成本
由于不再需要 sidecar，Istio 的环境模式显著减少了采用服务网格功能（如 mTLS 加密）所需的内存和 CPU 资源占用。与 sidecar 模式相比，我们发现内存使用量减少了 90% 以上，CPU 减少了 50% 以上。仅使用 ztunnel 时，资源使用量的减少幅度更大。
轻量级零信任网络
我们认为，Istio 环境模式的最大动机是轻量级 pod 到 pod mTLS 加密。随着零信任网络变得越来越重要，我们发现越来越多的客户要求服务网格在大量应用中实施 mTLS 加密。Istio 的环境模式与 ztunnel 单独提供了这一功能，包括身份和证书管理，同时最大限度地减少资源开销和对运行中工作负载的影响。随着需求的扩展，可以添加 waypoint 以引入应用级策略和遥测，例如基于 HTTP 请求类型（如 /GET）或标头的策略和遥测。
提高可扩展性
由于需要管理的代理更少，占用空间也小得多，Istio 的环境模式的可扩展性潜力明显大于传统的 sidecar 模式。虽然我们已经看到客户使用 Istio 的范围界定和扩展功能 扩展网格以支持数千个工作负载，但环境模式的架构提供了扩展到数万甚至数十万个工作负载的潜力，同时所需的优化更少。
潜在的性能特征
虽然早期的 Istio 社区中的性能测量结果 非常有希望，但我们仍在类似企业的设置中评估 Istio 环境模式的性能，以便与我们的客户进行比较。到目前为止，我们已经看到了与 sidecar 模式相当的性能，并且在未来版本中还有改进的潜力。与 ztunnel 和 waypoint 相比，单独使用 ztunnel 的性能特征会有所不同，具体取决于设置，waypoint 会增加更大的开销。我们还遇到了性能 已知瓶颈，这限制了 ztunnel 的垂直可扩展性，需要一段时间才能解决。我们相信，Istio 的环境架构在未来版本中显示出性能改进的潜力。
更轻松地采用
Istio 的环境模式也使服务网格更易于采用，不再需要修改工作负载来添加 sidecar 容器。事实上，甚至不需要重新启动这些工作负载，即可将其添加到网格中，或者在网格升级时重新启动。二级架构还支持逐步采用 Istio 功能，而不会在不需要时产生第 7 层代理的资源成本。
功能支持级别
请注意，环境模式对 Istio 功能的支持级别可能与传统 sidecar 模式不同。如需受支持功能的列表，请参阅服务网格 功能支持表。多集群 和多网格等高级功能在很大程度上仍处于开发阶段，而 将工作负载与 sidecar 和环境模式混合使用存在局限性，尤其是在将 waypoint 代理与 sidecar 搭配使用时。有关 Istio 社区对环境与 sidecar 的看法的更多信息，请参阅 此页面。
升级注意事项
Istio 的环境模式具有以下优势：可以在不重新启动工作负载 pod 的情况下更新 Istio 的数据平面，而 sidecar 代理则需要这样做。需要权衡的是，ztunnel 是共享的节点级代理，是多个应用的数据路径的一部分。因此，必须谨慎升级 ztunnel。我们建议在维护时段或流量较低的时段进行升级，这将导致该节点上的长期 TCP 连接被重置。自此版本起，尚不支持基于修订版 (canary) 的升级。这将是未来版本中的一个开发领域。
开始使用 Istio 的环境模式
为了开始使用 Istio 的环境模式，OpenShift 服务网格提供了“Ztunnel”资源，用于将 ztunnel 作为守护程序集进行安装和管理。它与“Istio”和“IstioCNI”资源一起安装，即使某些工作负载具有 sidecar，也必须使用“ambient”配置文件进行配置。
与传统的 sidecar 模式一样，配置 Istio“发现选择器”也很重要，以确保 Istio 控制平面能够监控将要成为网格一部分的命名空间。对于环境模式，标签“istio.io/dataplane-mode=ambient”用于指示网格中应包含命名空间或工作负载。有关添加工作负载的更多信息，请参阅 Istio 社区文档。
当新的工作负载添加到网格时，Istio CNI 代理将与节点本地 ztunnel 代理一起配置流量重定向，以便拦截所有流量并将其升级为使用采用 Istio 的 HBONE 隧道协议 的 mTLS。Ztunnel 还处理同一节点上所有 pod 的证书获取和管理。
如果需要 waypoint 代理，可以使用 OpenShift 4.19+ 附带的 Kubernetes 网关 API 中的 Kubernetes“网关”资源，以类似于添加入口或出口网关的方式添加。如需了解有关安装 waypoint 的更多信息，请点击 此处，也可点击 此处 了解如何将 waypoint 用于 L7 功能。
有关开始使用 Istio 环境模式的详细步骤，请参阅 OpenShift 服务网格文档。
如果我已经在使用服务网格，可以迁移到环境模式吗？
虽然环境模式非常适合服务网格新用户，但也可以将其引入到现有的服务网格部署中，并与 sidecar 模式工作负载结合使用，但有一些注意事项。我们还预计，当每个 pod 需要专用 Envoy 代理的完整功能集时，sidecar 模式将继续是首选用例。
要将环境模式引入现有网格，必须使用“ambient”配置集更新网格（Istio 和 Istio CNI），并且必须重新启动所有具有 sidecar 的工作负载，以便它们可以使用 HBONE 隧道协议 与 ztunnel 通信。
这种共存的当前限制是 sidecar 代理和环境工作负载之间的流量通常会绕过 waypoint 代理，因此第 7 层策略不会应用于环境工作负载。
鉴于这些限制，我们建议命名空间和应用组使用环境模式或 sidecar 模式，而不是在紧密耦合的应用工作负载中混合使用模式。同样重要的是，要避免混合使用 sidecar 和环境模式 pod 标签。
Kiali 与 Istio 环境模式
Kiali 是 OpenShift 服务网格附带的 Istio 控制台，提供了许多用于配置、可视化和验证 Istio 环境模式的功能。由于工作负载有可能处于多种可能的状态（与 ztunnel 处于网格状态、与 waypoint 处于网格状态、处于 sidecar 模式或不属于网格状态），因此，对于了解网格状态以及在分布式应用的行为不符合预期时进行故障排除，Kiali 变得更加重要。
Kiali 在每个级别上提供清晰的确认信息，表明环境模式已成功配置。首先，Istio 控制平面在启用了环境配置文件的情况下运行，并且命名空间和工作负载已被标记，以便工作负载流量将由 ztunnel 和/或 waypoint 按预期捕获。最后，在 pod 级别，您可以检查是否使用 Istio 的 HBONE 协议 （而不是未加密的 TCP）来保护流量。
Kiali 还提供 ztunnel 和 waypoint 之间的关联日志，以便您可以了解流量如何通过每个代理从工作负载转移，并进行故障排除。
虽然 waypoint 代理与其他代理类似，但 Kiali 有一个特定的选项卡来显示已注册的服务和工作负载。
最后，与 sidecar 模式相比，环境模式的拓扑图看起来有所不同。由于现在有两 2 个级别的代理，因此每个工作负载可能会报告两 2 组独立的遥测数据：来自 ztunnel 的 L4 (TCP) 指标显示为蓝色边缘，而配置了 waypoint 的 L7 (HTTP) 指标则显示为绿色边缘。Kiali 提供了选择所显示流量类型的功能。
由于 waypoint 代理很可能代表紧密耦合的工作负载组（可能构成一个常见的分布式应用），因此 waypoint 视图将在可能非常大的网格中提供网格的更高级别概述。
如需详细了解 Kiali 的所有环境模式功能，请参阅 Kiali 社区文档。
Istio 1.27 更新
此版本包含 Istio 1.27 变更说明中所述的所有更新。以下是部分亮点：
网关 API 推理扩展 (GIE)
此版本包含对 Gateway API 推理扩展 的支持。为了更好地为红帽 OpenShift AI 3 的客户提供支持，我们已将普遍可用的 API 实现（版本 1.0）向后移植到此版本中。请注意，此功能仅受红帽 OpenShift AI 3 支持，并且被视为 OpenShift 服务网格 3.2 的技术预览功能。
采用环境模式的多集群
此版本在多主、多集群拓扑中引入了对 Istio 环境模式的初步支持。由于此功能仍处于上游开发阶段，因此我们已将其指定为 OpenShift 服务网格 3.2 的“开发人员预览版”。
Sidecar 模式中的原生 nftables 支持
在为红帽企业 Linux (RHEL) 10 做准备的过程中，红帽将对 nftables 的支持贡献给了 Istio 项目，并在 Istio 1.27 中引入了对 sidecar 模式的支持。nftable 框架 是 iptables 的现代替代方案，后者是 Istio 用于配置网络重定向规则的 Linux 功能。它旨在为进出 Envoy sidecar 的流量重定向提供更佳的性能、可维护性和更灵活的规则管理。从 RHEL 10 开始，nftables 将成为管理网络规则的默认工具。OpenShift 的未来版本将提供对 RHEL 10 的支持。
Cert-manager Istio-CSR 现已正式发布
支持将 cert-manager Operator 与 OpenShift 服务网格搭配使用，但 cert-manager 需要 istio-csr 代理来签署、交付和续订工作负载的证书。随着 cert-manager Operator 1.18 版本的发布，此代理现已正式发布，并且可以用于所有受支持的 OpenShift 服务网格版本。如需详细了解 cert-manager 和 OpenShift 服务网格如何协同工作以实现零信任，请阅读 这篇博文。如需概述如何将 cert-manager 与 OpenShift 服务网格结合使用的步骤，请查看 文档。
OpenShift 服务网格入门
要了解有关红帽 OpenShift 服务网格的更多信息，请阅读 这篇博文 以及关于 多集群服务网格 的后续文章。
要开始使用服务网格，您必须先 安装红帽 OpenShift 服务网格 3 Operator。如果您不熟悉服务网格，不妨考虑 Istio 的环境模式。与传统的 sidecar 模式相比，它将提供资源效率显著提高的服务网格架构。要开始使用 Istio 的环境模式，请点击 此处 阅读相关文档。
有关将 OpenShift 服务网格与 OpenShift 用户工作负载监控、分布式跟踪和 Kiali 结合使用的端到端示例，请参阅 此解决方案模式。
关于作者
Jamie Longmuir is the product manager leading Red Hat OpenShift Service Mesh. Prior to his journey as a product manager, Jamie spent much of his career as a software developer with a focus on distributed systems and cloud infrastructure automation. Along the way, he has had stints as a field engineer and training developer working for both small startups and large enterprises.
