深度解析Istio系列之策略与遥测篇

注：以下讲述的案例环境场景是基于Kubernetes环境基础上部署的istio环境。

涉及到的Pilot和Envoy的了解请参考深度解析Istio系列之流量控制篇，本文重点在于介绍Mixer。

Mixer与Envoy sidecar数据平面进行网络通信，pilot控制平面配置Mixer check和report功能需要的配置信息。Mixer主要有两大核心功能：check和report，这两个功能具体实现则由Mixer后端众多适配器操作，下面会介绍下Mixer这两个功能是如何工作的。

Mixer与服务之间调用交互流程

每个经过Envoy sidecar的请求都会调用Mixer。如下图1所示，展示了Service A调用Service B的过程，Pod A请求到达Pod B的Envoy时，进行一次check操作，Mixer处理完后响应数据，Envoy B接收到通过或者拒绝，如果通过，请求继续，则Envoy B会继续请求Service B,Service B处理完业务向Envoy B 响应，Envoy B 接收到响应再次向Mixer发送一次report请求。Mixer组件提供了一组后端抽象服务，并且为这些服务提供了对应的 API，每次请求操作都会根据预先定义好的配置文件，调用相关Adapter的API来执行具体的check和report的操作。

Mixer在Istio部署环境中，又分为两个服务组件：istio-policy和istio-telemetry。这两个服务的pod里具有相同的容器：mixer和istio-proxy，但istio-proxy容器在启动时，–templateFile参数使用的模板文件不一致，它们所执行的功能也不同。istio-policy服务启动时加载/etc/istio/proxy/envoy_policy.yaml.tmpl模板文件，istio-telemetry服务启动时则加载/etc/istio/proxy/envoy_telemetry.yaml.tmpl模板文件，这两个文件偶读提供了两个监听端口：9091和15004。istio-policy主要负责接收来自Envoy sidecar的check请求，拒绝或通过，只有通过check校验的请求，才允许继续请求目标服务，istio-telemetry则负责接收来自Envoy sidecar的report请求，该请求只做日志记录操作并响应于请求端。

Mixer支持的后端适配器有很多种，这些适配器能处理和完成不同的功能，根据check功能型和report功能型，将分类列出一些常用的适配器。

Check功能型适配器：

• Denier/list适配器：权限控制/黑白名单检测功能

• memory quota/redis quota适配器：速率限制功能

Report功能型适配器：

• prometheus适配器：收集指标、获取TCP服务指标功能

• Stdio适配器：日志输入输出

• Fluentd适配器：将日志发送到Fluentd 守护进程

• Statsd适配器：向istio-statsd-prom-bridge后端服务发送指标数据

Mixer配置模型

Mixer配置模型分为三种：Handler、Instance、Rule。Handler对应了后端具体的某个Adapter实例，Instance对应着具体Handler需要的一组属性数据，Rule则配置匹配规则，指定满足什么样的条件才允许对相关后端适配器进行report或check操作。

我们举一个权限控制适配器中黑白名单处理器配置模型的例子，如下图2所示。该例子中listentry是Instacne类型，dimensions字段规定了这次请求需要的属性，在请求mixer时，需要从请求带来的参数中，获取客户端应用labels中version标签值。listchecker是Handler类型，指定了一个overrides列表，并指明该列表名单是一个白名单，如果请求端labels的version标签值属于白名单列表，才则允许继续请求目标应用，如果blacklist值为true,那么overrides列表就是一个黑名单列表。rule很明显就是Rule类型了，该规则配置里设定了匹配条件，如果请求的目标应用labels的app标签的值与"ratings"匹配，则请求listchecker适配的API，进行黑白名单的check，当然也可以不设定匹配规则，让所有的请求都进行check。

现在我们利用官网提供的BookInfo项目来测试下这个黑白名单适配器，如果不太明白BookInfo项目中各应用之间的调用关系，可以到官网上查看，这里不做特别说明，为了显示效果最终，我们需要提前做些限制条件，流程如下：

（1） Bookinfo 示例中的每个微服务都包含了多个版本，所以首先要创建目标规则，为每个版本创建一个对应的服务子集。

环境如果没有启用双向TLS，命令如下：

     istioctl create -f [samples/bookinfo/networking/destination-rule-all.yaml](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all.yaml)

环境如果启用双向TLS，命令如下：

     istioctl create -f [samples/bookinfo/networking/destination-rule-all-mtls.yaml](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all-mtls.yaml)

（2） 初始化版本路由，VirtualService中引用的子集是依赖于DestinationRule的，因此需要等待几秒钟，让DestinationRule生效后，再执行如下命令：

   istioctl create -f [samples/bookinfo/networking/virtual-service-all-v1.yaml](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml)

（3） 对目标为 reviews 服务的请求，来自用户 "jason" 的请求分配给 v2 版本，其他请求分配到 v3 版本，执行如下命令：

   istioctl replace -f [samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml](https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml)

（4） 执行到这边，我们通过浏览器访问http://{HostIp}:31380/productpage，会看到如下图所示的页面，显示reviews v3版本的红色五角星：

（5） 将图2内容放在yaml里，v1和v2是白名单，v3是黑名单，不带"jason"用户名的请求，我们将看不到v3版本的红色五角星，执行如下命令：

istioctl create -f whitelist.yaml

输出如下：

（6） 现在我们通过浏览器访问http://{HostIp}:31380/productpage，页面显示如下，看不到v3版本的红色五角星了：

（7） 现在我们将blacklist改成true，则v1和v2版本将变成黑名单，v3成为白名单。则不带"jason"用户的请求，将又会看到v3版本的红色五角星。

文件内容修改如下：

浏览器请求显示如下：

Mixer又是如何根据配置模型与后端的适配器交互的呢？

首先用户根据需求编写某种适配器的配置模型文件，并且创建这些资源对象，pilot通过与Kuberenetes ApiServer交互获取这些数据，并将数据格式转换成xDS专有的格式。

然后我们看下istio-policy和istio-telemetry服务中的istio-proxy容器在启动过程中都做了哪些。首先初始化前面提到的/etc/istio/proxy/*.yaml.tmpl文件后，随后启动了proxy agent，proxy agent是负责启动Envoy并且管理Envoy生命周期，Envoy启动后与pilot交互从xDS中获取数据。与此同时Mixer也获取到这些数据信息，对数据信息进行读取、解析，并且在Mixer服务初始化配置文件数据以及启动完成后，用户操作istio环境中的配置模型文件，都会通过Envoy通知Mixer做出相应的操作，这样Mixer就能得到实时更新的数据信息。

每次应用服务中的Envoy sidecar发请求时都会带着客户端和服务端一些属性信息，Mixer接收到这些属性信息，先会调取rule列表，根据rule规定好的条件进行匹配，匹配通过，获取该规则对应的Instance和Handler信息，处理Instance模板里的属性字段，并将属性作为请求Handler API的参数。

istio-telemetry服务控制台日志

istio-telemetry服务记录了每次请求结束后report上来的相关信息，我们可以打开mixer容器查看日志，所有请求的report操作都将在该容器的日志控制台被打印。如下图3截取的控制台部分日志信息，是一次BookInfo应用服务的请求过程日志，这次请求记录被report到istio-telemetry服务，从这次的日志记录信息可以看出，目标应用destinationApp是productpage，以及productpage应用其他相关的信息（如应用的pod名称、该pod所在的命名空间等等），源应用（发起请求的服务应用）sourceApp是istio-ingressgateway，同样也记录下了istio-ingressgateway应用服务的相关信息。

开启和禁用Envoy向Mixer请求

Mixer提供功能的同时，我们也可以禁止它提供的功能，取消每次请求经过Envoy时都调用Mixer，这样也就不需要在istio环境中运行Mixer组件。我们需要改动istio ConfigMap这个资源对象的先关配置信息。如下图4所示，将属性disablePolicyChecks改为true，还有mixerCheckServer和mixerReportServer这两个属性注释掉。

到这里，简单的介绍了一下Mixer提供哪些功能以及如何使用它，关于更多的适配器以及适配器的使用可以查看官网里的案例。

官网地址：https://preliminary.istio.io/zh/docs/reference/config/policy-and-telemetry/adapters/