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

演讲主要包含四部分的内容：

1）数据中心流量管理现状

2）基于Istio的应用网关实践

• Istio部署模式

• 应用高可用接入架构

• 流量统一管理模型

• 案例分享

3）Istio社区未解决的问题

4）未来展望

我们是有三个数据中心，每个数据中心有多个可用区，每个可用区有多个Kubernetes集群。现在流量接入数据中心主要是通过硬件负载均衡设备，也就是图中Web层的LB和APP层的LB，这些其实都是硬件负载均衡的设备对。目前，三个数据中心大概有2000多对这样的硬件负载均衡设备。我们内部应用相互间的调用主要是以南北向的流量为主，Web层会做流量的分发，将99%的流量转发到本地数据中心，1%的流量转发到远端的数据中心。数据中心的特征因我们是微服务的架构，所以它的VIP数量很多，同时会有公网和内网的VIP,并且在VIP上配置有少量L7规则，也就是应用间互相调用的防护规则。

我们期望实现的目标是可以基于Istio将这2000多对硬件负载均衡设备对全部替换掉。这种两层的架构其实我们已经用了很多年了，它最大的好处是假设某一个服务的应用在某一个数据中心全部宕机，这种情况下流量会自动切换到远端的数据中心，因为这边的健康检查会将这条链路断掉，如此客户端就不会因为缓存了这个VIP地址，造成客户端数据面的影响。因此在应用部署时，在每一个数据中心是有容量冗余的，就是我们可以端掉一个数据中心，其他两个数据中心的容量可足够支撑这个服务。

1）异构应用

• 云业务，大数据，搜索服务

• 多种应用协议

• 灰度发布

2）日益增长的安全需求：全链路TLS

3）可见性需求

• 访问日志

• Tracing

4）数据中心规模：3主数据中心，20边缘数据中心，100+ Kubernetes集群

5）规模化运营Kubernetes集群

• 总计100,000物理节点

• 单集群物理机节点规模高达 5,000

6）业务服务全面容器化，单集群

• Pod实例可达 100,000

• 发布服务 5,000-10000

7）单集群多环境支持

• 功能测试、集成测试、压力测试共用单集群

• 不同环境需要彼此隔离

目前我们采用的是基于IPVS和Istio的网络云原生架构：

基于IPVS的L4 Service控制器：

• 四层网关调度

• VIP地址分配

• 不同应用配置独立网关VIP

• 配置IPIP Tunnel模式的IPVS规则

• 基于BGP VIP子网路由宣告

• 配置IngressGateway Tunnel接口

• 支持Direct Server Return (DSR)

Istio作为应用网关控制器：

• 管理应用L7规则

• 自动化生成eBay证书

• 管理和注入sidecar

• 网格内部请求mTLS

网关证书

集群证书

单网关全链路加密模式的架构图

1）应用场景

• Feature/LnP/Staging Secure测试环境

• 全链路加密(E2E TLS)

• 可用性要求不高

2）同时支持API Gateway和Mesh

• 应用配置独立Gateway VIP

• External访问API Gateway为Simple TLS

• Mesh内部访问为mTLS

• 不同环境配置专有L4/L7集群

3）软件防火墙集成(Sentinel)

• 默认阻止所有访问

• 保护Ingress/Egress流量

• 保护进入Pod的流量

4）模拟生产环境

1）Kubernetes集群联邦

• 集群联邦APIServer作为用户访问kubernetes集群入口

• 所有Kubernetes集群注册至集群联邦

2）可用区

• 数据中心中具有独立供电制冷设备的故障域

• 同一可用区有较小网络延迟

• 同一可用区部署了多个Kubernetes集群

3）多集群部署

• 同一可用区设定一个网关集群

• 网关集群中部署Istio Primary

• 同一可用区的其他集群中部署Istio Remote

• 所有集群采用相同RootCA签发的中间证书

4）东西南北流量统一管控

• 同一可用区的服务调用基于Sidecar

• 跨可用区的服务调用基于Istio Gateway

Istio控制面主要考虑两个配置推送到mesh的收敛时间(convergence time)：

• Gateway XDS

• Sidecar EDS

结论：

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

• 32个Ingress Pods

• 2000个sidecar

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

• 2000 k8s service(5个端口)

• 其中同时有100个Endpoint地址发生变更

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

Istio Number = gateway number / 32 + sidecar number / 2000

这里的一层是指 VIP的数量：

流量管理

• GTM（智能DNS）配置多个VIP，负责健康检查

• GTM（智能DNS）配置不同数据中心流量权重

• L4 IPVS 为流量入口

• 没有跨数据中心流量

• 应用数据面为网关Envoy到Sidecar Envoy

故障容灾

• GTM监控VIP状态，自动mark down故障VIP

• Istio 网关宕机会影响客户端DNS缓存

• 单集群应用后端Pod整体宕机会造成数据面影响

方案一：

流量管理

• L4 IPVS 为流量入口

• 本集群流量从Gateway直连后端服务器

• 跨集群流量经过远端IPVS VIP转发

• ServiceEntry同时选择Pod和VIP

• 定义基于Locality的流量转发规则

• 同一数据中心流量权重99%，跨数据中心1%

故障容灾

• 单集群应用后端Pod整体宕机不会造成数据面影响

• Istio网关宕机，智能DNS停止返回该VIP

因此我们又提出了另外一种两层的架构，这种两层的架构是我们现在比较倾向于选择的架构，它虽然也有两层VIP，但实际上它只有一个IP，只是我们开了两个端口。

方案二：

流量管理

• 两层VIP，适配现有模型

• ServiceEntry实现跨数据中心流量

• 利用Weighted HTTPRouteDestination,本数据中心98%，远端各1%

• 所有流量都经过Istio

故障容灾

• 单集群应用后端Pod整体宕机不会造成数据面影响

• Istio 网关宕机会受客户端DNS缓存影响

• 99%请求走Mesh东西向流量
• 1%请求经Gateway跨Mesh
• VirtualService配置weighted Destination

Feature测试环境规模：

• 单个测试环境包含一个Pod和若干个CNAME

• Feature测试环境共享一个网关VIP

• 4000+个Pod/VS/GW/Service以及5k个CNAME

• 网关配置Wildcard证书

VirtualService指定转发规则

• Host: foo.example.com

• Destination：foo-service

Lesson Learn:

• Istio 1.3，1.7k个Pod, Pilot OOM

• 集群整体discover，配置过多

• Listener缺失，CDS推送太慢

• Gateway merge耗时，3k GW耗时近3k秒

因此这套方案后来我们没有使用，用另外一套方案去替换了。但是也有一个很大的教训，就是说一个merge的scalability不可能无限大，因此我们一是要做基于环境的隔离，二是要对merge的规模进行控制，这样才能保证整个merge的稳定性和可用性。

CAL日志系统集成Mesh

NuObject是我们目前做的一个新项目，用来替换Swift, 前期我们也做了很多压力测试，下图为压力测试环境与结果：

压力测试环境

高吞吐压力测试

• Gateway达到30Gb/s

• Backend BM达到40Gb/s

• Jumbo frame，9000 bytes MTU

• Sidecar内存增加到3GB

• Envoy worker增加到20

高安全性存储服务

• 注入Sidecar到后端服务

• 网关配置Simple TLS

• 网格内部mTLS

• 集成软件防火墙

Managed Stack是使用eBay框架的应用，包括Java, Java Web, Batch以及NodeJS应用

• 生产环境应用数量超过4000

• 个别应用部署后端服务器超过3000

• 生产环境Pod总数超180000

• TLS/限速/授权与框架解耦

• Fat container全面转向Native以及Mesh

1）端口协议冲突

• 不支持privilege端口<1024

• 同一网关端口不能同时支持TCP/HTTPS

• 解决方案：分配不通gateway service target port

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

• 解决方案：利用Subset Load Balancing，EnvoyFilter从URL解析Pod IP并转发

3）Envoy readiness probe

• 无法确保数据面通、证书配置好

• 解决方案：Readiness gate/Envoy active healthcheck

4）Init Container inbound/outbound被block，社区issue

• 解决方案：添加anntation traffic.sidecar.istio.io/excludeInboundPorts/用1337运行Init Container

5）控制面性能问题

• 解决方案：sharding，将mesh切片，限制单个mesh Gateway/Service/Pod数量

• 全面替换硬件负载均衡设备
  

• 南北流量接入软件应用网关

• 构建基于Mesh流量管理

• 全站应用全面转向Cloud Native/Service Mesh

• 数据中心内部南北流量转成东西流量

• 数据平面加速Cilium

推荐阅读

您有一份Kubernetes 1.22 指南待查收~

科普 | 从零开始入门容器，看这篇就够了！

【Ask云原生·VOL02】容器到底能“装”啥？