代管式控制平面

本文档介绍了已弃用的 ISTIOD 控制平面实现与 Google 的新式 TRAFFIC_DIRECTOR 控制平面实现之间的架构差异，并概述了如果您的集群仍在使用已弃用的控制平面，您接下来需要执行的步骤。

控制平面概览

在服务网格中，控制平面提供流量管理、Envoy 代理使用时的代理管理以及其他网络功能。

在 GKE 集群上使用 Istio API 的 Cloud Service Mesh 提供完全受支持的 Istio API 实现。 这些 API 由全代管式且与 Cloud Networking 集成的 TRAFFIC_DIRECTOR 控制平面实现和支持。之前，还支持另外两种控制平面实现：

  • 已弃用的托管式 ISTIOD 实现，该实现运行单集群专用控制平面。
  • 已弃用的集群内 ISTIOD 实现，可在集群内运行客户管理的控制平面组件。

TRAFFIC_DIRECTOR 控制平面的运行特征

使用 TRAFFIC_DIRECTOR 控制平面的 Cloud Service Mesh 使用 Google Cloud的托管式网络基础架构，而不是每个集群的控制平面实例。

发送到 Envoy Sidecar 的 Istio API (CRD) 和 xDS 配置仍然兼容，但您应该会遇到以下运行特征：

  • 政策和服务配置传播：当您创建新服务或更新路由和安全政策时，系统会在配置对边车生效之前验证配置并将其传播到 Google Cloud 系统。因此，与集群内或 ISTIOD 控制平面相比，初始政策和服务传播所需的时间更长。如需查看有关优化部署工作流的指导信息，请参阅配置传播。
  • Pod 伸缩和端点更新：工作负载端点（例如通过 Pod 横向自动伸缩创建的新 Pod 或使用新 IP 地址重启的 Pod）的更改由控制平面直接传播，不会产生与政策更新相关的延迟时间。提取现有配置的现有 Pod 会立即启动。
  • 多集群端点发现：在多集群网格中，集群通过 Google Cloud 直接共享其端点，而不是在每个集群组合之间以点对点方式同步端点。这样可确保随着网格规模的扩大，跨集群端点状态能够更快、更一致地收敛。

这对您有何影响？

后续步骤取决于您的集群使用的 Cloud Service Mesh 控制平面实现：

对采用 ISTIOD 实现的托管式 Cloud Service Mesh 进行控制平面现代化改造

所有运行已弃用的 ISTIOD 实现的受管理舰队都必须在弃用通知中指定的支持结束期限之前完成向 TRAFFIC_DIRECTOR 实现的现代化改造。 您可以使用客户触发的现代化改造（建议用于按集群控制和分阶段转移流量）或 Google 驱动的现代化改造（为符合条件的舰队自动推出）。

如需查看分步说明，请参阅托管式控制平面现代化改造。

检查控制平面兼容性

如需在现代化改造之前评估您的舰队是否支持相关功能并确定配置阻碍因素，请参阅：

附录：控制平面发布和弃用时间表

从 ISTIOD 控制平面过渡到受管理的 TRAFFIC_DIRECTOR 控制平面实现遵循了以下时间表：

  • 2024 年 5 月 23 日：Anthos Service Mesh 和 Traffic Director 已合并为 Cloud Service Mesh，并推出了 TRAFFIC_DIRECTOR 控制平面实现，用于支持 Istio API。
  • 2024 年 7 月 1 日：加入托管式 Cloud Service Mesh 的新舰队开始默认接收 TRAFFIC_DIRECTOR 实现。
  • 2024 年 9 月 8 日：面向新车队的 ISTIOD 实现的配置已结束（许可名单中的特定组织暂时不受此限制）。
  • 2026 年 9 月 28 日：正式宣布弃用 GKE 上的托管 ISTIOD 控制平面实现和集群内控制平面。