4 istio的策略和遥测 与适配器

Istio中策略和遥测要解决的问题、实现原理和使用方式;并讲解Istio基于Adapter机制提供的Prometheus、Fluentd、Quota 等策略和遥测功能，包括这些Adapter的工作机制和使用方法等;并基于这种扩展机制在不修改代码的情况下收集服务的运行数据和 执行策略。

4.1 istio策略和遥测的原理

4.1.1 应用场景
除了需要具备服务治理功能，还需要知道服务运行的怎么样、有没有问题、以及哪里有问题等。
这一班是APM的职能，设计数据采集、存储、检索。

1、传统的遥测数据收集方式
将数据采集的代码混合到业务代码中，会侵入业务代码。
如图：

问题场景
1）apm升级，如协议发生了变化，从Restful改为gRPC
2）apm上报字段被修改，如领导需要多关心一个信息。
上面的场景业务都没有修改，但是由于apm对业务的侵入，导致apm修改时，业务需要同时修改。

2 sidecar的遥测数据收集
sidecar代理了业务的各种能力，监控数据采集流程如图：

访问都被透明的Sidecar代理了，可以通过Sidecar代理上报监控数据。

为了提供综合的APM能力，需要上报多种数据，即可能会对接多个APM后端，
问题：
如果以上任何一个 APM 后端的上报格式或者其他逻辑有变更， Sidecar 就必须要升级。
如果用户因为业务需要再对接一个新的APM，则不但整个访问拓扑更乱，每个 Sidecar 都还要重新开发去支持这个后端，然后全局升级。

3 istio基于mixer的遥测数据收集
在遥测数据采集场景下，Istio更前进了一步，将Envoy里的这部分 功能提取出来，放到一个服务端组件Mixer上，在逻辑上将Envoy和各种遥测数据的收集解耦，并将Envoy 和真正的遥测后端解耦。
应用、代理、遥测后端的关系如下图：

上面三种场景下mixer的表现：
◎ 场景 1:当 APM协议改变时，只需修改 Mixer对接的 Adapter的对应接口即可，数据面代理无须随 之变更。
◎ 场景 2:当某个 APM上报的数据格式发生变化时，只需修改 Adapter的数据定义即可，数据面代 理无感知。
◎ 场景3:在对接一个新的后端时，只需基于Mixer的Adapter机制开发一个对应的Adapter即可，数据 面代理无感知。

4.1.2基于mixer遥测数据收集的工作原理
mixer的adapter机制，主要流程如图：

每个经过 Envoy的请求都会调用Mixer上报数据，流程主要有两步：
1）Envoy生成数据并将数据上报给Mixer，例如Envoy生成一条服务A访问服务B的数据，包括时 间、服务A的IP、服务B的IP等
2）Mixer调用对应的服务后端处理收到的数据，例如Mixer调用一个APM的Adapter，通过这个 Adapter将数据上报到APM后端

Adapter里封装了对数据的处理逻辑和和对后端服务的调用接口，提供通用接口供Mixer调用，然后将调用转到对应的后端服务。

4.1.3 属性及其表达式
1 istio属性的含义
envoy上报的数据在istio中被称为属性，描述服务请求或服务运行环境的信息。
每个属性都包括一个属性名和属性类型，如下图：

2.Istio支持的属性表达式
把右边的属性赋给左边的字段，比如在Metric的数据中 收集的 response_code就是 response.code这个属性在请求中的取值，具体属性包括：

除了直接使用上面的属性，在 Istio 中允许基于表达式描述属性。例如

例如，若response.code为空， response_code就会被赋默认值200。
这在Mixer中是简单的表达式，实际上，在Metric的定义中经常 有这样一个reporter字段，可以通过如下表达式描述Metric是从source还是destination端上报上去的:

4.1.4 mixer的配置模型
通过handler(业务处理)、Instance(数据定义)和 Rule(关联规则)这三个资源对象来描述对Adapter的配置。
在Rule中定义了基于满足match条件的请求构造的Instance对象，并 将Instance对象发送给配置的Handler处理。

1 handler
首先mixer中是支持多种adapter的，不同的adapter有不同的配置，也可以看成是不同的模板。
handler就是对某模板的一个具体实现。

mixer支持如下图所示的adapter：

下面是stdio对应的adapter模板定义，

handler是adapter定义的模板的实现，通过给模板上的参数赋值来进行实例化。一个adapter可以有任意多个实现。
如下图：

Handler对outputAsJson参数的赋值为true，表示使用JSON的格式输出。

handler的定义规则;
◎ name:必选字段，为Handler的名称，在Rule中引用的正是这个字段定义的Handler名称。
◎ compiledAdapter:必选字段，为进程内Adapter的名称，匹配Mixer的一个Adapter，其实就是
Adapter代码中的常量定义。
◎ adapter:必选字段，非进程内的Adapte名称，是Adapter代码中的常量定义。
◎ params:在 Handler中配置的参数。例如，本节的配置示例在 Stdio的 Adapter中定义了多个参数，
在Handler的Manifest中对参数进行配置。
◎ connection:配置对一个进程外的 Adapter 的连接信息，主要是一个 Adapter 服务的地址。当然， 根据Adapter的要求，还包括相关认证的配置。

2 instance
定义了Adapter要处理的数据对象，通过模板为Adapter提供对元数据的定义。
mixer通过instance把来自代理的属性拆分并分发给不同的适配器。
日志的instance配置如下图

Instance包括如下几个重要字段。
◎ name:必选字段，指Instance的名称。在Rule的Action定义中引用该名称表示对该Instance的引用。
◎ compiledTemplate:必选字段，指模板名，匹配编译模板名。
◎ template:必选字段，指模板名，匹配非编译模板名。
◎ params:必选字段，真正的参数定义。不同的模板会有不同的参数定义及不同的参数赋值和配
置。
◎ attributeBindings:用来配置将Adapter生成的属性映射到属性列表中。

3 Rule  
配置匹配规则，告诉 Mixer有哪个 Instance 在什么时候被发送给哪个 Handler来处理。

如下所示为给stdio配置一个规则:将协议是HTTP或者gRPC的请求转发到Stdio这个Handler上，并且 通过logentry这个Instance定义处理的数据格式:

rule的规则定义主要包括两个字段：
1)match:是一个必选字段，表示匹配条件。Mixer在收到请求时会根据该条件来决定是否执行在 下面的actions中定义的动作。
如果未定义条件，则判定为总是匹配。当然，最常见的是使用属性的操作表达式来描述条件，
例如match(source.workload.name，"forecast*")或者一般的context.protocol=="http"||context.protocol=="grpc"这种。
(2)actions:是一个数组，表示在满足条件后执行的动作。主要包括如下信息。
◎ handler:必选字段，Handler名称，需要是全名。
◎ instances:Instance 的全名，通过解析字段的取值来构造 Instance，并将构造的对象传给定义的
handler。

4.2 istio遥测适配器配置
4.2.1 prometheus适配器
先介绍prometheus:当前应用最广的开源系统监控和报警平台，存在数据此埃及能力强、查询语法灵活、扩展性强、方便集成的特点，尤其与云原生生态的结合，获得了越来越广泛的应用。

prometheus的工作原理如图所示：

prometheus主要工作为：抓取数据存储，提供PromQL语法进行查询，对接Grafana\Kiali等dashboard进行显示。

1 adapter的功能
一般可以使用Promethus提供的各种语言的sdk在业务代码中添加Metric的生成逻辑，通过http发不满足格式的metric接口。
更通用的方式是提供Prometheus Exporter的代理，和应用一起部署，收集应用的Metric并将其转换成Prometheus的格式发布出来。

Exporter方式的最大优点不需要修改用户的代码，所以应用非常广泛。Prometheus社区提供了丰富的 Exporter 实现(https://prometheus.io/docs/instrumenting/exporters/)，除了包括我们熟知的 Redis、 MySQL、TSDB、Elasticsearch、Kafka 等数据库、消息中间件，还包括硬件、存储、HTTP服务器、日志 监控系统等。

如图所示：

在Istio中通过Adapter收集服务生成的Metric供Prometheus采集，这个Adatper就是 Prometheus Exporter的一个实现。
上图中完整流程如下：
(1)Envoy通过Report接口上报数据给Mixer。
(2)Mixer根据配置将请求分发给Prometheus Adapter。
(3)Prometheus Adapter通过HTTP接口发布Metric数据。
(4)Prometheus 服务作为 Addon 在集群中进行安装，并拉取、存储 Metric 数据，提供Query接口进
行检索。
(5)集群内的Dashboard如Grafana通过Prometheus的检索API访问Metric数据。

2 prometheus的adapter的配置
1）hander配置
(1)metricsExpirationPolicy:配置 Metric 的老化策略，metricsExpiryDuration 定义老化周期， expiryCheckIntervalDuration定义老化的检查间隔。
实例如下图：

含义：可清理5分钟未更新的Metric，并且每隔30秒做一次检查，检查
周期 expiryCheckIntervalDuration 是个可选字段，若未配置，则使用老化周期的一半时间:
(2)metrics:配置在Prometheus中定义的Metric。这里是一个数组，每个元素都是一个MetricInfo类 型的结构，分别定义Metric的namespace、name、instanceName、description、kind、buckets、 labelNames，这些都是要传给Prometheus的定义。有以下几个注意点。
◎ Metric的namespace和name会决定Prometheus中的Metric全名。例如requests_total这个请求统计的 Metric对应图4-13中Prometheus的Metric:istio_requests_total，即由命名空间istio和Metric名称requests_total 拼接而成。
◎ instanceName是一个必选字段，表示instance定义的全名。
◎ kind 表示指标的类型，根据指标的业务特征，请求计数 requests_total 的类型为COUNTER，请求 耗时 request_duration_seconds 的类型为 DISTRIBUTION。对于DISTRIBUTION类型的指标可以定义其 buckets。

Prometheus Handler 的一个定义示例，定义了 15 秒的老化时间及Prometheus中的多个 Metric，有的是HTTP的Metric，有的是TCP的Metric

2)Instance的配置
Metric Instance的定义如图

 

说明：
dimensions记录每个请求上的重要属性信息。
value:"1"表示每个请求被记录一次。

3）rule配置
通过 Rule可以将 Handler 和 Instance建立关系，例如，下面两个 Rule可以分别处理HTTP和TCP的 Instance:
如图：

4.2.2 Fluentd适配器
Fluentd 是一个被广泛应用的开源日志数据收集器，提供了可高度定制化的功能，通过简单的配置，
可以将不同来源的日志收集到对应的日志后端。
Adapter通过Fluentd收集日志并与Elasticsearch、Kibana相结合的一个典型场景。

4.2.3 statsD适配器
StatsD 接收客户端发送来的数据，将数据解析、聚合并定期推送给后端，一 般是个时序数据库，再通过Dashboard显示。StatsD默认在UDP上监听数据，速度很快。

4.2.4 stdio适配器
Stdio只是将数据通过标准输出打印出来，Mixer的Stdio Adapter也是最简单的一种数据输出。

4.2.5 zipkin适配器
Zipkin是较早出现的一种开源实时分布式调用链跟踪系统，也是对大名鼎鼎的Dapper论文的比较经典 的实现。Zipkin 提供了一种完整的从调用链埋点、收集、存储、检索到UI的完整方案。虽然后期出现的 Opentracing标准和以Jaeger为代表的新的调用链框架获得了越来越多的关注和使用，Zipkin的使用仍然广 泛。

4.2.6 厂商适配器

4.3 Istio策略适配器配置
除了遥测数据收集，Istio Adapter 机制的另外一个重要应用是策略执行。
策略执行Adapter 负责处理 Mixer 转发的 Check 请求，并将该请求分发给对应的策略执行后端，根据后端的判断逻辑返回拒绝或通过，来控制网格内服务之间的访问。

4.3.1 List适配器
最简单的判断逻辑的 Adapter，它配置了一个黑名单或者白名单，匹配白名单则放行; 匹配黑名单则拒绝。
1.Handler的配置 对Handler的配置如下。
◎ providerUrl:名单的地址，当使用本地名单时可以不进行配置。
◎ refreshInterval:获取名单的刷新间隔。
◎ ttl:名单保存时长。
◎ cachingInterval:缓存的间隔。
◎ cachingUseCount:缓存的记录数。
◎ overrides:重要字段，该列表中的名单覆盖从providerUrl获取的名单。
◎ entryType:名单条目的类型，可以是STRINGS、CASE_INSENSITIVE_STRINGS、
IP_ADDRESSES 和 REGEX，分别表示字符串、大小写不敏感的字符串、IP 地址(段)和表达式。 ◎ blacklist:是否是黑名单，影响匹配后的判断逻辑。 如下所示配置了一个白名单的Handler，只有满足IP段条件的检查通过:

2.Instance的配置
策略执行的模板一般比遥测数据的模板简单，就是配置待检 查的字段，在如下Instance中定义了从请求中提取IP作为检查输入。

3.Rule的配置
配置如下Rule关联Handler和Instance，只有来源负载上标签是"forecast"的请求执行名单检查:

4.3.2 Denier适配器
Denier适配器也是一个比较简单的Adapter，按照配置总是返回拒绝。
1.Handler的配置
Denier 适配器的 Handler 的主要配置(见图 4-26)就是定义拒绝的状态信息 status，包括状态码
(code)、消息(message)和详情(details)，类似在写代码时定义的异常信息。还有两个有意思的字 段:validDuration和validUseCount，分别表示有效间隔和有效次数。当时间不超过validDuration时，检查 次数若不超过validUseCount，则不再做检查。

在满足条件时将会返回“1333”状态码:

2.Instance的配置 
Denier的检查对象同List名单中的检查对象定义。 

3.Rule的配置
只需配置如下所示的 Rule 让上面的 Handler 生效，来自标签为“forecast”的服务请求就都会被拒绝， 并返回“1333”状态码

4.3.3 Memory Quota适配器
使用场景是设置一个生效时间进行限流，即 设置在一个时间段内的访问配额。

4.3.4 Redis Quota适配器
具备 HA 能力，功能类似Memory Quota

4.4 Kubernetes Env适配器配置
用于提取Kubernetes中服务的元数据并交给后续的Adapter处理。

下面是一个具体场景：
在Envoy上报数据时，在上报的访问源和目标信息中一般只包含IP等基础信 息，不会包含服务的命名空间信息，但后端APM需要基于命名空间对数据进行分组管理。这时基于负载 的标识关联和补齐其他需要的属性就可以通过Kubernetesenv Adapter来实现，补齐的属性就可以在后续的 APM Adapter中使用。

1.Handler的配置
Kubernetes Env最主要的一个参数是通过kubeconfigPath配置Kubeconfig的文件位置，即找到Kube- apiserver，从Kube-apiserver上获取需要的信息。配置如下:

2.Instance的配置
在Kubernetes Instance中定义Kubernetesenv Adapter如何发现和生成需要的与Pod相关的数据，如下所 述。
◎ sourceUid:源Pod的UID。
◎ sourceIp:源Pod的IP。
◎ destinationUid:目标Pod的UID。
◎ destinationIp:目标Pod的IP。
◎ destinationPort:目标容器的端口。

另外，通过定义 attribute_binding 将 Kubernetesenv Adapter 输出的属性绑定到 Mixer的属性上，可以
供其他Adapter使用。
在Kubernetes Output模板中能提取的属性如下。
(1)源 Pod 的信息:sourcePodUid、sourcePodIp、sourcePodName、sourceLabels、
sourceNamespace、sourceServiceAccountName、sourceHostIp、sourceWorkloadUid、 sourceWorkloadName、sourceWorkloadNamespace、sourceOwner。
 (2)目标 Pod 的信息:destinationPodUid、destinationPodIp、destinationPodName、
destinationContainerName、destinationLabels、destinationNamespace、destinationService AccountName、 destinationHostIp、destinationOwner、destinationWorkloadUid、destination WorkloadName、 destinationWorkloadNamespace。

istio安装时会定义Kubernetes的如下模板实例，

3.Rule的配置