Cloud Service Mesh ISTIOD Support Ends on GKE

Google Cloud’s September 28 release notes deprecated the managed and in-cluster ISTIOD control planes for Cloud Service Mesh on Google Kubernetes Engine (GKE) on September 28, 2026, and set March 1, 2028, as their end-of-support date. After the cutoff, sidecars on unmodernized managed ISTIOD clusters will be unable to send or receive requests; affected in-cluster control-plane components will stop receiving Google Cloud updates, security patches and support.

The required work depends on the installation. A managed ISTIOD fleet can change to the TRAFFIC_DIRECTOR implementation on its existing GKE clusters. An in-cluster ISTIOD installation must move to managed Cloud Service Mesh on a new cluster or be uninstalled. A Cloud Parity report describes that new-cluster path and the separate status of in-cluster installations on Google Distributed Cloud software-only environments. Fleets already using TRAFFIC_DIRECTOR have no action to take under this deprecation.

Check the implementation for each GKE cluster

The Cloud Service Mesh name alone does not identify the control plane. Google’s control-plane check uses the command gcloud container fleet mesh describe --project FLEET_PROJECT_ID. Its output lists fleet memberships and, for a managed control plane, a controlPlaneManagement state and implementation. Teams need to read those values for each membership rather than treating one cluster’s result as the status of the fleet.

An ACTIVE managed control plane with implementation TRAFFIC_DIRECTOR is already on the current architecture. ACTIVE with implementation ISTIOD identifies the deprecated managed implementation and puts that cluster on the modernization path. An implementation value of UPDATING means a change is in progress; it is not evidence that modernization has finished.

If controlPlaneManagement.state is not ACTIVE, the managed-control-plane result does not establish that the cluster runs in-cluster ISTIOD. The additional check is kubectl -n istio-system get deploy istiod: an istiod deployment there identifies the in-cluster control plane. That distinction matters because the same ISTIOD name appears in both affected implementations, although their migration work is substantially different. The notice applies to these installations on GKE on Google Cloud; in-cluster Cloud Service Mesh on Google Distributed Cloud software-only installations remains supported.

Managed ISTIOD can modernize on existing clusters

Managed ISTIOD runs a dedicated control plane for a cluster, while TRAFFIC_DIRECTOR uses Google Cloud’s managed networking infrastructure. For a managed ISTIOD fleet, modernization changes the control-plane implementation without requiring the applications to move to replacement GKE clusters. Operators can initiate the transition themselves, or Google can schedule modernization for eligible fleets. Neither a scheduled rollout nor an eligibility finding means that a cluster has completed the change; the implementation must reach TRAFFIC_DIRECTOR.

Compatibility is the main qualification to that route. The destination continues to support Istio APIs, but features incompatible with TRAFFIC_DIRECTOR lose support with the retiring implementation. Teams therefore need to examine the mesh configuration and resolve blockers before the change. A fleet whose configuration still depends on an unsupported feature cannot treat the deadline as a routine control-plane switch. Removing managed Cloud Service Mesh is an alternative if modernization is not suitable.

This is an infrastructure transition with application consequences even when the cluster remains in place. Routing, security policy and proxy behavior need to work under the destination implementation, and a fleet may have memberships at different stages of the rollout. The membership-level implementation value provides a clearer completion check than the presence of familiar Istio configuration or the fact that modernization has started.

In-cluster ISTIOD needs a new GKE cluster

In-cluster ISTIOD runs customer-managed control-plane components inside the existing cluster. That installation cannot be modernized in place to managed Cloud Service Mesh. Retaining the service requires a new GKE cluster provisioned with the managed TRAFFIC_DIRECTOR control plane, with the application and compatible mesh configuration established on the destination. Simply upgrading ISTIOD in the old cluster does not change which control-plane architecture it uses.

The work is consequently a workload migration as well as a mesh change. Google’s migration tutorial illustrates an application running in both clusters while traffic moves toward the new one, followed by a DNS change for the final cutover. For a production service, the destination must be able to serve requests with the intended ingress, routing and security behavior before the old cluster is retired. The period in which both clusters operate is part of that migration, rather than a control-plane update on the original cluster.

Uninstalling Cloud Service Mesh is the other stated option for an in-cluster installation that will not move to the managed service. For applications that will remain on Cloud Service Mesh, the replacement cluster is a requirement of the supported migration path. It is the largest practical difference between the two deprecated ISTIOD implementations.

The support deadline has different consequences

Both affected control planes lose Google Cloud updates, security patches and support at the cutoff. The managed implementation carries an additional stated availability risk: workload sidecars on clusters that have not modernized will fail to exchange requests. For in-cluster installations, provisioning a destination alone does not complete the work; applications and their traffic must move to it.

The useful planning boundary is therefore the control plane recorded for each GKE membership. TRAFFIC_DIRECTOR memberships can be set aside for this notice, managed ISTIOD memberships need a compatible modernization, and in-cluster ISTIOD installations need a cluster migration or removal of Cloud Service Mesh before support ends.