1. 为什么“可复用部署包”比“会写 YAML”更重要？
YAML 是表达语法，不是交付资产。你真正需要的能力有三件事：
- 复用：不要每个服务都重新发明一套部署逻辑。
- 参数化：同一个服务在不同环境差异可控。
- 可审计与可回滚：render 后的结果、变更来源、回滚点必须能解释。
提醒：当你发现“复制粘贴”已经超过两次，就该把它提炼成 chart 或 base/overlay。
2. Helm：把模板与值变成可升级的发行版（Chart）
2.1 Helm 的基本对象：Chart、Release、Values、Templates
- Chart：一组文件组成的包（meta + 默认值 + 模板）。
- Values：用户给模板的参数（values.yaml + -f 指定文件）。
- Templates：渲染逻辑（Go template 语法）。
- Release：一次安装/升级在集群中的“实例状态”。
2.2 Helm 渲染管线：values 驱动“生成最终 manifests”
Helm 的关键理解是：它不是在集群里“保持模板”，而是在安装/升级时渲染出一组最终 YAML，交给 Kubernetes 去创建资源。 所以可审计性来自“渲染结果 + release 记录 + values 输入”。
图 1：Helm 的核心是“渲染”。你提供 values，模板生成最终 manifests，Release 决定升级与回滚依据。
3. Kustomize：用补丁叠加构建最终 manifests（base/overlay）
3.1 Kustomize 的基本思想：不写模板，写“变更”
Kustomize 的哲学是：尽量避免模板逻辑，让差异用 overlay 的补丁表达。 这使得最终输出是直观的 YAML，可以更容易做审计与比对。
- base：通用版本（例如应用核心资源）。
- overlay：环境差异层（dev/staging/prod 的 patches、namePrefix 等）。
- patches：战略合并/JSON patch，让你只改必要字段。
- generators：ConfigMap/Secret 等由文件生成并随 overlay 变化。
图 2：Kustomize 用 overlay 叠加 base，只改必要差异；最终输出就是可审计的 manifests。
4. Helm vs Kustomize：如何选择，避免“选工具而不是选架构”
选择 Helm 或 Kustomize，本质是选择“表达差异”的方式。 当差异简单、可解释、可补丁化，Kustomize 往往更稳；当差异复杂，需要参数驱动的生成逻辑，Helm 更灵活。
经验法则：如果你写到需要复杂逻辑来理解最终 YAML，就该反思：这是不是已经超过 Kustomize 的舒适区，或者需要把逻辑提炼到模板/库中？
4.1 对照维度（建议用来做团队决策）
- 可读性：Kustomize 输出更直观；Helm 需要渲染理解。
- 参数复杂度：Helm values 适合复杂参数；Kustomize patches 适合固定结构差异。
- 审计与 diff：Kustomize 天然更好做 diff；Helm 需配合 template 输出审计。
- 升级与回滚：Helm release 有内建历史；Kustomize 你通常依赖 Git commit 与外部机制回滚。
图 3：选择不是站队，而是用审计/差异复杂度/回滚机制三问做架构决策。
5. 混用模式：Helm 做“骨架”，Kustomize 做“环境皮肤”
在真实团队里，经常出现一个折中：用 Helm charts 负责生成通用骨架（尤其包含复杂依赖/可选组件）， 用 Kustomize overlays 在不同环境做补丁与注入（名字、资源规格、配置开关、副本策略）。
- Helm：解决“可选模块与依赖组合”的生成问题。
- Kustomize：解决“环境差异、命名隔离与配置补丁”的治理问题。
- GitOps：用 Git 提交渲染/合成后的期望状态来做晋级与审计。
图 4：混用模式把“复杂生成”交给 Helm，把“环境差异”交给 Kustomize，再由 GitOps 晋级与漂移治理完成交付闭环。
6. 可复用部署包的工程化规范（让团队用得起来）
- 接口契约：values schema（Helm）或 patch 约定（Kustomize）要稳定；变更要有版本。
- 默认安全：生产默认启用严格策略（resources、probe、securityContext、network policy 等）。
- 渲染/合成测试：用 CI 生成 rendered manifests 并做 lint（例如 helm lint、kubeconform 等思路）。
- 依赖锁定：Helm dependencies 与 chart versions 固化，避免“明天渲染结果不同”。
- 审计友好：输出 diff 可读；PR 中展示 rendered 或 kustomize output，便于 review。
- 回滚演练：Helm rollback 或 GitOps 回滚要在 SOP 里可执行、可验证。
总结：Helm/Kustomize 不是“替代 YAML”，而是把 YAML 变成“可产品化的部署语言”。你在做的，是平台工程里最核心的资产：可复用部署包。