minikube 二进制发布指南：从打 tag 到全平台产物上线的完整流程
【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube
minikube 的版本发布（Release）是一项高度流程化的工程操作：从更新 Kubernetes 版本、构建 ISO 与 kicbase 镜像，到生成发布说明、打 git tag、经 Jenkins 构建上传全平台二进制，再到合并 releases.json、验证校验和并通知下游包管理器。本文以官方发布文档 binaries.md 为主体骨架，结合仓库内 Makefile、hack/tag_release.sh、hack/jenkins/release_build_and_upload.sh 与 release_sanity_test.go 等源码，逐阶段还原一次完整发布的执行细节。读完本文，你将掌握 minikube 版本发布各阶段的具体操作、参数来源与验证手段，可以直接对照仓库复现整个发布链路。
发布流程总览
一次标准发布按以下顺序推进，每一阶段都有明确的前置条件与交付物：
- 准备：在 Slack
#minikube频道公告发布意向，暂停合并请求； - 升级依赖：更新默认 Kubernetes 版本并合入 PR；
- 构建 ISO：非补丁版本必须构建新 ISO；
- 发布 kicbase 镜像：通过 Jenkins
kic-release任务完成； - 生成发布说明：写入 CHANGELOG.md；
- 更新 Makefile 版本号：
VERSION_MAJOR/VERSION_MINOR/VERSION_BUILD； - 打 tag：执行
hack/tag_release.sh； - 构建并上传二进制：Jenkins Release 任务发布到 GCS 与 GitHub；
- 检查日志并合并 releases.json；
- 验证校验和、更新文档与公告。
其中 beta 版本在完成第 9 步的日志检查后即可视为发布完成，正式版本则需走完全部流程。
准备阶段：环境与仓库状态
发布前需要完成三件事：
- 在
#minikube频道公告发布意向，让社区周知； - 暂停合并请求，避免新增提交被意外遗漏在 ISO 或发布说明之外；
- 本地同时检出两个 minikube 仓库副本：你的个人 fork（用于提交 PR）与上游仓库（upstream，用于执行发布相关命令）。
后续所有make类命令均应在上游仓库副本中执行，确保基于最新 master 状态操作。
更新 Kubernetes 版本
在本地上游仓库副本运行：
make update-kubernetes-version该目标在 Makefile 中声明，底层实现位于hack/update/kubernetes_version/目录，负责探测最新稳定版 Kubernetes 并同步更新仓库内的默认版本常量与测试清单（目录下包含约 20 个版本相关 YAML 与一个 Go 程序，见 hack/update/kubernetes_version）。
运行后检查是否有文件被改动：若有，则先创建 PR 并合并，再继续后续发布步骤。默认 Kubernetes 版本常量定义在 pkg/minikube/constants/constants.go 的DefaultKubernetesVersion，Makefile 也正是通过读取该常量来确定编译基准版本。
构建新 ISO
ISO 的发布策略取决于版本类型：
- 所有非补丁（non-patch）版本必须构建新 ISO；
- 补丁版本（vx.x.1+）：仅当
deploy/iso目录自上次发布以来发生过变更时才需要。
判断方法：在仓库根目录执行git log -- deploy/iso检查是否有新提交。详细的 ISO 发布步骤见同目录文档 iso.md：在 Jenkins 的 ISO 任务中填入与 minikube 二进制版本一致的ISO_VERSION、ISO_BUCKET为minikube/iso后构建，构建完成后会自动创建携带变更的 PR；本地可用hack/jenkins/build_iso.sh脚本先行验证。ISO 构建根目录为 deploy/iso/minikube-iso，内含基于 Buildroot 的完整镜像定义。
发布新的 kicbase 镜像
运行 Jenkins 中的kic-release任务。该任务会自动创建一个 PR，必须确认输入正确的版本与仓库信息并手动合并该 PR。kicbase 是驱动 Kind 类集群的容器基础镜像，其版本号定义在 pkg/drivers/kic/types.go 的Version字段，Makefile 通过读取该常量获得KIC_VERSION。
值得注意的是，kic-release产出的 kicbase 镜像会以 tarball 形式随发布二进制一并上传：在 release_build_and_upload.sh 中，脚本读取KIC_VERSION后按amd64、arm64、ppc64le、s390x四种架构执行docker pull/docker image save/openssl sha256，生成out/kicbase-<版本>-<架构>.tar及其.sha256校验文件。
更新发布说明（Release Notes）
在本地上游仓库副本执行：
make release-notes该目标在 Makefile 中声明，实际调用 hack/release_notes.sh。脚本的工作机制如下：
- 从
gh auth获取 GitHub token（存入临时文件并在退出时清理），导出为GITHUB_TOKEN供 hack/changelog/changelog.go 使用； - 自动安装
github.com/google/pullsheet，统计上个 tag 以来的 PR 与评审数据； - 通过
git describe --abbrev=0定位最近一次 tag，驱动 changelog 生成与贡献者名单。
将脚本输出粘贴到 CHANGELOG.md 后，需要按对终端用户的重要程度排序；若变更超过 8 条，拆分为Improvements与Bug fixes两部分。同时执行以下清理：
- changelog 只保留面向用户的变更，剔除纯文档、低风险重构、仅测试相关的 PR；
- 从贡献者名单中移除机器人账号；
- 合并名单中重复/相似的名字。
该 PR 可以随时合并，也可以与后续的Makefile更新 PR 合并提交。
更新 Makefile 版本号
修改 Makefile 顶部的三个版本变量：
VERSION_MAJOR ?= 1 VERSION_MINOR ?= 39 VERSION_BUILD ?= 0它们组合出RAW_VERSION=$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_BUILD)，并进一步导出VERSION ?= v$(RAW_VERSION)（见 Makefile）。该版本号同时被 Windows 安装器生成流程使用：out/minikube-installer.exe构建时会将三者替换进 NSIS 模板（见 Makefile）。
⚠️警告：只有所有非实验性集成测试全部通过后，才允许合并该 PR！
打 tag：hack/tag_release.sh
版本号合并后，执行：
sh hack/tag_release.sh 1.<minor>.<patch>脚本 hack/tag_release.sh 的完整逻辑为：
- 校验参数个数，用法为
tag_release.sh <major>.<minor>.<build>； - 用正则
^[0-9]+\.[0-9]+\.[0-9a-z\.\-]+$校验版本格式，不匹配即退出； - 在临时目录浅克隆上游仓库，
checkout master并git pull到最新； - 创建带注释的 tag：
git tag -a "v${version}" -m "$version Release"； git push origin推送该 tag。
该脚本刻意在全新克隆中打 tag，以保证 tag 基于干净的上游 master，而不是本地未推送的提交。
构建并发布二进制
此阶段利用刚推送的 git tag，将新二进制发布到 GCS 并创建 GitHub Release。操作步骤：
- 打开 minikube 的 "Release" Jenkins 任务并登录；
- 点击左侧 "▶️ Build with Parameters"；
VERSION_MAJOR、VERSION_MINOR、VERSION_BUILD填与 Makefile 一致的值；- 获取两个 ISO 校验和并填入参数：
gsutil cat gs://minikube/iso/minikube-v<version>-amd64.iso.sha256 gsutil cat gs://minikube/iso/minikube-v<version>-arm64.iso.sha256 - 点击Build。
背后的执行脚本是 hack/jenkins/release_build_and_upload.sh，它完成了以下关键工作：
- 参数自检：从
VERSION_MAJOR/VERSION_MINOR/VERSION_BUILD拼出版本，并用grep校验其与 Makefile 中的声明一致（见脚本第 28-38 行），防止 tag 与 Makefile 版本漂移； - 环境准备：调用
check_install_golang.sh与check_install_docker.sh，并通过make verify-iso确认 ISO 已存在； - 多平台构建：
BUILD_IN_DOCKER=y make -j 16并行构建 Linux/Darwin 的 amd64 与 arm64 二进制、tar.gz压缩包、Windows 安装器（minikube-installer.exe）、以及 deb（amd64/arm64/ppc64el/s390x）与 rpm（x86_64/aarch64/ppc64le/s390x）等全平台产物； - dirty 校验：运行
minikube version检查commit:行是否带-dirty后缀，若工作区有未提交改动则中止发布（脚本第 74-88 行）； - latest 别名：复制
minikube_latest_amd64.deb等无版本号产物，避免每次发布都要更新上游 Kubernetes 文档； - 上传 GCS：
gsutil -m cp out/* "gs://$BUCKET/releases/$TAGNAME/"，随后将 beta/alpha 之外的正式版本内容复制到gs://$BUCKET/releases/latest/（脚本第 126-140 行）。
检查发布日志
任务结束后，点击 "Console Output" 确认发布过程无报错。brew 自动化失败通常在这一步暴露，因此日志检查是必经环节。
注意：如果你发布的是 beta 版本，到这里就算完成了。后续步骤仅适用于正式（stable）版本。
合并 releases.json 变更
发布脚本会更新https://storage.googleapis.com/minikube/releases.json——该文件是 minikube 二进制进行版本更新检查的数据源，且发布后立即生效。minikube-bot 随后会发出一个将 releases.json 变更合入代码树的 PR，请及时合并，以保持 GCS 与 GitHub 仓库数据同步。
仓库内对应产物包括 deploy/minikube/releases.json、deploy/minikube/releases-beta.json 与 deploy/minikube/releases-v2.json，更新检查逻辑位于 pkg/minikube/notify。
下游包管理器：AUR 与 Homebrew Cask
发布完成后，还需要跟进两个由社区维护的下游包：
| 包管理器 | 维护位置 | 发布后动作 |
|---|---|---|
| Arch Linux AUR | minikube-bin包 | 点击 "Flag as package out-of-date" 标记过期，触发维护者更新 |
| Brew Cask | Homebrew/homebrew-cask 仓库的 Casks 目录 | 发布任务会自动创建更新版本号与 SHA256 的 PR，需人工确认 PR 确实被创建 |
⚠️警告：Brew cask 自动化容易出错，务必确认 PR 已经创建。
验证发布校验和
运行：
make check-release该目标在 Makefile 中实现，执行go test -v ./deploy/minikube/release_sanity_test.go -run '//<版本>$$'。测试逻辑见 release_sanity_test.go：
TestReleases会分别从 stable 与 beta 两个 releases JSON 拉取全部版本（对应notify.GithubMinikubeReleasesURL等常量），逐一验证二进制可下载且校验和正确；validateChecksums校验 releases JSON 中 v1 扁平字段与 v2 嵌套 amd64 字段的一致性；releaseBinaries将 v1/v2 两种格式归一化，覆盖 darwin/linux/windows × amd64/arm/arm64/ppc64le/s390x 的完整矩阵；- 若最终没有任何二进制被检查到，测试直接失败（
no binaries were checked）。
由于 JSON 有 v1/v2 两种结构，make check-release实际验证的是发布产物与 releases.json 记录完全对齐，这是发布正确性的最后一道闸门。
更新文档与安全元数据
- 文档：若本次发布涉及重大变更，请向 Kubernetes 官方 minikube 学习环境文档提交更新 PR；
- 安全元数据：按 OPENSSF Security Insights 规范审阅并更新仓库根目录的 SECURITY-INSIGHTS.yml，使其准确反映仓库的构建、供应与安全实践现状。
公告新版本
最后在 README.md 中提及新版本，并通过以下渠道广而告之：
- Slack
#minikube频道； - minikube-dev、minikube-users 邮件列表；
- Twitter（目前已由
@minikube_dev账号自动化发布）。
小结：一次发布的完整清单
| 阶段 | 关键命令 / 操作 | 交付物 |
|---|---|---|
| 准备 | 公告、暂停合并、准备 fork + upstream | 干净的发布起点 |
| 升级 K8s | make update-kubernetes-version | 默认 Kubernetes 版本 PR |
| 构建 ISO | Jenkins ISO 任务（ISO_VERSION/ISO_BUCKET=minikube/iso） | 带 SHA256 的 ISO |
| kicbase 镜像 | Jenkinskic-release任务 | kicbase 镜像 PR |
| 发布说明 | make release-notes | CHANGELOG.md 更新 |
| 版本号 | 编辑 Makefile | 版本 PR |
| 打 tag | sh hack/tag_release.sh 1.<minor>.<patch> | 上游 git tag |
| 构建上传 | Jenkins Release 任务（含两个ISO_SHA256_*） | GCS 产物 + GitHub Release |
| 日志检查 | Console Output | 确认 brew 等自动化成功 |
| 同步数据 | 合并 minikube-bot 的 releases.json PR | GCS 与 GitHub 一致 |
| 验证 | make check-release | 全平台校验和通过 |
| 收尾 | 更新文档与 SECURITY-INSIGHTS.yml、公告 | 社区同步 |
整个流程的核心原则是版本单一来源：Makefile 的VERSION_MAJOR/MINOR/BUILD是唯一事实源，tag_release.sh与release_build_and_upload.sh都通过正则或 grep 反查它，确保 tag、二进制、ISO、releases.json 与 GitHub Release 五者版本完全一致。
【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
