01

K8s Ingress 简介

Cloud Native

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

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

02

K8s Ingress 现状

Cloud Native

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

03

K8s Ingress Provider 的发展趋势

Cloud Native

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

直观的可以看出对于占据 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 大规模验证过的。

04

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

Cloud Native

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

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

云原生网关的优势

Cloud Native

1 性能更强劲

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

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

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

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

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

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

Cloud Native

1 TLS 硬件加速

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

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

 Wasm 插件市场

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

MSE - 云原生网关提供后付费和包年包月两类付费模式，支持杭州、上海、北京、深圳 、张家口、香港、新加坡、美国（弗吉尼亚）、美国（硅谷）、德国（法兰克福）10 个 region，并会逐步开放其他 region，云原生网关购买链接请联系站内客服。