kubernetes实践之七十二：Istio之策略与遥测
一：Istio简介
1.Istio定义
一个用来连接，管理和保护服务的开发平台。Istio提供一种简单的方式建立已部署服务网络，具备负载均衡，服务间认证和监控等功能。
而不需要改变任何服务代码。想要为服务增加对Istio的支持，只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。
2.为什么需要Istio
随着微服务出现，微服务的连接，管理和监控成为难题。Kubernetes可以处理多个容器的工作负载，但当涉及更复杂的需求时，需要像Istio这样的服务网格。
3.Istio的主要功能
a.流量管理(Pilot): 控制服务之间的流量和API调用的流向，使得调用更灵活可靠，并使网络在恶劣情况下更加健壮。
b.可观察性： 通过集成zipkin等服务，快速了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
c.策略执行(mixer): 将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
d.服务身份和安全(Istio-auth)： 为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。
4.Envoy架构
a.svcA服务作为客户端点用服务端svcB，svcB存在有两个版本，但是svcA并不知情
b.Envoy作为sidecar部署到各个svc到pod内，代理所有到进出流量
c.当svcA通过svcB到域名访问其服务时，Envoy根据Pilot配置的路由规则，将1%的流量分给了svcB的alpha版本
5.Pilot架构
通过配置，Pilot可以使Envoy实现：路由配置、故障注入、流量迁移、请求超时、熔断等诸多能力。
6.Mixer架构
Mixer主要提供三个核心功能：
前提条件检查：发生在服务响应请求之前，如果检查不通过可终止响应
配额管理：
遥测报告：可监控服务、上报日志信息
二：Mixer详解
1. 基础设施后端：
Mixer在应用程序代码和基础架构后端之间提供通用中介层，
基础设施后端旨在提供用于构建服务的支持功能。它们包括访问控制系统，遥测捕获系统，配额执行系统，计费系统等等。服务传统上直接与这些后端系统集成，创建硬耦合，还有沾染特定的语义和使用选项。
Istio 提供统一抽象，使得 Istio 可以与一组开放式基础设施后端进行交互。这样做是为了给运维提供丰富而深入的控制，同时不给服务开发人员带来负担。Istio 旨在改变层与层之间的边界，以减少系统复杂性，消除服务代码中的策略逻辑并将控制权交给运维
2. 属性
属性是描述出口入口流量的有名称和类型的元数据片段。
Mixer在运行时，接受一组属性，mixer根据配置处理传入的属性到适当的基础设置后端。
功能：
a.前期条件检查。 发生在请求处理前 ，请求被拦截到envoy时访问mixer。
允许服务在响应来自服务消费者的传入请求之前验证一些前提条件。前提条件可以包括服务使用者是否被正确认证，是否在服务的白名单上，是否通过ACL检查等等。
b.配额管理。 发生在请求处理中 ，服务中需要调用后端基础设施时。
使服务能够在分配和释放多个维度上的配额，配额这一简单的资源管理工具可以在服务消费者对有限资源发生争用时，提供相对公平的（竞争手段）。频率控制就是配额的一个实例。
c.遥测报告。发生在请求处理后 ，上报参考性数据给mixer。也因此，envoy拥有检查pod健康能力。
服务能够上报日志和监控。在未来，它还将启用针对服务运营商以及服务消费者的跟踪和计费流。
遥测报告是异步形式。即缓存多条上报一次
3.适配器
Mixer 是高度模块化和可扩展的组件。他的一个关键功能就是把不同后端的策略和遥测收集系统的细节抽象出来，使得 Istio 的其余部分对这些后端不知情。
Mixer 处理不同基础设施后端的灵活性是通过使用通用插件模型实现的。每个插件都被称为 Adapter，Mixer通过它们与不同的基础设施后端连接，这些后端可提供核心功能，例如日志、监控、配额、ACL 检查等。通过配置能够决定在运行时使用的确切的适配器套件，并且可以轻松扩展到新的或定制的基础设施后端。
4.配置文件示例
a.处理器(Handler):
适配器封装了 Mixer 和特定外部基础设施后端进行交互的必要接口，例如 Prometheus 或者 Stackdriver。各种适配器都需要参数配置才能工作。例如日志适配器可能需要 IP 地址和端口来进行日志的输出。
这里的例子配置了一个类型为 listchecker 的适配器。listchecker 适配器使用一个列表来检查输入。如果配置的是白名单模式且输入值存在于列表之中，就会返回成功的结果。
apiVersion: config.istio.io/v1alpha2kind: listcheckermetadata:name: staticversion namespace: istio-systemspec:providerUrl: http://white_list_registry/ blacklist: false
{metadata.name}.{kind}.{metadata.namespace} 是 HANDLER 的完全限定名。上面定义的对象的 FQDN 就是 staticversion.listchecker.istio-system，他必须是唯一的。spec 中的数据结构则依赖于对应的适配器的要求。
有些适配器实现的功能就不仅仅是把 Mixer 和后端连接起来。例如 prometheus 适配器消费指标并以可配置的方式将它们聚合成分布或计数器。
apiVersion: config.istio.io/v1alpha2kind: prometheusmetadata:name: handler namespace: istio-systemspec: metrics:- name: request_count instance_name: requestcount.metric.istio-system kind: COUNTER label_names: - destination_service - destination_version - response_code- name: request_duration instance_name: requestduration.metric.istio-system kind: DISTRIBUTION label_names: - destination_service - destination_version - response_code buckets: explicit_buckets: bounds: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]
每个适配器都定义了自己格式的配置数据。适配器及其配置的详尽列表可以在这里找到
b.实例(Instance):
配置实例将请求中的属性映射成为适配器的输入。下面的例子，是一个 metric 实例的配置，用于生成 requestduration metric。
apiVersion: config.istio.io/v1alpha2kind: metricmetadata:name: requestduration namespace: istio-systemspec: value: response.duration | "0ms" dimensions: destination_service: destination.service | "unknown" destination_version: destination.labels["version"] | "unknown" response_code: response.code | 200 monitored_resource_type: '"UNSPECIFIED"'
c.规则(Rule):
规则用于指定使用特定实例配置调用某一 HANDLER 的时机。比如我们想要把 service1 服务中，请求头中带有 X-USER 的请求的 requestduration 指标发送给 Prometheus HANDLER。
apiVersion: config.istio.io/v1alpha2kind: rulemetadata: name: promhttp namespace: istio-system spec: match: destination.service == "service1.ns.svc.cluster.local" && request.headers["x-user"] == "user1" actions:- handler: handler.prometheus instances: - requestduration.metric.istio-system
规则中包含有一个 MATCH 元素，用于前置检查，如果检查通过则会执行动作列表。动作中包含了一个实例列表，这个列表将会分发给 HANDLER。规则必须使用 HANDLER 和实例的完全限定名。如果规则、HANDLER 以及实例全都在同一个命名空间，命名空间后缀就可以在 FQDN 中省略，例如 handler.prometheus。
