Istio 1.10 separates discovery scope from proxy configuration

A namespace can create work for Istio even when none of its applications use the mesh. By default, istiod watches resources throughout the cluster and processes their changes. Istio 1.10 introduces discovery selectors so mesh administrators can restrict that work to selected namespaces.

The 18 May release announcement pairs that change with revision tags, which make control-plane upgrades easier to organize. Both mechanisms introduce an explicit configuration boundary. One selects which namespaces contribute discovery data, and the other maps a stable upgrade label to a concrete control-plane revision.

I accept the cost of a mesh where common identity and traffic policy justify it. Unrelated cluster activity should not consume control-plane effort simply because the mesh happens to share the cluster. Discovery selectors provide a direct way to describe that scope.

Sidecar configuration did not eliminate upstream work

The discovery-selector explanation published on 30 April describes the earlier behavior. Istio watches namespaces, Services, Endpoints, and Pods across the cluster by default. A proxy can receive endpoint information for a Service that its application never needs.

The post's example places one mesh application in the default namespace and an unrelated service in another namespace. The unrelated endpoint appears in the mesh application's discovered configuration. With a few Services this may be inconsequential, but it becomes more work as resource counts or change rates increase.

A Sidecar resource can limit what configuration istiod sends to a particular proxy. That is useful for the proxy's configuration size, but it does not itself stop the control plane from watching and processing all the original Kubernetes resources.

The distinction is between the information istiod receives and the subset it distributes. Reducing the second does not necessarily reduce the work required for the first. Discovery selectors address that earlier part of the process.

Rapid resource turnover also matters independently of total size. The release announcement uses Spark Jobs as an example of unrelated namespace activity. A cluster need not contain a permanently enormous inventory to produce frequent updates that the mesh does not need to process.

Namespace labels define the discovery scope

The new meshConfig.discoverySelectors field is a list of Kubernetes label selectors applied to namespaces. The explanation supports simple label matches as well as set-based expressions.

This installation configuration selects namespaces carrying one explicit label:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    discoverySelectors:
      - matchLabels:
          istio-discovery: enabled

A namespace must carry istio-discovery=enabled to match this selector. The configuration does not label namespaces on its own. It defines the discovery rule that namespace metadata will satisfy or fail.

Several labels within a selector can express a conjunction, while separate selector entries support alternative matches. That distinction is useful when teams use different label conventions. A review needs to distinguish several requirements on one namespace from several acceptable ways to enter the selected set.

The feature is dynamic, according to the explanation and change notes. Administrators can configure it during installation or afterwards through mesh configuration. The selected set therefore follows the configured namespace-label relationship.

The consequence of excluding a namespace is reduced discovery processing and configuration derived from that namespace. This is an operational change to what the mesh knows. It is not merely a display filter in a diagnostic command.

Discovery selectors do not restrict istiod's authority

The explanation explicitly states that discovery selectors are not a security boundary. Istiod retains access to all namespaces even when discovery is configured to select fewer of them.

That qualification is central. A filter that tells a component what to process is not the same as an authorization rule denying it access to other data. Using selectors to reduce processing cannot establish isolation against a compromised or incorrectly operating control plane.

The feature still has practical value. It makes the administrator's intended mesh scope explicit and reduces work on irrelevant resources. It simply should not be presented as a replacement for permission design.

The distinction also prevents confusion between mesh membership, discovery, and packet enforcement. Selecting a namespace for discovery supplies information for configuration generation. It does not by itself establish every security policy an application needs.

My preference is for these boundaries to be named directly. A performance mechanism is easier to use correctly when its documentation states what authority remains unchanged. The 1.10 explanation does that explicitly for istiod.

Sidecar resources still refine the selected information

Discovery selectors and Sidecar resources can be used together. Administrators select the namespaces that istiod should process at the mesh level. Service owners can then use Sidecar configuration to narrow what individual proxies receive within that selected scope.

The explanation illustrates this with two namespaces participating in the mesh. A particular application can still restrict its proxy to the configuration associated with its own namespace and other required destinations.

This is a two-stage decision with different owners. Mesh administration defines the discovery scope for the control plane. A more local configuration can define the dependencies visible to a proxy.

Keeping both stages avoids expecting one field to answer two different questions. Istiod needs a bounded source set, and an individual application may need a smaller dependency set within it. Their scopes need not be identical.

The result is also easier to diagnose. If a destination is absent, the relevant question is whether it entered mesh discovery and then whether the proxy's configuration includes it. The mechanism provides those separate points to inspect.

Revision tags separate policy labels from deployment names

The release announcement describes a different source of repeated work during upgrades. Namespaces previously referenced concrete control-plane revisions directly. Moving them to another revision could require changing many namespace labels.

Revision tags provide an alias such as prod or canary. A namespace can use istio.io/rev=prod, while the tag points to a specific installed revision. Administrators can later associate that tag with a different revision.

This preserves the namespace's role label while changing the implementation behind it. The concrete revision still exists and still supplies the injection behavior. The tag reduces repeated namespace edits when a group should move together. Namespaces that need a separate promotion schedule can retain a different tag and move independently.

The 1.10 change notes introduce the experimental revision-tag command group. The release calls the resulting namespace labels stable because they need not embed a changing deployment name. That wording should not be expanded into a claim that every command involved has completed a separate maturity graduation.

The announcement specifically describes which revision new injection uses after a tag is reassociated. Existing proxy processes do not become different binaries merely because a namespace label now resolves differently. Injection selection and replacement of running workloads remain distinct operations.

Network behavior also changes in 1.10

The release changes how Envoy sends inbound traffic to applications. Earlier behavior redirected traffic arriving through the Pod's external interface toward loopback. In 1.10, Envoy sends it to the application on the Pod interface by default.

Applications that listen on all relevant interfaces may see little difference. Applications that deliberately bind only to localhost or only to the Pod interface can observe a meaningful change. The release announcement identifies administrative endpoints and stateful applications as examples where interface choice matters.

The precheck tool identifies localhost listeners that may be affected under diagnostic code IST0143. This supports migration by finding a concrete binding condition. It is different from asserting that every application works identically after the network change.

The relationship to the other changes is operational rather than architectural. Discovery selectors reduce irrelevant processing, revision tags organize control-plane selection, and the networking change corrects the traffic path applications observe. Each has its own configuration implications.

Explicit scope reduces unnecessary coordination

Istio 1.10 lists support for Kubernetes 1.18 through 1.21. Within that platform range, the new controls let operators express which namespaces matter to discovery and which installed revision should supply injection for a named deployment group.

Neither control removes the need to understand the underlying resources. Namespace labels still determine selector matches, Sidecar resources still constrain proxy configuration, and a revision tag still refers to a concrete control plane.

The practical improvement is that those relationships can be managed without copying every detail into every namespace decision. Mesh administrators can exclude unrelated resource activity at discovery time and keep stable namespace upgrade labels while changing the revision behind them.