fix(acceptance): 隔离控制面抖动与租约瞬态故障
线上 P24 验收暴露出高频 kubectl exec 放大 K3s API 压力、门禁查询挤占关键连接池,以及 PostgreSQL 锁超时被误判为租约所有权丢失。 本次合并验收身份查询、在租约有效期内重试瞬态续期错误、修复人工审核残留 attempt,并增加滚动后 etcd 稳定窗口、节点直连指标和双站独立报告。 验证:Go 全量测试、go vet、聚焦 race、gofmt、迁移安全检查、bash -n、ShellCheck、manual release test。
This commit is contained in:
@@ -110,6 +110,15 @@ API Pod 使用独立发布配置 `AI_GATEWAY_API_DATABASE_MAX_CONNS`,生产同
|
||||
每档依次运行全部五个模拟 Profile 三次。失败时恢复上一个已完整通过的档位,流量保持
|
||||
`validation`,不会自动放开正式请求。
|
||||
|
||||
每次容量配置滚动后不会立即造压测流量。脚本先等待默认 60 秒的控制面稳定窗口,要求三地
|
||||
`readyz/etcd`、CNPG 同步副本和节点内存正常,窗口内没有 API Server handler timeout、
|
||||
etcd peer I/O timeout、WAL receiver timeout 或 CNPG 控制面连接异常;同时按 etcd counter
|
||||
增量计算各节点 backend commit 和 WAL fsync 平均延迟。默认门槛分别为 50 ms 和 15 ms,
|
||||
可通过 `AI_GATEWAY_ACCEPTANCE_POST_ROLLOUT_STABILITY_SECONDS`、
|
||||
`AI_GATEWAY_ACCEPTANCE_ETCD_BACKEND_COMMIT_MAX_MS`、
|
||||
`AI_GATEWAY_ACCEPTANCE_ETCD_WAL_FSYNC_MAX_MS` 调整。最长等待 240 秒仍不稳定时直接阻断,
|
||||
不会把发布滚动造成的控制面抖动与业务容量混在同一次负载里。
|
||||
|
||||
常规容量调整只需修改服务器上的私有发布配置并执行获授权的滚动命令,不要求源码改动或
|
||||
新镜像:
|
||||
|
||||
@@ -142,7 +151,9 @@ PNG 并通过验收 Key 上传到 Gateway。生产快照默认在已部署的 AP
|
||||
压测器,校验 SHA-256 后以 `0600` 临时环境分别运行在宁波、香港宿主机的 K3s 之外;两个
|
||||
进程同时只访问本站 TLS 入口,并按奇偶全局序号分担请求。这样避免本机上行带宽成为容量
|
||||
瓶颈,同时仍覆盖正式 TLS/Nginx 入口。站点报告按请求数相加、耗时取较慢站点、p50/p95/p99
|
||||
取两站较差值进行保守合并。进程、私有环境和远端部分报告在 Run 退出时按精确路径清理。
|
||||
取两站较差值进行保守合并。宁波、香港的脱敏部分报告会分别保存在 Run 目录,远端进程和
|
||||
私有环境在 Run 退出时按精确路径清理。压力采样直接从节点访问 Pod metrics,不再反复创建
|
||||
`kubectl exec` 流,避免验收监控本身放大 K3s API Server 和 etcd 压力。
|
||||
|
||||
```bash
|
||||
scripts/cluster/run-production-acceptance.sh \
|
||||
@@ -166,7 +177,7 @@ scripts/cluster/run-production-acceptance.sh \
|
||||
2. 准备专属验收用户组、身份分片、独立钱包与候选访问规则。
|
||||
3. 部署 digest 固定且仅集群内可访问的协议模拟器。
|
||||
4. 创建 Run、切换 `validation`、等待已有正式任务排空。
|
||||
5. 按 P24、P28、P32 执行三轮负载和 Worker 强杀。
|
||||
5. 每档滚动后先通过控制面稳定窗口,再按 P24、P28、P32 执行三轮负载和 Worker 强杀。
|
||||
6. 执行两条真实小流量请求。
|
||||
7. 校验任务、账务、回调、队列、连接池、RSS、节点内存、数据库同步、六向 WireGuard 和
|
||||
公网健康。
|
||||
|
||||
Reference in New Issue
Block a user