有了Kubernetes，为啥还需要Helm？-51CTO.COM

随着容器技术的兴起，Kubernetes（简称K8s）已经成为部署、管理和扩展容器化应用的事实标准。然而，在实际使用过程中，直接通过YAML文件管理复杂的Kubernetes应用程序变得越来越困难。为了解决这一问题，Helm应运而生。本次将介绍为什么在拥有K8s之后仍然需要Helm，并简要介绍下Helm。

一、什么是Helm？

Helm是Kubernetes的一个包管理器，它允许开发者定义、安装和升级最复杂Kubernetes应用程序。Helm使用一种称为Charts的打包格式来描述一组相关的Kubernetes资源。这使得团队能够更容易地共享和重用他们的Kubernetes配置。

二、有了K8s，为何还需要Helm？

我们直接先给出一幅对比图：

图片

1、简化部署过程

（1）简化复杂的YAML文件：对于大型项目来说，维护成百上千个相互关联的YAML文件是一项艰巨的任务。Helm通过模板化这些文件并将其组织成易于理解和管理的charts来解决这个问题。

（2）参数化配置：Helm支持通过values文件或命令行参数动态改变chart中的值，从而让同一个chart可以适应不同环境的需求。

2、提高可移植性和复用性

（1）易于分享和重用：一旦创建了一个chart，就可以很容易地与其他人共享，或者在不同的环境中重复使用。

（2）版本控制：Helm提供了对charts进行版本管理的能力，这意味着你可以轻松回滚到之前的版本，或者尝试新功能而不影响生产环境。

3、便于团队协作

（1）促进团队合作：通过标准化的应用程序部署流程，团队成员之间可以统一使用Helm协作部署。

（2）集成CI/CD管道：Helm非常适合集成到持续集成/持续交付(CI/CD)工作流中，实现自动化测试、构建及部署。

三、Helm快速入门

1、Helm整体架构

2、Helm核心概念

Helm有三个核心概念：chart、repository和release。

（1）Chart 代表着 Helm 包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定义。你可以把它看作是 Homebrew formula，Apt dpkg，或 Yum RPM 在Kubernetes 中的等价物。

（2）Repository（仓库）是用来存放和共享 charts 的地方。它就像 Fedora 的软件包仓库，只不过它是供 Kubernetes 包所使用的。

（3）Release 是运行在 Kubernetes 集群中的 chart 的实例。一个 chart 通常可以在同一个集群中安装多次。每一次安装都会创建一个新的 release。以 MySQL chart为例，如果你想在你的集群中运行两个数据库，你可以安装该chart两次。每一个数据库都会拥有它自己的 release 和 release name。

3、Helm安装与使用

从以下命令中，我们可以看到Helm的安装和使用过程非常简单。

（1）安装Helm客户端

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
#macOS安装
brew install helm

（2）创建自己的Chart

$ helm create mychart

mychart结构如下：

mychart/
  Chart.yaml          # 包含了chart信息的YAML文件
  LICENSE             # 可选: 包含chart许可证的纯文本文件
  README.md           # 可选: 可读的README文件
  values.yaml         # chart 默认的配置值
  values.schema.json  # 可选: 一个使用JSON结构的values.yaml文件
  charts/             # 包含chart依赖的其他chart
  crds/               # 自定义资源的定义
  templates/          # 模板目录， 当和values 结合时，可生成有效的Kubernetes manifest文件
  templates/NOTES.txt # 可选: 包含简要使用说明的纯文本文件

Chart.yaml文件是chart必需的。包含了以下字段：

apiVersion: chart API 版本 （必需）
name: chart名称 （必需）
version: 语义化2 版本（必需）
kubeVersion: 兼容Kubernetes版本的语义化版本（可选）
description: 一句话对这个项目的描述（可选）
type: chart类型 （可选）
keywords:
- 关于项目的一组关键字（可选）
home: 项目home页面的URL （可选）
sources:
- 项目源码的URL列表（可选）
dependencies: # chart 必要条件列表 （可选）
- name: chart名称 (nginx)
version: chart版本 ("1.2.3")
repository: （可选）仓库URL ("https://example.com/charts") 或别名 ("@repo-name")
condition: （可选） 解析为布尔值的yaml路径，用于启用/禁用chart (e.g. subchart1.enabled )
tags: # （可选）
- 用于一次启用/禁用 一组chart的tag
import-values: # （可选）
- ImportValue 保存源值到导入父键的映射。每项可以是字符串或者一对子/父列表项
alias: （可选） chart中使用的别名。当你要多次添加相同的chart时会很有用
maintainers: # （可选）
- name: 维护者名字 （每个维护者都需要）
email: 维护者邮箱 （每个维护者可选）
url: 维护者URL （每个维护者可选）
icon: 用做icon的SVG或PNG图片URL （可选）
appVersion: 包含的应用版本（可选）。不需要是语义化，建议使用引号
deprecated: 不被推荐的chart （可选，布尔值）
annotations:
example: 按名称输入的批注列表 （可选）.

(3) 部署并查看Chart

# 安装chart
$ helm install mychart ./mychart
# 查看已安装的chart
$ helm list
# 查看chart的依赖
$ helm dependency list mychart
# 查看Chart的历史
$ helm history mychart

(4) 升级或卸载Chart

$ helm upgrade mychart ./mychart
$ helm uninstall mychart

四、结语

虽然Kubernetes本身已经非常强大，但随着容器化应用规模的扩大以及复杂度的增加，直接通过YAML文件来管理这些应用变得愈发困难。Helm作为Kubernetes的一个包管理器，不仅简化了部署流程，还极大地提高了配置的可维护性与复用性，使得开发团队能够更高效地协作，并且轻松应对多环境下的持续集成/持续交付(CI/CD)需求。

此外，Helm的强大之处不仅仅体现在其对于单个应用或服务的打包能力上，它还能帮助用户构建复杂的微服务架构。通过定义清晰的服务依赖关系，并利用版本控制系统来跟踪每次变更，Helm让整个系统的演进过程更加透明可控。这对于需要频繁更新和迭代的大中型企业级项目尤为重要。

值得注意的是，尽管Helm提供了许多便利功能，但在实际使用过程中也需要注意一些潜在问题。例如，不恰当的chart设计可能会导致资源过度消耗；而缺乏足够的安全性考量，则可能使系统面临不必要的风险。因此，在享受Helm带来便捷的同时，开发者们也需要不断学习最佳实践，确保自己的Kubernetes集群被高效安全地管理。

参考： https://helm.sh/docs/