大家知道，“服务网格”是当下科技行业的热门话题 ，Istio就是这一领域最流行的项目之一。Istio 由 IBM、谷歌和 Lyft 联合开发，用来解决当下微服务架构面临的众多问题。容器和 Kubernetes 的流行使微服务架构得到了广泛应用，但与此同时它们也带来了一系列全新的问题和挑战。

如今，我们所有的服务都在使用 HTTP/gRPC API 来互相通信。在传统的单体架构时代，这些通信只是在单个应用内部传递的函数调用而已。相比而言，在微服务体系中不同服务之间存在着大量的交互，更难观察、保护和监控。

现在，已经有很多资料介绍Istio的概况及其工作原理，这里我不再赘述。本文将着重讨论一个话题，也就是监控。Istio 的官方文档谈到了这方面的内容，但我花了不少时间才搞清楚它是怎么回事。所以我会在这篇教程中带你浏览一遍相关内容，这样你就能更好地理解如何使用 Istio 来监控任务了。

现状

选择服务网格（mesh）的主要目的之一是提高可观察性。直到现在，开发者都需要在自己的应用中插入诸如公共库或者New Relic或Datalog这样的代理服务，从而暴露一系列指标数据；这样一来，运营就能使用监控解决方案来获取应用的终端节点指标，从而知晓系统的运行状态。但为此不得不修改代码实在很麻烦，尤其是改动或新增内容较多时更让人痛苦不堪。另外多个团队都使用这种方式做监控时，代码维护也会变得很困难。

Istio 的做法是在无需改动任何代码的前提下暴露并追踪应用行为。这是通过所谓“边车（sidecar）”的概念实现的，它是一个与我们的应用共同运行，并向中央遥测组件提供数据的容器。边车能够识别应用正在使用的协议（redis、mongo、http、grpc 等），从而嗅探出与数据请求相关的大量信息。

混合器，Istio 的“瑞士军刀”

首先来看混合器（Mixer）组件，谈一谈它的作用以及它给监控带来的好处。在我看来，所谓“混合器”最好看作是一种属性处理器。网格中的代理都会发送一组内容各异的属性，比如数据请求或环境信息之类，“混合器”会处理所有这些数据并将它们分别路由到正确的适配器上。

“适配器”是附加到“混合器”上的 handler，负责为后端调整属性数据。后端可以是对这些数据感兴趣的外部服务，诸如监控工具（如 Prometheus 或 Stackdriver）、授权后端或日志堆栈。

概念

入门 Istio 最难的过程之一是熟悉新术语。你刚以为自己好容易搞明白了整个 Kubernetes 词汇表的时候，却会发现 Istio 又多出来 50 多个新术语！

在监控这方面，以下是混合器设计中最有趣且有用的一些概念：

• 属性（Attribute）：指由混合器处理的一段数据。大多数属性是从边车发送来的，但适配器也能产生属性。在实例中会使用属性将所需数据映射到后端。

• 适配器（Adapter）：嵌入在混合器组件中的逻辑，用来将数据转发到指定的后端。

• Handler：适配器的配置。由于一个适配器可以服务多个用例，因此将配置解耦就可以让适配器以多种设置来运行了。

• 实例：将来自 Istio 的数据绑定到适配器模型的实体。 Istio 有一套由边车容器获取的统一属性集，这些数据需要翻译成后端语言。

• 模板：定义实例模板的通用接口。

创建一个新的监控案例

了解过 Istio 相关的定义和概念后，我们要牢记它们的最好方法就是在真实场景中过一遍。

做这个练习时，我推荐大家充分利用 Kubernetes 的标签元数据，用它来追踪我们服务的版本迭代。一般来说，转向微服务架构后你的服务最后都会有很多版本（A/B 测试，API 版本等）。 Istio 的边车会将你的群集中的所有元数据都发送到混合器。所以在我们这个示例中，我们将利用部署的标签来识别服务的版本，并观察每个版本的使用状况统计信息。

简单起见我们先来找一个现成的项目，用谷歌微服务演示项目就行了，然后做一些修改以适用我们的方案。这个项目模拟了一个由多个组件组成的微服务架构，用来构建一个电子商务网站。

首先，我们要确保这个项目与 Istio 一起能在我们的集群中正确运行。我们使用自动注入功能在命名空间中部署所有组件，并让 Istio 自动注入边车。

$ kubectl label namespace mesh istio-injection=enabled

警告：一定要提前创建 mesh 命名空间，并让你的 kubectl 上下文指向它。

如果启用了一个 pod 安全策略，则需要为 init 容器配置一些权限，以使其能正确配置 iptables。出于测试目的你可以使用：

$ kubectl create clusterrolebinding mesh --clusterrole cluster-admin --serviceaccount=mesh:default

这会将默认服务帐户绑定到群集管理员角色。现在我们可以使用全资源 YAML 文档来部署所有组件了。

$ kubectl apply -f release/kubernetes-manifests.yaml

现在你应该能看到 pod 在 mesh 命名空间中开始运行了。其中一些 pod 会出错，因为 Istio 资源还没添加进去。例如，出口流量会被阻止，currency 组件也会出错。用下面这些资源来解决问题，并通过 Istio ingress 暴露前端组件。

$ kubectl apply -f release/istio-manifests.yaml

现在我们就可以查看正在使用你的云服务商提供的 IP 或域工作的前端了（frontend-external 服务通过云服务商的负载均衡器暴露）。

现在我们的微服务应用开始工作了，下面再进一步，将其中一个组件配置为多个版本。正像你在微服务 YAML 中看到的那样，部署会有带着应用名称的单个标签。如果我们要管理 canary 部署或运行我们应用的多个版本，我们可以添加另一个版本标签。

apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: currencyservicespec:  template:    metadata:      labels:        app: currencyservice        version: v1

将更改应用于我们的集群后，我们可以用其他名称复制部署并更改版本。

apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: currencyservice2spec:  template:    metadata:      labels:        app: currencyservice        version: v2

现在再次将其提交给 API。

$ kubectl apply -f release/kubernetes-manifests.yaml

注意：虽然我们又一次应用了所有的清单，但只有已更改的清单才会由 API 更新。

一位热心读者注意到我们用了一个技巧，就是让服务选择器只指向 app 标签。这样一来流量就会在不同版本之间平等分配了。

进阶之路

现在轮到重头戏了。我们需要创建三份资源来将版本暴露为 prometheus 中的新指标。

首先，我们创建一个实例。在这里我们使用 metric 实例模板来将边车提供的值提供程序映射到适配器的输入端。我们只看负载的名称（源）和版本。

apiVersion: "config.istio.io/v1alpha2"kind: metricmetadata:  name: versioncount  namespace: meshspec:  value: "1"  dimensions:    source: source.workload.name | "unknown"    version: destination.labels["version"] | "unknown"  monitored_resource_type: '"UNSPECIFIED"'

现在该配置适配器了。在这个示例中我们希望将指标连接到一个 Prometheus 后端。所以我们要在 handler 配置中定义指标名称，以及指标会为后端（Prometheus DSL）提供的数值类型，此外还有维度标识所需的标签名称。

apiVersion: "config.istio.io/v1alpha2"kind: prometheusmetadata:  name: versionhandler  namespace: meshspec:  metrics:  - name: version_count # Prometheus metric name
    instance_name: versioncount.metric.mesh # Mixer instance name (fully-qualified)    kind: COUNTER    label_names:    - source
    - version

最后，我们需要将这个 handler 与指定的实例（指标）链接起来。

apiVersion: "config.istio.io/v1alpha2"kind: rulemetadata:  name: versionprom  namespace: meshspec:  match: destination.service == "currencyservice.mesh.svc.cluster.local"   actions:  - handler: versionhandler.prometheus
    instances:    - versioncount.metric.mesh

一旦应用了这些定义，Istio 将指示 prometheus 适配器开始收集并提供新指标。如果我们看一下 prometheus 用户界面，会发现它现在正在搜索新指标，内容类似于：

结论

微服务架构中获得良好的可观察性并不容易。 Istio 有助于简化开发者的工作，并将工作交给运营商。

一开始，处理服务网格带来的各种复杂问题可能很难。但是一旦你驯服了它，就能让监控配置标准化和自动化，并在极短时间内构建一个出色的可观察系统。

更多资料

• 如何在集群中安装Istio
  

• 官方https://istio.io/docs/](https://istio.io/docs/">文档与示例

作者简介

Fernando Ripoll

Giant Swarm 的解决方案工程师，以丰富的经验帮助客户使他们的 Kubernetes 走上正轨。

查看英文原文：https://blog.giantswarm.io/Istio-monitoring-explained/