ISTIO telemetry V2 介绍

 阿里云安全     |      2020-04-18 00:00:00

背景

ISTIO 早期版本(1.4以前)的架构非常优雅， 模块之间解耦清晰，职责分明。 但现在看来有一定理想化，所有流量通过Mixer，通过Mixer 统一采集和上报所有的遥测数据和服务间访问鉴权，导致一旦规模上来，Mixer 非常容易成为性能瓶颈。

image.png



Telemetry V2介绍 

在1.4中，ISTIO提出 Mixer-less telemetry 架构，将Mixer 从主流程抽离。 将遥测和服务鉴权能力下沉到每个服务的代理Proxy Envoy中。了解ISTIO 以前架构的同学应该都知道，Mixer 是一个热拔插组件，有极好的扩展性。 支持代码中注册编写Adapter并重新打包的方式更新遥测对接的配置，也支持配置 Out Of Process Adapter  这样的外部适配器，进行遥测的对接和动态配置。但提供灵活性同时，也成为了整个ISTIO 明显的性能瓶颈。

image.png


image.png

Istio 中Telemetry V2的实现

那么ISTIO 1.4 是如何实现 Mixerless 的呢？
在1.4中， 服务的遥测和访问鉴权从Mixer逐渐开始下沉到Envoy中， 从而经过我们应用的出入流量不必全部上报到Mixer，实现了Mixer 旁路。   服务遥测在Envoy中完成追踪服务之间的流量请求，并在Envoy所在Pod中监听相关端口，提供Prometheus采集指标。

image.png

那么在ISTIO 支持EnvoyFilter  这个CRD，它提供一种机制，可以帮助我们定制 Pilot 所生成并下发给Envoy 配置，在EnvoyFilter中我们能够定义生效的pod范围，注入的时机以及执行内容。 同样EnvoyFilter支持WebAssembly,  我们可以通过EnvoyFilter 配置WebAssembly的执行时机，实现Envoy 的流量管理策略的更新， 例如：  https://istio.io/blog/2020/deploy-wasm-declarative/ 。
目前在ISTIO 维护的Envoy proxy中， 支持部分内置的WebAssembly 扩展， 目前有4个内置WebAssembly扩展（access_log_policy，stackdriver， stats，metadata_exchange）代码： https://github.com/istio/proxy/tree/master/extensions 

  • 其中access_log_policy，stackdriver 是用于往Google StackDriver推送数据

  • metadata_exchange和stats 用于遥测。 

    • metadata_exchange 会做reqeust和response的上下游标记，记录请求
    • stats 采集请求相关监控指标，暴露Prometheus 可采集的接口。

image.png

阿里云服务网格

阿里云服务网格 目前已经通过Telemetry V2的方式支持Prometheus 监控遥测，您可以在控制台一键开启或者关闭遥测功能，并将监控数据采集到自建Prometheus 或者 阿里云ARMS 中。

阿里云服务网格动态配置遥测

image.png

查看请求数据的监控大盘

image.png