开发者学堂课程【从概念、部署到优化，Kubernetes Ingress 网关的落地实践：从概念、部署到优化，Kubernetes Ingress 网关的落地实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1013/detail/15070
从概念、部署到优化，Kubernetes Ingress 网关的落地实践
通常会按照业务域和功能对服务进行拆分，在对外设计 API 的时候也可以遵循这样的原则。可以在原有的后端服务对外暴露的 path 上可以添加具有代表性意义的业务前缀，在请求完成路由匹配之后，和转发请求到后端服务之前时，这个前缀由 Ingress provider 通过重写 path 将其消除。整个工作流程图是这样的，就是现在有三个服务：用户中心、订单中心和支付中心，内部代码对外暴露的 API 是不带有业务语义的，类似于/xx、/yy、
/zz这种比较简单的 API，当通过对外暴露的时候会为这些 API 添加一些具备业务语义的前缀，这样的做法易于管理对外暴露的服务集合，通过业务前缀就可以非常明确知道 API 的业务语义，同时可以基于业务前缀做更细腻的认证鉴权，比如哪些用户可以访问带有 /user 的 API，另外一些用户可以访问带有
/order 的前缀的 API。另一方面由于对 API进行了统一格式，在做可观测性建设的时候提取标志性的key的时候会非常方便。总结就是易于管理维护，便于认证鉴权，便于观测统计，对应到 Ingress 资源上同样也是通过 Annotation 做到的，就是 path 需要全面匹配，通过正则规范捕获 path 前缀的后一部分，Annotation 通过 rewrite-target 指定重写后的值为捕获后的值。比如配置了/path 这个捕获组， Ingress provider 在转发流量到后端时就会把 users 去掉，重写为捕获后的值。
另一个比较重要的问题就是安全问题，安全问题始终是业务应用的一个头号公敌，主要存在于整个业务发展的生命周期。外部互联网环境越来越复杂，内部业务架构日益庞大，内部业务架构的部署结构公有、私有以及混合等多种形态，安全问题不可忽视。其中零信任作为安全领域的一种新型设计模型，被广大开发者追捧。主要思想是认为应用网络内外的所有用户服务都不可信，在发起请求处理请求之前都要进行相关认证，所有的授权操作都遵循最小权限原则。总结就是不相信任何人，要验证所有请求。
为什么需要零信任，因为现在互联网外部网络环境存在的黑客非法用户总体是呈现不安全的状态，也没有机构帮助管理网络环境，另外随着业务规模的扩大，内部的应用架构部署结构也会越来越复杂，就呈现出了混合状态，所以零信任是挺重要的。示意图主要讲解了如何将零信任落地到实际的业务场景，在该示意图中，举例是客户端、Ingress provider 和一个后端服务，展示了在整个链路上如何进行零信任的实践。对于外部用户到 Ingress provider 这一层面，外部用户通过向权威机构验证 Ingress provider 提供的证书完成相关认证， Ingress provider 通过外部用户提供的 JWT 凭证完成认证鉴权。
具体做法就是 Ingress provider 对 JWT 进行合法性检验，当检验通过之后就会取出其中 Client 信息，基于信息通过向授权服务检测该用户是否拥有访问该 API 的权限。Ingress provider 与后端服务做认证主要是通过 MTLS, Ingress provider 通过向内部私有证书机构验证后端服务提供的证书完成身份认证，后端服务通过向内部私有证书机构验证 Ingress provider 提供的证书完成身份认证。 Ingress provider 与后端服务所使用的证书都是由内部的私有 c 签的，所以 Ingress provider 与后端服务可以做一个向私有 c 认证对方的身份，因为证书中包含了用户两方的身份信息。同样后端服务在验证完身份之后可以做一下鉴权的操作，可以向授权服务检测调用端是否有访问该服务的权限。以上就是一个简单的零信任场景。
因为所有访问流量都需要先经过 Ingress provider,因此所有的性能瓶颈是体现在 Ingress provider 上。在持续对它高并发高性能有了一个更高的要求，如果抛开 Ingress provider 实现差异，可以从底层做一些通用性的性能调优，比如可以调整内置参数进一步提升性能。经过阿里巴巴多年在集群阶层的实践经验，一般会适当调整以下参数。比如会调整 TCP 连接队列的容量，这里主要涉及一个 TCP 存在一个半连接的队列和一个全连验证队列，当通过调大队列容量时，会调整并发数。
另一方面会调大可用端口的范围，当网关向后端服务进行建链的时候会随机分配一个端口，这个端口范围默认是比较小的，一般会调大这个范围。另一方面会开启复用 TCP 连接的开关，当 TCP 连接处于 turn away 的时候，当开这个选项之后，当有新的请求时候，可以复制这个链接。另一个优化角度是从硬件着手，充分释放底层硬件算力帮助应用程序性能提升，目前 HTTPS 流量已经成为公网请求的主要使用方式，当全部使用 HTTPS 之后，由于要做 TLS 握手 相比 HTTP 性能上会有一定的损耗。现在随着 CPU 的发展，可以利用 CPU 的 SIMD 的机制，可以很好的加速 TLS 的性能，也就是说将 TLS 的加解密在硬件中进行卸载释放 CPU 的时间片。优化方案其实比较依赖机器硬件的支持以及 Ingress Provider 内部实现的支持，目前依托 Ingress Provider、新型的网关，并且结合了阿里云第七代 ECS 率先完成了 TLS 的加速，在不增加用户机器成本的同时，大幅度提升了 HTTPS 的性能。通过压测发现 HTTPS 的 QPS 提升了大约百分之八十六， TLS 握手 RT 下降了一倍，效果还是非常明显的。
现在用户用的比较多的是 Nginx Ingress,但 Nginx Ingress 在对复杂路由配置在应用层协议还有服务访问的安全性以及流量的可观测建设上是略显不足的。此外 Nginx Ingress 另一个比较大的弊端就是通过 review 的方式进行配置更新，这样在面对大规模场景情况下会出现连接闪断，发现频繁变更配置在一定时候会出现业务流量有损。针对该情况，推出了兼容标准 Ingress 规范的下一代网关，具备低成本、安全、高集成和高可用的产品，将传统的 WAF 网关、流量网关和微服务网关三合一，在降低用户资源成本的同时，为用户提供了丰富的治理能力。图中在证书发现集成了阿里云 SSL 服务,用户可以关联由阿里云代现发的证书以及一些第三方的证书用户可以上传到 SSL 平台，都可以由原生网关来关联。
另一方面在 WAF 通过 adding 的方式挂载在网关的旁边，相比于传统的 WAF 网关，在真正业务网关之前少了一条，在 RT 上是比较友好的。另一方面集成了 AHAS，可以对原生网关进行集群级别的限流，同样可以利用 AHAS 一些比较高级的特性做一些路由级别的垄断、限流以及降级的操作。在认证鉴权集齐了 JWT 的认证，也对接了阿里云的 IDaaS,做一些统一的身份认证，同时支持了一个标准的 OIDC协议，用户可以通过原生网关对接其他云产商提供的身份云。对于扩展性因为用户的业务在入口流量管理是多样化的，一个产品可能在做功能时可能无法满足所有用户的需求，所以推出了 WASM 插件市场，帮助用户自定义扩展功能，通过 WASM 用户可以选择自己喜爱的语言编写插件在原生网关上进行上传应用，目前支持 c++,用户可以根据自己的技术和语言进行选择。此外，在可观性通过 SLS 日志服务将网关的访问日志进行投递，用户可以基于 SLS 进行日志分析以及线上问题的排查。
在 ARMS 主要用到一些监控指标，方便用户监控网关一些 CPU 内存的使用情况以及 qbs、mpv 各种路由级别的成功率的检测。第三个就是集成的 XTrace，构建从网关到后端服务整条链路的调用链的记录，用户可以根据整个调用链分析线上问题以及进行性能平稳的分析。作为一款原生网关，势必要支持标准的 K8s 的资源，同时也针对了 Nginx Ingress 支持，相比于 Nginx Ingress, MSE 网关另一个比较有用的地方就是可以做多集群的流量管理，可以通过一个原生网关关联多个并且同时监听对应集群的 Ingress 资源，把路由规则 Ingress 合并之后转换为原生网关的路由规则，用户可以在原生网关做统一的一个跨集群的流量管理。
为了进一步融合 K8s 生态，还开发了 MSE Ingress Controller,用户可以在应用市场通过 html 方式安装组件，方便用户通过 DataOps 和 SCS 的方式管理原生网关。
分析一下MSE 网关相比于 Nginx Ingress有哪些功能上的不同。首先是产品定位， Nginx Ingress 主要处理 HTTP/HTTPS 流量治理，MSE 原生网关将流量网关、微服务网关和安全网关三合一，在降低资源成本的情况下，能力不打折，同样也能处理大规模的 HTTPS 的流量。
在性能上，Nginx Ingress 需要用户手动调优，需要注意的是配置变更需要通过 reload 方式进行生效，可能对长连接的情况不太友好。MSE 网关是托管式的免运维的并且内核参数根据多年的网关经验调至最优，配置是热更新的，而且结合了阿里云第七代 ECS 内置 TLS 硬件加速，进一步提升 HTTPS 流量的性能。
路由上 Nginx Ingress 支持基于 header、权重的流量分流还有重写和重定向，都是通过拓展 Ingress 做到的。此外需要注意灰度发布 Nginx Ingress 仅支持服务的两个版本，无法支持多个版本之间的流量分流。 MSE 原生网关也支持基本的路由功能，注意的是灰度发布支持服务的多个版本，v1、v2、v3、v4 线上可以承担多版本，可以根据 header 或者权重进行流量分流。
服务发现上 Nginx Ingress 主要支持 K8s Service, MSW 网关不仅仅聚焦 K8s Service,也聚焦一些微服务架构下比较流行的比如 Nacos、Eureka、DNS、ECS 以及 FaaS 服务进行一些发现，也是基于域名做的。
认证鉴权 Nginx 支持基本的 Auth，通过 app 的insname 和 pathword 做的，也支持 OAuth标准的诉权协议。MSE 网关除了这两种比较流行的协议以外，还支持 JWT、OIDC、IDaaS，额外支持一个自定义认证鉴权，因为用户的形式由于历史原因或者自身业务原因不是使用标准 IWT 或者OIDC的形式，是一个自定义的形式，网关可以接入一个自定义认证鉴权服务，等于需要认证鉴权的请求之后会有网关向用户配置的认证服务进行鉴权之后，这个请求会被放入并且转发到后端服务，如果认证不通过，就会直接响应给客户端。
安全性 Nginx Ingress 支持 HTTPS、MTLS 以及黑白名单，原生网关另外支持了一个 WAF 防护和无缝对接阿里云 SSL 证书，另外也支持了一个批量更新证书的功能。
扩展性 Nginx Ingress 通过 Lua 脚步来做的，原生网关在额外支持一个 WASM 插件，因为 Lua 可能受限于语言并且性能没有 WASM 性能好，WASM 不仅性能好，而且在多语言方面比较有亮点，用户可以基于自己语言选择编写对应的插件。
可观测 Nginx Ingress 也是对外暴露通过标准的 Prometheus 定义的这种规范对外吐露指标，原生网关将这些访问日志监控指标和 XTrace 无缝对接云产品方便用户一体化进行可观测的建设。通过对比发现 MSE 原生网关相比于 Nginx Ingress 多了许多能力，如何平滑迁移到 MSE 原生网关呢？
假设集群中有一个 Nginx Ingress,监听集群的 Ingress,并让流量转发到后端 pod，需要创建原生网关，然后关联对应的 SACK 集群，需要在原生网关配置监听的 Ingress class 以及 Ingress,当原生网关建立监听 Ingress 链接之后，可以绑定原生网关 SLB 的地址，绑定本地 host 的方式验证流量 Ingress 在原生网关解析是否符合预期。当验证完毕之后，可以在 DNS Server 上按照权重进行灰度，将线上的一部分流量引流到原生网关，这里的做法就是通过在 DNS Server上添加原生网关的 SLB IP,并且调至权重为百分之一，这样通过很小一部分流量验证功能是否符合预期，当验证完毕后可以通过不断调整权重直至全部迁移完毕。
这期间如果遇到不符合预期的情况，在原生网关出现不符合预期的同时可以在 DNS Server 上调整权重把流量回迁到 Nginx Ingress。通过该方式用户可以平滑迁移到 MSE 原生网关，其他的 Ingress Provider 也可以参照该方法完成网关迁移。
三．动手实践
首先介绍 MSE Ingress Controller，是用来管理 MSE 原生网关的，提供 MSE Ingress Controller 主要是为了提供给用户通过声明式配置的方式管理原生网关。可以在应用市场点击应用场景微服务中找到 ack-mse-ingress-controller 进行安装。
点击下一步
