1. 为什么要在 TaoToken 网关下折腾 traefik 的 WRR如果你正在用 TaoToken 统一管理多个大模型 Key把请求先打到网关再分发到后端那你迟早会遇到一个很实际的问题后端不止一个服务怎么按比例把流量分出去。比如灰度发布时想让新版本只吃 10% 的流量或者两个推理服务一个性能强一个性能弱想让强的多扛一点。这时候 traefik 2.x 的 WRRWeighted Round Robin带权重的轮询就是最顺手的方案。WRR 说白了就是“按权重排队轮着发”。假设 appv1 权重 3、appv2 权重 1那 traefik 每轮发 4 个请求其中 3 个给 appv1、1 个给 appv2。它和普通轮询的区别在于普通轮询是 1:1 平均分WRR 是你说了算。适合谁适合已经在 Kubernetes 里跑 traefik、又需要精细控制流量比例的运维和开发。这篇就把从配置文件到验证的完整链路走一遍四个 yaml 按顺序 apply最后用 curl 数请求次数确认权重生效。我试过把这套用在 TaoToken 的 API 通道后面前端统一走网关后端两个服务按权重接流量调权重不用改代码改个 yaml 重新 apply 就行实测下来比想象中省事。2. TaoToken 前置准备Key、通道与 traefik 的关系在动手写 traefik 配置之前先把 TaoToken 这一层理清楚。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 它的定位是统一 Key 和 API 通道你手上有多个模型供应商的 Key不用在每个项目里各配一套而是通过 TaoToken 收敛成一个入口。API 地址是 https://taotoken.net/api 注意这个不带 UTM 参数直接填就行。那它和 traefik 的 WRR 有什么关系关系在于流量入口的分层。典型链路是客户端请求 → traefik做 WRR 负载均衡→ 后端服务 → 后端再调 TaoToken 的 API 通道。traefik 负责的是“请求该发给哪个后端 Pod”TaoToken 负责的是“后端拿到请求后该用哪个 Key 去调模型”。两者不冲突是上下游。你需要提前准备的东西一个能用的 Kubernetes 集群kubectl 能正常连上。traefik 2.x 已经装好。如果你还没装先按官方 Helm chart 或 manifest 装一遍确认 traefik 的 dashboard 能打开、entryPoints 里有 web80和 websecure443。TaoToken 的 API Key。去控制台生成一个路径是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 生成后到 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 复制出来。这个 Key 后面会配到后端服务的环境变量里不是配到 traefik 里别搞混。注意traefik 的 WRR 只关心后端 Service 的权重它不碰你的模型 Key。Key 是后端服务调 TaoToken 时用的属于应用层。把这两层分开排障时思路会清晰很多。如果你还想先确认模型通道是否通可以到模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 发一条测试消息确认 Key 有效再往下走。3. 可复制配置四个 yaml 按顺序落地 WRR这一节是核心四个文件按 01 到 04 的顺序 apply。每个文件我都贴完整内容你直接复制保存成对应文件名即可。命名沿用 excerpt 里的习惯方便对照。3.1 01-appv1.yaml第一个后端服务这个文件包含一个 Deployment 和一个 Service。镜像用 containous/whoami它会返回请求头信息方便我们验证请求到底打到了哪个 Pod。apiVersion: apps/v1 kind: Deployment metadata: name: appv1 spec: selector: matchLabels: app: appv1 template: metadata: labels: use: test app: appv1 spec: containers: - name: whoami image: containous/whoami ports: - containerPort: 80 name: portv1 --- apiVersion: v1 kind: Service metadata: name: appv1 spec: selector: app: appv1 ports: - name: http port: 80 targetPort: portv1执行kubectl apply -f 01-appv1.yaml3.2 02-appv2.yaml第二个后端服务第二个服务用 nginx:1.8和 appv1 的 whoami 返回内容不同这样 curl 的时候一眼就能看出请求落到了哪个服务。apiVersion: apps/v1 kind: Deployment metadata: name: appv2 spec: selector: matchLabels: app: appv2 template: metadata: labels: use: test app: appv2 spec: containers: - name: nginx image: nginx:1.8 ports: - containerPort: 80 name: portv2 --- apiVersion: v1 kind: Service metadata: name: appv2 spec: selector: app: appv2 ports: - name: http port: 80 targetPort: portv2执行kubectl apply -f 02-appv2.yaml3.3 03-app-ingress-route.yamlIngressRoute 指向 TraefikService注意这里 services 里引用的不是普通 Service而是 kind: TraefikService名字叫 app-wrr。这个 TraefikService 就是 WRR 的载体在第四个文件里定义。apiVersion: traefik.containo.us/v1alpha1 kind: IngressRoute metadata: name: wrringressroute namespace: default spec: entryPoints: - web routes: - match: Host(wrr.duliri.com) kind: Rule services: - name: app-wrr kind: TraefikService执行kubectl apply -f 03-app-ingress-route.yaml3.4 04-wrr.yaml权重声明WRR 的关键这是整篇的重点。weighted.services 下面两个条目appv1 权重 3appv2 权重 1比例就是 3:1。apiVersion: traefik.containo.us/v1alpha1 kind: TraefikService metadata: name: app-wrr spec: weighted: services: - name: appv1 weight: 3 port: 80 kind: Service - name: appv2 weight: 1 port: 80 kind: Service执行kubectl apply -f 04-wrr.yaml四个文件全部 apply 完之后用下面这条命令确认资源都起来了kubectl get deploy,svc,ingressroute,traefikservice你应该能看到 appv1、appv2 两个 Deployment 都是 Running两个 Service 存在IngressRoute 和 TraefikService 也都创建成功。如果 TraefikService 报错多半是 CRD 没装全检查一下 traefik 的 CRD 是否包含 traefikservices.traefik.containo.us。4. 验证请求数一数权重到底生效没有配置写完不算完得用请求验证。分两步先配 hosts再 curl 多次看比例。4.1 配置 hosts 解析找到你的节点 IP假设是 192.168.1.100在本地 hosts 文件里加一行192.168.1.100 wrr.duliri.comWindows 的 hosts 在 C:\Windows\System32\drivers\etc\hostsLinux/macOS 在 /etc/hosts。加完保存。4.2 curl 多次观察分发比例假设 traefik 的 web entryPoint 通过 NodePort 暴露在 30001那请求地址就是 http://wrr.duliri.com:30001。连续请求 8 次for i in $(seq 1 8); do curl -s http://wrr.duliri.com:30001 | head -n 1 echo --- done因为 appv1 是 whoami返回内容里会有 Hostname、IP 等字段appv2 是 nginx返回的是 nginx 欢迎页的 HTML。你数一下 8 次里有多少次是 whoami、多少次是 nginx。按 3:1 的权重理论上 8 次里 6 次 whoami、2 次 nginx。实际会有轻微波动但大样本下比例会收敛到 3:1。如果想更精确请求 40 次并统计for i in $(seq 1 40); do curl -s http://wrr.duliri.com:30001 | grep -o whoami\|nginx | head -n 1 done | sort | uniq -c输出里 whoami 大约 30 次、nginx 大约 10 次就说明 WRR 生效了。4.3 调整权重后复测把 04-wrr.yaml 里 appv1 的 weight 改成 1、appv2 改成 3重新 applykubectl apply -f 04-wrr.yaml等几秒让 traefik 重新加载配置再跑一次 40 次统计。这次应该反过来nginx 大约 30 次、whoami 大约 10 次。如果比例跟着权重变了说明动态调整没问题。4.4 在 dashboard 里看权重traefik 的 dashboard 里能直接看到 TraefikService 的权重配置。打开 dashboard进 HTTP → Services找到 app-wrrkubernetescrd点进去能看到 weighted 下面两个服务的权重值。这个页面适合截图留档也方便排查“为什么流量没按预期分”。5. 本篇常见错排查配置过程中容易踩的坑我列几个高频的。第一个TraefikService 创建失败提示 no matches for kind。这是 CRD 没装。traefik 2.x 的 TraefikService 属于 CRD装 traefik 时要确保 CRD 一起 apply 了。检查命令kubectl get crd | grep traefik如果没有 traefikservices.traefik.containo.us回去补装 CRD。第二个curl 返回 404。多半是 Host 匹配没对上。IngressRoute 里写的是 Host(wrr.duliri.com)你 curl 时用的域名必须完全一致包括大小写。另外确认 hosts 解析指向的是 traefik 所在节点的 IP不是 Pod IP。第三个权重改了但流量没变。traefik 加载动态配置有延迟通常几秒内生效。如果一直不变检查是不是 apply 到了错误的 namespace或者 dashboard 里看的是旧的 TraefikService。用 kubectl get traefikservice app-wrr -o yaml 确认权重值已经更新。第四个请求全部打到同一个服务。检查两个 Service 的 selector 是否和 Deployment 的 labels 匹配。appv1 的 Service selector 是 app: appv1Deployment 的 pod label 也必须是 app: appv1。label 对不上Service 后面没有 Endpointtraefik 自然只能把流量发给有 Endpoint 的那个。第五个端口写错。TraefikService 里每个 service 的 port 是 80对应 Service 的 port不是 targetPort。别把 targetPort 填进去。提示排障时优先看 traefik 的日志kubectl logs 后面跟 traefik 的 Pod 名配置加载错误会直接打出来比猜快得多。6. 把 WRR 接进 TaoToken 通道的下一步traefik 这层 WRR 跑通之后后端服务怎么调 TaoToken 就是应用层的事了。你可以在 appv1 和 appv2 的容器里各配一个环境变量指向 TaoToken 的 API 地址 https://taotoken.net/api Key 用控制台生成的那个。这样前端请求经 traefik 按权重分发到两个后端后端再用统一的 Key 去调模型通道整条链路就闭环了。如果你后面要做长期的编码任务或者 Agent 类应用需要更稳定的通道配额可以了解一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入细节和参数说明在文档里 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到接入报错先去文档翻一遍大部分问题都有对应说明。权重实验本身不复杂难的是把流量分层想清楚traefik 管分发TaoToken 管通道各司其职。改权重就改一个 yaml 重新 apply不用重启服务这个灵活性在灰度场景里很实用。