企业官网建设流程全解析

minikube time-to-k8s 每日基准：Daily Benchmark 图表体系与自动化实现解析

【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube

本文聚焦 minikube 项目文档中的 Daily Benchmark 页面，讲解其背后的 time-to-k8s 基准测试：它度量"从执行启动命令到 Kubernetes 集群完全可用"的耗时，并每日针对最新开发版（HEAD）自动运行、生成趋势图表。读完本文，你将理解 4 种 driver/runtime 组合的测试矩阵、每日/每周图表的自动化产出链路，以及各阶段指标（Command Exec、DNS Answering 等）的精确含义与计算方式，并掌握如何在本地复现这套基准。

从零到 Kubernetes：time-to-k8s 基准测试要度量什么

time-to-k8s（T2K）是 minikube 社区用于回答一个朴素问题的基准：从敲下minikube start开始，到 Kubernetes 集群真正可用（示例应用能运行、DNS 能应答），一共需要多少秒？

该基准将全过程拆分为 6 个可独立计时的阶段，这一阶段定义可以在 chart.go 的源码中直接看到：

除耗时外，基准还会记录CPU Utilization(%)与CPU Time(seconds)两个资源指标（见 cpu.go）。

Daily Benchmark 页面的描述明确指出，这一系列图表用于"可视化每日针对 HEAD（最新开发版）的 time-to-k8s 基准"，即：每次基准都以仓库最新代码构建的 minikube 二进制为被测对象，因此图表能反映性能随每日提交的演化趋势，属于 minikube 的持续性能回归监控手段。

Daily Benchmark 页面：四种 driver/runtime 组合

Daily Benchmark 页面本身是一个图表展示页，包含 4 张趋势图，覆盖驱动（driver）与容器运行时（container runtime）的交叉组合：

1. Docker driver - Docker runtime：以 Docker 作为虚拟机驱动，容器运行时使用 Docker
2. Docker driver - containerd runtime：Docker 驱动 + containerd 运行时
3. VirtualBox driver - Docker runtime：VirtualBox 驱动 + Docker 运行时
4. VirtualBox driver - containerd runtime：VirtualBox 驱动 + containerd 运行时

这 4 种组合不是随意挑选的，仓库中对应存放了 4 份可执行的基准配置，位于 hack/benchmark/time-to-k8s/public-chart/，每份配置都声明了被测工具的启动与清理命令，例如：

• docker-docker-benchmark.yaml：

  testcases: minikube: setup: minikube start --driver=docker --container-runtime=docker --memory=max --cpus=max teardown: minikube delete

• docker-containerd-benchmark.yaml：--driver=docker --container-runtime=containerd
• virtualbox-docker-benchmark.yaml：--driver=virtualbox --container-runtime=docker
• virtualbox-containerd-benchmark.yaml：--driver=virtualbox --container-runtime=containerd

可以看到，被测的 minikube 统一以--memory=max --cpus=max请求最大资源配置，以尽量排除资源瓶颈、反映软件本身的启动链路性能；测试结束统一执行minikube delete清理环境。

关于基准机器规格：原文档指出基准运行在GitHub Actions 标准托管 runner（standard GitHub-hosted runners for public repositories）之上，其具体 CPU/内存/磁盘规格以 GitHub Actions 官方文档为准。这意味着图表中的绝对秒数带有特定机器规格前提，跨硬件对比时应谨慎；同一张图内的纵向趋势（同一规格机器上的逐日变化）才具有直接的回归参考价值。

页面中的每日图与每周平均图（对应 weekly_benchmark.md 展示的周均值）均由自动化管线生成并托管，下面剖析这条链路。

自动化管线：public-chart.sh 如何产出每日图表

每日基准不是手工执行的，而是由 public-chart.sh 脚本驱动的完整流水线，其执行流程如下：

1. 拉取历史数据：从s3://time-to-k8s桶下载历史累计结果$DRIVER-$RUNTIME-runs.json到本地runs.json，用于与当日结果拼接成趋势；
2. 构建被测对象：调用make从当前仓库 HEAD 构建 minikube 二进制，并安装到/usr/local/bin/minikube；
3. 运行基准：进入基准工具目录hack/benchmark/time-to-k8s/time-to-k8s-repo/（一个 git submodule），执行git submodule update --init初始化后，以对应组合的配置运行：

   go run . --config "../public-chart/$DRIVER-$RUNTIME-benchmark.yaml" --iterations 10 --output ./output.csv

   每次基准连续迭代 10 次并输出为 CSV；

4. 生成图表：调用 generate-chart.go 同时产出当日图与周均图：

   go run ./hack/benchmark/time-to-k8s/public-chart/generate-chart.go \ --csv ./hack/benchmark/time-to-k8s/time-to-k8s-repo/output.csv \ --daily-chart ./daily-chart.png --weekly-chart ./weekly-chart.png \ --past-runs ./runs.json

5. 回传结果：用aws s3 cp将更新后的runs.json、当日快照 JSON（文件名带%Y-%m-%d日期前缀）、每日图与每周图分别上传回 S3 桶；
6. 清理：删除本地的runs.json、output.csv及两张临时图表。

脚本接收两个参数：DRIVER（docker / virtualbox）与RUNTIME（docker / containerd），即页面上的 4 种组合各自独立跑一遍该流水线，最终在 S3 上形成 4 套*-chart.png与*-weekly-chart.png文件，正是 Daily Benchmark 页面中 4 张图的来源。由此可以看出：页面上每个小节的图表背后，都是一条"构建 HEAD → 10 次迭代基准 → 生成图表 → 归档结果"的完整 CI 任务。

图表生成原理：generate-chart.go 源码解析

generate-chart.go 负责把 CSV 与历史 JSON 加工成趋势图，其内部机制值得细看。

单日基准的汇总计算

readInLatestBenchmark读取最新一次基准的 CSV：跳过表头（name行）后，依次取每行的第 8～13 列与第 16 列，对应 6 个耗时阶段与 CPU 指标；将全部迭代（默认 10 次）的数值累加后除以迭代次数得到平均值。这里有一个关键设计——计算 Total 总耗时时会跳过 CPU 时间，源码注释明确写着 "Don't add CPU time to the total time"：CPU 指标与耗时指标量纲不同、用途不同，不能混入总时长。

汇总后的单日结果以如下 JSON 结构沉淀（即runs.json的条目）：

{"date":"2026-09-18T...","cmd":21.0,"api":0.05,"k8s":0.05,"dnsSvc":0.05,"app":6.5,"dnsAns":26.3,"total":54.0,"cpu":17.0}

每日趋势图：时间序列折线

createDailyChart将所有历史 benchmark 条目按日期（Unix 时间戳）作为 X 轴绘制时间序列，每个条目产出 8 条曲线：6 个耗时阶段 + Total 总耗时 + CPU。图表标题为 "time-to-k8s"，X 轴刻度格式化为2006-01-02（Go 参考时间格式，即YYYY-MM-DD），Y 轴上限取历史最大 Total 再加 20 秒余量，保证曲线不被截断。图上每条曲线配独立图例与圆形散点标记，方便肉眼识别各阶段随日期的起伏。

每周平均图：168 小时聚合窗口

createWeeklyChart采用 168 小时（7×24h）作为聚合窗口：从最早一条基准的日期开始，把落在同一周内的所有条目按阶段累加，在窗口结束时除以该周基准条数得到周均值；窗口推进后若遇到整周无基准数据，则跳过该周（不产出 0 值点，避免误导性回落）。周均值同样绘制为 8 条曲线的时间序列。这正是 weekly_benchmark.md 中 4 张周均值图的生成逻辑，与每日图形成"日粒度原始 + 周粒度平滑"的互补视图。

指标如何呈现：版本基准页的表格与堆叠柱状图

除了每日/每周趋势图，仓库中还有一条独立的"版本基准"分支，用于展示某个发布版本与同类工具（kind、k3d）的横向对比，其脚本为 time-to-k8s.sh，页面生成器为 page.go。

time-to-k8s.sh的流程是：依次安装 kind、k3d，再用make构建 minikube，然后在基准 submodule 中运行go run . --config local-kubernetes.yaml --iterations 10 --output output.csv，最后调用 page.go 一次性生成 Markdown 页面与两张 PNG 图：

go run ./hack/benchmark/time-to-k8s/*.go --csv .../output.csv \ --image ./site/static/images/benchmarks/timeToK8s/"$1" \ --page ./site/content/en/docs/benchmarks/timeToK8s/"$1".md

page.go 内部用 Go 模板渲染页面骨架，核心数据表由 chart.go 生成：

• 运行时间表：横轴为被测工具（minikube / kind / k3d），纵轴为 6 个阶段 + Total，数值保留 3 位小数；
• 时间柱状图：6 个阶段按StackOn依次堆叠成一根柱子，柱顶标注 Total 总秒数，图例给出各阶段颜色；Y 轴固定上限 80 秒；
• CPU 图：由 cpu.go 生成，对 CPU Utilization(%) 与 CPU Time(seconds) 两个维度分别绘制三组柱（minikube / kind / k3d）。

以仓库中的 v1.35.0 基准页 为例，其时间数据表完整形态如下（minikube v1.35.0 / kind v0.26.0 / k3d v5.7.5，单位：秒）：

对应 CPU 表：

从这张表可以直观理解各阶段的分解逻辑：minikube 的启动链路在 "App Running" 与 "DNS Answering" 两个阶段耗时占比较高，同时 CPU 利用率较低——这正是时间/资源两个维度并列呈现的价值所在。需要注意，这类对比表的结论依赖被测版本与运行机器规格，仅作为仓库历史快照的事实呈现。

如何查阅与自行复现

查阅入口

• Daily Benchmark：针对 HEAD 的每日趋势，4 张图（Docker/containerd × Docker/VirtualBox）
• Weekly Average Benchmark：同一 4 组合的周均值趋势
• time-to-k8s Benchmarks 索引 与各vX.Y.Z.md版本页：历史版本与 kind、k3d 的横向对比

本地复现

仓库的基准工具是一个 git submodule（hack/benchmark/time-to-k8s/time-to-k8s-repo/），本地复现的通用步骤为：

# 1. 初始化基准工具 submodule cd hack/benchmark/time-to-k8s/time-to-k8s-repo git submodule update --init # 2. 按组合配置运行基准（示例：Docker driver + Docker runtime，10 次迭代） go run . --config ../public-chart/docker-docker-benchmark.yaml --iterations 10 --output output.csv # 3. 生成页面与图表（需已有历史 runs.json） go run ../public-chart/generate-chart.go \ --csv output.csv \ --daily-chart ./daily-chart.png \ --weekly-chart ./weekly-chart.png \ --past-runs ./runs.json

完整流水线可直接执行hack/benchmark/time-to-k8s/public-chart/public-chart.sh <driver> <runtime>（例如public-chart.sh docker containerd），但该脚本依赖aws s3 cp与 S3 桶time-to-k8s的读写权限，本地跑通全链路需要先配置 AWS 凭证；若仅想查看结果，阅读站点文档页面即可，无需自行构建。

小结

Daily Benchmark 页面是 minikube 持续性能监控的对外窗口，其背后是一套自洽的自动化体系：4 份组合配置定义被测矩阵，public-chart.sh串联"构建 HEAD → 10 次迭代基准 → 图表生成 → S3 归档"，generate-chart.go以 JSON 累积历史并以 168 小时窗口聚合周均值，chart.go/cpu.go/page.go则负责把同一份 CSV 渲染为可读的表格与堆叠柱状图。理解这套链路后，你既能准确解读页面上的每一根柱子、每一条曲线，也能在本地复现或扩展这套基准，用于跟踪 minikube 启动性能的每日演化。

【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube