开发者学堂课程【K8s Ingress 选择 MSE 云原生网关解析：K8s Ingress 为什么选择 MSE 云原生网关？】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/965/detail/14886
K8s Ingress 为什么选择 MSE 云原生网关？
内容介绍：
一、K8s Ingress 简介
二、K8s Ingress 现状
三、K8s Ingress Provider 的发展趋势
四、K8s Ingress Provider 的新选择-云原生网关
五、云原生网关的优势
一、K8s Ingress 简介
1. 背景
K8s 集群内的网络与外部是隔离的，即在 K8s 集群外部无法直接访问集群内服务。
2. 分类
（1）Node Port
Node Port 是在集群内部的 node 上开放一个端口，外部用户能够访问端口，同时内部服务可以从端口上接受外部流量。
方案的缺点为每个端口只能挂载一个 Service ,端口范围限制为30000-32767。
（2）LoadBalancer
LoadBalancer 是一个云厂商提供公网的SOB ,用于接受外部的请求，外部请求通过 LoadBalancer 利用Node Port转发给集群内部的 node 。
LoadBalancer 的缺点与 Node Port 本质上一致：
第一：一个LoadBalancer对应一个 Service ，无法与多 Service 复用。第二个缺点是 LoadBalancer 只能纯流量转发，无法基于规则路由规则二次分发流量。
（3）Ingress
①注意
K8s Ingress只是K8s 的一种资源，不能提供路由分发能力。路由分发能力由 K8s Ingress 的具体实现方 K8s Ingress Provider 来完成。K8s Ingress 只是定义规则，K8s Ingress Provider 负责实现响应规则。注意区分 K8s Ingress 与 K8s Ingress Provider 。
②介绍
K8s Ingress 的流量首先要从外部的LoadBalancer 接受四层流量，流量接受到后会转发集群内部的 Ingress Provider ，Ingress Provider七层流量二次分发流量，并且可以挂载后端的多个 Service ，因此可以支持多个 Service 的共享。
二、K8s Ingress是目前三类方案中最多用户。因为可以基于规则进行路由二次分发，扮演路由器或者集群入口的角色。还可以实现多个 Service 共享。
三、K8s Ingress 现状
从上图可知，K8s Ingress 标准的定义中提供路由的能力较弱，无法满足实际业务诉求，例如常用的 redirect、rewrite 等。标准K8s Ingress无法解决。解决 K8s Ingress路由规则能力弱的方法为 Ingress Provider 各自扩展。
Ingress Provider可以分为两类：
一类为使用 metadata.annotations 扩展，例如 Nginx Ingress ；一类为使用新的 CRD，提供更丰富的路由能力，例如 Istio Ingress 。
目前 K8s 社区页面中K8s Ingress Provider 提供商种类已达20多个，每个Provider 提供商具有各自的特色。
三、K8s Ingress Provider 的发展趋势
从上图（ CNFF 2019年报告与2020年报告中截取的关于 Ingress Provider 的图示）可知，2019年 Nginx Ingress 仍然占据 Ingress Provider 首位，但2018-2019年增长为下降的趋势。包括第二名HAProxy也呈下降趋势。Envoy作为Ingress Provider在2018-2019呈大幅增长趋势。
2020年报告显示占据首位为Nginx Ingress，但第二位由Envoy代替HAProxy。Envoy增长率从2019年的不足20% 增长为2020年的37%，成倍增长。在2020年图示下的标注为揭示了新用户选择 Envoy 的占比增长率为116%。
在Ingress Provider领域Envoy 是最有可能超越 Nginx Ingress 的 Ingress Provider 的具体实现者，得益于 Envoy 相比于其它的在性能和扩展性上有一定优势。
除此之外 Switch mase 领域比较火爆，现在占据主流标准的就是 Istiod和 Envoy 的搭配，可以完全覆盖 Switch mase 东西向的场景和南北向的网关场景，一套方案就可以解决东西南北向的流量调度以及服务治理问题。
四、K8s Ingress Provider 的新选择-云原生网关
传统网关部署模式中，通常会采用两层的布局架构:第一层为流量网关，负责南北向流量调度及安全防护；第二层网关为微服务网关，它承担东西向流量调度及服务治理。
采用两层网关部署架构的原因：首先流量网关，所有业务都有共性需求，即对全局的流量调度以及安全防护，例如 htps 的安全证书卸载以及安全认证、限流，为共性诉求适合于流量网关。但是每个业务具有相关自身业务域的流量特点，希望可以根据特点进行流量的二次分发，因此诞生了微服务网关，负责的是贴合业务域的服务治理以及东西向的流量调度。
两层网关部署架构适用于大企业、超大型企业，例如阿里巴巴目前采用两层网关架构。小型企业、中小型企业大部分业务场景使用一层网关架构即可。一层网关可以同时提供流量网关和微服务网关的能力，即同时提供东西南北向的流量调度及安全防护与服务治理能力，可以完全满足中小型企业的业务诉求。并且用户运维成本以及资源部署成本直降50%。
基于对网关演变的理解，云原生网关诞生。它基于开源 Istiod 与 Envoy 的技术架构，完全遵循开源的技术标准，不会产生锁定的问题。正如所展示的数据与前文 CNFF 报告所讲，使用Istiod 与 Envoy 架构一方面可以满足作为网关的诉求，另一方面可以与 Switch mase 进行技术整合，提供一套整体的解决方案。
五、云原生网关的优势
1. 性能更强劲
在真实的压测对比下，压测模型是说网关是采用4*16C32G , 后端业务采用6*16C32G。后端业务 pode的部署数量大于网关，可以保证后端业务不成为一个压测时的性能瓶颈。对比的软件使用Istiod 与 Envoy 组合与社区的Nginx Ingress做对比。
由图所示， ACK的Nginx Ingress是阿里云的容器服务，基于社区Nginx Ingress的一个调优版本，即对里面的一些参数做了一个性能的二次调优。
压测对比两个软件，而压测结果对比了三组压测模型。三组分别是为在后端返回的包大小是在256、1024、4096时，RT跟TPS的对比。压测结果比较明显：第一，在CPU30%到40%的情况下，云原生网关的TPS相比于Nginx Ingress的要高出约90%。第二，在CPU超过40%之后，Nginx Ingress的吞吐会非常的不稳定，呈现一种波动的状态。同时云原生网关会非常稳定，并且TPS与CPU几乎是保持一个线性的增长。
进一步分析可知，在Nginx Ingress当中，它大量的使用了 Lua 脚本，实现动态的特性。传统的NES在做配置变更的时候，是需要做reload调整。而在Nginx Ingress下，大部分的场景不需要做reload调整。只有在HTPS证书变更时需要做reload 。但是对于后端例如20分钟service节点的end point的一些变化，不需要做 reload 。能够实现这一动态的特性的原因是大量的使用了Lua脚本。Lua脚本实际上对性能影响较大。
截图是来自于从K8S Nginx Ingress社区里面部分用户去做了一个性能测试的对比，比如基线版本使用Nginx Ingress的0.32版本，对应的是13万的RPS，那么第一步压测关掉log _ by _ Lua _ block Lua模块， RPS出现80%-90%的提升。关掉body _ filter _ by_ Lua_ block， RPS 又产生变化。
通过这组数据，可以直观的发现 Lua脚本对于源生 Nginx 的性能影响较大。使用ECU加 Evovy与Nginx Ingress对比时，性能会更强，甚至高于90%。高负载或高吞吐时，Nginx Ingress会出现非常大的抖动，是源于Lua。
展示 K8S Nginx Ingress社区关于性能测试的一个具体的依据： Poor performance in benchmark 。
