Istio 核心功能
Istio 核心功能
一. 流量控制
微服务应用的最大的痛点就是处理服务间的通信, 而这一问题的核心其实就是 流量的管理。
传统的微服务在金丝雀发布的路由功能在不借助于第三方框架,最简单的实现方法,就是在服务期间添加一个负载均衡(比如
nginx
)做代理, 通过修改配置的权重分配流量。
- 缺点: 对流量的管理和基础设施绑定在一起, 难以维护
而使用 Istio就可以轻松的实现各种维度的流量控制。下图是典型的金丝雀发布策略:根据权重把 5% 的流量路由给新版本,如果服务正常,再逐渐转移更多的流量到新版本。
![](https://www.servicemesher.com/istio-handbook/images/concept-trafficcontrol-canary.png)
Istio 的流量控制功能主要分为三个方面:
- 请求路由和流量的转移
- 弹性功能, 包括熔断,超时, 重试
- 调试能力, 包括故障注入和流量镜像
1.1.路由和流量转移
Istion 为了控制服务请求,引入了服务版本(version)的概念,可以通过版本这一标签将服务进行区分。
-
版本的设置是非常灵活的,可以根据服务的迭代编号进行定义(如 v1、v2 版本);也可以根据部署环境进行定义(比如 dev、staging、production);或者是自定义的任何用于区分服务的某种标记
如下图为Istio通过版本进行流浪控制
-
除了上面介绍的服务间流量控制外,还能控制与网格边界交互的流量。可以在系统的入口和出口处部署 Sidecar代理,让所有流入和流出的流量都由代理进行转发。
-
Istio 还能设置流量策略。比如可以对连接池相关的属性进行设置,通过修改最大连接等参数,实现对请求负载的控制。
-
还可以对负载均衡策略进行设置,在轮询、随机、最少访问等方式之间进行切换。
-
还能设置异常探测策略,将满足异常条件的实例从负载均衡池中摘除,以保证服务的稳定性。
1.2.弹性功能
目前支持超时、重试和熔断
- 超时就是设置一个等待时间,当上游服务的响应时间超过这个时间上限,就不再等待直接返回,就是所谓的快速失败。超时主要的目的是控制故障的范围,避免故障进行扩散。路由配置里添加
timeout
就可以实现 - 重试一般是用来解决网络抖动时通信失败的问题。因为网络的原因,或者上游服务临时出现问题时,可以通过重试来提高系统的可用性。 路由配置中添加 retry关键字可以实现
- 熔断,它是一种非常有用的过载保护手段,可以避免服务的级联失败。熔断一共有三个状态,
-
当上游服务可以返回正常时,熔断开关处于关闭状态;
-
一旦失败的请求数超过了失败计数器设定的上限,就切换到打开状态,让服务快速失败;
-
熔断还有一个半开状态,通过一个超时时钟,在一定时间后切换到半开状态,让请求尝试去访问上游服务,看看服务是否已经恢复正常。如果服务恢复就关闭熔断,否则再次切换为打开状态。
-
熔断需要在自定义资源
DestinationRule
的TrafficPolicy
里进行设置。
-
1.3.调试能力
调试的能力,包括故障注入和流量镜像。对流量进行调试可以让系统具有更好的容错能力,也方便我们在问题排查时通过调试来快速定位原因所在
1.3.1.故障注入
故障注入就是 在系统中认为设置一些故障,来测试系统的稳定性和系统恢复的能力
- 比如 给某个服务注入一个延迟,使其长时间无响应,然后检测调用方是否能处理这种超市而自身不受影响
支持两种类型的故障: 延迟和中断
-
延迟就是模拟网络延迟或服务过载的情况
-
中断时模拟上游服务崩溃的情况,以HTTP的错误码和TCP链接失败来表现。
-
故障注入很方便,在路由配置中添加
fault
关键字即可。
1.3.2.流量镜像
通过复制一份请求并把它发送到镜像服务,从而实现流量的复制功能。
流量镜像的主要应用场景有以下几种:
- 最主要的就是进行线上问题排查。一般情况下,因为系统环境,特别是数据环境、用户使用习惯等问题,我们很难在开发环境中模拟出真实的生产环境中出现的棘手问题,同时生产环境也不能记录太过详细的日志,因此很难定位到问题。流量镜像,我们就可以把真实的请求发送到镜像服务,再打开 debug 日志来查看详细的信息。
- 通过它来观察生产环境的请求处理能力,比如在镜像服务进行压力测试。
- 也可以将复制的请求信息用于数据分析。
现起来也非常简单,只需要在路由配置中通添加mirror
关键字即可。
1.4. 实现流量控制的自定义资源
实现流量控制的用户自定义资源(CRD)主要有以下几个:
-
VirtualService
:用于网格内路由的设置; -
DestinationRule
:定义路由的目标服务和流量策略; -
ServiceEntry
:注册外部服务到网格内,并对其流量进行管理; -
Ingress、Egress gateway:控制进出网格的流量;
通过这些自定义资源,实现了对网格内部、网格外部、进出网格边界的流量的全面的控制。也就是说所有和网格产生交互的流量都可以被 Istio
所控制,其设计思路堪称完美。下图是这几种资源的示意图。
二. 安全
安全对于微服务这样的分布式系统非常重要。
与单体应用在进程内进行通信不同, 网络成为了服务间通信的组件, 这使得它对安全有了跟迫切的要求。
- 比如为了抵御外来的攻击, 需要对流量进行加密
- 为了保证服务间通信的可靠性,需要使用mTLS的方式进行交互
- 为控制不同身份访问,需要设置不同粒度的授权策略
Istio 中的安全架构是由多个组件协同完成的。
- Citadel 是负责安全的主要组件,用于密钥和整数的管理
- Pilot 会将安全策略配置发送给Envoy代理
- Envoy执行安全策略来实现访问控制
安全策略架构和运作流程如下
Istio 提供的安全功能主要分为认证 和 授权。
2.1 认证
Istio
提供两种类型认证:
- 对等认证(Peer authentication):用于服务到服务的认证。这种方式是通过双向 TLS(mTLS)来实现的,即客户端和服务端都要验证彼此的合法性。
Istio
中提供了内置的密钥和证书管理机制,可以自动进行密钥和证书的生成,分发和轮换,而无需修改业务代码。 - 请求认证(Request authentication):也叫最终用户认证, 验证终端用户或客户端。
Istio
使用目前业界流行的JWT(JSON Web Token) 作为实现方案
Istio
的mTLS
提供了一种宽容模式的配置方法,使得服务可以同时支持纯文本和mTLS
流量。用户可以先用非加密的流量确保服务间的连通性,然后再逐渐迁移到 mTLS,这种方式极大的降低了迁移和调试的成本。
还提供了多种粒度的认证策略,可以支持网格级别、命名空间级别和工作负载级别的认证,用户可以灵活的配置各种级别的策略和组合。
2.2 授权
Istio
的授权策略可以为网络中的服务提供不统计被的访问控制。 比如网络比如网格级别、命名空间级别和工作负载级别。授权策略支持 ALLOW
和 DENY
动作,每个Envoy都代理都运行一个授权引擎,当请求到达代理时,授权引擎根据当前策略评估请求的上下文,并返回授权结果 ALLOW或
DENY。 授权功能没有显示的开关进行配置,默认就是启动状态,只需要将配置好的授权策略应用到对应的工作负载就可以进行访问控制了。
授权策略通过自定义资源AuthorizationPolicy
来配置。除了定义策略指定的目标(网格、命名空间、工作负载)和动作(容许、拒绝)外,Istio 还提供了丰富的策略匹配规则,比如可以设置来源、目标、路径、请求头、方法等条件,甚至还支持自定义匹配条件,其灵活性可以极大的满足用户需求。
三. 可观察性
可观察性的作用
- 及时反馈异常或者风险使得开发人员可以及时关注、修复和解决问题(告警);
- 出现问题时,能够帮助快速定位问题根源并解决问题,以减少服务损失(减损);
- 收集并分析数据,以帮助开发人员不断调整和改善服务(持续优化)
Istio
一共提供了三种不同类型的数据从不同的角度支撑起其可观察性:
-
指标(Metrics):可以用于查看某一段时间范围内系统状态的变化情况, 甚至可以预测未来一段时间系统的行为。Istio中有四类不同的监控标识(响应延迟、流量大小、错误数量、饱和度)生成了一系列观测不同服务的监控指标,用于记录和展示网格中服务状态。
-
日志(Access Logs):日志是软件系统中记录软件执行状态及内部事件最为常用也最为有效的工具。日志包含了系统状态更多的细节部分。在分布式系统中,日志是定位复杂问题的关键手段;同时,由于每个事件都会产生一条对应的日志,所以日志也往往被用于计费系统,作为数据源。对接 ELK 等日志分析系统后,可以快速的筛选出具有特定特征的日志以分析系统中某些特定的或者需要关注的事件
-
分布式追踪(Distributed Traces):通过额外数据(Span ID等特殊标记)记录不同组件中事件之间的关联,并由外部数据分析系统重新构造出事件的完整事件链路以及因果关系。在服务网格的一次请求之中,Istio 会为途径的所有服务生成分布式追踪数据并上报,通过 Zipkin 等追踪系统重构服务调用链,开发人员可以借此了解网格内服务的依赖和调用流程,构建整个网格的服务拓扑。