eBay基于Istio的应用网关的探索和实践
7月17日，在Cloud Native Days China云原生多云多集群专场，eBay软件工程师陈佑雄发表了《eBay基于Istio的应用网关的探索和实践》主题演讲，分享了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
基于Istio的应用网关实践
Istio单集群多环境部署
- 非生产环境：Feature/LnP/Staging/StagingPCI
- 生产环境：Pre-Prod/Prod/PCI(Payment Card Industry)
- 单个k8s集群部署多套Istiod，IngressGateway和L4集群
- Cheery-pick 社区Pilot scoped namespaces PR
- 不同环境控制面数据面隔离
Istio集群证书管理
网关证书
- 集成eBay CA，secret保存证书Ref
- Istiod集成cert agent
- SDS通过cert agent GRPC获取证书和key推送到IngressGateway
集群证书
- 利用自签根证书为每个Istio集群签发中间证书
- 因安全方面的需求，需保证中间证书更新期间新旧证书同时可用
单网关全链路加密模式
单网关全链路加密模式的架构图
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 Primary-Remote压力测试
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
应用高可用接入方案-多集群1层
这里的一层是指 VIP的数量：
流量管理
- GTM（智能DNS）配置多个VIP，负责健康检查
- GTM（智能DNS）配置不同数据中心流量权重
- L4 IPVS 为流量入口
- 没有跨数据中心流量
- 应用数据面为网关Envoy到Sidecar Envoy
故障容灾
- GTM监控VIP状态，自动mark down故障VIP
- Istio 网关宕机会影响客户端DNS缓存
- 单集群应用后端Pod整体宕机会造成数据面影响
应用高可用接入方案-多集群2层
方案一：
流量管理
- 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缓存影响
应用高可用接入方案-数据面
- 用户请求通过L4(IPVS)转发到IngressGateway
- TLS PAASTHROUGH将请求路由至weighted cluster
- Weighted cluster的Endpoints为本地和远端的网关地址
- 请求转发至本集群:TLS握手发生在client和gateway pod
- 请求需经过2次TLS
- IngressGateway将请求响应通过Direct Server Return返回客户端
- TLS握手发生在local gateway和gateway pod
- Ingress Gateway Pod需配置eBay Root CA
- 请求需经过2次TLS
- 正常接收1%流量，本集群后端服务整体宕机接收100%流量
适配服务间调用（L7转发规则）
- 99%请求走Mesh东西向流量
- 1%请求经Gateway跨Mesh
- VirtualService配置weighted Destination
统一流量模型 - AccessPoint
基于Istio网关的feature测试开发环境
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的稳定性和可用性。
基于Istio网关的集中日志系统CAL
CAL日志系统集成Mesh
- 不同网格同时部署应用以及日志服务器
- 同时注入sidecar到应用端以及日志系统服务端
- 网格内部mTLS实现日志脱敏
- 南北流量转成东西流量
全链路加密存储服务-NuObject
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全面集成Mesh
Managed Stack是使用eBay框架的应用，包括Java, Java Web, Batch以及NodeJS应用
- 生产环境应用数量超过4000
- 个别应用部署后端服务器超过3000
- 生产环境Pod总数超180000
- TLS/限速/授权与框架解耦
- Fat container全面转向Native以及Mesh
Istio社区未解决的问题
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
推荐阅读