1. Helm 基础概念
1.1 Helm 是什么
Helm 是 Kubernetes 生态中最流行的包管理工具，类比于 Linux 中的 yum/apt 或 Node.js 中的 npm。它通过将 Kubernetes 资源（Deployment、Service、ConfigMap 等）打包为可复用、可配置的 Chart，解决了原生 YAML 管理中的重复编写、环境差异、版本混乱等痛点。
核心价值：Helm 让 K8s 应用发布从“手动拼 YAML”升级为“声明式 Chart 编排 + 参数化模板 + 版本化发布”。
| 对比维度 | 原生 YAML 管理 | Helm 管理 |
|---|---|---|
| 复用性 | 每个环境复制粘贴，难以维护 | Chart 模板 + values.yaml 参数化复用 |
| 版本控制 | 依赖 Git 文件级管理 | Release 版本号 + 回滚机制 |
| 依赖管理 | 手动处理子组件顺序 | Chart 依赖声明 + 自动解析 |
| 安装/升级 | kubectl apply -f 逐个执行 | helm install/upgrade 一键操作 |
1.2 Helm 架构演进：Tiller vs Helm 3
Helm 架构经历了从 Helm 2（Tiller 模式）到 Helm 3（无 Tiller 模式）的重大变革。理解这一演进对生产环境选型至关重要。
生产建议：当前所有新项目应使用 Helm 3。Helm 2 已于 2020 年 11 月停止安全更新，Tiller 的集群级权限存在严重安全风险。
| 特性 | Helm 2 (Tiller) | Helm 3 (无 Tiller) |
|---|---|---|
| 服务端组件 | 需要 Tiller 部署在集群内 | 无服务端组件，纯客户端 |
| 权限模型 | Tiller 使用 ServiceAccount，权限过大 | 使用用户本地 kubeconfig，遵循 RBAC |
| Release 存储 | ConfigMap（默认）或 Secrets | Secrets（默认），更安全 |
| 安全审计 | Tiller 是攻击面，需额外加固 | 无额外攻击面，原生 K8s 认证 |
| 安装复杂度 | 需先安装 Tiller 并授权 | 仅需 Helm 二进制，开箱即用 |
1.3 Helm 核心组件：Chart、Repo、Release
Helm 的三大核心组件构成了完整的包管理生命周期：Chart 是应用包的定义，Repo 是 Chart 的存储仓库，Release 是 Chart 在集群中的运行实例。
1.3.1 Chart — 应用包定义
Chart 是 Helm 的核心打包格式，本质是一个遵循特定目录结构的文件集合。一个标准的 Chart 目录结构如下：
my-chart/
├── Chart.yaml # Chart 元数据（名称、版本、描述）
├── values.yaml # 默认配置值
├── values.schema.json # （可选）values 的 JSON Schema 校验
├── charts/ # （可选）子 Chart 依赖
├── templates/ # Go 模板文件目录
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── _helpers.tpl # 模板辅助函数
│ └── NOTES.txt # 安装后提示信息
└── README.md # 使用说明
运维注意：Chart 版本号必须遵循 SemVer 2 规范（如 1.2.3），且每次修改模板或 values 默认值后必须升级 Chart 版本，否则会导致 Release 追踪混乱。
1.3.2 Repo — Chart 存储仓库
Repo 是 Chart 包的远程存储和分发中心，本质是一个提供 index.yaml 和 Chart 压缩包的 HTTP 服务器。常见的 Repo 类型包括：
- 公共 Repo：Bitnami、Prometheus Community、Elastic 等官方维护的 Chart 仓库
- 私有 Repo：企业自建的 ChartMuseum、Harbor、Nexus 等
- OCI 仓库：Helm 3.8+ 支持将 Chart 以 OCI 镜像形式存储在 Harbor、Docker Hub、ACR 等容器镜像仓库中
| Repo 类型 | 协议 | 适用场景 | 示例命令 |
|---|---|---|---|
| HTTP/HTTPS | helm repo add | 传统 Chart 仓库 | helm repo add bitnami https://charts.bitnami.com/bitnami |
| OCI | helm pull/install oci:// | 容器镜像仓库集成 | helm install my-app oci://registry.example.com/charts/my-app |
| 本地 | helm repo add --insecure-skip-tls-verify | 开发测试 | helm repo add local http://localhost:8080 |
1.3.3 Release — 集群运行实例
Release 是 Chart 在 Kubernetes 集群中的一次具体部署实例。每次执行 helm install 都会创建一个新的 Release，并分配唯一的 Release Name。Release 的生命周期包括：
- 安装（Install）：helm install → 创建 Release，状态为
deployed - 升级（Upgrade）：helm upgrade → 创建新 Revision，保留历史版本
- 回滚（Rollback）：helm rollback → 恢复到指定 Revision
- 卸载（Uninstall）：helm uninstall → 删除 Release，可选择保留历史记录
关键概念：Release 的 Revision 是每次变更的版本号（从 1 递增），Helm 3 默认保留最近 10 个 Revision 用于回滚。可通过
--history-max 参数调整。
查看当前集群中的 Release 列表：
# 列出所有命名空间的 Release
helm list --all-namespaces
# 查看特定 Release 的历史版本
helm history my-release
# 查看 Release 的详细状态
helm status my-release
运维清单要点：
- 生产环境必须使用 Helm 3，禁止使用 Tiller
- Chart 版本号严格遵循 SemVer 2，每次模板变更必须升级
- Repo 优先使用 OCI 仓库，便于与镜像仓库统一管理
- Release 名称建议包含环境标识（如
prod-my-app、staging-my-app） - 设置合理的
--history-max（建议 5~10），避免 Secrets 过多