作者：如葑

## K8s Ingress 简介

K8s 集群内的网络与外部是隔离的，即在 K8s 集群外部无法直接访问集群内部的服务，如何让将 K8s 集群内部的服务提供给外部用户呢？K8s 社区有三种方案：NodePort、LoadBalancer、Ingress，下图是对这三种方案的对比：

![在这里插入图片描述](https://img-blog.csdnimg.cn/09aa84e33c8741fb9f4bc4dc702ae6dd.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

通过对比可以看到 Ingress 是更适合业务使用的一种方式，可以基于其做更复杂的二次路由分发，这也是目前用户主流的选择。

## K8s Ingress 现状

套用一句流行语：理想是丰满的、现实是骨感的，这句话放在 K8s Ingress 也同样适用，K8s 希望通过 Ingress 来标准化集群入口流量的规则定义，但实际业务落地时需要的功能点要远比 Ingress 提供的多，为了满足业务诉求，各 Ingress Provider 也各出招数，总的来说解法分成两类：使用 annotations 扩展与使用新的 CRD。下面使用图示来说明：

![在这里插入图片描述](https://img-blog.csdnimg.cn/92b0fc6f06fc4a8dbbf2977abc701847.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## K8s Ingress Provider 的发展趋势

Ingress Provider 的百花齐放，站在用户角度各有利弊，好处是用户的可选项很多，而坏处也恰恰是选择太多，我们如何去选择一个适合自身业务的 Ingress Provider 呢？不妨先看看权威 CNCF 的统计数据：

![在这里插入图片描述](https://img-blog.csdnimg.cn/2277a689cc76421c9d544b1885360c43.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

直观的可以看出对于占据 Ingress Provider 首位的 Nginx 是在预期之内的，细看之下虽 Nginx Ingress 仍占据榜首，但其增长有点乏力，甚至有下降的态势；反观 Envoy 已经从 2019 年的第三位攀升至 2020 的第二位，其使用率也从 2019 年的不足 20% 攀升至  2020 年的 37%，几乎成倍增长。

所谓透过现象看本质，为什么 Envoy 的增长这么快呢？总结起来有以下几点：

1、Envoy 诞生在分布式微服务的大背景下，其配置热更新、HTTP3、Wasm 等特性非常贴合目前的使用场景，同时社区治理也非常健康，很多互联网大厂也深度参与其中。

2、Envoy 即可用作 Ingress Provider，也是 ServiceMesh 中 sidecar 的事实领导者，使用同一种技术同时解决南北向与东西向流量调度也是用户选择 Envoy 的一大原因。

3、Envoy 是达到生产级要求的，是经 Lyft 大规模验证过的。

## K8s Ingress Provider 的新选择 - 云原生网关

在虚拟化时期的微服务架构下，业务通常采用流量网关 + 微服务网关的两层架构，流量网关负责南北向流量调度和安全防护，微服务网关负责东西向流量调度和服务治理，而在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关标准，赋予了网关新的使命，使得流量网关 + 微服务网关合二为一成为可能。

![在这里插入图片描述](https://img-blog.csdnimg.cn/6294dd2673f84ff8a1bc9afdaa88f9fe.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

MSE 发布的云原生网关在能力不打折的情况下，将两层网关变为一层，不仅可以节省 50% 的资源成本，还可以降低运维及使用成本。

## 云原生网关的优势

### 性能更强劲

在开始介绍前先抛个问题：Nginx Ingress 的性能与 Nginx 是等价的吗？带着这个疑问我们直接看压测数据对比：

![在这里插入图片描述](https://img-blog.csdnimg.cn/1e923829d4424b8a9c7f610a7ddf1628.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

有没有感觉很意外呢？说实话压测后包括我们自己也是有些意外，压测结论如下：

![在这里插入图片描述](https://img-blog.csdnimg.cn/80c28de9d1b34124a6c1c205316a480f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

我们也查看了 Nginx Ingress 的实现以及社区反馈，由于其大量使用 Lua 脚本从而对性能带来了非常大的影响，K8s Nginx Ingress 社区也有具体的 issue：
https://github.com/kubernetes/ingress-nginx/issues/5658

社区压测 Lua 对 Nginx Ingress 的性能影响截图如下：

![在这里插入图片描述](https://img-blog.csdnimg.cn/3f97f5ba428a41a2923c4d9e5af2772a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

### 功能更丰富

云原生网关作为流量网关与微服务网关的二合一，其功能上同时提供丰富的安全认证与服务治理能力，同时在性能上也做了内核调优以及接下来要发布的硬件加速功能，结合阿里内部两年的大促经验在高可用建设上也进一步做了扩展，整体功能大图如下：

![在这里插入图片描述](https://img-blog.csdnimg.cn/9d51fb9c80ba439b8a6240ab8b8b5b08.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

### 稳定更可靠

经过历年大促的验证，阿里内部积累了一套高可用保障方案，从研发时、运行时、变更时来控制风险提升稳定性，在每个阶段各自有手段去验证其高可用目标，图示说明如下：

![在这里插入图片描述](https://img-blog.csdnimg.cn/3b1cd516ed20463baad74a7ec19c7e4d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## 云原生网关即将上线的重磅功能

### TLS 硬件加速

目前 HTTPS 已经成为公网请求的主要使用方式，全部使用 HTTPS 后由于其要做 TLS 握手，相比HTTP势必性能上会有很大损耗，目前随着 CPU 性能的大幅提升，利用 CPU 的 SIMD 机制可以很好的加速 TLS 的性能，因此我们基于 Intel Ice Lake 处理器推出 TLS 硬件加速功能，通过压测验证启用 TLS 加速后 QPS 可以大幅提升，具体如下图：

![在这里插入图片描述](https://img-blog.csdnimg.cn/86d1ad244e25487b93a37584c5aa9548.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

### 内置 Waf

作为面向南北向的公网网关，使用 Waf 防护异常流量是很常规的需求，而且随着互联网环境变得越来越复杂，用户对防护的诉求是持续增强的，常规做法是将流量先接入 Waf 安全网关，过滤后再将流量转发给流量网关，最后到达微服务网关；云原生网关希望内置 Waf 模块直接对接阿里云的 Waf 云产品，使得用户的请求链接只经过云原生网关就可以同时完成 Waf 防护、流量分发、微服务治理，即提升链路 RT，也降低网关的运维复杂度，图示如下：

![在这里插入图片描述](https://img-blog.csdnimg.cn/5283dc6b087d4fc5a958f39170f08146.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

###  Wasm 插件市场

Wasm 作为目前非常火热的技术之一，其最受追捧的原因在于其可以支持多语言编写 Wasm 程序，且 Wasm 提供了一个很好的沙箱环境来控制程序的执行环境，Istiod 与 Envoy 社区也已经对 Wasm 插件做了基础的支持，云原生网关希望在社区的基础上推出自己的插件市场，提升网关的可扩展性，方便用户自定义网关插件。我们也对现有的 wasm runtime 做了性能对比与测试，这些测试数据也会作为我们的开发依据，图示如下：

![在这里插入图片描述](https://img-blog.csdnimg.cn/0cfd6fb6fc0d4fea9a2438047c2ed242.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## 写在最后

MSE - 云原生网关，旨在为用户提供更可靠的、成本更低、效率更高的，符合 K8s Ingress 标准的企业级网关产品，更多发布详情移步直播间观看：
https://yqh.aliyun.com/live/detail/27794

MSE - 云原生网关提供后付费和包年包月两类付费模式，支持杭州、上海、北京、深圳 、张家口、香港、新加坡、美国（弗吉尼亚）、美国（硅谷）、德国（法兰克福）10 个 region，并会逐步开放其他 region，云原生网关购买链接请点击[此处](https://www.aliyun.com/product/aliware/mse?spm=5176.19720258.J_2937333540.8.652f2c4ag5onyh&scm=20140722.B_8470.P_5034.MO_406-ST_4277-ID_26497-CID_26497-V_1)。

也可钉钉搜索群号 34754806 加入用户群进行交流、答疑。

ITPub博客

K8s Ingress Provider 为什么选择 MSE 云原生网关？

最新文章