Istio: Up and Running

Chapter 9. Mixer and Policies in the Mesh

Of the various ways in which you can use Mixer, we can divide its responsibilities into two categories: telemetry and policy enforcement. As you look at the APIs that Mixer exposes, these areas of responsibilities become more concretely obvious in that Mixer has two main APIs: check (for precondition tests) and report (for collecting telemetry). Reflecting these two areas of focus is the fact that by default Istio deployments have two Mixer pods running in the control plane—one Mixer pod for telemetry and another for policy enforcement.

Given its role as an aggregation point for telemetry, Mixer is often described as an attribute-processing engine because it ingests telemetric attributes from service proxies and transforms and funnels them to external systems (through adapters). Considering its role as a policy evaluator, Mixer is also described as a (second level) cache in that it responds to requests to check on traffic policy and caches evaluation results. Mixer ingests different configurations from different sources and mingles them together.

Architecture

Residing in the control plane, Mixer liaises between the data plane and the management plane. Contrary to how Mixer appears in Figure 9-1, it is not one single point of failure, because Istio’s default configuration includes a set of pod replicas for HA (a HorizontalPodAutoscaler). Mixer is a stateless component, using caching and buffering techniques along with a hardened design ...