Istio 1.0.1 adds limited merging for destination configuration

Splitting a service's configuration across files does not establish how conflicting declarations should combine. The Istio 1.0.1 release on August 29 adds limited support for merging VirtualService and DestinationRule definitions for the same host. It also improves Pilot scalability and Envoy startup time. The destination-rule merging code provides a concrete example of the configuration work performed before Pilot generates proxy settings.

I regard the qualification about limited merging as useful. Shared traffic policy can become difficult to understand when several declarations target one service. A merge operation needs defined behavior for duplicate names and conflicting defaults. Without that behavior, splitting a configuration merely moves ambiguity from one file into the control plane.

Pilot combines rules after resolving the host

The 1.0.1 destination-rule implementation sorts configuration objects by creation time before combining them. A source comment explains that the first top-level traffic policy takes precedence when several rules provide one. The algorithm is therefore not an unrestricted field-by-field merge of every policy declaration.

Each rule's host is resolved from its short name to a fully qualified name using the configuration's metadata. Pilot groups rules by that resolved host. This makes the host's interpreted identity part of the merge operation. Two strings which look similar in separate files need to resolve to the same destination before this code treats them as one group.

For the first rule encountered for a host, the code stores the configuration and records its subset names. When another rule resolves to the same host, Pilot adds subsets whose names have not already appeared. A subset's name is the key used to decide whether it contributes another named destination version. The code does not merge duplicate subset bodies into a new combined definition.

This permits separate declarations to contribute different subsets for one service. It does not make two independently authored definitions of the same subset harmless. Routing still identifies a subset by name, so the control plane needs a single interpretation of that name's workload membership and policy.

Duplicate subsets become diagnostic state

When a later rule repeats a subset name, the implementation records a DuplicatedSubsets diagnostic for the host. It leaves that duplicate out of the appended subset list. The result contains the subset already recorded, rather than both conflicting definitions. An operator therefore needs to consider the diagnostic when explaining why one declaration did not contribute the expected subset.

The source also handles top-level traffic policy conservatively. If the combined rule has none and an incoming rule supplies one, that policy can populate the combined rule. Once a top-level policy exists, subsequent declarations do not replace it through this path. The sorting step and first-policy rule are consequently relevant to understanding the final configuration.

Creation order is an awkward dependency for configuration authors because it is less visible than the fields in a file. The implementation nevertheless makes it part of the conflict behavior. Two rule sets containing similar policy bodies can yield different selected defaults if their creation history differs. Keeping conflicting defaults out of separate same-host declarations avoids making that history determine the intended service policy.

The combined result supplies subset membership

After combining rules, Pilot sorts its host list and stores the map for later lookup. Destination lookup uses the most specific host match. Subset lookup then finds the named subset within the selected rule and returns its labels. The merge therefore affects the workload selection used by later configuration generation, not just the appearance of an administrative listing. An empty subset name returns no subset labels, and a missing destination rule likewise leaves no named membership for that lookup.

A route which names a subset depends on that lookup returning the intended labels. If another declaration already claimed the subset name, appending another body does not create a second independently addressable version. The diagnostic and combined list explain the effective membership. A valid resource submission alone does not establish that every submitted subset body became part of the result.

I find the source helpful for setting the scope of this patch. It adds a specific form of composition, with host resolution and subset deduplication, while retaining one selected top-level policy. Those are useful mechanics for shared service configuration. They also leave a clear reason to keep default policy ownership deliberate rather than distributing conflicting defaults among unrelated files.

The release's performance improvements accompany this configuration work without supplying a universal numerical speedup. Its installation changes also enable standalone Pilot and standalone gateways, allowing users to select traffic management without every mesh component. In either installation shape, the combined destination configuration remains an input to what Pilot generates for the proxies serving that traffic.