在管理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,它对应的就是nginx
Chart在集群里的一次部署。通过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
仓库的nginx
Chart,给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的时候遇到问题,或者对上面这些操作有不明白的地方,比如在特定场景下怎么调整配置,随时来交流。