Explains how to configure a Mixer Aspect and its dependencies.
Mixer configuration expresses system behavior by specifying three key pieces of information: what action to take, how to take that action, and when to take that action.
What action to take: Aspect configuration defines what action to take. These actions include logging, metrics collection, list checks, quota enforcement and others. Descriptors are named and re-usable parts of the aspect configuration. For example the metrics aspect defines the MetricDescriptor and refers to the MetricDescriptor instances by name.
How to take that action: Adapter configuration defines how to take an action. The metrics adapter configuration includes details of the infrastructure backends.
When to take that action: Selectors and subjects define when to take an action. Selectors are attribute-based expressions like response.code == 200 and Subjects are hierarchical resource names like myservice.namespace.svc.cluster.local.
Consider the following aspect configuration that enables rate limits.
- aspects:
- kind: quotas
params:
quotas:
- descriptorName: RequestCount
maxAmount: 5
expiration: 1s
labels:
label1: target.service
It uses RequestCount to describe the quota. The following is an example of the RequestCount descriptor.
name: RequestCount
rate_limit: true
labels:
label1: 1 # STRING
In this example, rate_limit is true, hence the aspect must specify an expiration. Similarly, the aspect must supply one label of type string.
Mixer delegates the work of applying rate limits to an adapter that implements the quotas kind. adapters.yml defines this configuration.
- name: default
kind: quotas
impl: memQuota
params:
minDeduplicationDuration: 2s
The memQuota adapter in the above example takes one parameter. An operator may switch from memQuota to redisQuota by specifying an alternate quotas adapter.
- name: default
kind: quotas
impl: redisQuota
params:
redisServerUrl: redisHost:6379
minDeduplicationDuration: 2s
The following example shows how to use a selector to apply rate limits selectively.
- selector: source.labels["app"]=="reviews" && source.labels["version"] == "v3"
aspects:
- kind: quotas
params:
quotas:
- descriptorName: RequestCount
maxAmount: 5
expiration: 1s
labels:
label1: target.service
The steps outlined in the previous section apply to all of Mixer’s aspects. Each aspect requires specific desciptors and adapters. The following table enumerates valid combinations of the aspects, the descriptors and the adapters.
Istio uses protobufs to define configuration schemas. The Writing Configuration document explains how to express proto definitions as yaml.
Aspect configuration applies to a subject. A Subject is a resource in a hierarchy. Typically subject is the fully qualified name of a service, namespace or a cluster. An aspect configuration may apply to the subject resource and its sub-resources.
istioctl pushes configuration changes to the API server. As of the alpha release, the API server supports pushing only aspect rules.
A temporary workaround allows you to push adapters.yml and descriptors.yml as follows.
kubectl get pods -l istio=mixer
The output is similar to this:
NAME READY STATUS RESTARTS AGE
istio-mixer-2657627433-3r0nn 1/1 Running 0 2d
kubectl cp istio-mixer-2657627433-3r0nn:/etc/opt/mixer/configroot/scopes/global/adapters.yml adapters.yml
kubectl cp adapters.yml istio-mixer-2657627433-3r0nn:/etc/opt/mixer/configroot/scopes/global/adapters.yml
/etc/opt/mixer/configroot/scopes/global/descriptors.yml is similarly updated.
Mixer provides default definitions for commonly used descriptors and adapters.
Learn more about Mixer and Mixer Config.
Discover the full Attribute Vocabulary.