feat: distribute bazel JKS truststore via squid-ca-cert (Vault)

.gitignore

@@ -4,3 +4,9 @@ test-report.txt
 result.json
 k8s/*.csv
 buildkit/src/
+.metrics-state
+.metrics-baseline
+.metrics-k8s-state
+.metrics-k8s-baseline
+traffic-test/logs
+traffic-test/traffic-gen

README.md

@@ -79,7 +79,7 @@ git clone https://github.com/opensourceways/squid_e2e_tests.git && cd squid_e2e_
 | 01 | HTTP + HTTPS 代理连通(HTTP 200 断言) |
 | 02 | 单 Squid 故障,代理仍返回 200 |
 | 03 | HAProxy 节点故障,VIP 双向漂移,代理仍返回 200 |
-| 04 | HTTPS SSL Bump 缓存,展示首次(MISS)与二次(HIT)耗时对比 |
+| 04 | HTTPS SSL Bump 缓存,**分层指标**: HIT/MISS 延迟分位(p50/p95/p99)+ CPU 两项成本 + 错误分类(用 `scripts/metrics.sh`) |
 | 05 | 下载中 Squid 中断,代理仍返回 200 |
 | 06 | 两台 Squid 同时故障(仅剩 1/3),代理仍返回 200 |
 
@@ -100,13 +100,13 @@ git clone https://github.com/opensourceways/squid_e2e_tests.git && cd squid_e2e_
   ✓ 恢复后代理: HTTP 200
   [02-squid-failover.sh] PASS (24s)
 ...
---- 04-https-cache.sh ---
-  ✓ 首次下载(MISS): HTTP 200
-  首次(MISS): 2.6s  15000000 bytes  5700000 B/s
-  ✓ 二次下载(HIT): HTTP 200
-  二次(HIT):  0.16s  15000000 bytes  95000000 B/s
-  耗时对比: 首次 2.6s → 二次 0.16s
-  [04-https-cache.sh] PASS (5s)
+--- 04-https-cache.sh ---   (分层指标, 用 metrics.sh 框定 MISS/HIT 两个窗口)
+  ✓ 冷取(MISS): HTTP 200
+    MISS  n=1   p50=3638ms   请求命中率 0%    每请求CPU 0.247s  每GB 17.8s
+  ✓ 命中(HIT): HTTP 200
+    HIT   n=30  p50=130 p95=148 p99=149 ms   请求命中率 100%  每请求CPU 0.085s  每GB 6.1s
+    → 缓存价值 = 延迟 28× 提速(3638→130ms); 两次采样看不到 p95/p99 分布与 CPU 成本
+  [04-https-cache.sh] PASS
 ...
 ============================================
   结果: 6 通过 / 0 失败 / 6 总计
@@ -147,6 +147,74 @@ cd buildkit && ./run-tests.sh   # 运行 BuildKit 扩展测试(自动起停 buil
 详见 `buildkit/README.md` 与 `buildkit/DESIGN.md`。依赖 BuildKit
 [PR #1](https://github.com/TommyLike/buildkit/pull/1)（`feature/upstream-proxy-config` 分支）。
 
+## 分层性能指标
+
+`scripts/metrics.sh` 按区间采集分层指标,只依赖已有数据源(各 Squid 的 `access.log`、
+HAProxy stats CSV、cgroup `cpu.stat`),不引入任何新组件:
+
+```bash
+./scripts/metrics.sh baseline  # 零负载时跑一次,测空闲 CPU 基线(可复用)
+./scripts/metrics.sh begin     # 打基线
+<跑你的负载>
+./scripts/metrics.sh end       # 输出这段区间的分层指标
+```
+
+输出四层:**Squid**(请求/字节命中率、省下的回源字节)、**SSL Bump**(bump/splice 隧道数、
+CPU 两项成本)、**HAProxy**(后端分发、健康、检查失败)、**归因**(按客户端的请求数与字节数)。
+
+三个采集上的坑,脚本里已经处理:
+
+- **必须框定区间**。累计值会把预热、健康检查、历史负载混在一起,命中率和 CPU/GB 都没有意义。
+- **健康检查要剔除**。每 3 秒 × 3 后端 × 2 节点,不滤掉会把请求数和命中率彻底冲淡
+  (日志里是 `NONE_NONE/400`、方法为 `-`)。
+- **CONNECT 隧道不是对象请求**。`bump` 的 CONNECT 记录是 `NONE_NONE/200 bytes=0`,
+  只是建隧道,真正的负载会作为解密后的 `GET https://...` 再记一行;混进去会凭空翻倍
+  请求数并稀释命中率。`splice` 则相反,是 `TCP_TUNNEL` 带真实字节且不可能命中。
+
+> **归因层需要 PROXY protocol**。HAProxy 是 TCP 模式转发,默认情况下 Squid 看到的客户端
+> 永远是 HAProxy 节点,按 worker/job 的归因做不出来。脚本会在检测到这种情况时给出提示。
+
+### 关于「命中率」不是唯一指标
+
+合并进来的 K8s 压测数据(`reports/stress-benchmark-20260811.md`)显示:N=120 时
+**纯 HIT 比纯 MISS 更吃 CPU**(199m vs 88m),HIT 反而更慢(104s vs 67s)——
+因为命中要对内容重新做 TLS 加密,而回源只是在等被限速的源站。
+所以只看命中率会得出错误的扩容结论,还必须看 CPU 成本。
+
+### CPU 成本是两项,不是一个「每 GB」常数
+
+CPU 消耗 = **每请求固定成本**(TLS 握手、证书生成、缓存查找)+ **每字节边际成本**(加密、I/O)。
+只报「每 GB CPU」会把固定成本摊进字节里,于是同一套环境下这个数会随对象大小漂移 ——
+实测 14MB 对象约 28 秒/GB,而 58KB–6MB 混合约 37–44 秒/GB,相差 1.6 倍。
+
+容量估算要用两项模型:
+
+```
+核数 ≈ 请求速率 × 每请求CPU + 吞吐(GB/s) × 每GB CPU
+```
+
+要拟合这两项,需要在**不同对象大小/并发**下各跑一个窗口再比较,单个窗口拟合不出来。
+
+另外必须先跑 `metrics.sh baseline`:Squid 零流量时也在烧 CPU(健康检查每 3 秒 × 3 后端 × 2 节点、
+日志写入、缓存索引维护)。窗口越稀疏——比如里面有大量 `docker run` 启动等待——这部分占比越高,
+实测能占到测量值的三分之一。不扣掉会显著高估 CPU 成本,也会让两个窗口之间的比较失去意义。
+
+### K8s 上的同款采集
+
+`k8s/metrics-k8s.sh` 是 metrics.sh 的 K8s 版——**口径完全相同**(健康检查过滤、CONNECT 去重、
+HIER 错误分类、HIT/MISS 延迟分位、CPU 两项成本),只把数据源从 docker+HAProxy 换成
+`kubectl exec`(access.log、cgroup **v1** `cpuacct.usage`)+ `kubectl get endpoints`。
+一键跑 MISS/HIT 两窗口:
+
+```bash
+NS=test-husheng ./k8s/latency-test.sh   # 起 client pod → baseline → MISS 窗口 → HIT 窗口 → 清理
+```
+
+两点与 Compose 侧不同:① 没有 HAProxy/VIP,负载均衡是 Service `sessionAffinity: ClientIP`;
+② **K8s Service 保留客户端源 IP,归因层无需 PROXY protocol 即可用**(Compose 侧 Squid 只看得到
+HAProxy 节点 IP)。实测 HIT p50≈167ms、MISS p50≈1000ms,HIT 每请求 CPU 略高于 MISS
+——与"HIT 需重新加密更吃 CPU"方向一致。
+
 ## 其他部分
 
 | 部分 | 位置 | 说明 |

buildkit/README.md

@@ -18,6 +18,22 @@ Squid HA，完成**代理 + SSL Bump 缓存**。
 预构建镜像已推送，无需自行编译：`tommylike/buildkit-upstream-proxy:latest`
 （自行构建见 `image/README.md`）
 
+## 上游 PR #6996 变体（env 变量式，已端到端验证）
+
+上游社区（gmarmstrong）在 moby/buildkit#6996 用**环境变量**实现了同一能力：
+上游代理从 buildkitd 进程的 `HTTP_PROXY`/`HTTPS_PROXY`/`NO_PROXY` 读取，**无 cert 配置**，
+CA 信任走系统信任库（`SSL_CERT_FILE`）。与上面 fork 方案（`[proxy]` 段 + `upstreamCACert`）
+的差异及端到端验证结果见 **`../reports/buildkit-pr6996-validation-20260813.md`**。
+
+验证资产（与 fork 版并列，互不影响）：
+
+- `buildkitd-6996.toml` —— 无 `[proxy]` 段，仅 `proxyNetwork = true`
+- `docker-compose.6996.yml` —— env 变量式部署（`HTTP(S)_PROXY` + `SSL_CERT_FILE`）
+- 镜像：`tommylike/buildkit-6996:test`（从 `gmarmstrong/buildkit@proxy-chaining` 编译）
+
+关键实测结论：正对照（RUN HTTPS 经 Squid 下载成功）、缓存命中（TCP_HIT 增加）、
+负对照（无 CA → 502）全部符合设计；一次 env 配置同时覆盖 **PULL + RUN** 两个场景。
+
 ## 快速开始
 
 ```bash
@@ -61,8 +77,10 @@ Squid HA (VIP) SSL Bump 解密 → 缓存 → 回源
 buildkit/
 ├── README.md                    ← 本文件
 ├── DESIGN.md                    ← 设计与信任链、权限实证
-├── buildkitd.toml               ← proxyNetwork + [proxy] upstreamURL/CACert
-├── docker-compose.buildkit.yml  ← buildkitd(精简 cap)
+├── buildkitd.toml               ← proxyNetwork + [proxy] upstreamURL/CACert(fork 版)
+├── docker-compose.buildkit.yml  ← buildkitd(精简 cap, fork 版)
+├── buildkitd-6996.toml          ← 上游 #6996 变体(env 变量式, 无 [proxy] 段)
+├── docker-compose.6996.yml      ← 上游 #6996 变体(HTTP(S)_PROXY + SSL_CERT_FILE)
 ├── Dockerfile.test              ← 测试镜像(RUN curl https)
 ├── run-tests.sh                 ← 扩展测试入口(起停 buildkitd + 跑用例)
 ├── image/README.md              ← 如何自行编译镜像

buildkit/buildkitd-6996.toml

@@ -0,0 +1,14 @@
+# buildkitd 配置 —— 基于上游 PR #6996(env 变量式上游代理, 无 [proxy] 段)
+# 上游代理完全由 buildkitd 进程环境变量决定: HTTP_PROXY / HTTPS_PROXY / NO_PROXY
+# CA 信任走系统信任库: 容器里设 SSL_CERT_FILE=/etc/buildkit/squid-ca.pem
+
+# 开启内置 MITM 代理:给 RUN exec 注入 HTTP(S)_PROXY 并注入 CA
+proxyNetwork = true
+
+[worker.oci]
+enabled = true
+# 沙箱网络用 host,确保 RUN 沙箱/代理出向能路由到 Squid VIP(172.30.0.100)
+net = "host"
+
+[worker.containerd]
+enabled = false

buildkit/docker-compose.6996.yml

@@ -0,0 +1,63 @@
+# BuildKit daemon —— 基于上游 PR #6996(env 变量式上游代理)的验证部署
+# 与 docker-compose.buildkit.yml 的区别:
+#   - 镜像: 从 gmarmstrong/buildkit@proxy-chaining 编译
+#   - 上游代理配置从 buildkitd.toml 的 [proxy] 段 → buildkitd 进程环境变量
+#   - CA 信任从 upstreamCACert 显式配置 → 系统信任库(SSL_CERT_FILE)
+#
+# 对照组用法: 把 SSL_CERT_FILE 这行注释掉再 up, HTTPS 下载应因证书校验失败
+# (证明无 cert 配置时, CA 必须预置进系统信任库, 这是 PR #6996 的关键限制)
+
+services:
+  buildkitd:
+    image: tommylike/buildkit-6996:test
+    container_name: buildkitd
+    entrypoint: ["buildkitd", "--addr", "tcp://0.0.0.0:1234", "--config", "/etc/buildkit/buildkitd.toml"]
+    environment:
+      # 上游代理 = Squid HA VIP(PR #6996: 从 buildkitd 环境读取)
+      HTTP_PROXY: "http://172.30.0.100:3128"
+      HTTPS_PROXY: "http://172.30.0.100:3128"
+      http_proxy: "http://172.30.0.100:3128"
+      https_proxy: "http://172.30.0.100:3128"
+      NO_PROXY: "localhost,127.0.0.1,172.30.0.0/24"
+      no_proxy: "localhost,127.0.0.1,172.30.0.0/24"
+      # PR #6996 无 cert 配置 → 信任下沉到系统信任库。Go x509 会读 SSL_CERT_FILE,
+      # 把 Squid SSL-Bump CA 加进内建代理出站连接的系统证书池。
+      # (对照组: 注释此行 → HTTPS 经 bump Squid 应证书校验失败)
+      SSL_CERT_FILE: "/etc/buildkit/squid-ca.pem"
+    cap_drop:
+      - ALL
+    cap_add:
+      - SYS_ADMIN
+      - NET_ADMIN
+      - NET_RAW
+      - SETUID
+      - SETGID
+      - MKNOD
+      - SYS_CHROOT
+      - DAC_OVERRIDE
+      - CHOWN
+      - FOWNER
+      - FSETID
+      - SETPCAP
+      - SETFCAP
+      - KILL
+      - SYS_PTRACE
+      - NET_BIND_SERVICE
+      - AUDIT_WRITE
+    security_opt:
+      - apparmor=unconfined
+      - seccomp=unconfined
+      - systempaths=unconfined
+    cgroup: host
+    networks:
+      squid_net:
+        ipv4_address: 172.30.0.30
+    volumes:
+      - ./buildkitd-6996.toml:/etc/buildkit/buildkitd.toml:ro
+      - ../configs/certs/client-ca.crt:/etc/buildkit/squid-ca.pem:ro
+      - /sys/fs/cgroup:/sys/fs/cgroup:rw
+
+networks:
+  squid_net:
+    external: true
+    name: haproxy_ha_squid_net