红帽 OpenShift 服务网格 3：开发人员预览版更新

今年早些时候，我发布了 适用于红帽 OpenShift 平台上 Istio 的全新 Operator，作为下一代 OpenShift 服务网格（版本 3）的开发人员预览版。那篇博客文章中提供了有关 2024 年 OpenShift 服务网格变化的重要背景信息。此后，我们继续开发  Sail Operator，同时为  OpenShift 服务网格 2 的客户提供支持，并收集有关服务网格 3 计划的反馈。虽然全新 Operator 仍处于 开发人员预览阶段，但本文将介绍最新动态，讨论各项未来计划，并就 OpenShift 服务网格用户如何为 OpenShift 服务网格 3 做好准备提供初步指导。

服务网格 3.0 更新

服务网格 3 Kubernetes Operator 目前正在作为“Sail Operator”进行开发，并以社区版 Kubernetes Operator 的形式在 OpenShift Operator Hub 上提供。Sail Kubernetes Operator 每天夜间更新一次，因此仍处于开发之中，随时可能会发生变化。它的发展方向可能会与本文所述有所不同，因此，目前我们仅建议将其用于实验目的。如需 Kubernetes Operator 的最新信息，请参阅随附的  README。

我们计划将这个社区版 Kubernetes Operator 转移到上游  istio-ecosystem 组织，以加强社区协作，同时为核心 Istio 项目提供增强功能，以提高 Istio 在 OpenShift 上的兼容性。OpenShift 服务网格 3 的下游产品工件将驻留在新建的  openshift-service-mesh 组织中，而  maistra 组织将继续用于服务网格 2。

适用于 Istio 的 Kubernetes Operator 且仅限于 Istio

正如上一篇博客文章中所述，OpenShift 服务网格 3 将基于适用于 Istio 的全新 Kubernetes Operator。与当前的 OpenShift 服务网格 2 Kubernetes Operator 不同，全新 Kubernetes Operator 仅负责管理 Istio 资源，不会像 Kiali 那样试图配置  Istio 集成。Kiali、指标和跟踪等补充组件将由独立支持的产品 Kubernetes Operator 进行管理。

在首次发布 Sail Operator 时，用于安装 Istio 控制平面的自定义资源曾被称为  IstioHelmInstall。为了准确反映该资源的职责，即创建和管理单个 Istio 实例（一个控制平面和一个数据平面），现已更名为“Istio”。

与 OpenShift 服务网格 2 中使用的  ServiceMeshControlPlane 自定义资源不同，Istio 资源使用上游  Istio 的 Helm 值 来定义 Istio 配置。这样，用户可以更加轻松地将社区配置示例转换为 OpenShift 服务网格 3。这也有助于确保与 Istio 社区合作完成未来的配置改进工作。我们不排除未来与社区的 Istio Operator API 融合的可能，后者与  istioctl 安装流程和上游  Istio Operator 安装（不推荐）搭配使用。

我们接下来的工作将包括完善配置和增强功能的安排，以更好地支持 Istio 修订、 金丝雀式升级和多租户等功能。如需最新的信息，请参阅 Kubernetes Operator 的 README 文件。

选择发行版本

当我们第一次发布 Sail Operator 时，它将部署最新版本的 Istio，即开发中的 Istio 的  Master 分支。尽管这样可以方便地试验来自 Istio 社区的最新版本，但在大多数情况下，用户应该使用 Istio 的正式发行版，以确保与  istioctl 和  Kiali 等集成的稳定性和兼容性。

我们现在默认使用最新版本的 Istio，目前为 1.20。您可使用 Istio CRD 中的  version 字段进行配置。使用 OpenShift 控制台创建新实例时，现在可以通过下拉菜单，从可用的 Istio 发行版列表中进行选择。可用的 Istio 发行版在  versions.yaml 文件中定义，每当有新的 Istio 发行版可用时，该文件都会进行更新。

Istio 版本选择下拉菜单

未来的 OpenShift 服务网格 3 产品 Kubernetes Operator 将基于 Sail Operator，以类似的方式管理 OpenShift 服务网格的发行版。虽然此  version 字段与服务网格 2.x 中 ServiceMeshControlPlane 资源的  version 字段类似，但一个明显区别是用户可以指定低至 Z“补丁”发行版级别的版本（如 3.1.1）。虽然我们仅支持 OpenShift 服务网格的最新补丁发行版，但此功能允许用户固定或回滚到特定的“z”补丁发行版，从而增强了补丁更新管理的控制力和灵活性。

配置验证

使用新 CRD 来配置 Istio 时，主要使用的字段是  values 字段。通过这个功能强大的字段，用户能够直接引用  Istio Helm 配置值。我们为此字段添加了验证功能，以根据上游 Istio 的  protobuf 验证来捕获不存在的配置值和其他配置错误。

这些验证还支持管理  values 字段，如下方所示：

$ oc explain istio.spec.values 
KIND:     Istio 
VERSION:  operator.istio.io/v1alpha1 
RESOURCE: values <Object> 
DESCRIPTION: 
    Values defines the values to be passed to the Helm chart when installing 
    Istio. 
FIELDS: 
  base <Object> 
  cni <Object> 
  defaultRevision <string> 
  global <Object> 
  istio_cni <Object> 
  istiodRemote <Object> 
  meshConfig <> 
  ownerName <string> 
  pilot <Object> 
  revision <string> 
  revisionTags <[]string> 
  sidecarInjectorWebhook <Object> 
  telemetry <Object> 
  ztunnel <>

鉴于有时出于特定需求（比如访问尚未整合至 Istio 的 protobuf 架构的试验性配置），需要绕过这些验证步骤，我们增设了 rawValues 字段，该字段与 values 字段功能相同，但不包含任何验证流程。

请注意，Istio 资源、values 字段和 rawValues 字段仍处于试验阶段，随时可能会发生变化。如需最新信息，请参阅项目的  README。

Istio 状态和配置

在应用 Istio 配置后，您应该验证控制平面的状态。您可使用以下命令来执行此操作：

$ kubectl get istioundefinedundefinedundefined

NAME         READY  STATUS VERSION AGE

istio-sample True  Healthy v1.20.0 62sundefinedundefined

或者，使用 status 字段：

Istio 自定义资源定义

展开之后，您可以使用 status.appliedValues 字段，以利用 spec.values 字段来验证配置是否已按预期应用。

OpenShift 上的 Istio

作为与 Istio 社区进行融合的一部分，我们继续为上游 Istio 贡献力量，以提高 Istio 在 OpenShift 上的兼容性。这不仅关乎我们自身的利益（简化 Istio 的产品化工作），也是为了回馈社区、客户和合作伙伴。我们的贡献极大地便利了在 OpenShift 上运行社区版 Istio 的过程，同时也为我们所支持的 OpenShift 服务网格铺设了一条无缝的集成之路。

这方面的一个示例是，不再需要向 Istio 控制平面和数据平面组件授予 anyuid 安全上下文约束（SCC）特权，正如 Istio 1.20 中近期所强调的那样。我们将坚持不懈地做出类似的贡献，其中最为重要的是致力于让 Istio 的 Ambient 网格在 OpenShift 平台上顺畅运行。

网关最佳实践

在此 Kubernetes Operator 推出之时，它会自动安装 网关，类似于默认的 Istio 安装配置集。这与 OpenShift 服务网格 2.x 一致，后者会创建默认的入口和出口网关，分别名为  istio-ingressgateway 和 istio-egressgateway。

尽管这些自动创建的网关提供了便利的入门途径，但它们难以满足生产环境中对高度可配置性的需求。我们还深信，相较于控制平面，在数据平面中与应用一起创建和管理网关，能够带来更好的效果。与应用一起创建和管理网关是一种更优越的安全方式。这可将网关的作用范围限制为较小的应用集合，并使它能够采用应用的生命周期，而不是控制平面的生命周期。

因此，我们选择删除这些控制平面网关，以便引导用户使用网关注入或 Kubernetes Gateway API 来与应用一起创建网关。OpenShift 服务网格 2.x 的 ServiceMeshControlPlane中指定的 istio-ingressgateway 和 istio-egressgateway 将不包含在服务网格 3.0 中。相反，我们将使用网关注入和 Kubernetes Gateway API 来为 Bookinfo 应用提供网关的示例配置。

有了 网关注入，网关的创建和管理与 Kubernetes 或 OpenShift 上的任何其他工作负载一样，将使用通过 Envoy 代理注入的 Deployment 资源。这种方法将网关的完全控制权交给了应用所有者。在 OpenShift 服务网格 2.3 及更高版本中，推荐使用这种方式来创建和管理网关。

在 OpenShift 服务网格 2.4 的技术预览版中，可利用 Gateway API 为每个 网关实例创建和配置一个网关“Deployment”实例。

这些选项允许与应用一起创建和管理网关，最好是融入到  GitOps 工作流中。

Kubernetes Gateway API

Kubernetes Gateway API 代表了用于在 Kubernetes 中进行网络建模的新一代 API。相较于当前的 Kubernetes Ingress API，它可为管理大型企业的网络提供更大的灵活性和可扩展性。虽然原本设计用于管理来自集群外部客户端的南北流量，但如今已经扩展至涵盖东西流量，包括服务网格在内。为了明确 Gateway API 如何全面覆盖服务网格用例，我们启动了 GAMMA 计划。Istio 现已为大多数成文任务（如 流量管理）提供了 Gateway API 配置示例。

虽然在 OpenShift 服务网格 2.4 中，Gateway API 仍然是技术预览功能，并且必须通过 功能标志来启用，但它现在 已在社区中公开发布。该 API 的 1.0 版在 Istio 1.20 中提供（将包含在 OpenShift 服务网格 2.6 及更高版本中）。Istio 计划日后将 Gateway API 设为所有流量管理的默认 API，同时在可预见的未来继续支持各种 Istio API（Gateway、VirtualService、DestinationRule 等）。

我们对  Gateway API 项目充满热情，因为它有望为 Kubernetes 网络提供超越服务网格范畴的通用标准。

我们正在开发基于 Gateway API 的 OpenShift Ingress 实施方案，让用户可以通过 Gateway API Ingress Operator 独立于服务网格进行部署。如需有关这项工作和 Gateway API 的更多信息，请参阅这篇 博客文章和 最新动态。

与此同时， 3Scale API Management 的开发团队正在紧锣密鼓地开发  Kuadgrant.io 项目，该项目旨在利用 Gateway API 解决一系列关于外部流量如何进入入口网关的用例，例如多集群连接、全局负载平衡、速率限制和授权等。如需有关此项目的信息，请参阅即将发布的博客文章。

开始使用 Kiali 等 Istio 附加组件

OpenShift 服务网格 3.0 中的一个显著变化是 Kubernetes Operator 将仅负责管理 Istio。Kiali、分布式跟踪和指标等集成将独立地安装和管理。尽管“入门”体验会因此增加一些步骤，但在配置这些组件时将获得良好的模块化特性和灵活性，因而这一权衡是完全值得的。

为帮助用户快速上手并运行，我们在 Kubernetes Operator README 中添加了 相关说明，以指导使用 Istioctl、示例网关、Prometheus、Jaeger 和 Kiali 来设置 Istio。这提供了一个演示/开发环境，与 OpenShift 服务网格 2.x 目前开箱提供的环境大致相当。它还展示了我们即将在 OpenShift 服务网格 3 中推出的安装工作流的预览，采用该工作流时，Istio 将会单独安装，而且附加组件也可独立安装。当然，受支持的服务网格 3.0 会将受支持的产品 Kubernetes Operator 用于各个 Istio 附加组件，并且使用受支持的 Istioctl 分发。这些社区 Istio 附加组件配置仅用于演示/开发目的，不可用于生产环境

为服务网格 3.0 做准备

OpenShift 服务网格 2 的用户现可着手进行几项准备工作，以便顺利采用服务网格 3.0。

务必谨记，OpenShift 服务网格 3 将继续基于  Istio，并且最终用户可能使用的  Istio 稳定 API 将不会有变化。OpenShift 服务网格 3 中发生变化且需要迁移的是控制平面配置资源，如  ServiceMeshControlPlane、 ServiceMeshMemberRoll 和  ServiceMeshMemberRoll 等。负责管理这些资源的通常是管理员或平台团队，而不是应用所有者。我们将继续探索各种方法，以方便管理员将现有控制平面配置迁移到服务网格 3 的配置中。

而特定于应用的配置，诸如  VirtualServices、 DestinationRules 乃至  PeerAuthentication 等 Istio 资源，不会有变化。因此，用户可以放心，在迁移到 OpenShift 服务网格 3 时，他们能够无缝地开始或扩展使用 OpenShift 服务网格 2，而不必费心迁移特定于应用或服务的配置。

用户现在可以着手进行一些准备工作，以便更轻松地迁移到 OpenShift 服务网格 3.0。除了使用最新的 OpenShift 服务网格版本（2.4 以上）外，用户还可以：

• 采用或迁移到网关注入，与应用一起创建和管理 Istio 网关，而不是使用 Istio 控制平面（这是服务网格 2.0 中的默认设置）。如上文所述，3.0 中的控制平面不会创建网关。
• 如果您不需要多个控制平面，请使用 集群范围模式。在这种模式下，Istiod 作为集群级资源来运行。在服务网格 3.0 中，这将是默认设置，并且可以使用新兴的 多控制平面功能来创建多个控制平面。
• 对服务网格进行配置，以使用 OpenShift 的用户工作负载监控功能或 红帽高级集群管理的可观测性功能来捕获指标。这些将提供具备警报功能的生产级监控堆栈，相比 OpenShift 服务网格 2.x 版本中安装（但将在服务网格 3 中移除）的指标堆栈，它们将具有更高的可配置性和可扩展性。
• 应使用外部配置的 Kiali 和 Jaeger 资源，而不是直接在 ServiceMeshControlPlane 资源中进行配置。除了为管理 Kiali 和 Jaeger 带来更大的灵活性之外，它们将在服务网格 3 中实现独立配置。

我们之后会发表博客文章，逐一对这些主题进行深入探讨。

OpenShift 服务网格的下一步是什么？

我们的下一个发行版是 OpenShift 服务网格 2.5（基于 Istio 1.18），发布时间为 2024 年初。我们还决定在 2024 年推出基于 Istio 1.20 或更新版本的 2.6 发行版，以确保客户在从 OpenShift 服务网格 2 升级到 3 的过程中，享有至少一年的重叠支持。此外，2.6 版本将为我们提供更多时间，以收集 OpenShift 服务网格 3 在技术预览阶段期间的用户反馈。

对于 OpenShift 服务网格 3，我们持续改进全新的 Kubernetes Operator，包括调整自定义资源定义来优化 Istio 配置的管理，并增添功能来强化对 Istio 控制平面金丝雀升级的支持。我们的目标是在 2024 年第一季度末推出技术预览版，并于 2024 年下半年正式发布。当然，这些目标可能会有变化。我们将继续为 OpenShift 服务网格 2.x 的客户提供支持，直到我们正式发布 OpenShift 服务网格 3。

如需进一步了解红帽 OpenShift 服务网格，请访问此页面。