Helm Chart 是什么？

文章目录

[Helm Chart 是什么？](#Helm Chart 是什么？)
- - [一、Helm 与 Helm Chart 是什么？](#一、Helm 与 Helm Chart 是什么？)
  - [二、为什么需要 Helm Chart？](#二、为什么需要 Helm Chart？)
  - [三、Helm Chart 的核心结构](#三、Helm Chart 的核心结构)
  - [四、Helm 的核心概念与工作流程](#四、Helm 的核心概念与工作流程)
  - [五、如何使用 Helm Chart？](#五、如何使用 Helm Chart？)
  - [六、总结：Helm Chart 的价值](#六、总结：Helm Chart 的价值)

本文是一篇关于 Helm Chart 的详细介绍，涵盖其概念、核心组件、工作原理以及使用价值。

一、Helm 与 Helm Chart 是什么？

首先，我们需要分清 Helm 和 Helm Chart。

Helm ：是 Kubernetes 的 包管理器 。你可以把它类比为 Ubuntu 的 apt、CentOS 的 yum 或 Node.js 的 npm。它的主要作用是简化在 Kubernetes 集群上查找、共享、安装、升级和管理应用程序的过程。
Helm Chart ：是 Helm 使用的 打包格式 。一个 Chart 就是一个包含了在 Kubernetes 上运行一个应用、工具或服务所需的所有资源定义文件 的集合。你可以把它想象成一个"软件包"，就像 .deb、.rpm 或 Docker 镜像一样，但它是专门为 Kubernetes 环境设计的。

简单来说：Helm 是工具，Chart 是打包好的应用。

二、为什么需要 Helm Chart？

在 Kubernetes 上部署一个简单的应用（例如一个 Nginx Web 服务器）可能只需要几个 YAML 文件（Deployment, Service）。但是，部署一个复杂的微服务应用（例如包含前端、后端、数据库、缓存、配置等）可能需要几十个甚至上百个 YAML 文件。

传统方式（kubectl apply -f）的痛点：

管理繁琐：需要手动维护大量 YAML 文件。
缺乏复用性：为不同环境（开发、测试、生产）部署时，需要复制并修改大量配置。
发布流程复杂：升级、回滚操作困难，需要记录和管理每个资源的版本。
依赖管理：如果应用依赖其他服务（如 Redis、MySQL），需要手动确保这些依赖先被部署。

Helm Chart 的解决方案：

打包和复用：将所有相关资源打包成一个 Chart，便于分享和版本控制。
模板化配置：通过 Go 模板语言，将需要动态变化的配置（如镜像标签、副本数、服务端口）提取为变量。
参数化部署 ：通过一个中心化的 values.yaml 文件，可以为不同环境提供不同的配置值，而无需修改模板本身。
生命周期管理 ：Helm 提供了 install、upgrade、rollback、uninstall 等完整命令，方便管理应用的整个生命周期。
依赖管理：可以在 Chart 中声明对其他 Charts 的依赖，Helm 会帮你自动安装它们。

三、Helm Chart 的核心结构

一个典型的 Helm Chart 目录结构如下：

text 复制代码

my-awesome-app-chart/
├── Chart.yaml          # 【必需】Chart 的元数据文件（名称、版本、依赖等）
├── values.yaml         # 【必需】Chart 的默认配置值
├── templates/          # 【必需】模板文件目录，包含所有 Kubernetes 资源 YAML 模板
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── configmap.yaml
│   └── ingress.yaml
├── charts/             # 【可选】存放本 Chart 依赖的其他子 Charts
├── README.md           # 【可选】使用说明
└── crds/               # 【可选】自定义资源定义文件

关键文件详解：

Chart.yaml:
- 描述 Chart 自身的元信息。
- 包含字段：apiVersion（Chart API 版本）、name（Chart 名称）、version（遵循语义化版本）、appVersion（所打包应用的版本）、description、dependencies（依赖列表）等。
values.yaml:
- 定义 Chart 中模板可以使用的默认配置值。
- 例如：replicaCount: 2、image.repository: nginx、image.tag: "latest"。
- 用户可以通过自定义的 values.yaml 文件或命令行参数（--set）来覆盖这些默认值。
templates/ 目录:
- 这是 Chart 的"引擎室"。里面的文件是标准的 Kubernetes YAML 资源清单，但使用了 Go 模板语言进行增强。
- 模板中可以使用变量、函数和流程控制语句。
- 示例 (templates/deployment.yaml 片段):
  yaml 复制代码
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
```
  - {``{ .Release.Name }}: 发布名称，由用户 helm install [RELEASE_NAME] 时指定。
  - {``{ .Chart.Name }}: 来自 Chart.yaml 的名称。
  - {``{ .Values.replicaCount }}: 来自 values.yaml 或用户覆盖的值。

四、Helm 的核心概念与工作流程

Chart: 如上所述，是应用包。
Release : 是 Chart 在 Kubernetes 集群中的一个运行实例 。同一个 Chart 可以安装多次，每次安装都会创建一个新的 Release（例如：为团队 A 和团队 B 分别安装 myapp chart，会创建两个独立的 Release：team-a-myapp 和 team-b-myapp）。
Repository (Repo): Chart 的存储库，一个 HTTP 服务器，存放并共享 Charts。类似于 Docker Hub。

基本工作流程：

用户编写或获取一个 Helm Chart。
用户通过 helm install [RELEASE_NAME] [CHART] 命令进行安装。
Helm 读取 Chart 和用户提供的 values。
Helm 将 templates/ 下的所有模板与 values 结合，渲染成纯 Kubernetes YAML 文件。
Helm 通过 Kubernetes API 将这些 YAML 文件提交给集群，创建所有定义好的资源。
Helm 在集群中创建一个 Secret（默认存储驱动）来记录这次安装的 Release 状态、配置和版本。

helm upgrade 和 helm rollback 正是基于这个 Release 记录来实现的。

五、如何使用 Helm Chart？

安装 Helm 客户端。

查找 Chart:

bash 复制代码

helm search hub wordpress      # 在 Artifact Hub（官方中心仓库）查找
helm repo add bitnami https://charts.bitnami.com/bitnami # 添加第三方仓库
helm search repo bitnami/mysql # 在已添加的仓库中查找

安装 Chart:

bash 复制代码

# 使用默认配置安装
helm install my-wordpress bitnami/wordpress

# 使用自定义 values 文件安装
helm install my-wordpress bitnami/wordpress -f my-values.yaml

# 在安装时动态设置参数
helm install my-wordpress bitnami/wordpress --set replicaCount=3

管理 Release:

bash 复制代码

helm list                     # 列出所有 Release
helm status my-wordpress      # 查看 Release 状态
helm upgrade my-wordpress bitnami/wordpress -f new-values.yaml # 升级
helm rollback my-wordpress 1  # 回滚到版本 1
helm uninstall my-wordpress   # 卸载

六、总结：Helm Chart 的价值

方面	传统 kubectl	Helm Chart
部署单元	零散的 YAML 文件	一个完整的、版本化的 Chart 包
配置管理	手动编辑/复制 YAML	模板化，通过 `values.yaml` 集中配置
复用性	低，需大量复制修改	高，一次编写，多处参数化部署
生命周期	手动操作，易出错	完整的 `install/upgrade/rollback/uninstall` 命令
依赖管理	手动处理	声明式依赖，自动安装
共享与分发	困难（如通过 Git）	容易，通过 Chart 仓库（Harbor, Artifact Hub）

适用场景：

部署和管理复杂的微服务应用。
需要为不同环境（开发、预发、生产）提供不同配置。
希望在团队或社区内标准化和共享 Kubernetes 应用部署配置。
需要实现应用的快速回滚和可重复部署。

需要权衡的方面：

学习成本：需要学习 Chart 结构、模板语法和 Helm 命令。
复杂度：对于极其简单的应用，使用 Helm 可能显得"杀鸡用牛刀"。
安全性 ：确保从可信的仓库获取 Charts，并审查 values.yaml 的配置。

总而言之，Helm Chart 是 Kubernetes 生态中实现"应用即代码"和"GitOps"实践的关键工具，它极大地提升了在 Kubernetes 上部署和管理应用的效率、可靠性和一致性。