企业官网建设流程全解析

• 云原生
• 后端
• 容器编排
• 弹性伸缩

本文以 Kubernetes Metrics Server 仓库的官方发布文档（RELEASE.md）为主体，结合仓库中的 Makefile、OWNERS、cloudbuild.yaml、Helm Chart 等源码与配置证据，完整梳理 Metrics Server 主版本（Release）与 Helm Chart 两条发布流程，并深入解释make release-tag、CI 镜像推送、发布清单生成、OWNER 审批等每个环节背后的实现细节。读完本文，你将掌握 Kubernetes 生态项目典型的"代码 + 镜像 + 清单 + Chart"四层发布模型，并能在需要为 Metrics Server 做贡献或管理类似 SIG 项目发布时，准确执行每一步操作。

一、发布模型总览：按需发布而非固定周期

Metrics Server 采用"按需发布"（released on an as-needed basis）策略，即没有固定的版本节奏，只要仓库中存在需要交付的变更（例如新功能、Bug 修复或安全补丁），维护者就可以发起一次发布。这一点与很多按固定节奏发版的组件不同，意味着整个发布流程是事件驱动的：从提出 issue、通过 OWNER 审批、合并版本号 PR、打 tag 构建镜像，到发布 GitHub Release 与 Helm Chart，每一步都由明确的触发条件衔接。

从仓库结构看，发布流程涉及三类交付物，缺一不可：

仓库当前发布状态可从 charts/metrics-server/Chart.yaml 读出：version: 3.14.0、appVersion: 0.9.0，即 Metrics Server 应用当前为 0.9.0，对应 Chart 3.14.0，两者遵循各自独立的版本序列（详见后文 Chart 发布小节）。

二、Metrics Server 主版本发布流程（10 步）

RELEASE.md 将主版本发布拆解为 10 个步骤，下面逐一展开，并补充每个步骤在仓库中的落地依据。

第 1 步：提出发布提案 Issue

由维护者（或社区成员）创建一个 Issue，提议发布一个新版本。Issue 中必须包含自上次发布以来的变更日志（changelog），通常通过仓库的 commit 对比视图生成。这一步的核心价值是让整个社区在发布前对"这个版本里到底有什么"形成共识，同时也是后续公告与用户升级时的重要参考依据。

第 2 步：至少一名 OWNER 审批（LGTM）

发布提案必须获得至少一位 OWNER的 LGTM（Looks Good To Me）才能继续。在 Kubernetes 生态中，OWNERS 文件定义了项目的审批权限矩阵。查看本仓库的 OWNERS 文件：

approvers: - serathius - dgrisonnet reviewers: - RainbowMango - dgrisonnet - serathius - slashpai - yangjunmyfm192085

可以看到approvers列表（当前为 serathius、dgrisonnet）拥有批准发布的权限。这个设计保证了发布动作是受控的——只有项目核心维护者才能推进版本交付，避免未经审核的变更进入用户集群。

第 3 步：合并"版本号硬编码"PR

发布前需要创建一个 PR，把硬编码在代码中的版本号提升到新版本，并合并到主干。版本号在仓库中并非单一存在，从源码结构看至少体现在以下几处：

• Chart 元数据：appVersion字段（见 charts/metrics-server/Chart.yaml），如appVersion: 0.9.0；
• 二进制构建参数：Makefile 通过VERSION_LDFLAGS将GIT_TAG（git describe --abbrev=0 --tags的结果）注入k8s.io/client-go/pkg/version包，使metrics-server --version能输出准确的版本信息（见 Makefile 第 59-61 行）；
• 文档兼容性矩阵：README 中的 Compatibility Matrix 记录了各版本对应的 Kubernetes 支持范围。

这一步骤完成后，主干代码即"准备好"被打上新的版本号。

第 4 步：创建 GitHub Release 草稿

OWNER 在 GitHub 上创建一个draft（草稿）状态的 Release。草稿化的目的是：先让 CI 完成镜像构建与推送，等一切就绪后再正式对外发布，避免出现"版本已公开但镜像不可用"的中间状态。

第 5 步：创建 Helm Chart 发布 Issue

由于 Chart 发布与主版本发布是两条并行流程（详见第四节），RELEASE.md 要求 OWNER 在此刻专门创建一个 Issue，用于启动对应版本的 Chart 发布，并用该 Issue 记录整个 Chart 发布过程，形成可审计的轨迹。

第 6 步：打标签并触发镜像构建

OWNER 在本地执行：

GIT_TAG=$VERSION make release-tag

其中$VERSION形如v0.9.0（注意 Kubernetes 风格标签带v前缀）。查看 Makefile 中release-tag目标（第 125-128 行）：

.PHONY: release-tag release-tag: git tag $(GIT_TAG) git push origin $(GIT_TAG)

它实际做了两件事：在本地打 git tag并推送到远端 origin。tag 推送后，仓库的 CI（prow.k8s.io）会被触发，开始构建并推送新镜像到gcr.io/k8s-staging-metrics-server（staging 仓库）。

镜像构建与推送的具体逻辑同样在 Makefile 中可见：

• container：基于go.mod中的 Go 版本拉取基础镜像并构建（第 86-90 行）；
• push：把镜像打上GIT_TAG标签并推送（第 105-107 行）；
• push-all/push-multi-arch：为amd64 arm arm64 ppc64le s390x五个架构分别推送镜像，并用 docker manifest 创建多架构清单（第 109-120 行）。

而驱动这套流程的 CI 配置在 cloudbuild.yaml：它由 Google Cloud Build 执行make push-all，并注入GIT_TAG=$_PULL_BASE_REF、GIT_COMMIT=$_PULL_BASE_SHA——这正是 tag 推送后自动构建镜像的"发令枪"。

第 7 步：向 registry.k8s.io 推广镜像

staging 仓库的镜像被验证后，还需要一个 PR 将其发布到官方镜像仓库registry.k8s.io。该 PR 创建在kubernetes/k8s.io仓库的registry.k8s.io/images/k8s-staging-metrics-server/images.yaml中。这是 Kubernetes 项目的标准镜像晋升流程：staging（临时）→ 官方 registry，确保只有通过 CI 验证的镜像才能进入用户可见的官方仓库。这一步完成后，用户便可通过registry.k8s.io/metrics-server/metrics-server:v0.9.0拉取镜像。

第 8 步：发布 GitHub Release（清单自动附加）

一切就绪后，OWNER 正式publish该 GitHub Release。发布后，CI 会自动把发布清单附加到 Release 页面——这正是用户能够执行kubectl apply -f https://.../releases/latest/download/components.yaml的原因。

清单由 kustomize 从仓库渲染生成。在 Makefile 的release-manifests目标（第 130-135 行）中可以看到三类清单的来源：

release-manifests: mkdir -p $(OUTPUT_DIR) kubectl kustomize manifests/overlays/release > $(OUTPUT_DIR)/components.yaml kubectl kustomize manifests/overlays/release-ha > $(OUTPUT_DIR)/high-availability.yaml kubectl kustomize manifests/overlays/release-ha-1.21+ > $(OUTPUT_DIR)/high-availability-1.21+.yaml

其中components.yaml对应单副本标准安装，high-availability.yaml与high-availability-1.21+.yaml对应高可用安装（后者用于 Kubernetes v1.21+，差异在于 PDB 的 API 版本，见 manifests/overlays/release-ha-1.21+）。这些 overlay 最终引用 manifests/base 下的基础资源（Deployment、RBAC、Service、APIService 等），例如 manifests/base/deployment.yaml 中默认的参数为--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname、--metric-resolution=15s等。

第 9 步：发送公告邮件

版本发布后，向 Kubernetes SIG Instrumentation 邮件组kubernetes-sig-instrumentation@googlegroups.com发送公告，主题格式为：

[ANNOUNCE] metrics-server $VERSION is released

公告是对社区的正式通知，包含版本号与关键变更，方便用户评估是否升级。

第 10 步：关闭发布 Issue

最后关闭第 1 步创建的发布提案 Issue，一次完整的发布闭环结束。

三、版本发布中的三个关键实现细节

3.1 版本号如何嵌入二进制

在 Makefile 第 60-61 行，构建时通过 ldflags 注入版本信息：

VERSION_LDFLAGS:=-X $(PKG)/version.gitVersion=$(GIT_TAG) -X $(PKG)/version.gitCommit=$(GIT_COMMIT) -X $(PKG)/version.buildDate=$(BUILD_DATE) LDFLAGS:=-w $(VERSION_LDFLAGS)

GIT_TAG来自git describe --abbrev=0 --tags（最近的 tag），GIT_COMMIT来自git rev-parse。这意味着即使是本地开发构建，metrics-server --version也能追溯到对应 commit，为发布后的排障提供了关键依据。

3.2 发布前必须通过质量门槛

虽然 RELEASE.md 没有显式列出测试步骤，但从仓库工程化配置看，合并发布相关 PR 前会经过严格校验：Makefile 中的verify目标（第 223-224 行）聚合了 license 检查、golangci-lint、TOC 检查、依赖校验（go mod verify+go mod tidy）、OpenAPI 生成物校验与结构化日志检查；test-unit（第 148-149 行）会运行./pkg/... ./cmd/...的全部单元测试。这些检查保证了发布出去的是经过验证的代码。

3.3 多架构支持是发布的一部分

发布不只是打一个 tag 那么简单，Makefile 第 23 行定义了ALL_ARCHITECTURES=amd64 arm arm64 ppc64le s390x，第 26-30 行又扩展了 darwin/windows 平台二进制，push-all会为每个架构构建镜像并最终生成多架构 manifest。因此，registry.k8s.io/metrics-server/metrics-server:v0.9.0是一个多架构镜像，可运行在绝大多数 Kubernetes 节点架构上。

四、Helm Chart 发布流程（5 步）

Metrics Server 的 Helm Chart 作为仓库内独立组件维护（位于 charts/metrics-server），其发布流程与主版本解耦、但又保持同步节奏。Chart 变更遵循 Keep a Changelog 规范，记录在 charts/metrics-server/CHANGELOG.md 中。

第 1 步：提出 Chart 发布 Issue

创建一个提议发布新 Chart 版本的 Issue。这个 Issue 同时也是整个 Chart 发布过程的文档载体，所有后续动作都在其中记录。

第 2 步：判断目标分支

大多数情况下，最新 Metrics Server 版本的 Chart 发布可以直接在master分支进行。但有两种情况需要将 PR 指向发布分支（release branch）：

• 该版本是backport（回移植）；
• master分支上的 Chart 与要发布的版本不再兼容（例如 master 上已包含尚未发布的改动）。

这个设计保证了 release 分支上的 Chart 永远与对应 Metrics Server 版本匹配。

第 3 步：更新 Chart.yaml 并提交 PR

创建 PR 更新 charts/metrics-server/Chart.yaml 中的两个字段：

• appVersion：Metrics Server 应用版本（如0.9.0）；
• version：Chart 自身版本（如3.14.0，遵循 SemVer）。

注意 Chart 版本与 appVersion 是两套独立序列：Chart 可以因为模板改动（如 CHANGELOG.md 中记录的namespaceOverride、cert-manager annotations 修复等）单独升版，而无需升级 Metrics Server 镜像。

第 4 步：CI 自动校验 Chart

PR 提交后，触发chart linting and testing GitHub Action对 Chart 进行校验。从仓库 CI 配置看，Chart 测试覆盖了多种 TLS 场景（见 charts/metrics-server/ci 下的ci-values.yaml、tls-certManager-values.yaml、tls-existingSecret-values.yaml、tls-helm-values.yaml），例如ci-values.yaml中通过--kubelet-insecure-tls参数验证无 TLS 场景下的渲染正确性。

第 5 步：合并并自动发布

PR 合并后，GitHub Action 会自动发布 Chart（推送到基于gh-pages分支的 Chart 仓库）。若发布发生在 release 分支，则需要手动关闭第 1 步创建的 Issue。

注意：README 明确建议不要直接引用master分支上的 Chart 代码，因为它可能包含自上次发布以来的未发布改动；查看 Chart 代码应使用 Chart release tag。

五、发布全流程时间线速查

为便于整体把握，将两条流程合并为一张时间线视图：

六、实践建议与常见问题

1. 发布不是一个人能完成的：从 OWNERS 和 RELEASE.md 可以看到，审批、打 tag、发布 Release、发公告分别由不同角色协作完成，个人 contributor 的贡献止步于"提交变更 + 提出发布 Issue"，后续动作均需 OWNER 执行。
2. 版本号一致性检查：合并版本号 PR 前，建议核对 charts/metrics-server/Chart.yaml 的appVersion与将要打的 git tag（v0.9.0）一致，避免出现镜像标签与代码版本错位。
3. 发布清单依赖 kustomize 产物：components.yaml等清单由 manifests/overlays/release 渲染而来，若发布后发现清单与预期不符，应先检查 base 与 overlay 的变更（manifests/base、manifests/components/release）。
4. 高可用清单的分版本：high-availability-1.21+.yaml与high-availability.yaml并存，安装时务必按集群版本选择，否则可能因 PDB API 版本差异导致部署失败（参见 README.md 的 High Availability 一节与 manifests/overlays/release-ha-1.21+）。
5. 关注 Chart 变更日志：用户升级 Chart 前，应阅读 charts/metrics-server/CHANGELOG.md 中的 Added/Changed/Fixed/Security 分类记录，例如 3.14.0 版本中 "cert-manager annotations 此前未渲染" 这类修复，往往影响 GitOps 工具（如 ArgoCD）的同步状态。

七、结语

Metrics Server 的发布流程完整呈现了 CNCF/Kubernetes 生态项目"按需发布 + OWNER 审批 + CI 驱动镜像构建 + 官方仓库晋升 + 独立 Chart 同步"的工程范式。以 RELEASE.md 的 10 步主流程与 5 步 Chart 流程为骨架，配合仓库中的 Makefile 与 cloudbuild.yaml 实现，你可以精确复现从make release-tag到用户kubectl apply -f components.yaml的完整链路。对维护者而言，这是交付新版本的行动清单；对贡献者而言，这揭示了"我的 PR 何时以及如何进入正式版本"的完整答案。

• 云原生
• 后端
• 容器编排
• 弹性伸缩