- 什么是Istio
- 服务治理的三种形态
- 官网介绍
- Istio与Kubernetes的关系
- istio是如何实现的service mesh, 即istio的工作机制
- istio的架构发展史
- istio的主要组件
- Istio的xDS协议
- 标准xDS流程
- 协议分析
- 四种变种
- 参考资料
什么是Istio
- 与Kubernetes紧密结合,适用于云 原生场景
- Service Mesh形态的
- 用于服务治理的开放平台
服务治理的三种形态
官网介绍
- 连接:Istio通过集中配置的流量规则控制服务间的流量和调用,实现负载均衡,熔断,故障注入,重试,重定向等服务治理功能
- 安全:Istio提供透明的认证机制,通道加密,服务访问授权等安全能力,可增强服务访问的安全性
- 策略执行:Istio通过可动态插拔,可扩展的策略实现访问控制,速率限制,配额管理,服务计费等能力
- 可观察性:动态获取服务运行数据和输出,提供强大的调用链,监控和调用日志收集输出的能力。配合可视化工具,可方便运维人员了解服务的运行状况,发现并解决问题。
Istio与Kubernetes的关系
istio是如何实现的service mesh, 即istio的工作机制
Istio的工作机制和架构,分为控制面和数据面两部分,控制面主要包括Pilot,Mixer,Critadel等服务组件,数据面由伴随每个应用程序部署的代理程序Envoy组成,执行针对应用程序的治理逻辑。
上图为基于1.4的一个流程,升级到1.5之后,Mixer被移除,Pilot,Galley, citaldel被统一并到了Istiod的服务中。
- (1)自动注入:指在创建应用程序时自动注入Sidecar代理,在Kubernetes场景下创建Pod时,Kube-apiserver调用管理面组件的Sidecar-Injector服务,自动修改应用程序的描述信息并注入Sidecar。在真正创建pod时,在创建业务容器的同时在Pod中创建Sidecar容器
- (2)流量拦截:在Pod初始化时设置iptables规则,当有流量到来时,基于配置的iptables规则拦截业务容器的Inbound流量和Outbound流量到Sidecar上。应用程序感知不到Sidecar的存在,还以原来的方式进行互相访问。在上图中,流出Frontend服务的流量会被frontend服务侧的Envoy拦截,而当流量到达forecast容器时,Inbound流量被forecast服务侧的Envoy拦截。
- (3)服务发现:服务发起方的Envoy调用管理面组件Pilot的服务发现接口获取目标服务的实例列表。在上图中,frontend服务侧的Envoy通过Pilot的服务发现接口得到forecast服务各个实例的地址,为访问做准备。
- (4)负载均衡:服务发起方的Envoy根据配置的负载均衡策略选择服务实例,并连接对应的实例地址。在上图中,数据面的各个Envoy从Pilot中获取Forecast服务的负载均衡配置,并执行负载均衡动作。
- (5)流量治理:Envoy从Pilot中获取配置的流量规则,在拦截到Inbound流量和Outbound流量时执行治理逻辑。在上图中,frontend服务侧的Envoy从Pilot中获取流量治理规则,并根据该流量治理规则将不同特征的流量分发到forecast服务的v1或者v2版本。
- (6)访问安全:在服务间访问时通过双方的Envoy进行双向认证和通道加密,并基于服务的身份进行授权管理。在上图中,Pilot下发安全相关配置,在frontend服务和forecast服务的Envoy上自动加载证书和密钥来实现双向认证,其中的证书和密钥由另一个管理面组件Citadel维护。
- (7)服务遥测:在服务间通信时,通信双方的Envoy都会连接管理面组件Mixer上报访问数据,并通过Mixer将数据转发给对应的监控后端。在上图中,frontend服务对forecast服务的访问监控指标、日志和调用链都可以通过这种方式收集到对应的监控后端。
- (8)策略执行:在进行服务访问时,通过Mixer连接后端服务来控制服务间的访问,判断对访问是放行还是拒绝。在上图中,Mixer后端可以对接一个限流服务对从frontend服务到forecast服务的访问进行速率控制。
- (9)外部访问:在网格的入口处由一个Envoy扮演入口网关的角色。在上图中,外部服务通过Gateway访问入口服务frontend,对frontend服务的负载均衡和一些流量治理策略都在这个Gateway执行。
istio的架构发展史
Istio 是由 Google、IBM 和 Lyft 联合开发的。 其中它的数据平面直接使用了 Lyft 的 Envoy 作为 sidecar。 控制平面是由 Google、IBM 联合开发。
第一个版本 0.1 release 发布于2017年5月24日。截止到2020年12月份已经发布了1.8.1版本。 其中1.4之前 Istio 的架构还是基本沿用一致的架构设计,仅仅是在功能上做增强以及增加一些辅助的组件。 1.5 版本后将原有的 Istio 架构设计重新推倒,将之前的组件合并为一个单体架构 Istiod。然后其组件虽然精简成单体架构,但是之前支持的功能却一个都没有少。因此1.5版本作为 Istio 社区的一个全新形态,堪称是一次突破性的设计革新。
核心改动是去掉了Mixer,把Pilot,Galley,Citadel合并到了istiod服务中
1.5之前的架构图
1.5 之后架构图
istio的主要组件
1.5之前的组件
- Pilot :Istio 的核心组件,主要负责核心治理、流量控制、将配置转换为数据平面可识别的 xDS 协议分发配置到数据平面
- Galley :主要负责配置校验、以及配置/服务发现。这两项功能在 galley的架构设计中是相对独立的,对应的是galley的两种运行模式 server 和enable-validation,两种模式可以单独开启也可以共同开启。
- Citadel :可选开启或关闭,负责安全相关的证书和密钥管理。
- Injector :负责数据平面的初始化相关的动作,例如自动注入 sidecar 就是使用该组件完成的。
- Mixer:默认关闭,负责提供策略控制和遥测收集的组件,内部包含 Policy 和 Telemetry 2个子模块,其中 Policy负责在服务相互调用过程中对请求进行策略检查,例如鉴权、限流,而 Telemetry 负责监控相关的采集数据的信息聚合以用于对接各种后端。
- Istio数据平面 :Istio 的数据平面主流选用 Lyft 的 Envoy,当然也可以选择其他的数据平面,例如 MOSN。
1.5之后控制面的所有组件都被整合进了istiod中,主要负责Traffic Management,Security,Observe的部分。
Istio的xDS协议
xDS是一类发现服务的总称,包含LDS, RDS, CDS, EDS以及SDS。
Envoy通过xDS API可以动态获取Listener(监听器),Route(路由),Cluster(集群),Endpoint(集群成员)以及Secret(密钥)配置。
- LDS:Listener发现服务。Listener监听器控制Envoy启动端口监听(目前只支持TCP协议),并配置L3/L4层过滤器,当网络连接达到后,配置好的网络过滤器堆栈开始处理后续事件。这种通用的监听体系结构用于执行大多数不同的代理任务(限流,客户端认证,HTTP连接管理,TCP代理等)。
- RDS: Route发现服务,用户HTTP连接管理过滤器动态获取路由配置。路由配置包含HTTP头部修改(增加,删除HTTP头部键值),virtual hosts(虚拟主机),以及virtual hosts定义的各个路由条目。
- CDS:Cluster发现服务,用于动态获取Cluster信息。Envoy cluster管理器管理着所有的上游cluster。鉴于上游cluster或者主机可用于任何代理转发任务,所以上游cluster一般从Listener或Route中抽象出来。
- EDS:Endpoint发现服务。在Envoy术语中,Cluster成员就叫Endpoint,对于每个Cluster,Envoy通过EDS API动态获取Endpoint。EDS作为首选的服务发现的原因有两点:
- 与通过DNS解析的负载均衡器进行路由相比,Envoy能明确的知道每个上游主机的信息,因而可以做出更加智能的负载均衡策略
- Endpoint配置包含负载均衡权重、可用域等附加主机属性,这些属性可用域服务网格负载均衡,统计收集等过程中。
- SDS:Secret发现服务,用于运行时动态获取TLS证书。若没有SDS特性,在k8s环境中,必须创建包含证书的Secret,代理启动前Secret必须挂在到sidecar容器中,如果证书过期,则需要重新部署。使用SDS,集中式的SDS服务器将证书分发给所有的Envoy实例,如果证书过期,服务器会将新的证书分发,Envoy接收到新的证书后重新加载不用重新部署。
标准xDS流程
协议分析
xDS 协议是Envoy获取配置信息的传输协议,也是Istio与Envoy连接的桥梁。 Envoy动态的发现服务以及相关资源的API就是指xDS。xDS可以通过两种方式承载:gRPC、REST,这两种方式都是通过xDS-API发送DiscoveryRequest请求,然后资源通过DiscoveryRequest下发
DiscoveryRequest
DiscoveryResponse
四种变种
- State of the World (Basic xDS): SotW, separate gRPC stream for each resource type
- Incremental xDS: incremental, separate gRPC stream for each resource type
- Aggregated Discovery Service (ADS): SotW, aggregate stream for all resource types
- Incremental ADS: incremental, aggregate stream for all resource types
参考资料
- 《云原生服务网格Istio原理,实践,架构和源码解析》
- https://istio.io/latest/docs/
- https://istio.io/latest/news/releases/1.8.x/
- https://www.selinux.tech/architecture/infrastructure/service-mesh-istio
- https://zhuanlan.zhihu.com/p/112050345
- https://www.bilibili.com/read/cv7233104
- https://blog.csdn.net/fly910905/article/details/104036296
- https://istio.io/latest/blog/2020/istiod/
- https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
- https://www.bilibili.com/video/BV1vt411H755?p=5