从 Sidecar 迁移至 Ambient

本指南将引导您将现有的 Istio 部署从 Sidecar 模式迁移至 Ambient 模式。 此次迁移旨在实现渐进式且可逆的操作：在迁移过程中， Sidecar 模式与 Ambient 模式下的工作负载可在同一服务网格中共存，从而允许您逐个命名空间地进行迁移。

迁移策略

迁移采用循序渐进的方法：

1. **安装 Ambient 组件：**添加 ztunnel 并更新 CNI 以支持 Ambient 模式， 同时保持所有现有的 Sidecar 工作负载不变。
2. **迁移策略：**将 VirtualService 资源转换为 HTTPRoute； 根据需要更新 AuthorizationPolicy 资源，使其指向 waypoint； 并将 RequestAuthentication 和 WasmPlugin 资源挂载到 waypoint 上。 如果您仅使用 L4 策略，请跳过此步骤。 如果您使用了 L7 策略， 请注意在迁移过程中会出现短暂的策略执行空窗期，详见上方的警告。
3. **按命名空间启用 Ambient 模式：**为命名空间添加标签以加入 Ambient 网格， 激活 waypoint，移除 Sidecar 注入，并重启 Pod。

每一个步骤均可独立撤销。无需一次性迁移所有命名空间。

资源迁移概述

下表总结了 Sidecar 模式资源如何映射至其 Ambient 模式下的对应资源：

您需要 waypoint 代理吗？

如果您的工作负载使用了以下任何一项，您就需要使用 waypoint 代理：

• L7 AuthorizationPolicy 规则（基于 HTTP 方法、路径或请求头进行匹配）。
• 基于 HTTPRoute 的 L7 流量路由（重试、故障注入、请求头操纵、流量拆分）。 如果您目前使用 VirtualService 来实现此功能，则需要迁移至 HTTPRoute； VirtualService 在 Ambient 模式下的支持目前处于 Alpha 阶段。
• RequestAuthentication（JWT 验证）。
• L7 遥测数据丰富。

如果您不确定，迁移策略页面可协助您审计现有资源。

不支持的内容

以下为硬性阻碍，在解决这些问题之前，无法进行迁移：

• 网格内的 VM 工作负载。基于 VM 的工作负载无法加入 Ambient 网格。
• 将 SPIRE 作为证书提供方。Ambient 模式不支持集成 SPIRE。
• 包含 mode: DISABLE 的 PeerAuthentication 策略。 Ambient 模式始终在网格工作负载之间强制执行 mTLS。 配置为 DISABLE 模式的策略将被忽略，且无法进行迁移。
• 主-远端（Primary-remote）多集群配置。 仅支持多主集群配置。包含一个或多个远端集群的部署将无法正常工作。

以下是已知限制，会影响迁移期间或迁移后的行为：

• 针对 waypoint 的 EnvoyFilter 资源目前不受支持。 如果您依赖 EnvoyFilter 对 Sidecar 代理进行高级 Envoy 配置， 这些配置将无法沿用到 waypoint 上。此 API 功能可能会在未来的版本中得到支持。
• 来自 Sidecar 模式工作负载的流量会绕过 waypoint 代理。 在增量迁移过程中，如果一个 Sidecar 模式的工作负载调用了带有 waypoint 的 Ambient 模式工作负载，该流量将完全绕过 waypoint。 除非源工作负载也迁移至 Ambient 模式，否则 waypoint 上配置的 L7 策略将不会对该流量生效。
• Ingress 网关默认会绕过 waypoint；但您可以通过在 Gateway 资源上添加 istio.io/ingress-use-waypoint 标签， 将其配置为通过 waypoint 路由流量。
• 针对同一工作负载混用 VirtualService 和 HTTPRoute 是不受支持的， 且会导致未定义的行为。请在继续操作之前，确保已将每个工作负载完全迁移至使用其中一种 API。

后续步骤

请从开始之前入手，以验证您的环境并备份配置。