专栏首页云计算与大数据eBay基于Istio的应用网关的探索和实践

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

推荐阅读

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

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

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

本文分享自微信公众号 - 黑洞日志(heidcloud)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-08-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 我为啥不看好ServiceMesh

    今年,ServiceMesh(服务网格)概念在社区里头非常火,有人提出2018年是ServiceMesh年,还有人提出ServiceMesh是下一代的微服务架构...

    程序猿DD
  • 下一代的微服务架构基础是ServiceMesh?

    今年,ServiceMesh(服务网格) 概念在社区里头非常火,有人提出 2018 年是 ServiceMesh 年,还有人提出 ServiceMesh 是下一...

    纯洁的微笑
  • 微服务 | 我为啥不看好 ServiceMesh

    1. 前言2. 微服务架构的核心技术问题3. 三种服务发现模式4. 三种服务发现模式的比较5. 服务网格ServiceMesh6. 我的建议7. 结论8. 附录

    芋道源码
  • Hango 开源解读:云原生网关实践,为何要选择 Envoy ?

    Hango 是由网易公司开源的一个基于 Envoy 构建的高性能、可扩展、功能丰富的云原生 API 网关。

    CNCF
  • Dapr 将引领云原生时代应用和中间件的未来!!

    Dapr 是由微软发起的云原生开源新项目,在今年 2 月份刚刚发布了 v1.0 正式版本。虽然推出至今不过一年半时间,但 Dapr 发展势头十分迅猛,目前已经在...

    架构师修行之路
  • 中秋福利 | 15个系列100+篇超实用云原生原创干货合集(内含腾讯彩蛋)

    还有2天,就要迎来中秋小长假啦 这个中秋节你打算怎么过? ? 小云选择把这篇干货全部拿下! 云原生技术干货文章合集,来咯~ ? 2021 年,要说咱们技术圈...

    腾讯云原生
  • 终于有人把 Elasticsearch 原理讲透了!

    搜索是现代软件必备的一项基础功能,而 Elasticsearch 就是一款功能强大的开源分布式搜索与数据分析引擎。

    Spark学习技巧
  • Istio 知多少 | 下一代微服务的守护者

    在写完eShopOnContainers 知多少[12]:Envoy gateways后,就一直想进一步探索Service Mesh,最近刚在极客时间上学完《S...

    圣杰
  • ServiceMesh入门的起点:构建一个微服务网关

    本文是在看了国外 Solo 公司 CTO 的博客之后整理的,本来是想按原文翻译,但是考虑到我自己在公司实践的思路,还是想把他的思路和我自己的思路做一些结合。所以...

    黑光技术
  • Service Mesh · Istio · 以实践入门

    本文是笔者在学习官方文档、相关博客文章和实践过程中,整理了一些知识概念和自己的思考,主要在探索 lstio 的实际应用场景, Sidecar 原理, Servi...

    heidsoft
  • 云原生软件开发与运维 · 大咖微访谈,来咯~

    云原生软件开发与运维 智能化软件开发微访谈 背景介绍 包含容器化、微服务、服务网格等技术在内的云原生已经成为新的技术浪潮,深刻地改变着软件开发、维护和运行的...

    腾讯云原生
  • Netflix、IBM、阿里等世界级FaaS、K8s、Istio核心架构案例都在这里

    纯洁的微笑
  • Istio与Kubernetes叠加后的快感从何而来?

    本文选自《云原生服务网格Istio》一书,带你从原理、实践、架构与源码多角度全解Istio,直击Istio的每一个细节。

    博文视点Broadview
  • 2018全球机器学习技术大会40位大神即将开讲!

    ​​​"Can Machine Think?" 1936年阿兰· 图灵提出「图灵机」以及机器具备「思维」的可能性。历经82年,以机器学习为代表的人工智能经过近几...

    活动家
  • 腾讯云-Istio案例分析: 端口命名不满足约束导致流量异常

    istio 支持多平台,不过 Istio 和 k8s 的兼容性是最优的,不管是设计理念,核心团队还是社区, 都有一脉相承的意思。但 istio 和 k8s 的适...

    朱瑞卿
  • 长居容器圈话题榜C位,明星项目的【高级感】谁来解读?

    当印务老师通知我去拿《深入浅出Prometheus》样书的时候,我兴奋坏了,从送印到拿样书,才三天,真是个奇迹!

    博文视点Broadview
  • 一盏茶的时间初探网格服务架构Istio

    微服务架构2.0 Service Mesh架构框架方面,业内陆续开源了不少优秀框架,主流两个:Service Mesh产品Istio 和 AWS App Mes...

    孙玄@奈学教育
  • 查询亿级数据毫秒级返回!Elasticsearch 是如何做到的?

    前两天看到曹政大佬的文章,说他上个世纪末在广州做 PHP 程序员的时候,接到一个私活儿。

    Java团长
  • 在k3d上快速安装Istio,助你在本地灵活使用K8S!

    在之前的文章里我们介绍了如何使用k3d创建k3s集群,并且了解到k3d能为我们搭建本地k3s环境提供非常大的便利。本文将探索k3d的另一种使用方式,将Istio...

    k3s中文社区

扫码关注云+社区

领取腾讯云代金券