Gateway API替代Ingress

Gateway API 核心组件与应用场景详解

Gateway API 是 Kubernetes 社区为标准化服务网络流量管理而设计的下一代 API，相比传统的 Ingress，它提供了更丰富、更灵活的流量控制能力。以下是 Gateway API 的核心组件及其应用场景的详细介绍：

一、Gateway API 核心资源组件

1. GatewayClass（网关类）

作用：定义网关的实现类型，将 Gateway 与特定的控制器（如 Istio、Contour）绑定。
应用层级：集群级资源，由集群管理员创建和管理。
关键字段：
- controllerName：指定实现网关的控制器（如 istio.io/gateway-controller）。

示例：

yaml
 
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: istio
spec:
  controllerName: istio.io/gateway-controller

2. Gateway（网关）

作用：定义流量入口点（如端口、协议、TLS），是实际运行的网关实例。
应用层级：命名空间级资源，通常由平台团队部署。
关键字段：
- gatewayClassName：引用 GatewayClass。
- listeners：定义监听的端口、协议和路由绑定规则。

示例：

yaml
 
 

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  gatewayClassName: istio
  listeners:
    - name: http
      port: 80
      protocol: HTTP

 

3. HTTPRoute/TCPRoute/UDPRoute/TLSRoute（路由规则）

作用：定义具体的流量匹配和转发规则，绑定到 Gateway。
应用层级：命名空间级资源，由应用团队部署。
关键字段：
- parentRefs：引用要绑定的 Gateway。
- matches：定义匹配条件（如路径、Header、方法）。
- backendRefs：指定转发的目标服务。

示例（HTTPRoute）：

yaml
 
 

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bookinfo-route
spec:
  parentRefs:
    - name: bookinfo-gateway
  rules:
    - matches:
        - path: { type: PathPrefix, value: /productpage }
      backendRefs:
        - name: productpage
          port: 9080

 

4. ReferenceGrant（引用授权）

作用：允许跨命名空间的路由引用（如不同命名空间的 Gateway 和 HTTPRoute）。
应用层级：命名空间级资源，用于解决跨命名空间访问的权限问题。

示例：

yaml
 
 

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: ReferenceGrant
metadata:
  name: allow-cross-namespace
  namespace: gateway-ns  # Gateway 所在命名空间
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: apps-ns  # HTTPRoute 所在命名空间
  to:
    - group: ""
      kind: Service

 

二、组件间的关系与工作流程

plaintext
 
客户端请求 → GatewayClass（控制器） → Gateway（监听配置） → HTTPRoute（匹配规则） → Service（后端服务）

集群管理员创建 GatewayClass，指定使用的控制器（如 Istio）。
平台团队部署 Gateway，引用特定的 GatewayClass，并配置监听端口。
应用团队创建 HTTPRoute，绑定到 Gateway，并定义流量转发规则。
可选：如果 HTTPRoute 和 Gateway 不在同一命名空间，需创建 ReferenceGrant 授权。

三、应用场景与最佳实践

1. 基础流量路由

场景：将不同路径的请求转发到不同服务。
配置：使用 HTTPRoute 的 matches 和 backendRefs。

示例：

yaml
 
 

rules:
  - matches:
      - path: { type: PathPrefix, value: /api/v1 }
    backendRefs:
      - name: api-service
        port: 8080
  - matches:
      - path: { type: PathPrefix, value: /web }
    backendRefs:
      - name: web-service
        port: 80

 

2. 流量拆分（A/B 测试、灰度发布）

场景：按比例将流量分发到不同版本的服务。
配置：使用 backendRefs 的 weight 字段。

示例：

yaml
 
 

backendRefs:
  - name: service-v1
    port: 8080
    weight: 90  # 90% 流量到 v1
  - name: service-v2
    port: 8080
    weight: 10  # 10% 流量到 v2

 

3. 基于 Header 的路由

场景：根据请求 Header 分发流量（如用户分组）。
配置：使用 matches.headers。

示例：

yaml
 
 

matches:
  - headers:
      - name: user-group
        value: beta
    path:
      type: PathPrefix
      value: /

 

4. TLS 终止与加密

场景：在网关层处理 HTTPS 请求。
配置：在 Gateway 的 listeners 中添加 TLS 配置。

示例：

yaml
 
 

listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
        - kind: Secret
          name: tls-cert

 

5. 跨命名空间路由

场景：不同命名空间的服务需要通过同一网关暴露。
配置：使用 ReferenceGrant 授权跨命名空间引用。

示例：

yaml
 
 

# 在网关命名空间创建 ReferenceGrant
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: apps-ns
  to:
    - group: ""
      kind: Service

 

四、与传统 Ingress 的对比

特性	Gateway API	传统 Ingress
资源模型	多资源协作（GatewayClass、Gateway、Route）	单一 Ingress 资源
命名空间支持	支持跨命名空间引用（需 ReferenceGrant）	通常限于同一命名空间
路由规则	更丰富（路径、Header、方法、权重）	主要基于路径前缀
协议支持	HTTP、TCP、UDP、TLS	主要 HTTP，TCP 支持有限
流量策略	可扩展（通过 Policy 资源）	有限（依赖控制器特定注解）
API 演进	标准化、版本化设计	碎片化、控制器特定实现

五、生产环境部署建议

权限分离：
- 集群管理员管理 GatewayClass
- 平台团队部署和维护 Gateway
- 应用团队创建和管理 Route
渐进式迁移：
- 在现有 Ingress 基础上逐步引入 Gateway API
- 使用双网关共存进行测试
监控与日志：
- 配置 Gateway API 资源的状态监控
- 收集 Envoy 或其他网关控制器的访问日志
安全加固：
- 限制 Route 只能引用授权的 Service
- 使用 TLS 加密所有外部流量

六、主流实现与支持情况

Istio：从 1.18 版本开始支持 Gateway API，逐步替代自定义资源。
Contour：完全支持 Gateway API。
NGINX：通过 Gateway API 控制器提供支持。
Traefik：开发中，计划支持。

总结

Gateway API 通过分层设计（GatewayClass → Gateway → Route）和更丰富的路由规则，解决了传统 Ingress 的局限性，提供了更灵活、更安全的流量管理方案。它特别适合大型复杂集群、多团队协作的场景，是 Kubernetes 流量管理的未来标准。

k3s集群需手动安装 Gateway API CRD

可以通过以下命令在 K3s 中安装 Gateway API CRD：

bash
 
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

验证安装：

bash
 
kubectl get crd | grep gateway
# 应看到 gatewayclasses、gateways、httproutes 等资源

是的，Gateway API + NGINX Ingress Controller 可以部分替代 Istio 的功能，包括按流量百分比分发（灰度发布）。但两者的定位和能力范围有所不同，需要根据具体需求权衡。

一、功能对比

功能	Gateway API + NGINX	Istio
流量分发	✅ 支持按百分比分发（通过 `weight` 字段）	✅ 更丰富的流量策略（权重、Header、Cookie）
协议支持	✅ HTTP、HTTPS、TCP	✅ 全协议支持（HTTP、TCP、gRPC、MQTT 等）
可观测性	❌ 基础指标（需额外集成 Prometheus）	✅ 内置分布式追踪、指标、日志
安全	✅ TLS 终止、简单认证	✅ mTLS、细粒度访问控制、JWK 验证
服务网格能力	❌ 仅边缘网关功能	✅ 全网状流量管理（内部服务间通信）
API 复杂度	✅ 标准化 API（Gateway API）	❌ 自定义 CRD（学习成本较高）

二、流量百分比分发实现

使用 Gateway API + NGINX 可以通过 HTTPRoute 实现流量百分比分发，示例如下：

yaml
 
 

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: traffic-split
spec:
  parentRefs:
  - name: nginx-gateway  # 引用NGINX Gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: service-v1
      port: 80
      weight: 90  # 90%流量到v1版本
    - name: service-v2
      port: 80
      weight: 10  # 10%流量到v2版本

 

关键点：

weight 字段：控制流量分配比例（总和为 100）。
NGINX 支持：确保使用的 NGINX Ingress Controller 版本支持 Gateway API（如 v1.7+）。
部署方式：需先安装 Gateway API CRD，再部署支持 Gateway API 的 NGINX 控制器。

三、替代场景分析

1. 可以替代的场景

仅需边缘网关功能：如果只需要对外暴露服务，处理外部流量（如 Web 应用入口），不需要管理内部服务间通信。
轻量级部署：Istio 对资源要求较高（需部署多个组件），而 NGINX 更轻量。
标准化优先：Gateway API 是 Kubernetes 社区标准，未来兼容性更好。

2. 不可替代的场景

全网状流量管理：需要管理集群内所有服务间的通信（如微服务间的重试、熔断、负载均衡）。
深度可观测性：需要自动收集服务间调用链路（如 Jaeger 追踪）、细粒度指标。
多集群 / 多协议支持：需要跨集群流量分发或支持非 HTTP 协议（如 gRPC、TCP）。

四、混合方案建议

如果需要部分 Istio 功能（如网格内流量管理），同时希望利用 Gateway API 的标准化，可以采用 混合架构：

边缘网关层：使用 Gateway API + NGINX 处理外部流量。
内部服务层：使用 Istio 管理服务间通信。

这种方案结合了两者的优势，但需要注意：

避免功能重叠导致复杂性增加。
确保两个系统的配置协调一致（如 TLS 证书管理）。

五、总结

Gateway API + NGINX Ingress Controller 可以满足基础的流量百分比分发需求，但如果需要完整的服务网格功能（如内部流量治理、深度可观测性），Istio 仍是更合适的选择。选择时需根据实际需求、团队技术栈和资源限制综合评估。

posted @ 2025-07-08 11:41 呆瓜小贼66 阅读(141) 评论(0) 收藏举报

刷新页面返回顶部

呆瓜小贼66