首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Istio Helm Chart 详解 - Mixer

Istio Helm Chart 详解 - Mixer

作者头像
崔秀龙
发布2019-07-23 15:18:56
7040
发布2019-07-23 15:18:56
举报
文章被收录于专栏:伪架构师伪架构师

前言

Mixer 是 Istio 的核心组件之一,负责服务网格中的遥测和策略两部分重要功能,因此 Mixer 的部署也分成了 Policy 和 Telemetry 两部分。

values.yaml 中的全局变量

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-policyistio-telemetry 两部分是用于控制两个部署的自动伸缩。而 prometheusStatsdExporter 部分则是指定了一个镜像,用于提供 Prometheus 监控使用。而从 enable 位置来看,两个组件是不推荐单独启用的,但是 HPA 是可以分别设置的。

RBAC 相关

这里可以看到,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-policymixer.istio-telemetry,使用各自的 HPA 参数对伸缩过程进行配置。

两个 HPA 对象的名字来自上面的循环:istio-policyistio-telemetry。引用变量包括这两个分组中的所有变量。

这里不难发现 Mixer 中的根级变量 autoscaleMinautoscaleMax 是无用的,该问题在新版本中已经修正。

service.yaml

和 HPA 的情况类似,这里用循环的方式生成了两个 Service,分别为 istio-policyistio-telemetry

端口方面,两个服务都开放了 grpc-mixergrcp-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 可以从这一端口获取遥测数据。

此处仅引用了 ChartRelease 的全局变量。

statsdtoprom.yaml

这个组件用来把 Envoy 的 Statsd 指标转换为 Promtheus 指标。这里包含了 Service 和 Deployment 两部分。

Deployment

这里实际上是引用了 Prom 的一个 Exporter,除了引用了 ChartRelease 全局变量之外,还使用了如下几个变量:

  • prometheusStatsdExporter.hub:镜像仓库的地址。
  • prometheusStatsdExporter.tag:镜像版本。
  • global.imagePullPolicy:镜像拉取策略。
  • prometheusStatsdExporter.resources:可以定义这一 Pod 的资源使用策略。
  • nodeSelector:可以根据资源情况,为该 Pod 进行节点选择,避免资源争用。

除去上面的变量之外,还可以看到如下信息:

  • 该 Pod 不接受自动注入。
  • 开放了 TCP 端口 9102 以及 UDP 端口 9125。
  • 加载一个 ConfigMap:istio-statsd-prom-bridge,用于配置文件。

上文提到的 Configmap 来自于模板文件 configmap.yaml,这一文件没有提供任何额外配置。

Service

这里声明了 Exporter 的端口使用:

  • TCP 端口 9102 提供给 Prometheus 进行数据抓取。
  • UDP 端口 9125,Envoy 会发送指标进入 Exporter。

autoscale.yaml

这里使用 values.yaml 中定义的内容,分别给 Telemetry 和 Policy 两个组件定义了各自的自动伸缩。

缺省情况下,都是最少单副本,最多 5 副本,平均 CPU 用量 80%。

deployment.yaml

这个文件稍微有点古怪,首先分别定义了 policy_containertelemetry_container 两个模板,然后在文件尾部进行合并。

policy_container

这个 Deployment 负责 Mixer 的策略实施功能,其主进程为 mixs,并且注入了 Sidecar。除了 Chart 和 Release 之外,引用全局变量包括:

  • global.priorityClassName:Pod 优先级
  • global.hub:镜像仓库。
  • global.tag:镜像标签。
  • image:镜像名称,如果名称中包含 /,则忽略 global.hubglobal.tag
  • resourceglobal.defaultResources:如果没有特别定义资源限制,则沿用 Chart 设计的缺省限制。需要注意的是,Policy 和 Telemtry 的两个组件,资源设置是共享的同一套值。
  • global.controlPlaneSecurityEnabled:根据这个参数来设置 istio-proxy--controlPlaneAuthPolicy,在 MUTUAL_TLSNONE 之间选择。
  • global.proxy.resourcesglobal.defaultResources:如果没有定义全局的 Proxy 资源限制,也会沿用缺省限制。

mixs policy 进程使用了 unix:///sock/mixer.socket 进行监听,这一点在 Envoy 配置中也有对应的处理。

telemetry_container

该容器仅在命令行(args)上和 policy Pod 有差别,就无需介绍了。

config.yaml

这里包含了 Mixer 初始配置:

  • attributemanifest:
    • istioproxy:定义了 Sidecar 中的属性清单。
    • kubernetes:Kubernetes 相关的属性清单。
  • stdio:定义使用 JSON 格式进行输出的 stdio handler。
  • logentry:定义了两个不同用途的日志模板实例,用不同属性组成不同内容,用于记录访问日志:
    • accesslog
    • tcpaccesslog
  • metric 对象用于定义遥测数据的结构清单:
    • requestcount
    • requestduration
    • requestsize
    • responsesize
    • tcpbytesent
    • tcpbytereceived
  • prometheus Handler:把前面定义的 metric 实例逐个映射为 Prometheus 的监控指标。
  • kubernetesenv:该 Handler 为 Mixer 提供 Kubernetes 集群的连接。
  • kubernetes:用于生成 Kubernetes 相关的数据。
  • rule:
    • stdio:定义一条规则,将 httpgrpc 协议的访问日志,用 accesslog 的样式输出到 stdio
    • stdiotcp:定义一条规则,将 httpgrpc 协议的访问日志,用 tcpaccesslog 的样式输出到 stdio
    • promhttp:将 httpgrpc 协议产生的 requestcountrequestdurationrequestsize 以及 responsesize 四种指标送入前面建立的 Prometheus handler。
    • promtcp:将 tcp 协议产生的 tcpbytesenttcpbytereceived 指标送入前面建立的 Prometheus handler。
    • kubeattrgenrulerule:将 kubernetesenv 生成的数据交由 kubernetes 属性模板处理。
    • tcpkubeattrgenrulerule:将 kubernetesenv 生成的 tcp 通信相关数据交由 kubernetes 属性模板处理。
  • 目标规则:两条规则分别定义了到 policy 和 telemetry控制器的连接池,如果启用了 controlPlaneSecurityEnabled,则加入对 15004 端口的 tls 定义。

总结

在 Istio 中 Mixer 一直是一个备受争议的组件,一方面表达了 Istio 的远大设计目标,另一方面因为自身结构以及众多 Adapter 的缺陷,持续遭到用户诟病,因此上也是目前为止部署体系变化最大的一块,相信后续版本中,Mixer 还会做出频繁的好的和坏的变更。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-11-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 伪架构师 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • values.yaml 中的全局变量
  • RBAC 相关
  • autoscale.yaml
  • service.yaml
  • statsdtoprom.yaml
    • Deployment
      • Service
      • autoscale.yaml
      • deployment.yaml
        • policy_container
          • telemetry_container
          • config.yaml
          • 总结
          相关产品与服务
          容器服务
          腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档