Istio 1.7.4 makes multicluster suffix assumptions configurable
Multicluster installation gains a configurable domain suffix, and diagnostics can fall back to exec when port forwarding is unavailable. The patch also adds an optional inbound TLS configuration change.
A multicluster installation cannot assume that every Kubernetes service name ends in the same suffix. Istio's operator installed a translation filter when multicluster mode was enabled, but its assumed target suffix did not fit every deployment. Istio 1.7.4 adds configuration for the domain suffix, making one of those hidden installation assumptions explicit.
The October 27 patch announcement describes changes since 1.7.3. Alongside multicluster configuration, it repairs endpoint removal when a remote Secret is deleted and improves access to control plane diagnostics. These changes concern how the mesh integrates with a particular cluster environment, rather than introducing a new routing model.
I find these details relevant to the cost of operating Istio across a fleet. A shared mesh configuration does not make every cluster's naming and administrative interfaces identical. Giving operators a way to express those differences reduces the need for manual edits that conflict with the installation controller.
The suffix was part of a generated filter
The feature request behind the change describes a multicluster EnvoyFilter translating *.global names into names ending in svc.cluster.local. Its author identifies two cases the default does not cover. A cluster can use another suffix, or the global name can already be directly addressable in a remote cluster through a ServiceEntry.
The suggested alternative was to disable the operator and remove the filter manually. The reporter also explains why that defeats the intended installation model. An operator manages generated resources, so removing its output by hand leaves the installation's desired state unresolved.
The patch's configurable suffix addresses the assumption named in the release notes. It does not mean arbitrary naming arrangements become equivalent or that declaring a name creates remote connectivity. The point is to let installation describe the suffix appropriate to the environment instead of embedding one value in every generated multicluster arrangement.
This is a useful distinction between application configuration and installation output. An application can refer to a service name while the generated translation depends on cluster-specific conventions. When the convention differs, the operator needs to expose the relevant choice in the configuration it owns.
Remote endpoint removal must follow credential removal
The patch also fixes deletion of a multicluster remote Secret so that remote endpoints are removed. The release note is concise, but the relationship it repairs is clear. Removing the remote configuration must update the endpoint view derived from that remote cluster.
Leaving endpoint state after its remote configuration disappears would give the mesh information inconsistent with the current installation state. The correction connects a deletion event to the derived state it should invalidate. It is separate from suffix configuration, even though both affect how multicluster endpoints are represented and reached.
Diagnostic commands have another access path
istioctl proxy-status and related commands now try both port forwarding and exec before failing to contact the control plane. The release says this restores operation in clusters that do not offer port forwarding to the control plane. A missing administrative transport should no longer be treated as the only possible way to obtain the information.
That distinction matters when interpreting a diagnostic failure. An inability to establish the tool's preferred access method does not establish that the control plane itself has failed. The fallback gives the command another route to the same diagnostic subject, within the access available in that cluster.
Revision-based istiod deployments also gain support in istioctl version. That keeps version inspection aligned with the multiple-control-plane arrangement introduced earlier. A diagnostic command needs to describe the deployment model in use, especially when an upgrade intentionally has more than one revision present. The patch separately repairs a deadlock in Pilot's syncz endpoint, addressing the reliability of the diagnostic service itself.
The optional TLS change has a precise version
The patch adds an opt-in inbound sidecar TLS configuration controlled by PILOT_SIDECAR_ENABLE_INBOUND_TLS_V2. It is disabled by default. Although the release prose calls this TLS 2.0, the 1.7.4 implementation sets a minimum of TLS 1.2 and supplies an explicit list of supported cipher suites in the relevant configuration path.
The implementation is the precise source for the protocol setting. The feature variable's name should not be interpreted as a protocol version, and the release's wording does not override the actual TLSv1_2 value. Operators considering the option need to understand both its default state and the setting it generates.
My preference is to read these patch changes at their actual integration points. Domain suffix configuration affects generated multicluster naming. Remote Secret deletion affects derived endpoints, while diagnostic fallback affects access to control plane information. The optional TLS setting changes a specific inbound configuration path and remains off unless enabled.