helm入门指南（一）- 简介
发布时间：2022年3月10日
Helm 是什么
Helm 是官方提供的类似于 YUM 的包管理器，是部署环境的流程封装。
Helm 的安装十分简单，其本质是一个二进制的工具，与其他常用的二进制工具如 git、curl、wget 的安装方式相同，可以通过服务器自身携带的包管理工具进行安装。
Helm 管理的对象有两个，一个是 chart，另一个是 release。
- chart 是创建一个应用所需的完整信息集合，包括了 Deployment、Service、Ingress、PV/PVC 等配置信息，也就是说 chart 是一个应用所有 YAML 配置文件的集合。chart 是应用部署的自包含逻辑单元，通过对 chart 的使用，我们可以将集群管理的范围从单个 YAML 文件拓展到一个完整的应用。
- release 是 chart 的运行实例，代表了一个正在运行的应用。当 chart 被安装到 Kubernetes 集群，就生成一个 release。chart 能够多次安装到同一个集群，每次安装都是一个 release
Helm架构设计
如上图所示，Helm 与 kubernets 集群是相互独立的，helm 在每次应用升级时主要做的是更新前后版本的比对工作，对具体的资源更新的工作是通过对 kube-apiserver 的调用实现。
具体从实现上来看，在 v2 版本中，helm 与集群 kube-apiserver 的通信需要经过 Tiller 组件的代理，而在 v3 版本中，helm 抛弃了 Tiller 组件，转为直接调用 kube-apiserver 来实现对集群资源的变更。
移除 Tiller 组件的使用的好处在于：
- Tiller 是一个与集群 kubectl 相互独立的组件，kubelet 也是通过对 kube-apiserver 的调用来实现资源清单的更新。由于是两个相互独立的工具，就会出现 Tiller 与 kubectl 的权限不同的情况，如果集群中对 kubectl 的访问权限进行了部分限制，使用 Tiller 则可以绕过这些限制直接对集群进行修改，存在一定的安全隐患。
- 在 v2 中使用 helm 命令必须依赖于 Tiller 组件的安装，而在 Tiller 组件安装后，还需要手动执行 helm init 命令完成 helm - Tiller - kubelet 的链接，对系统的侵入性过强。
常用命令
| 命令 | 解释 |
|---|---|
helm repo add {repository-name} {repository-url} |
添加指定的 helm chart 仓库 |
helm -n {namespace} |
指定命名空间 |
helm —kubeconfig={kubeconfig-path} |
使用指定鉴权文件查看集群中应用 |
helm list |
查看当前环境下安装的 helm 应用 |
helm create {chart-name} |
创建一个标准的 chart 包，包名为 chart-name |
helm package {chart-path} |
将 chart 文件所在文件夹打包成一个 .tgz 格式的 chart 包，命名格式为：{chart-name}-{chart-version}.tgz |
helm lint {chart-file} |
对指定的 chart 进行格式校验：1. 配置错误时输出错误位置信息 2. 正确时只输出正确提示，不输出完整配置 |
helm template --debug {chart-file} |
对指定的 chart 进行格式校验。 1. 校验不通过时会提示具体的错误位置与错误信息 2. 校验通过时输出 chart 包中配置的完整应用信息 |
helm get values {release-name} -o yaml/json |
以 yaml/json 格式输出指定应用的现有 values 配置 |
helm install/upgrade {release-name} {chart-file} |
最基础的 helm 安装与更新应用语法 |
helm install/upgrade {release-name} {chart-file} -f {values.yaml} |
常用的语法，用法为：先导出现有应用的 values.yaml 文件，然后在升级应用时通过 -f 指令来使用现有环境的配置，当 values.yaml 文件中与 chart 中的 values.yaml 存在相同的变量时，将会覆盖 chart 包中的配置 常用于客户现场环境中，将客户的镜像仓库地址、域名等信息写入到固定的 values.yaml 文件中，此后进行升级时沿用该配置，可保证与客户环境相关的信息的正确性。每次升级应用后，会将 chart 包中的 values.yaml 信息保存下来做为下次升级时的基础配置信息 |
helm install/upgrade {release-name} {chart-file} --set xxx=yyy |
使用指定 chart 更新对应应用，并通过 –set 命令更新指定 chart 包中的字段，可以通过类似 –set xx.yy[0].zz=aa 语法来实现对象、数组复杂路径指定。 -f 与 – set 优先级排序逻辑为：1. 同种类型的参数传递，如多个 -f / –set，优先级按照在命令行中的位置从左到右递增 2. – set 优先级高于 -f |
helm install/upgrade {release-name} {chart-file} --set-string xxx=yyy |
传入的值将转为字符串进行保存 |
helm install/upgrade {release-name} {chart-file} --set-file xxx=yyy |
当要覆盖的值内容比较多时，比如一个nginx的配置，可以将内容写在一个文件中，并通过 –set-file key={file-path} 来指定读取目标文件内容对字段进行值覆盖 |
helm uninstall {release-name} |
移除当前环境下的某一个应用 |
helm history {release-name} |
查看某一个应用的安装/更新历史记录 |
helm rollback {release-name} {history-id} |
将指定应用回滚到指定的版本 |
当我们使用 helm install/upgrade 命令时，helm 会执行五个阶段：
加载目标 chart 文件
通过整合 chart 中自带的
values.yaml、通过-f选项传入的values.yaml以及通过--set/set-string/set-file传入的值来确定本次安装/更新最终要使用的values将最终的
values与一些内置的变量（如：Release、Chart）传入模板并渲染内置变量列表
变量 解释 Release.Name 安装的应用在 helm 中展示的名称 Release.Time 应用安装时间 Release.Namespace 应用安装到的命名空间 Release.Revision 当前应用的版本号，每 helm upgrade 一次增加一个 Release.IsUpgrade 应用更新标识位，如果是更新或回滚，则为 true Release.IsInstall 应用安装标识位，安装时为 true Values 最外层 values.yaml 文件传入和用户通过 -f / –set 提供的值 Chart 最外层 Chart.yaml 文件的内容 Template 包含有关正在执行的当前模板的信息 Name 到当前模板的 namespace 文件路径，如 mychart/templates/mytemplate.yaml BasePath 当前 chart 模板目录的 namespace 路径，如 mychart/templates
将模板的渲染结果格式化为
YAML调用
kubernetes openapi校验格式化后的资源清单YAML是否正确调用
kube-apiserver的接口完成应用创建
一些用于调试 chart 是否正确的命令，如：
helm template、helm install/upgrade --dry-run只会进行前五步并将 YAML 结果输出到屏幕上
当格式化后的 YAML 格式错误时，通过 openapi 校验时会报错，只会输出错误提示，不会输出生成的 YAML 信息。如果需要展示生成的错误 YAML 文件，可以通过--disable-openapi-validation选项来控制在 YAML 格式错误的情况下仍然输出生成的资源清单列表