云原生容器编排微服务运维【免费下载链接】kruiseAutomated management of large-scale applications on Kubernetes (incubating project under CNCF)项目地址https://gitcode.com/gh_mirrors/kr/kruise点击查看免费下载OpenKruiseKruise是 CNCF 孵化项目定位为 Kubernetes 大规模应用自动化管理套件。本文以仓库中的 RELEASE-PROCESS.md 为骨架结合仓库内的 GitHub Actions 工作流、Makefile 构建目标、Helm Chart 生成脚本与卸载保护逻辑等源码证据完整讲解一个 Kruise 新版本从版本号规划、Changelog 编写、文档快照、镜像发布、Helm Chart 打包到社区公告的全过程。读完本文你可以完整掌握 Kruise 的发布机制与每个环节对应的仓库落地实现也能复用这套流程模式来规划自己项目的发版节奏。说明Kruise 的版本发布目前仅限项目 maintainers 执行本文面向希望理解发布机制、参与发布或自建发布流水线的读者。一、发布前置条件确定下一个版本号发布的第一步是确定要发什么版本号。RELEASE-PROCESS.md 给出的做法非常直接打开 GitHub Releases 页面查看最近一次发布的版本号然后在语义化版本SemVer规则下推导下一个版本。以原文档撰写时的例子来说最近一次发布是 v1.2.0那么下一个版本就是 v1.3.0。推而广之若最近一次是 v1.8.2下一个 minor 版本就是 v1.9.0若是紧急修复则应在当前 minor 内递增 patch 号。Kruise 的版本策略在仓库根目录的 RELEASES.md 中有明确约定Kruise 使用语义化版本控制semantic versioning让用户可以按需可靠地升级发布周期为 23 个月并通过 GitHub Milestones 给出下一个版本的预期发布时间Milestone 上的日期只是预期允许延期并在 Milestone 上体现。这个先看上一个版本 → 推断下一个版本号的步骤本质上是在为后续所有环节Changelog 标题、镜像 tag、Chart 版本号确定统一的版本基准。从仓库证据看当前 CHANGELOG.md 已经演进到 v1.9.0 及其 Upgrade Notice升级 Kubernetes 依赖到 v1.32.6、Golang 到 v1.23并将 BroadcastJob、AdvancedCronJob、ImagePullJob 等一组 API 从 v1alpha1 升级到 v1beta1说明版本号推导的实践一直在持续运转。二、编写 Changelog只写对用户重要的事确定版本号后第一步产出是更新仓库根目录的 CHANGELOG.md为即将发布的新版本新增一个段落记录该版本引入的新功能features、补丁patches与废弃项deprecations。原文档特别强调了一个筛选原则Changelog不需要包含每一个变更只需要收录对客户用户有意义的内容。例如某个 issue 模板改动了这种就不值得写进去。这一原则在当前仓库的 CHANGELOG.md 中体现得非常清晰。以 v1.9.0 段落为例其结构是Upgrade Notice先给出升级前必读的破坏性/关键变更例如依赖升级、API 版本提升、feature gate 默认值变化等Key Features核心功能如 UnitedDeployment 支持 ReserveUnschedulablePods、AdvancedCronJob 支持 cron ImagePullJob、CloneSet 支持 progressDeadlineSeconds 等Other Notable Changes按模块Sidecar Management、Others归类的重要变更Bug Fixes重要的缺陷修复列表MiscChores and tests测试、工程化等杂项。这种分节组织方式既方便用户按版本快速评估升级风险也方便发布时直接复用为 GitHub Release 正文。撰写 Changelog 时每条变更通常附上对应的 PR 链接与贡献者信息便于追溯仓库中的 v1.8.0 段落还展示了 feature gate 状态变化的记录方式哪些 gate 被禁用、哪些被提升到 beta。三、发布新版本的官方文档Kruise 的用户文档托管在 openkruise.io 站点上发布新版本时需要同步为文档打一个版本快照避免站点上的文档随主分支持续漂移而和已发布版本脱节。原文档给出的操作路径是Fork 文档仓库openkruise/openkruise.io在本地基于当前版本执行 Docusaurus 的版本化命令生成新版本文档yarn run docusaurus docs:version VERSION例如对 v1.3.0 执行yarn run docusaurus docs:version v1.3.0Docusaurus 会把当前 docs 目录内容固化为该版本的快照此后该版本文档不会再随主分支变化。这一步对应仓库侧的事实是Kruise 主仓库中的用户指南类文档如 docs/tutorial 下的 cloneset、sidecarset、uniteddeployment、broadcastjob 等教程以及 docs/proposals 中的特性提案是文档站点的上游素材发布时文档站点版本与 Kruise 代码版本保持一致用户在 openkruise.io 上选择对应版本即可查看与该版本匹配的使用说明。四、在 GitHub 创建 Release触发镜像构建流水线版本发布的核心动作是在 GitHub Releases 页面创建一条 Release。原文档明确指出创建 Release 会触发一个 GitHub workflow用最新代码构建新镜像并打上版本 tag。这一说法可以在仓库的 .github/workflows/docker-image.yaml 中得到印证该工作流监听workflow_dispatch手动触发登录 Docker Hub 后执行多平台镜像构建- name: Build the Docker image run: | docker buildx create --use --platformlinux/amd64,linux/arm64,linux/ppc64le --name multi-platform-builder docker buildx ls IMGopenkruise/kruise-manager:${{ github.ref_name }} make docker-multiarch关键点在于github.ref_name—— 它取的是触发工作流的 tag 名称即本次发布的版本号。也就是说镜像 tag 与 Release 的版本号天然保持一致无需人工维护镜像 tag 与版本号的对应关系。底层的make docker-multiarch目标定义在仓库根目录的 Makefile 中# Build and push the multiarchitecture docker images and manifest. docker-multiarch: docker buildx build -f ./Dockerfile_multiarch --pull --no-cache --platform$(PLATFORMS) --push . -t $(IMG)其中PLATFORMS ? linux/amd64,linux/arm64,linux/ppc64le即一次构建同时覆盖 amd64、arm64、ppc64le 三个 CPU 架构。多架构构建的实际执行逻辑在 Dockerfile_multiarch 中构建阶段使用--platform$BUILDPLATFORM的 golang 基础镜像通过TARGETOS/TARGETARCH环境变量为每个目标平台分别编译 manager 与 kruise-daemon 二进制运行阶段则统一落到精简后的 alpine 基础镜像上。除 manager 主镜像外Makefile 还提供了docker-build-hook目标用于构建 helm_hook 镜像见下文第八节以及docker-win-daemon用于构建 Windows 版 daemon。因此发布者在 Releases 页面创建 release 并打上版本 tag 后CI 即自动产出openkruise/kruise-manager:版本号的多架构镜像这就是 Helm Chart 和部署清单所引用的正式镜像。五、使用统一的 Release 模板为了让每个版本的 GitHub Release 正文风格一致、信息结构可预期原文档强制要求所有 Release 使用固定模板。模板原文如下#### To install or upgrade to the old version, see [installation doc](https://openkruise.io/docs/installation/). ## Changes since v1.2.0 ### New CRD and Controller: XXX ### CloneSet ### XXX ### Others Thanks to all our contributors! 模板要点开头固定给出安装/升级指引指向 openkruise.io 的安装文档以## Changes since 上一版本作为变更总览标题方便读者快速对比相邻版本差异按功能模块分节### New CRD and Controller: XXX、### CloneSet、### XXX、### Others每个模块下列出该模块的主要变更XXX是占位符发布时替换为实际模块名结尾统一致谢所有贡献者。这套版本差异 模块分节 贡献者致谢的结构与 CHANGELOG.md 的分节风格互相呼应Changelog 是发布正文的素材来源Release 正文则是 Changelog 面向终端用户的呈现形式。实际发布时模板中的Changes since v1.2.0应替换为Changes since 上一实际版本号例如当前仓库最新段落的写法是 Change log since v1.8.2。六、准备 Helm Chart同步版本号与 CRDKruise 的安装方式之一是通过 Helm Chart 部署因此在发布镜像之前需要先在 Charts 仓库中准备新版本的 Chart。原文档列出的准备步骤有两条在 Chart 仓库openkruise/charts 的versions/kruise目录中创建新的 Chart 版本更新version和appVersion基于发布产物YAML更新 Chart 内的 CRD 与 Kubernetes 资源。第 2 步更新 CRD在主仓库中有对应的自动化脚本scripts/generate_helm_crds.sh。该脚本的完整工作流是校验本地是否安装了yq用于解析 YAML并创建临时目录用kustomize build config/crd把 config/crd 下的所有 CRD 清单渲染成一份合并的 crds.yamlconfig/crd的 kustomization 聚合了 config/crd/bases 下各apps.kruise.io_*.yaml、policy.kruise.io_*.yaml基础文件与 config/crd/patches 中的 webhook/cainjection 补丁按---分隔符把合并清单拆分回单个 CRD 文件用yq提取每个 CRD 的spec.group与spec.names.plural按group_plural.yaml的规则重命名例如apps.kruise.io_clonesets.yaml在每个文件首尾包上 Helm 模板条件语句{{- if .Values.crds.managed }} --- ... {{- end }}这样 Chart 用户可以通过crds.managed开关控制是否托管安装这些 CRD。也就是说每次发布时运行make generate_helm_crds对应 Makefile 中的generate_helm_crds: scripts/generate_helm_crds.sh目标就能基于当前代码的 API 定义重新生成与版本一致的 CRD 模板文件从而保证 Helm Chart 中的 CRD 与代码版本严格对齐避免Chart 里的 CRD 落后于代码这类经典发版事故。七、发布新 Helm ChartPublish Action 自动打包Chart 准备好之后向 Charts 仓库提交 PR 合并随后仓库的 Publish Action 会自动完成打包与发布。原文档明确指出这一步引用的是 Charts 仓库中的 Publish actionPR 合并 → 触发 publish 工作流 → 自动打包并发布 Chart。发布后的 Chart 一般会发布到 Chart 仓库对应的 Helm 仓库索引中用户侧即可通过标准的 Helm 流程安装/升级helm repo add openkruise https://openkruise.github.io/charts helm repo update helm upgrade -i kruise openkruise/kruise --version 新版本号需要提醒的一点是Helm Chart 的versionChart 版本与appVersion对应 Kruise 版本都要更新前者决定 Helm 仓库中的可安装版本后者决定部署出来的 Kruise 实际版本与镜像 tag两者不一致会造成装的是新 Chart、跑的是旧镜像的割裂。八、为卸载兜底helm_hook 的 CR 残留检查虽然发布流程本身不直接涉及卸载但 Kruise 的发布治理中有一个与 Helm 生命周期强相关的防护机制值得一并说明因为它直接影响用户升级/卸载 Kruise 的安全性并且已经在 CHANGELOG.md 的 v1.8.0 Upgrade Notice 中被作为关键变更记录Prior to Kruise 1.7.3,helm uninstallis ahigh-riskoperation that deletes Kruise, its CRDs, and associated CRs. Starting from Kruise 1.7.3, it uses a pre-delete hook to check for existing Kruise CRs before uninstallation and blocks the process to prevent accidental deletion.Kruise 1.7.3 之前helm uninstall属于高风险操作会连同 CRD 与 CR 一起删除从 1.7.3 起通过 pre-delete hook 在卸载前检查集群中是否仍存在 Kruise CR有残留则阻止卸载。这个 pre-delete hook 的实现就在主仓库的 cmd/helm_hook/main.go它通过 Kruise 生成的 clientsetpkg/client/clientset/versioned遍历 CloneSetv1alpha1、Advanced StatefulSetv1alpha1/v1beta1与 Advanced DaemonSetv1alpha1只要任意一类资源仍有残留len(items) 0 || continue ! 就log.Fatalln(...)直接终止卸载流程只有确认集群干净cluster is clean, ready to delete kruise才放行。该 hook 的镜像由 Dockerfile_helm_hook 构建基于 golang 1.20 构建cmd/helm_hook/main.go二进制最终镜像内仅保留该可执行文件对应 Makefile 中的docker-build-hook目标。这套机制确保发布的新版本在 Helm 侧具备卸载前自检能力也是发布流程中更新 Kubernetes 资源这一准备项背后隐含的工程背景——Kruise 的 Chart 并不只是简单的清单打包还内嵌了对用户数据安全的保护逻辑。九、筹备下一个版本Shipping Cycle 与 Milestone当前版本发布接近尾声时需要为下一个版本提前铺路。原文档给出了两件事创建新的 shipping cycle依据 RELEASES.md 的发布治理约定每 23 个月一个周期在项目设置中为下一个发布周期设定目标日期通常定在上一个周期之后的 23 个月内创建新的 Milestone在 GitHub Milestones 中新建一个面向下一版本的 milestone用来归集下一个版本的变更。Milestone 在 Kruise 的发布协作中承担着版本看板的角色RELEASES.md 明确要求每个已关闭的 issue 和 PR 都应挂到对应 Milestone 上从而形成这个版本会包含什么、预计什么时候发的完整视图同时它也明确提醒Milestone 上的日期只是预期实际发布日期可能顺延。对贡献者而言把 PR 挂到正确的 Milestone 不仅方便 maintainers 在发布时快速汇总变更Changelog 素材的来源之一也能让社区对每个版本的边界有清晰预期。十、多渠道公告触达全球与本地社区最后一步是发布公告。原文档列出的渠道包括SlackKubernetes Slack 的#openkruise频道注册入口见 RELEASES.md 的 Support 小节其中还列出了 GitHub Discussions 用于每个新版本的讨论钉钉DingTalk搜索群号 23330762中文社区微信群WeChat面向国内用户的即时沟通渠道。公告内容通常附带新版本的 Release 链接与关键变更摘要让使用者第一时间知道该升级了、升级要注意什么。这一步虽然简单却是发布闭环中面向社区的最后一块拼图——没有它再完整的发布流程也无法触达用户。小结Kruise 发布流程全景把整个流程串起来看Kruise 的一次完整发布包含八个环节环节动作仓库证据版本号规划基于上一版本推导下一版本号RELEASES.mdSemVer 23 个月周期Changelog在 CHANGELOG.md 新增版本段落按 Upgrade Notice / Key Features / Bug Fixes 分节文档快照Fork 文档仓库yarn run docusaurus docs:version VERSIONdocs/tutorial、docs/proposals 为文档素材创建 Release打 tag 触发镜像构建.github/workflows/docker-image.yaml Makefiledocker-multiarchRelease 正文使用统一模板版本差异 模块分节 致谢RELEASE-PROCESS.md 模板原文准备 Chart更新version/appVersion重新生成 CRD 模板scripts/generate_helm_crds.shmake generate_helm_crds发布 ChartPR 合并后由 Publish Action 自动打包Charts 仓库 publish.yaml配合 cmd/helm_hook/main.go 的卸载保护公告Slack / 钉钉 / 微信群同步发布RELEASES.md Support 小节这套流程的精髓在于一处定版本处处引版本镜像 tag 取自 GitHub Release 的 tag 名Chart 的 appVersion 对应 Kruise 版本CRD 模板由代码生成、与 API 定义强一致卸载环节又有 helm_hook 兜底。对于想要在自研 Kubernetes 组件上建立正规发版机制的技术团队Kruise 的这份流程文档与其仓库内的工程实现是一份非常值得对照参考的范本。赞分享云原生容器编排微服务运维【免费下载链接】kruiseAutomated management of large-scale applications on Kubernetes (incubating project under CNCF)项目地址https://gitcode.com/gh_mirrors/kr/kruise点击查看免费下载相关推荐ExternalDNS 发布流程全指南镜像发布、版本规范与 Helm Chart 发布ExternalDNS 发布流程全指南镜像发布、版本规范与 Helm Chart 发布 本篇技术指南以 ExternalDNS 项目官方发布文档为主体结合仓云原生Agones 发布流程全解析从版本分支、镜像构建到 SDK 上线的完整工程实践Agones 发布流程全解析从版本分支、镜像构建到 SDK 上线的完整工程实践 Agones 是基于 Kubernetes 的专用游戏服务器托管与弹性伸缩平台游戏开发云原生Descheduler 发布指南从预发布准备到镜像提升与 Helm Chart 发布的完整流程Descheduler 发布指南从预发布准备到镜像提升与 Helm Chart 发布的完整流程 本文基于 Kubernetes SIG Scheduling云原生运维上一篇Aptos Protos TypeScript 使用指南用 aptos-labs/aptos-protos 消费 Aptos 链上数据下一篇AWS Provider 数据源 aws_bedrockagent_agent_versions 完全指南查询 Amazon Bedrock Agent 的版本列表创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考