mixer | 伪架构师

Istio 1.1 中的限流问题

Sat, 23 Mar 2019 01:55:47 +0800

在 Istio 1.1 发布之后，对《深入浅出 Istio》一书中的例子进行了一遍快速的检查，发现限流功能已经无法使用了。

在解决了 Prometheus 的 Handler 问题之后，开始查看限流的问题。

Mixer 日志控制的两个小技巧

Mixer 策略相关内容比较多，经常需要查看 Policy 和 Telemetry 的日志，然而这两种进程的缺省日志都是很多的，可以用一点小技巧来进行清理。

GODEBUG

首先，Mixer 的两个 Deployment 中都会带有 GODEBUG 环境变量，用于开启调试信息，可以使用 kubectl edit 命令删除环境变量。

ControlZ

Istio 组件都带有 ControlZ 接口，可以用于控制和查看核心组件的一些配置信息，其端口都开放在 9876，可以用端口转发的方式打开进行调整，例如：

$ kubectl port-forward -n istio-system \
> istio-telemetry-c545bb9bd-x7jpz 9876:9876
Forwarding from 127.0.0.1:9876 -> 9876
Forwarding from [::1]:9876 -> 9876

然后就可以用浏览器打开 http://127.0.0.1:9876 进行调整了。

言归正传

应用书中的 YAML 代码的同时，可以打开 Mixer 的日志，会发现其中有几行错误：

error  failed to evaluate expression for field 'Dimensions[destination]'; unknown attribute destination.service
error  Instance not found: instance='dest-quota.quota'
error  No valid instances found                                                error  No valid actions found in rule

这里发现了一个无法识别的属性：destination.service。翻查文档发现，该属性在 Istio 1.0 的 Reference 中声明即将过期;在 1.1 中已经停用，因此将其改为 destination.service.host 即可正常使用。更新代码已经上传到随书代码库的 1.1 分支中的第八章内容里。

Istio 1.1 中的 Handler

Fri, 22 Mar 2019 19:18:15 +0800

一直觉得 Mixer 的功能会比较不稳定，这次在《深入浅出 Istio》一书的的验证过程中发现，Prometheus 的部分无法工作了，因此今天排查一下，也因此有了些收获，这里做一个简单的记录。

首先我发现，istio-system 中系统默认安装的 Prometheus 资源不见了：

$ kubectl get prometheus --all-namespaces
No resources found.

但是好在相关的 Rule 还在，写法有了一些变化，例如 istio-system 中的 promtcp 的定义：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
...
  name: promtcp
  namespace: istio-system
spec:
  actions:
  - handler: prometheus
    instances:
    - tcpbytesent.metric
    - tcpbytereceived.metric
  match: context.protocol == "tcp"

过去我们习惯的 Handler 填写一般会是 handler.prometheus，也就是名为 handler 的 prometheus 资源。例如官方文档中的写法：

# Rule to send metric instances to a Prometheus handler
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: doubleprom
  namespace: istio-system
spec:
  actions:
  - handler: doublehandler.prometheus
    instances:
    - doublerequestcount.metric

很明显的，1.1 的用法发生了变更，这个新用法中并没有提及对象名称，只知道名字是 prometheus。在 Istio 1.1 的 Helm 源码中搜索一下 name: prometheus 就会看到，在 helm/istio/charts/mixer/templates/config.yaml 中定义了一个对象，一个 handler 类型的对象：

apiVersion: "config.istio.io/v1alpha2"
kind: handler
metadata:
  name: prometheus

这样就可以查查他的定义了，运行 kubectl get -n istio-system handler prometheus -o yaml：

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
...
  name: prometheus
  namespace: istio-system
...
spec:
  compiledAdapter: prometheus
  params:
    metrics:
    - instance_name: requestcount.metric.istio-system
...

是的，这个名为 prometheus 的 handler 对象和以前几乎一毛一样。现在有两种定义 Prometheus 的 Handler 了，对此开发给出的解释是，并非所有 Adapter 都会创建自己的 CRD，因此推荐共用的 Handler 类型来进行定义。

在 Reference 中对这一对象做了个大概的讲解。需要注意其中的 compiledAdapter: prometheus，用于指定 Adapter 类型。其中使用 compiledAdapter 和 adapter 两个字段分别用于描述进程内外的两种适配器类型。

因此在 1.1 中，Handler 真正的成为了 Handler，下面给出一个简单的定义，来讲解一下自定义指标中，新 Handler 的定义方法，其中给指标定义名称为 cxl_counter：

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  labels:
    app: mixer
    chart: mixer
    heritage: Tiller
    release: istio
  name: prometheus
spec:
  compiledAdapter: prometheus
  params:
    metrics:
      - instance_name: cxl.metric.default
        kind: COUNTER
        label_names:
          - source_app
          - source_workload
          - source_workload_namespace
          - source_version
          - destination_app
          - destination_workload
          - destination_workload_namespace
          - destination_version
          - destination_service
          - destination_service_name
          - destination_service_namespace
          - reporter
          - response_code
        name: cxl_counter
    metricsExpirationPolicy:
      metricsExpiryDuration: 10m

原有 Handler 的定义方式，同样的指标，定义为 double_counter：

apiVersion: config.istio.io/v1alpha2
kind: prometheus
metadata:
  name: handler
spec:
  metrics:
    - instance_name: cxl.metric.default
      kind: COUNTER
      label_names:
        - source_app
        - source_workload
        - source_workload_namespace
        - source_version
        - destination_app
        - destination_workload
        - destination_workload_namespace
        - destination_version
        - destination_service
        - destination_service_name
        - destination_service_namespace
        - reporter
        - response_code
      name: double_counter
  metricsExpirationPolicy:
    metricsExpiryDuration: 10m

用一个 Rule，将同样的指标分别输出到两个 Handler 之中：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: prom-http
spec:
  actions:
    - handler: prometheus
      instances:
        - cxl.metric
    - handler: handler.prometheus
      instances:
        - cxl.metric
  match: context.protocol == "http" || context.protocol == "grpc"

而指标的定义不变：

apiVersion: config.istio.io/v1alpha2
kind: metric
metadata:
  name: cxl
spec:
  dimensions:
    destination_app: destination.labels["app"] | "unknown"
    destination_service: destination.service.host | "unknown"
    destination_service_name: destination.service.name | "unknown"
    destination_service_namespace: destination.service.namespace | "unknown"
    destination_version: destination.labels["version"] | "unknown"
    destination_workload: destination.workload.name | "unknown"
    destination_workload_namespace: destination.workload.namespace | "unknown"
    source_app: source.labels["app"] | "unknown"
    source_version: source.labels["version"] | "unknown"
    source_workload: source.workload.name | "unknown"
    source_workload_namespace: source.workload.namespace | "unknown"
    reporter:
      conditional((context.reporter.kind | "inbound") == "outbound", "source",
      "destination")
    response_code: response.code | 200
  monitored_resource_type: '"UNSPECIFIED"'
  value: "2"

制造请求之后，会发现新旧 Handler 同时工作，并用各自的名字写入了指标。在 Prometheus 中即可查看。

这里真的要吐槽一句，Metric 定义中的所有 Label 需要照抄到 Handler 定义中，映射关系出错的时候，出的不是 Warning，而是 Panic。

涉及到的代码已经更新到版本库的 1.1 分支的第八章内容里。

Istio Helm Chart 详解 - Mixer

Mon, 05 Nov 2018 16:37:23 +0800

前言

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-policy 和 istio-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-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 两部分。

Deployment

这里实际上是引用了 Prom 的一个 Exporter，除了引用了 Chart 和 Release 全局变量之外，还使用了如下几个变量：

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_container 和 telemetry_container 两个模板，然后在文件尾部进行合并。

policy_container

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

global.priorityClassName：Pod 优先级
global.hub：镜像仓库。
global.tag：镜像标签。
image：镜像名称，如果名称中包含 /，则忽略 global.hub 和 global.tag。
resource 和 global.defaultResources：如果没有特别定义资源限制，则沿用 Chart 设计的缺省限制。需要注意的是，Policy 和 Telemetry 的两个组件，资源设置是共享的同一套值。
global.controlPlaneSecurityEnabled：根据这个参数来设置 istio-proxy 的 --controlPlaneAuthPolicy，在 MUTUAL_TLS 和 NONE 之间选择。
global.proxy.resources 和 global.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：定义一条规则，将 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 属性模板处理。
目标规则：两条规则分别定义了到 policy 和 telemetry控制器的连接池，如果启用了 controlPlaneSecurityEnabled，则加入对 15004 端口的 tls 定义。

总结

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

试译：Mixer 的适配器模型

Fri, 10 Nov 2017 09:53:02 +0800

原文：Mixer Adapter Model

Mixer 插件架构概述

Istio 0.2 引入了新的 Mixer 适配器模型，从而具有了更大的灵活性去接入各种基础设施后端。本文尝试讲述这一模型及其工作机制。

为什么是适配器模型？

各种基础设施都提供了用于支持服务构建的功能，例如访问控制、遥测、配额、计费等等。传统服务会直接和这些后端系统打交道，和后端紧密耦合，并集成其中的个性化语义以及用法。

Mixer 服务构成了基础设施和 Istio 之间的抽象层。Istio 组件和运行于 Service Mesh 中的服务，借助 Mixer 的能力就能在不直接访问后端接口的情况下和这些后端进行交互。

Mixer 除了作为应用和基础设施之间的隔离层之外，操作者还可以借助 Mixer 的中介模型，注入或者操作应用和后端之间的策略，例如哪些数据需要报告给哪些后端、哪些后端提供认证等。

每种后端都有各自不同的接口和操作方式，因此 Mixer 需要有代码来支持这种差异，我们称这些内容为适配器。

适配器是 Go 包的形式存在的，直接链接到 Mixer 二进制中。如果缺省适配器无法满足特定的用例，创建自己的适配器也是比较简单的。

哲学

本质上 Mixer 这个模块就是用来处理属性和路由的。代理把属性作为前置检查和遥测报告的一部分发送出来，转换为对适配器的一系列调用。运维人员提供了用于描述如何将属性转换为适配器指令的配置。

配置是一个复杂的任务。有证据表明，绝大多数的服务中断都来自于配置错误。为了解决这一问题，Mixer 加入了很多限制来避免错误。例如在配置中使用强类型，以此保障在任何上下文中都只能使用有意义的属性或表达式。

Handler：适配器的配置

Mixer 使用的每个适配器都需要一些配置来进行操作。一般来说适配器需要一些数据进项实例化，例如后端的 URL、认证信息、缓存选项等等。每个适配器使用一个 protobuf 消息来定义所需的配置数据。

可以通过创建 Handler 的方式来为适配器提供配置。Handler 就是一套能让一个适配器就绪的完整配置。对同一个适配器可以有任意数量的 Handler，这样就可以在不同场景下复用了。

例如：memquota 适配器，可以配置多个不同的 Handler，用于进行不同的限制。或者同类服务的不同服务端点的实例

Template（模板？）：适配器的输入结构（Schema）

一个请求到达 Mesh 中的服务时，一般会发生两次对 Mixer 的调用，一次是前置检查，一次是遥测报告。每一次这种调用，Mixer 都需要调用一个或更多的适配器。不同的适配器需要不同的数据块作为输入来进行处理。例如日志适配器需要日志输入，指标适配器需要指标输入，认证适配器需要凭据输入。适配器在请求时消费的数据就是由 Mixer 的 Template 来描述的。

每个 Template 对应一个 protobuf 消息。在运行时一个 Templates 描述了一系列的发送给一或多个适配器的数据。适配器和 Template 是多对多的关系，其对应关系由开发者决定。

Metric（指标）和Logentry（日志条目）是最重要的两个 Template，分别用于描述工作负载的一个指标和一条日志。

Template 定义同样来自于 Adapter

Instances(实例？) ：属性映射

创建 Instance 用于决定把什么数据发送给特定的适配器。Instance 决定了 Mixer 如何把来自代理的属性拆分为各种数据然后分发给不同的适配器。

一般来说需要使用 Attribute Expression 来创建 Instance。属性表达式的功能是使用属性和常量来生成可以给 Instance 字段赋值的结果。

每个 Instance 字段都有类型，类型的定义来自于 Template，每个属性也有类型，然后每个属性表达式还是有类型。只有类型一致的情况才可以进行赋值。例如不能把整数型的表达式赋值给字符串字段。强类型设计的目的就是降低配置出错引发的风险。

Rules（规则）：把数据分发给适配器

拼图的最后一块就是 Rules，他负责告诉 Mixer，哪个 Instance 应该在什么时候发送给哪个 Handler。每个 Rule 包含了一系列的 Instance，以及将要发送这些 Instance 的目标 Handler。Mixer 被触发以后，就会调用指定的 Handler，令其处理指定的 Instance。

Rules 包含有匹配断言，这一断言是一个返回布尔值的属性表达式。只有断言成功的属性表达式才会触发 Handler。

符合条件的 Instance 被发给 Handler

未来

我们一直在尝试提高适配器的使用和开发的端到端体验。例如计划中包含很多特性来帮助用户更方便的创建 Tempalte。另外表达式语言也在不断地发展和成熟。

长期来看，我们在评估如何让适配器不再直接连入 Mixer 的方式，这样会更加方便的进行开发和使用。

结论

新的 Mixer 适配器模型，设计目的是提供一个有弹性的框架，以此支持开放的基础设施后端。

Handler 为适配器提供了配置，Template 在运行时能够决定不同的适配器需要的数据种类，数据经由 Instance，被 Rules 发送给一个或多个 Handler。

策略和控制中介绍了更多的 Mixer 架构的内容，Mixer 参考包含更多的 Template、Handler 以及 Rules 的内容。Bookinfo 示例中提供了对应的示例文件。