0%

白话 istio

前言

istio 文档有很多,但是多是面向使用者的角度,介绍了好多个新概念,对于开发者而言,不是很友好。
最近折腾了一番 istio,以开发者的视角,简单谈谈我的理解。

一句话介绍

Istio 是零散的网关配置的组装 & 推送通道

背景

在现代网关软件中,已经积累了大量的通用能力,比如:路由,限流,鉴权,日志,等等各式各样的能力。
而且这些能力并不是一成不变的,而是在不同业务场景下,需要有不同的策略调整。
所以,网关软件会通过暴露配置,来满足各种场景的定制需求。

以往常规的搞法是,搞个配置文件,网关软件启动之后,读取本地的配置文件,按照配置文件的规则来执行网关的各种逻辑。
比如,经典的 Nginx,就是提供了一套配置语法,用户将配置写在文件里。
但是,随着网关规模越来越大,配置越来越多,更新也越来越频繁,配置文件已经不太能满足需求了。(主要是,不太好做到动态局部更新)
所以,又单独搞了一个软件,负责管理这些配置,其主要用途就是将配置同步给网关软件。

这里,也就对应了两个概念:

  1. 控制面,提供配置的软件;本文主角 istio 就是代表
  2. 数据面,具体执行网关逻辑的软件;比如 Envoy,它通常是作为 Istio 的搭档出场。

干什么的

搞懂一个软件,核心是抓住输入 & 输出

  1. 输入:各种零散的网关配置
  2. 输出:Envoy 能理解的配置

这里引出两个层次概念:

Istio CRD

如上所述,在网关领域,有各种各样的配置,那么,在 Istio 这一层,则对这些配置进行了一层语义抽象。
按照 k8s 的套路,也就有了 CRD 这个概念,Custom Resource Description(k8s 把啥都抽象为了资源)。
(当然,Istio 也可以读取 k8s 里的中的标准资源,比如 Service,Endpoints 等)

具体是咋个抽象的呢?列举几个 CRD:

  1. Gateway:描述网关层,流量进来的端口,协议,域名之类的
  2. VirtualService:描述的虚拟服务,主要是路由规则,比如不同请求的转发处理策略
  3. Destination Rule:描述服务的流量策略,复杂均衡算法,连接池策略等
  4. Service Entry:描述服务,地址,端口,等

举个栗子,有这么个需求:http://example.com/v1.txt 随机转发到 1.1.1.1:802.2.2.2:80 这两个地址,需要拆分为四个资源:

  1. Gateway,定义一个网关,端口是 80,协议是 http,域名是 example.com
  2. Virtual Service,定义个虚拟服务,uri 是 /v1.txt 的转发到一个目标 xxx
  3. Destination Rule,指定 xxx 目标的复杂均衡策略:随机
  4. Service Entry,指定 xxx 服务的地址:1.1.1.1:802.2.2.2:80

这里不同种类的资源,也就是 Istio 的输入,零散的网关配置。
CRD 是面向使用的抽象,用户只需要将希望的效果,通过 CR 描述出来,具体的实现是不用关心的。

为啥要拆开成这么多资源呢?以我开发者的视角,主要还是为了方便局部动态更新,比如应用服务扩容了,只需要更新 Service Entry 就行了,其他的不用动。

xDS

在数据面,也就是 Envoy 这一层,并不是直接接受 CR 的,而是又提供了一套自己的抽象。
也就是 LDS,RDS,CDS,EDS 这些,统称为 xDS,这里就不详细展开了。

简单点来说,xDS 的抽象更贴近 Envoy 的实现细节,Istio CRD 更贴近用户描述。
xDS,既是 Envoy 的输入,也是 Istio 的输出。

工作流程

首先,基本模式是,Envoy 是向 Istio 订阅指定资源。

当 Istio 收到一个 xDS 订阅时(比如 LDS),大致有这么几个环节:

  1. 筛选当前订阅的 xDS,所需要用到的 CR
    这里的筛选条件还是挺复杂的,也不细说了。举一个简单的,用 Envoy 所属的 namespace 来筛选
  2. 组装 & 转换
    一个 xDS 可能会对应多个 CR,这个时候需要组装起来,转换为 xDS 格式
  3. 推送
    推送给 Envoy,如果后续某个 CR 有更新,也是这个推送流程

那么,Istio 用到的 CR 资源是从哪里来呢?
有多种方式,从 k8s API server 来,从 MCP server 来,从本地 watch 的文件来,等。

Istio 收到了 CR 之后,就全量存储在本地内存中(是的,就是这么简单粗暴)

  1. 收到了 Envoy 的订阅,就走上面的筛选 & 组装 & 推送流程
  2. 收到了 CR 更新,也是走类似的筛选 & 组装 & 推送流程

总结

打个比方,Istio 就是一个工厂,将原材料 CR,加工成为 xDS,也就是它的下游(Envoy)所需要的原材料。
不过呢,它对需要的原材料是有标准的,也就是 CRD 描述的标准。

最后,软件系统就像积木一样,是一层层搭建出来的,每一层都有抽象出一套自己的标准。
如果抽象得好,表达能力强,适用范围广,大家都遵循这套标准,那就成为了业界标准,也就有了更长远的生命力。
如果只是一个小范围流行,生命力就没那么强了,不是说一定活不下去,但是很难说得上绚烂。