K8s Gateway API + Traefik 实战：生产环境上线 Checklist
#博客更新
上一篇我写了为什么我现在更倾向于在 K8s 里用 Gateway API。
这篇继续，但只讲一件事：怎么把 Gateway API + Traefik 跑到生产可用。
我自己的标准很简单：
● 出问题能快速定位
● 峰值不抖
● 发布可灰度
● 失败可回滚
如果你现在正准备把 Ingress 迁到 Gateway API，下面这份清单基本可以直接套。
----------------------
一、先把职责切开：平台管 Gateway，业务管 Route
Gateway API 最大的价值不是“对象更多”，而是边界更清晰。
我建议默认这么拆：
● 平台团队维护：
● 业务团队维护：
● 跨命名空间引用：必须经过
这样做的好处很现实：
1. 网关入口（监听端口、TLS 入口）不会被业务随手改坏
2. 业务可以自己发版改路由，不必每次找平台改 Ingress
3. 审计链路清楚，后续排障不扯皮
----------------------
二、Traefik 部署层：先做硬化，再谈功能
很多团队一上来就写路由规则，但网关本身还在“默认配置裸奔”。 这在生产里会非常危险。
1）高可用基础项（必须）
●
●
●
2）资源与弹性（必须）
● 给 Traefik 设置
● 配 HPA（CPU + QPS/请求速率）
没有资源边界的网关，一到高峰就会变成“抖动放大器”。
3）滚动升级策略（强烈建议）
●
●
目的只有一个：发布过程不断流。
----------------------
三、Gateway 资源治理：别让 Route 野蛮生长
下面这个点我吃过亏：allowedRoutes 默认放太宽。
建议：
● 生产不要直接
● 通过命名空间标签做白名单
● 对跨命名空间资源引用用
示例（只允许打了
----------------------
四、TLS：最容易“看起来没问题，实际上埋雷”
上线前至少确认这几件事：
● 80 -> 443 强制跳转是否生效
● 证书是否自动续期（建议 cert-manager）
● 证书过期告警是否可触达
● TLS 最低版本策略是否已收敛（建议 1.2+）
常见翻车点：
1. 证书 Secret 放错 namespace，Gateway 引不到
2. SAN 不全，某些子域名握手失败
3. 证书续期成功但网关没及时 reload
这三条任何一条踩中，通常都是线上事故。
----------------------
五、灰度发布：用权重，不用祈祷
Gateway API 的
建议节奏：
示例：
Traefik 侧建议一起配：
● 超时
● 重试
● 限流
灰度不只是“切比例”，而是要把异常流量限制在小范围。
----------------------
六、观测体系：没有观测就别做迁移
我最低配会盯这些指标：
● 网关入口 QPS / RPS
● 2xx / 4xx / 5xx 比例
● P95 / P99 延迟
● 上游错误率、重试率、超时率
● Traefik Pod CPU/内存/重启次数
日志侧建议：
● 访问日志采样（别全量）
● 统一注入 Request ID / Trace ID
● 按 Route 维度聚合错误
你会发现，真正难的不是“配置写出来”，而是出问题时 5 分钟内能不能定位根因。
----------------------
七、安全基线：网关是入口，不是实验场
至少做到：
● 网关命名空间独立 RBAC
● 业务命名空间无权改核心 Gateway
● Traefik 控制面端口仅内网
● 高风险路径加 ACL / WAF / 速率限制
如果你有公网 API，这块不是“优化项”，是上线门槛。
----------------------
八、回滚预案：上线前先演习一次
我现在默认把“回滚演习”放在正式切流前。
标准流程：
1. 保留旧入口配置快照
2. 新入口灰度切流并观察 10~15 分钟
3. 指标超阈值（5xx、P99、超时率）立即回滚权重
4. 必要时切回旧入口
一句话：切过去不算成功，切过去还能秒回才算成功。
----------------------
九、我自己上线前会过的 15 条清单
1. Gateway API CRD 与 Traefik 版本兼容
2. Traefik 已启用 Kubernetes Gateway Provider
3. Traefik 多副本 + 反亲和 + PDB
4. requests/limits/HPA 完整
5. Gateway / Route 命名规范统一
6. allowedRoutes 已收敛到白名单
7. 跨 ns 引用均有 ReferenceGrant
8. HTTPS 强制跳转已验证
9. 证书自动续期与告警可用
10. 灰度权重可调且已演练
11. 超时/重试/限流策略已启用
12. Prometheus + Dashboard 可用
13. 访问日志采样与链路追踪可用
14. 回滚脚本可执行
15. 发布窗口和值班人已确认
----------------------
结尾
如果你在做 Gateway API 迁移，我建议把重点放在三件事：
● 边界：谁能改什么
#博客更新
上一篇我写了为什么我现在更倾向于在 K8s 里用 Gateway API。
这篇继续，但只讲一件事：怎么把 Gateway API + Traefik 跑到生产可用。
我自己的标准很简单：
● 出问题能快速定位
● 峰值不抖
● 发布可灰度
● 失败可回滚
如果你现在正准备把 Ingress 迁到 Gateway API，下面这份清单基本可以直接套。
----------------------
一、先把职责切开：平台管 Gateway，业务管 Route
Gateway API 最大的价值不是“对象更多”，而是边界更清晰。
我建议默认这么拆：
● 平台团队维护：
GatewayClass、Gateway● 业务团队维护：
HTTPRoute● 跨命名空间引用：必须经过
ReferenceGrant这样做的好处很现实：
1. 网关入口（监听端口、TLS 入口）不会被业务随手改坏
2. 业务可以自己发版改路由，不必每次找平台改 Ingress
3. 审计链路清楚，后续排障不扯皮
----------------------
二、Traefik 部署层：先做硬化，再谈功能
很多团队一上来就写路由规则，但网关本身还在“默认配置裸奔”。 这在生产里会非常危险。
1）高可用基础项（必须）
●
replicas >= 2●
podAntiAffinity（副本不要同节点）●
PodDisruptionBudget（升级/维护时不全挂）2）资源与弹性（必须）
● 给 Traefik 设置
requests/limits● 配 HPA（CPU + QPS/请求速率）
没有资源边界的网关，一到高峰就会变成“抖动放大器”。
3）滚动升级策略（强烈建议）
●
maxUnavailable: 0●
maxSurge: 1目的只有一个：发布过程不断流。
----------------------
三、Gateway 资源治理：别让 Route 野蛮生长
下面这个点我吃过亏：allowedRoutes 默认放太宽。
建议：
● 生产不要直接
from: All● 通过命名空间标签做白名单
● 对跨命名空间资源引用用
ReferenceGrant 做显式授权示例（只允许打了
gateway-access=true 的业务命名空间挂路由）：apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gw-public
namespace: infra-gateway
spec:
gatewayClassName: traefik
listeners:
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
- kind: Secret
name: wildcard-example-com
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
gateway-access: "true"
----------------------
四、TLS：最容易“看起来没问题，实际上埋雷”
上线前至少确认这几件事：
● 80 -> 443 强制跳转是否生效
● 证书是否自动续期（建议 cert-manager）
● 证书过期告警是否可触达
● TLS 最低版本策略是否已收敛（建议 1.2+）
常见翻车点：
1. 证书 Secret 放错 namespace，Gateway 引不到
2. SAN 不全，某些子域名握手失败
3. 证书续期成功但网关没及时 reload
这三条任何一条踩中，通常都是线上事故。
----------------------
五、灰度发布：用权重，不用祈祷
Gateway API 的
backendRefs.weight 足够做大多数金丝雀发布。建议节奏：
1% -> 5% -> 20% -> 50% -> 100%示例：
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-v1
port: 8080
weight: 90
- name: app-v2
port: 8080
weight: 10
Traefik 侧建议一起配：
● 超时
● 重试
● 限流
灰度不只是“切比例”，而是要把异常流量限制在小范围。
----------------------
六、观测体系：没有观测就别做迁移
我最低配会盯这些指标：
● 网关入口 QPS / RPS
● 2xx / 4xx / 5xx 比例
● P95 / P99 延迟
● 上游错误率、重试率、超时率
● Traefik Pod CPU/内存/重启次数
日志侧建议：
● 访问日志采样（别全量）
● 统一注入 Request ID / Trace ID
● 按 Route 维度聚合错误
你会发现，真正难的不是“配置写出来”，而是出问题时 5 分钟内能不能定位根因。
----------------------
七、安全基线：网关是入口，不是实验场
至少做到：
● 网关命名空间独立 RBAC
● 业务命名空间无权改核心 Gateway
● Traefik 控制面端口仅内网
● 高风险路径加 ACL / WAF / 速率限制
如果你有公网 API，这块不是“优化项”，是上线门槛。
----------------------
八、回滚预案：上线前先演习一次
我现在默认把“回滚演习”放在正式切流前。
标准流程：
1. 保留旧入口配置快照
2. 新入口灰度切流并观察 10~15 分钟
3. 指标超阈值（5xx、P99、超时率）立即回滚权重
4. 必要时切回旧入口
一句话：切过去不算成功，切过去还能秒回才算成功。
----------------------
九、我自己上线前会过的 15 条清单
1. Gateway API CRD 与 Traefik 版本兼容
2. Traefik 已启用 Kubernetes Gateway Provider
3. Traefik 多副本 + 反亲和 + PDB
4. requests/limits/HPA 完整
5. Gateway / Route 命名规范统一
6. allowedRoutes 已收敛到白名单
7. 跨 ns 引用均有 ReferenceGrant
8. HTTPS 强制跳转已验证
9. 证书自动续期与告警可用
10. 灰度权重可调且已演练
11. 超时/重试/限流策略已启用
12. Prometheus + Dashboard 可用
13. 访问日志采样与链路追踪可用
14. 回滚脚本可执行
15. 发布窗口和值班人已确认
----------------------
结尾
如果你在做 Gateway API 迁移，我建议把重点放在三件事：
● 边界：谁能改什么
