Cloud Service Mesh retires ISTIOD: plan a boundary migration

“We use a managed service” does not tell us which implementation is actually running. The product name can stay the same while the mechanism controlling traffic changes underneath it. Open the inventory before opening the migration calendar.

Confirmed facts and scope

Event date: 28 September 2026. Google announced deprecation of Cloud Service Mesh ISTIOD control planes on GKE on Google Cloud, both in-cluster and managed. Support ends on 1 March 2028. For the managed implementation, the announcement also warns that sidecars on unmodernized clusters will lose communication after that date. The stated exception is continued in-cluster support on Google Distributed Cloud (software only).

This does not announce the end of Istio itself. The target Cloud Service Mesh implementation uses TRAFFIC_DIRECTOR and Istio APIs. Matching resource names do not establish that the features you use are compatible.

Two different paths

The documentation also identifies field-level differences for ServiceEntry and Sidecar. Fleet compatibility reporting includes MODERNIZATION_COMPATIBLE; results may take up to a day to update after changes. A newly enabled check is not an instant answer.

Interpretation: configuration compatibility is the first piece of evidence

ArchitectMentor interpretation: a positive vendor compatibility check is necessary, but it cannot replace testing our service. The checker does not know every business rule or what users consider a correct outcome. “Configuration accepted” and “the process works” are different statements.

Fictional educational example: an application accepts an order and then calls an external service through mesh rules. We are not assuming incompatibility or claiming an outage. The question is: which test would detect a routing or access-policy change before it reaches a user?

An evidence package, not just a deadline

1. Identify the actual implementation. For each fleet and cluster, record the control plane, version, features in use and owner. An inventory entry saying “Cloud Service Mesh” is too vague to select a procedure.
2. Map dependencies. Link each important routing and access rule to an application call. Record differences from the target implementation and how you will resolve them.
3. Prepare two kinds of test. Positive: an allowed call returns the right outcome. Negative: a disallowed client is still rejected. Testing only that “everything responds” can miss the disappearance of an access restriction.
4. Include difficult conditions. Test workload restart, dependency unavailability and process-relevant time limits. Observe errors and latency across the complete path, not just Pod readiness.
5. Define when to stop. Before changing anything, name measurable stop conditions, the decision owner and the reversal mechanism available in the chosen procedure. Do not assume reversal remains possible at every stage.

This is a proposed verification plan, not a report of executed tests or a complete migration runbook. Adapt it to the service topology, scale and requirements. Use the current vendor procedure; this article does not replace its prerequisites.

A decision worth recording

If required features are supported, select the appropriate path and plan a controlled transition before support ends. If they are not, compare configuration changes with operating OSS Istio or removing the mesh. Google’s documentation also identifies those alternatives. Running it yourself brings responsibility for updates and operations; it is not a free shortcut.

Record the starting implementation, required features, selected path, risk owner and acceptance evidence in an ADR. A deadline in 2028 gives time to prepare. It does not guarantee that every team will be ready.

Learn: choose the scope of a change-impact analysis → · Record the decision in an ADR →

Complete Weekly edition