Mixer FAQ
Why does Istio need Mixer?
Mixer provides a rich intermediation layer between the Istio components as well as Istio-based services, and the infrastructure backends used to perform access control checks and telemetry capture. This layer enables operators to have rich insights and control over service behavior without requiring changes to service binaries.
Mixer is designed as a stand-alone component, distinct from Envoy. This has numerous benefits:
Scalability. The work that Mixer and Envoy do is very different in nature, leading to different scalability requirements. Keeping the components separate enables independent component-appropriate scaling.
Resource Usage. Istio depends on being able to deploy many instances of its proxy, making it important to minimize the cost of each individual instance. Moving Mixer’s complex logic into a distinct component makes it possible for Envoy to remain svelte and agile.
Reliability. Mixer and its open-ended extensibility model represents the most complex parts of the data path processing pipeline. By hosting this functionality in Mixer rather than Envoy, it creates distinct failure domains which enables Envoy to continue operating even if Mixer fails, preventing outages.
Isolation. Mixer provides a level of insulation between Istio and the infrastructure backends. Each Envoy instance can be configured to have a very narrow scope of interaction, limiting the impact of potential attacks.
Extensibility. It was imperative to design a simple extensibility model to allow Istio to interoperate with as widest breath of backends as possible. Due to its design and language choice, Mixer is inherently easier to extend than Envoy is. The separation of concerns also makes it possible to use Istio policy and telemetry processing with different proxies, just as a mix of Envoy and NGINX.
Envoy implements sophisticated caching, batching, and prefetching, to largely mitigate the latency impact of needing to interact with Mixer on the request path.
How do I see all Mixer's configuration?
Configuration for instances, handlers, and rules is stored as Kubernetes
Custom Resources.
Configuration may be accessed by using kubectl
to query the Kubernetes
API server for the resources.
Rules
To see the list of all rules, execute the following:
$ kubectl get rules --all-namespaces
NAMESPACE NAME AGE
istio-system kubeattrgenrulerule 20h
istio-system promhttp 20h
istio-system promtcp 20h
istio-system stdiohttp 20h
istio-system stdiotcp 20h
istio-system tcpkubeattrgenrulerule 20h
To see an individual rule configuration, execute the following:
$ kubectl -n <namespace> get rules <name> -o yaml
Handlers
Handlers are defined based on Kubernetes Custom Resource Definitions for adapters.
First, identify the list of adapter kinds:
$ kubectl get crd -listio=mixer-adapter
NAME AGE
adapters.config.istio.io 20h
bypasses.config.istio.io 20h
circonuses.config.istio.io 20h
deniers.config.istio.io 20h
fluentds.config.istio.io 20h
kubernetesenvs.config.istio.io 20h
listcheckers.config.istio.io 20h
memquotas.config.istio.io 20h
noops.config.istio.io 20h
opas.config.istio.io 20h
prometheuses.config.istio.io 20h
rbacs.config.istio.io 20h
servicecontrols.config.istio.io 20h
signalfxs.config.istio.io 20h
solarwindses.config.istio.io 20h
stackdrivers.config.istio.io 20h
statsds.config.istio.io 20h
stdios.config.istio.io 20h
Then, for each adapter kind in that list, issue the following command:
$ kubectl get <adapter kind name> --all-namespaces
Output for stdios
will be similar to:
NAMESPACE NAME AGE
istio-system handler 20h
To see an individual handler configuration, execute the following:
$ kubectl -n <namespace> get <adapter kind name> <name> -o yaml
Instances
Instances are defined according to Kubernetes Custom Resource Definitions for instances.
First, identify the list of instance kinds:
$ kubectl get crd -listio=mixer-instance
NAME AGE
apikeys.config.istio.io 20h
authorizations.config.istio.io 20h
checknothings.config.istio.io 20h
edges.config.istio.io 20h
instances.config.istio.io 20h
kuberneteses.config.istio.io 20h
listentries.config.istio.io 20h
logentries.config.istio.io 20h
metrics.config.istio.io 20h
quotas.config.istio.io 20h
reportnothings.config.istio.io 20h
servicecontrolreports.config.istio.io 20h
tracespans.config.istio.io 20h
Then, for each instance kind in that list, issue the following command:
$ kubectl get <instance kind name> --all-namespaces
Output for metrics
will be similar to:
NAMESPACE NAME AGE
istio-system requestcount 20h
istio-system requestduration 20h
istio-system requestsize 20h
istio-system responsesize 20h
istio-system tcpbytereceived 20h
istio-system tcpbytesent 20h
To see an individual instance configuration, execute the following:
$ kubectl -n <namespace> get <instance kind name> <name> -o yaml
What is the full set of attribute expressions Mixer supports?
Please see the Expression Language Reference for the full set of supported attribute expressions.
Does Mixer provide any self-monitoring?
Mixer exposes a monitoring endpoint (default port: 15014
). There are a few
useful paths to investigate Mixer performance and audit
function:
/metrics
provides Prometheus metrics on the Mixer process as well as gRPC metrics related to API calls and metrics on adapter dispatch./debug/pprof
provides an endpoint for profiling data in pprof format./debug/vars
provides an endpoint exposing server metrics in JSON format.
Mixer logs can be accessed via a kubectl logs
command, as follows:
- For the
istio-policy
service:
$ kubectl -n istio-system logs -l app=policy -c mixer
- For the
istio-telemetry
service:
$ kubectl -n istio-system logs -l app=telemetry -c mixer
Mixer trace generation is controlled by command-line flags: trace_zipkin_url
, trace_jaeger_url
, and trace_log_spans
. If
any of those flag values are set, trace data will be written directly to those locations. If no tracing options are provided, Mixer
will not generate any application-level trace information.
How can I write a custom adapter for Mixer?
Learn how to implement a new adapter for Mixer by consulting the Adapter Developer’s Guide.
Why does my rule not match?
Mixer rules must be valid to be applied at runtime. That means the match conditions are well-defined expressions in the language, the attributes are declared in an attribute manifest, and rules have no dangling references to handlers and instances.
The attribute values are typically normalized before evaluating rules on
them. For example, HTTP headers have lowercase keys in request.headers
and
response.headers
attributes. An expression
request.headers["X-Forwarded-Proto"] == "http"
does not match any request
even though HTTP headers are case-insensitive. Instead, use an expression
request.headers["x-forwarded-proto"] == "http"
.