cAdvisor 发布流程完整指南从 Release PR 到多架构镜像发布的五个关键步骤【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址: https://gitcode.com/gh_mirrors/ca/cadvisor本篇指南以 docs/development/releasing.md 为核心系统讲解 cAdvisor 官方维护者从准备发布、打 tag、构建产物、容器验证到正式 Cut Release 的完整五步流程。无论你是 cAdvisor 的贡献者、想要自建分支发布fork 发布的团队还是希望通过make release理解多架构镜像构建机制的平台工程师读完本文后都能掌握一次可复现、可校验的发布操作并理解每一步背后对应的仓库脚本与源码实现。一、发布流程总览与核心产物cAdvisor 的发布流程分为五个阶段每阶段都有明确的产出物Send Release PR将变更记录Release Notes合入 CHANGELOG.md作为发布前置提交。Create the release tag创建 release 分支仅 major/minor 版本并为发布提交打上带签名的 tag。Build release artifacts执行make release产出多架构容器镜像与各架构二进制。Check the Containers用 build/check_container.sh 逐一启动镜像并探测/healthz验证镜像可运行。Cut the release在 GitHub Releases 页面组装发布说明、粘贴镜像与哈希、上传二进制并发布。整个过程的目标产物包括一个 Multi-Arch 清单镜像如gcr.io/cadvisor/cadvisor:v0.44.1-test-8架构专属镜像如gcr.io/cadvisor/cadvisor-arm64:v0.44.1-test-8等各平台二进制如cadvisor-v0.44.1-test-8-linux-amd64及其 SHA256 校验和。从 build/release.sh 的实现可以看到官方正式支持的架构为amd64、arm、arm64、s390x脚本内部维护了 Docker 架构名到 QEMU 架构名的映射x86_64、arm、aarch64、s390x并在发布前强制校验本机是否安装了对应的qemu-*-static二进制解释器。二、第 1 步提交 Release PR把变更写入 CHANGELOG发布的第一步不是直接打 tag而是把本次发布要公之于众的变更记录先合入仓库这一步被官方称为Send Release PR。具体操作新增一个 PR将本次发布涵盖的变更整理进 CHANGELOG.md仓库根目录版本条目按时间倒序排列格式形如### 0.39.0 (2021-03-08)下方以列表逐条列出 PR 标题与链接。一个实用技巧用 GitHub 的 PR 搜索功能找出自上次发布以来的全部已合并 PR作为编写 Release Notes 的素材搜索条件形如is:pr is:merged merged:2016-04-21把日期替换为上次发布的时间点即可。从仓库现状看CHANGELOG.md 已积累了 521 行、从 0.39.0 往前追溯的完整变更历史这正体现了发布流程对变更记录的持续维护要求每次发布都应把 Release Notes 提前合入主干这样后续 Cut Release 时可以直接从 CHANGELOG 复制正文而不是临时回忆。三、第 2 步创建 release 分支与签名 tag2.a 创建 release 分支仅 major/minor 版本需要补丁patch发布可以跳过此步major/minor 发布则需要先切出一个长期维护分支例如v0.23# Example version VERSIONv0.23 PATCH_VERSION$VERSION.0 # Sync to HEAD, or the commit to branch at git fetch upstream git checkout upstream/master # Create the branch git branch release-$VERSION # Push it to upstream git push gitgithub.com:google/cadvisor.git release-$VERSION几点说明命令中的upstream指向官方上游仓库本仓库是镜像实际操作时应替换为你自己的远程名与仓库地址分支命名统一为release-VERSION其中VERSION只到 minor 级别如v0.23不带 patch 号创建分支的基点通常是upstream/master的最新提交但也可以显式指定某个提交作为分支点以便只携带指定范围内的变更。2.b 打发布 tag所有发布都需要# Example patch version VERSIONv0.23 PATCH_VERSION$VERSION.0 # Checkout the release branch git fetch upstream git checkout upstream/release-$VERSION # Tag the release commit. If you arent signing, ommit the -s git tag -s -a $PATCH_VERSION # Push it to upstream git push gitgithub.com:google/cadvisor.git $PATCH_VERSION关键点tag 名形如v0.23.0即v 完整三/四段版本号git tag -s -a表示创建**带签名sign且带注释annotated**的 tag如果无法签名官方明确允许省略-s参数但要意识到签名 tag 有助于供应链溯源打好 tag 后必须git push到远程因为后续第 5 步要在 GitHub Releases 界面中直接选中这个 tag。四、第 3 步make release构建发布产物4.1 触发入口Makefile 的 release target在仓库根目录执行make release该命令实际指向 Makefile 中的 targetrelease: echo building release binaries ./build/release.sh也就是说make release是 build/release.sh 的封装。执行前官方给出了几条重要前置检查Git 客户端必须同步到发布切点release cut point即 release 分支/tag 所在的提交尽量从 release 分支构建因为分支名会被编入二进制的版本信息Go 版本尽量与 Kubernetes 使用的 Go 版本保持一致参考 Kubernetes 的build/dependencies.yaml中声明的 Go 版本官方建议使用 gvm 之类的工具在多个 Go 版本之间切换以满足不同发布期的编译要求构建前要确认git config user.email已设置——从源码看这并非可选项而是硬性要求见下文。4.2 release.sh 内部做了什么阅读 build/release.sh 可以还原make release的完整执行链路第一步确定版本号。若环境变量VERSION未设置脚本用git describe --tags --dirty --abbrev14自动推导并用正则^v[0-9]\.[0-9]\.[0-9](-(alpha|beta|rc)\.?[0-9]*)?$校验必须是已打 tag 的合法版本支持alpha/beta/rc预发布后缀不合法直接报错退出从机制上杜绝在未打 tag 的提交上发版。第二步人工确认。脚本用read -p Please confirm: $VERSION is the desired version...等待输入y/n非y立即退出。第三步设置构建元信息。要求git config --get user.email必须可读否则报错并提示git config user.email email随后导出export BUILD_USER$git_user export BUILD_DATE$( date %Y%m%d ) # Release date is only to day-granularity export VERBOSEtrue第四步准备 buildx 并构建多架构镜像。脚本检查/创建名为cadvisor-builder的 Docker buildx builder然后按架构循环对每个架构先用build/build.sh交叉编译对应架构的二进制设置GOARCH、CGO_ENABLED0、OUTPUT_NAME_WITH_ARCHtrue再用docker buildx build --platform linux/arch构建并推送架构专属镜像最后通过docker manifest create/annotate/push把四个架构镜像聚合为一个多架构清单镜像。第五步输出 Release info。脚本末尾打印Release info (copy to the release page)区块内容即多架构镜像名、架构专属镜像列表、以及二进制 SHA256 校验和。官方文档特别强调构建完成后把Release info...之后的输出复制保存留待第 5 步使用。4.3 版本信息是怎么编进二进制的make release验证 ldflags 输出时需要关注Version、BuildUser、GoVersion是否符合预期这背后的机制在 build/build.sh 中ldflags -X ${repo_path}/lib/version.Version${ldseparator}${version} -X ${repo_path}/lib/version.Revision${ldseparator}${revision} -X ${repo_path}/lib/version.Branch${ldseparator}${branch} -X ${repo_path}/lib/version.BuildUser${ldseparator}${BUILD_USER} -X ${repo_path}/lib/version.BuildDate${ldseparator}${BUILD_DATE} -X ${repo_path}/lib/version.GoVersion${ldseparator}${go_version}其中版本、revisiongit rev-parse --short HEAD、分支git rev-parse --abbrev-ref HEAD、Go 版本均在编译期通过-ldflags -X注入。这些变量的接收者位于 lib/version/version.go它们被组织进version.Infomap最终通过 cmd/cadvisor.go 在运行时输出fmt.Printf(cAdvisor version %s (%s)\n, version.Info[version], version.Info[revision])这解释了为何官方要求从 release 分支构建Branch与Revision会如实反映构建时的分支与提交从错误分支构建会导致二进制内的版本信息与 tag 不一致难以排查问题。4.4 一次发布产物的典型输出官方文档给出的输出示例以下均为示意版本Multi Arch Container: gcr.io/cadvisor/cadvisor:v0.44.1-test-8 Architecture Specific Containers: gcr.io/cadvisor/cadvisor-arm:v0.44.1-test-8 gcr.io/cadvisor/cadvisor-arm64:v0.44.1-test-8 gcr.io/cadvisor/cadvisor-amd64:v0.44.1-test-8 Binaries: SHA256 (cadvisor-v0.44.1-test-8-linux-arm64) e5e3f9e72208bc6a5ef8b837473f6c12877ace946e6f180bce8d81edadf66767 SHA256 (cadvisor-v0.44.1-test-8-linux-arm) 7d714e495a4f50d9cc374bd5e6b5c6922ffa40ff1cc7244f2308f7d351c4ccea SHA256 (cadvisor-v0.44.1-test-8-linux-amd64) ea95c5a6db8eecb47379715c0ca260a8a8d1522971fd3736f80006c7f6cc9466注意其中架构列表只展示了arm/arm64/amd64实际脚本会同时构建s390x哈希计算逻辑位于 build/release.sh 末尾(cd _output find . -name cadvisor-${VERSION}* -exec sha256sum --tag {} \;)即对_output目录下所有以cadvisor-${VERSION}开头的产物做 SHA256 摘要--tag模式输出格式与上方示例一致二进制路径约定为_output/cadvisor-version-GOOS-GOARCH见 build/build.sh 的命名逻辑。五、第 4 步逐架构启动容器验证/healthz健康检查发布镜像构建完成后不能直接发布——必须先验证每个架构的镜像都能真正启动并对外提供服务。官方提供的验证脚本是 build/check_container.sh用法如下build/check_container.sh gcr.io/tstapler-gke-dev/cadvisor:v0.44.1-test-8唯一参数就是第 3 步产出的 Multi-Arch 容器镜像 tag。5.1 前置条件QEMU 用户态模拟由于本机 CPU 架构通常只是amd64运行arm、arm64、s390x的镜像需要 QEMU 用户态二进制解释器。官方给出的准备命令sudo apt install qemu-user-static docker run --rm --privileged multiarch/qemu-user-static --reset -p yes第一条安装 QEMU 静态二进制第二条把 QEMU 注册为 Docker 的跨架构二进制解释器。这个前置条件是强制的——build/release.sh 在构建前就会逐个检查qemu-${arch}-static是否存在缺失直接报错退出。5.2 脚本校验逻辑对应源码从 build/check_container.sh 看脚本会遍历arches( amd64 arm arm64 s390x )四个官方架构对每个架构执行docker run --platform linux/$arch -p 8080:8080 --rm --detach后台启动被测镜像把容器 8080 端口映射到本机 8080sleep 10等待 cAdvisor 完成初始化用curl --show-error --retry 5 --fail -L 127.0.0.1:8080/healthz探测健康检查端点重试 5 次、失败即退出成功后打印Success!然后docker stop并docker rmi清理容器与镜像避免同名不同架构的镜像污染本地 Docker 缓存。脚本头部的注释同样强调需要先运行 QEMU 注册命令并将自身定位为针对 cAdvisor 支持的每个 CPU 架构运行基本冒烟测试的脚本。也就是说第 4 步本质是一次自动化的跨架构冒烟测试smoke test/healthz返回成功即认为该架构镜像可用。六、第 5 步Cut Release组装正式发布容器验证通过后进入最后的发布环节打开 GitHub Releases 页面点击Draft a new releaseTag version 与 Release title都要以v开头接版本号并选中第 2.b 步推送的 tag建议复制一个旧版本作为模板官方举例v0.23.1保持发布格式一致正文Body结构开头是 Release Notes直接从 CHANGELOG.md 复制本次版本的条目接下来粘贴第 3 步保存的 Docker 镜像列表与二进制 SHA256 哈希上传第 3 步构建的二进制文件位于仓库根目录的_output目录下如果本次是minor 版本发布把发布标记为pre-release预发布patch 版本则无需此标记全部确认后点击Publish完成发布。从 CHANGELOG.md 的格式可以印证该流程的一致性每个版本条目都带发布日期与逐条 PR 说明这正是 Release 正文正文的直接来源。七、版本号约定与常见坑位总结综合文档与仓库脚本整理出发布过程中需要特别注意的规则与常见问题阶段硬性要求常见坑位Release PR变更记录必须先合入 CHANGELOG.md忘记整理合并的 PR导致 Release Notes 缺失分支/tagpatch 发布跳过分支tag 命名vX.Y.Z建议-s签名从错误的基点切分支导致 tag 携带无关变更make releaseGit 同步到切点、git config user.email已设置、qemu-user-static 已安装、Go 版本与 Kubernetes 对齐VERSION未设置且当前提交未打 tag 时脚本直接报错拒绝构建容器验证必须先执行 QEMU 注册命令未注册 QEMU 时docker run --platform无法执行其他架构镜像Cut Releasetag 选中第 2.b 步推送的 tagminor 发布标记 pre-release二进制上传遗漏或哈希与镜像不一致几点补充说明依据源码build/release.sh 中的版本校验正则允许alpha、beta、rc后缀因此预发布版本同样可以走完整发布流程与第 5 步minor 标记 pre-release相互呼应make release在 Makefile 中没有任何依赖项即不会自动先跑make build/make assets所有构建逻辑都在 release.sh 内闭环构建产物统一落盘在_output/目录Makefile 的cleantarget 也会清理该目录第 5 步上传二进制时直接从中选取。八、总结cAdvisor 的发布流程是一套变更记录先行 → 签名 tag 固化 → 脚本化多架构构建 → 跨架构冒烟验证 → 手工组装 Release的完整闭环。其核心价值在于可复现版本号、分支、提交、构建用户、Go 版本全部通过 ldflags 注入二进制发布信息可溯源可验证check_container.sh用/healthz探针在每个官方架构上自动冒烟杜绝构建成功但跑不起来的镜像发布可约束release.sh 从机制上拦截未打 tag、未配置 git 用户、未安装 QEMU 等错误状态降低人为失误。对于需要维护自建分支或定制版本的团队完全可以在 fork 仓库中沿用这套流程将命令中的 remote 与镜像地址替换为自己的仓库与镜像仓库即可。进一步可阅读 docs/development/integration_testing.md 了解发布前的集成测试体系或直接阅读 build/release.sh 与 build/check_container.sh 两个脚本的完整实现。【免费下载链接】cadvisorAnalyzes resource usage and performance characteristics of running containers.项目地址: https://gitcode.com/gh_mirrors/ca/cadvisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
