Mixer 是 Istio 的核心组件之一,负责服务网格中的遥测和策略两部分重要功能,因此 Mixer 的部署也分成了 Policy 和 Telemetry 两部分。
mixer:
enabled: true
replicaCount: 1
autoscaleMin: 1
autoscaleMax: 5
image: mixer istio-policy:
autoscaleEnabled: true
autoscaleMin: 1
autoscaleMax: 5
cpu:
targetAverageUtilization: 80 istio-telemetry:
autoscaleEnabled: true
autoscaleMin: 1
autoscaleMax: 5
cpu:
targetAverageUtilization: 80 prometheusStatsdExporter:
hub: docker.io/prom
tag: v0.6.0
这里看到,和我们前面说到的功能分离相同,Policy 和 Telemetry 两个组件也是分别设置了各自的变量。根据前面几篇的经验看,istio-policy
和 istio-telemetry
两部分是用于控制两个部署的自动伸缩。而 prometheusStatsdExporter
部分则是指定了一个镜像,用于提供 Prometheus 监控使用。而从 enable
位置来看,两个组件是不推荐单独启用的,但是 HPA 是可以分别设置的。
这里可以看到,Mixer 的两个组件使用的是同一个 istio-mixer-service-account
,根据对 clusterole.yaml
的观察,可以看到如下权限:
组 | 资源 | 权限 |
---|---|---|
config.istio.io | * | 读写 |
rbac.istio.io | * | 读写 |
apiextensions.k8s.io | customresourcedefinitions | 读 |
"" | "configmaps", "endpoints", "pods", "services", "namespaces", "secrets" | 读 |
extensions | replicasets | 读 |
config.istio.io | replicasets | 读 |
autoscale.yaml
这里用了一个循环:
{{- range $key, $spec := .Values }}
{{- if or (eq $key "istio-policy") (eq $key "istio-telemetry") }}
{{- if and $spec.autoscaleEnabled $spec.autoscaleMin }}
分别遍历全局变量中的 mixer.istio-policy
和 mixer.istio-telemetry
,使用各自的 HPA 参数对伸缩过程进行配置。
两个 HPA 对象的名字来自上面的循环:istio-policy
和 istio-telemetry
。引用变量包括这两个分组中的所有变量。
这里不难发现 Mixer 中的根级变量
autoscaleMin
、autoscaleMax
是无用的,该问题在新版本中已经修正。
service.yaml
和 HPA 的情况类似,这里用循环的方式生成了两个 Service,分别为 istio-policy
和 istio-telemetry
。
端口方面,两个服务都开放了 grpc-mixer
、grcp-mixer-mtls
以及 http-monitoring
三个端口:
grpc-mixer: 9091
:用于 Mixer 的 gRPC API 端口。grpc-mixer-mtls: 15004
:启用 mtls 的时候使用的 API 端口。如果启用了 controlPlaneAuthPolicy,则使用该端口进行 Mixer API 通信。http-monitoring
:用于监测 Mixer 存活状态。另外如果是 istio-telemetry
,还多定义了一个端口 prometheus
,Prometheus 可以从这一端口获取遥测数据。
此处仅引用了 Chart
和 Release
的全局变量。
statsdtoprom.yaml
这个组件用来把 Envoy 的 Statsd 指标转换为 Promtheus 指标。这里包含了 Service 和 Deployment 两部分。
这里实际上是引用了 Prom 的一个 Exporter,除了引用了 Chart
和 Release
全局变量之外,还使用了如下几个变量:
prometheusStatsdExporter.hub
:镜像仓库的地址。prometheusStatsdExporter.tag
:镜像版本。global.imagePullPolicy
:镜像拉取策略。prometheusStatsdExporter.resources
:可以定义这一 Pod 的资源使用策略。nodeSelector
:可以根据资源情况,为该 Pod 进行节点选择,避免资源争用。除去上面的变量之外,还可以看到如下信息:
上文提到的 Configmap 来自于模板文件
configmap.yaml
,这一文件没有提供任何额外配置。
这里声明了 Exporter 的端口使用:
autoscale.yaml
这里使用 values.yaml
中定义的内容,分别给 Telemetry 和 Policy 两个组件定义了各自的自动伸缩。
缺省情况下,都是最少单副本,最多 5 副本,平均 CPU 用量 80%。
deployment.yaml
这个文件稍微有点古怪,首先分别定义了 policy_container
和 telemetry_container
两个模板,然后在文件尾部进行合并。
这个 Deployment 负责 Mixer 的策略实施功能,其主进程为 mixs,并且注入了 Sidecar。除了 Chart 和 Release 之外,引用全局变量包括:
global.priorityClassName
:Pod 优先级global.hub
:镜像仓库。global.tag
:镜像标签。image
:镜像名称,如果名称中包含 /
,则忽略 global.hub
和 global.tag
。resource
和 global.defaultResources
:如果没有特别定义资源限制,则沿用 Chart 设计的缺省限制。需要注意的是,Policy 和 Telemtry 的两个组件,资源设置是共享的同一套值。global.controlPlaneSecurityEnabled
:根据这个参数来设置 istio-proxy 的 --controlPlaneAuthPolicy
,在 MUTUAL_TLS
和 NONE
之间选择。global.proxy.resources
和 global.defaultResources
:如果没有定义全局的 Proxy 资源限制,也会沿用缺省限制。mixs policy
进程使用了 unix:///sock/mixer.socket
进行监听,这一点在 Envoy 配置中也有对应的处理。
该容器仅在命令行(args
)上和 policy
Pod 有差别,就无需介绍了。
config.yaml
这里包含了 Mixer 初始配置:
accesslog
tcpaccesslog
requestcount
requestduration
requestsize
responsesize
tcpbytesent
tcpbytereceived
metric
实例逐个映射为 Prometheus 的监控指标。stdio
:定义一条规则,将 http
和 grpc
协议的访问日志,用 accesslog
的样式输出到 stdio
。stdiotcp
:定义一条规则,将 http
和 grpc
协议的访问日志,用 tcpaccesslog
的样式输出到 stdio
。promhttp
:将 http
和 grpc
协议产生的 requestcount
、requestduration
、requestsize
以及 responsesize
四种指标送入前面建立的 Prometheus handler。promtcp
:将 tcp
协议产生的 tcpbytesent
和 tcpbytereceived
指标送入前面建立的 Prometheus handler。kubeattrgenrulerule
:将 kubernetesenv
生成的数据交由 kubernetes
属性模板处理。tcpkubeattrgenrulerule
:将 kubernetesenv
生成的 tcp 通信相关数据交由 kubernetes
属性模板处理。telemetry
控制器的连接池,如果启用了 controlPlaneSecurityEnabled
,则加入对 15004 端口的 tls 定义。在 Istio 中 Mixer 一直是一个备受争议的组件,一方面表达了 Istio 的远大设计目标,另一方面因为自身结构以及众多 Adapter 的缺陷,持续遭到用户诟病,因此上也是目前为止部署体系变化最大的一块,相信后续版本中,Mixer 还会做出频繁的好的和坏的变更。