Mixer Aspect Configuration

Explains how to configure a Mixer Aspect and its dependencies.

Overview

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.

Configuration steps

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

Aspect associations

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.

AspectDescriptorsAdapters
Quota enforcementQuotaDescriptormemQuota, redisQuota
Metrics collectionMetricDescriptorprometheus,statsd
Whitelist/BlacklistNonegenericListChecker,ipListChecker
Access logsLogEntryDescriptorstdioLogger
Application logsLogEntryDescriptorstdioLogger
Deny RequestNonedenyChecker

Istio uses protobufs to define configuration schemas. The Writing Configuration document explains how to express proto definitions as yaml.

Organization of configuration

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.

Pushing configuration

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.

  1. Find the Mixer pod FIXME
    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
    
  2. Fetch adapters.yml from Mixer
    kubectl cp istio-mixer-2657627433-3r0nn:/etc/opt/mixer/configroot/scopes/global/adapters.yml  adapters.yml
    
  3. Edit the file and push it back.
    kubectl cp adapters.yml istio-mixer-2657627433-3r0nn:/etc/opt/mixer/configroot/scopes/global/adapters.yml
    
  4. /etc/opt/mixer/configroot/scopes/global/descriptors.yml is similarly updated.

  5. View Mixer logs to see validation errors since the above operation bypasses the API server.

Default configuration

Mixer provides default definitions for commonly used descriptors and adapters.

What’s next