在Kubernetes上维护一套完整的应用栈，光靠手工编写和更新大量YAML文件，很容易出现配置漂移和版本混乱。Helm作为Kubernetes事实上的包管理标准，通过Chart模板把部署、服务、配置映射等资源打包成一个可发布单元，并支持版本升级与回滚。CentOS是很多Kubernetes节点和运维终端的常见操作系统，下面围绕CentOS环境，介绍Helm从安装到实际发布应用的过程。
Helm安装方式对比与前置条件
Helm 3的架构与Helm 2存在较大差异，最明显的变化是移除了服务端组件Tiller。现在的Helm客户端会直接使用本地kubeconfig文件与Kubernetes API Server通信，因此安装Helm本身并不要求必须运行在集群节点上，只要CentOS主机能够通过kubectl访问目标集群即可。安装前建议先执行kubectl cluster-info确认集群连接正常，并保证当前用户对目标命名空间有足够的创建权限。
在CentOS上安装Helm最推荐的方式是使用官方脚本。脚本会自动检测操作系统架构并下载合适的二进制文件，安装路径默认在/usr/local/bin。执行以下命令可以完成安装。脚本方式适合快速搭建环境，但如果你的网络无法直接访问GitHub，建议提前准备好离线二进制包。
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 helm version
第二种方式是手动下载二进制包。这种方式更透明，可以固定版本，避免脚本更新带来的不确定性。先到Helm官方发布页找到对应版本，然后使用wget下载linux-amd64包，解压后将helm文件移动到PATH目录中。安装完成后同样通过helm version检查版本号，如果输出中包含Version字段，说明客户端安装成功。
wget https://get.helm.sh/helm-v3.16.2-linux-amd64.tar.gz tar -zxvf helm-v3.16.2-linux-amd64.tar.gz mv linux-amd64/helm /usr/local/bin/helm chmod +x /usr/local/bin/helm helm version
需要注意的是，CentOS 7或8默认的yum/dnf仓库并没有直接提供Helm软件包，一些网络教程中提到的yum install helm通常依赖额外第三方仓库或者是对旧版Helm 2的封装。如果必须使用包管理器统一维护，可以考虑通过snap安装，但生产环境更建议直接使用官方脚本或二进制方式，减少中间层带来的版本滞后和兼容问题。
仓库管理与Chart检索
Helm的Chart存放在仓库中，仓库本质上是一个包含索引文件index.yaml的HTTP服务器。安装完成后，默认的仓库列表为空，需要手动添加稳定仓库或第三方仓库。由于Helm官方后来调整了稳定仓库策略，很多旧的stable仓库已经不再维护，实际使用中可以选择Bitnami仓库，它提供了大量常用的中间件和应用Chart。
helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update helm repo list
仓库添加后，Helm会把索引缓存到本地，通过helm search repo命令可以按关键字检索Chart。例如搜索mysql，会列出包含该关键字的Chart名称、版本和描述。检索结果中第一列是仓库名/Chart名，这个完整名称在后续安装时需要用到。更新了仓库地址或需要获取最新索引时，要再次执行helm repo update。
除了公共仓库，企业内部也常搭建私有Chart仓库，例如使用ChartMuseum或Harbor的Helm Chart功能。私有仓库同样通过helm repo add添加，只是URL替换成内网地址，如果需要认证，可以使用--username和--password参数。理解仓库机制后，安装Chart时就不容易混淆名称和来源。
Chart部署、升级与回滚
从仓库安装Chart使用helm install命令，它需要一个发布名称和Chart引用。比如要部署一个Nginx应用到名为web的发布中，可以使用Bitnami的nginx Chart。下面的命令演示了标准安装过程，并设置了服务类型为NodePort，方便在集群外访问。安装完成后，Helm会输出一组状态信息，包括发布名称、Chart版本、部署资源和访问方式。
helm install web bitnami/nginx --set service.type=NodePort helm status web helm list
发布安装后，如果需要调整参数或升级Chart版本，可以使用helm upgrade命令。它支持两种方式：通过--set直接覆盖某个参数，或者通过-f values.yaml指定完整参数文件。升级命令会生成一个新的Release版本，旧的Pod会按照滚动更新策略逐步替换。如果升级过程中发现新版本有问题，Helm会保留历史版本，可以通过helm rollback回退到上一个稳定状态。
helm upgrade web bitnami/nginx --set service.type=ClusterIP helm history web helm rollback web 1
回滚操作时，版本号对应的是helm history输出中的REVISION字段，每执行一次install或upgrade都会增加一次修订。回滚本质上是用指定修订版本的配置重新部署资源，因此不会丢失历史记录，反而会产生新的修订。对于需要快速恢复的场景，这个机制比重新执行配置变更更可靠。
values文件与参数覆盖
在命令行中使用--set虽然方便，但参数一多就很难维护，而且无法版本化。实际项目中更推荐将配置写入values.yaml文件，并通过-f参数传给Helm。values文件是YAML格式，结构必须与Chart定义的可配置项保持一致。通常可以从默认values文件入手，使用helm show values bitnami/nginx查看该Chart支持的全部参数。
replicaCount: 2
service:
type: NodePort
ports:
http: 80
resources:
limits:
cpu: 500m
memory: 512Mi
上面的values文件设定了副本数为2，并将服务类型改为NodePort。使用该文件安装或升级时，命令如下。Helm会把values文件中的参数与Chart模板渲染结果合并，最终生成Kubernetes能识别的资源清单。需要注意的是，默认values如果嵌套层级较深，书写时要保持正确的缩进，否则Helm会提示类型转换错误。
helm install web bitnami/nginx -f values.yaml helm upgrade web bitnami/nginx -f values.yaml
如果希望查看实际渲染后的资源而不直接部署，可以使用helm template命令，它会输出完整的YAML内容。这个功能在CI/CD流水线中非常有用，可以让团队在提交配置变更前先审查最终资源定义。总之，把参数集中到values文件并结合helm template做预检查，能显著减少集群中出现意外配置的概率。
HelmCentOSKubernetes修改时间：2026-09-25 22:54:07