Google Cloud在2026年9月28日宣布，GKE上的集群内ISTIOD控制平面和托管ISTIOD控制平面进入弃用期，两者计划于2028年3月1日结束支持。这给现有Cloud Service Mesh环境留下了迁移窗口，但需要调整控制平面类型的集群不适合等到期限临近才处理。
官方特别区分了部署环境：Google Distributed Cloud上的集群内ISTIOD仍受支持。先识别控制平面及集群类型，是决定是否需要迁移的第一道边界，不能仅凭工作负载使用Istio sidecar就判断受影响。
本次弃用针对GKE上的两种ISTIOD形态
受影响的是运行在GKE中的in-cluster ISTIOD，以及由Google管理的managed ISTIOD控制平面。它们的生命周期和运维责任不同，但这次共享同一个支持结束日期。Google Distributed Cloud中的集群内ISTIOD不在本次停服范围内。
团队应在舰队和集群层面核对实际配置，而不是只检查命名空间里是否存在istiod组件。托管控制平面可能不会以相同方式暴露组件，历史安装方式与后续升级也可能让资源标签和当前状态不一致。
目标是现代化到TRAFFIC_DIRECTOR控制平面
对于使用managed ISTIOD的GKE集群，官方要求现代化到TRAFFIC_DIRECTOR控制平面，并继续通过Istio API管理服务网格能力。这个变化把控制平面的底层实现与应用使用的网格API进一步分离。
迁移前应核对所用Istio API、流量策略、安全策略、遥测配置和网关能力是否与目标实现兼容。API名称没有变化，不代表所有行为与扩展点都能原样迁移，特别是依赖实现细节或实验特性的环境需要单独验证。
超过支持期限可能影响工作负载通信
2028年3月1日之后，相关控制平面不再获得支持。官方还警告，仍未现代化的managed ISTIOD集群，其工作负载sidecar可能失效，并因此无法正常发送或接收流量。对承载关键服务的网格而言，这不是单纯的管理面告警。
期限较长容易让迁移被不断后移，但证书轮换、配置下发和sidecar生命周期都依赖控制面持续工作。应把迁移当作可用性项目，而不是临近停服时执行的软件升级，并在变更计划中预留应用验证和回退时间。
兼容性盘点应先于集群改造
盘点范围至少包括控制平面类型、集群版本、舰队成员关系、注入方式、代理版本、网关、授权策略、mTLS模式、流量分配规则与可观测性集成。还应找出未受版本控制的手工配置，避免新环境只恢复了声明式资源的一部分。
对每项能力建立可验证的预期，例如路由比例、故障注入、超时重试、服务身份和关键指标。完成目标环境部署后，应通过真实请求或合成流量验证这些结果，而不能只以控制台显示“已配置”作为通过标准。
新建金丝雀集群更适合渐进式切流
Google给出的迁移教程支持把工作负载迁移到启用托管Cloud Service Mesh的新GKE集群，并使用金丝雀集群策略逐步转移流量；同一集群内的金丝雀控制平面迁移并不在该教程支持范围内。生产切流应从小比例开始，观察错误率、延迟和连接稳定性后再扩大。
迁移窗口内需保留旧集群和流量回退路径，并明确DNS、负载均衡、证书和状态数据的切换顺序。只有在所有关键服务、策略和遥测均通过验证后，才应退役原ISTIOD环境，同时把完成日期安排在支持结束前留出充足缓冲。
