必读！Istio Service Mesh中的策略与遥测概念详解

Posted ServiceMesher

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了必读！Istio Service Mesh中的策略与遥测概念详解相关的知识，希望对你有一定的参考价值。

编者注：Istio Service Mesh中的策略与遥测功能就是Mixer组件干的活，Mixer组件中使用Adapter对接了各种各样的基础设施后端，虽然Sidecar具有本地缓存，从而可以在缓存中执行相对较大比例的前提条件检查，缓冲出站遥测，使其实际上不需要经常调用Mixer。而独立运行的Mixer可以使用相当大的缓存和输出缓冲区，可用作Sidecar的高度扩展且高度可用的二级缓存。但是其性能还是存疑的，不过不管你用还是不用，还是要了解下，Istio为什么要设计Mixer这个组件，它存在的意义是什么。

之前给大家分享了两篇、，这次再给大家分享一篇Istio中重要功能——策略（policy）与遥测（telemetry）的解析。

Istio 提供灵活的模型来执行授权策略，并为网格中的服务收集遥测数据。

基础设施后端旨在提供用于构建服务的支持功能。它们包括访问控制系统、遥测捕获系统、配额执行系统以及计费系统等等。服务传统上直接与这些后端系统集成，创建硬耦合，还有沾染特定的语义和使用选项。

Istio 提供统一抽象，使得 Istio 可以与一组开放式基础设施后端进行交互。这样做是为了给运维提供丰富而深入的控制，同时不给服务开发人员带来负担。Istio 旨在改变层与层之间的边界，以减少系统复杂性，消除服务代码中的策略逻辑并将控制权交给运维。

Mixer 是负责提供策略控制和遥测收集的 Istio 组件：

必读！Istio Service Mesh中的策略与遥测概念详解

Mixer 拓扑

在每次请求执行先决条件检查之前以及在每次报告遥测请求之后，Envoy sidecar 在逻辑上调用 Mixer。 该 Sidecar 具有本地缓存，从而可以在缓存中执行相对较大比例的前提条件检查。此外，sidecar 缓冲出站遥测，使其实际上不需要经常调用 Mixer。

在高层次上，Mixer 提供：

  • 后端抽象。Mixer 隔离 Istio 的其余部分和各个基础设施后端的实现细节。

  • 中介。Mixer 允许运维对网格和基础设施后端之间的所有交互进行细化控制。

除了这些纯粹的功能方面，Mixer 还具有如下所述的可靠性和可扩展性方面的优势。

策略执行和遥测收集完全由配置驱动。可以完全禁用这些功能，并免除在 Istio 部署中运行 Mixer 组件的必要性。

适配器

Mixer 是高度模块化和可扩展的组件。它的一个关键功能就是把不同后端的策略和遥测收集系统的细节进行抽象，完成 Istio 其余部分和这些后端的隔离。

Mixer 处理不同基础设施后端的灵活性是通过使用通用插件模型实现的。每个插件都被称为 Adapter，Mixer 通过它们与不同的基础设施后端连接，这些后端可提供核心功能，例如日志、监控、配额、ACL 检查等。通过配置能够决定在运行时使用的确切的适配器套件，并且可以轻松扩展到新的或定制的基础设施后端。

必读！Istio Service Mesh中的策略与遥测概念详解

Mixer 及其适配器

获取更多适配器支持范围方面的内容。

可靠性和延迟

Mixer 是一个高可用的组件，其设计有助于提高整体可用性并减少网格中服务的平均延迟。其设计的关键方面带来以下好处：

  • 无状态。Mixer 是无状态的，因为它不管理任何自己的持久化存储。

  • 加固。Mixer 本身被设计成高度可靠的组件。设计目标是为任何单独的 Mixer 实例实现 > 99.999％ 的正常运行时间。

  • 缓存和缓冲。Mixer 被设计为累积大量瞬态短暂状态。

网格中每个服务都会有对应的 Sidecar 代理在运行，因此在内存消耗方面，Sidecar 必须厉行节约，这就限制了本地缓存和缓冲的可能数量。然而，独立运行的 Mixer 可以使用相当大的缓存和输出缓冲区。因此，Mixer 可用作 Sidecar 的高度扩展且高度可用的二级缓存。

必读！Istio Service Mesh中的策略与遥测概念详解

Mixer 拓扑

由于 Mixer 的预期可用性远高于大多数基础设施后端（通常这些可用性可能达到 99.9％）。Mixer 的本地缓存和缓冲不仅有助于减少延迟，而且即使在后端无响应时也能继续运行，从而有助于屏蔽基础设施后端故障。

最后，Mixer 的缓存和缓冲有助于减少对后端的调用频率，并且有时可以减少发送到后端的数据量（通过本地聚合）。这些都可以减少某些情况下的运维费用。    

属性

每个属性都有一个名称和一个类型。该类型定义了该属性所持有的数据的种类。例如，属性可以是 STRING 类型，这意味着它的值是文本类型；或者可以是 INT64 类型，指示它的值是 64 位整数。

以下是一些具有相关值的示例属性：

 
   
   
 
    
  
    
    
  
  1. request.path: xyz/abc
    2. 
  
    
    
  
  2. request.size: 234
    3. 
  
    
    
  
  3. request.time: 12:34:56.789 04/17/2017
    4. 
  
    
    
  
  4. source.ip: 192.168.0.1
    5. 
  
    
    
  
  5. destination.service: example
    6.

Mixer 本质上是一个属性处理机。每个经过 Envoy sidecar 的请求都会调用 Mixer，为 Mixer 提供一组描述请求和请求周围环境的属性。基于 Envoy sidecar 的配置和给定的特定属性集，Mixer 会调用各种基础设施后端。

必读！Istio Service Mesh中的策略与遥测概念详解

属性机

属性词汇

给定的 Istio 部署中具有其可理解的一组固定的属性词汇表。具体词汇表由部署中使用的一组属性生成器确定。Istio 中的主要属性生产者是 Envoy，但专用的 Mixer 适配器也可以生成属性。

这里定义了大多数 Istio 部署中可用的通用基准属性集。

属性表达式

配置 Instance 时要使用属性表达式。下面是一些简单的属性表达式示例：

 
   
   
 
    
  
    
    
  
  1. destination_service: destination.service
    2. 
  
    
    
  
  2. response_code: response.code
    3. 
  
    
    
  
  3. destination_version: destination.labels["version"] | "unknown"
    4.

冒号右侧的序列是属性表达式的最简单形式。前两行只包括了属性名称。 response_code 标签的内容来自于 response.code 属性。

以下是条件表达式的示例：

 
   
   
 
    
  
    
    
  
  1. destination_version: destination.labels["version"] | "unknown"
    2.

上面的表达式里， destination_version 标签被赋值为 destination.labels["version"]，如果 destination.labels["version"] 为空，则使用 "unknown" 代替。

有关详细信息，请阅读属性表达式参考。

配置模型

Istio 通过一个通用模型进行策略和遥测功能的配置，目的是让运维人员能够控制授权策略和遥测收集的方方面面。在保持模型简单的同时，还提供了足以控制 Istio 各项功能的强大能力。

策略和遥控功能的控制能力包含了三种类型资源的配置：

  • 配置一组实例（Instance），描述如何将请求属性映射到适配器输入。实例表示一个或多个适配器将操作的各种数据。例如，运维人员可能决定从诸如 destination.service 和 response.code 之类的属性中生成 requestcount 指标的实例。

  • 配置一组规则（Rule），这些规则描述了何时调用特定适配器及哪些实例。规则包含 match 表达式和 action。 match 表达式控制何时调用适配器，而 action 决定了要提供给适配器的一组实例。例如，规则可能会将生成的 requestcount 实例发送到 statsd 适配器。

配置基于适配器和模板（Template） ：

  • 适配器 封装了 Mixer 和特定基础设施后端之间的接口。

  • 模板 定义了从特定请求的属性到适配器输入的映射关系。一个适配器可以支持任意数量的模板。

处理器（Handler）

这里的例子配置了一个类型为 listchecker 的适配器。 listchecker 适配器使用一个列表来检查输入。如果配置的是白名单模式且输入值存在于列表之中，就会返回成功的结果。

 
   
   
 
    
  
    
    
  
  1. apiVersion: config.istio.io/v1alpha2
    2. 
  
    
    
  
  2. kind: listchecker
    3. 
  
    
    
  
  3. metadata:
    4. 
  
    
    
  
  4.   name: staticversion
    5. 
  
    
    
  
  5.   namespace: istio-system
    6. 
  
    
    
  
  6. spec:
    7. 
  
    
    
  
  7.   providerUrl: http://white_list_registry/
    8. 
  
    
    
  
  8.   blacklist: false
    9.

{metadata.name}.{kind}.{metadata.namespace} 是 Handler 的完全限定名。上面定义的对象的 FQDN 就是 staticversion.listchecker.istio-system，他必须是唯一的。 spec 中的数据结构则依赖于对应的适配器的要求。

有些适配器实现的功能就不仅仅是把 Mixer 和后端连接起来。例如 prometheus 适配器采集指标并以可配置的方式将它们聚合成分布或计数器。

 
   
   
 
    
  
    
    
  
  1. apiVersion: config.istio.io/v1alpha2
    2. 
  
    
    
  
  2. kind: prometheus
    3. 
  
    
    
  
  3. metadata:
    4. 
  
    
    
  
  4.   name: handler
    5. 
  
    
    
  
  5.   namespace: istio-system
    6. 
  
    
    
  
  6. spec:
    7. 
  
    
    
  
  7.   metrics:
    8. 
  
    
    
  
    9. 
  
    
    
  
  9. - name: request_count
    10. 
  
    
    
  
  10.   instance_name: requestcount.metric.istio-system
    11. 
  
    
    
  
  11.   kind: COUNTER
    12. 
  
    
    
  
  12.   label_names:
    13. 
  
    
    
  
  13.   - destination_service
    14. 
  
    
    
  
  14.   - destination_version
    15. 
  
    
    
  
  15.   - response_code
    16. 
  
    
    
  
  16. - name: request_duration
    17. 
  
    
    
  
  17.   instance_name: requestduration.metric.istio-system
    18. 
  
    
    
  
  18.   kind: DISTRIBUTION
    19. 
  
    
    
  
  19.   label_names:
    20. 
  
    
    
  
  20.   - destination_service
    21. 
  
    
    
  
  21.   - destination_version
    22. 
  
    
    
  
  22.   - response_code
    23. 
  
    
    
  
  23.     buckets:
    24. 
  
    
    
  
  24.     explicit_buckets:
    25. 
  
    
    
  
  25.       bounds: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]
    26.

每个适配器都定义了自己格式的配置数据。适配器及其配置的详尽列表可以在这里找到。

实例（Instance）

配置实例将请求中的属性映射成为适配器的输入。下面的例子，是一个 metric 实例的配置，用于生成 requestduration 指标。

 
   
   
 
    
  
    
    
  
  1. apiVersion: config.istio.io/v1alpha2
    2. 
  
    
    
  
  2. kind: metric
    3. 
  
    
    
  
  3. metadata:
    4. 
  
    
    
  
  4.   name: requestduration
    5. 
  
    
    
  
  5.   namespace: istio-system
    6. 
  
    
    
  
  6. spec:
    7. 
  
    
    
  
  7.   value: response.duration | "0ms"
    8. 
  
    
    
  
  8.   dimensions:
    9. 
  
    
    
  
  9.     destination_service: destination.service | "unknown"
    10. 
  
    
    
  
  10.     destination_version: destination.labels["version"] | "unknown"
    11. 
  
    
    
  
  11.     response_code: response.code | 200
    12. 
  
    
    
  
  12.   monitored_resource_type: '"UNSPECIFIED"'
    13.

注意 Handler 配置中需要的所有维度都定义在这一映射之中。每个模板都有自己格式的配置数据。完整的模板及其特定配置格式可以在这里查阅。

规则（Rule）

规则用于指定使用特定实例配置调用某一 Handler 的时机。比如我们想要把 service1 服务中，请求头中带有 x-user 的请求的 requestduration 指标发送给 Prometheus Handler。

 
   
   
 
    
  
    
    
  
  1. apiVersion: config.istio.io/v1alpha2
    2. 
  
    
    
  
  2. kind: rule
    3. 
  
    
    
  
  3. metadata:
    4. 
  
    
    
  
  4.   name: promhttp
    5. 
  
    
    
  
  5.   namespace: istio-system
    6. 
  
    
    
  
  6. spec:
    7. 
  
    
    
  
  7.   match: destination.service == "service1.ns.svc.cluster.local" && request.headers["x-user"] == "user1"
    8. 
  
    
    
  
  8.   actions:
    9. 
  
    
    
  
  9.   - handler: handler.prometheus
    10. 
  
    
    
  
  10.     instances:
    11. 
  
    
    
  
  11.     - requestduration.metric.istio-system
    12.

规则中包含有一个 match 元素，用于前置检查，如果检查通过则会执行 action 列表。 action中包含了一个实例列表，这个列表将会分发给 Handler。规则必须使用 Handler 和实例的完全限定名。如果规则、Handler 以及实例全都在同一个命名空间，命名空间后缀就可以在 FQDN 中省略，例如 handler.prometheus。

点击【阅读原文】可以直接访问文中的链接。

相关文章



参与社区

以下是参与ServiceMesher社区的方式，最简单的方式是联系我！

  • 社区网址：http://www.servicemesher.com

  • Slack：https://servicemesher.slack.com （需要邀请才能加入）

  • GitHub：https://github.com/servicemesher

  • Istio中文文档进度追踪：https://github.com/servicemesher/istio-official-translation

  • Twitter: https://twitter.com/servicemesher

  • 提供文章线索与投稿：https://github.com/servicemesher/trans

以上是关于必读！Istio Service Mesh中的策略与遥测概念详解的主要内容，如果未能解决你的问题，请参考以下文章

Istio Service Mesh 教程——一文了解 Istio 全部功能，示例见 GitHub

谈谈 Service Mesh 中的 Sidecar 模式

谈谈微服务架构中的基础设施：Service Mesh与Istio

Service Mesh 开源实现之 Istio 架构概览

漫画 | 小黄人学 Service Mesh 之 Istio

入门了解Service Mesh + Istio？从本文开始