作者： 魁予
现今有越来越多的企业开始采纳云原生理念进行应用架构转型。而 K8s 和微服务是云原生的两大支柱，随着云原生浪潮而被广泛应用。
对多数应用而言，提供对外服务的使命并不会改变，相比于原来的单体应用，微服务架构下的应用的服务出口更多，管理更繁琐，微服务网关也应运而生；而 K8s 也提供了多种方式来暴露应用的服务，各种 Ingress 实现百花齐放。面对众多技术方案，我们如何做出合理的选择，规避潜在风险，本文将给出一些选型建议，供大家参考。
云原生网关基本概述
K8s 中服务对外访问的方式
对于部署在云服务器上的应用，通常使用负载均衡软件或服务（如 SLB）来提供高可用的服务。K8s 提供了基于 Service 的服务发现机制，用户通过将一批相同特性的 Pod 绑定到一个 Service，可以提供稳定的 VIP（虚拟IP）或域名供集群内访问，并由 kube-proxy 组件基于 ipvs 或 iptables 实现 Pod 访问的负载均衡。当需要提供服务对外访问时，需要使用 NodePort 或 LoadBalancer 类型的 Service。
默认情况下，NodePort 会为服务在每个 K8s 集群的节点上分配一个节点端口，使用节点的 IP 地址和指定的节点端口可以从集群外部访问到服务后端的 Pod。用 NodePort 的方式暴露服务时，由于客户端配置的是节点的 IP 地址和端口，即使 Service 提供了负载均衡的能力，其稳定性也会受对应节点的影响。在客户端访问服务时，设置多个 K8s 集群节点的 IP 和服务 nodePort 端口，并配置合适的负载均衡和重试策略，才能够避免单点故障。
K8s 同时提供了 LoadBalancer 的 Service，客户端使用 LoadBalancer 的服务端点，可以有效规避掉节点单点故障风险。LoadBalancer 类型 Service 基于 NodePort 实现，云厂商 CCM 组件将根据 Service 创建负载均衡监听端口，并将 K8s 集群中各节点和 nodePort 端口添加到负载均衡器后端，由云上负载均衡器实现服务负载均衡能力。
对于需要 TCP 或 UDP 协议的四层转发时，使用 LoadBalancer 是一个简单有效的方式。但是当 K8s 集群中有大量 HTTP 或 HTTPS 类型的 web 服务需要进行七层转发时，如果仅使用 LoadBalancer 方式来暴露服务，当存在多个服务需要使用相同的端口时，需要为每个服务创建一个负载均衡器，分配不同的 IP 地址，会造成大量的资源成本和维护成本。
应用网关的要求
如前文所述，K8s Service 解决的是服务发现和负载均衡的问题，但并没有服务治理能力，无法被当成网关使用，而对于一个典型的应用网关，基本都包含以下能力：
- 为了避免为各个微服务做重复冗余的认证鉴权配置，网关能够支持提供安全认证、访问限制、支持 SSL 卸载等。
- 出于网关稳定性考虑，我们希望网关能够提供一定的限流能力。
- 需要有可观测能力查看网关后端各服务响应时间趋势、请求状态码统计等。
- 为了保证能够快速定位排查问题，网关也需要记录各请求的详细访问日志。
K8s 提出了 Ingress 以支持从集群外部到集群内服务的 HTTP 和 HTTPS 服务路由，并提供了对外访问的统一端点，Nginx Ingress 是社区提供的基于 Nginx 实现的默认 Ingress 控制器。
Nginx Ingress 概述
网关云原生化是一个普遍的趋势，使用不同底层网关实现的 Ingress Provider，其提供的网关特性能力各不相同。Nginx 作为被普遍使用的反向代理工具，基于 Nginx 实现的 Nginx Ingress 也成为了 K8s 集群中最广泛使用的Ingress网关。
工作原理
通常 Nginx Ingress 以 Deployment 结合 LoadBalancer Service 的方式部署在 K8s 集群中，Nginx Ingress Controller 由 manager 和 Nginx 进程组成，manager 负责监听 Ingress 资源变更并基于 Nginx 配置模版将 Ingress 资源的 Spec 定义和注解转换为Nginx可识别参数，生成新的 nginx.conf 配置文件，并由 manager 发起 Nginx 进程 reload，新的路由配置就通过 Ingress 在网关生效了。外部流量经过 LoadBalancer 转发到 Nginx，由 Nginx 根据路由配置转发到后端服务中。
Nginx Ingress Controller 还监听了 Service 的后端的变化，并将变更后的后端列表发送到 Nginx 中进行缓存，在应用 Pod 变更或扩缩容时，无需考虑 Pod IP 变化即可实现 Nginx 服务后端的动态变更。此外，Nginx Ingress 官方提供了 prometheus 监控对接方案，并提供了基础指标的监控大盘，便于观察网关后端服务响应状态。
Ingress 资源定义了主机名和路径来设置服务在 Nginx 上的七层转发规则，同时 Nginx Ingress 还支持配置扩展，扩展机制包括：
- 通用注解：对于一些通用的 Nginx 能力，比如重写、重定向、连接数设置、超时时间等，Nginx Ingress 定义了通用的注解以便于 Controller 识别解析为 nginx.conf 配置文件内容。
- 配置片段：面对需要定制化 Nginx 配置的场景，Nginx Ingress 也提供了注解 main-snippet、server-snippet、configuration-snippet 来插入定制化的 nginx.conf 配置片段。
- lua 插件：Nginx Ingress 还支持插件化挂载自定义 lua 脚本便于从自建 Nginx 迁移到K8s Nginx Ingress 中。
一个使用 Ingress 的注解来自定义 location 片段，实现根据请求头重定向的例子如下：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
if ($http_user = "gray") {
rewrite ^/(.*)$ /traffic;
}
...
spec:
rules:
- host: test.domain.com
http:
paths:
- backend:
service:
name: test-svc
port:
number: 80
path: /test
...查看 Nginx Ingress Controller 中的配置，可以看到插入的配置片段：
server {
server_name test.domain.com
...
location /test {
...
if ($http_user = "gray") {
rewrite ^/(.*)$ /traffic;
}
}
}Nginx Ingress 网关不足
不难看出，Nginx 反向代理网关仍然是部署在 K8s 集群中的，网关的性能直接受 Pod 资源分配和宿主机性能影响。且如果 Nginx Ingress Controller Pod 所在的节点仍然存在其他业务 Pod，还会出现资源抢占问题。由于 Nginx Ingress 承担了集群的大量入口流量，稳定性要求很高，通常情况下，我们会将其 Pod 独立调度来保证稳定性，比如在节点上设置污点，并在 Ingress Controller 的 Pod 中设置污点容忍让其独占节点资源；为增强 Ingress 网关可靠性，需要结合业务实际压力设置 Ingress 的副本数和资源分配；出于网关高峰期弹性考虑，还需要结合 HPA 以支持网关 Pod 水平扩容；此外，Nginx Ingress 实际是由负载均衡器提供的对外访问能力，还需要结合业务考虑负载均衡带宽是否满足高峰期需求。
K8s 为 Pod 提供了 livenessProbe 和 readinessProbe 的存活检查和健康检查机制，官方 Nginx Ingress Controller 的 Deployment 部署模版中也使用了该机制进行网关健康检查，相关配置如下：
livenessProbe:
failureThreshold: 5
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
readinessProbe:
failureThreshold: 3
httpGet:
path: /healthz
port: 10254
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1其健康检查和存活检查使用的是由控制面 manager 监听的 10254 端口提供的 /healthz 健康检查入口，而 Nginx Ingress 数据面和控制面在同一个容器中，在业务高峰期网关负载较高时很有可能导致控制面的健康检查接口响应超时。根据 livenessProbe 机制，很有可能出现 Nginx Ingress 网关不断重启导致网关不稳定，流量有损。此外，控制面 manager 还负责采集prometheus监控指标，在业务高峰期控制面还可能抢占不到足够的 CPU，出现 OOM，导致容器被 Kill 的情况。
另外需要注意的是，通过 Nginx Ingress 更新 Nginx 网关路由规则直接将域名和路径订正到 nginx.conf 配置文件，需要更新 Nginx 配置并重新加载才能生效。当应用存在长连接，如 websocket 的情况下，reload 操作会导致业务连接在一段时间后出现明显掉线。
在操作 Ingress 资源时，如新建 Ingress、删除 Ingress、更新 Ingress 后端、更新 Ingress 证书配置等操作，都会触发 Nginx 进程的 reload。虽然 Nginx 的 reload 过程存在优雅停止机制，在接收到 reload 信号后会创建新的 workerq 子进程并保持旧 worker 进程处理已有请求，如下图所示：
但是当客户端存在 TCP 长连接超过了 worker_shutdown_timeout 时间没有断开时，会强制终止原有的 worker 进程，断开 worker 上的连接，nginx reload 原理示意图如下：
除此之外，由于 Nginx Ingress Controller 是通过 List 和 Watch 机制监听 K8s 中的资源，多个节点的控制器行为一致，reload 操作的时间虽然存时间差异，但大致可以看作是同时进行，同时 reload 无疑会让风险最大化。为降低 reload 的影响，我们可以考虑优化 Nginx Ingress，比如通过将 Nginx Ingress Controller 的配置文件变更与自动reload 行为分开，保留动态修改配置逻辑，增加 reload 触发逻辑，reload 操作只有满足了特定条件才能进行。比如，为 Pod 新增 reload 信号注解，控制器识别到节点存在该注解再触发 reload，降低 reload 操作的影响面。
但是 Nginx Ingress 通过配置文件来更新 Nginx 路由配置的操作，无法避免 reload。面对该问题，业界也提出了使用 Nginx 结合 Lua 插件动态读取网关上游配置的方案，路由规则存储在数据库中，由 Lua 配置读取到 Nginx 的共享内存中，示意图如下。
自建网关容易忽略的细节
综上可见，Nginx Ingress 网关在 K8s 集群中存在进程 reload 长连接有损、数据面和控制面未分离、运维难度高等短板。当我们需要自建 Nginx Controller 时，设想一下，在 K8s 中还需要考虑哪些细节：
- 不稳定的后端 IP：Pod 的 IP 地址会随应用的重启、迁移、新版本发布频繁的变更。不稳定的后端 IP 让配置难以下手。
- 频繁更新的配置文件：每次后端应用的变更都需要人工维护 Nginx 配置，当构建多节点的高可用 Nginx 服务时，需要人工保证多节点配置的准确性一致性。
- 配置持久化：由于 Pod 的不稳定性，当以 Pod 形式部署 Nginx 服务时，每次 Pod 的销毁和新建，在 Pod 中的变更都会丢失，需要持久化保存配置并挂载到多个 Nginx Pod 中。
- 监控面板对接：需要运维人员自行安装 Nginx 监控模块，并对接到外部监控系统。
- 访问日志持久化：需要为 Nginx 服务额外挂载持久化数据盘以保存访问日志。
庆幸的是，随着云原生化趋势，越来越多的网关兼容了 Ingress 实现成为了 Ingress Provider，不少网关已经实现了配置热加载，数据面和控制面分离的能力，并且根据网关特性能力的不同存在各自的优缺点。在 EDAS 中，除了接入了 Nginx Ingress 路由外，还接入了 ALB Ingress、MSE Ingress。下面以这两种 Ingress Provider 为例介绍多种Ingress Provider 的通用实现及其优缺点。
其他 Ingress 网关实现
Ingress 支持设置 “kubernetes.io/ingress.class” 注解或者配置 ingressClassName 属性来为 Ingress 关联不同的 Ingress Controller。并由 Ingress Controller 来作为 Ingress 资源的监听组件，将 Ingress 的配置解析为后端网关的配置中，如 Nginx 网关的 nginx.conf 配置，ALB 网关的监听后端转发规则，云原生网关的路由规则。Ingress、Ingress Class、Ingress Controller 关联关系如下图所示：
ALB Ingress
由上图可见，ALB Ingress 工作时业务面与数据面分离，支持热加载，底层的网关实现为托管在阿里云上的 ALB 实例。基于 ALB 的高弹性、高并发数特性，能够得到完全免运维、自动弹性伸缩的高性能网关，阿里云的 ALB Ingress 解决了 Nginx Ingress 维护的难点。ALB Ingress 兼容了部分 Nginx Ingress 的通用注解，但对于配置片段和插件机制，由于底层实现的不同，并不能做到完全兼容。
MSE Ingress（云原生网关）
MSE Ingress 是基于 MSE 云原生网关实现的，业务面与数据面分离、支持热加载，云原生网关不仅能够作为 Ingress Provider 为 K8s 集群中的 Service 提供对外南北向流量管理，还能够作为微服务网关对接 EDAS 注册中心、MSE 注册中心、自建 Nacos、Eureka 注册中心提供东西向流量管理能力。同时支持完备的微服务网关功能，如限流、流量防护、熔断等，能够节省部署和维护应用型微服务网关的成本，如 springCloud gateway、zuul。此外，在扩展性上，MSE Ingress 支持了 Wasm 插件，对于 Lua 插件的支持也在进行中。
场景总结
网关云原生化是一个普遍的趋势，使用不同底层网关实现的 Ingress Provider，其提供的网关特性能力各不相同。除本文介绍 EDAS 支持的配置的三种 Ingress Provider 外，还有其他多种热门 Provider，如 APISIX Ingress、Haproxy Ingress、Istio Ingress，他们在 K8s 集群中的工作模型均可参考上述的 Ingress-IngressClass-Ingress Controller 模式。
面对多样化的应用路由网关，我们需要了解网关特性能力并结合实际业务场景来做选择，对于本文提到的三种 Ingress Provider，可以总结其分别适用的场景：
- Nginx Ingress：官方提供的开源 Nginx Ingress 解决方案，与平台无关最易接入，适用于对网关有定制化需求场景，适用于从自建 Nginx 网关迁移到 K8s Ingress 网关的场景。但需要额外对网关进行运维，存在稳定性风险。
- ALB Ingress：基于 ALB，全托管于阿里云上，免运维。适用于业务高峰期超大 QPS、超高并发连接的场景。如果应用运行在阿里云上，且没有复杂的扩展需求，ALB 是省时省力的选择。
- MSE Ingress：基于云原生网关，作为流量网关和微服务 API 网关，适用于对 K8s Ingress 网关和微服务网关同时需求的场景，支持多语言编写 Wasm 插件扩展网关能力。此外，该网关实现已开源，详细可见：https://github.com/alibaba/hi...
此外，Ingress API 仅支持根据域名和路径配置转发规则，网关供应商需要通过自定义注解来实现更丰富的路由转发和流量治理能力，致使网关路由资源配置越来越复杂。K8s 社区推出了开源项目 Gateway API，用以提供规范化、可扩展、更丰富的网关路由模型，已有多种 Ingress 网关供应商在其控制器中实现了 Gateway API 标准，保证了其路由配置向 Gateway API 标准平滑迁移。
EDAS 应用路由管理
K8s Ingress为应用网关提供了很多灵活的选择，但每种网关能力各有差异，而且大多通过注解方式来提供扩展能力，对很多用户来说复杂度是比较高的。为此，EDAS 提供了应用路由管理功能，用户只需要编写路由规则并选择网关类型，就能将应用的服务暴露到外部，方便快捷。同时 EDAS 也提供了应用路由的监控大盘，日志检索等必备的运维功能，可以帮助用户快速发现和定位问题，保证业务稳定性。参见下图：
- Nginx Ingress
- MSE Ingress
- ALB Ingress
- 概览大盘
- 访问日志查询
- 调用链路追踪