Policies and Control

Attributes

背景

Istio使用属性来控制网格中运行服务的运行时行为。属性是被命名和分类的元数据，描述出入通信及所在环境。一个Istio属性携带特定信息块，如API请求的错误码，API请求的延迟，或一个TCP请求的原始IP地址。如：

request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: 192.168.0.1
destination.service: example

属性词汇表

一个给定Istio部署有一个它能理解的固定属性词汇表。具体词汇表是由部署中使用的属性生产者的集合所决定的。Istio的当前属性生产者是Envoy，不过特定Mixer适配器同样能生产属性。
Istio部署中最常用的可用属性见here

属性名

Istio属性使用类Java的全限定标识符作为属性名。可以使用的字符为 [_.a-z0-9]。"." 用于命名空间分隔符。例如，request.size 和 source.ip.

属性类型

Istio属性是强类型。支持的属性类型见here

Mixer

背景

Mixer 提供了一个在基础设施和应用代码之间的逻辑中间层。相比传统的应用代码与特定后端组件集成，现在可以使应用代码与Mixer简单集成，然后由Mixer与后端系统交互。
Mixer的目的是改变层间边界以减少系统复杂度，消除服务代码中的策略逻辑，将控制权交给操作人员。

Mixer提供了三个核心要素：
1. 先决条件检查。允许调用者在响应来自服务使用者的传入请求之前验证一些先决条件；包括身份认证，白名单，ACL检查等。
2. 配额管理。配额被用作一个相对简单的资源管理工具，在争夺有限资源的时候，为服务消费者提供一些公平性。
3. 遥测报告。使服务提供日志和监控。未来还将提供针对服务消费者和操作员的追踪和计费流等功能。

适配器

Mixer是一个高度模块化和可扩展的组件。它的一个关键功能就是抽象出不同策略和遥测后端系统的细节，使这些后端系统对于Envoy和基于Istio的服务不可见，这使得这些服务可扩展。

Mixer通过一个通用插件模型来实现灵活处理不同基础设施后端。单独的插件被称为适配器（adapters），它们允许Mixer连接不同交付核心功能的基础设施后端，例如日志，监控，配额，ACL检查等。适配器使Mixer暴露一个独立于使用中后端的统一API。在运行中的实际使用的适配器集通过配置确定，并且可以轻易的扩展到新的或自定义的目标基础设施后端。

配置状态

Mixer的核心运行方法（Check和Report）接受一组输入的属性。Mixer的当前配置决定了如何执行带有一组输入属性的单个方法。为此，服务操作负责：
1. 配置一组针对由Mixer生成数据的处理器。处理器配置了适配器。一个简单例子是为statsd后端提供一个带有ip地址的statsd适配器。
2. 配置一组基于Mixer属性和字面值生成的实例。这表示适配器代码将操控大量数据。例如，一个操作员可能配置Mixer去生成针对来自destination.service 和response.code这些属性的 requestcount 的metric值。
3. 配置一组Mixer每次请求都会执行的规则。规则由match表达式和动作组成。match表达式控制Mixer合适执行特定行为。这些行为又指定生成的实例及处理这些实例的处理器。例如，一个规则可能通知Mixer将生成好的 requestcount 实例发送给statsd 处理器来处理所有Report 调用。
以上配置状态需要Mixer知道如何处理传入的属性，并分发到合适的基础设施后端。

请求阶段

当一个请求到达Mixer，它将经过一系列不同处理阶段：
1. 附加属性生产。Mixer最初运行一个负责引入新属性的全局适配器集。这些属性与来自请求的属性相结合，形成了操作的全部属性集。
2. 分辨。第二阶段是评估属性集，以确定对于请求申请的有效配置。有效配置决定了处理后续阶段请求可用的方面和描述符集合。
3. 属性加工。第三阶段获取全部属性集并提供一系列适配器参数。属性加工首先通过一个简单声明式的形式配置，详见Mixer Configuration。
4. 适配器调度。 分辨阶段确定了可用方面集，属性加工阶段创建适配器参数集。适配器调度阶段调用与每个方面有关的适配器并将参数传递给它们。

Mixer Configuration

背景

Istio是一个拥有数百个独立功能的复杂系统。一次Istio部署可能是一个庞大的事件，包含了数十个服务，由大量的Envoy代理和Mixer实例支持它们。在大型部署中，不同的运维人员负责着不同的范围，可能涉及管理整个部署。
Mixer配置模型使它能够充分利用它的所有功能性和灵活性，同时能保持相对简单的使用。模型的作用域特性使得大型支持组织能轻松的共同管理负责的部署。模型的一些关键特性包括：
1. 为运维人员设计。服务的运维人员通过操控配置资源来控制Mixer部署的所有操作和策略方面。
2. 灵活性。配置模型围绕Istio的属性建立，使运维人员能够前所未有的控制在部署过程中使用的策略和遥测技术。
3. 健壮性。配置模型设计的目的是提供最大静态正确性以确保减少糟糕的配置更改导致服务中断的可能性。
4. 可扩展性。该模型的设计目的使支持Istio的整体可扩展性。可以将新的或自定义适配器加入Istio，并且完全使用与现有适配器相同的通用机制操控。

概念

Mixer是一个属性处理器。带有一系列属性的请求到达Mixer，基于这些属性，Mixer对各种基础设施后端产生调用。速率控制系统、ACL提供者、策略实施者都是基础设施后端的例子。一组属性决定了Mixer针对所给请求调用那个后端，并且给它们什么参数。为了隐藏每个独立后端的详情，Mixer使用称作适配器的组件。

Mixer的配置由如下主要责任：
1. 描述哪些适配器正在使用，以及如何操作；
2. 描述如何将请求属性映射到适配器的输入；
3. 描述一个特定适配器被调用时的特定输入。

配置基于适配器和模板。
适配器封装了Miser和特定基础设施后端交互的必要逻辑。
模板定义了从适配器输入的属性映射到特定请求的模式。一个给定适配器可以支持任意数量模板。

配置使用YAML模式构建，围绕以下抽象表达：
Handlers：一个处理器是一个适配器的配置实例。适配器的构造参数被指定为handler配置。
Instances：一个实例是请求属性应用到模板映射的结果。映射被指定为一个instance配置。
Rules：一个规则定义了何时为特定handler调用特定模板配置。

配置资源在k8s资源中语法表示如下：

apiVersion: config.istio.io/v1alpha2
kind: rule, adapter kind, or template kind
metadata:
  name: shortname
  namespace: istio-system
spec:
  # kind specific configuration.

1. apiVersion - Istio版本常量
2. kind - 一个Mixer为每个适配器和模板分配了唯一的种类
3. name - 配置资源名
4. namespace - 配置资源适用的名称空间
5. spec - 特定种类（对应上面的kind）的配置。

Handlers

适配器封装了Mixer与特定外部基础设施后端交互的必要逻辑，如Prometheus、New Relic或StackDriver。单个适配器需要操作参数来完成它的工作。例如，一个日志适配器可能需要IP地址和日志接收器的端口。
下面例子展示如何配置种类为listchecker的适配器。这个适配器对比一个列表检查一个输入值。如果适配器被配置为一个白名单，当它在列表中找到输入值时返回成功。

apiVersion: config.istio.io/v1alpha2
kind: listchecker
metadata:
  name: staticversion
  namespace: istio-system
spec:
  providerUrl: http://white_list_registry/
  blacklist: false

{metadata.name}.{kind}.{metadata.namespace} 是一个handler完全限定名。上面适配器的完全限定名为staticversion.listchecker.istio-system 并且它必须唯一。spec 中的数据模式依赖于特定的适配器配置。
一些适配器实现的功能超出了连接Mixer和后端。例如，prometheus 适配器消费metrics并聚合它们，以一种可配置的方式分发或计数。

apiVersion: config.istio.io/v1alpha2
kind: prometheus
metadata:
  name: handler
  namespace: istio-system
spec:
  metrics:
  - name: request_count
    instance_name: requestcount.metric.istio-system
    kind: COUNTER
    label_names:
    - destination_service
    - destination_version
    - response_code
  - name: request_duration
    instance_name: requestduration.metric.istio-system
    kind: DISTRIBUTION
    label_names:
    - destination_service
    - destination_version
    - response_code
    buckets:
      explicit_buckets:
        bounds: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]

每个适配器定义自己配置数据的特定形式。想知道更多请看here

Instances

Instance配置指定适配器输入属性映射到请求。下面是一个生产requestduration metric的metric instance configuration的例子。

apiVersion: config.istio.io/v1alpha2
kind: metric
metadata:
  name: requestduration
  namespace: istio-system
spec:
  value: response.duration | "0ms"
  dimensions:
    destination_service: destination.service | "unknown"
    destination_version: destination.labels["version"] | "unknown"
    response_code: response.code | 200
  monitored_resource_type: '"UNSPECIFIED"'

注意在handler配置中所期望的所有维度都是在映射中指定的。
每个模板定义自己配置数据的特定形式。想知道更多请看here

Rules

Rules指定何时使用特定实例配置调用特定handler。
考虑如下实例，你想要将requestduration metric发送到prometheus 处理器，其中最终服务是
service1 而 x-user 请求头有一个特定值。

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: promhttp
  namespace: istio-system
spec:
  match: destination.service == "service1.ns.svc.cluster.local" && request.headers["x-user"] == "user1"
  actions:
  - handler: handler.prometheus
    instances:
    - requestduration.metric.istio-system

一个rule包含一个match 谓语表达式，以及一个如果谓语为真使执行的一系列actions。一个action指定给要传递的handler一个instances列表。一个rule必须使用handlers和instances的完全限定名。如果rule，handlres和instances都在同一个命名空间，命名空间后缀可以从完全限定名中省略，如handler.prometheus

match谓语是一个属性表达式，如下所述。

Attribute expressions

Mixer包含许多独立的请求处理阶段。Attribute Processing 阶段负责摄取一组属性，并生成必要模板实例来调用特定适配器。这个阶段通过评估一系列属性表达式来操作。
你可能在之前的例子中看到过一些简单的属性表达式：

destination_service: destination.service
response_code: response.code
destination_version: destination.labels["version"] | "unknown"

冒号右边的序列是属性表达式最简单的模式。前两个只包含属性名，response_code 标签分配来自 request.code 属性的值。
下面是一个条件表达式的例子：

destination_version: destination.labels["version"] | "unknown"

如上所示， destination_version 标签分配destination.labels["version"]的值。如果属性不存在，则使用字面值"unknown"

属性表达式中可以使用的属性必须在部署的属性清单中定义。在清单中，每个属性都有一个类型，代表属性所携带的数据类型。同样，属性表达式也有类型，它们的类型通过表达式中的属性及应用这些属性的运算符推导而出。

Resolution

当一个请求到达，Mixer通过了很多请求处理阶段。Resolution阶段关注确定使用的配置源来处理进入的请求。例如，服务A到达Mixer的请求可能和服务B有一些配置上的不同。Resolution决定为请求使用哪种配置源。
Resolution的选择取决于一个被称为 identity attribute（标识属性） 的属性。默认的标识属性是destination.service 。默认值为 istio-system 的 mesh-wide 配置被保存在configDefaultNamespace 。
Mixer通过如下步骤来实现actions集合。
1. 从请求中提取标识属性的值。
2. 从标识属性中提取服务命名空间。
3. 从所在服务命名空间和configDefaultNamespace 的所有rules中提取match谓语。
上述actions操作是通过Mixer执行。

Manifests

Manifests捕获一个特定Istio部署所涉及的组件的不变量。目前唯一支持的清单是attribute manifests ，用于定义单个组件产生的精确属性集。Manifests由组件生产者提供，并且插入到部署配置中。
下面是Istio proxy的部分清单：

manifests:
  - name: istio-proxy
    revision: "1"
    attributes:
      source.name:
        valueType: STRING
        description: The name of the source.
      destination.name:
        valueType: STRING
        description: The name of the destination
      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