灰度发布 3 个副本 实际只有 1 个走新版本

kubectl get pod -l app=api --show-labels
kubectl describe ingress api-canary | grep -i canary
for i in $(seq 1 100); do curl -s -o /dev/null -w '%{http_code}\n' http://api.example.com/version; done | sort | uniq -c

灰度发布新版本 replicas 设 1，旧版本 3，Service 选中两边后新版本实际只拿到 25% 流量，和预期的 10% 对不上。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。

原因不复杂，按副本数分摊流量只在连接均匀时成立，长连接和 keepalive 会让比例偏离。两个 Deployment 共用同一个 Service 标签时，权重完全由副本数决定。

「灰度副本比例」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。

接口问题先分清是没发出去、发出去了没收到，还是收到了处理失败。偶发问题先统计频率，一小时几次和一天一次，查法完全不同。

处理上按这个顺序：给新旧版本打不同的 version 标签 Service 先只选稳定版；用 Ingress 的 canary-weight 注解控制比例 不靠副本数猜；按请求量而不是连接数观察实际分流；灰度期间把新版本副本调到能承受目标流量的大小。

改完只确认一件事：100 次请求里新版本响应约 10 次 比例和 canary-weight 一致。