Istio 1.0.5 disables a policy cache that returned invalid results

A cache in a policy service must preserve the result of the decision it replaces. Saving computation is insufficient if reuse produces a different answer. The Istio 1.0.5 release on December 20 disables the precondition cache in istio-policy because it could return invalid results. This is a correction to a performance mechanism in shared mesh infrastructure, with the release choosing to remove that reuse path.

I regard this as a necessary priority for policy infrastructure. The mesh asks applications to rely on behavior implemented outside their own processes. A policy result needs a dependable meaning before reducing its evaluation cost becomes useful. An optimization which changes that result undermines the purpose of centralizing the behavior.

The deployment selects zero cache entries

The Mixer deployment template shipped in 1.0.5 makes the change visible in the policy container's arguments. Alongside its address and configuration-store settings, the container receives this option.

args:
  - --numCheckCacheEntries=0

This is a fragment of the container configuration, not a complete replacement for the chart's argument list. The zero-entry setting expresses the removal of the server-side check-cache allocation in this deployment. It should be interpreted at the policy process where it is supplied. It is not a declaration that every cache in Envoy or every other mesh component has disappeared.

That scope matters because Istio has several kinds of repeated work. Generated proxy configuration, policy checks and telemetry processing do not share one universal cache. The release names the precondition cache in the policy service specifically. A correction there does not establish a new invalidation rule for unrelated discovery state.

The announcement does not provide the faulty cache key or a detailed sequence which produced an invalid result. Those particulars should not be invented from the fact that caching is involved. The supported conclusion is that the released policy service disables that optimization because its results were incorrect. The deployment argument provides a concrete way to identify the intended process setting.

Policy and telemetry remain separate deployments

The same chart template generates policy and telemetry Deployments from separate container definitions. Both run Mixer, but their accompanying proxies use different service-cluster names and proxy configuration templates. Policy and telemetry therefore share implementation components while retaining separate deployed roles.

Only the policy container definition in this template includes the zero-entry check-cache option. The telemetry definition retains its own address, configuration store and tracing URL settings. This is useful when inspecting generated manifests. Finding the setting in one role explains the policy-cache correction without implying identical argument changes in the other role.

Both roles communicate locally through a Unix socket volume shared with their proxy. The Mixer container listens on the socket path, and the proxy uses its role-specific configuration. This adds another distinction between the service endpoint visible to clients and the local process which evaluates or reports the request. The corrected cache configuration belongs to Mixer in that local arrangement. The chart mounts that shared socket directory into both containers.

I find the separate roles helpful for interpreting performance claims. A reduction in telemetry tracing work concerns a different process role from the policy cache being disabled. Combining both into a statement that every request becomes cheaper would conceal the actual changes. The patch removes one incorrect optimization while avoiding unnecessary work elsewhere.

Tracing work now depends on an enabled adapter

The release also changes Mixer to generate spans only when a tracespan adapter is enabled. Its stated benefit is reduced CPU overhead in normal cases. The change links creation of tracing data to the existence of a configured consumer for that data. A tracing URL in process arguments does not, by itself, mean every operation needs a generated span.

That is a different performance tradeoff from caching policy results. Avoiding work with no enabled tracing adapter does not require reusing an earlier policy decision. It removes generation which the current configuration does not request. The release can consequently reduce this overhead while separately disabling a cache whose reuse semantics are incorrect.

The third announced correction addresses a condition which could make Pilot hang. The release note does not identify its internal mechanism, so it should be treated as another control-plane fix rather than attributed to the policy cache. Pilot delivers proxy configuration, while the named cache belongs to istio-policy. Those processes have different responsibilities even though an application can depend on both.

For an installed mesh, the concrete policy change is the zero-entry cache setting in the policy container. The template preserves distinct telemetry deployment behavior and role-specific proxies. Reading those generated arguments identifies the correction's location without assuming a broader change to every policy evaluation or configuration cache in the mesh.