K8s Ingress 与 Gateway API：从 nginx-ingress 到新一代网关标准

K8s Ingress 与 Gateway API从 nginx-ingress 到新一代网关标准一、Ingress 的能力天花板为什么需要 Gateway APIKubernetes 的 Ingress 资源是集群内 HTTP 路由的标准入口但它的能力已经无法满足现代云原生应用的需求。Ingress 只支持 HTTP/HTTPS 协议无法路由 TCP/UDP 流量如数据库连接、gRPCIngress 的注解Annotation机制导致每个 Ingress Controller 有自己的扩展语法配置不可移植Ingress 缺乏细粒度的流量控制能力无法实现按请求头、查询参数的精确路由。Gateway API 是 Kubernetes SIG-Network 推出的新一代网关标准通过角色分离集群管理员/集群运维/应用开发者和更丰富的路由语义解决了 Ingress 的核心局限。二、Gateway API 的角色模型与资源层次Gateway API 的核心设计是角色分离不同角色管理不同层次的资源实现关注点分离。flowchart TD A[GatewayClass基础设施管理员] -- B[Gateway集群运维] B -- C[HTTPRoute应用开发者] B -- D[TCPRoute应用开发者] B -- E[GRPCRoute应用开发者] C -- F[路由规则路径/头/参数匹配] C -- G[流量处理重写/重定向/限流] C -- H[后端Service/Pod] subgraph 角色分离 A --- A1[定义网关类型和基础设施] B --- B1[配置网关实例和监听器] C --- C1[定义应用级路由规则] endGatewayClass 定义网关的基础设施类型如公网网关、内网网关由基础设施管理员管理。Gateway 定义具体的网关实例监听端口、TLS 配置由集群运维管理。HTTPRoute/TCPRoute/GRPCRoute 定义应用级路由规则由应用开发者管理。这种分层模型确保了不同角色的权限边界。三、工程化实现3.1 GatewayClass 与 Gateway 定义# GatewayClass基础设施管理员定义 apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: public-gateway spec: controllerName: example.com/gateway-controller description: 公网入口网关支持 HTTP/HTTPS 和 gRPC --- # Gateway集群运维定义 apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: main-gateway namespace: infra spec: gatewayClassName: public-gateway listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: Selector selector: matchLabels: shared-gateway-access: true - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: wildcard-cert namespace: infra allowedRoutes: namespaces: from: All - name: grpc protocol: HTTPS port: 8443 tls: mode: Terminate certificateRefs: - name: wildcard-cert namespace: infra3.2 HTTPRoute应用级路由# HTTPRoute应用开发者定义 apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: api-server-route namespace: production spec: parentRefs: - name: main-gateway namespace: infra hostnames: - api.example.com rules: # 精确路径匹配 - matches: - path: type: PathPrefix value: /v1/users backendRefs: - name: user-service port: 8080 weight: 90 - name: user-service-canary port: 8080 weight: 10 # 请求头匹配灰度路由 - matches: - path: type: PathPrefix value: /v1/orders headers: - type: Exact name: X-Canary value: true backendRefs: - name: order-service-canary port: 8080 # 查询参数匹配 - matches: - path: type: PathPrefix value: /v1/search queryParams: - type: Exact name: version value: 2 backendRefs: - name: search-service-v2 port: 8080 # 重定向规则 - matches: - path: type: Exact value: /old-api filters: - type: RequestRedirect requestRedirect: scheme: https statusCode: 301 hostname: api.example.com path: type: ReplacePrefixMatch replacePrefixMatch: /v13.3 gRPC 路由# GRPCRoutegRPC 服务路由 apiVersion: gateway.networking.k8s.io/v1 kind: GRPCRoute metadata: name: grpc-service-route namespace: production spec: parentRefs: - name: main-gateway namespace: infra sectionName: grpc hostnames: - grpc.example.com rules: - matches: - method: service: order.OrderService method: GetOrder backendRefs: - name: order-grpc-service port: 9000 - matches: - method: service: order.OrderService headers: - type: Exact name: x-env value: canary backendRefs: - name: order-grpc-service-canary port: 90003.4 从 Ingress 迁移到 Gateway API# 原始 Ingress 配置 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: api-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 nginx.ingress.kubernetes.io/canary: true nginx.ingress.kubernetes.io/canary-weight: 10 spec: rules: - host: api.example.com http: paths: - path: /api(/|$)(.*) pathType: Prefix backend: service: name: api-server port: number: 8080 --- # 迁移后的 Gateway API 配置 # 注解变为原生字段可移植性更强 apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: api-server-route spec: parentRefs: - name: main-gateway namespace: infra hostnames: - api.example.com rules: - matches: - path: type: PathPrefix value: /api filters: - type: URLRewrite urlRewrite: path: type: ReplacePrefixMatch replacePrefixMatch: / backendRefs: - name: api-server port: 8080 weight: 90 - name: api-server-canary port: 8080 weight: 10四、Gateway API 的 Trade-offs生态成熟度Gateway API 的 v1 版本于 2023 年发布但并非所有 Ingress Controller 都已完全支持。Envoy Gateway、Istio、Kong 等主流实现的支持程度不一。迁移前需要确认目标 Controller 的兼容性。迁移成本从 Ingress 迁移到 Gateway API 需要重写所有路由配置。对于有数百条 Ingress 规则的大型集群迁移工作量巨大。建议采用渐进式迁移新路由使用 Gateway API存量路由逐步迁移。角色分离的权限管理Gateway API 的角色分离需要配合 RBAC 权限控制。应用开发者只能管理自己 namespace 的 Route但需要引用 infra namespace 的 Gateway。这需要配置 ReferenceGrant 资源允许跨 namespace 引用。多 Gateway 的管理复杂度大型集群可能有多个 Gateway公网、内网、gRPC应用开发者需要知道应该引用哪个 Gateway。建议建立命名规范和文档降低选择成本。五、总结Gateway API 是 Kubernetes 网络入口的下一代标准通过角色分离和更丰富的路由语义解决了 Ingress 的核心局限。落地路线上建议新项目直接使用 Gateway API存量项目制定渐进式迁移计划。关键原则GatewayClass 管基础设施Gateway 管网关实例Route 管应用路由三层分离各司其职。