1. 为什么要在 k8s 里做 Traefik 流量复制线上灰度最怕两件事一是新版本逻辑没跑通二是跑通了但没人知道它在真实流量下会不会崩。传统做法是切 5% 流量过去出问题再切回来但这样老版本能看到的请求新版本就看不到了回放和对比都缺样本。Traefik 2.4 的流量复制Traffic Mirroring解决的正是这个痛点主请求照常走老服务同时把一份副本悄悄发给新服务新服务的响应直接丢弃不影响用户但日志、指标、AI 调用全都能被记录下来。我试过在几个 k8s 集群里用这套机制做线上回放最大的感受是「复制比例」和「鉴权一致性」是两个最容易翻车的点。复制比例好理解percent 写 50 就是一半请求进镜像鉴权一致性则常被忽略——镜像流量里的 AI 调用如果还用老 Key或者每个服务各配一套 Key日志里根本对不上号。这时候用 TaoToken 的统一 Key 通道就顺理成章了主服务和镜像服务共用同一个 API 入口和 Key复制出来的请求在鉴权层面完全等价比对才有意义。这篇面向的是已经在跑 k8s、想用 Traefik 做灰度或回放的工程师。你需要对 IngressRoute、Middleware 这些 CRD 有基本概念知道 kubectl apply 怎么用。全文会给出可直接复制的 TraefikService 和 IngressRoute 片段配 kubectl 验证动作最后用请求计数和日志比对确认复制真的生效。TaoToken 在这里的角色是「统一鉴权层」不是替代 Traefik也不是替代你的业务服务它只负责让镜像流量里的 AI 调用有一致的 Key 和 Base URL。先说清楚 Traefik 流量复制的本质它在反向代理层做请求克隆主请求走原路副本请求走 mirrors 里定义的服务。副本请求的 Host、Path、Header 默认和主请求一致但响应不会返回给客户端。这意味着镜像服务必须能独立处理这些请求不能依赖主请求的上下文。对于 AI 调用来说镜像服务拿到的请求体里如果有模型名、prompt它需要自己带着 Key 去调 TaoToken 的 API而不是复用主服务的连接。所以统一 Key 的意义在于主服务和镜像服务配置同一个TAOTOKEN_API_KEY和https://taotoken.net/api复制出来的请求在鉴权上零差异。还有一个细节Traefik 2.4 的 mirroring 是「异步复制」副本请求的失败不会影响主请求。这既是优点也是坑——如果镜像服务的 AI 调用因为 Key 不对返回 401主请求完全无感你只能通过镜像服务的日志发现。所以验证环节必须看镜像 Pod 的日志而不是看客户端响应。下面从环境准备开始一步步把配置落地。2. TaoToken 统一 Key 的前置准备在写 Traefik CRD 之前先把鉴权层理清楚。镜像流量里的 AI 调用要有一致的 Key最省事的做法是让主服务和镜像服务都从同一个环境变量读 Key而这个 Key 来自 TaoToken 的控制台。TaoToken 的定位是统一 API 通道你可以在一个地方管理 Key然后让 k8s 里的多个 Deployment 共用。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时别写错。具体操作上你需要先拿到一个可用的 Key。登录后进控制台在 API Keys 页面创建一个新 Key复制出来。这个 Key 后面会以 Secret 的形式注入到主服务和镜像服务的 Pod 里。为什么不用 ConfigMap因为 Key 是敏感信息Secret 至少做了 base64 编码配合 RBAC 能限制读取范围。创建 Secret 的命令如下把sk-你的实际Key替换成真实值kubectl create secret generic taotoken-key \ --from-literalTAOTOKEN_API_KEYsk-你的实际Key \ -n default创建完可以用kubectl get secret taotoken-key -o yaml确认但注意别把输出贴到公开地方。接下来在 Deployment 里引用这个 Secret主服务和镜像服务用同一份。下面是一个简化的 Deployment 片段关键是env部分apiVersion: apps/v1 kind: Deployment metadata: name: ai-app-v1 namespace: default spec: replicas: 1 selector: matchLabels: app: ai-app version: v1 template: metadata: labels: app: ai-app version: v1 spec: containers: - name: app image: your-registry/ai-app:v1 env: - name: TAOTOKEN_API_KEY valueFrom: secretKeyRef: name: taotoken-key key: TAOTOKEN_API_KEY - name: TAOTOKEN_BASE_URL value: https://taotoken.net/api ports: - containerPort: 80镜像服务ai-app-v2的 Deployment 除了 image 和 version 标签不同env 部分完全一样。这样复制出来的请求进到 v2 时它拿到的 Key 和 Base URL 与 v1 一致AI 调用不会因为鉴权差异产生噪音。如果你用的是 Claude Code 或 Cline 这类工具做本地调试也可以在 settings 里配同样的 Base URL 和 Key但生产环境还是走 Secret 更稳妥。这里有个容易忽略的点TaoToken 的 Key 如果设置了额度或速率限制镜像流量会额外消耗一份配额。比如主服务每秒 10 个请求复制 50% 就是每秒多 5 个总调用量变成 15。所以上线前要确认 Key 的配额够用或者在 TaoToken 控制台里给这个 Key 单独提额。另外镜像服务的 AI 调用如果失败Traefik 不会重试也不会影响主请求但日志里会留下 401 或 429这正是我们后面排查的依据。前置准备做完后你应该有一个可用的 TaoToken Key、一个名为taotoken-key的 Secret、两个 Deploymentv1 和 v2都挂载了同一个 Secret。接下来才是 Traefik 的 CRD 配置。顺序别反先有鉴权层再配流量复制否则镜像服务起来后调 AI 全是 401你会以为是 Traefik 配错了。3. 可复制的 TraefikService 与 IngressRoute 配置Traefik 2.4 的流量复制靠两个 CRD 配合TraefikService 定义镜像规则IngressRoute 定义入口和路由。先确认你的集群里已经装了 Traefik 的 CRD可以用kubectl get crd | grep traefik检查应该能看到traefikservices.traefik.containo.us和ingressroutes.traefik.containo.us。如果没有需要先安装 Traefik 2.4 的 CRD 和控制器这部分不在本文展开假设你已经有一个可用的 Traefik 2.4 环境。第一个 CRD 是 TraefikService它负责把请求分发给主服务和镜像服务。下面这段可以直接复制注意name和port要和你实际的 Service 对上apiVersion: traefik.containo.us/v1alpha1 kind: TraefikService metadata: name: app-mirror namespace: default spec: mirroring: name: ai-app-v1 port: 80 mirrors: - name: ai-app-v2 percent: 50 port: 80这里mirroring.name是主服务100% 的请求走它mirrors里的ai-app-v2是镜像服务percent: 50表示复制 50% 的请求过去。percent 可以调灰度初期建议 10 或 20稳定后再往上加。注意name填的是 k8s Service 的名字不是 Deployment 的名字所以你需要先创建两个 ServiceapiVersion: v1 kind: Service metadata: name: ai-app-v1 namespace: default spec: selector: app: ai-app version: v1 ports: - port: 80 targetPort: 80 --- apiVersion: v1 kind: Service metadata: name: ai-app-v2 namespace: default spec: selector: app: ai-app version: v2 ports: - port: 80 targetPort: 80第二个 CRD 是 IngressRoute它把域名和 TraefikService 绑起来。下面这段的match用Host(\mirror.test.com)你可以换成自己的测试域名apiVersion: traefik.containo.us/v1alpha1 kind: IngressRoute metadata: name: mirror-ingress-route namespace: default spec: entryPoints: - web routes: - match: Host(mirror.test.com) kind: Rule services: - name: app-mirror kind: TraefikService注意services里的kind: TraefikService这表示流量先经过 TraefikService 的镜像逻辑而不是直接打到普通 Service。如果你写成默认的 Service镜像就不会生效。apply 的顺序也有讲究先 apply 两个 Service再 apply TraefikService最后 apply IngressRoute。用一条命令批量 applykubectl apply -f services.yaml kubectl apply -f traefikservice.yaml kubectl apply -f ingressroute.yamlapply 完之后用kubectl get traefikservice app-mirror -o yaml和kubectl get ingressroute mirror-ingress-route -o yaml确认状态。如果 Traefik 的 dashboard 开着可以在 HTTP 路由页面看到mirror.test.com这条规则点进去能看到它指向app-mirror。这一步如果报错最常见的是 CRD 版本不对——Traefik 2.4 用的是traefik.containo.us/v1alpha12.5 之后改成了traefik.io/v1alpha1版本不匹配会提示no matches for kind。配置里还有一个隐藏参数mirroring下面可以加healthCheck但 2.4 的 mirroring 对 healthCheck 支持有限建议先不加等复制跑通再考虑。另外percent是整数写 50 就是 50%写 100 就是全量复制调试阶段可以临时写 100 方便看日志但生产环境别这么干配额和日志量都会翻倍。4. 验证请求复制是否生效配置 apply 完接下来要证明复制真的发生了。最直接的办法是看两个 Pod 的日志计数。先确认 Pod 在跑kubectl get pods -l appai-app -o wide你应该看到 v1 和 v2 各至少一个 Pod。然后开两个终端分别 tail 两个 Pod 的日志。假设 v1 的 Pod 叫ai-app-v1-xxxxv2 的叫ai-app-v2-yyyykubectl logs -f ai-app-v1-xxxx kubectl logs -f ai-app-v2-yyyy接着在本地配 hosts把mirror.test.com指向 Traefik 的入口 IP。如果是 minikube用minikube ip拿 IP如果是云上 LB用 LB 的地址。配好后用 curl 发请求curl -H Host: mirror.test.com http://traefik-ip/api/chat连续发 4 次观察两个终端的日志。按percent: 50的配置v1 应该记录 4 次v2 大约记录 2 次。注意是「大约」因为 50% 是概率复制4 次里可能复制 1 次也可能 3 次样本越大越接近 50%。如果你想精确验证可以临时把 percent 改成 100发 4 次v2 应该记录 4 次确认链路通了再改回 50。除了日志还可以用 Traefik 的 metrics 验证。如果 Traefik 开了 Prometheus可以查traefik_service_requests_total这个指标按 service 分组能看到ai-app-v1和ai-app-v2的请求数。命令类似kubectl port-forward -n traefik svc/traefik-metrics 8080:8080 curl http://localhost:8080/metrics | grep traefik_service_requests_total输出里会有servicedefault-ai-app-v1-80和servicedefault-ai-app-v2-80两条对比它们的值就能算出实际复制比例。这个方法比数日志更准因为日志可能被采样或轮转。还有一个验证点是 AI 调用的鉴权一致性。在 v2 的日志里搜TAOTOKEN或401如果看到 401说明镜像服务没读到正确的 Key回去检查 Secret 挂载和 env 引用。如果看到 200 且响应体里有模型返回说明 TaoToken 的 Key 在镜像流量里也生效了。这一步很关键因为 Traefik 的复制是透明的AI 调用失败不会体现在客户端只能靠镜像服务自己的日志暴露。实测下来最容易出问题的是 Service 的 selector 写错导致 v2 的 Service 选不到 Pod复制过去的请求全部 503。用kubectl get endpoints ai-app-v2确认 endpoints 里有 Pod IP如果是空的检查 Deployment 的 labels 和 Service 的 selector 是否匹配。另外 Traefik 的 entryPoints 要确认web存在如果 Traefik 只开了websecureIngressRoute 里的web会不生效请求直接 404。5. 常见报错与排查对照镜像流量跑起来后报错往往不在 Traefik 本身而在鉴权或服务发现。下面列几个我踩过的坑对照真实报错给排查路径。第一个是401 Unauthorized出现在镜像服务的日志里。这通常意味着 v2 的 Pod 没拿到正确的 TaoToken Key。排查步骤先kubectl exec进 v2 的 Pod执行env | grep TAOTOKEN看TAOTOKEN_API_KEY是否存在且值正确。如果为空检查 Deployment 的env里secretKeyRef的 name 和 key 是否和 Secret 一致。如果值不对可能是 Secret 创建时写错了用kubectl get secret taotoken-key -o jsonpath{.data.TAOTOKEN_API_KEY} | base64 -d解码确认。注意别在共享终端里直接解码Key 会暴露。第二个是local proxy failed或connection refused出现在 Traefik 的日志里。这通常是 TraefikService 里引用的 Service 名字或端口不对。用kubectl get svc确认ai-app-v1和ai-app-v2存在且 port 是 80。如果 Service 的 port 是 8080TraefikService 里写 80 就会连不上。另外检查 Service 的targetPort是否和 Pod 的containerPort一致不一致的话 endpoints 会是空的。第三个是reading choices相关的错误出现在 AI 调用的响应解析里。这个报错说明请求到了 TaoToken 但返回体格式不对常见原因是 Base URL 写成了https://taotoken.net/api/带尾斜杠或者模型名拼错。检查 v2 的TAOTOKEN_BASE_URL是否为https://taotoken.net/api不带尾斜杠。模型名要和 TaoToken 文档里的一致别自己造。第四个是OAuth或invalid token如果你用的是 Claude Code 或 Cline 这类工具做本地回放可能会遇到。这类工具通常有自己的 settings 文件需要同时配 Base URL、Key 和 Model ID 三件套。以 Cline 的 MCP 配置为例settings 里要有{ mcpServers: { taotoken: { url: https://taotoken.net/api, apiKey: sk-你的实际Key, model: claude-3-5-sonnet } } }如果是 Codex 的auth.json结构类似关键是base_url和api_key两个字段。配错任何一个都会导致 OAuth 失败。注意这些本地配置只用于调试生产环境的镜像流量还是走 k8s Secret。第五个是复制比例不对比如配了 50% 但 v2 日志里只有 10%。先确认 percent 是整数Traefik 2.4 不支持小数。然后看请求量如果总共只发了 4 次50% 复制 1 到 3 次都正常样本太小。发 100 次再看应该接近 50。如果偏差很大检查是否有多个 TraefikService 或 IngressRoute 冲突用kubectl get ingressroute -A看有没有重复的 Host 规则。排查时有个通用技巧把 Traefik 的日志级别调到 DEBUG在traefik.yaml里加log.level: DEBUG然后kubectl logs -f看 Traefik 的决策过程。DEBUG 日志里会打印每条请求走了哪个 service、是否触发 mirror非常直观。调完记得改回 INFO不然日志量很大。6. 把统一 Key 接入你的镜像流量配置跑通、报错排完最后一步是把 TaoToken 的统一 Key 正式接入镜像流量。前面用的是 Secret 挂载生产环境建议再加一层用 TaoToken 的 API Keys 页面给这个 Key 设置独立的配额和告警这样镜像流量的额外消耗不会影响主服务。入口在 https://taotoken.net/api-keys 进去后找到你创建的那个 Key设置每日限额和速率限制。如果镜像流量只是临时回放可以设一个较低的限额跑完就删。对于长期做灰度或 Agent 回放的场景可以考虑 TaoToken 的 Coding Plan它更适合持续性的编码和 Agent 调用配额和计费方式对镜像流量更友好。入口在 https://taotoken.net/coding-plan 。如果你的镜像流量里主要是模型对话验证用模型对话页面调试单次请求更方便地址是 https://taotoken.net/model-chat 。控制台总览在 https://taotoken.net/console 接入文档在 https://taotoken.net/doc API Keys 管理在 https://taotoken.net/api-keys 。这些入口按需用别一股脑全配一遍。回到 k8s 侧镜像流量稳定后你可以把 percent 从 50 逐步调到 100做全量回放。全量回放时注意 v2 的副本数要跟上否则镜像请求会排队。用 HPA 根据 CPU 或自定义指标扩 v2 的副本但别让 HPA 影响 v1两个 Deployment 分开配。另外镜像流量的日志建议单独收集比如给 v2 的 Pod 打上mirror: true标签日志采集器按标签分流这样比对时不会和主服务日志混在一起。最后说一个实际经验镜像流量里的 AI 调用如果涉及流式响应Traefik 的复制可能会把流式请求也复制过去但副本的流式响应会被丢弃。这本身没问题但镜像服务的连接数会翻倍如果 TaoToken 的 Key 有并发限制可能会触发 429。解决办法是在 TaoToken 控制台给这个 Key 提高并发上限或者在 TraefikService 里把 percent 调低控制复制量。验证并发是否够用可以看 v2 日志里有没有 429有的话就调。整套流程走下来核心就三件事TraefikService 定义镜像规则、IngressRoute 绑定入口、TaoToken 统一 Key 保证鉴权一致。配置片段可以直接复制验证靠日志计数和 metrics排错对照 401、local proxy failed、reading choices、OAuth 这几个高频报错。做完这些你的 k8s 集群就有了一个可灰度、可回放、鉴权统一的流量复制通道。