Helm Chart

1 三秒看懂

Helm Chart 是 Kubernetes 生态的标准化应用打包与交付格式，可类比为 Linux 世界的 apt/deb 包或 macOS 的 Homebrew Formula——它将云原生应用所需的全部 K8s 资源清单（Deployment、Service、ConfigMap、CRD 等）封装为一个可版本化、可复用、可共享的 Chart 包。

“chain-cloud/helm-chart”特指一条明确的技术线索：将 Helm Chart 作为 AI 算力调度、分布式训练、模型推理服务等场景的声明式交付载体——通过“云链化”方式把 GPU 驱动、训练框架、推理引擎、监控堆栈等数十个异构组件编排为一条可重复部署的软件供应链。从产业层面看，这意味着 AI 基础设施不再依赖手工运维脚本，而是进入“用 Chart 定义一切”的声明式工程阶段。

核心认知锚点：

• 本质：Kubernetes 应用的包管理器（K8s-native package manager）
• 关键动作：helm install / helm upgrade / helm rollback 三条命令即可完成应用全生命周期管理
• AI 场景的特殊性：区别于普通 Web 应用，AI Chart 通常需要编排 GPU 设备插件、分布式训练 Operator、模型网关、推理运行时等“有状态+异构硬件”组件，复杂度远超无状态微服务

2 三分钟产业解释

产业逻辑：AI 大模型训练和推理不是一个软件问题，而是一个“软件×硬件×调度”的系统工程。典型的大模型训练集群涉及至少 6 层技术栈——GPU 驱动与 CUDA 工具链、容器运行时、Kubernetes 调度层、分布式训练框架（PyTorch/TensorFlow）、数据加载管道、监控与日志系统。每层都有版本约束和配置依赖，手动部署不仅耗时，更是生产事故的主要来源。

Helm Chart 在这一链条中的角色是“标准化封装器”：将上述 6 层技术栈的部署知识编码为可执行的 YAML 模板，通过参数暴露（values.yaml）实现“一次封装，随处部署”。这与传统 shell 脚本的本质区别在于声明式治理——运维人员不再描述“怎么做”（创建、等待、检查），只描述“要什么”（GPU 类型、节点数、镜像版本），由 Helm 的 Release 机制保证状态收敛。

关键价值矩阵：

典型产业落地路径：

1. GPU 基础设施层：NVIDIA GPU Operator Chart 是事实标准，将 GPU 驱动、容器运行时插件、DCGM 监控统一打包
2. 训练平台层：Kubeflow 以复合 Chart 形式交付，内部依赖 Istio、Knative、MySQL 等子 Chart
3. 推理服务层：KServe、Seldon Core、Triton Inference Server 均提供官方 Helm Chart
4. MLOps 流水线：MLflow Tracking Server、Feast Feature Store 等以 Chart 形态持续发布

中国市场的差异化：国内云厂商（阿里云 ACK、华为云 CCE、腾讯云 TKE）均将 Helm Chart 作为 AI 组件市场的标准交付格式，但存在“半封闭化”趋势——云厂商的托管 AI 平台对外暴露的是控制台 UI，底层 Chart 并不完全开放给用户定制。这意味着对企业自建 AI 平台而言，直接使用社区 Chart 进行自主编排仍是主流选择；但在云上 AI 场景，Helm 正从“用户工具”转变为“云厂商内部交付引擎”。

需要纠正的常见错觉：认为 Helm 是“万能部署器”，可以替代 Ansible 等配置管理工具。实际上 Helm 解决的是 K8s 资源的编排问题，对节点层面的操作系统配置（内核参数、文件系统挂载）无能为力——这正是 GPU Operator 等 Chart 需要结合 DaemonSet + InitContainer 等底层机制才能覆盖 AI 基础设施全栈的原因。

3 技术原理

3.1 Chart 包解剖学

Helm Chart 是一套约定优于配置（Convention over Configuration）的目录结构规范。以典型的 AI 训练平台 Chart 为例：

kubeflow-train/
├── Chart.yaml              # Chart 元数据：名称、版本、K8s版本约束
├── values.yaml             # 默认参数（暴露给用户的配置入口）
├── values.schema.json      # 参数校验（JSON Schema，Helm 3.7+）
├── templates/              # Go Template 模板文件
│   ├── _helpers.tpl        # 可复用模板片段
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── configmap.yaml
│   └── NOTES.txt           # 安装后提示信息
├── crds/                   # 自定义资源定义（安装时优先创建）
│   └── tfjobs.kubeflow.org.yaml
├── charts/                 # 依赖子 Chart（或通过 Chart.yaml dependencies 声明）
└── .helmignore             # 打包时忽略文件列表

关键文件详解：

• Chart.yaml：声明 apiVersion（Helm 3 固定为 v2）、name、version（Chart 自身版本）、appVersion（应用版本），以及可选的 kubeVersion（兼容的 K8s 语义版本范围）、dependencies（依赖的 Chart 列表及版本约束）。
• values.yaml：这是用户与 Chart 的唯一交互界面。设计良好的 Chart 将一切可变因素（镜像仓库地址、GPU 类型、副本数、存储类）均暴露为 values 项，通过 values.stage 或 values.profile 等约定支持多环境覆盖。
• templates/：核心渲染层，采用 Go Template 语法。AI Chart 中常见的模式包括：条件渲染（{{ if .Values.gpu.enabled }}）、循环（{{ range .Values.workers.nodes }}）、函数管道（{{ .Values.image.tag | default "latest" }}）。

3.2 Release 生命周期管理

Helm 的核心数据模型是 Release——每次 helm install 或 helm upgrade 操作都会创建一个带版本号的 Release 对象，记录当前部署的 Chart 版本、用户传入的 values、渲染后的 K8s 资源状态。

Release 生命周期流转：
  install → deployed
  upgrade → superseded (上一版本)
  rollback → 回退到指定历史版本
  uninstall → 清理所有关联 K8s 资源

Helm 3 的重大架构变更是移除了 Tiller 服务端组件（Helm 2 时期常驻集群的 gRPC 服务）。当前 Helm 3 的 Release 元数据直接以 Secret 形式存储在部署的 Namespace 中，极简且消除了 Tiller 的 RBAC 安全隐患。对 AI 场景而言，这意味着 GPU 集群的 Helm 操作不再需要额外的集群管理员权限配置，符合细粒度安全治理要求。

AI 场景的特殊 Release 实践：

• 训练任务：每个实验性训练 Job 往往以独立 Release 部署（如 train-bert-exp-001），训练完成后 uninstall 回收 GPU 资源
• 推理服务：不同模型版本的推理服务作为独立 Release 并存（如 infer-llama-v1 和 infer-llama-v2），通过 Ingress 权重分流
• 基础设施：GPU Operator、存储 CSI、网络 CNI 等系统级 Chart 通常以固定 Release 名部署，不允许重复安装

3.3 依赖解析与组合模式

Helm 支持显式依赖声明（Chart.yaml dependencies）和隐式子 Chart 嵌入（charts/ 目录）两种方式。生产级 AI 平台 Chart 通常采用混合策略：核心依赖（如 GPU Operator）显式声明版本约束，内部定制的监控组件以子 Chart 形式嵌入。

依赖递进安装示例（Kubeflow 全景）：

kubeflow (umbrella chart)
├── cert-manager (证书管理)
├── istio (服务网格)
│   ├── istio-base
│   └── istio-ingress
├── knative (Serverless)
├── minio (对象存储，存模型文件)
├── mysql (元数据存储)
├── training-operator (TFJob/PyTorchJob CRD)
├── katib (超参调优)
└── kserve (推理服务)

Helm 的依赖锁文件（Chart.lock）记录所有子 Chart 的精确版本和 SHA 摘要，类似 Go 的 go.sum，确保依赖项在 CI/CD 中可复现。

3.4 仓库分发与签名

Helm Chart 的分发渠道演进方向明确：从传统的 HTTP Helm Repository（基于 index.yaml）向 OCI Registry（Open Container Initiative）迁移。OCI 兼容的容器镜像仓库（Docker Hub、Harbor、AWS ECR、阿里云 ACR）可直接用于存储和分发 Chart，复用容器镜像的安全扫描、签名和访问控制能力。

AI 场景下的 Chart 供应链安全愈发关键：

• 来源验证：通过 helm verify + GPG 签名或 OCI 的 cosign 签名，确保 Chart 未经篡改
• 内容扫描：对 Chart 内的容器镜像引用进行漏洞扫描（如 Trivy 集成），避免 GPU 驱动版本和 CUDA 版本的不安全组合
• 准入控制：部分企业要求在 Chart 安装前通过 OPA/Kyverno 策略校验，如禁止使用 latest 标签、强制指定 resources.limits 等——这对 GPU 资源管理尤为重要

4 关键参数

对于 AI 场景的 Helm Chart（以 Kubeflow、GPU Operator、KServe 为代表），以下参数是在生产部署中必须关注的“控制面参数”，决定了平台的性能、成本和稳定性边界。

4.1 GPU 资源参数

4.2 训练框架参数

4.3 推理服务参数

4.4 平台全局参数

参数治理最佳实践：

• 分层 values：将 values.yaml 分为 base.yaml（通用）、staging.yaml（预发布）、production.yaml（生产），通过 -f 参数叠加，避免参数散落在多个 Helm 命令中
• 加密敏感值：数据库密码、API Key 等使用 Sealed Secrets 或 Vault 插件注入，禁止明文写入 values 文件
• 参数校验：通过 values.schema.json 约束参数类型和取值范围，防止因为误拼写导致的不安全默认行为

5 技术路线

AI 场景下的 Helm Chart 技术路线存在三条主要演进方向，它们并非互斥，而是分别解决 AI 基础设施不同阶段的工程挑战。

5.1 路线 A：社区原生 Helm → Operator 增强

演进逻辑：原生 Helm 擅长有状态应用的首次部署与升级，但无法处理 Day-2 运维中的复杂状态管理（如 Grafana Dashboard 的自动注册、模型版本状态的协调）。CNCF 推荐将 Helm 与 Operator 模式结合——Helm 负责 Operator 本身的部署，Operator 通过自定义控制器（Controller）管理应用生命周期。

技术特征：

• 初期：纯 Helm Chart 部署，values 覆盖所有配置
• 中期：将 Day-2 运维逻辑下沉到 Operator，Helm 降级为“安装器”
• 成熟期：Operator 监听 CRD 变更自动调谐（Reconcile），Helm 仅维护初始部署

AI 场景对应：Kubeflow 从 1.4 版本后，核心组件的生命周期管理逐渐从“Helm 脚本钩子”迁移到“Kubernetes Operator 控制器”。这是 Helm 在复杂 AI 平台中角色收敛的典型信号。

5.2 路线 B：OCI 标准化分发 → GitOps 持续部署

演进逻辑：Helm Chart 的分发渠道正从 HTTP Helm Repository 转向 OCI Registry，这一步解决了 Chart 的安全存储、版本固定和跨平台分发问题。同时，GitOps 工具（ArgoCD、Flux）已将 Helm 作为一等公民——用户只需在 Git 仓库中维护 values 文件，GitOps 控制器自动 sync 到集群。

技术特征：

• Chart 包本身存储在 OCI Registry（如 Harbor），与容器镜像共享安全扫描链路
• values 文件版本托管在 Git，PR/MR 审批流程触发 Chart 升级
• ArgoCD 的 Application CRD 直接引用 Helm Chart 的 OCI 地址 + 版本

AI 场景对应：大规模 AI 集群通常涉及多个团队（训练、推理、数据），每个团队通过 Git 仓库管理自己的 values，ArgoCD 按 Application 粒度分别部署，实现多租户 GitOps。字节跳动、第四范式等中国 AI 公司公开分享中均提及 GitOps + Helm 的 AI 平台部署模式（公开资料见于 KubeCon China 2023 演讲）。

5.3 路线 C：AI 专用抽象层 → 屏蔽底层 Helm

演进逻辑：对算法工程师而言，Helm 的 values 语义仍然太底层。以 Jupyter Notebook 界面或自研 ML 平台为例，用户通过表单填写训练参数（镜像、GPU 数、数据路径），平台后端将表单映射为 Helm values → 调用 Helm SDK 部署训练 Job。这套模式使 Helm 从“用户工具”变为“平台 API 的底层引擎”。

技术特征：

• 用户交互面：Web UI / CLI（非 Helm 原生命令）
• 平台引擎层：Go/Python Helm SDK 或封装 helm install 子进程
• 底层：标准 Helm Chart 包，但 values 完全由平台生成，人工不直接编辑

AI 场景对应：阿里云 PAI、华为云 ModelArts 的托管训练服务，内部均采用类似架构——前端屏蔽 Helm 命令，后端以 Helm Chart 作为组件编排引擎。但在开源场景与自建平台中，Helm CLI 依然是最直接的控制手段。

5.4 技术路线选择判断框架

进度判断：截至 2024 年，路线 A 是绝对主流（超过 80% 的 AI 平台部署仍以直接 Helm install 或简单脚本封装为主，来源：CNCF 2023 年调查报告中 Helm 使用率 75%，但未区分 AI 场景与通用场景）。路线 B 在千人以上规模企业中渗透率显著提升（SUSE Rancher、Red Hat OpenShift GitOps 均推荐此模式）。路线 C 仅见于头部云厂商的托管 AI 服务，尚不构成开源主流。

6 上游

Helm Chart 的“上游”指 Chart 封装前所依赖的组件层——没有这些底层组件，Chart 中定义的 Deployment、CRD 等资源将无法调度和运行。理解上游对评估 Chart 的稳定性、可移植性和性能基线至关重要。

6.1 Kubernetes 版本演进

Helm 3.x 要求 Kubernetes 1.16+（实际生产中推荐 1.24+）。Kubernetes 自身的 API 弃用（如 Ingress v1beta1 在 1.22 移除）直接影响 Chart 中模板的兼容性。2024 年主要云厂商的 K8s 服务默认版本：

• 阿里云 ACK：1.28（2024.06，来源：阿里云官网）
• 华为云 CCE：1.29（2024.06，来源：华为云官网）
• AWS EKS：1.29（2024.06，来源：AWS 官网）
• Google GKE：1.29（2024.06，来源：Google Cloud 官网）

AI 场景下，K8s 版本的 GPU 特性支持差异显著：nvidia.com/gpu 资源类型从 K8s 1.26 开始作为稳定特性 GA，MIG 支持在 1.25 后逐步完善。

6.2 容器运行时

GPU 容器运行时的技术栈演进直接影响 AI Chart 的基础配置：

6.3 网络与存储（CNI/CSI）

AI 训练的网络需求远超普通 Web 应用——分布式训练会因网络瓶颈而严重降低 GPU 利用率。Chart 中通常不直接包含 CNI/CSI 定义，但在 NOTES.txt 或文档中声明前置依赖。

6.4 OCI Registry 与 Helm Repository

Chart 分发流的上游基础设施：

上游版本锁定策略：AI Chart 对上游组件版本高度敏感——例如 NVIDIA GPU Operator v23.9.0 与 containerd 1.7.x 的特定子版本存在已知的兼容性问题（来源：NVIDIA GPU Operator Release Notes）。在实际部署中，企业对上游组件的版本锁定比 Chart 本身更为严格。

7 下游

Helm Chart 的下游指向 Chart 被部署后的最终消费场景——即“Chart 跑起来之后面向谁、产出了什么价值”。对 AI 场景而言，下游可划分为三层：平台层应用、算法工程师体验、以及业务决策者关注的投资回报（ROI）。

7.1 平台层下游应用

7.2 算法工程师体验链

从算法工程师的实际工作流看，Helm Chart 的最终价值体现在以下体验点：

1. “一键跑实验”：申请 GPU 资源 → 定义 PyTorchJob → kubectl apply（背后是 Helm 渲染的 CRD），无需等待运维手动开通
2. “环境复现”：同一份 Chart + values 可在开发集群和训练集群得到完全一致的 PyTorch/CUDA 组合
3. “释放资源”：实验完成后 helm uninstall train-xxx，GPU 资源自动归还池中，无需担心“僵尸进程”占用算力
4. “模型版本可追溯”：KServe Chart 的 Revision 机制保留模型版本历史，支持模型回退（类比 helm rollback 的语义）

产业痛点：以上理想流程的实现高度依赖 Chart 质量与运维成熟度。公开资料中多次提到，算法工程师面临的主要摩擦不是 Chart 本身复杂，而是运维侧对 Chart values 的“过度封锁”——参数未暴露导致工程师无法自定义镜像或调整 GPU 数量，最终不得不绕过 Helm 直接手写 Pod YAML。

7.3 业务决策者的 ROI 视角

下游信号：2023 年以来，国内头部的 AI 能力型公司（如 MiniMax、月之暗面 Moonshot AI）以及互联网大厂 AI Lab 公开发布的招聘 JD 中，“熟悉 Helm/Kustomize/GitOps”已成为 MLOps 岗位的标配要求——这说明 Helm 作为 AI 基础设施基础工具已从“可选项”转为“必选项”（来源：公开招聘信息，2023-2024）。

8 受益公司

以下分析从 Helm Chart 在 AI 场景中的工具属性出发，梳理产业中因 Helm 生态繁荣而间接受益的组织类型。需要明确：Helm 本身是 CNCF 的开源项目，不产生直接商业收入；受益逻辑是“Helm 降低部署复杂度→加速相关商业产品采纳→生态参与者获利”。

8.1 公有云厂商

8.2 基础设施软件与平台公司

8.3 中国 AI 基础设施公司

说明：上述受益逻辑为产业分析推演，不对任何公司的股票、经营业绩做预测或评估。未标注收入数据的公司，仅代表公开资料未见其单独披露 Helm 相关口径。

9 市场规模

9.1 Container/Kubernetes 基础市场

Helm 作为 Kubernetes 的包管理器，其市场规模无法直接统计——Helm 本身是 CNCF 开源项目，零许可费用。但可以通过相关容器基础设施市场的规模推算其潜在影响范围。

9.2 AI 基础设施市场的 Helm 关联度

AI 基础设施的部署方式中，Kubernetes 占据云原生场景的主导地位，而 Helm 又是 Kubernetes 部署的事实标准。可以合理推测：

• 关联逻辑：所有基于 Kubernetes 的 AI 平台/MLOps 工具的部署，超过 70% 采用 Helm 或兼容 Helm 的方式分发（基于 CNCF 调查中 Helm 75% 的使用率推算，但该数据为通用场景，AI 场景可能偏低）
• 无法精确拆分：公开市场报告中不提供“AI 场景下 Helm 部署”的细分口径，以下为关联市场参考。

中国市场特殊性：

• 中国 AI 基础设施市场增速领先全球（IDC 预测 2022-2027 中国 AI 服务器市场 CAGR 约 39%，来源：IDC 中国 2023.10），间接拉动 Helm + K8s 生态的渗透
• 国产信创要求可能推动 Helm 的“国产化替代”或自定义分发方案，公开资料未见针对 Helm 本身的信创替代存在商业化产品
• 中国云厂商的 AI 平台倾向于提供“免 Helm 安装”的托管体验，但这实际上是将 Helm 从显性工具转为后台引擎，并非替换 Helm

10 玩家对比

以下对比聚焦于 AI 场景中持续发布和维护 Helm Chart 的核心组织，从 Chart 质量、维护频率、AI 场景覆盖度、安全实践等维度进行比较。

10.1 关键决策维度的横向对比

10.2 “链 chain-cloud”视角下的比较

在“云链化”AI 部署的场景中，Chart 的可组合性和跨平台迁移能力是关键：

10.3 选型启示

• 快速尝鲜：Bitnami 打包的各类 AI Chart是一站式选项，但版本滞后于上游 1-2 个小版本是常态
• GPU 基础设施标准：NVIDIA GPU Operator 已成事实标准，2024 年几乎无替代方案
• 完整 AI 平台：Kubeflow 全功能但运维复杂；简化为仅使用 KServe + MLflow 的“轻量 KubeFlow”近年来成为趋势
• 生产就绪：需评估自建组合与托管服务的长期运维成本比值，公开资料未见中国 AI 企业在 Helm 方案选型上的系统性对比数据

11 风险

11.1 供应链安全风险

缓解措施：

• 仅从 artifacthub.io 验证过的发布者（Verified Publisher）下载 Chart
• OCI 分发 + cosign 签名校验
• Helm 安装前 --dry-run 渲染完整 YAML 进行人工/自动化审计
• 企业内部维护 Chart 白名单和镜像白名单

11.2 运维复杂度风险

11.3 厂商锁定风险

11.4 治理与合规风险

• GPU 资源超卖：Helm 本身不限制 GPU 配额，若 values 中未正确设置 resource limits，多租户下 GPU 超额分配可能导致 OOM 和任务失败
• 数据合规：AI Chart 部署的训练任务可能将数据下载到非合规地域的节点（取决于 Chart 的节点选择器配置），需人工审查
• 安全审计难度：Chart 中的 RBAC 模板若无安全审核，可能授予训练 Pod 不必要的集群级权限（如 cluster-admin）

公开数据缺口：公开资料未见针对 AI 场景 Helm Chart 安全事件的系统性统计，上述风险识别来源于 CNCF 安全审计报告（2021）、Kubernetes 安全社区披露案例，以及行业实践总结。

12 误读纠偏

12.1 “Helm 是 Kubernetes 的唯一部署工具”

事实纠正：Helm