• 什么是Istio
• 服务治理的三种形态
• 官网介绍
• Istio与Kubernetes的关系
• istio是如何实现的service mesh, 即istio的工作机制
• istio的架构发展史
• istio的主要组件
  • 1.5之前的组件
  • 1.5之后控制面的所有组件都被整合进了istiod中，主要负责Traffic Management，Security，Observe的部分。
• Istio的xDS协议
• 标准xDS流程
• 协议分析
  • DiscoveryRequest
  • DiscoveryResponse
• 四种变种
• 参考资料

什么是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