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


数据中心流量管理现状

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

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

规模化带来的挑战


  • 异构应用
    • 云业务,大数据,搜索服务
    • 多种应用协议
    • 灰度发布

  • 日益增长的安全需求:全链路TLS

  • 可见性需求
    • 访问日志
    • Tracing

  • 数据中心规模:3主数据中心,20边缘数据中心,100+ Kubernetes集群

  • 规模化运营Kubernetes集群
    • 总计100,000物理节点
    • 单集群物理机节点规模高达 5,000

  • 业务服务全面容器化,单集群
    • Pod实例可达 100,000
    • 发布服务 5,000-10000

  • 单集群多环境支持
    • 功能测试、集成测试、压力测试共用单集群
    • 不同环境需要彼此隔离


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

基于IPVS的L4 Service控制器:
  • 四层网关调度
  • VIP地址分配
  • 不同应用配置独立网关VIP
  • 配置IPIP Tunnel模式的IPVS规则
  • 基于BGP VIP子网路由宣告
  • 配置IngressGateway Tunnel接口
  • 支持Direct Server Return(DSR)


Istio作为应用网关控制器:
  • 管理应用L7规则
  • 自动化生成eBay证书
  • 管理和注入sidecar
  • 网格内部请求mTLS


基于Istio的应用网关实践

Istio单集群多环境部署

3.png

  • 非生产环境:Feature/LnP/Staging/StagingPCI
  • 生产环境:Pre-Prod/Prod/PCI(Payment Card Industry)
  • 单个Kubernetes集群部署多套Istiod,IngressGateway和L4集群
  • Cheery-pick 社区Pilot scoped namespaces PR
  • 不同环境控制面数据面隔离


Istio集群证书管理

网关证书

4.png

  • 集成eBay CA,secret保存证书Ref
  • Istiod集成cert agent
  • SDS通过cert agent GRPC获取证书和key推送到IngressGateway


集群证书
5.png

  • 利用自签根证书为每个Istio集群签发中间证书
  • 因安全方面的需求,需保证中间证书更新期间新旧证书同时可用


单网关全链路加密模式

6.png

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

  • 应用场景
    • Feature/LnP/Staging Secure测试环境
    • 全链路加密(E2E TLS)
    • 可用性要求不高

  • 同时支持API Gateway和Mesh
    • 应用配置独立Gateway VIP
    • External访问API Gateway为Simple TLS
    • Mesh内部访问为mTLS
    • 不同环境配置专有L4/L7集群

  • 软件防火墙集成(Sentinel)
    • 默认阻止所有访问
    • 保护Ingress/Egress流量
    • 保护进入Pod的流量

  • 模拟生产环境


多网关多集群部署

7.png


  • Kubernetes集群联邦
    • 集群联邦APIServer作为用户访问kubernetes集群入口
    • 所有Kubernetes集群注册至集群联邦

  • 可用区
    • 数据中心中具有独立供电制冷设备的故障域
    • 同一可用区有较小网络延迟
    • 同一可用区部署了多个Kubernetes集群

  • 多集群部署
    • 同一可用区设定一个网关集群
    • 网关集群中部署Istio Primary
    • 同一可用区的其他集群中部署Istio Remote
    • 所有集群采用相同RootCA签发的中间证书

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


Istio Primary-Remote压力测试

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

  • Gateway XDS
  • Sidecar EDS


8.png

9.png

结论:

  • 单个Istiod 32 CPU/10G内存可以支持:
    • 32个Ingress Pods
    • 2000个sidecar

  • 收敛时间小于5秒能够支持的规模:
    • 2000 Kubernetes Service(5个端口)
    • 其中同时有100个Endpoint地址发生变更

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

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


应用高可用接入方案-多集群1层

这里的一层是指 VIP的数量:
10.png

流量管理:
  • GTM(智能DNS)配置多个VIP,负责健康检查
  • GTM(智能DNS)配置不同数据中心流量权重
  • L4 IPVS 为流量入口
  • 没有跨数据中心流量
  • 应用数据面为网关Envoy到Sidecar Envoy


故障容灾:
  • GTM监控VIP状态,自动mark down故障VIP
  • Istio网关宕机会影响客户端DNS缓存
  • 单集群应用后端Pod整体宕机会造成数据面影响


应用高可用接入方案-多集群2层

方案一:
11.png

流量管理:
  • L4 IPVS为流量入口
  • 本集群流量从Gateway直连后端服务器
  • 跨集群流量经过远端IPVS VIP转发
  • ServiceEntry同时选择Pod和VIP
  • 定义基于Locality的流量转发规则
  • 同一数据中心流量权重99%,跨数据中心1%


故障容灾:
  • 单集群应用后端Pod整体宕机不会造成数据面影响
  • Istio网关宕机,智能DNS停止返回该VIP


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

方案二:
12.png

流量管理:
  • 两层VIP,适配现有模型
  • ServiceEntry实现跨数据中心流量
  • 利用Weighted HTTPRouteDestination,本数据中心98%,远端各1%
  • 所有流量都经过Istio


故障容灾:
  • 单集群应用后端Pod整体宕机不会造成数据面影响
  • Istio网关宕机会受客户端DNS缓存影响


应用高可用接入方案-数据面

13.png

  • 用户请求通过L4(IPVS)转发到IngressGateway
  • TLS PAASTHROUGH将请求路由至weighted cluster
  • Weighted cluster的Endpoints为本地和远端的网关地址
  • 请求转发至本集群:TLS握手发生在client和gateway pod
  • 请求需经过2次TLS
  • IngressGateway将请求响应通过Direct Server Return返回客户端


14.png

  • 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

15.png

基于Istio网关的feature测试开发环境

16.png

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

17.png

  • 不同网格同时部署应用以及日志服务器
  • 同时注入sidecar到应用端以及日志系统服务端
  • 网格内部mTLS实现日志脱敏
  • 南北流量转成东西流量


全链路加密存储服务-NuObject

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

18.png

压力测试环境

19.png

高吞吐压力测试:
  • Gateway达到30Gb/s
  • Backend BM达到40Gb/s
  • Jumbo frame,9000 bytes MTU
  • Sidecar内存增加到3GB
  • Envoy worker增加到20


高安全性存储服务:
  • 注入Sidecar到后端服务
  • 网关配置Simple TLS
  • 网格内部mTLS
  • 集成软件防火墙


Managed Stack全面集成Mesh

20.png

Managed Stack是使用eBay框架的应用,包括Java,Java Web,Batch以及NodeJS应用。
  • 生产环境应用数量超过4000
  • 个别应用部署后端服务器超过3000
  • 生产环境Pod总数超180000
  • TLS/限速/授权与框架解耦
  • Fat container全面转向Native以及Mesh


Istio社区未解决的问题


  • 端口协议冲突
    • 不支持privilege端口<1024
    • 同一网关端口不能同时支持TCP/HTTPS
    • 解决方案:分配不通gateway service target port

  • 单点从外部访问mTLS Mesh机器
    • 解决方案:利用Subset Load Balancing,EnvoyFilter从URL解析Pod IP并转发

  • Envoy readiness probe
    • 无法确保数据面通、证书配置好
    • 解决方案:Readiness gate/Envoy active healthcheck

  • Init Container inbound/outbound被block,社区issue
    • 解决方案:添加anntation traffic.sidecar.istio.io/excludeInboundPorts/用1337运行Init Container

  • 控制面性能问题
    • 解决方案:sharding,将mesh切片,限制单个Mesh Gateway/Service/Pod数量


未来展望

  • 全面替换硬件负载均衡设备
  • 南北流量接入软件应用网关
  • 构建基于Mesh流量管理
  • 全站应用全面转向Cloud Native/Service Mesh
  • 数据中心内部南北流量转成东西流量
  • 数据平面加速Cilium


原文链接:https://mp.weixin.qq.com/s/IA5gQFzRQDMnDsXl_5tg0w

0 个评论

要回复文章请先登录注册