Istio 1.13.4 stops expanding unrelated service hostnames

A hostname can resemble a Kubernetes Service name without belonging to the local Kubernetes domain. Istio 1.13 could confuse those cases when generating Envoy routes. The result was more serious than an unnecessary alias, because aliases from different services could collide and leave route selection dependent on which entry won.

The May 17 release of Istio 1.13.4 fixes some ServiceEntry hostnames producing nondeterministic routes. The original report supplies the mechanism and a useful reduced example. A name shaped like a Kubernetes service received local short-name expansion even when its domain suffix did not match the local cluster.

I regard deterministic configuration generation as a basic requirement for operating a mesh. For a fleet with separately maintained application and infrastructure configuration, a stable declaration should not send the same short hostname to different destinations after a control-plane restart. The difficulty here is that a convenience feature for local names expanded the set of names a service could claim.

A familiar shape triggered the wrong expansion

The report uses foo.default.svc.bar.baz as its non-local hostname, with the proxy's DNS domain set to default.svc.cluster.local. Expected generated domains contain the supplied full name and its port-qualified form. The observed result also includes shorter aliases.

Those aliases include foo, foo.default, and foo.default.svc, with port-qualified variants. They are meaningful conveniences for local Kubernetes service naming, but they were not intended consequences of this unrelated domain.

The problem is therefore not that the hostname cannot be represented in Envoy. Its full name appears in the generated output. The defect is that the generator also assigns additional names to the same service.

That creates an ambiguity when another Kubernetes Service or ServiceEntry produces the same alias. The report describes deduplication choosing a winner nondeterministically. After restarting the control plane, a request to the short name can reach a different matching service.

A route change without a source manifest change is particularly difficult to explain operationally. The declaration appears stable, while the generated representation contains competing claims to the same name. The restart exposes the ambiguity rather than creating a new intended route.

Origin metadata alone is not enough

The discussion considers checking whether the service came from a Kubernetes Service or from a ServiceEntry. That seems attractive because the erroneous example uses a ServiceEntry. However, a maintainer points out that some ServiceEntries represent Kubernetes services and should still receive expansion.

This is a useful design constraint. Resource origin and service identity are related but different facts. Declaring every ServiceEntry ineligible for expansion would fix the reported example by changing valid behaviour elsewhere.

The alternative discussed is to check the local cluster suffix in addition to the name's shape. A hostname containing a namespace and svc is insufficient evidence of membership in the local service domain. The domain relationship needs to be part of the decision.

That explains why this is a semantic routing fix instead of a sorting change. Making collision resolution deterministic could make the same wrong destination win every time. Preventing unrelated names from acquiring local aliases addresses the source of this reported collision.

The issue discussion also raises deterministic deduplication as a broader concern. The patch release's claim should remain bounded to the ServiceEntry hostname problem it names. It does not establish that every possible collision among arbitrary service registry entries has been eliminated.

The second fix repairs a diagnostic lookup

The same patch fixes istioctl experimental describe pod returning a mesh configuration lookup error. The report for that problem describes a revisioned installation whose ConfigMap has a revision-specific name. Instead of selecting that name, the command tried to read the unqualified istio ConfigMap instead.

That failure is different from a broken data-plane route. The diagnostic tool could print some information and then fail to obtain the mesh configuration needed for further analysis. A maintainer identifies the missing revision-aware lookup in the discussion.

The distinction matters when interpreting command output. An error fetching configuration is evidence that the tool could not complete its analysis. It does not prove that the cluster lacks all mesh configuration or that a particular application policy is invalid.

My preference is to keep those two patch effects separate. One corrects the generated routing state that proxies consume. The other corrects the diagnostic view used to understand an installation.

Both fixes concern assumptions about names. The route generator inferred local identity from an overly broad hostname pattern. The command assumed a default configuration name where the installation used a revision-specific one. Istio 1.13.4 repairs those specific assumptions, so existing declarations can generate the intended routes and the diagnostic command can read the configuration belonging to the selected installation.