K8s 网关选型初判:Nginx 还是 Envoy?
作者:张添翼(澄潭)
为了避免混淆,我们先对一些关键定义做一些厘清:
-
传统网关:未作容器化改造,未启用 K8s,通过流量网关与业务网关两层网关来构建,流量网关提供全局性的、与后端业务无关的策略配置,例如 Tengine 就是典型的流量网关;业务网关提供独立业务域级别的、与后端业务紧耦合策略配置,随着应用架构模式从单体演进到现在的分布式微服务,业务网关也有了新的叫法 - 微服务网关。
-
K8s 网关:即云原生网关,也被称为下一代网关,Ingress 成为 K8s 生态的网关标准,促使流量网关和业务网关,合二为一。基于 Ingress 规范的实现主要分为基于 Nginx 和基于 Envoy 两大阵营,基于 Nginx 的 Nginx Ingress Controller 是目前大多数 K8s 集群的选择,基于 Envoy 的实现作为后起之秀,大有赶超之势。
-
MSE 云原生网关:是基于 Envoy,做了深度优化的云上服务。
本文将从性能和成本、可靠性、安全性 3 方面,对两大开源实现进行比对,希望对正在做 K8s 网关选型的企业有所借鉴。
性能和成本
MSE 云原生网关的吞吐性能几乎是 Nginx Ingress Controller 的一倍,尤其是传输小文本时性能优势会更明显,如下图所示,网关 CPU 使用率达到 30% 时的吞吐对比:
网关规格:16 核 32 G * 4 节点
ECS 型号:ecs.c7.8xlarge
当 CPU 负载升高时,吞吐差距会更加明显,下图是 CPU 使用率达到 70% 时的情况:
高负载下 Nginx Ingress Controller 吞吐下降原因是出现了 pod 重启,详情见下一节“可靠性”中的分析。
随着网络安全愈加受重视,现在互联网上已经普遍使用 HTTPS 进行传输加密,在网关侧,用于实现 HTTPS 的 TLS 非对称加密算法是占用 CPU 资源的大头。针对此场景,MSE 云原生网关使用了 CPU SIMD 技术实现了 TLS 加解密算法的硬件加速:
从上图压测数据可以看出使用 TLS 硬件加速后,相比普通 HTTPS 请求 TLS 握手时延降低一倍,极限 QPS 提升 80%以上。
基于以上数据,使用 MSE 云原生网关,只需一半的资源,就能达到 Nginx Ingress Controller 的吞吐,在做过硬件加速优化的 HTTPS 场景下,吞吐还能进一步提升。
可靠性
前文提到高负载下,Nginx Ingress Controller 会出现 pod 重启导致吞吐下降,导致 pod 重启的原因主要有 2 点:
-
存活健康检查(livenessProbe)在高负载时容易超时失败,社区在 0.34 版本通过减少冗余检测进行了一定的优化,但问题仍然存在。
-
在开启了 prometheus 采集监控指标的情况下,高负载时会出现 OOM,导致容器被 kill,详细原因见相关 issue:https://github.com/kubernetes/ingress-nginx/pull/8397
这两个问题,本质上皆是由于 Nginx Ingress Controller 的部署架构不合理导致。其控制面(Go 实现的 Controller)和数据面(Nginx)进程混跑在一个容器内,高负载下,数据面进程和控制面进程出现了 CPU 抢占。其中控制面进程负责了健康检查和监控指标采集,因为没有足够的 CPU 导致请求积压引起 OOM 以及健康检查超时。
这种情况是极危险的,会在高负载下引发网关的雪崩效应,对业务造成严重影响。MSE 云原生网关使用了数据面和控制面隔离的架构,在架构上具备可靠性优势:
从上图可以看到,MSE 云原生网关并不部署在用户的 K8s 集群中,而是纯托管的模式,这种模式在可靠性上还有更多优势:
- 不会与业务容器混跑在一个 ECS 节点上
- 网关的多个实例不会混跑在一个 ECS 节点上
- 提供网关可用性的 SLA 保障
如果使用 Nginx Ingress Controller 要实现高可靠部署,一般需要独占 ECS 节点,同时还需要部署多个 ECS 节点,来避免单点故障,这种情况下资源成本会直线上升。此外,Nginx Ingress Controller 因为部署在用户集群中,也无法提供网关可用性的 SLA 保障。
安全性
Nginx Ingress Controller 的不同版本都还存在着一些 CVE 漏洞隐患,具体影响版本见下表:
从 Nginx Ingress Controller 迁移到 MSE 云原生网关后,将一次性修复所有 CVE 漏洞隐患;并且,MSE 云原生网关提供了平滑升级方案,一旦出现新的安全漏洞,可以快速对网关版本进行升级,同时确保升级过程对业务影响最小化。
此外,MSE 云原生网关内置了阿里云 Web 应用防火墙(WAF),相比传统 WAF 用户请求链路更短、RT 更低,且相比Nginx Ingress Controller 可以做到细粒度路由级防护,使用成本是目前阿里云 Web 应用防火墙架构的 2/3。
MSE 云原生网关
阿里云容器服务应用市场已经上架 MSE 云原生网关,可用于替代默认安装的网关组件 Nginx Ingress Controller。
MSE 云原生网关在阿里集团内部作为网关中间件已经大规模使用,其强劲的性能和可靠的稳定性已被多年双十一流量所验证。
在 K8s 容器服务场景下,对比默认安装的 Nginx Ingress Controller,主要有以下优势:
- 更强劲的性能,更合理的架构,可以将网关资源成本降低至少 50%
- 更好的可靠性和 SLA 保障,纯托管免运维,背靠阿里云技术团队提供支持
- 更优的安全性保障,一次性解决现存 CVE 安全漏洞隐患,且内置 WAF 防护功能
同时在路由策略、灰度治理、可观测等方面提供了更丰富的功能,并且支持使用多种语言开发自定义的扩展插件,详细对比请参考:https://help.aliyun.com/document_detail/424833.html
平滑迁移方案
部署 MSE 云原生网关并不直接影响原有网关流量,通过 DNS 权重配置可以实现业务流量的平滑迁移,对后端业务完全无感知,核心的流量迁移过程如下图所示:
完整步骤如下:
-
步骤一:在容器服务的应用市场中找到 mse-ingress-controller,并安装到目标 ACK 集群
-
步骤二:在 K8s 中配置 MseIngressConfig (配置指引),自动创建指定规格的 MSE 云原生网关
-
步骤三:从 Ingress 的 address 字段中获取 MSE 云原生网关的 IP,本地绑定 host,将业务域名解析到该 IP,完成业务测试
-
步骤四:修改业务域名的 DNS 权重配置,添加云原生网关 IP,并逐步调高权重,进行流量灰度
-
步骤五:完成灰度后,将业务域名原先的 IP 从 DNS 配置中移除,实现全部流量切到云原生网关
点击此处,了解更多云原生网关产品信息~
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
ZooKeeper 在阿里巴巴的服务形态演进
作者:草谷 Apache ZooKeeper 在阿里巴巴经历了开源自用、深度优化、反哺社区、开发企业版服务云上客户的演进过程,为了厘清本文脉络,我们对演进过程中提到的关键名词做以下定义。 Apache ZooKeeper:提供分布式协调服务如分布式锁、分布式队列等,还可用于注册配置中心的能力。 TaoKeepeer:基于 ZooKeeper 做了深度改造,于2008年服务于淘宝。 MSE:阿里云的一个面向业界主流开源微服务生态的一站式微服务平台。 ZooKeeper 企业服务:MSE 的子产品,提供开源增强的云上服务,分为基础版和专业版两种。 ZooKeeper 在阿里巴巴的服务形态演进历程 早在 2008 年,阿里巴巴基于 ZooKeeper 的开源实现和淘宝的电商业务,设计 Taokeeper 这款分布式协调软件,彼时恰逢淘宝启动服务化改造,那时候,也诞生了各类分布式中间件,例如 HSF/ConfigServer/VIPServer 等。 10 年后的 2019 年,阿里巴巴实施全站上云战役,所有的产品都需要升级到公有云架构,MSE 就是在那个时候诞生的,上线后便兼容了主流的 Zo...
- 下一篇
开源中的“胖虎效应”
今天我们来聊一个非常有意思的现象:“胖虎效应”。 胖虎是经典动漫《哆啦A梦》中的“反派角色”,常年对主角大雄实施校园霸凌,一副猪皮恶霸的形象深入人心,是很多小朋友厌恶的对象。然而在一些《哆啦A梦》剧场版的作品中,胖虎偶然间做了一件好事,就会给人一种“这小子其实也不是那么坏”的感觉,使得观众对其好感直线上升。 反之,一个平日里一直做好事的正人君子,突然被曝出做了一件坏事,那么这个人在人们心中“坏”的形象则会倍增,甚至会把他此前做过的所有好事全盘否定,给人一种“这个人一直以来的好都是装出来的”感觉。也就是俗话说的,“伪君子比真小人更可怕”。 “胖虎效应”最初出自漫画《银魂》的一句恶搞台词,虽然该定律并没有什么靠谱的理论依据,但通过胖虎这个简单的例子,直观地反映了一种常见心理现象。这种现象映射到现实生活中,我们能看到很多例子与之相符,其中开源领域尤为契合。 开源中的“胖虎效应” “胖虎效应”在开源领域最经典的例子就是微软的转变。 众所周知,微软曾是开源世界最大的敌人,这个专有软件巨头在 20 年前公然宣称以 Linux 为代表的开源软件是业界毒瘤,并通过媒体舆论、法律威胁等手段对开源社区进行...
相关文章
文章评论
共有0条评论来说两句吧...