Istio 1.23.3 adds exceptions to cluster-local service routing

A multicluster mesh can need a broad local-routing default with a small set of shared services. A policy that only marks more hosts local makes that arrangement difficult to express. Istio 1.23.3 adds clusterLocal host exclusions, according to its October 24 release notes. The useful change is the ability to represent an exception explicitly, rather than treating every configured host as another member of the local-only set.

The MeshConfig API at this release defines cluster-local behavior as requiring client and service endpoints to reside in the same cluster. By default, a multicluster mesh assumes service endpoints are reachable from clients across its participating clusters. A cluster-local setting narrows the endpoints visible to a client. This is a routing-scope decision, distinct from whether a particular network connection is physically possible.

I find that distinction useful at fleet scale, where a shared service name need not imply that every endpoint is interchangeable. Istio's configuration can describe the intended endpoint scope. Exceptions make a broad policy practical without requiring the administrator to enumerate every service that should retain the default.

False becomes meaningful configuration

The 1.23.3 implementation stores hostname settings in separate maps for specific names and wildcard names. The values are booleans. A configured false value is therefore retained as policy data, rather than disappearing into the absence of a local-only rule.

When classifying a host, the implementation uses MostSpecificHostMatch. If no setting matches, it returns false for cluster-local behavior. That separates three useful cases, a host selected as local, a host explicitly excluded by a matching setting, and a host with no matching policy. The first two can coexist in a broad wildcard configuration.

For example, this MeshConfig fragment makes ordinary service selection cluster-local while allowing a specific shared service to use mesh-wide endpoints:

serviceSettings:
- hosts:
  - "*"
  settings:
    clusterLocal: true
- hosts:
  - shared.catalog.svc.cluster.local
  settings:
    clusterLocal: false

The exact hostname is significant. Its more specific match supplies the exception to the wildcard. The example assumes that cluster.local is the cluster domain used by the installation. A different domain requires corresponding hostnames in the configuration. The policy selects service names, not arbitrary applications sharing an informal label.

Built-in local defaults also have exceptions

The API documents local defaults for the Kubernetes API Service and Services in kube-system. The implementation constructs those defaults using the environment's domain suffix. It also includes the discovery address among default local hosts. These defaults reflect infrastructure relationships where cluster-local behavior is useful even without an administrator defining a broad rule.

The implementation checks explicit false settings against those default hosts. A matching override can remove a default entry before the remaining defaults are added to the maps. This matters because simply inserting user configuration first would not be enough if the code later overwrote it with an unconditional local default. The construction process needs to preserve the intended exception.

This is why the release note's short phrase describes more than a convenience in YAML. The policy model has to retain the negative setting, select the correct host match and prevent defaults from silently restoring the behavior the administrator excluded. The source makes those stages visible.

The provider also registers a mesh-configuration handler and rebuilds its host settings when that configuration changes. It constructs the replacement maps before publishing them under a lock. Readers obtain the current host settings through the provider. The exclusion is consequently part of the configuration model maintained by the control plane, not a one-time transformation of the installation manifest.

I prefer that explicit rule interpretation to relying on declaration order as an informal explanation. A broad default and a specific exception are understandable when the implementation chooses the most specific host match. The resulting configuration can state which service is shared without obscuring the policy for every other service.

Endpoint scope does not create reachability

An exclusion permits endpoint selection beyond the local cluster. It does not create the underlying network path or establish application authorization. The API describes the setting in terms of endpoint visibility and the relationship between client and endpoint clusters. Those are the properties this configuration controls.

This limit matters when interpreting a successful configuration change. A service becoming eligible for mesh-wide endpoints is one step in the communication arrangement. The surrounding multicluster installation still supplies the connectivity assumed by that selection. The exclusion should not be described as an independent cross-cluster networking mechanism.

The same maintenance release adds metrics-port declarations to the Istio CNI DaemonSet and the kube-gateway container generated by the discovery chart. It also repairs cleanup of kube-virt-interfaces rules by the iptables cleanup tool. Those are separate deployment and lifecycle fixes. For multicluster routing, the substantive addition is a policy representation that can preserve a local default while expressing particular hosts whose endpoints remain shared.