mirror of https://github.com/istio/istio.io.git
96 lines
34 KiB
HTML
96 lines
34 KiB
HTML
<!DOCTYPE html><html lang="en" itemscope itemtype="https://schema.org/WebPage" style="overflow-y: scroll;"><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="title" content="Mixer Configuration"><meta name="og:title" content="Mixer Configuration"><meta name="og:image" content="/v0.1/img/logo.png"/><meta name="description" content="An overview of the key concepts used to configure Mixer."><meta name="og:description" content="An overview of the key concepts used to configure Mixer."><title>Istioldie 0.1 / Mixer Configuration</title><script> window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date; ga('create', 'UA-98480406-2', 'auto'); ga('send', 'pageview'); </script> <script async src='https://www.google-analytics.com/analytics.js'></script><link href='https://fonts.googleapis.com/css?family=Roboto:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic' rel='stylesheet' type='text/css'><link rel="alternate" type="application/rss+xml" title="Istio Blog RSS" href="/v0.1/feed.xml"><link rel="apple-touch-icon" href="/v0.1/favicons/apple-touch-icon.png" sizes="180x180"><link rel="icon" type="image/png" href="/v0.1/favicons/android-chrome-96x96.png" sizes="96x96" ><link rel="icon" type="image/png" href="/v0.1/favicons/favicon-32x32.png" sizes="32x32"><link rel="icon" type="image/png" href="/v0.1/favicons/favicon-16x16.png" sizes="16x16"><link rel="manifest" href="/v0.1/favicons/manifest.json"><link rel="mask-icon" href="/v0.1/favicons/safari-pinned-tab.svg" color="#2DA6B0"><meta name="msapplication-TileColor" content="#ffffff"><meta name="msapplication-TileImage" content="/v0.1/favicons/mstile-150x150.png"><link href="//maxcdn.bootstrapcdn.com/bootstrap/3.3.1/css/bootstrap.min.css" rel="stylesheet"><link rel="stylesheet" href="/v0.1/css/all.css"><link rel="stylesheet" href="/v0.1/css/prism.css"><link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.4.0/css/font-awesome.min.css"> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script></head><body class="language-unknown"><div class="nav-hero-container" style="z-index: 200000;"><nav id="header-nav" class="navbar navbar-inverse" role="navigation"><div class="container"><div class="row"><div class="col-md-11 nofloat center-block "><div class="navbar-header"> <button type="button" class="hamburger navbar-toggle collapsed" data-toggle="collapse" data-target="#navbar-collapse-1" aria-expanded="false"> <span class="sr-only">Toggle navigation</span> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </button> <a class="navbar-brand" href="/v0.1/"><div> <img src="/v0.1/img/logo.png" alt="Istio" width="36px" height="54px"/> <span class="brand-name">Istioldie 0.1</span></div></a></div><div class="collapse navbar-collapse" id="navbar-collapse-1"><ul class="nav navbar-nav navbar-right"><li><a href="/v0.1/about/" >About</a></li><li><a href="/v0.1/docs/" class='current'>Docs</a></li><li><a href="/v0.1/blog/" >Blog</a></li><li><a href="/v0.1/community/" >Community</a></li><li><a href="/v0.1/faq/" >FAQ</a></li><li class="dropdown"> <a class="dropdown-toggle" data-toggle="dropdown" href=""> <i class='fa fa-lg fa-cog'></i> <span class="caret"></span> </a><ul class="dropdown-menu"><h6 class="dropdown-header">Other versions of this site</h6><li> <a href="https://istio.io">Current Release</a></li><li> <a href="https://preliminary.istio.io">Next Release</a></li><li> <a href="https://archive.istio.io">Older Releases</a></li></ul></li><li><form name="cse" id="searchbox_demo" class="navbar-form navbar-right" role="search"> <input type="hidden" name="cx" value="013699703217164175118:iwwf17ikgf4" /> <input type="hidden" name="ie" value="utf-8" /> <input type="hidden" name="hl" value="en" /><div class="form-group"><div class="input-group"> <input name="q" class="form-control" type="text" size="30" /><div class="input-group-addon"> <span class="btn-search glyphicon glyphicon-search"></span></div></div></div></form> <script type="text/javascript" src="https://www.google.com/cse/brand?form=searchbox_demo"></script></li></ul></div></div></div></div></nav></div><div class="container"><div class="row"><div class="col-md-11 nofloat center-block" style="margin-top: 3px;"><ul class="col-sm-10 nav nav-tabs"><li role="presentation" ><a href="/v0.1/docs/index.html">Welcome</a></li><li role="presentation" class='active'><a href="/v0.1/docs/concepts/index.html">Concepts</a></li><li role="presentation" ><a href="/v0.1/docs/tasks/index.html">Tasks</a></li><li role="presentation" ><a href="/v0.1/docs/samples/index.html">Samples</a></li><li role="presentation" ><a href="/v0.1/docs/reference/index.html">Reference</a></li></ul></div></div></div><script src="/v0.1/js/navtree.js"></script><div class="container docs"><div class="row"><div class="col-md-11 nofloat center-block"><div class="row"><div id="sidebar-container" class="col-sm-3"><ul class="doc-side-nav"><li><h5 class='doc-side-nav-title'>Concepts</h5></li><script type="text/javascript"> var docs = []; docs.push({path: [ "index.md", ], url: "/docs/concepts/index.html", title: "Concepts", order: 10, overview: "Concepts help you learn about the different parts of the Istio system and the abstractions it uses."}); docs.push({path: [ "network-and-auth", "auth.md", ], url: "/docs/concepts/network-and-auth/auth.html", title: "Auth", order: 10, overview: "Architectural deep-dive into the design of Auth, which provides the secure communication channel and strong identity for Istio."}); docs.push({path: [ "network-and-auth", "index.md", ], url: "/docs/concepts/network-and-auth/index.html", title: "Network and Auth", order: 30, overview: "Introduces core network and authentication functionality."}); docs.push({path: [ "policy-and-control", "attributes.md", ], url: "/docs/concepts/policy-and-control/attributes.html", title: "Attributes", order: 10, overview: "Explains the important notion of attributes, which is a central mechanism for how policies and control are applied to services within the mesh."}); docs.push({path: [ "policy-and-control", "index.md", ], url: "/docs/concepts/policy-and-control/index.html", title: "Policies and Control", order: 40, overview: "Introduces the policy control mechanisms."}); docs.push({path: [ "policy-and-control", "mixer-aspect-config.md", ], url: "/docs/concepts/policy-and-control/mixer-aspect-config.html", title: "Mixer Aspect Configuration", order: 38, overview: "Explains how to configure a Mixer Aspect and its dependencies."}); docs.push({path: [ "policy-and-control", "mixer-config.md", ], url: "/docs/concepts/policy-and-control/mixer-config.html", title: "Mixer Configuration", order: 30, overview: "An overview of the key concepts used to configure Mixer."}); docs.push({path: [ "policy-and-control", "mixer.md", ], url: "/docs/concepts/policy-and-control/mixer.html", title: "Mixer", order: 20, overview: "Architectural deep-dive into the design of Mixer, which provides the policy and control mechanisms within the service mesh."}); docs.push({path: [ "traffic-management", "fault-injection.md", ], url: "/docs/concepts/traffic-management/fault-injection.html", title: "Fault Injection", order: 40, overview: "Introduces the idea of systematic fault injection that can be used to uncover conflicting failure recovery policies across services."}); docs.push({path: [ "traffic-management", "handling-failures.md", ], url: "/docs/concepts/traffic-management/handling-failures.html", title: "Handling Failures", order: 30, overview: "An overview of failure recovery capabilities in Envoy that can be leveraged by unmodified applications to improve robustness and prevent cascading failures."}); docs.push({path: [ "traffic-management", "index.md", ], url: "/docs/concepts/traffic-management/index.html", title: "Traffic Management", order: 20, overview: "Describes the various Istio features focused on traffic routing and control."}); docs.push({path: [ "traffic-management", "load-balancing.md", ], url: "/docs/concepts/traffic-management/load-balancing.html", title: "Discovery & Load Balancing", order: 25, overview: "Describes how traffic is load balanced across instances of a service in the mesh."}); docs.push({path: [ "traffic-management", "overview.md", ], url: "/docs/concepts/traffic-management/overview.html", title: "Overview", order: 0, overview: "Provides a conceptual overview of traffic management in Istio and the features it enables."}); docs.push({path: [ "traffic-management", "pilot.md", ], url: "/docs/concepts/traffic-management/pilot.html", title: "Pilot", order: 10, overview: "Introduces Pilot, the component responsible for managing a distributed deployment of Envoy proxies in the service mesh."}); docs.push({path: [ "traffic-management", "request-routing.md", ], url: "/docs/concepts/traffic-management/request-routing.html", title: "Request Routing", order: 20, overview: "Describes how requests are routed between services in an Istio service mesh."}); docs.push({path: [ "traffic-management", "rules-configuration.md", ], url: "/docs/concepts/traffic-management/rules-configuration.html", title: "Rules Configuration", order: 50, overview: "Provides a high-level overview of the domain-specific language used by Istio to configure traffic management rules in the service mesh."}); docs.push({path: [ "what-is-istio", "goals.md", ], url: "/docs/concepts/what-is-istio/goals.html", title: "Design Goals", order: 20, overview: "Describes the core principles that Istio's design adheres to."}); docs.push({path: [ "what-is-istio", "index.md", ], url: "/docs/concepts/what-is-istio/index.html", title: "What is Istio?", order: 10, overview: "A broad overview of the Istio system."}); docs.push({path: [ "what-is-istio", "overview.md", ], url: "/docs/concepts/what-is-istio/overview.html", title: "Overview", order: 15, overview: "Provides a conceptual introduction to Istio, including the problems it solves and its high-level architecture."}); genNavBarTree(docs) </script></ul></div><div id="tab-container" class="col-xs-1 tab-neg-margin pull-left"> <a id="sidebar-tab" class="glyphicon glyphicon-chevron-left" href="javascript:void 0;"></a></div><div id="content-container" class="thin-left-border col-sm-9 markdown"><div id="toc" class="toc"></div><div id="doc-content"><h1>Mixer Configuration</h1><p>This page describes Mixer’s configuration model.</p><h2 id="background">Background</h2><p>Istio is a sophisticated system with hundreds of independent features. An Istio deployment can be a sprawling affair potentially involving dozens of services, with a swarm of Envoy proxies and Mixer instances to support them. In large deployments, many different operators, each with different scopes and areas of responsibility, may be involved in managing the overall deployment.</p><p>Mixer’s configuration model makes it possible to exploit all of its capabilities and flexibility, while remaining relatively simple to use. The model’s scoping features enable large support organizations to collectively manage complex deployments with ease. Some of the model’s key features include:</p><ul><li><p><strong>Designed for Operators</strong>. Service operators control all operational and policy aspects of a Mixer deployment by manipulating configuration records.</p></li><li><p><strong>Scoped</strong>. Configuration is described hierarchically, enabling both coarse global control as well as fine-grained local control.</p></li><li><p><strong>Flexible</strong>. The configuration model is built around Istio’s <a href="./attributes.html">attributes</a>, enabling operators unprecedented control over the policies used and telemetry produced within a deployment.</p></li><li><p><strong>Robust</strong>. The configuration model is designed to provide maximum static correctness guarantees to help reduce the potential for bad configuration changes leading to service outages.</p></li><li><p><strong>Extensible</strong>. The model is designed to support Istio’s overall extensibility story. New or custom <a href="./mixer.html#adapters">adapters</a> can be added to Istio and be fully manipulated using the same general mechanisms as existing adapters.</p></li></ul><h2 id="concepts">Concepts</h2><p>Mixer is an attribute processing machine. Requests arrive at Mixer with a set of <a href="./attributes.html"><em>attributes</em></a>, and based on these attributes, Mixer generates calls to a variety of infrastructure backends. The set of attributes determines which backend Mixer calls for a given request and what parameters each is given. In order to hide the details of individual backends, Mixer uses modules known as <a href="./mixer.html#adapters"><em>adapters</em></a>.</p><figure><img src="./img/mixer-config/machine.svg" alt="Attribute Machine" title="Attribute Machine" /><figcaption>Attribute Machine</figcaption></figure><p>Mixer’s configuration has two central responsibilities:</p><ul><li>Describe which adapters are being used and how they operate.</li><li>Describe how to map request attributes into adapter parameters.</li></ul><p>Configuration is expressed using a YAML format built around five core abstractions:</p><table><thead><tr><th>Concept</th><th>Description</th></tr></thead><tbody><tr><td><a href="#adapters">Adapters</a></td><td>Low-level operationally-focused configuration for individual mixer adapters.</td></tr><tr><td><a href="#aspects">Aspects</a></td><td>High-level intent-focused configuration for individual mixer adapters.</td></tr><tr><td><a href="#descriptors">Descriptors</a></td><td>Description of parameters used with individual aspects.</td></tr><tr><td><a href="#scopes">Scopes</a></td><td>Mechanism to select which aspects and descriptors to use based on a request’s attributes.</td></tr><tr><td><a href="#manifests">Manifests</a></td><td>Description of various static characteristics of an Istio deployment.</td></tr></tbody></table><p>The following sections explain these concepts in detail.</p><h3 id="adapters">Adapters</h3><p><a href="./mixer.html#adapters">Adapters</a> are the foundational work horses that the Istio mixer is built around. Adapters encapsulate the logic necessary to interface Mixer with specific external infrastructure backends such as <a href="https://prometheus.io">Prometheus</a>, <a href="https://newrelic.com">New Relic</a>, or <a href="https://cloud.google.com/logging">Stackdriver</a>. Individual adapters generally need to be provided some basic operational parameters in order to do their work. For example, a logging adapter may need to know the IP address and port where it’s log data should be pumped.</p><p>Mixer can use a suite of adapters, and each requires separate configuration parameters. Here’s an example showing how to configure an adapter:</p><pre><code class="language-yaml">adapters:
|
||
- name: myListChecker # user-defined name for this block of config
|
||
kind: lists # kind of aspect this adapter can be used with
|
||
impl: ipListChecker # name of the particular adapter component to use
|
||
params:
|
||
publisherUrl: https://mylistserver:912
|
||
refreshInterval: 60s
|
||
</code></pre><p>The <code>name</code> field gives a name to the block of adapter configuration so it can be referenced from elsewhere. The <code>kind</code> field indicates the <a href="#aspects">aspect kind</a> that this configuration applies to. The <code>impl</code> field gives the name of the adapter being configured. Finally, the <code>params</code> section is where the actual adapter-specific configuration parameters are specified. In this case, this is configuring the URL the adapter should use in its queries and defines the interval at which it should refresh its local caches.</p><p>For each available adapter implementation, you can define any number of independent configuration blocks. This allows the same adapter to be used multiple times within a single deployment. Depending on the situation, such as which service is involved, one configuration block will be used versus another. For example, here are two more configuration blocks that can coexist with the previous one:</p><pre><code class="language-yaml">adapters:
|
||
- name: mySecondaryListChecker
|
||
kind: lists
|
||
impl: ipListChecker
|
||
params:
|
||
publisherUrl: https://mysecondlistserver:912
|
||
refreshInterval: 3600s
|
||
- name: myTernaryListChecker
|
||
kind: lists
|
||
impl: genericListChecker
|
||
params:
|
||
listEntries:
|
||
"400"
|
||
"401"
|
||
"402"
|
||
</code></pre><p>And yet one more:</p><pre><code class="language-yaml">adapters:
|
||
- name: myMetricsCollector
|
||
kind: metrics
|
||
impl: prometheus
|
||
</code></pre><p>This configures an adapter that reports data to the Prometheus system. This adapter doesn’t require any custom parameters and so doesn’t have a <code>params</code> stanza.</p><p>Each adapter defines its own particular format of configuration data. The exhaustive set of adapters and their specific configuration formats can be found <a href="/v0.1/docs/reference/config/mixer/adapters/index.html">here</a>.</p><h3 id="aspects">Aspects</h3><p>Aspects define high-level configuration (what is sometimes called intent-based configuration), independent of the particular implementation details of a specific adapter type. Whereas adapters focus on <em>how</em> to do something, aspects focus on <em>what</em> to do.</p><p>Let’s look at the definition of an aspect:</p><pre><code class="language-yaml">aspects:
|
||
- kind: lists # the aspect's kind
|
||
adapter: myListChecker # the adapter to use to implement this aspect
|
||
params:
|
||
blacklist: true
|
||
checkExpression: source.ip
|
||
</code></pre><p>The <code>kind</code> field distinguishes the behavior of the aspect being defined. The supported kinds of aspects are shown in the following table.</p><table><thead><tr><th>Kind</th><th>Description</th></tr></thead><tbody><tr><td>quotas</td><td>Enforce quotas and rate limits.</td></tr><tr><td>metrics</td><td>Produce metrics.</td></tr><tr><td>lists</td><td>Enforce simple whitelist- or blacklist-based access control.</td></tr><tr><td>access-logs</td><td>Produces fixed-format access logs for every request.</td></tr><tr><td>application-logs</td><td>Produces flexible application logs for every request.</td></tr><tr><td>attributes</td><td>Produces supplementary attributes for every request.</td></tr><tr><td>denials</td><td>Systematically produces a predictable error code.</td></tr></tbody></table><p>In the example above, the aspect declaration specifies the <code>lists</code> kind which indicates we’re configuring an aspect whose purpose is to enable the use of whitelists or blacklists as a simple form of access control.</p><p>The <code>adapter</code> field indicates the block of adapter configuration to associate with this aspect. Aspects are always associated with specific adapters in this way, since an adapter is responsible for actually carrying out the work represented by an aspect’s configuration. In this particular case, the specific adapter chosen determines the list to use in order to perform the aspect’s list checking function.</p><p>By separating aspect configuration from adapter configuration, it makes it possible to easily change the adapter used to implement a particular aspect’s behavior without having to change the aspect itself. Additionally, many aspects can reference the same adapter configuration.</p><p>The <code>params</code> stanza is where you enter kind-specific configuration parameters. In the case of the <code>lists</code> kind, the configuration parameters specify whether the list is a blacklist (entries on the list lead to denials) as opposed to a whitelist (entries not on the list lead to denials). The <code>checkExpression</code> field indicates the attribute to use at request time to get the symbol to check against the associated adapter’s list</p><p>Here’s another aspect, this time it is a <code>metrics</code> aspect:</p><pre><code class="language-yaml">aspects:
|
||
- kind: metrics
|
||
adapter: myMetricsCollector
|
||
params:
|
||
metrics:
|
||
- descriptorName: request_count
|
||
value: "1"
|
||
labels:
|
||
source: source.name
|
||
target: target.name
|
||
service: api.name
|
||
responseCode: response.code
|
||
</code></pre><p>This defines an aspect that produces metrics which are sent to the myMetricsCollector adapter, which was defined previously. The <code>metrics</code> stanza defines the set of metrics that are generated during request processing for this aspect. The <code>descriptorName</code> field specifies the name of a <em>descriptor</em> which is a separate configuration block, described <a href="#descriptors">below</a>, which declares the kind of metric this is. The <code>value</code> field and the four label fields describe which attributes to use at request time in order to produce the metric.</p><p>Each aspect kind defines its own particular format of configuration data. The exhaustive set of aspect configuration formats can be found <a href="/v0.1/docs/reference/config/mixer/aspects/index.html">here</a>..</p><h4 id="attribute-expressions">Attribute expressions</h4><p>Mixer features a number of independent <a href="./mixer.html#request-phases">request processing phases</a>. The <em>Attribute Processing</em> phase is responsible for ingesting a set of attributes and producing the adapter parameters necessary to invoke individual adapters. The phase operates by evaluating a series of <em>attribute expressions</em>.</p><p>We’ve already seen a few simple attribute expressions in the previous examples. Specifically:</p><pre><code class="language-yaml"> source: source.name
|
||
target: target.name
|
||
service: api.name
|
||
responseCode: response.code
|
||
</code></pre><p>The sequences on the right-hand side of the colons are the simplest forms of attribute expressions. They only consist of attribute names. In the above, the <code>source</code> label will be assigned the value of the <code>source.name</code> attribute. Here’s an example of a conditional expression:</p><pre><code class="language-yaml"> service: api.name | target.name
|
||
</code></pre><p>With the above, the service label will be assigned the value of the api.name attribute, or if that attribute is not defined, it will be assigned the value of the target.name attribute.</p><p>The attributes that can be used in attribute expressions must be defined in an <a href="#manifests"><em>attribute manifest</em></a> for the deployment. Within the manifest, each attribute has a type which represents the kind of data that the attribute carries. In the same way, attribute expressions are also typed, and their type is derived from the attributes in the expression and the operators applied to these attributes.</p><p>The type of an attribute expression is used to ensure consistency in which attributes are used in what situation. For example, if a metric descriptor specifies that a particular label is of type INT64, then only attribute expressions that produce a 64-bit integer can be used to fill-in that label. This is the case for the <code>responseCode</code> label above.</p><p>Refer to the <a href="/v0.1/docs/reference/config/mixer/expression-language.html">attribute expression reference</a> for details.</p><h4 id="selectors">Selectors</h4><p>Selectors are annotations applied to an aspect to determine whether the aspect applies for any given request. Selectors use attribute expressions which produce a boolean value. If the expression returns <code>true</code> then the associated aspect applies. Otherwise, it is ignored and has no effect.</p><p>Let’s add a selector to the previous aspect example:</p><pre><code class="language-yaml">aspects:
|
||
- selector: target.service == "MyService"
|
||
kind: metrics
|
||
adapter: myMetricsCollector
|
||
params:
|
||
metrics:
|
||
- descriptorName: request_count
|
||
value: "1"
|
||
labels:
|
||
source: source.name
|
||
target: target.name
|
||
service: api.name
|
||
responseCode: response.code
|
||
</code></pre><p>The <code>selector</code> field above defines an expression that returns <code>true</code> if the <code>target.service</code> attributes equals “MyService”. If the expression returns <code>true</code>, then the aspect definition takes effect for the given request, otherwise it’s like the aspect was not defined.</p><h3 id="descriptors">Descriptors</h3><p>Descriptors are used to prepare Mixer, its adapters, and its infrastructure backends to receive particular types of data. For example, declaring a set of metric descriptors tells Mixer the type of data different metrics will carry and the set of labels used to identity different instances of these metric.</p><p>There are different types of descriptors, each associated with particular aspect kinds:</p><table><thead><tr><th>Descriptor Type</th><th>Aspect Kind</th><th>Description</th></tr></thead><tbody><tr><td>Metric Descriptor</td><td>metrics</td><td>Describes what an individual metric looks like.</td></tr><tr><td>Log Entry Descriptor</td><td>application-logs</td><td>Describes what an individual log entry looks like.</td></tr><tr><td>Quota Descriptor</td><td>quotas</td><td>Describes what an individual quota looks like.</td></tr></tbody></table><p>Here’s an example metric descriptor:</p><pre><code class="language-yaml">metrics:
|
||
- name: request_count
|
||
kind: COUNTER
|
||
value: INT64
|
||
displayName: "Request Count"
|
||
description: Request count by source, target, service, and code
|
||
labels:
|
||
source: STRING
|
||
target: STRING
|
||
service: STRING
|
||
responseCode: INT64
|
||
</code></pre><p>The above is declaring that the system can produce metrics called <code>request_count</code>. Such metrics will hold 64-bit integer values and be managed as absolute counters. Each metric reported will have four labels, two specifying the source and target names, one being the service name, the other being the response code for the request. Given this descriptor, Mixer can ensure that generated metrics are always properly formed, can arrange for efficient storage for these metrics, and can ensure infrastructure backends are ready to accept these metrics. The <code>displayName</code> and <code>description</code> fields are optional and are communicated to infrastructure backends which can use the text to enhance their metric visualization interfaces.</p><p>Explicitly defining descriptors and creating adapter parameters using them is akin to types and objects in a traditional programming language. Doing so enables a few important scenarios:</p><ul><li><p>Having the set of descriptors explicitly defined enables Istio to program infrastructure backends to accept traffic produced by Mixer. For example, a metric descriptor provides all the information needed to program an infrastructure backend to accept metrics that conform to the descriptor’s shape (it’s value type and its set of labels).</p></li><li><p>Descriptors can be referenced and reused from multiple aspects.</p></li><li><p>It enables Istio to provide a strongly-typed scripting environment as discussed <a href="./mixer.html#scripting">here</a></p></li></ul><p>The different descriptor types are detailed in <a href="/v0.1/docs/reference/config/mixer/mixer-config.html">here</a>.</p><h3 id="scopes">Scopes</h3><p>An Istio deployment can be responsible for managing a large number of services. Organizations often have dozens or hundreds of interacting services, and Istio’s mission is to make it easy to manage them all. Mixer’s configuration model is designed to support different operators that manage different parts of an Istio deployment without stepping on each other’s toes, while allowing them to have control over their areas, but not other’s.</p><p>Here’s how this all works:</p><ul><li><p>The various configuration blocks described in the previous sections (adapters, aspects, and descriptors) are always defined within the context of a hierarchy.</p></li><li><p>The hierarchy is represented by DNS-style dotted names. Like DNS, the hierarchy starts with the rightmost element in the dotted name.</p></li><li><p>Each configuration block is associated with a <em>scope</em> and a <em>subject</em> which are both dotted names representing locations within the hierarchy:</p><ul><li><p>A scope represents the authority that created the configuration block. Authorities higher up in the hierarchy are more powerful than those lower in it.</p></li><li><p>The subject represents the location of the block of state within the hierarchy. The subject is necessarily always at or below the level of the scope within the hierarchy.</p></li></ul></li><li><p>If multiple blocks of config have the same subject, the blocks associated with the highest scope in the hierarchy always take precedence.</p></li></ul><p>The individual elements that make up the hierarchy depend on the specifics of the Istio deployment. A Kubernetes deployment likely uses Kubernetes namespaces as the hierarchy against which Istio configuration state is deployed. For example, a valid scope might be <code>svc.cluster.local</code> while a subject might be <code>myservice.ns.svc.cluster.local</code></p><p>The scoping model is designed to pair up with an access control model to constrain which human is allowed to create configuration blocks for particular scopes. Operators which have the authority to create blocks at a scope higher in the hierarchy can impact all configuration associated with lower scopes. Although this is the design intent, Mixer configuration doesn’t yet support access control on its configuration so there are no actual constraints on which operator can manipulate which scope.</p><h4 id="resolution">Resolution</h4><p>When a request arrives, Mixer goes through a number of <a href="./mixer.html#request-phases">request processing phases</a>. The Resolution phase is concerned with identifying the exact configuration blocks to use in order to process the incoming request. For example, a request arriving at Mixer for service A likely has some configuration differences with requests arriving for service B. Resolution is about deciding which config to use for a request.</p><p>Resolution depends on a well-known attribute to guide its choice, a so-called <em>identity attribute</em>. The value of this attribute is a dotted name which determines where Mixer begins to look in the hierarchy for configuration blocks to use for the request.</p><p>Here’s how it all works:</p><ol><li><p>A request arrives and Mixer extracts the value of the identity attribute to produce the current lookup value.</p></li><li><p>Mixer looks for all configuration blocks whose subject matches the lookup value.</p></li><li><p>If Mixer finds multiple blocks that match, it keeps only the block that has the highest scope.</p></li><li><p>Mixer truncates the lowest element from the lookup value’s dotted name. If the lookup value is not empty, then Mixer goes back to step 2 above.</p></li></ol><p>All the blocks found in this process are combined together to form the final effective configuration that is used to evaluate the current request.</p><h3 id="manifests">Manifests</h3><p>Manifests capture invariants about the components involved in a particular Istio deployment. The only kind of manifest supported at the moment are <em>attribute manifests</em> which are used to define the exact set of attributes produced by individual components. Manifests are supplied by component producers and inserted into a deployment’s configuration.</p><p>Here’s part of the manifest for the Istio proxy:</p><pre><code class="language-yaml">manifests:
|
||
- name: istio-proxy
|
||
revision: "1"
|
||
attributes:
|
||
source.name:
|
||
valueType: STRING
|
||
description: The name of the source.
|
||
target.name:
|
||
valueType: STRING
|
||
description: The name of the target
|
||
source.ip:
|
||
valueType: IP_ADDRESS
|
||
description: Did you know that descriptions are optional?
|
||
origin.user:
|
||
valueType: STRING
|
||
request.time:
|
||
valueType: TIMESTAMP
|
||
request.method:
|
||
valueType: STRING
|
||
response.code:
|
||
valueType: INT64
|
||
</code></pre><h2 id="examples">Examples</h2><p>You can find fully formed examples of Mixer configuration by visiting the <a href="/v0.1/docs/samples">Samples</a>. As a specific example, here is the <a href="https://github.com/istio/mixer/blob/master/testdata/configroot/scopes/global/subjects/global/rules.yml">Default configuration</a>.</p></div></div></div></div></div></div><script src="/v0.1/js/sidemenu.js"></script><footer><div class="container"><div class="row"><div class="col-md-2"></div><div class="col-md-3 col-sm-4 col-xs-12 center-block"><ul class="toggle"><p class="header">Docs</p><li><a href="/v0.1/docs/">Welcome</a></li><li><a href="/v0.1/docs/concepts">Concepts</a></li><li><a href="/v0.1/docs/tasks">Tasks</a></li><li><a href="/v0.1/docs/samples">Samples</a></li><li><a href="/v0.1/docs/reference">Reference</a></li></ul></div><hr class="footer-sections" /><div class="col-md-3 col-sm-4 col-xs-12 center-block"><ul class="toggle"><p class="header">Resources</p><li><a href="/v0.1/faq">Frequently Asked Questions</a></li><li><a href="/v0.1/troubleshooting">Troubleshooting Guide</a></li><li><a href="/v0.1/bugs">Report a Bug</a></li><li><a href="https://github.com/istio/istio.github.io/issues/new?title=Issue with _docs/concepts/policy-and-control/mixer-config.md">Report a Doc Issue</a></li><li><a href="https://github.com/istio/istio.github.io/edit/master/_docs/concepts/policy-and-control/mixer-config.md">Edit This Page on GitHub</a></li></ul></div><hr class="footer-sections" /><div class="col-md-3 col-sm-4 col-xs-12 center-block"><ul class="toggle"><p class="header">Community</p><li><a href="https://groups.google.com/forum/#!forum/istio-users" target="_blank"><span class="group">User</span></a> | <a href="https://groups.google.com/forum/#!forum/istio-dev" target="_blank">Dev Mailing Lists</a></li><li><a href="https://twitter.com/IstioMesh" target="_blank"><span class="twitter">Twitter</span></a></li><li><a href="https://github.com/istio/istio" target="_blank"><span class="github">GitHub</span></a></li></ul></div><div class="col-md-1"></div></div><div class="row"><p class="description small text-center"> Copyright © 2017 Istio Authors<br> Istio 0.1<br> Archived on 20-Jul-2017</p></div></div></footer><script src="https://cdnjs.cloudflare.com/ajax/libs/jquery-validate/1.15.0/jquery.validate.min.js"></script> <script src="/v0.1/js/jquery.form.min.js"></script> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.1/js/bootstrap.min.js"></script> <script src="/v0.1/js/slick.min.js"></script> <script src="/v0.1/js/jquery.visible.min.js"></script> <script src="/v0.1/js/common.js" type="text/javascript" charset="utf-8"></script> <script src="/v0.1/js/buttons.js"></script> <script src="/v0.1/js/search.js"></script> <script src="/v0.1/js/prism.js"></script></body></html>
|