APISIX 结合 Istio 实现全链路灰度

作者:苏万亮,中国移动云能力中心软件研发工程师,专注于云原生、微服务、算力网络等领域。

前言

近期团队想利用Istio对产品做全链路灰度,但是对于产品已经选择Apisix作为网关的场景,出于不改变产品原有架构的考虑,不想再引入Istio Ingress Gateway,而只依赖开源的Apisix又无法对产品做到全链路灰度,因此便调研能否将Apisix和Istio结合实现全链路灰度。本文就介绍一下两种可行的方案,与大家一起探讨学习。

问题介绍

上图是简化的一个产品服务调用关系图。其中,Apisix ingress承接外部流量,根据路由规则请求client服务,client服务还会请求provider服务。现在的目的就是对服务client和provider全部做灰度,实现全链路灰度。而Apisix只能对入口服务client进行灰度,做不到全链路灰度。因此考虑引入Istio来实现全链路灰度,为了不改变产品的原有架构,不引入Istio Ingress Gateway,依旧只使用Apisix ingress一种网关。结合Apisix和Istio实现全链路灰度,在配置具体流量规则时共有两种方案,下面对两种方案做详细介绍。

方案一:网关注入sidecar,重写host

对于Istio的灰度方式,我们知道若一个已注入sidecar的服务所配置的灰度规则(virtualservices和destinationrules)想生效,需要请求访问它的服务同样也注入sidecar(是一个istio envoy)。因此对于入口服务client,若引入Istio Ingress Gateway当然没有问题,Istio Ingress Gateway本身就是一个envoy,现不引入Istio Ingress Gateway的话,就需要对Apisix的数据面注入sidecar,如下图所示。

对于服务client,其正常灰度规则配置如下:

apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: client spec: host: client subsets: - labels: version: v0-0-1 name: v0-0-1 - labels: version: v0-0-2 name: v0-0-2


apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: client
spec:
hosts:
- client
http:
- match:
- headers:
client_version:
exact: v0-0-2
route:
- destination:
host: client
subset: v0-0-2
- route:
- destination:
host: client
subset: v0-0-1

上述规则中,hosts的配置为client(kubernetes的完全限定域名),表示根据访问client服务的请求是否带请求头client_version:v0-0-2决定流量路由到某版本。而对于Apisix来说,一般配置规则为:hosts为www.xxx.com,匹配到某路径转发到client服务。这样Apisix和Istio的规则就匹配不上,导致灰度规则不生效。

因此若想服务client的灰度规则生效的话,则需要在外部流量进入Apisix网关后,重写其host。对于重写host,可使用Apisix的插件proxy-rewrite将请求host(www.xxx.com)改成k8s内部域名(test.ns.svc.cluster.local)。具体配置如下:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: ingress-testclient
spec:
http:

  • backends:
    • serviceName: client
      servicePort: 8070
      match:
      hosts:
      • www.xxx.com
        paths:
      • /client/*
        name: testclient-route-default
        plugins:
    • config:
      host: client.wgb.svc.cluster.local
      enable: true
      name: proxy-rewrite
    • config:
      burst: 1
      key: remote_addr
      key_type: var
      nodelay: true
      rate: 1
      rejected_code: 503
      rejected_msg: limit-req-error
      enable: true
      name: limit-req

      通过上述配置,外部流量经过Apisix后,其请求头host:www.xxx.com就被重写成host:client.wgb.svc.cluster.local,从而匹配到服务client的virtualservices中的host,灰度规则生效。

      上述方案虽然可以实现client服务的灰度,但其很明显的问题就是若client服务本身会根据传入的host值来处理业务,那丢失原有的host,对业务带来的影响就很大。

      方案二、各施其职,不重写host

      对于Apisix来说,虽然不能对产品做到全链路灰度,但是其针对入口服务,即图中的client服务,是具备灰度发布能力的。因此第二个方案就是将入口服务交给Apisix来灰度,其余非入口服务交给Istio来灰度。

      通常一个产品由多个微服务构成的话,其大部分服务都不是入口服务,因此都可以用Istio实现这些服务的灰度发布。Istio的灰度方式不做赘述,以provider服务为例,通常是会部署两个deployment对应其两个版本,一个service关联这两个版本的pod,再通过配置virtualservices和destinationrules即可实现灰度。对于整个产品全链路灰度,最好是能将灰度版本的服务部署方式统一起来,即对于入口服务client,也部署两个deployment对应其两个版本,一个service关联这两个版本的pod,但用Apisix的路由配置来实现灰度。具体方式就是利用ApisixRoute+ApisixUpstream实现下发规则路由到不同版本的client服务。Apisix相关配置如下:

      apiVersion: apisix.apache.org/v2
      kind: ApisixUpstream
      metadata:
      name: client
      spec:
      subsets:

  • name: v0-0-2
    labels:
    version: v0-0-2
  • name: v0-0-1
    labels:
    version: v0-0-1

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: ingress-testclient
spec:
http:

  • backends:
    • serviceName: client
      servicePort: 8070
      subset: v0-0-2
      match:
      exprs:
      • op: Equal
        subject:
        name: client_version
        scope: Header
        value: v0-0-2
        hosts:
      • testclient.com
        paths:
      • /client/*
        name: route-v2
        priority: 1
  • backends:
    • serviceName: client
      servicePort: 8070
      subset: v0-0-1
      match:
      hosts:
      • testclient.com
        paths:
      • /client/*
        name: route-default

        从上述配置可以看出,首先ApisixUpstream根据不同版本的pod的标签创建subset,配置规则与Istio中的destinationrules类似,其次ApisixRoute也只需要定义好匹配规则,选择路由到服务client的某个subset。整个配置同样只需要client服务存在两个deployment对应其两个版本,一个service关联这两个版本的pod。

        需要注意的是虽然client服务是用Apisix做灰度,但其也需要注入sidecar,因为provider的灰度规则需要client同样是一个envoy。另外该方案仅针对服务的灰度发布能力,没有对Apisix的数据面注入sidecar,若产品还需要提供完整的服务拓扑或链路追踪功能,对Apisix的数据面注入sidecar即可。

        总结

        本文针对产品已使用Apisix作为网关,并想在不改变产品原有架构的前提下,对产品的所有服务实现全链路灰度,提出了两种可行的方案。两种方案各有利弊,方案一实现较简单,但需重写host,要考虑产品能否接受,不适用于所有产品;方案二无需重写host,产品都能接受,但灰度逻辑略复杂,配置也略复杂。因此,使用哪种方案需根据产品本身架构来决定。