本指南以 helm/charts 项目根目录 README.md 为核心，系统讲解官方 Helm Chart 仓库（stable与incubator）的定位、安装方式、仓库结构、贡献与维护流程，以及该项目已进入归档期的迁移策略。读者读完本文后，将能熟练地在 Helm 2/3 中启用官方 Chart 仓库、判断 Chart 的成熟度与稳定性、按技术规范提交或审查 Chart，并为迁移到 Artifact Hub 生态做好准备。

一、项目定位：官方 Chart 仓库的现状与归档

Helm Charts 是 Kubernetes Helm 生态中最早的官方 Chart 集中地，其根 README.md 明确说明：该 GitHub 项目是 Helmstable和incubator两个 Chart 仓库的源码所在地，通过 GitHub Pages 承载打包发布后的 Chart Repository。如今该项目已不再处于活跃开发阶段，仅作为存档（archive）保留。

需要特别注意的是，README 开头的警示图标直接标注了 "This project is no longer supported"——这意味着：

• 新 Chart 已不再被接受进入stable或incubator；
• 社区可继续提交既有 Chart 的补丁（在归档时间线内），由 Chart OWNERS 视时间评审；
• 该仓库面向apiVersion: v1的 Chart（Helm 2 与 Helm 3 均可安装），不面向apiVersion: v2（仅 Helm 3 可安装）的 Chart。

当前 Helm 生态的权威 Chart 来源已迁移至Artifact Hub（一个聚合分布式 Chart 仓库的平台），本文所述仓库的历史价值与迁移参考意义远大于继续新增使用。

二、弃用与归档时间线（Deprecation Timeline）

根 README 给出了与 Helm 2 支持计划同步的正式弃用时间表，这是理解该仓库一切现状的关键：

这一时间线给了 Chart OWNERS、组织、团体或个人 9 个月的窗口期，把各自维护的 Chart 迁移到新的 Helm 仓库，并在下架前将新仓库登记到 Helm Hub。

三、快速上手：安装官方 Chart

在仓库仍可用时期，安装官方 Chart 的方式非常简单——stable仓库是 Helm v2 的默认仓库：

$ helm install stable/<chart>

例如在 stable/drupal/README.md 中记载的经典用法：

$ helm install my-release stable/drupal

该命令会以默认配置在 Kubernetes 集群中部署 Drupal，同时自动带上它所依赖的 Bitnami MariaDB Chart（作为 Drupal 应用的后端数据库）。这也是本仓库大多数 Chart 的通用形态：应用 Chart 通过requirements.yaml声明依赖，安装时一并拉起。

查看本仓库 stable/ 与 incubator/ 目录可以发现，每个 Chart 均遵循同一套标准布局：Chart.yaml（元数据）、values.yaml（可配置参数及默认值）、templates/（含_helpers.tpl、NOTES.txt与各资源模板）、README.md（文档说明）。例如 stable/drupal/Chart.yaml 与 incubator/kafka/Chart.yaml 均标注了deprecated: true，并且前者声明了apiVersion: v1、engine: gotpl，这正是该仓库面向 Helm 2 时代 Chart 格式的直接证据。

四、Helm 3 下启用 stable 与 incubator 仓库

Helm v3 不再默认携带任何 Chart 仓库，需要手动添加。根 README 给出了官方命令：

启用stable仓库：

$ helm repo add stable https://charts.helm.sh/stable "stable" has been added to your repositories

启用incubator仓库：

$ helm repo add incubator https://charts.helm.sh/incubator "incubator" has been added to your repositories

添加完成后即可用helm search incubator浏览 incubator 中的 Chart 列表。

本仓库 test/ct.yaml 展示了官方 CI 中如何引用这两个仓库源：

remote: k8s target-branch: master chart-dirs: - stable - incubator excluded-charts: - common chart-repos: - stable=https://charts.helm.sh/stable - incubator=https://charts.helm.sh/incubator helm-extra-args: --timeout 600

从该配置可以看到：CI 对stable与incubator两个目录同时做校验，common这类基础工具 Chart 被排除在发布之外，且每个安装测试设置了 600 秒超时。这也印证了 README 中"本仓库通过 CI 流程管理 Chart 发布"的说法。

五、Chart 格式：撰写前的必修课

根 README 建议，编写自己的首批 Chart 前，先参考官方提供的alpine 示例 Chart，熟悉标准 Chart 格式。其要点包括：

• Chart.yaml声明名称、版本、依赖与应用版本；
• values.yaml承载全部可配置参数及默认值；
• templates/目录存放渲染为 Kubernetes 资源的 Go 模板（含_helpers.tpl公共辅助模板与NOTES.txt安装后提示）。

以 stable/drupal/values.yaml 为例，可以看到一个成熟 Chart 的参数设计模式：镜像参数（image.registry/repository/tag/pullPolicy）、应用参数（drupalUsername、drupalEmail、drupalProfile）、外部依赖参数（externalDatabase.*、mariadb.*）、网络参数（service.type、ingress.*）、持久化参数（persistence.*）、资源配额（resources）与可观测性参数（metrics.*）分层组织，并配有大量注释说明默认值与取值范围。这是判断一个 Chart 是否达到官方仓库质量标准的最直观样本。

六、仓库结构：stable 与 incubator 双轨机制

本仓库将 Chart 划分为两个目录，这是理解其治理逻辑的核心：

• stable/：满足 CONTRIBUTING.md 中"技术需求"（Technical Requirements）全部标准的 Chart，与 Chart Repository 中最新打包版本一一对应（仓库内可能还保留着更早的历史版本）；
• incubator/：尚未达到上述标准的 Chart。设立此目录的目的是让不成熟的 Chart 先被共享、改进，直到准备好被移入stable。

从 incubator 晋升 stable 的方式很直接：由 Chart 维护者发起一个移动 Chart 文件夹的 Pull Request。而 README 也明确指出，stable/目录中的 Chart 与 Chart Repository 中最新打包版本一致，可供用户以helm install stable/<chart>直接安装。

七、Chart 进入官方仓库的验收标准

结合根 README 与 CONTRIBUTING.md，一个 Chart 要进入stable，必须同时满足技术需求与文档需求。

技术需求（Technical Requirements）

• 所有 Chart 依赖也应独立提交；
• 必须通过helm lint校验；
• 必须能使用默认值成功安装（helm install .），且所有 Pod 进入 running 状态（若必需值缺失，则NOTES.txt必须给出进一步指引）、所有 Service 至少有一个 endpoint；
• 必须提供 Chart 所用镜像的源码 GitHub 仓库地址，且镜像不应存在重大安全漏洞；
• 必须紧跟最新的稳定版 Helm/Kubernetes 特性，优先使用 Deployment 而非 ReplicationController；
• 应遵循 Kubernetes 最佳实践，包括：尽可能包含健康检查、允许配置资源 requests/limits；
• 如适用，必须提供数据持久化方案；
• 必须支持应用升级与应用配置自定义，提供安全的默认配置；
• 不得使用 Kubernetes 的 alpha 特性；
• 必须包含 NOTES.txt 说明安装后如何使用应用；
• 遵循 Helm 官方最佳实践（尤其是 labels 与 values 规范）。

文档需求（Documentation Requirements）

• 必须包含详尽的README.md：Chart 简介、前置条件或需求、以及values.yaml中各项参数及其默认值的说明——stable/drupal/README.md 正是这一标准的范例，其中用完整的参数表格逐项列出了 40 余个配置项；
• 必须包含简短的NOTES.txt：安装后的相关信息、如何访问 Chart 提供的应用或服务。

合并与发布流程（Merge Approval and Release Process）

Chart 变更提交后，由维护者发起 CI 校验任务验证技术需求，至少一位维护者给出 LGTM（Looks Good To Me）后才能合并；合并后 CI 自动运行发布任务，将 Chart 打包并发布到 Google Storage 存储桶（gs://kubernetes-charts）。本仓库 REVIEW_GUIDELINES.md 则记录了评审流程的具体细则。

八、贡献、维护与信任机制

成为 Chart 维护者（Owning and Maintaining A Chart）

单个 Chart 可由一个或多个 GitHub 用户共同维护。要获得某 Chart 的合并权限，需依次完成三步：

1. 在 Chart 的Chart.yaml中被列为 maintainer（若缺少赞助者，可联系既有维护者或 OWNERS 中的仓库 OWNERS）；
2. 被邀请（并接受邀请）为本仓库的只读协作者，这是@k8s-ci-robot进行 PR 评论交互的前提；
3. 在 Chart 目录下添加OWNERS文件，分别列出 reviewers 与 approvers 的 GitHub 用户名（根目录的 OWNERS 文件即为仓库级维护者名单，包含 approvers 与 emeritus 两组），并将OWNERS追加到.helmignore中。

完成这三步后，Chart 的 approver 即可按 REVIEW_GUIDELINES.md 中的指引合并 Pull Request。

信任协作者（Trusted Collaborator）

pull-charts-e2e测试（实际安装 Chart 进行验证）是 PR 合并前的必过关卡。该测试对 Helm Org 成员与 Chart 仓库协作者自动运行；对普通但可信的贡献者，则通过"信任协作者"机制获得自动测试资格，并可用/ok-to-test评论触发其他 PR 的测试。成为信任协作者有两条路径（满足其一即可）：

1. 是 Kubernetes GitHub org 成员且公开其 org 成员身份；
2. 获得本仓库根 OWNERS 文件所列 Chart 维护者的赞助。

申请流程为：提交 issue 申请成为信任协作者，随后由 Helm Chart 维护者将其添加为只读协作者。

评审流程与陈旧清理

Pull Request 与 Issue 在 30 天无活动后自动变为 stale，再经过 30 天变为 rotten，rotten 满 30 天后被自动关闭——这是 Kubernetes GitHub 组织所有仓库的标准 stale 处理流程。

九、支持的 Kubernetes 版本策略

该仓库的策略是支持 Kubernetes最新小版本及其前一个版本。例如若最新小版本是 1.8，则支持 1.7 与 1.8；更早版本虽不在目标支持窗口内，Chart 仍可能正常工作。

为达成这一目标，模板中对象的 API 版本应同时兼容最新与上一个小版本。这一要求在 stable/drupal/README.md 的升级章节有具体体现：Drupal Chart 6.0.0 将 Deployment 的apiVersion从旧版本升级到apps/v1，由于 GroupVersionKind（GVK）变更被 Kubernetes 视为兼容性破坏，无法原地升级，因此以主版本号变更来标记这一破坏性变化。

十、中国用户的替代方案

根 README 专门设有 "Happy Helming in China" 章节：对于身处中国的用户，直接使用上游 Helm Charts 可能遇到网络问题（例如镜像托管于gcr.io、quay.io，Chart 托管于googleapis.com等），此时可使用自动同步并在每个 Chart 中替换不可访问镜像与仓库地址的镜像仓库。该镜像仓库由社区维护，同步了本项目的全部 Chart 并替换了不可达的资源地址。

十一、面向未来的迁移建议

结合归档时间线与本仓库的实际状态（stable与incubator下各 Chart 的Chart.yaml均已标记deprecated: true，如 stable/mysql/Chart.yaml），给仍在使用的用户的迁移路径建议是：

1. 存量使用：仍可查阅本存档仓库学习 Chart 结构、参数设计与模板写法，但不应再期待新功能与普通缺陷修复；
2. 新部署：优先通过 Artifact Hub 检索仍在维护的 Chart 发行版，例如 Bitnami 维护的 Chart 已迁移至独立仓库，安装方式从stable/<chart>变为bitnami/<chart>（如 stable/drupal/README.md 所述，helm repo add bitnami ...后即可用helm install my-release bitnami/<chart>，Helm 2 则需加--name参数）；
3. 已有部署升级：可执行helm repo add bitnami ...后用helm upgrade my-release bitnami/<chart>迁移到仍在维护的 Chart 版本；
4. 自托管 Chart：参照本文第六、七节的标准，将自身维护的 Chart 迁移到自有仓库，并在 Artifact Hub 登记，完成从本仓库生态的过渡。

总而言之，helm/charts 是 Helm 2 时代官方 Chart 治理的完整范本——从stable/incubator双轨评审机制、技术验收标准，到 OWNERS 维护与 CI 发布流水线，至今仍值得 Chart 作者与平台建设者参考；而它的归档历程，也恰好是 Helm 生态从集中式仓库走向 Artifact Hub 分布式聚合时代的缩影。