Istio 1.8.1 restores updates to delegated routes

A routing configuration can be correct when a proxy starts and still fail to update later. Istio's delegated VirtualService bug has that shape. An operator changes weights in the delegated resource, but the sidecar retains its previous routes because the change does not trigger an xDS push. Restarting the pod produces the correct configuration, which exposes a failure in update propagation rather than the intended route definition.

The December 8 announcement of Istio 1.8.1 includes a correction for that path. It also repairs a separate 1.8.0 regression involving multiple Services with overlapping ports. Both affect the relationship between declared configuration and generated proxy behavior, but their failure mechanisms differ.

I value the ability to keep routing rules in versioned configuration. That only works operationally when changes reach the proxies already serving requests. A fresh proxy getting the right route is insufficient evidence that the running fleet converges after an edit.

Delegation creates a dependency between resources

The delegated route report supplies a concrete example. A root VirtualService in namespace foo matches a source namespace and source label, then delegates to a VirtualService named bar in namespace bar. The delegated object defines weighted destinations and a timeout.

The reporter changes the weights from 90 and 10 to 80 and 20. The sidecar for the selected source does not receive the new route state. Restarting its pod gives it the corrected configuration. Both destinations remain declared in the same delegated resource throughout that change. The original report lists Istio 1.6.11, so the issue should not be described as originating exclusively in 1.8.0.

A reduced delegation fragment shows the resource relationship. It belongs inside an appropriate HTTP route in the root VirtualService, with the remaining match and host configuration supplied separately.

delegate:
  name: bar
  namespace: bar

That reference makes the root route depend on another resource's contents. An update to the delegate must therefore be relevant to the generated route used by consumers of the root. Watching only changes to the root's own text would not capture every change to its effective configuration.

The release note identifies the repaired behavior as triggering an xDS push when the delegate changes. The issue's restart observation supports the distinction between initial configuration and change notification. It does not establish a particular internal implementation beyond what those sources describe.

A restart can reveal the class of failure

The reported restart is useful diagnostic evidence because it changes how the proxy obtains its configuration. The new instance receives state reflecting the updated resource, while the old instance had retained its previous state. That narrows the problem to maintaining the running view after a change.

This does not make restarting application pods the intended route-management mechanism. Delegation is meant to allow configuration changes through the referenced resource. The patch restores that operating model for the affected update path, without requiring a pod replacement whenever a delegated weight changes.

The implication for route inspection is specific. Seeing the desired weights in the Kubernetes object answers what the operator declared. Seeing them in the running proxy answers whether the change reached the data plane. The bug separates those observations, and its correction reconnects them for the delegated update case.

Overlapping Service ports caused another routing error

The port regression report describes two Services selecting the same pod. Both expose port 80, but one forwards to container port 8080 and the other to 8081. Under 1.8.0, calls through both Services reach the same container.

The report shows a duplicate generated cluster name, inbound|80||, and a corresponding control plane warning. Its configuration dump contains only one target address for that name. The earlier format included additional service information, and the reporter connects the collision to the changed inbound cluster naming format.

Istio 1.8.1 identifies the regression as fixed. This case differs from delegated configuration becoming stale. Here the generated representation loses a distinction between two target ports, even though the Services express that distinction. An update notification alone would not resolve a collision in the generated representation.

Patch scope distinguishes the two failures

The release also removes unnecessary downgrade warnings and stops validation of resource types Istio no longer supports. Those fixes improve management behavior, while the routing corrections affect the proxy configuration used for traffic. The announcement provides a short set of changes with identifiable operational consequences.

My preference is to diagnose the declared-to-runtime relationship at the point where it diverges. The delegated-route case needs a push when a referenced object changes. The overlapping-port case needs distinct generated configuration for distinct destinations. Istio 1.8.1 repairs both, preserving the intended route updates and the target-port differences already expressed by their respective resources.