Managed control plane
This document explains the architectural differences between the deprecated
ISTIOD control plane implementation and Google's modern TRAFFIC_DIRECTOR
control plane implementation, and outlines your next steps if your clusters
still use a deprecated control plane.
Control plane overview
In service meshes, the control plane provides traffic management, proxy management when the Envoy proxy is in use, and other networking capabilities.
Cloud Service Mesh using Istio APIs on GKE clusters provides
a fully supported implementation of the Istio APIs.
The APIs are implemented and supported by the fully managed and Cloud Networking
integrated TRAFFIC_DIRECTOR control plane. Previously, two additional control
plane implementations were supported:
- The deprecated managed
ISTIODimplementation, which runs a single-cluster dedicated control plane. - The deprecated in-cluster
ISTIODimplementation, which runs customer-managed control plane components inside your cluster.
Operational characteristics of the TRAFFIC_DIRECTOR control plane
Cloud Service Mesh with the TRAFFIC_DIRECTOR control plane uses Google Cloud's
managed networking infrastructure rather than per-cluster control plane instances.
The Istio APIs (CRDs) and the xDS configuration sent to Envoy sidecars remain compatible, but you should expect the following operational characteristics:
- Policy and service configuration propagation: When you create new
services or update routing and security policies, configuration is validated
and propagated across Google Cloud systems before taking effect on sidecars.
As a result, initial policy and service propagation takes longer than with
in-cluster or
ISTIODcontrol planes. For guidance on optimizing deployment workflows, see Configuration propagation. - Pod scaling and endpoint updates: Changes to workload endpoints—such as new Pods created by horizontal Pod autoscaling or Pods restarting with new IP addresses—are propagated directly by the control plane without the latency associated with policy updates. Existing Pods fetching existing configuration start without delay.
- Multi-cluster endpoint discovery: In multi-cluster meshes, clusters share their endpoints directly through Google Cloud rather than synchronizing them point-to-point between each combination of clusters. This ensures cross-cluster endpoint state converges more quickly and consistently as your mesh scales.
How does this affect you?
Your next steps depend on which Cloud Service Mesh control plane implementation your clusters use:
- Managed control plane (
TRAFFIC_DIRECTORimplementation):- You are already using the current, globally scalable architecture (whether configured using Istio APIs, Gateway API, or Google Cloud APIs).
- No action is required.
- Managed control plane (
ISTIODimplementation):- This implementation is deprecated.
- You must take action to inspect your fleet for compatibility blockers, update your configuration, and complete managed control plane modernization, or uninstall managed Cloud Service Mesh.
- In-cluster control plane:
- The in-cluster control plane on GKE is deprecated.
- In-cluster installations cannot be modernized in-place. You must take action to migrate from in-cluster to the managed control plane on a new cluster or uninstall Cloud Service Mesh.
Control plane modernization for managed Cloud Service Mesh with the ISTIOD implementation
All managed fleets running the deprecated ISTIOD implementation must complete
modernization to the TRAFFIC_DIRECTOR implementation before the end-of-support
deadline specified in the deprecation notice.
You can modernize your fleet using either customer-triggered modernization
(recommended for per-cluster control and staged traffic shifting) or
Google-driven modernization (automated rollouts for eligible fleets).
For step-by-step instructions, see Managed control plane modernization.
Check control plane compatibility
To evaluate your fleet against supported features and identify configuration blockers before modernization, see:
Appendix: Control plane rollout and deprecation timeline
The transition from ISTIOD control planes to the managed
TRAFFIC_DIRECTOR control plane implementation has followed this timeline:
- May 23, 2024: Anthos Service
Mesh and Traffic Director converged into Cloud Service Mesh,
introducing the
TRAFFIC_DIRECTORcontrol plane implementation for Istio APIs. - July 1, 2024: New fleets
onboarded to managed Cloud Service Mesh began receiving the
TRAFFIC_DIRECTORimplementation by default. - September 8, 2024: Provisioning of the
ISTIODimplementation for new fleets ended for general availability (with temporary exceptions for specific organizations in an allowlist). - September 28, 2026: Formal
deprecation announced for both the managed
ISTIODcontrol plane implementation and the in-cluster control plane on GKE.