干货|eBay基于Istio的应用网关的探索和实践

作者|陈佑雄

编辑|林颖

供稿|Network SIG/PaaS Team

本文共12522字，预计阅读时间30分钟

更多干货请关注“eBay技术荟”公众号

随着Kubernetes的不断发展和推广，服务网格（Service Mesh）在近几年也变得很流行。服务网格作为服务间通信的基础设施层，通过构成现代云原生应用程序的复杂服务拓扑，负责将请求进行可靠的传递。这里的云原生（Cloud Native）不仅仅是包括运行时的云原生，也包括网络的云原生。

具体的云原生概念可以参考CNCF 2018年的定义^[1]：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建“容错性好、易于管理和便于观察”的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

这里面有几个关键字：容器、服务网格以及微服务，而Istio正是我们选择实现服务网格的一个重要组件，我们内部也称Istio为应用网关（Application Gateway）。

Istio官网的解释是：“Istio允许您连接、保护、控制和观察服务，它是一个完全开源的服务网格，作为透明层接入到现有的分布式应用程序里。同时，它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio多样化的特性，能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。”

而社区的解释有一些抽象：笔者更倾向于把它当成是一个同时支持服务网格以及网关的Ingress控制器。用更加通俗易懂的话来说，Istio能够提供从网格外部访问网格内部L7规则的管理、SSL（Secure Sockets Layer）终结以及负载均衡，同时还能通过给负载注入Sidecar模式，实现网格内部端到端加密、限速、授权认证等功能。

从上述对Istio的描述中可以看出：

①Isito既能够充当API Gateway的控制器，管理跨网格的南北向流量以及L7规则；

②同时也能够将服务网格化，实现网格内部应用调用直接走东西流量，并且实现全链路加密。

以上两点我认为是选择Istio作为eBay应用网关的两个主要的原因。Ingress控制器本身有很多第三方的项目的实现，比如Ambassador、Contour、HAProxy Ingress等等。这些项目都各有所长，而且Contour已经在eBay另外一个项目“UFES”上成功在eBay边缘节点得到生产化应用，具体可以参考eBay边缘节点的云原生网络实践^[2]，我们现在的目标是希望Istio能够在数据中心得到广泛的生产化应用。

这里我们用到了Istio以下几个主要的定制资源定义（Custom Resource Definition，CRD）来管理流量:

①VirtualService：用于定义网格内的路由规则，也就是L7规则；

②DestinationRule：用于定义路由规则的目标服务和流量策略；

③ServiceEntry：将网格外部的服务注册到网格内部，并对其进行服务发现和流量管理；

④WorkloadEntry: 用来描述非k8s的工作负载（workload），比如VM/BM（Bare Metal/Virtual Machine）。ServiceEntry可以通过label selector同时选择WorkloadEntry和Pod;

⑤Ingress：管理进出网格的流量，包括端口、协议、SNI配置以及TLS证书等；

⑥Sidecar：用来管理Istio给workload注入的sidecar的相关配置，包括Sidecar能够接受的端口，协议以及限制Sidecar能够访问的服务；

通过Istio以上的定制资源定义，可以很方便地对进入网格、网格内部以及访问网格外部服务的流量进行控制。

eBay的数据中心目前通过大量的硬件负载均衡设备来管理流量，总计有将近2,000多对的硬件负载均衡设备，它们提供了L4到L7的负载均衡的功能，包括TLS终结、L7规则配置以及流量管理等等。通过这些负载均衡设备，最终会将外网进入eBay数据中心的请求负载到不同应用的后端服务器。

图2.1是目前eBay数据中心的两层硬件负载均衡架构图。其中，GTM是智能DNS，主要功能是对VIP（Virtual IP）做健康检查以及流量权重配置等等。

图2.1 两层硬件负载均衡架构图

(点击可查看大图)

之所以称为“两层”架构，是因为其中有两组负载均衡（Load Balancer，LB）设备：

App层LB：这层LB连接的是应用后端服务器，VIP的协议是HTTP，通常根据最小连接算法进行负载均衡

Web层LB：这层LB连接的是App层的VIP，VIP的协议是SSL，并启用轮询算法，配置有少量L7规则，同时根据99:1:1的权重将流量下发到三个数据中心的App层VIP。

通常eBay生产应用会跨三个数据中心部署，而实际的情况可能不止3个Web和3个App VIP。为了实现更高的可用性，应用会在每个数据中心的多个可用区分别部署，有可能是9个Web和9个App VIP。又由于eBay应用的微服务架构，导致消耗了更多的VIP和硬件负载均衡设备。此外，数据中心内部服务间的调用以南北流量为主，即请求需要经过负载均衡设备，这种服务间的调用也是导致负载均衡设备数据面过载的一个很重要的原因。

除了硬件负载均衡设备数据面无法弹性增加带宽的瓶颈以外，其控制面的性能也比较差，如通过封装的API创建一个VIP需要数分钟才能完成，这也是促使我们将硬件负载均衡设备用Istio来替换的重要原因。

目前，eBay有3个主数据中心，主要部署eBay的各种应用后端服务器。另外，还有20多个边缘数据中心，用来管理外网接入eBay的请求，现通过UFES项目边缘数据中心已经实现了基于IPVS的Contour的网络云原生，成功替换了硬件负载均衡设备。此外，还有100多个面向用户的Kubernetes集群，上面部署了多种应用，包括Hadoop、Elastic search、Kafka等等。

数据中心Kubernetes集群总计达100,000物理节点，单集群物理机节点规模可以达到5,000个，并且通过近两年C3 to Tess（OpenStack to Kubernetes）的迁移，绝大部分的应用服务已经全面实现容器化。单集群Pod实例可达100,000个，发布服务可以达到5,000-10,000个。另外由于eBay的Dev网络是通过OVN与生产环境网络进行隔离的，这也导致我们需要在单个Dev网络的Kubernetes集群支持多环境支持，比如功能测试、集成测试。压力测试会共用一个Kubernetes，甚至还会在同一个Dev集群部署安全的测试环境，集成软件防火墙。

这种规模化给Istio在eBay落地上带来以下几个挑战：

①Istio控制面和数据面潜在的性能问题；

②Istio单集群多环境部署，不同环境之间数据面和控制面的隔离；

③多集群多环境的管理；

④Istio跨可用区（Mesh）的故障转移。

Istio里面有几个很容易混淆的概念，分别是Ingress CRD、IngressGateway Pods以及Gateway Service，这几个虽然是完全不同的概念，但是它们互相有着密切的关联。

1）Istio Ingress CRD

它的主要作用是用来描述访问网关的服务端口、协议以及证书等信息。比如下面的foo-ingress Gateway资源定义了“访问网关服务foo.example.com协议是HTTPS，端口是443以及相关的证书和私钥”，最终这些配置（包括证书）会由Istio的Discovery Service生成Envoy的配置，再通过XDS接口推送到IngressGateway Pods。而IngressGateway Pods本质上就是一个Envoy集群，或者称L7 Cluster，作为数据面，来处理所有通过网关进入网格的流量。

(点击可查看大图)

2）IngressGateway Pods

它们像是一个网格的边缘节点，能够代理所有外部进入网格的流量，并且会把相应的请求通过L7路由转发到后端应用的Sidecar，具体如图3.1所示：

图3.1 IngressGateway代理网格边缘流量

(点击可查看大图)

3）Gateway Service

它其实是一个Kubernetes Service，它本身有多种类型，比如ClusterIP、Node Port以及LB等，它实际上是一个L4的Service，功能上有点像一个TCP proxy，位于用户和IngressGateway之间，将用户的请求转发到IngressGateway Pods, 完整的架构图如图3.2所示：

图3.2 Gateway Service与Gateway Pod关系

(点击可查看大图)

图3.3是基于IPVS和Istio的网络云原生架构图，这也是一张多次引用的很经典的图，这也是目前eBay云原生网络的一个基础的架构图。

图3.3 基于IPVS和Istio的网络云原生架构

(点击可查看大图)

Istio Ingress本身没有提供Gateway Service的实现，但是Gateway Service提供了很重要的L4负载均衡。它将用户请求通过TCP转发到IngressGateway Pods（即L7 Cluster)，以进行进一步的TLS终结和L7路由转发。对于L4的实现，我们称之为TLB（Tess LoadBalancer)，它是基于IPVS，具体实现细节可以参考eBay的4层软件负载均衡实现^[3]，所以Gateway Service本质上就是一个IPVS Service。因此，TLB加上Istio才完整实现了eBay的软件负载均衡，并且能够同时具备L4和L7负载均衡的功能。

1）L4 Cluster

L4集群本质上是一组IPVS Pod，这组Pod上面运行了IPVS，同时也运行了TLB控制器，对Pod网络空间的IPVS规则进行编程，所以L4的控制面和数据面都运行在同一个Pod。除了TLB控制器，还有相应的TLB Service控制器，负责VIP IP分配的IPAM控制器、BGP宣告和创建主机路由的控制器等等。通过上述这一组控制器实现了完整的L4的软件负载，主要提供了以下功能：

①四层软件负载调度。每组L4 Cluster相当于一个4层软件负载均衡，分配1,000个VIP，同一个k8s集群上会部署多个L4集群，需要一个调度器选择L4集群。

②不同应用配置独立网关VIP，以支持微服务架构。

③配置IPIP Tunnel模式的IPVS规则，同一组L4集群上面配置的IPVS规则相同。

④基于BGP VIP子网路由宣告，这里利用开源的Bird守护进程宣告VIP网段路由到机架顶部交换机(TOR），每个TLB Pod会分别宣告一条路由，主要内容是创建VIP网段到下一条的路由，比如10.0.0.1/22, nextHop:TLB Pod IP。

⑤配置IngressGateway Tunnel接口，这里是通过内部实现的netd（以DaemonSet方式运行）来创建tun接口并且绑定VIP，以支持IPIP Tunnel。

⑥支持Direct Server Return (DSR），即客户端请求会经过L4集群，服务端响应不会经过。

2）L7 Cluster

L7集群主要是指Istio，包括Istiod（将Istio控制平面组件合并为的一个二进制文件）和IngressGateway。前者是Istio的控制面，主要功能是生成Envoy的配置文件，并推送到IngressGateway（它是L7集群的数据面，实际上是一个Envoy集群）。Istio作为应用网关控制器主要提供以下功能：

①管理应用L7规则。数据中心的Web层LB上配置有一部分L7规则，这部分规则最终会被转换成VirtualService/Gateway，配置到网格的边缘节点。

②自动化生成eBay证书。网格边缘启用的是单向TLS，这里和eBay的CA集成，保证网格外部进入网格传输安全。

③管理和注入Sidecar。通过Sidecar能实现流量透明劫持，应用和框架不需要考虑传输安全以及限速，授权和认证等功能。

④网格内部会强制启用双向TLS。这里Istiod同时充当了网格内部的CA（Certificate Authority），接收Sidecar发送的证书签名请求（CSR）并且通过自签的根证书签发叶子证书，再通过SDS（Secret Discovery Service）推送给Sidecar。

通常应用开发需要在多个环境验证，进行多种测试，才能最终发布到生产环境。eBay内部有很多种环境，主要有两大类：

1）非生产环境，通过OVN和防火墙与生产环境隔离，主要包括以下几种：

-Feature：功能测试环境

-Dev：开发测试环境

-LnP：压力测试环境

-Staging：集成测试环境

-StagingPCI：安全的集成测试环境

2）生产环境，主要包括以下几种：

-Pre-Production: 预发布环境

-Production: 生产环境

-TCoP: 允许所有其它环境访问的生产环境

-PCI（Payment Card Industry）：安全的生产环境

因为一个k8s集群会同时支持多个环境，所以这里采取了单个k8s集群部署多套Istiod，IngressGateway和L4集群，实现不同环境控制面数据面隔离，主要架构如图4.1。

图4.1 Istio单集群多环境部署

(点击可查看大图)

这里我们选取（Cherry-pick）了社区Pilot Scoped Namespaces PR^[4]。它主要实现了Istiod能够根据命名空间（Namespace）选择性的观察一部分Service、Pod以及Endpoint。它的实现机制是引入一个如下discoverySelector，通过这个配置Istiod只会观察命名空间的环境是Feature的相关资源。

这个PR是今年2月份才合并到master的。它在很大程度上缓解了Istiod在复杂k8s集群的控制面和数据面的性能问题。

为了实现全链路（从客户端到服务端全程）加密，这里需要在网格边缘节点以及网格内部分别配置证书。所需要配置的证书有：

1）网关证书

社区对网关证书的做法是通过Secret保存证书和私钥，Istio的Secret Discovery Service最终会将证书和私钥推送到IngressGateway。然而，eBay信息安全的规定是私钥不能存盘，所以社区Secret的实现不能满足安全要求。

为了实现社区Secret，我们首先集成了eBay定制的CA、Secret保存证书的URL以及私钥的URL。然后，Istiod集成一个cert agent sidecar（该agent提供GRPC接口，负责通过URL分别获取证书和私钥内容），Istiod通过cert agent GRPC获取完整证书信息后，再通过SDS推送到IngressGateway，具体流程如图4.2：

图4.2 Istio IngressGateway证书集成

(点击可查看大图)

2）集群证书

我们利用一个自签根证书为每个Istio集群签发中间证书，这也是社区推荐的做法，Istiod充当了网格内部的CA，网格内部Sidecar的证书是Istio维护的，证书有效期是24小时，也就是每天会更新一次。Istio多集群的证书管理如图4.3所示：

图4.3 Istio集群证书管理

(点击可查看大图)

单网关是指将应用部署在一个服务网格，这是一种很常见的部署模式。IngressGateway充当网格的边缘节点，将外部流量单向加密转入网格，网格内部通信双向加密，最终实现全链路加密(E2E TLS)。

这种模式适用于对可用性要求不高场景，比如Dev/LnP/Staging Secure测试环境，同时支持API Gateway和Mesh的应用场景，支持为应用配置独立Gateway VIP，并且不同环境配置专有L4/L7集群，实现控制面和数据面的隔离。此外，IngressGateway还集成了eBay的软件防火墙（Sentinel），默认会阻止所有访问。防火墙会保护Ingress/Egress流量，同时也会保护进入Pod的流量，具体的实现是通过在节点创建IPtables规则。这也是我们第一次实现全链路加密并且有防火墙的集成测试环境，由此我们可以完整的模拟生产环境，具体架构图如图4.4：

图4.4 单网关全链路加密模式

(点击可查看大图)

eBay目前有三个数据中心，每个数据中心又会有多个可用区（可用区是数据中心中具有独立供电制冷设备的故障域）。在同一个可用区，网络延迟较小，同时可能会部署多个Kubernetes集群。我们内部实现了联邦Kubernetes集群，能够统一管理不同数据中心的Kubernetes。由于集群联邦API Server是用户访问Kubernetes集群的入口，所有Kubernetes集群需注册至集群联邦。

图4.5 Istio多网关多集群部署

(点击可查看大图)

eBay应用的生产环境部署通常会跨三个数据中心，因此需要支持Istio多集群的部署。社区对于Istio多集群提供了多种方案，这里我们倾向于选择Istio Primary-Remote的方式，具体部署架构如图4.5所示。这种部署模式有以下几个特点：

①一个可用区会部署一个Kubernetes网关集群以及若干个面向用户的Kubernetes集群；

②在网关中Kubernetes集群中，部署了Istio Primary。而面向用户的Kubernetes集群部署Istio Remote，一个可用区为一个服务网格，所有集群采用相同RootCA签发的中间证书；

③东西南北流量统一管控。同一可用区的服务调用基于Sidecar，走东西向流量，跨可用区的服务调用基于Istio Gateway。

1）Istio Primary-Remote压力测试

由于Istio多集群计划采取Primary-Remote部署模式，针对该模式我们在eBay的环境下进行了压力测试。Istio控制面性能主要考虑两个配置推送到网格的收敛时间（convergence time）：

①Sidecar EDS，主要是将Endpoint的配置信息推送到Sidecar，这里衡量的是Sidecar的控制面。

②Gateway XDS，也就是网格内部的配置信息，包括RDS、EDS、LDS、CDS、SDS等将配置信息推送到Gateway的收敛时间，这里衡量的是网关的控制面。

我们分别实现了两组压力测试场景来测试网格内部控制面的性能，压力测试的用例主要是Huang Lei同学实现的，这里是压力测试的一些配置参数：

在运行压力测试中，Pilot资源为CPU 32, Memory为200Gi；Gateway资源为CPU 4, Memor为20Gi。

图4.6 Sidecar压力测试

图4.6是Sidecar压力测试的结果，横坐标是Sidecar的数量，纵坐标是延迟。在这个压力测试场景中，Gateway Pod以及Istiod Pod数量分别为1个。资源映射为1 GW -> 1 VS -> 1 SVC -> 10 Endpoints -> 5 ports。在运行压力测试过程中，会有100个Endpoint同时发生变更（增减Endpoint中IP地址的数量）。从这个图中我们可以看出，在2,000个Sidecar和100个Endpoint发生变更的条件下，Sidecar EDS延时的99分位数是5秒钟。

图4.7 Gateway压力测试

图4.7是Gateway压力测试的结果，横坐标是Service的数量，纵坐标是延迟。测试环境中有32个Gateway Pods以及1个Istiod Pod，资源映射为1 GW -> 1 VS -> 1 SVC -> 10 Endpoints -> 5 ports。在运行压力测试过程中，会有100个Endpoint同时发生变更（增减Endpoint中IP地址的数量）。从这个图中我们可以看到，在2,000个Service和100个Endpoint发生变更的条件下Gateway XDS延时的99分位数是5秒钟。

基于这两组测试，我们对Isito Primary-Remote部署方式的压力测试有以下的一些结论：

1）单个Istiod 32 CPU/10G内存可以支持：

- 32个Ingress Pods

- 2,000个Sidecar

2）收敛时间小于5秒能够支持的规模：

- 2,000 k8s Service(5个端口)

- 其中有100个Endpoint地址发生变更

3）如果k8s Service数量少于2,000，为了实现收敛时间小于5s，Istiod Pod的数量可以通过如下公式计算:

2）Istio Primary-Remote的挑战

通过Primary-Remote的方式，我们可以实现可用区级别的Mesh。比如在每个可用区部署一个网关k8s集群，将Istio控制面部署到网关k8s集群，而且可以通过在网关集群上配置专用的硬件加速卡以实现TLS加速等。其带来的好处是Istio控制面和数据面的隔离，随之而来也会产生一些挑战：

①可用区级别Mesh规模和性能问题。Mesh规模越大，性能问题会更加明显，而如果拆分网关，又会导致可用区Mesh的数量增加。

②更加复杂的流量管理和运维管理。由于Remote集群并没有Istio控制面，导致负载会创建在Remote集群中，但是Istio相关的资源则需要创建到Primary集群中。用户创建资源的分散会增加管理的成本和复杂度。

既然Istio会通过多集群部署，我们也要为应用的部署提供多集群的接入方案，主要涉及到跨集群、跨网格的流量管理以及故障容灾两个方面，部署架构图如图4.8所示：

图4.8 应用跨集群部署

(点击可查看大图)

1）流量管理

这里仍然使用GTM（智能DNS）来配置多个数据中心的网关VIP，并且能够设置不同数据中心网关VIP的流量权重。L4 IPVS 为流量入口，会将流量转发到Istio的网关，应用数据面从网关Envoy到Sidecar Envoy，这种模式下网格内部没有跨数据中心流量。

2）故障容灾

GTM会对VIP进行周期性的TCP健康检查，大概是每十秒检查一次，如果发现VIP TCP检查不过，会自动停止返回该VIP给客户端。由于VIP的目的地址是IngressGateway，这种健康检查只会在IngressGateway整体宕机才会生效。如果Istio网关宕机或者应用后端Pod整体宕机，都会给客户端造成数据面的影响，因为客户端DNS解析可能缓存了已经不可用的VIP。为了实现VIP和应用后端服务器的联动，我们实现了一个健康检查控制器，该控制器会监控应用的后端服务器，如果整体宕机会将该VIP标志为不可用，这样GTM将不会继续返回VIP到客户端。

这种模式目前我们也应用到了生产环境，但是会有一定的风险，后续我们会实现一些更加高可用的部署模式，能够做到即使应用的后端服务器在某个数据中心整体宕机也不会造成数据面的影响。

Istio中定义了多种资源管理L4到L7的流量，同时Kubernetes中有Service以及eBay内部定义的TLB相关资源。为了便于统一管理这些资源，我们定义了AccessPoint资源，这也是一个联邦资源，用户只需要通过Federated APIServer创建一个AccessPoint，相应的联邦控制器会将资源同步到用户指定的集群，而集群中的控制器会进一步创建在AccessPoint定义的Istio/Kubernetes资源。

早期我们在定义该资源的时候，曾经取名FederatedService以及FederatedIngress，但是这些名字都不能完整的表达统一L4和L7的流量管理模型，所以最终取名为AccessPoint。这个模型存在的作用是能够方便我们能够统一管理Istio和Kubernetes中众多松散的流量管理资源，并且支持联邦管理。后期我们可以定义一些模板开放给用户，这样也能降低用户使用的复杂度。图4.9是用户创建一个AcessPoint的流程图：

图4.9 AccessPoint统一流量管理模型

(点击可查看大图)

下面的表格是AccessPoint资源的主要SPEC，里面主要封装了Isito和Kubernetes的资源，同时能指定资源需要同步到的集群。并且，该SPEC能够在不同的集群中通过修改模板属性值来进行定制。此外，还能在SPEC中指定流量策略，比如运行时的策略、不同数据中心的流量权重以及发布策略，主要是指在执行L7规则变更的过程中能支持对不同可用区逐个变更。最后一部分是状态的收集和汇总，每个集群的网关VIP、证书、FQDN的状态都会同步到Federated APIServer，能够给用户提供一个全局的状态。

这一个章节主要分享一些Istio在eBay实践的具体案例，这些案例包括了Istio支持的API Gateway以及Service Mesh不同使用场景。同时，结合eBay业务的具体需求，希望大家能够对Istio的功能有一个更直观的认识。

早期eBay的Feature测试环境的软件负载均衡是基于OpenStack的Neutron/LBaaS的。它充当了一个API Gateway的角色，不同的Feature测试集群通过创建不同的CNAME（Canonical Name）以及L7规则被路由到不同的后端应用。这种场景是Istio IngressGateway原生就支持的，所以我们在2019年尝试将这套系统迁移到Istio。

通常一个Feature测试环境包含一个Pod和若干个CNAME，我们需要支持大概5,000个Feature测试环境（即Pod、VirtualService、Gateway以及Service各5,000个），另外还有5,000+个CNAME，这些CNAME都会指向同一个Gateway VIP的A记录。

同时，会在网关配置Wildcard证书，通配所有的CNAME。L7的规则主要在VirtualService指定如下的主机名匹配的转发规则：

通过这条L7规则会将所有访问域名（foo.example.com）的请求转发到foo对应的后端服务器，具体架构图如图6.1。

图6.1 基于Istio网关的Feature测试开发环境

(点击可查看大图)

这套方案的初衷是先将Isito作为API Gateway的使用场景，现在Feature测试开发环境得到应用和验证，再逐步推广到集成测试、压力测试以及最终到生产环境，但是很不幸这套方案遇到了严重的性能问题并且最终失败了。当时Istio是基于1.3版本，当创建了1,700个Feature测试集群之后，Pilot会出现OOM并且无法恢复。主要的原因是Pilot会对集群整体进行服务发现，所以会因配置过多导致控制面出现性能问题，使得CDS推送太慢，进而造成了Listener缺失，这也就意味着数据面无法正常工作。

目前，Feature集成环境是通过另外一套方案实现的，具体可以参考eBay Feature测试环境上k8s的实践^[5]。解决Istio IngressGateway性能问题主要有两个方向：

①基于命名空间过滤，Isiod只监控Feature环境的Pod、Service以及Endpoint，社区的PR今年已经合并到master分支了。

②对IngressGateway进行切片（Sharding）。比如我们限制一个IngressGateway只能创建2,000个Pod，甚至可以对Istiod也进行切片，做到数据面和控制面的隔离。

CAL是eBay的集中日志系统，这套系统之前是基于硬件负载均衡，应用的后端服务器根据CAL Ingress的地址将日志发送到CAL系统。这里我们采用了两种模式来实现CAL，分别是IngressGateway模式和Mesh模式，其目标都是为了替换掉硬件负载均衡。

1）IngressGateway模式

在这种模式中，Istio作为一个API Gateway，能够与原有的硬件负载均衡架构无缝替换，eBay应用以及CAL服务器几乎不需要做任何修改，只需要创建一个新的Gateway VIP，更新到GTM，并且停用原来的硬件负载均衡VIP。目前这套方案应用到了CAL的集成测试环境，具体配置如下：

(点击可查看大图)

图6.2是基于Istio网关的CAL IngressGateway活跃连接数。因为这里的IPVS是工作在IPIP Tunnel模式，所以TCP的连接不是建立在IPVS Pod上，而是在Ingress Gateway Pod上。这里我们可以看到Ingress Gateway的总连接数稳定在8万个。

图6.2 基于Istio网关的CAL IngressGateway

(点击可查看大图)

图6.3是基于Istio网关的CAL入站流量，这里我们看到总流量是150MB/s，这只是集成测试环境，而实际生产环境下总的流量会达到50GB/s。

图6.3 基于Istio网关的CAL入站流量

(点击可查看大图)

2）Mesh模式

网关模式下面，应用写CAL日志依旧需要经过负载均衡，并且走南北向流量，这种方式并不是最高效的。长期来看，较好的方式是：网格内部的流量直接走东西向；另外通过在客户端和服务端分别注入Sidecar，在实现客户端Egress服务发现的同时，也能支持日志的端到端加密。

这就是基于Mesh的CAL方案，这套方案目前也已经应用到集成测试环境，后期也会被采用到生产环境，具体架构如图4.6：

图6.4 基于Isito Mesh的CAL

(点击可查看大图)

NuObject是eBay用来替换Swift的一个对象存储服务系统。这套系统会基于Isito的IngressGateway模式下实现，前期我们对这套方案实施了数据面的高吞吐压力测试，最终结果（如图6.5）是Gateway达到30Gb/s，存储后端服务器器物理机达到40Gb/s。

图6.5 NuObject压力测试数据面

(点击可查看大图)

在压力测试初期，Gateway吞吐量停止在10Gb/s。后来，我们通过使用巨形帧（Jumbo frame）9,000bytes MTU以及对压力测试使用的物理机进行性能调优，显著提升了Gateway的吞吐量。同时，也遇到了后端服务Sidecar OOM的问题，增加Sidecar内存增加到3GB解决了OOM。

图6.6 NuObject压力测试流程

(点击可查看大图)

图6.6是压力测试的流程图，除了数据面的压力测试，这套方案提供了另外一个很重要的功能——全链路加密。该套方案通过以下手段实现了高安全性存储服务：

①注入Sidecar到后端服务

②网关配置Simple TLS

③网格内部mTLS

④集成软件防火墙

目前这套方案已经应用到生产环境，总体规模会达到1,000个Deployments^[6]，并且会分配到200个VIP，服务于不同的存储客户端。在实际的生产环境应用中，有的客户会在半个小时内上传近2TB的文件。由此可以看出，这套方案基本经受住了考验。

语音服务是eBay的客户服务，客户可以通过拨打服务电话联系客服。这套服务之前部署在虚拟机，而且要做到会话保持（Session Stickniess)，也就是同一个客户端的会话需要在同一台后端服务器进行处理。

会话保持是Isito支持的一个功能，主要实现方法是：通过创建一个DestinationRule，并在其中指定流量策略，IngressGateway在处理负载均衡时会通过指定的HttpCookie名称实现一致性哈希算法的调度。

其具体配置如下：

Managed Stack是使用eBay框架的应用，内部称为Raptor、Raptor IO、Raptor Web等等，主要包括Java、Java Web、Batch以及NodeJS应用。eBay的框架有点类似一个软件开发套件（SDK），它内置了一些与eBay内部各系统集成的功能，比如日志系统、监控系统的集成以及通过内置Envoy实现服务端加密等功能。通过这种框架，应用只需要关心自身的业务逻辑，在一定程度上将业务和服务治理进行解耦。

而Mesh则将TLS、负载均衡、熔断限速以及授权验证等功能进一步与框架解耦，将这一部分服务治理的功能下沉到Sidecar。同时，它还实现了与业务自身逻辑以及框架的解耦，如图6.7所示。

图6.7 Managed Stack集成Mesh

(点击可查看大图)

目前Managed Stack承担了整个eBay站点大部分的流量，服务数量也众多。生产环境应用数量超过4,000个，个别应用部署后端服务器超过3,000个，生产环境Pod总数超180,000个，这些也是我们正在解决的问题。同时，在集成服务网格的过程中，我们需要将应用运行和部署模式也转变为云原生。

虽然这些应用在生产环境大都已经部署在Pod中，但是实际上它仍是一个胖容器（Fat container），我们依然把Pod当成虚拟机使用。Pod在启动的时候并不会下载应用镜像并直接启动应用，而是只启动一个Agent，再通过发布系统调用Agent接口去部署应用。目前我们正在进行框架和Mesh的集成，全面将服务运行和服务治理转向云原生，这套方案已经在集成测试环境中开始验证，最终会发布到生产环境。

图6.8是Managed Stack同时支持Mesh和Gateway的一个架构图。

图6.8 Managed Stack同时支持Mesh和Gateway

(点击可查看大图)

这也是我们对于将eBay生产应用跨数据中心部署并集成服务网格的一个最终状态的构想图：

①应用在网格内部通过Istio的服务发现将服务间的调用转为东西向流量；

②通过在客户端和服务端分别注入Sidecar，实现服务间调用端到端加密；

③为了保证高可用性，同时支持跨Mesh，跨数据中心的服务调用，以应对极端情况网格内服务整体不可用的情况；

④跨Mesh的流量通过远端Gateway VIP接入，Gateway VIP采用HTTPS协议。

在整个的实践过程中，我们也遇到了一些社区暂时还没有解决的问题。这些问题可能在简单的用户场景下不会暴露，但是随着用例越来越多，对可用性和安全性要求也在增加，这就变成了我们必须要面对和解决的问题。

1）端口协议冲突

Istio从1.6开始已经是非root权限运行，这也就意味着IngressGateway不支持特权端口（privileged ports），即端口号小于1024。社区的做法是让IngressGateway监听在Gateway Service的目标端口，也就是做了一个端口映射，将80映射到8080，443映射到8443。如此一来对用户暴露的还是80和443，但是Envoy实际监听在8080和8443。这里有个问题是目前只做了这两个端口的转换。对于其它的端口，比如22、53等等，也需要实现类似的端口转换。

另外一个问题是同一网关端口不能同时支持TCP/HTTPS。比如同一个Mesh里面有个用户需要创建一个Gateway，这需要创建一个8888的Ingress端口，协议是HTTPS，而另外一个用户也需要该端口，但是协议却是TCP。面对这种情况，目前同一网关无法实现。

目前，我们考虑的解决方案是给不同的Gateway分配一个独立的目标端口，比如Ingress 8888/HTTPS分配的目标端口是18888，而Ingress 8888/TCP分配的目标端口是18889。

2）从外部访问mTLS Mesh单个机器

为了保证网格内部是双向加密，我们默认开始了STRICT模式的PeerAuthentication^[7]，但它导致无法从网格外部无法直接访问网格内部的机器，因为网格外部的客户端无法从Istiod获取客户端证书。

这里我们的解决方案是利用Subset Load Balancing以及定制的EnvoyFilter从URL的path或者Header解析到Pod的地址，再通过定义L7规则将请求转发到指定的Pod。这样客户端能通过访问Gateway并且指定地址，来访问到后端服务，URL地址如下：

3）Envoy Readiness Probe

这个问题的本质是如何保证网格内部的Sidecar数据面是正常可达的，不仅仅包括Sidecar的证书是合法有效，同时也要确保IngressGateway到Sidecar是可以正常访问。对于这一点，硬件负载均衡通常会对后端的服务器做健康检查。但是，Isito是服务发现的机制，它依赖于kubelet^[8]进行对Pod进行健康检查，这种检查不能保证数据面正常。

目前,我们考虑借助于Pod的Readiness Gate来解决该问题，也就是在Pod启动的时候通过一个外部的服务访问该Pod，只有能够正常访问才对Pod标记为健康的。

4）Init Container inbound/outbound被阻止访问

这也是社区的一个已知问题，原因是因为目前Isito Sidecar的IPtables规则不是通过Init container生成，而是通过CNI的方式，这就导致IPtables会在Init container之前就创建，如果Init container需要有进出容器的访问，会被iptables劫持并转发给Envoy，但是这个时候Envoy sidecar还没有启动，所以所有的请求都会被拒绝连接。

目前社区有两个解决方案，一是添加annotation traffic.sidecar.istio.io/excludeInboundPorts，但带来的副作用也是很明显的，它会将这些端口从服务网格排除掉，从而无法实现这些端口的全链路加密。由于原因是Sidecar的IPtables规则不会劫持uid是1337的流量，所以另外一种方案是用1337运行Init container，使得访问正常。这里我们推荐采用的是第二种方案，因为相对来说副作用更小一点。

5）控制面性能问题

Mesh的规模不可能无限大，而且单个Mesh也支持不了现有的eBay生产环境规模。

这里我们考虑的解决方案还是Sharding，即将Mesh切片，限制单个Mesh Gateway/Service/Pod的数量。虽然现在Mesh的规模是可用区级别的，但是在一个可用区里面，我们也会需要对Mesh进行切片，比如将可用区1的生产环境Mesh拆分成多个：

Az1-prod-mesh1

Az1-prod-mesh2

Az1-prod-mesh3

将每个网格内部的Sidecar和Service数量控制在一个合理的范围，再通过Namespace过滤限制每个Mesh里面需要服务发现的资源，更彻底的是将不同的Mesh的控制面和数据面也进行隔离。

eBay对Istio的实践和探索其实在2018年底就开始启动了，那时候我们实现了第一版的AccessPoint，并且实现了基于Isito的Feature测试集群方案。接下来，在2019年，我们开始将eBay的测试集群往Istio IngressGateway上搬迁。然而，在项目进展中并不是一帆风顺的，这套方案最终宣告失败。而且，目前我们在应用网关上的实践也是有些磕磕绊绊。这也从侧面说明将一个开源项目在大规模的生产环境上落地是充满挑战的，这些挑战主要包括：

- 性能问题

- 与内部生态环境集成

- 实现应用高可用

- 应用云原生化

- 服务网格流量管理

这些问题并不是Istio社区主要会考虑的问题，因为通常不会有那么大规模的用户场景以及严格的高可用需求，并且目前eBay绝大部分的应用都不是以云原生的方式部署，而这些正是Istio生产化落地需要重点解决的问题。

另一方面，随着近两年Istio以及Kubernetes社区的稳步推进和发展，也促使我们对云原生和服务网格的认知有了进一步地提升。其中，最重要的是对于终态的理解以及技术发展方向的把控。这让我们对云原生的最终形态（End Picture）有了更加清晰的认识。这也是从云计算（OpenStack）到云原生（Kubernetes）的一次变革。在这场变革中，我们走过一些弯路，或者说采用了一些折中的方案，比如胖容器（Fat container）、硬件负载均衡的集成。但是我们越来越认识到，云原生一定会朝着服务网格的方向发展，从硬件负载均衡到软件负载均衡的发展。服务网格会变成基础设施的一部分，应用与服务治理实现彻底解耦，这对于提高应用开发以及服务治理都是一种双赢。

经过最近这一年的探索和实践，我们已经有了一些生产环境的用例，同时在做更多的集成将Istio全面推广到不同技术栈的生产环境，也相信有一天我们能看到我们所预见的终态会变为现实，到时候也不枉我们这一路的跋山涉水。

参考资料:

[1]https://github.com/cncf/toc/blob/main/DEFINITION.md#%E4%B8%AD%E6%96%87%E7%89%88%E6%9C%AC

[2]https://mp.weixin.qq.com/s/v75lCw4RHT7PpM-YXdmQbw

[3]https://mp.weixin.qq.com/s/bZMxLTECOK3mjdgiLbHj-g

[4]https://github.com/istio/istio/pull/29802

[5]https://mp.weixin.qq.com/s/iiOsEHfeTtVx3ewaiXbbrA

[6]https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/

[7]https://www.bookstack.cn/read/istio-1.6-zh/11c65f69298c763a.md

[8]https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet/

       eBay大量优质职位虚席以待

       我们的身边，还缺一个你