随着容器和 Kubernetes 技术的兴起，集群入口流量管理方式逐渐被 Ingress 通用化和标准化。入口网关的标准化制定将入口流量管理与网关的实现解耦，不仅促进了各种 Ingress Controller 的发展，而且消除了开发者存在的与厂商绑定的顾虑，日后也可以根据自身业务实际场景切换到不同 Ingress Controller。目前，越来越多的开发者开始关注并考虑将业务网关切换为 Ingress 网关，有的企业甚至已经落地了 Ingress 网关。

本文主要介绍 Ingress Controller 新选择——MSE Ingress 是什么，分享 MSE Ingress 最佳实践来帮助开发者从用 Ingress、到用好 Ingress。

什么是 Ingress

简单回顾一下之前我们在使用一些传统网关遇到的问题。

式均不同，开发者在选用网关之前需要熟悉对应网关的配置文件的使用方法，企业在招聘人员也要考虑是否具备所用网关的技术栈。
迁移成本：业务由于自身原因需要切换网关类型，开发者需要熟悉目标网关的配置文件，开发迁移工具，测试迁移工具的完整性，演练迁移方案，最终才能完成迁移。

在 Kubernetes 平台中，抽象、标准是第一要义。有了标准，才能更好适配各类不同实现的组件，才能不断蓬勃、可持续的发展。Kubernetes 通过统一抽象定义的 Ingress 资源来管理外部访问集群内部服务的方式，将入口网关的功能与实现解耦。

使用 Ingress 来管理集群入口流量有3大优势：

切换业务网关的实现。
简单：Ingress 的定义格式简单，易于学习。通过简单配置 Host、Path 和目标服务即可快速完成集群内部服务的对外发布。
可扩展：Ingress 的标准定义仅仅包含了 HTTP 流量的路由匹配规则以及 HTTPS 流量所需的证书配置。开发者可以通过 Ingress Annotation 的形式进一步拓展 Ingress 的 API，实现流量分流、跨域、Header控制等治理策略。

Ingress 实现现状

Ingress 是抽象接口，具体的实现仍然由各类网关完成。目前，Ingress 的实现有两大阵营：Nginx 和 Envoy。Nginx 存量大，但是由于架构设计的问题，随着用户规模变大逐步暴露安全和稳定性风险，目前社区宣布停止 6 个月新需求开发，集中解决安全和稳定性问题；Envoy + Istio 作为后起之秀，采用数据面和控制面分离架构，有更好的安全和稳定性保障，并且支持多语言扩展，热更新优势，Envoy 社区也推出 Gateway 产品加速 Gateway API 落地。

Ingress 实现趋势

从以下 CNCF 对 Ingress Provider 调研结果来看，虽然 Nginx 仍然处于 Ingress Provider 榜首，但增长速度已经放缓；Envoy 正在以最快的速度占据市场，越来越多的企业开始使用 Envoy，Envoy 的优势正在被更多的用户认可。

Ingress 实现新选择：MSE Ingress

随着云原生技术持续演进，云原生应用微服务化不断深入，Nginx Ingress 在面对复杂路由规则配置、支持多种应用层协议（Dubbo和QUIC等）、服务访问的安全性以及流量的可观测性等问题上略显疲惫。

另外，Nignx Ingress 在处理配置更新问题上是通过 Reload 方式来生效配置，在面对大规模长连接的情况下是会出现闪断情况，频繁变更配置可能会造成业务流量有损。

为了解决用户对大规模流量治理的强烈诉求，基于 Envoy 内核构建的 MSE Ingress 网关应运而生，这是阿里云推出的兼容标准 Ingress 规范的下一代网关，具备低成本、安全、高集成和高可用的产品优势。将传统的 WAF 网关、流量网关和微服务网关合并，在降低 50% 资源成本的同时为用户提供了精细化的流量治理能力，支持 ACK 容器服务、Nacos、Eureka、固定地址、FaaS 等多种服务发现方式，支持多种认证登录方式快速构建安全防线，提供全方面、多视角的监控体系，如指标监控、日志分析以及链路追踪，并且支持解析单、多 K8s 集群模式下的标准 Ingress 资源，帮助用户在云原生应用场景下以声明式进行统一流量治理，此外我们引入了 WASM 插件市场满足用户定制化的需求。

MSE Ingress 优势

MSE Ingress 相比 Nginx Ingress，在流量治理和安全防护上更胜一筹。

MSE Ingress 开源：Higress

有了阿里巴巴内部业务实际场景和云产品的沉淀，我们希望有更多的开发者可以一起共建 MSE Ingress 网关，于是我们在去年 11 月开源了 Higress 网关，依托以 Kubernetes Ingress 网关为契机带来了的流量网关与微服务网关融合的可行性，实现了流量网关 + 微服务网关 + 安全网关三合一的高集成能力，同时深度集成了 Dubbo、Nacos、Sentinel 等，能够帮助用户极大的降低网关的部署及运维成本，而且能力不打折。

MSE Ingress 最佳实践：灰度发布

业务规模不断扩大促使应用系统的迭代速度加快，多变的外部市场环境要求业务系统具备快速试错的能力，如何保障应用升级过程中流量无损是开发者始终关心的问题。

MSE Canary Ingress

用户借助 MSE Ingress 可以实现服务多个灰度版本共存，方便服务多个特性功能同时开发并且独立灰度验证。MSE Ingress 支持多种灰度流量识别方式，基于 HTTP Header、基于请求参数、基于 Cookie 和基于权重的方式，用户可以按需针对路由级别实施灰度匹配策略。

渐进式交付框架：Kruise Rollout

以上的方式依赖开发者手动管理 Ingress、Deployment 和 Service 资源，借助于渐进式交付框架 Kruise Rollout，开发者无需关注发布过程中如何调整 Deployment、Ingress、Service 等资源，只需声明并管理发布策略 Rollouts 资源即可，原生 Deployment 的滚动发布会自动实现为渐进式交付，让应用发布可批次、可灰度、可回滚，助力业务快速迭代发展同时，也提高了应用发布的稳定性和效率问题。

MSE Ingress最佳实践：全链路灰度

对于分布式架构的微服务应用而言，服务之间的依赖关系错综复杂，一个业务功能需要多个微服务共同提供能力，一次业务请求需要经过多个微服务才能完成处理，牵一发而动全身。

在这种场景下，业务新功能发布可能同时涉及到多个服务发布，对新功能验证时就涉及到了对多个服务同时灰度的问题，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证，这就是微服务架构中特有的全链路灰度场景。

目前，全链路灰度的解决方案包括基于物理环境隔离和基于逻辑环境隔离。基于物理环境隔离的做法是通过增加机器的方式来搭建真正意义上的流量隔离，该方式存在一定的人力成本和机器成本，所以业界比较常用的做法是更灵活的基于逻辑环境管理。该方式虽然看起来是服务正式版本和灰度版本都部署在一个环境中，但是通过灰度路由匹配策略，可以精确控制灰度流量优先流经服务对应的灰度版本，只有当目标服务不存在灰度版本时，才会容灾到服务正式版本。从总体视角上看，针对新功能的灰度验证流量只会流经涉及到待发版服务的灰度版本，对于本次新功能未涉及到改动的服务，灰度流量正常通过，这种精准化的流量控制方式大大方便了开发者在微服务架构中多版本并行开发和验证的痛点，同时也降低了搭建测试环境的机器成本。

容器服务 ACK 用户，可以搭配使用 MSE 微服务治理和 MSE Ingress，在不改任何一行代码的情况下，轻松快速上手全链路灰度能力，通过这种精细化的流量控制能力在用户在微服务架构治理过程中得心应手。

MSE Ingress 最佳实践：无损上下线

无损下线

服务的 Pod 实例在以下情况会出现下线：

服务缩容：当大促洪峰流量结束时，为节省资源会对服务进行缩容操作，将资源控制在合理范围内。
服务发布：当服务进行升级迭代时，服务的老版本实例会进行下线操作，流量逐步转向服务的新版本实例。

看似简单的下线操作，其实暗藏玄机。由于微服务应用自身调用特点，在高并发下，服务提供端应用实例的直接下线，会导致服务消费端应用实例无法实时感知下游实例的实时状态，因而出现继续将请求转发到已下线的实例从而出现请求报错，流量有损。

为什么会出现这种问题呢？这是因为在 K8s 平台中 Pod 的 Endpoint 下线事件是异步的，也就是说 Ingress 网关可能在 Pod 下线之后才收到 Endpoint 下线事件，而这期间的线上流量仍然会被 Ingress 网关转发至已下线的实例，导致请求出错。

那么如何保证实例下线过程中流量无损呢？有以下几种方案：

间内（一般15s）继续处理新到的请求，之后开始关闭连接并终止进程。
如果你无法或不愿意对业务应用代码添加 SIGTERM 信号的处理逻辑，那么你可以采用 K8s PreStop 机制。PreStop 机制是一种外部可插拔的，用于在发送 SIGTERM 信号之前执行的拦截点。常用的做法是执行 Sleep 命令等待 15 到 30 秒，确保 Endpoint 下线事件已被 Ingress 网关、CoreDNS、KubeProxy 等组件处理。
你可以选用云产品 MSE 微服务治理，以无侵入的方式实现无损下线。

无损上线

服务的 Pod 实例在以下情况会出现上线：

服务扩容：当大促洪峰流量到来之前，为满足请求容量，会对服务进行扩容。
服务发布：当服务进行升级迭代时，服务的新版本实例会进行上线操作。

同样，新节点上线过程中也是危机重重。当服务的新节点启动之后，Ingress 网关会感知服务新节点上线事件，更新连接池信息并加入新节点，新的访问请求会被负载到新节点上。由于新节点启动之后，需要进行一些资源初始化和预热操作。这时，如果大量的请求在资源初始化完毕之前到来，会导致请求出现超时或出错，甚至直接导致新节点宕机不可用。

MSE Ingress 给出了一个非常简单的解决方案，用户只需在 Ingress 资源上通过 Annotation 配置服务预热时间即可。MSE Ingress 会对新节点按照新节点启动时间在预热窗口期中的占比决定新节点分配流量的权重，确保新节点在接收全部流量之前已完成充分预热，保障上线过程中平滑无损。

MSE Ingress 最佳实践：全域安全

安全问题始终是业务应用的头号公敌，伴随着业务发展的整个生命周期。此外，外部互联网的环境越来越复杂，内部业务架构日益庞大，部署结构涉及公有云、私有云以及混合云多种形态，安全问题愈演愈烈。

作为入口网关的 MSE Ingress，从一开始就在安全领域进行了积极探索和增强，打造了全方面的安全防护。主要体现在以下几个方面：

加密通信以及 TLS 硬件加速

业务通信数据通常来说都是私有的、敏感的，TLS 作为最基本、最广泛的防窃听、防篡改的协议经常和 HTTP 协议结合使用，就是大家熟知的 HTTPS 协议。MSE Ingress 构建了从客户端到网关、网关到后端服务整个体系的 HTTPS 协议支持，并且结合阿里云第七代 ECS 率先完成了 TLS 硬件加速，在不增加用户资源成本的同时大幅度提升 HTTPS 的性能。针对特殊业务场景下对 TLS 协议版本以及 TLS 加密条件的合规性要求，MSE Ingress 额外支持了域名级别的 TLS 版本控制以及加密套件选择。

细粒度的 WAF 防护

在功能上，MSE Ingress 不仅支持全局WAF防护，而且提供了细粒度的路由级别的 WAF 防护；在架构上，MSE Ingress 采用内置 WAF Agent 的方式，相比传统 WAF 用户请求链路更短、RT 更低。

细粒度的 IP 访问控制

MSE Ingress 支持实例级别、域名级别以及路由级别的 IP 黑白名单，优先级逐步增加。用户可以在实例级别配置应用范围更广的 IP 访问控制，然后在路由级别配置与业务相关的 IP 访问控制，满足用户多样化的访问控制策略。

多样化的认证鉴权体系
在微服务的架构中，会有多个服务接收来自外部用户（客户端）的请求，通常不会直接将服务暴露给外部用户，而是在中间加一层网关作为外部用户访问内部服务的控制点。对于外部用户访问的请求，我们通常希望在网关中进行身份验证，知道用户是谁，并能定义访问控制策略。目前，MSE Ingress 支持 Basic Auth、JWT Auth、OIDC、阿里云 IDaaS 服务以及自定义外部认证鉴权，助力业务以无侵入的方式轻松实现高阶访问控制。