Istio 1.28.3 fixes ambient controller lifecycle failures

Istio 1.28.3 fixes a goroutine memory leak in ambient mode and an ambient multicluster failure that could require restarting istiod. It also adds a gateway chart setting for Service selectors during revision-based migration. These are changes to the behavior of a running mesh during replacement and recovery, which deserves more attention than a short patch announcement usually receives.

My view of Istio is qualified. After five years with it, I value workload identity and uniformly configured traffic policy, but I regard the additional distributed system as a real operating cost. The trade is worthwhile when a fleet needs those capabilities. Fixes that remove hidden lifecycle dependencies are relevant to that cost because they affect how much diagnosis an operator needs after ordinary configuration changes.

Stopping an index must stop its informers

The ambient goroutine leak report identifies delayed informers created without explicit startup calls binding them to their parent's stop channel. When the ambient index stopped, the affected informers continued running. The report also identifies a multicluster local-cluster runner that lacked the parent's stop channel.

This gives the memory-leak description a specific mechanism. The issue concerns work that outlives the component responsible for it. It does not describe an application allocating too much memory or a workload's traffic policy retaining requests. That distinction determines which process observations are relevant to validating the patch.

The report names authorization and gateway-related informers among the affected resources. A leak report does not itself demonstrate incorrect authorization decisions. The documented problem is the lifecycle of the background work. A security-policy resource appearing in the list of watched objects does not establish a policy bypass.

A validation exercise should reproduce the relevant index lifecycle in a controlled environment and inspect whether background work and memory settle after cleanup. A short steady-state traffic check would not exercise that transition. The acceptance criterion should correspond to the reported stop behavior, with the old reproduction and the patched result recorded together.

The issue also notes that a cleanup test was skipped because of other goroutine leaks. The scope of a regression test therefore needs inspection before anyone claims comprehensive leak coverage. One corrected lifecycle path does not establish that every source of long-lived work in the process has been eliminated.

Remote-cluster recovery should not require a restart

The release notes describe an ambient multicluster informer failure that persisted until an istiod restart. The linked remote-secret reconciliation report supplies a concrete example. A remote secret initially named an unsuitable server address. Updating the secret left the control plane trying the old endpoint, and the reporter needed a restart before the correction took effect.

That fix needs a transition test. Start with the invalid connection information, confirm the expected failure, and then correct the declared secret. The useful result is recovery from the updated configuration without restarting istiod. Beginning with a valid secret and observing a healthy connection would not establish that the reported failure has changed.

The test needs to identify the remote cluster and the changed configuration. Otherwise a healthy connection elsewhere in a multicluster mesh could obscure a still-failing informer. Diagnostic evidence should stay scoped to the affected path and verify the control plane's return to ordinary operation after the correction.

This is consistent with what I want from a controller-managed system. A corrected resource should give the controller enough information to recover. Requiring a process restart adds an operational step whose necessity may not be apparent from the resource state. The patch is useful because the release explicitly addresses that persistent failure mode.

Gateway selection is part of revision migration

The gateway Helm chart gains service.selectorLabels for custom Service selector labels during revision-based migrations. Reviewing that setting requires the generated Service and the intended gateway workload labels. The configuration needs to express which gateway instances should receive traffic during the migration.

A selector override needs a specific migration requirement. The change is useful when the migration plan needs custom selection. The review should explain the desired population before and after a revision transition, then verify that the resulting configuration selects that population. That supplies an acceptance criterion independent of the chart field's name.

The patch also lists a fix involving crashing NFT operations and pod deletion failures. Installations using that path need an upgrade assessment based on a reproduction of the failure. A patch release can contain several unrelated corrections, and the validation plan should identify which of them the installation actually exercises.

Adoption should include tests of cleanup and failed-then-corrected configuration alongside the normal readiness checks. Those are the transitions the January release makes more reliable. The upgrade record should show that the corrected secret takes effect and that stopping the relevant ambient work no longer leaves the reported background activity behind.