这类问题我又碰上了一次。Knative Serving 1.13 发布新 revision 后设置 traffic 5% 到 latestRevision,观察两小时新版本 QPS 占比接近 100%,旧 revision 实例数已经缩到零。
第一反应是「旧 revision 被缩容到零后冷启动超时,流量被重试到新版本」,验证下来不成立。
排查方向其实有限,先把可能性排一排。traffic 配置里 latestRevision 与 revisionName 同时存在,前者覆盖后者;路由标签直接指到 latest,客户端访问的是标签地址;流量百分比按请求数算,但监控看的是实例数占比。
先查看 Route 的实际流量分配
kubectl get route app -o jsonpath='{.status.traffic}'
再往下确认两个 revision 的地址与就绪状态
kubectl get revisions -o custom-columns=NAME:.metadata.name,READY:.status.conditions[0].status
然后把流量显式按 revisionName 分配后重发布
kubectl patch route app --type merge -p '{"spec":{"traffic":[{"revisionName":"app-00001","percent":95},{"revisionName":"app-00002","percent":5}]}}'
等前面都确认过,再用两个地址各打 100 次核对比例
for i in $(seq 100); do curl -s http://app/api/ver; done | sort | uniq -c
排查用的命令都是临时敲的,没有写成脚本,事后才整理。
改完先别撤,确认这几项。两个 revision 的请求数比例接近 95 比 5,旧 revision 保持至少一个实例不缩到零。
补一句。latestRevision 是个指针而不是固定版本,和具体的 revisionName 混写时以更宽的那个为准,灰度必须钉死版本名。这类问题最好一次改到位,反复小改反而容易把原因搅混。
