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

2021-08-26 17:03:35 浏览数 (1)

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

推荐阅读

如何利用云原生技术构建现代化应用

浅谈5 种典型的云原生架构反模式

Serverless 时代下大规模微服务应用运维的最佳实践

tcp/ip SSL证书 https 腾讯云测试服务 kubernetes

0 人点赞