Google公布Cloud Service Mesh退役安排：ISTIOD控制平面支持止于2028年3月
2026年9月28日，Google Cloud公布Cloud Service Mesh两类ISTIOD控制平面的弃用安排：Google Cloud上GKE集群使用的托管ISTIOD实现，以及集群内ISTIOD控制平面，支持都将在2028年3月1日结束。Google Distributed Cloud软件版中的集群内控制平面继续按其支持范围运行，不应被一起列为本次退役对象。
配图为AI生成的概念插图，表现服务网格控制平面的渐进迁移，不是真实产品界面。
弃用已经开始，终止支持是另一个时间点
此次通知并不意味着9月28日所有现有网格立即停止工作。它给出了迁移期限和后续支持变化：受影响组件到期后不再获得更新、安全补丁或Google Cloud支持。对于尚未现代化的托管ISTIOD集群，发布记录还明确警告，期限之后工作负载sidecar会失败，无法正常收发请求。
因此，计划不能只写一个遥远的截止日期。团队应先确认自己的控制平面实现、部署平台、fleet与业务负责人，再将受影响范围列成实际清单。仅凭项目使用了“Istio API”无法判断是否受影响，迁移目标TRAFFIC_DIRECTOR仍然涉及Istio API配置，名称相似不等于实现相同。
托管路径先过兼容性检查
官方为托管控制平面提供客户主动发起和Google自动安排两条现代化路径。两者都要求先检查并修复兼容性问题，检查内容涉及Istio自定义资源、Pod注解、基础设施依赖与规模参数。自动安排也不等于所有环境无需准备：组织中未延期的fleet必须满足兼容要求，局部不兼容可能阻止整体安排。
遇到不支持的功能，官方建议改写配置为受支持的替代方式；如果业务严格依赖TRAFFIC_DIRECTOR不支持的能力，则需要评估自管开源Istio等不同方案。不能把迁移理解成单纯替换一个标识，原有配置与运行习惯都需要对照检查。
对多团队环境，本文建议先确定非生产验证顺序和关键业务的维护窗口，再选择自动或主动路径。把复杂fleet临时延期可以帮助组织分批推进，但官方明确，延期只影响自动调度，不会延长支持截止期限。
工作负载过渡与回退有自己的阶段
托管现代化过程中，两个控制平面会在维护窗口内并行，Deployments对应的工作负载和网关自动过渡；StatefulSet与DaemonSet工作负载需要手动重启。遗漏这些类型，可能造成控制平面状态变化之后，仍有业务没有完成预期切换。
官方流程还包含观察期，至少六个工作日，并在fleet最终确认前提供回退能力。一旦进入FINALIZED状态，旧Istiod组件会被移除，无法再按这套流程回退。因此，完成迁移与最终确认应是两个经过明确验收的决定，不宜只看到某个集群显示完成就立刻收尾。
验收可以围绕实际服务路径展开：服务发现、认证授权、跨服务请求、网关流量与关键告警是否符合预期。检查应覆盖成功与拒绝路径，尤其是原来依赖特殊配置的业务，让兼容性清单与应用观察共同形成证据。
集群内部署，参考的是另一条迁移路线
针对集群内控制平面，官方链接的是在新集群配置托管控制平面，再逐步迁移流量的路线。教程明确区分新集群金丝雀迁移与在同一集群并存控制平面的方式，后者不属于该文档支持的迁移路径。两类环境不能照抄同一组步骤。
新集群方式还涉及额外运行资源与短期双环境成本，预算、容量和DNS切换也应提前准备。生产流量的转移幅度应小于演示教程的粗粒度步骤，并保留明确的回退触发条件。
这次通知给出的时间窗口足以开展有序迁移，但前提是尽早把“我们是否受影响”变成具体结论。最应该马上准备的是清单、兼容性差距与演练计划；把业务验证留到最后一个维护窗口，会让原本可控的版本迁移变成紧急事故风险。
