Istio Mixer组件和服务的重要说明

[TOC]

Istio Mixer组件和服务的重要说明

Mixer的Service和Pod

三个Service【statsd、Policy、Telemetry】

Mixer分为Policy和Telemetry两个子模块。Policy用于向Envoy提供准入策略控制，黑白名单控制，速率限制等相关策略；Telemetry为Envoy提供了数据上报和日志搜集服务，以用于监控告警和日志查询。

Mixer Policy和Mixer Telemetry很容易成为整个集群的性能短板，由于Envoy发起每一个请求前都须要对Policy服务进行Check请求，一方面增长了业务请求自己的延迟，一方面也给做为单点的Policy增大了负载压力。若是追求性能，能够裁剪一些功能如速率限制，全局配额等，禁用Mixer的Policy

Istio 在 UAEK 中的实践改造之路中有对这个的较多说明。

istio-statsd-prom-bridge 这个服务也是mixer会提供的，经过安装参数--set mixer.enabled=false就禁能了这个组件，禁能这个组件会致使envoy初始化失败，报错日志error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge

Policy、Telemetry 、statsd详解

kubectl get svc -n istio-system能够发现会有两个和Mixer相关的Service

• istio-policy

  • Mixer相关组件，用于与envoy交互，check须要上报的数据，肯定缓存内容，挂掉会影响check相关功能，除非设置为不进行check

  • Envoy会在每次请求发送前向Mixer Policy发送Check请求检查该请求是否收策略限制或者配额限制

  • 不能直接关闭或者说禁能这个策略组件，由于默认请求都是要去policy pods进行check检测的，若是失败则会致使请求失败，详见

  • 若是要禁能全部的policy策略检查，须要从新编辑整个服务网格的配置，而且重启pilot 容器

  • 全局选项--set global.disablePolicyChecks=true能够禁止策略检查，而后对应的helm install的value.yaml的配置这里修改disablePolicyChecks为true也是OK的。注意这些个策略的更改须要稍等一些时间才能所有生效。修改完须要重启pilot。

  • 经过安装参数--set mixer.enabled=false禁能Mixer组件

• istio-telemetry

  • Mixer相关组件的Service，用于采集envoy上报的遥测数据，该组件挂掉将致使各监控运维插件没法采集到数据，同时，该组件在高并发情境下，会承受较大负荷，建议设置为多实例，加强可靠性

  • Envoy每次请求接收后会向Mixer Telemetry上报本次请求的基本信息，如调用是否成功、返回状态码、耗时数据。

  • 暴露909一、909三、1500四、42422端口

    • 9093端口是Mixer组件自己的prometheus暴露的端口
    • 42422是全部 Mixer 生成的网格指标

  • 经过安装参数--set mixer.enabled=false禁能Mixer组件

• istio-statsd-prom-bridge

  • 暴露910二、9125端口

  • 这个 statsd是一个转换为prometheus的组件，用来统计envoy 生成的数据，这个是必须的

  • 经过安装参数--set mixer.enabled=false就禁能了这个组件，禁能这个组件会致使ingressgateway的envoy初始化失败，报错日志error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge，由于statsdUdpAddress这个参数指定了地址为istio-statsd-prom-bridge:9125，所以还须要修改istio这个configmap中的statsdUdpAddress地址

    • 这就须要外部的statsd_exporter支持，关于statsd exporter的更多信息查看这里

  • 安装选项global.proxy.envoyStatsd.enabled能够控制envoy是否直接经过statsd上报，global.proxy.envoyStatsd.host和global.proxy.envoyStatsd.port能够设置statsd exporter的地址

• 总体而言，彻底禁用Mixer的话，须要配置：

  • envoy的statsd exporter的地址【statsdUdpAddress】
  • set global.disablePolicyChecks=true
  • set mixer.enabled=false

若是直接经过安装参数--set mixer.enabled=false禁能Mixer组件后，访问会报错以下：

[2018-10-12T09:21:17.749Z] "GET /wudebao HTTP/1.1" 503 - 0 33 0 - "192.168.65.3" "curl/7.54.0" "457cf709-2396-953e-b9e0-c405c9c56544" "www.wudebao-web.com" "-"
[libprotobuf ERROR src/istio/mixerclient/report_batch.cc:83] Mixer Report failed with: UNAVAILABLE:Cluster not available
复制代码

不过，这个异步的report上报不会影响使用，也就是不会影响正常流程。只有同步的check才会影响到流程和功能使用，设置全局选项不进行check便可解决，可是须要注意envoy的statsdUdpAddress

修改 install/kubernetes/helm/istio/charts/mixer/templates/deployment.yaml 和 service.yaml ，删除掉policy配置，而后更新就不会再部署policy了 。或者直接将install/kubernetes/helm/istio/charts/mixer/templates/deployment.yaml 和 service.yaml文件移除，就都不会部署istio-telemetry 和 istio-policy，这个作法还会部署istio-statsd-prom-bridge ，其实这正是咱们想要的。

不过问题在于，没法经过选型参数来禁止istio-telemetry 和 istio-policy，这个后面还须要再研究研究。

Mixer的check和report

须要check的 policy 策略

envoy的每一个前置请求都要到mixer中进行check，这个check必然会致使一些性能的下降，抛开性能不谈，先看看这个check的究竟是哪些策略，有些什么策略能够check，check完会如何？

首先要说明的是，这些策略的检测，是人为控制的，也就是并不是是istio自带就有会这些策略须要检测，而是须要人为去配置一些策略。

envoy发起check请求的时候，会根据收到的请求生成指定的attributes，而后attributes做为参数之一贯Mixer发起Check rpc请求。Mixer中若是有对应的adapter，则会进行处理而后返回响应结果，而后envoy根据结果决定是否执行请求或拒绝请求。

一些常见的check策略如：白名单检查、ACL检查、速率限制等，其实这些功能都是相对来讲对业务更为友好的一些功能，因此，若是性能问题不是一个大的瓶颈下的话，这个组件最好仍是保留较好。

须要report的Telemetry遥测报告

Mixer提供了一个GRPC接口，这个接口负责接收Envoy上报的数据，Envoy会向Mixer上报日志、监控（log、metrics）等数据，Envoy上报的原始数据都是一些属性词汇，而后Mixer会转换，最终会分发到logentry 和 Metric，Mixer后端的adapter（如prometheus）会基于遥测数据作进一步处理。

Proxy代理（Envoy sidecar）是在执行请求以后才须要Report，调用Mixer进行上报，这个属于后置上报，是异步的处理流程，模式是fire-and-forget，固然若是后端adapter处理不过来，没法Response给Envoy的话一样仍是会影响到Envoy的性能。

从一些Default Metrics中能够看到提供给外界的一些监控指标是很是重要的，有助于咱们去分析整个系统和后端adapter

遥测相关的后端包含：

• Tracing
• prometheus
• grafana
• serviceGraph
• Metrics
• Fluentd

固然，prometheus、grafana、Tracing等能够直接经过envoy，而不通过Mixer；通过Mixer能够查询到更丰富的数据，固然缺陷就在于多了一层下降性能。

问题 & TODO

没法经过选项参数来禁止istio-telemetry 和 istio-policy，这个后面还须要再研究研究。能够将helm install下的相关的Service和Deployment文件移除，而后helm install 或者 upgrade

【"欢迎关注个人微信公众号：Linux 服务端系统研发，后面会大力经过微信公众号发送优质文章"】