Kubernetes七层流量入口深度解析：Ingress与Gateway API架构对比与选型指南

在前面的Kubernetes知识点中，我们已经了解了Pod之间的互通机制，以及Service（包括ClusterIP和NodePort）是如何完成四层流量转发的。但在现实的业务场景中，还有一个至关重要的问题：基于HTTP/HTTPS的七层流量，是如何根据域名、路径等规则被路由到具体服务的？

这个问题的答案，就落在Ingress与Gateway API这两个核心组件上。

01 为什么Service无法处理七层流量？

Service本质上是一个四层（L4）负载均衡器：

• 它只识别IP地址和端口号。
• 无法理解HTTP协议中的域名、请求路径、请求头等信息。
• 因此，它无法实现以下常见需求：
  • 将 /api 路径的请求转发到后端A服务。
  • 将 /admin 路径的请求转发到后端B服务。
  • 根据访问的域名（如 example.com 或 api.example.com）进行流量分流。

为了解决这些七层路由需求，Kubernetes引入了更高层级的流量入口抽象。

02 Ingress：经典的七层入口方案

Ingress 是什么？

Ingress本身是一组规则声明（一个API资源对象），它定义了外部流量应如何路由到集群内部的服务。Ingress控制器（Ingress Controller）才是实际执行这些规则的组件。

常见的Ingress控制器实现包括：

• Nginx Ingress Controller
• Traefik
• HAProxy
• Kong

Ingress 的核心能力

Ingress主要解决三个问题：

1. 基于域名的路由：将不同域名的请求导向不同的服务。
2. 基于路径的转发：在同一域名下，根据URL路径将请求分发到不同的后端。
3. TLS/SSL终止：在入口处处理HTTPS证书，将解密后的HTTP流量转发至后端服务。

一个简化的流量路径如下：

客户端 (Client) -> Ingress Controller (如Nginx) -> Service -> Pod

Ingress 流量转发详解

以Nginx Ingress为例，当客户端发起一个请求（如https://api.example.com/v1）时：

1. 流量首先到达部署在集群中的Ingress Controller Pod。
2. Controller读取集群中定义的Ingress资源规则，并匹配请求的Host（域名）和Path（路径）。
3. 根据匹配结果，Controller将流量转发到对应的Kubernetes Service。
4. Service再通过kube-proxy设置的网络规则（如iptables/IPVS），将流量负载均衡到后端的Pod。

简单总结：Ingress定义七层路由规则，Service提供四层负载均衡。

03 Ingress的局限性：为何需要演进？

尽管Ingress非常流行，但在大规模、复杂的生产环境中，其设计上的局限性逐渐显现：

• API能力有限：主要围绕HTTP/HTTPS设计，对TCP/UDP等协议的支持依赖厂商扩展，不够统一。
• 扩展性差：高级功能（如认证、超时、重试）严重依赖于各控制器厂商私有的annotation（注解），导致配置碎片化、可移植性差。
• 角色模糊：将流量入口管理、监听器配置、路由规则等多个关注点混在一个资源对象中，不利于多团队协作与精细化管理。

为了解决这些问题，Kubernetes社区推出了新一代的标准——Gateway API。

04 Gateway API：下一代流量管理标准

Gateway API并非Ingress的简单升级，而是一套全新设计的、角色分离的API模型，是未来Kubernetes生态中重要的云原生流量管理标准。

核心思想：关注点分离 (Separation of Concerns)

它将流量管理的职责清晰地划分为三个独立的资源对象：

• GatewayClass：定义一类网关的配置模板（由基础设施提供商实现）。
• Gateway：定义具体的网关实例，负责在特定节点上监听端口（“在哪里监听”）。
• HTTPRoute/TCPRoute：定义具体的路由规则，关联到Gateway和后端Service（“如何路由”）。

这种设计天然支持了多租户场景，例如，平台运维团队管理Gateway（基础设施），而应用开发团队管理HTTPRoute（业务路由）。

Gateway API 的流量路径

客户端 (Client) -> Gateway (监听80/443端口) -> HTTPRoute (路由规则) -> Service -> Pod

05 Ingress vs Gateway API 核心对比

核心结论：

• Ingress：成熟、简单、生态完善，适合大多数以HTTP为主的常规场景，能够快速落地。
• Gateway API：面向未来、设计规范、扩展性强，适合对流量治理有高阶要求、需要多团队协作或混合协议（HTTP+TCP）支持的复杂场景。

06 实战选型建议

何时选择 Ingress？

• 集群规模不大，业务以Web服务（HTTP/HTTPS）为主。
• 追求快速部署和稳定，希望利用成熟的社区方案（如Nginx Ingress）。
• 对高级流量治理功能需求不高，或可通过控制器的注解满足。

何时考虑 Gateway API？

• 集群为多团队、多租户共享，需要清晰的职责边界。
• 业务需要同时管理HTTP和TCP/UDP流量。
• 处于云厂商或Service Mesh（如Istio）环境中，它们已提供良好的Gateway API支持。
• 看重标准的、可移植的配置，避免厂商锁定。

07 与Service/kube-proxy的协同关系复盘

完整的入站流量链路可以清晰地串联起来：

客户端 -> (七层) Ingress / Gateway -> (四层) Service -> (网络实现) kube-proxy (iptables/IPVS) -> Pod

• Ingress / Gateway API：工作在七层，解决 “根据规则转给哪个Service” 的问题。
• Service：工作在四层，解决 “如何负载均衡到一组Pod” 的问题。
• kube-proxy：是Kubernetes网络的实现层，负责维护节点上的转发规则（如iptables/IPVS），真正执行流量到具体Pod的转发。

08 总结

通过本文，你应该能清晰地回答以下三个核心问题：

① 为什么Kubernetes需要Ingress或Gateway API？

因为内置的Service只提供四层（IP+Port）负载均衡，无法理解和处理基于HTTP域名、路径等信息的七层路由需求。

② Ingress控制器实际做了什么？

Ingress资源定义了七层路由规则，而Ingress控制器（如Nginx Ingress）会监听这些规则的变化，并将其转换为负载均衡器（如Nginx）的实际配置，从而执行流量转发。

③ Gateway API为何代表未来方向？

因为它通过角色分离（Gateway, Route等） 的设计，将复杂的入口流量管理标准化、模块化，提供了更好的扩展性、移植性和多团队协作能力，是适应现代云原生架构演进的下一代方案。