minikube ISO 版本发布全流程从构建判定、Jenkins 参数到自动 PR 的实战指南【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube本指南以 minikube 仓库的 releasing/iso.md 为核心系统讲解何时需要发布新 ISO、如何在 Jenkins 上触发 ISO 构建、如何填写ISO_VERSION与ISO_BUCKET参数以及构建产物如何自动回流为 Pull Request这一完整发布链路。读者读完将掌握 minikube ISO 发布的标准操作步骤并能结合仓库中 build_iso.sh、Makefile 与 iso.go 的源码理解每次发布背后实际发生的关键行为。发布 ISO 与构建 ISO 是两件事本文聚焦**发布release**流程如需在本地亲手构建出 ISO 镜像请参考仓库中的 building/iso.md。何时需要发布新 ISO以deploy/iso目录变更判定minikube 的惯例是大版本Major release发布时必定配套一个新 ISO而小版本 bugfix 则不一定需要。判定依据非常具体——检查仓库deploy/iso目录自最近一次发布以来是否发生过提交# 在仓库根目录执行 git log -- deploy/iso若该目录存在自最近一次发布之后的提交说明 ISO 内容内核、用户态组件、板级配置等发生了变化需要重新构建并发布 ISO若没有相关提交则说明 ISO 无需更新可直接沿用既有镜像。从仓库结构看deploy/iso目录即 minikube ISO 的家核心构建配置集中在 deploy/iso/minikube-iso包含arch/x86_64 与 aarch64 的 Buildroot 配置模板、board/两种架构的 rootfs overlay、CHANGELOG等、package/可选的第三方软件包、configs/minikube_*_defconfig以及patches/Buildroot 补丁。该目录中任何文件的变动理论上都可能影响最终 ISO 的内容与行为因此也是判定是否需要发布新 ISO的观察对象。发布前准备用build_iso.sh在本地验证构建正式的发布由 Jenkins 流水线完成但仓库明确提示可以使用hack/jenkins/build_iso.sh脚本在本地构建 ISO。该脚本是发布流程的本地预演也直接复用了 Makefile 中真实的构建链路。脚本开头会依次做这些事对应 build_iso.sh清理构建产物与缓存删除out/目录执行go clean -cache -modcache并清理$GOPATH/src因为 ISO 构建基于 buildroot、并不依赖宿主机 Go 缓存清理 Jenkins 工作区残留与将 systemd journal 截断至 1GB避免构建机磁盘被历史日志占满检查环境依赖通过 hack/jenkins/installers/check_install_gh.sh 与 check_install_golang.sh 确保ghCLI 与 Go 工具链可用并安装build-essential unzip rsync bc python3 p7zip-full cmake xorriso等系统包生成 CHANGELOG调用 hack/jenkins/build_changelog.sh 为 x86_64 / aarch64 两个 board 的rootfs-overlay/CHANGELOG填充最近合并的 PR 列表校验 ISO 版本未过期拉取 master 上的 Makefile比较当前分支ISO_VERSION的时间戳若过期会通过gh pr comment提示作者 rebase执行make release-iso构建并上传上传部分见下文。脚本还内置了磁盘空间保护构建前检查可用空间若低于100GB会直接失败并调用 hack/jenkins/investigate_disk_usage.sh 排查占用然后在 PR 上留言说明原因——可见 ISO 构建是一个对磁盘高度敏感的流程。需要说明的是该脚本的完整自动化逻辑按 PR 编号生成临时 ISO 版本、自动 push 到 PR 等主要在 Jenkins 环境中运行本地手动执行时请重点关注其构建与上传 ISO 的核心部分并根据你的实际环境设置好ISO_VERSION、ISO_BUCKET等环境变量。本地构建 ISO 的底层链路无论通过脚本还是手动执行最终都汇聚到 Makefile 的构建规则见 Makefile# Makefile 中与 ISO 构建相关的关键定义节选 BUILDROOT_OPTIONS BR2_EXTERNAL../../deploy/iso/minikube-iso $(GOLANG_OPTIONS) ISO_BUILD_IMAGE ? $(REGISTRY)/buildroot-image ISO_BUCKET ? minikube/iso minikube-iso-%: iso-source-% out/auto-pause-% # 构建 minikube iso cp out/auto-pause-$* deploy/iso/minikube-iso/board/minikube/$*/rootfs-overlay/usr/bin/auto-pause $(MAKE) -C $(BUILD_DIR)/buildroot $(BUILDROOT_OPTIONS) O$(BUILD_DIR)/buildroot/output-$* host-go $(MAKE) -C $(BUILD_DIR)/buildroot $(BUILDROOT_OPTIONS) O$(BUILD_DIR)/buildroot/output-$* # x86_64 ISO 仍为 BIOS 而非 EFIKVM 的 AppArmor 与 Hyper-V Gen2 问题所致 if [ $* aarch64 ]; then \ mv $(BUILD_DIR)/buildroot/output-aarch64/images/boot.iso $(BUILD_DIR)/minikube-arm64.iso; \ else \ mv $(BUILD_DIR)/buildroot/output-x86_64/images/rootfs.iso9660 $(BUILD_DIR)/minikube-amd64.iso; \ fi; release-iso: minikube-iso-aarch64 minikube-iso-x86_64 checksum ## Build and release .iso files gsutil cp out/minikube-amd64.iso gs://$(ISO_BUCKET)/minikube-$(ISO_VERSION)-amd64.iso gsutil cp out/minikube-amd64.iso.sha256 gs://$(ISO_BUCKET)/minikube-$(ISO_VERSION)-amd64.iso.sha256 gsutil cp out/minikube-arm64.iso gs://$(ISO_BUCKET)/minikube-$(ISO_VERSION)-arm64.iso gsutil cp out/minikube-arm64.iso.sha256 gs://$(ISO_BUCKET)/minikube-$(ISO_VERSION)-arm64.iso.sha256从中可以提取出几个关键事实双架构产出一次发布同时构建amd64x86_64与arm64aarch64两个 ISO并各自生成.sha256校验文件由checksum目标用openssl sha256生成版本号参与产物命名上传到 GCS 的对象名为minikube-$(ISO_VERSION)-$(ARCH).isoISO_VERSION直接影响线上可下载文件名发布目标桶由ISO_BUCKET决定Makefile 默认ISO_BUCKET ? minikube/iso而正式发布流程中该值由 Jenkins 参数显式传入。在 Jenkins 上触发 ISO 发布构建当确认需要新 ISO、且本地验证通过后正式发布走 minikube 的ISO Jenkins job。官方文档给出的操作步骤为进入 minikube ISO 的 Jenkins job确认已登录页面右上角点击左侧的 ▶️ Build with Parameters带参数构建填写ISO_VERSION输入目标发布版本号必须与 minikube 二进制自身的版本号保持一致例如v1.39.0填写ISO_BUCKET输入minikube/iso正式发布桶与 Makefile 默认值一致点击 Build开始构建。构建完成后流水线会自动创建一个携带变更的 PR——这即是发布动作的收尾产物详见下文自动 PR一节。参数背后的含义ISO_VERSION与ISO_BUCKET这两个参数看似简单却是整个发布的关键结合 build_iso.sh 的源码可以看得很清楚ISO_VERSION发布版本号在发布模式下脚本直接export ISO_VERSION透传 Jenkins 参数它会被写进三处地方Makefile 的ISO_VERSION ? ...版本标记rootfs overlay 中的etc/VERSION文件通过iso-prepare-%目标写入见 Makefile 第 292 行附近最终 ISO 的上传文件名minikube-$(ISO_VERSION)-arch.iso。ISO_BUCKETGCS 桶正式发布固定为minikube/iso。脚本在非发布PR 构建场景下会自动改成minikube-builds/iso/$ghprbPullId把每个 PR 的 ISO 隔离到独立目录避免互相覆盖发布时则原样使用 Jenkins 传入的桶名。发布模式与 PR 构建模式的分流build_iso.sh 通过ISO_VERSION是否为空来区分两种模式PR 构建ISO_VERSION为空脚本会从当前 Makefile 解析出版本前缀拼出形如v1.39.0-当前时间戳-PR号的临时版本桶设为minikube-builds/iso/PR号构建成功后用gh pr checkout切到贡献者分支执行sed更新 Makefile 与pkg/minikube/download/iso.go中的isoBucket再make generate-docs并 commit、push 回 PR最后在 PR 上留言告知已更新 ISO 引用。这对应 CI 中每个 PR 自动构建 ISO的能力。发布模式ISO_VERSION非空也就是本文的发布场景。脚本将版本与桶原样导出构建完成后新建iso-release-${ISO_VERSION}分支同样更新 Makefile、pkg/minikube/download/iso.go与生成的start.md文档commit 后经minikube-bot远程强推最后gh pr create --fill --base master创建 PR 并打上ok-to-test标签。构建完成后自动产生的 PR 里包含什么官方文档强调构建会自动创建一个携带变更的 PR其内容来自脚本末尾的发布分支见 build_iso.sh 的releasetrue分支sed -i s/ISO_VERSION ? .*/ISO_VERSION ? ${ISO_VERSION}/ Makefile sed -i s|isoBucket : .*|isoBucket : \${ISO_BUCKET}\| pkg/minikube/download/iso.go make generate-docs git add Makefile pkg/minikube/download/iso.go site/content/en/docs/commands/start.md git commit -m Release: Update ISO to ${ISO_VERSION}也就是说自动 PR 至少包含三类变更MakefileISO_VERSION更新为本次发布版本例如v1.39.0-1788948396-23685这类带时间戳与 PR 号的形式见 Makefile 第 27 行pkg/minikube/download/iso.goisoBucket更新为minikube/iso。该文件中DefaultISOURLs()会按优先级依次尝试构建 ISO 下载地址见 iso.goreturn []string{ fmt.Sprintf(https://storage.googleapis.com/%s/minikube-%s-%s.iso, isoBucket, v, runtime.GOARCH), fmt.Sprintf(https://github.com/kubernetes/minikube/releases/download/%s/minikube-%s-%s.iso, v, v, runtime.GOARCH), fmt.Sprintf(https://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/iso/minikube-%s-%s.iso, v, runtime.GOARCH), }可见发布桶minikube/iso中的 ISO 正是minikube start首次下载 VM 启动镜像的首选来源这也是为何 PR 必须携带这一变更site/content/en/docs/commands/start.md由make generate-docs重新生成同步反映新版 ISO 的下载信息。顺带说明 ISO 下载侧的校验逻辑downloadISOiso.go默认以?checksumfile:iso.sha256的方式拉取并校验 sha256若失败会依次回退到 GitHub Releases 与阿里云 OSS 镜像源——这解释了为什么release-iso会同时上传.iso与.iso.sha256两个对象。发布后验证与故障排查验证 ISO 已就位Makefile 提供了check-isogsutil stat gs://$(ISO_BUCKET)/minikube-$(ISO_VERSION)-amd64.iso见 Makefile 第 547-548 行之类的检查目标可用于确认两个架构的 ISO 均已上传到minikube/iso桶PR 自动注释脚本在构建失败非发布模式或构建成功推送失败等场景下都会通过gh pr comment在对应 PR 上留下带有构建日志链接的说明维护者可据此定位问题磁盘空间不足构建前置检查要求至少 100GB 可用空间不足时会直接中止并留言避免长时间空跑后失败版本过期若当前分支的 ISO 时间戳早于 master脚本会提示ISO info is out of date. Please rebase并退出发布前务必先 rebase 到最新 master。总结minikube ISO 的发布是一个判定变更 → 本地预演 → Jenkins 参数化构建 → 自动 PR 回流的闭环流程环节关键动作依据/产出变更判定git log -- deploy/iso大版本必发bugfix 视目录变更而定本地预演hack/jenkins/build_iso.sh复用真实构建链路含磁盘与版本检查参数填写ISO_VERSION与二进制版本一致、ISO_BUCKETminikube/iso决定产物命名与上传桶构建上传make release-iso产出 amd64/arm64 两套 ISO 及 sha256上传 GCS自动 PR更新 Makefile、iso.go、start.md指向新 ISO供minikube start下载使用理解这条链路后无论是排查为什么minikube start下载的 ISO 不是我预期的版本检查 pkg/minikube/download/iso.go 的isoBucket与ISO_VERSION还是手工补跑一次发布按 build_iso.sh 的发布分支操作都能做到有据可依、按图索骥。【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考