📚 课程目录第1章 Helm基础概念

1. Helm 基础概念

Helm 是 Kubernetes 生态中最流行的包管理工具，常被称为“Kubernetes 的 apt/yum/homebrew”。它通过预定义的模板和参数化配置，将一组 Kubernetes 资源（Deployment、Service、ConfigMap 等）打包为一个可重复部署的单元，从而大幅简化应用的安装、升级、回滚与配置管理。

1.1 Helm 是什么

Helm 的核心价值在于将复杂的 Kubernetes 资源清单抽象为可配置、可版本化的 Chart。使用 Helm 后，开发者不再需要手动编写或复制大量 YAML 文件，而是通过一条命令即可完成整个应用栈的部署。

特性	说明
包管理	将 Kubernetes 资源打包为 Chart，支持版本化、依赖管理和发布
模板化	使用 Go 模板引擎动态生成 YAML，通过 values.yaml 实现环境差异化
生命周期管理	支持 install、upgrade、rollback、delete 等完整操作
仓库生态	通过 Repository 分发和共享 Chart，类似 Docker Hub 之于容器镜像

关键认知： Helm 不是容器编排工具，而是 Kubernetes 资源的编排封装层。它解决的是“如何标准化、可重复地部署一组 Kubernetes 资源”的问题。

1.2 Helm 架构演进：Tiller vs Helm 3

Helm 的架构在 v2 到 v3 的升级中发生了根本性变化，核心差异在于服务端组件 Tiller 的移除。理解这一演进对掌握 Helm 的安全模型和运维方式至关重要。

对比维度	Helm 2（Tiller 架构）	Helm 3（无 Tiller 架构）
服务端组件	需要 Tiller 在集群内运行	无服务端组件，直接使用 kubeconfig 与 API Server 交互
权限模型	Tiller 拥有集群级权限，存在安全风险	使用当前用户的 kubeconfig 权限，遵循 RBAC
Release 存储	存储在 ConfigMap 中（默认）	存储在 Secret 中，默认加密
命名空间隔离	Tiller 跨命名空间管理 Release	Release 严格绑定到命名空间
安装复杂度	需先安装 Tiller 并授权	仅需二进制客户端，开箱即用

  迁移建议： 当前 Helm 3 已是稳定主线，Helm 2 已于 2020 年 11 月停止安全更新。所有新项目应直接使用 Helm 3，存量 Helm 2 环境建议通过 helm 2to3 插件迁移。

1.3 Helm 核心组件

Helm 的三大核心组件构成了其完整的工作流：Chart（包定义）、Release（运行实例）、Repository（分发仓库）。三者之间的关系可以用“Chart 是食谱，Release 是烹饪好的菜肴，Repository 是菜谱集”来类比。

1.3.1 Chart

Chart 是 Helm 的打包格式，本质是一个遵循特定目录结构的文件集合。一个标准的 Chart 目录结构如下：

mychart/
├── 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.yaml`	定义 Chart 名称、版本、API 版本、描述、关键字等元信息
`values.yaml`	默认配置值，用户可通过 `--set` 或自定义 values 文件覆盖
`templates/`	Go 模板文件，渲染后生成最终的 Kubernetes 资源 YAML
`charts/`	存放子 Chart 依赖，Helm 会自动解析 `Chart.yaml` 中的 `dependencies`

1.3.2 Release

Release 是 Chart 在 Kubernetes 集群中的一次具体部署实例。同一个 Chart 可以部署多次，每次生成一个独立的 Release。例如，使用同一个 nginx Chart 部署开发环境和生产环境，会得到两个不同的 Release。

  Release 版本管理： 每次执行 helm upgrade 都会生成一个新的 Release 版本号（revision）。Helm 默认保留最近 10 个版本的 Release 历史，可通过 --history-max 调整。回滚操作就是切换到某个历史 revision。

1.3.3 Repository

Repository（仓库）是 Chart 的存储和分发中心。一个 Repository 本质上是一个 HTTP 服务器，提供 index.yaml 索引文件和 Chart 压缩包（.tgz）。

常用的 Helm 仓库操作命令：

# 添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami

# 列出已添加的仓库
helm repo list

# 更新仓库索引
helm repo update

# 从仓库搜索 Chart
helm search repo bitnami/nginx

# 移除仓库
helm repo remove bitnami

1.4 核心工作流总结

一次完整的 Helm 部署流程可以概括为以下步骤：

准备 Chart：从 Repository 拉取或本地创建 Chart 包
配置 values：通过 values.yaml、--set 或自定义文件注入配置
执行 install：Helm 客户端渲染模板并与 API Server 交互创建资源
生成 Release：集群中生成一个 Release 实例，版本号为 1
升级/回滚：通过 helm upgrade 或 helm rollback 管理 Release 版本

常见误区： 初学者容易混淆 Chart 版本和 Release 版本。Chart 版本（Chart.yaml 中的 version）是包本身的版本号；Release 版本（revision）是部署实例的变更序号，两者独立管理。