从 Nginx Ingress 窥探云原生网关选型

现今有越来越多的企业开始采纳云原生理念进行应用架构转型。而 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网关。

工作原理