启用 Ambient 模式
逐个命名空间启用 Ambient 模式。这使您能够在继续操作之前对每个命名空间进行验证， 并在出现问题时回滚单个命名空间。
迁移命名空间
顺序要求
Failing to follow this sequence can result in traffic being processed by neither sidecar nor ztunnel, causing disruption in your workloads. 若未能遵循此顺序，可能导致流量既未被 Sidecar 处理， 也未被 ztunnel 处理，从而引发工作负载中断。
步骤 1：激活 waypoint
通过添加 istio.io/use-waypoint 标签，激活在上一步中部署的 waypoint。
若要为整个命名空间激活 waypoint：
$ kubectl label namespace <namespace> istio.io/use-waypoint=waypoint若仅为特定服务激活 waypoint：
$ kubectl label service <service-name> -n <namespace> istio.io/use-waypoint=waypoint验证 waypoint 是否就绪：
$ kubectl get gateway waypoint -n <namespace>READY 列应显示为 True。
步骤 2：为命名空间启用 Ambient 模式
为该命名空间添加 istio.io/dataplane-mode=ambient 标签。
这会告知 CNI 插件，该命名空间内新建及重启的 Pod 应使用 ztunnel，
而非（或同时）使用 Sidecar：
$ kubectl label namespace <namespace> istio.io/dataplane-mode=ambient验证该命名空间现已加入 Ambient 网格：
$ istioctl ztunnel-config workloads -n istio-system | grep <namespace>该命名空间下的工作负载将显示以 HBONE 作为其协议。
此时，Pod 仍保留其 Sidecar。对于同时拥有 Sidecar 和 ztunnel 的 Pod，Sidecar 具有优先权。
步骤 3：移除 Sidecar 注入
从命名空间中移除 Sidecar 注入标签：
如果您使用默认注入标签：
$ kubectl label namespace <namespace> istio-injection-如果您使用修订标签：
$ kubectl label namespace <namespace> istio.io/rev-步骤 4：重启 Pod
重启该命名空间下的工作负载。随着 Pod 重启，它们将不再包含 Sidecar 容器， 转而使用 ztunnel（若已配置，还将使用 waypoint）：
$ kubectl rollout restart deployment -n <namespace>
$ kubectl rollout status deployment -n <namespace>步骤 5：移除旧的 Sidecar 策略
请删除所有使用了包含 L7 规则的负载工作流 selector 的 AuthorizationPolicy 资源，
因为它们现已被基于 targetRefs 的等效资源所取代。
$ kubectl delete authorizationpolicy <sidecar-policy-name> -n <namespace>Also remove VirtualService and DestinationRule resources replaced by HTTPRoute:
此外，请移除已被 HTTPRoute 替换的 VirtualService 和 DestinationRule 资源：
$ kubectl delete virtualservice <name> -n <namespace>
$ kubectl delete destinationrule <name> -n <namespace>使用 selector 的 L4 AuthorizationPolicy 资源（不含 L7 规则）可安全保留，
ztunnel 能够正确地对其进行强制执行。
步骤 6：验证
验证 Pod 正在运行且不包含 Sidecar 容器：
$ kubectl get pods -n <namespace>确认 ztunnel 正在管理工作负载：
$ istioctl ztunnel-config workloads -n istio-system | grep <namespace>如果您已部署 waypoint，请通过测试您的 HTTPRoute 和 AuthorizationPolicy
资源所定义的特定行为（例如基于标头的路由、HTTP 方法限制等），
来验证 L7 策略和路由规则是否正在生效。
对每个命名空间重复此操作
针对您想要迁移的每个命名空间，重复执行迁移命名空间中的步骤。
未标记 istio.io/dataplane-mode=ambient 的命名空间将继续使用其 Sidecar，且不受影响。
回滚
每个步骤均可独立撤销。请根据您已完成的进度，执行相应的回滚操作：
| 步骤 | 回滚操作 |
|---|---|
| 完成步骤 1 后（waypoint 已激活） | kubectl label namespace <ns> istio.io/use-waypoint- |
| 完成步骤 2 后（已启用 Ambient 模式） | kubectl label namespace <ns> istio.io/dataplane-mode- |
| 完成步骤 3 后（注射已移除） | 重新添加注入标签：kubectl label namespace <ns> istio-injection=enabled |
| 完成步骤 4 后（Pod 已重启） | 重新添加注入标签，然后执行 kubectl rollout restart deployment -n <ns> |
| 完成步骤 5 后（旧策略已删除） | 运行 kubectl apply -f istio-config-backup.yaml 从备份进行恢复。 |
在执行任何涉及 Pod 重启的回滚操作后，请验证 Pod 状态是否显示为 2/2 容器 （表明 Sidecar 已被重新注入），并在继续操作前确认流量传输正常。
迁移后的可观测性变更
迁移至 Ambient 模式后，请留意遥测方面的以下变更：
指标：在 Sidecar 模式下，指标通过 reporter="source" 和 reporter="destination" 进行上报。
在 Ambient 模式下，来自 ztunnel 的指标使用 reporter="source"，
而来自 waypoint 代理的指标使用 reporter="waypoint"。
请更新所有依赖于 reporter 标签的仪表板或告警规则。
指标合并：在 Sidecar 模式下，代理代理（proxy agent）支持指标合并功能，
该功能利用标准的 prometheus.io 注解，将 Istio 指标与应用程序指标合并为一个抓取目标。
此功能在 Ambient 模式下不可用。迁移后，您必须将 Prometheus 配置为分别抓取
Istio 组件（ztunnel 和 waypoint Pod）以及您的应用程序 Pod，
将其作为独立的目标进行处理。请更新所有依赖于单一合并端点的 PodMonitor 或 ServiceMonitor 资源。
链路追踪：在 Sidecar 模式下，每一跳（hop）会生成两个 Span（一个来自源端 Sidecar， 一个来自目标端 Sidecar）。在带有 waypoint 的 Ambient 模式下， 每个 waypoint 生成一个 Span。请据此相应地更新基于追踪的 SLO。
istioctl proxy-status：此命令不显示 ztunnel 工作负载。
请改用 istioctl ztunnel-config workloads 来检查 Ambient 代理状态。
欲了解更多信息，请参阅：