idou老师教你学Istio05: 如何用Isito实现智能路由配置

1,357 阅读6分钟

概要

要介绍 istio 请求路由,我们不由得先从 pilot 和 envoy 开始谈起。 在服务网格中,Pilot 管理和配置所有的 envoy 实例。在 pilot 中,你几乎可以配置所有的关于流量导向规则及其他故障恢复规则。而 Envoy 不仅会获得从 pilot 拿到的基本负载均衡信息,同时周期性的健康检查,也会告诉所有的 envoy 其他的实例现在的运行状况。负载均衡信息,及健康检查的信息可以使 envoy 更加智能的去分发流量。

在上述的 pilot 结构中,不难理解,platform adapter 作为平台适配器,可以使istio顺利的在任何平台下工作。Envoy Api 则提供动态更新信息,服务发现及配置路由规则的功能。

请求路由

在 istio 中,envoy 的存在为流入及流出的流量提供了可控和可视的基本条件。Envoy 根据所维护的信息对请求流量的一方面有利于平衡各个 pod 的工作量,保证不会存在极端情况而是“雨露均沾”。另一方面,envoy 对请求流量的分发,从使用者角度来讲是无感知的。

如图中,用户通过某个地址来访问服务 A,服务A的 envoy 实时发现了网格内存在的服务 B,并且根据既定的转发规则来分发流量(1%流入 pod4 访问B’版本其余99%根据负载均衡信息流入 pod1-pod3 访问 B 版本)。也正是envoy挂在服务外部的这一设计,方便开发和运维人员进行故障测试,熔断以及实时监控。

VirtualService & DestinationRule

Virtualservice

VirtualService 中主要是定义了请求的路由规则,当某个请求满足了先前预设的路有条件,那么这个请求就会路由至预设的服务。我们看一个简单的 VirtualService 例子:

在这个 virtualservice 中,绿色范围内的 host 有两条内容,第一条是服务的短名称,实际上这个名称是省略后的 FQDN,这里的全称应当是reviews.default.svc.cluster.local 中间标红的是规则所在的 namespace,而不是 reviews 所在的 namespace。第二条则是配置给 reviews 组件的通过负载均衡访问的地址。黄色部分则是路由地址,其中的 subset 对应的是服务中的版本。

DestinationRule

DestinationRule 是路由后的流量访问策略,访问策略包含负载均衡算法,熔断等限制。下图是一个 destinationrule 的例子:

黄色部分很显然是服务的两个版本。绿色部分的意义是 TrafficPolicy,里面配置的是负载均衡算法设定为最小连接数,当两个主机提供服务时,会自动选择连接数最小的主机。我们也可以在这里配置连接池,TLS 连接,端口级别策略,自动移除不健康主机等设置。

连接池管理

连接池配置给上游主机,这意味着该主机所有获取到来自envoy的链接请求,都要遵循配置好的连接池原则,这些原则既可以配在TCP层也可以配在HTTP层。

所属 类型 描述
TCP ConnectionPoolSetting.TCPSettings 由于HTTP和TCP的关系,这部分属性既会作用在http连接也会作用在tcp连接
HTTP ConnectionPoolSetting.HTTPSettings 这部分是对于应用层的HTTP连接专有的配置

HTTP连接池配置

  • http1MaxPendingRequests: 到目标主机最大等待请求数,如果不设定默认是1024,这是针对http1.1设定的,对于http2因为不会将请求放入队列所以不受影响。

  • http2MaxRequests: 对后端的最大请求数量,不设定会默认为1024、

  • maxRequestsPerConnection: 每次连接最大的请求数,如果这个属性值设为1,那么每次连接最多发送一个请求,也就是无法保持连接。

  • MaxRetries: 最大重试次数。

TCP连接池配置

  • MaxConnections: 最大连接数,但是只作用于http1.1也不作用于http2,因为后者只建立一次连接。

  • ConnectionTimeOut: TCP连接超时

负载均衡器配置

负载均衡概述

负载均衡有两种:基于负载均衡算法和基于一致性哈希。对于基于负载均衡算法的配置十分简便,只要在simpleLB配上响应的字段即可。

算法字段 描述
ROUND_ROBIN 简单的轮训算法,这也是默认的方式
LEAST_CONN 随机选择两个健康的主机,并且在两者中选择连接数少的一个
RANDOM 健康主机内随机选择
PAASTHROUGH 直接分发到目标地址主机

基于一致性哈希的负载均衡方式可以根据 HTTP header,cookie 来提供 soft session affinity,但是这种负载均衡方式仅支持 http 连接。

算法字段 描述
httpHeaderName 根据http header获得哈希
httpCookie 根据http cookie获得哈希
useSourceIp 根据IP地址获得哈希
minimumRingSize 哈希环中最小虚拟节点数,默认是1024

负载均衡样例

负载均衡策略配置十分灵活,可以针对某个服务进行配置,配置后隶属于该服务的所有 pod 将会按照设定的负载均衡方式进行请求的分配,除此之外,istio 也允许用户进行更深一层的配置,对于服务中的版本进行负载均衡配置的。配置后符合该版本的 pod 将会按照深层配置的负载均衡模式进行分配,其余的则还按服务层面的负载均衡模式进行分配。下面我们根据一个实例来看这种情况。

如图所示,绿色的内容是针对服务层面设置的负载均衡方式,如果请求了 ratings 这个服务那么默认将会采用最小连接数这个负载均衡方式,如果请求访问这个服务需要的是v3版本这时候版本级的负载均衡方式将会覆盖服务级的负载均衡方式,这时则会使用 ROUND_ROBIN 的方式。不同层级的负载均衡设置可以让操作者更加细化自身的服务设计。

总结

本文只介绍了很小一部分 istio 请求路由的内容,其灵活的配置,非侵入式的设计,跨平台的支持极大地提升了开发效率,降低了测试难度。深入理解 virtualservice,destinationrule 等是使用 istio 功能的基本前提,熟练使用连接池和负载均衡配置可以在有限资源的前提下最大化的提升应用性能。