Istio系列三:Mixer、Pilot组件分析实践
本文为Istio系列的终结篇,前两篇《Istio系列一:Istio的认证授权机制分析》、《Istio系列二:Envoy组件分析》笔者分别对Istio的安全机制和数据平面组件Envoy进行了解读,相信各位读者已经对Istio有了一定认识,本文主要对Istio的控制平面核心组件Mixer、Pilot进行分析解读,在文中笔者会结合Envoy说明Mixer、Pilot的工作原理及它们在Istio中的价值,文章阅读时间大致15分钟,希望能给各位读者带来收获。
Istio 流量管理的核心组件是 Pilot,它管理和配置部署在特定Istio服务网格中的所有Envoy代理实例。Pilot还允许用户指定在 Envoy 代理之间使用什么样的路由流量规则,并配置故障恢复功能,如超时、重试和熔断器。它还维护了网格中所有服务的规范模型,并使用这个模型通过DS(发现服务)让 Envoy 了解网格中的其它实例。
图1 Pilot架构图
首先Pilot定义了网格服务中的标准模型,即图1中的Abstract Model,服务标准模型独立于各种底层平台,例如Kubernetes、Mesos、Cloud Foundry等。各个平台可以通过Platform Adapter和Pilot进行对接,将自己持有的元数据(以Kubernetes举例,元数据为Pod,Service,Endpoints等)转化为Abstract Model标准格式,并填充到标准模型中。另外Platform Adapter是可插拔的,开发人员也可以自己开发Platform Adapter去适配其它服务发现组件集成至Pilot中。这里注意Istio的服务发现用的是各个底层平台原有的功能,比如Kubernetes平台使用kube-dns或core-dns做服务发现。Pilot通过在Kubernetes里注册一个Controller来监听事件,从而获取Service和Kubernetes的Endpoint以及Pod等元数据。
2Envoy API所以Istio通过标准API的设计,将控制平面与数据平面解耦,除了Istio集成Envoy,Istio还可以集成Linkerd、Nginmesh等其它代理软件,当然也可以基于该API自己编写Sidecar实现。目前Istio和Envoy制定了Envoy V2 API,V1已废弃。
用于从提供服务发现功能的Kubernetes中获取元数据信息。 用于从Kubernetes API Server 中获取流量规则(用户指定DSL语言并通过Rules API获取) 用于将前两项得出的服务信息和流量规则转化为Abstract Model定义的数据格式并通过标准的Envoy API的XDS接口暴露给各个服务的Envoy代理,Envoy根据得到的配置信息对服务间的通讯进行寻址和路由。
用户定义基于DSL语言的yaml文件,使用kubectl或istioctl通过Rules API指定流量管理规则下发给Pilot。 Pilot通过Platform Adapter适配Kubernetes平台,利用Kubernetes的服务发现功能寻找定义在第一步yaml文件中服务在Kubernetes中的Pod和Service对应关系,并通过Kubernetes API Server传递给Discovery Service模块,与此同时,Discovery Service模块也收集yaml文件中用户定义的流量规则,并将收集到的两者信息结合形成Abstract Model定义的数据格式。 最后通过Envoy API暴露给对应服务的Envoy容器,等待Envoy容器拉取这些流量规则并进行有效处理。
Mixer的核心功能有两个,分别是:
前置条件检查(Precondition Checking):用户通过Envoy向Mixer发送check请求,检查请求是否满足一些前提条件,比如ACL检查,白名单检查,日志检查等。
遥测报告上报(Telemetry Reporting):如果前置条件检查通过,处理完后通过Envoy向Mixer上报日志,监控等数据。
图3为Mixer的官方架构图,图4为笔者画的Mixer拓扑图,如下所示:
图3 Mixer架构图
图4 Mixer拓扑图
Mixer组件主要功能为check(前置条件检查)和report(上报遥测数据), 这两个功能在Mixer中以RPC(Remote Procedure Call)的形式对外呈现,为了更清晰的理解上述拓扑图中的Mixer工作流程,首先介绍Mixer组件的几个重要概念:
1request.path:xyz/abc
2
3request.size:234
4
5request.time:11:07:35.234 02/19/2019
6
7source.ip:192.168.0.1
8
9destination.service:example
图6 Mixer Adpater
结合以上Mixer基本概念和图4拓扑图,Mixer的工作流程可描述如下:
用户下发一个新的策略请求至某服务,Envoy根据配置内容提取出Attributes ,并调用Mixer的check rpc。Mixer进行前置条件检查(调度相应的Adapter处理),返回相应结果(引用属性)。
Envoy分析结果,满足条件后进行代理转发。Envoy完成转发请求后,通过调用Mixer的report rpc上报遥测数据。
Mixer的后端Adapter基于遥测数据作进一步处理。
从Mixer的工作流程可看出其存在一些问题,每有请求进来,Envoy便会调用两次请求给Mixer,在微服务规模较小时,似乎不会有太大影响,但生产环境中微服务数量到达成千上百时无疑会对网络资源,内存资源消耗巨大,那么有什么好的解决方式吗?
1apiVersion:"config.istio.io/v1alpha2"
2kind:metric
4metadata:
6 name:requestsize
8 namespace:istio-system
10spec:
12 value:request.size | 0
14dimensions:
16 source_version:source.labels["version"] | "unknown"
18 destination_service:destination.Service.host | "unknown"
20 destination_version:destination.labels["version"] | "unknown"
22response_code:response.code | 200
24monitored_resource_type:'"UNSPECIFIED"'
1apiVersion:config.istio.io/v1alpha2
2kind:prometheus
3metadata:
4 name:handler
5 namespace:istio-system
6spec:
7 metrics:
8 - name:request_count
9 instance_name:requestcount.metric.istio-system
10 kind:COUNTER
11 label_names:
12 - destination_service
13 - destination_version
14 - response_code
1apiVersion:config.istio.io/v1alpha2
2kind:rule
3metadata:
4 name:promhttp
5 namespace:istio-system
7spec:
8 match:destination。service == "service1.ns.svc.cluster.local" && request。headers["x-user"] == "user1"
9 actions:
10 - handler:handler.prometheus
11 instances:
12 - requestduration.metric.istio-system
Service Mesh的出现加快了微服务的发展,大多数开发或是运维人员逐步由Spring Cloud框架转向Istio的学习,Istio的影响力自然不必多说,那么下一个使用者会是你吗?
内容编辑:星云实验室 浦明 责任编辑:肖晴
往期回顾
本公众号原创文章仅代表作者观点,不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权,严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用,转载须注明来自绿盟科技研究通讯并附上本文链接。
关于我们
绿盟科技研究通讯由绿盟科技创新中心负责运营,绿盟科技创新中心是绿盟科技的前沿技术研究部门。包括云安全实验室、安全大数据分析实验室和物联网安全实验室。团队成员由来自清华、北大、哈工大、中科院、北邮等多所重点院校的博士和硕士组成。
绿盟科技创新中心作为“中关村科技园区海淀园博士后工作站分站”的重要培养单位之一,与清华大学进行博士后联合培养,科研成果已涵盖各类国家课题项目、国家专利、国家标准、高水平学术论文、出版专业书籍等。
我们持续探索信息安全领域的前沿学术方向,从实践出发,结合公司资源和先进技术,实现概念级的原型系统,进而交付产品线孵化产品并创造巨大的经济价值。
长按上方二维码,即可关注我们