从 Ingress 到 Gateway：K8s 网络入口的进化史

David爱编程
729 阅读3分钟

引言

你可能在 K8s 中用过 Ingress，也听过新标准 Gateway API，但这两者究竟有啥区别？什么时候该用哪个？到底要不要迁移？

本篇文章带你理清 Kubernetes 网络入口的技术演进脉络，搞懂从 Ingress 到 Gateway API 的设计哲学与实战场景，助你搭建更稳定、灵活的微服务网关体系。

一、什么是 Ingress？

Ingress 是 Kubernetes 提供的标准资源对象，用于通过 HTTP/HTTPS 协议将集群外部请求引入到集群内部的 Service。

它解决了什么问题？

  • 使用 NodePort/LoadBalancer 暴露服务太原始，每个服务都需要配置；
  • Ingress 帮我们集中管理路由、TLS 等访问规则；
  • 由 Ingress Controller 实现流量代理，比如 Nginx、Traefik、HAProxy 等。

一个典型的 Ingress 示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

用户访问 myapp.example.com 会被自动转发到 my-service。

二、Ingress 的局限性

虽然 Ingress 广泛使用，但它也存在不少“成长的烦恼”：

问题描述
控制器不统一每种 Controller 支持的特性不一致，如 Nginx 与 Traefik 参数差异大
自定义能力弱需要通过 annotations 来做扩展，逻辑复杂且容易出错
不支持多协议默认仅支持 HTTP/HTTPS，不支持 TCP、gRPC 等
可观测性差标准 Ingress 难以监控访问日志、指标、健康状况等
生命周期不清晰控制平面与数据面耦合，缺少角色职责分离机制

这些问题在云原生时代变得越来越明显，尤其是在大规模微服务或多租户平台中。

于是，Gateway API 应运而生。

三、Gateway API 是什么？

Gateway API 是 Kubernetes 社区推出的新一代网络入口标准，核心目标是：

解耦流量治理的控制平面与数据平面，实现更清晰的架构与更强的扩展能力。

Gateway API 拥有五种核心资源：

资源类型描述
GatewayClass定义网关控制器的实现，如 NGINX、Istio 等
Gateway表示实际运行的网关实例
HTTPRoute定义 HTTP 路由规则
TCPRoute定义 TCP 路由规则
ReferenceGrant控制跨命名空间访问权限

一个简单的 Gateway + HTTPRoute 示例：

# GatewayClass 定义
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: nginx-gateway
spec:
  controllerName: example.com/nginx-gateway

# Gateway 定义
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: nginx-gateway
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      hostname: "myapp.example.com"

# HTTPRoute 路由定义
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: my-service
          port: 80

是不是有点类似 Ingress + Controller，但更加解耦与灵活？

四、Ingress vs Gateway API 对比

项目IngressGateway API
协议支持HTTP/HTTPSHTTP、HTTPS、TCP、TLS、gRPC 等
扩展性基于 annotation、容易混乱CRD 扩展原生支持，结构清晰
控制平面解耦控制器实现混杂GatewayClass 定义控制器，实现解耦
路由与网关绑定在一起路由与网关分离，便于复用和治理
多租户支持较弱支持跨命名空间管理、权限隔离

可以说 Gateway API 是 Ingress 的现代化重构版本，更适合云原生规模化部署需求。

五、我现在需要迁移到 Gateway API 吗？

这取决于你的场景：

适合继续用 Ingress 的场景适合用 Gateway API 的场景
小规模集群、低并发多团队协作、角色隔离、统一网关治理
已有稳定的 Ingress 配置需支持 TCP/gRPC 等非 HTTP 协议服务
现有生态以 Ingress 为主需要更强大的流量路由与观测能力

目前 Ingress 依旧是 Kubernetes 标准的一部分，无需急着替换，但建议新项目优先考虑 Gateway API。

六、总结与实践建议

✅ Ingress 简洁易用，是过去几年的主流解决方案；

✅ Gateway API 是云原生场景下更现代的服务入口治理标准；

✅ Ingress 更适合中小规模、单团队使用；

✅ Gateway API 更适合复杂团队协作、服务网格、混合协议场景。

如果你正在搭建一个未来可扩展的大型平台，现在就是学习 Gateway API 的最佳时机！

avatar
文章
阅读
粉丝