第2章 Istio
入门
什么是Istio
- 它是一个完全开源的服务网格,以透明层的方式构建在现有分布式应用中。它也是一个提供了各种
API
的平台,可以与任何日志平台、监控系统或策略系统集成。Istio
的多样化特性可以让你高效地运行分布式微服务架构,并提供一种统一的方式来保护、连接和监控微服务 Istio
为微服务应用提供了一个完整的解决方案,可以以统一的方式去检测和管理微服务。同时,它还提供了管理流量、实施访问策略、收集数据等功能,而所有这些功能都对业务代码透明,即不需要修改业务代码就能实现- 有了
Istio
,就几乎可以不需要其他的微服务框架,也不需要自己去实现服务治理等功能,只要把网络层委托给Istio
,它就能帮助完成这一系列的功能。简单来说,Istio
就是一个提供了服务治理能力的服务网格
Istio
的架构
Istio
的架构从逻辑上分成数据平面(Data Plane
)和控制平面(Control Plane
)
- 数据平面:由一组和业务服务成对出现的
Sidecar
代理(Envoy
)构成,它的主要功能是接管服务的进出流量,传递并控制服务和Mixer
组件的所有网络通信(Mixer
是一个策略和遥测数据的收集器,稍后会介绍) - 控制平面:主要包括了
Pilot
、Mixer
、Citadel
和Galley
共4个组件,主要功能是通过配置和管理Sidecar
代理来进行流量控制,并配置Mixer
去执行策略和收集遥测数据(Telemetry
)
Istio
的核心控件
Envoy
Istio
的数据平面就是指代理。Istio
选择Envoy
作为Sidecar
代理,Envoy
本质上是一个为面向服务的架构而设计的7层代理和通信总线。Envoy
基于C 11开发而成,性能出色。除了具有强大的网络控制能力外,Envoy
还可以将流量行为和数据提取出来发送给Mixer
组件,用以进行监控Envoy
在网络控制方面的主要功能如下
HTTP 7
层路由- 支持
gRPC
、HTTP/2
- 服务发现和动态配置
- 健康检查
- 高级负载均衡
Pilot
Pilot
是Istio
实现流量管理的核心组件,它主要的作用是配置和管理Envoy
代理。比如可以为代理之间设置特定的流量规则,或者配置超时、重试、熔断这样的弹性能力。Pilot
会将控制流量行为的路由规则转换为Envoy
的配置,并在运行时将它们广播到Envoy
。另外,Pilot
还能够把服务发现机制抽象出来并转换成API
分发给Envoy
,使得后者具有服务发现的能力- 简单来说,
Pilot
的主要任务有两个
- 从平台(如
Kubernetes
)获取服务信息,完成服务发现 - 获取
Istio
的各项配置,转换成Envoy
代理可读的格式并分发
Pilot
维护了一套独立于平台的服务规则,并提供了一个平台适配器,以便接入各种不同的平台。Rules API
对运维人员开放,使得他们可以设置想要的流量规则,Pilot
会把这些配置好的规则通过Envoy API
分发给Envoy
代理,以使其执行指定的规则
Mixer
Mixer
的主要功能是提供策略控制,并从Envoy
代理收集遥测数据。每次网络通信时Envoy
代理都会向Mixer
发出预检要求,用来检测调用者的合法性。调用之后Envoy
代理会发送遥测数据供Mixer
收集。一般情况下Sidecar
代理可以缓存这些数据,不需要频繁地调用Mixer
Citadel
Citadel
是与安全相关的组件,主要负责密钥和证书的管理。它可以提供服务间和终端用户的身份认证,还可以加密服务网格中的流量
Galley
- 在2019年3月份发布的1.1版本中,
Galley
作为一个独立的组件被添加到了架构当中(在此之前的版本中Galley
并未独立出现),它现在是Istio
主要的配置管理组件,负责配置的获取、处理和分发。Galley
使用了一种叫作MCP
(Mesh Configuration Protocol
,网格配置协议)的协议与其他组件进行通信
Istio
的主要功能
流量管理
- 微服务应用最大的痛点就是处理服务间的通信,而这一问题的核心其实就是流量管理。首先来看一看传统的微服务应用在没有服务网格介入的情况下,如何完成诸如金丝雀发布这样的动态路由
- 而使用
Istio
就可以轻松地实现各种维度的流量控制。下图展示了两种不同的金丝雀发布策略。第一种是根据权重把5%的流量路由给新版本;第二种是根据请求的头信息User-Agent
把使用iPhone
的用户流量路由到新版本
Istio
的流量管理是通过Pilot
和Envoy
这两个组件实现的,将流量和基础设施进行了解耦。Pilot
负责配置规则,并把规则分发到Envoy
代理去实施;而Envoy
按照规则执行各种流量管理的功能,比如动态请求路由,超时、重试和熔断,还可以通过故障注入来测试服务之间的容错能力
请求路由
Istio
为了控制服务请求,引入了服务版本(Version
)的概念,可以通过版本这一标签将服务进行区分。版本的设置是非常灵活的,可以根据服务的迭代编号进行定义(如v1
、v2
版本);也可以根据部署环境进行定义(如Dev
、Staging
和Production
);或者是自定义任何用于区分服务的标记。通过版本标签,Istio
就可以定义灵活的路由规则以控制流量,上面提到的金丝雀发布这类应用场景就很容易实现了- 下图展示了
使用服务版本实现路由分配
的例子。服务版本定义了版本号(v1.5
、v2.0-alpha
)和环境(us-prod
、us-staging
)两种信息。服务B包含了4个Pod
,其中3个是部署在生产环境的v1.5
版本,而Pod4
是部署在预生产环境的v2.0-alpha
版本。运维人员根据服务版本指定路由规则,通过Pilot
同步给Envoy
代理,使得99%的流量流向v1.5
版本的生产环境,而1%的流量进入v2.0-alpha
版本的预生产环境
入口网关(Ingress
)和出口网关(Egress
)
- 服务间通信是通过
Envoy
代理进行的。同样,我们也可以在整个系统的入口和出口处部署代理,使得所有流入和流出的流量都由代理进行转发,而这两个负责入口和出口的代理就叫作入口网关和出口网关。它们相当于整个微服务应用的边界代理,把守着进入和流出服务网格的流量。下图展示了Ingress
和Egress
在请求流中的位置,通过设置Envoy
代理,出入服务网格的流量也得到了控制
服务发现和负载均衡
- 服务发现的前提条件是具有服务注册的能力。目前
Kubernetes
这类容器编排平台也提供了服务注册的能力。Istio
基于平台实现服务发现和负载均衡时,需要通过Pilot
和Envoy
协作完成,如图2-7所示。Pilot
组件会从平台获取服务的注册信息,并提供服务发现的接口,Envoy
获得这些信息并更新到自己的负载均衡池。Envoy
会定期地对池中的实例进行健康检查,剔除离线的实例,保证服务信息的实时性
故障处理
Istio
的故障处理都由Envoy
代理完成。Envoy
提供了一整套现成的故障处理机制,比如超时、重试、限流和熔断等。这些功能都能够以规则的形式进行动态配置,并且执行运行时修改
故障注入
- 简单来说,故障注入就是在系统中人为地设置一些故障,来测试系统的稳定性和系统恢复的能力。比如为某服务设置一个延迟,使其长时间无响应,然后检测调用方是否能处理这种超时问题而自身不受影响(如及时终止对故障发生方的调用,避免自己受到影响且使故障扩展)
Isito
支持注入两种类型的故障:延迟和中断。延迟是模拟网络延迟或服务过载的情况;中断是模拟上游服务崩溃的情况,表现为HTTP
的错误码和TCP
连接失败
策略和遥测
策略
- 在微服务应用中,除了流量管理以外,常常还需要进行一些额外的控制,比如限流(对调用频率、速率进行限制)、设置白名单和黑名单等。
Istio
中的策略控制是依靠Mixer
完成的。Envoy
代理在每次网络请求时,都会调用Mixer
进行预先检查,确定是否满足对应的策略。同时,Mixer
又可以根据这些来自流量的数据,进行指标数据的采集和汇总,这就是遥测功能
遥测(Telemetry
)
- 遥测是工业上常用的一种技术,它是指从远程设备中收集数据,并传输到接收设备进行监测。在软件开发中,遥测的含义引申为对各种指标(
metric
)数据进行收集,并监控、分析这些指标,比如我们经常听到的BI
数据分析。Mixer
的一大主要功能就是遥测。前面已经说过,Envoy
代理会发送数据给Mixer
,这就使得Mixer
具有了数据收集的能力。Mixer
可以接入不同的后端设施作为适配器,来处理收集到的指标数据,比如日志分析系统、监控系统等
可视化
- 在微服务应用越来越复杂的情况下,对整个系统的状态进行监控和追踪变得尤为重要。试想如果一个包含上百个服务的系统发生了故障却无法准确定位问题的根源,或者系统压力已经到了承受的临界值而运维人员却浑然不知,这是多么可怕的事情。没有完备的、可观察的监控系统就无法保障系统的稳定性
Istio
可以很方便地和各种监控、追踪工具集成,以便我们以可视化的方式(网页)直观地查看整个系统的运行状态。比如可以集成Prometheus
来进行指标数据的收集,然后将收集的数据放在Grafana
监控工具中展示;还可以集成Jaeger
作为追踪系统,帮助我们对请求的调用链进行跟踪,在故障发生时分析出现问题的根源;或者将请求日志记录到Kibana
系统,以图表的方式进行数据分析
安全
Istio
中的安全架构是由多个组件协同完成的。Citadel
是负责安全的主要组件,用于密钥和证书的管理;Pilot
会将授权策略等信息分发给Envoy
代理;Envoy
根据策略实现服务间的安全通信;Mixer
负责管理授权等工作
认证
- 两种类型的身份认证
- 传输认证:也叫作服务到服务认证。这种方式的认证是通过双向
TLS
(mTLS
)来实现的,即客户端和服务端(或者是调用者和被调用者)都要验证彼此的合法性 - 来源认证:也叫作最终用户认证,用于验证终端用户或设备。
Istio
使用目前业界流行的JWT
(JSON Web Token
)作为实现方案(在配置项上Istio
提供了扩展性,但在撰写本书时仍然只支持JWT
)
- 这两种认证的工作原理类似,都是将来自平台的认证策略存储起来,然后通过
Pilot
分发给Envoy
代理
授权
Istio
的授权功能沿用了Kubernetes
中的授权方式:RBAC
(Role-Based Access Control
,基于角色的访问控制)。它可以为网格中的服务提供不同级别的访问控制。比如命名空间级别、服务级别和方法级别
小结
Istio
的架构分为数据平面和控制平面,这种优雅的设计使得各个组件充分解耦,各司其职,这就是很多人将它称为第二代服务网格产品的原因- 数据平面即
Envoy
代理,负责流量的接管 - 控制平面包含了下面这些组件,这些组件的协同工作
Pilot
:流量控制Mixer
:策略控制Citadel
:安全加固Galley
:数据收集
Istio
顺利地完成了4
大功能
- 流量管理
- 策略和遥测
- 可视化
- 安全