Helm核心概念与常见操作介绍

在管理Kubernetes集群里的应用时，Helm能帮上大忙，它把应用的部署、升级和管理变得简单多了，有如是Kubernetes的 “应用商店”。

Helm的三个重要概念

三大概念最直接的理解：Helm 安装 charts 到 Kubernetes 集群中，每次安装都会创建一个新的 release。你可以在 Helm 的 chart repositories 中寻找新的 chart。接下来分个介绍。

Chart

Chart是Helm里特别关键的东西，它其实就是个提前配置好的软件包，包含在Kubernetes集群部署某个应用要用的所有资源。你可以把它想成是一份详细的 “应用搭建指南”，能帮你在Kubernetes集群里把应用搭起来。Chart主要包含以下几个重要部分：

• Chart.yaml：这个文件记录着Chart的基本信息，比如Chart的名字、版本号、对它的描述，还有它依赖哪些其他的Chart等。就好比产品说明书的封面，让你对这个Chart有个初步的了解。例如，在一个部署WordPress应用的Chart里，Chart.yaml会写明这是WordPress的Chart，版本是多少，以及简单介绍它能做什么。
• templates目录：这里面放着各种Kubernetes资源的模板文件，像deployment.yaml用来规定应用的部署方式，比如要部署多少个副本；service.yaml负责把应用服务对外展示，让外部能访问到应用；还有configmap.yaml可以存一些配置信息，像是数据库连接字符串等。这些模板就像是搭建应用的各个零件图纸，告诉Kubernetes该怎么创建和配置这些资源。比如说deployment.yaml模板里，会定义使用个Docker镜像来运行应用，以及应用运行所需的资源限制等。
• values.yaml：部署应用的时候，你能通过它灵活地改各种参数。比如在部署一个Web应用的Chart时，你能在values.yaml文件里轻松修改数据库连接字符串，把它改成你实际要用的数据库地址；还能调整应用副本数量，根据业务量来决定部署多少个实例；以及设置资源请求和限制，比如给应用分配多少CPU和内存。通过修改values.yaml里的参数，能让应用适应不同的运行环境。比如在测试环境，你可能把副本数量设为1，方便调试；在生产环境，根据业务量把副本数调高，保证应用的性能。

Repository

Repository就是存Helm图表（Chart）的地方，就跟一个大软件仓库似的，里面放着各种各样的Chart。Helm官方有公共仓库，咱们自己也能搭私有仓库。仓库里，每个Chart都按特定的目录结构存着。我们通过helm repo相关的命令和仓库打交道。比如，用helm repo add命令添加仓库，把远程仓库地址和一个好记的别名连起来，后面用着方便；helm repo update命令是把远程仓库的最新信息同步到本地，这样就能拿到最新版的Chart；helm repo list能列出现在已经配置好的所有仓库信息，方便我们查看和管理。有了仓库，大家分享和重复使用Chart就方便多了，大大提高了部署应用的效率。

Release

当我们用Helm把一个Chart装到Kubernetes集群里的时候，每装一次，就会生成一个Release。Release其实就是Chart在Kubernetes集群里的一个具体实例，它记着Chart在某个时间点的部署状态、配置信息，还有相关的元数据。每个Release都有个独一无二的名字，方便我们管理和追踪。比如说，你装了个叫my - nginx的Release，它对应的就是nginxChart在集群里的一次部署。通过Release，我们能很方便地对应用进行升级、回滚、卸载这些操作，而且这些操作都是根据Release记录的信息来进行的。

Helm的常用操作

1. 仓库操作

添加仓库

用helm repo add这个命令来添加仓库。比如说：

helm repo add stable https://charts.helm.sh/stable

这里，stable是我们给仓库起的别名，最紧要好记；https://charts.helm.sh/stable就是官方稳定仓库的地址。如果是私有仓库需要认证，添加的时候带上用户名和密码参数：

helm repo add --username myuser --password mypass private_repo https://my_private_repo.com

列出仓库

运行helm repo list就能看到已经添加的仓库列表：

helm repo list

结果会显示仓库别名和对应的URL，让我们清楚现在都配置了哪些仓库，方便后面管理和使用。

在官方仓库搜索

helm search hub这个命令能在官方仓库找Chart。比如说，你想找和nginx有关的Chart，就这么做：

helm search hub nginx

Helm会在官方仓库里找名字或者描述里有nginx的Chart，然后把相关信息列出来，像Chart名字、版本、描述啥的，这样我们就能很快找到想要的应用。

在自己配置的仓库搜索

要是想在自己配的仓库里找Chart，就用helm search repo命令。假设仓库别名是myrepo，找和nginx相关的Chart：

helm search repo myrepo/nginx

这样就能在指定仓库里精准找到特定的Chart，提高搜索效率。

删除仓库

要是不用某个仓库了，用helm repo remove命令删掉。比如说删别名是stable的仓库：

helm repo remove stable

执行完，这个仓库的相关信息就从本地配置里没了，清理掉没用的仓库配置。

2. 安装操作

下载图表

用helm pull命令下载Chart。默认下，下载的是最新版本，比如：

helm pull stable/nginx

要是想指定版本下载，加个--version参数：

helm pull stable/nginx --version 1.2

下载下来的Chart是个压缩包，解压后能看到里面的文件结构，有Kubernetes资源模板文件、values.yaml文件等，方便我们在安装前研究，或者用来离线安装。

安装仓库里的Chart

用helm install命令把Chart装到Kubernetes集群里。比如说，装stable仓库的nginxChart，给Release起名叫my - nginx：

helm install my - nginx stable/nginx

安装的时候，Helm会从指定仓库把Chart下载下来，然后按照Chart里的定义，在集群里创建对应的Kubernetes资源。

使用自定义的values.yaml文件

安装的时候，能通过-f参数指定自定义的values.yaml文件，用自己的配置把默认配置换掉。比如：

helm install my - nginx stable/nginx - f myvalues.yaml

在myvalues.yaml文件里，我们能根据实际需要改各种参数，像调整副本数量、改服务端口，让应用更符合实际运行环境。

升级版本或者修改配置

应用更新了，或者需求变了，就得升级已经安装的Release。拿my - nginx来说，假设要升级到stable/nginx图表的新版本，还想把副本数改成4：

helm upgrade my - nginx stable/nginx --set replicaCount = 4

升级的时候，Helm对原配置的处理机制是这样的：它会先读取当前Release的配置信息，这些信息存储在values.yaml文件以及Release的元数据中 。对于那些在新版本Chart里依然存在且未发生重大变更的配置项，Helm会保留原有的配置值。例如，如果原配置里设置了image.repository为nginx:1.18，在新版本Chart里该配置项的结构和用途未变，那么升级时这个配置值会被继续沿用，实现平滑转移 。

但如果新版本Chart引入了新的配置项，Helm会按照以下规则处理：若用户在升级命令中没有显式指定新配置项的值，Helm会尝试使用新版本Chart中values.yaml文件里定义的默认值。比如新版本stable/nginx图表新增了一个extraEnvVars配置项用于设置额外的环境变量，而用户升级时没有通过--set或-f参数指定其值，那么Helm会采用新版本values.yaml里为extraEnvVars设置的默认值。若用户在升级命令中通过--set或-f参数指定了新配置项的值，Helm则会使用用户指定的值。例如用户执行helm upgrade my - nginx stable/nginx --set extraEnvVars[0].name=TEST_VAR --set extraEnvVars[0].value=test，那么Helm会按照用户指定的内容，为应用配置新的环境变量。

在更新资源时，Helm会尽量用滚动更新的办法，保证服务一直能用。比如说对于Deployment资源，Helm会一个一个把旧的Pod换成新配置的Pod，同时盯着整个更新过程，一有问题，马上能回滚到上一个版本。

卸载

用helm uninstall命令卸载Release。比如说卸载叫my - nginx的Release：

helm uninstall my - nginx

Helm会把这个Release对应的所有Kubernetes资源都删掉，像Deployment、Service这些。不过要注意，如果Chart创建了PVC（PersistentVolumeClaim）这种持久化资源，默认情况下，Helm不会删这些资源，得我们自己手动清理，不然就浪费资源了。

预安装检查

在安装或者升级Release之前，可以用--dry - run和--debug参数做个预安装检查。比如：

helm install my - redis stable/redis --dry - run --debug

--dry - run能让Helm模拟安装过程，但不会真的创建资源，这样能提前发现潜在问题，像模板渲染错误、资源冲突这些；--debug参数会输出详细的调试信息，方便我们找到问题、解决问题，保证正式安装或者升级能顺顺利利的。

3. 创建chart

创建一个基础框架

用helm create命令生成Chart的基础结构。比如说创建一个叫my - nginx的Chart：

helm create my - nginx

这个命令会在当前目录生成一个my - nginx文件夹，里面有Chart的基本文件和目录结构。像Chart.yaml（存图表的基本信息，比如名字、版本、描述）、templates目录（放Kubernetes资源模板文件，像deployment.yaml、service.yaml）、values.yaml（用来配置图表参数）。我们可以根据实际需要，修改这些文件，做出符合项目要求的Chart。

打包成压缩包

自定义图表做好了之后，用helm package命令把它打成压缩包，方便分享或者部署。在my - nginx图表目录下运行：

helm package my - nginx

命令会在当前目录生成my - nginx - 0.1.0.tgz（版本号在Chart.yaml里定好的）压缩包，这个压缩包就是打包好的Chart，后面能用来上传或者分发。

上传压缩包

要是有自己的私有Helm仓库，用helm push命令上传打包好的图表。假设私有仓库地址是https://my_private_repo.com，用户名是myuser，密码是mypass，上传my - nginx - 0.1.0.tgz：

helm push my - nginx - 0.1.0.tgz --username myuser --password mypass https://my_private_repo.com

上传之后，这个Chart就能在私有仓库里，供其他用户使用了。

4. 查看操作

Release列表

运行helm list能看到集群里已经安装的Release列表：

helm list

结果会显示Release的名字、在哪个命名空间、版本号、更新时间、状态，还有对应的Chart名字和应用版本等信息，让我们全面了解现在集群里都部署了哪些应用。

升级Release

升级Release的操作前面讲过了，用helm upgrade命令。比如说把my - nginx升级到stable/nginx的新版本，还改改配置：

helm upgrade my-nginx stable/nginx --set replicaCount = 4

升级的时候，Helm会根据现在Release的状态和配置，再结合新版本Chart的变化，巧妙地决定怎么更新Kubernetes资源。要是有新资源，Helm就创建；要是已有资源的配置变了，Helm会按照资源类型的更新规则去更新。比如说对于Deployment资源，会用滚动更新的方式，一个一个把旧Pod换成新的，保证服务一直能用。同时，Helm会记录升级过程中的状态和事件，方便我们跟踪和排查问题。

查看Release配置

用helm get values命令查看Release的配置参数。比如说查看叫my - nginx的Release配置：

helm get values my - nginx

结果会显示这个Release现在用的配置参数，和values.yaml文件里的配置是对应的，方便我们检查配置对不对，了解现在的运行配置情况。

获取Release详细信息

运行helm status命令能拿到Release的详细信息，像配置、状态、事件这些。比如说查看my - nginx的详细信息：

helm status my - nginx

输出的内容有Release现在的状态（比如deployed表示已经成功部署）、资源状态（像Deployment的副本数、Pod的运行状态）、配置参数，还有相关的NOTES信息（一般是Chart作者给的一些使用说明），能帮我们排查问题，更深入了解部署情况。

5. 回滚操作

查看Release历史版本

用helm history命令查看Release的历史版本信息。比如说查看my - nginx的历史版本：

helm history my-nginx

结果会显示每个版本的修订号、更新时间、状态、对应的Chart版本，还有操作描述（比如安装、升级）。通过看历史版本，我们能知道Release都有哪些变化，为回滚操作提供依据。

回滚Release

要是升级之后出问题了，需要回滚到之前的某个版本，就用helm rollback命令。比如说把my - nginx回滚到版本1：

helm rollback my-nginx 1

回滚的时候，Helm会根据历史记录，把Release对应的Kubernetes资源变回指定版本的状态。它会重新用旧版本Chart的配置，改资源的参数，像Deployment的镜像版本、副本数量，让它们和目标版本一样。同时，Helm也会像升级操作那样，采用合理的资源更新策略，保证回滚过程中服务稳定、连续。要是回滚过程出问题了，Helm会试着恢复，尽量让系统保持一致。

6. 名称空间

-n namespace

直接在以上的命令后面加上这个，就能在具体的namespace里面运行这些命令，比如：

helm list -n mynamespce
helm history alias -n mynamespace

掌握了Helm这些核心概念和常用操作，在管理Kubernetes集群里的应用时，我们就能更高效地部署、升级、维护应用，充分发挥Kubernetes的优势，提高开发运维效率。要是在使用Helm的时候遇到问题，或者对上面这些操作有不明白的地方，比如在特定场景下怎么调整配置，随时来交流。