feat: add git mirror proxy benchmark stage

This commit is contained in:
Codex
2026-06-27 02:23:46 +00:00
parent 1114517e98
commit cb99ad969b
5 changed files with 94 additions and 24 deletions
+7 -7
View File
@@ -1,6 +1,6 @@
---
name: unidesk-ops
description: UniDesk 手动运维 CLI — `server``gc`、PK01 `platform-db postgres`、platform-infra egress proxy 和 k3s dependency proxy benchmark 运维。覆盖主 server 启停、健康检查、swap、日志、Docker 镜像清理、磁盘 GC、服务重建/重启、PK01 host PostgreSQL、D601/D518 proxyserver 视角流量测速和 k3s 真实依赖拉取 benchmark。用户提到 server start、server status、server swap、server rebuild、server restart、gc、磁盘清理、platform-db、PK01 PostgreSQL、egress-proxy traffic、proxy 测速、k3s benchmark、apk/npm/go 拉取测速时使用。
description: UniDesk 手动运维 CLI — `server``gc`、PK01 `platform-db postgres`、platform-infra egress proxy 和 k3s dependency proxy benchmark 运维。覆盖主 server 启停、健康检查、swap、日志、Docker 镜像清理、磁盘 GC、服务重建/重启、PK01 host PostgreSQL、D601/D518 proxyserver 视角流量测速和 k3s 真实依赖拉取 benchmark。用户提到 server start、server status、server swap、server rebuild、server restart、gc、磁盘清理、platform-db、PK01 PostgreSQL、egress-proxy traffic、proxy 测速、k3s benchmark、apk/npm/go/git mirror 拉取测速时使用。
---
# UniDesk Ops
@@ -24,7 +24,7 @@ bun scripts/cli.ts platform-infra egress-proxy k3s-build-benchmark --targets D60
## K3s Dependency Proxy Benchmark
用于验证 k3s CI/CD 构建出网性能时,必须用真实远程依赖,不用 Cloudflare synthetic。标准 profile 是 `real-deps-500m`k3s 远程拉 `alpine:3.20``node:22-bookworm``golang:1.24-bookworm`,然后在 Pod 内跑 `apk add``npm install``go mod download`proxyserver 视角累计/窗口流量至少要能支撑 500MiB+ 验收。
用于验证 k3s CI/CD 构建出网性能时,必须用真实远程依赖,不用 Cloudflare synthetic。标准 profile 是 `real-deps-500m`k3s 远程拉 `alpine:3.20``node:22-bookworm``golang:1.24-bookworm`,然后在 Pod 内跑 `apk add``npm install``go mod download``git clone --mirror``remote update --prune`proxyserver 视角累计/窗口流量至少要能支撑 500MiB+ 验收。
```bash
# 计划预览:确认 D601/D518、镜像、pull policy、最小 proxy 流量和依赖集合。
@@ -35,11 +35,11 @@ bun scripts/cli.ts platform-infra egress-proxy k3s-build-benchmark \
bun scripts/cli.ts platform-infra egress-proxy k3s-build-benchmark \
--targets D601,D518 --profile real-deps-500m --confirm
# 状态表:看 APK/NPM/GO/REAL_DEPS、failure family 和 proxyserver 采样。
# 状态表:看 APK/NPM/GO/GIT_MIRROR/REAL_DEPS、failure family 和 proxyserver 采样。
bun scripts/cli.ts platform-infra egress-proxy k3s-build-benchmark status \
--targets D601,D518 --profile real-deps-500m --traffic-sample-seconds 15
# 日志 drill-down:按 init container 展开 image pull、apk、npm、go 阶段尾部。
# 日志 drill-down:按 init container 展开 image pull、apk、npm、go、git mirror 阶段尾部。
bun scripts/cli.ts platform-infra egress-proxy k3s-build-benchmark logs \
--targets D601,D518 --profile real-deps-500m --tail-lines 160
@@ -52,7 +52,7 @@ bun scripts/cli.ts platform-infra egress-proxy k3s-build-benchmark cleanup \
--targets D601,D518 --profile real-deps-500m --confirm
```
D601/D518 结果必须分表记录:`STATE`、Job/run、duration、`APK/NPM/GO/REAL_DEPS``TRAFFIC_WINDOW``TRAFFIC_RATE``PROXY_CUM``TOP_CLIENT``TOP_DEST``FAILURE`。D518 通过不代表 D601 通过;D601 只证明 k3s/containerd 走到 proxy 也不等于性能达标。未完成 500MiB+ 的真实 k3s image pull + apk/npm/go 测试前,不关闭对应 issue,不合并标记为等待运行面验收的 PR。
D601/D518 结果必须分表记录:`STATE`、Job/run、duration、`APK/NPM/GO/GIT_MIRROR/REAL_DEPS``TRAFFIC_WINDOW``TRAFFIC_RATE``PROXY_CUM``TOP_CLIENT``TOP_DEST``FAILURE`。D518 通过不代表 D601 通过;D601 只证明 k3s/containerd 走到 proxy 也不等于性能达标。未完成 500MiB+ 的真实 k3s image pull + apk/npm/go/git mirror 测试前,不关闭对应 issue,不合并标记为等待运行面验收的 PR。
## Egress Proxy 运行面修复入口
@@ -69,8 +69,8 @@ D601 若需要让 `sub2api-egress-proxy` 绕开 pod overlay,可在 YAML 中显
常见判读:
- `TOP_CLIENT=10.42.0.1``TOP_DEST=registry-1.docker.io:443`k3s/containerd image pull 已从 proxyserver 视角可见。
- `TOP_DEST=dl-cdn.alpinelinux.org:443`Pod 内 `apk` 阶段已走 proxy。
- `registry.npmjs.org:443``proxy.golang.org:443`:分别对应 `npm install`Go module 拉取。
- `image-pull` failure 表示还卡在 kubelet/containerd 拉镜像;`apk-download``npm-download``go-download` 分别表示 Pod 内依赖阶段失败。
- `registry.npmjs.org:443``proxy.golang.org:443``github.com:443`:分别对应 `npm install`Go module 拉取和 Git mirror clone/sync
- `image-pull` failure 表示还卡在 kubelet/containerd 拉镜像;`apk-download``npm-download``go-download``git-mirror` 分别表示 Pod 内依赖阶段失败。
- proxy 窗口 `0 B/s` 但 active cumulative 增长很慢时,按性能不达标处理;先清理 Job,再继续查上游,不要让慢速 benchmark 长时间占用资源。
## P0 边界