K8s 集群使用 Gateway API + Traefik：为什么我建议从 Ingress 迁过来
#博客更新

最近在整理集群入口层，结论先放前面：

新服务我会优先上 Gateway API + Traefik，老服务按节奏从 Ingress 迁移。

不是说 Ingress 不能用，而是当服务数量和团队规模起来以后，Ingress 在“治理”和“协作边界”上会越来越吃力。

----------------------

Ingress 到底卡在哪里

Ingress 最大的问题不是能力不够，而是抽象太薄：

● 路由、入口、TLS、策略经常混在一起
● 大量依赖 Controller 私有注解，可移植性差
● 多团队协作时，权限边界不够清晰

在小规模阶段这些都还能忍，但一旦进入“多业务线 + 高频变更”，入口层会迅速变成高风险区域。

----------------------

Gateway API 带来的变化（重点是“边界”）

Gateway API 把角色拆开了：

● GatewayClass：网关实现类型（由平台定义）
● Gateway：具体入口实例（监听端口、协议、TLS）
● HTTPRoute/TCPRoute：业务路由规则（业务团队维护）
● ReferenceGrant：跨命名空间引用授权（安全边界）

这种拆法的价值非常实在：

1. 平台和业务职责清晰，不会互相踩配置
2. 路由治理能力更强，后续扩展成本更低
3. 变更可审计，出了问题更容易定位责任边界

----------------------

为什么我用 Traefik 承接 Gateway API

我对 Traefik 的评价是：足够轻、足够稳、足够快落地。

主要是这几条：

● 对 K8s 场景友好，上手成本低
● Gateway API 支持成熟，和 HTTPRoute 结合自然
● 中间件能力实用（限流、重试、Header 处理）
● 可观测体系接起来不费劲

如果团队没有强依赖某个特定网关生态，Traefik 是一个很均衡的选择。

----------------------

最小可运行方案（MVP）

1）安装 Gateway API CRD
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml


2）安装 Traefik 并启用 Gateway Provider
helm repo add traefik https://traefik.github.io/charts
helm repo update

helm upgrade --install traefik traefik/traefik \
  -n traefik --create-namespace \
  --set service.type=LoadBalancer \
  --set providers.kubernetesGateway.enabled=true


3）创建 Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gw-public
  namespace: infra-gateway
spec:
  gatewayClassName: traefik
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"


4）业务接入 HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: app
spec:
  parentRefs:
    - name: gw-public
      namespace: infra-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: app-svc
          port: 8080

----------------------

迁移时最容易踩的坑

我这里列 5 个最常见的：

1. allowedRoutes 配置过宽或过窄，导致路由挂不上或边界失控
2. 跨命名空间引用没配 ReferenceGrant，直接被拒绝
3. TLS Secret namespace 放错，证书加载失败
4. 大事务或慢服务导致灰度阶段误判网关问题
5. 没有统一监控面板，切流时只能靠“感觉”

一句话，入口层迁移不是配置问题，是工程化问题。

----------------------

一条我更推荐的迁移路径

不要硬切，建议分四步：

1. 并行期：Ingress 与 Gateway API 同时存在
2. 试点期：低风险服务先迁
3. 灰度期：核心服务按权重切流
4. 收敛期：验证稳定后下线旧 Ingress 规则

这样做看起来慢一点，但线上风险会小很多。

----------------------

结语

如果你的集群还在 3~5 个服务规模，Ingress 继续用没问题。
但如果你已经进入多团队协作和持续变更阶段，Gateway API 基本是迟早要上的。

我现在的默认策略就是：

新服务直接 Gateway API，老服务分批迁移，Traefik 做统一入口承接。

下一篇我会继续写生产向内容：

《Gateway API + Traefik 生产环境 Checklist（TLS、灰度、限流、可观测、回滚）》

via 棒无
棒无
K8s 集群使用 Gateway API + Traefik：为什么我建议从 Ingress 迁过来 - 棒无
结合真实落地场景聊清楚：Gateway API 到底解决了什么问题、Traefik 为什么适配，以及一套可执行的迁移路径。
 
 
Back to Top