Helm ppt
三大概念
•Chart 代表着 Helm 包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定义。
•Repository（仓库） 是用来存放和共享 charts 的地方。
•Release 是运行在 Kubernetes 集群中的 chart 的实例。一个 chart 通常可以在同一个集群中安装多次。每一次安装都会创建一个新的 release。
•Helm 安装 charts 到 Kubernetes 集群中，每次安装都会创建一个新的 release。你可以在 Helm 的 chart repositories 中寻找新的 chart。
Helm 架构
Helm管理名为chart的Kubernetes包的工具。Helm可以做以下的事情：
•从头开始创建新的chart
•将chart打包成归档(tgz)文件
•与存储chart的仓库进行交互
•在现有的Kubernetes集群中安装和卸载chart
•管理与Helm一起安装的chart的发布周期
Helm重要概念：
•chart 创建Kubernetes应用程序所必需的一组信息。
•config 包含了可以合并到打包的chart中的配置信息，用于创建一个可发布的对象。
•release 是一个与特定配置相结合的chart的运行实例。
组件
Helm是一个可执行文件，执行时分成两个不同的部分：
Helm客户端 是终端用户的命令行客户端。负责以下内容：
•本地chart开发
•管理仓库
•管理发布
•与Helm库建立接口
•发送安装的chart
•发送升级或卸载现有发布的请求
Helm库 提供执行所有Helm操作的逻辑。与Kubernetes API服务交互并提供以下功能：
•结合chart和配置来构建版本
•将chart安装到Kubernetes中，并提供后续发布对象
•与Kubernetes交互升级和卸载chart
独立的Helm库封装了Helm逻辑以便不同的客户端可以使用它。
执行
•Helm客户端和库是使用Go编程语言编写的
•这个库使用Kubernetes客户端库与Kubernetes通信。现在，这个库使用REST+JSON。它将信息存储在Kubernetes的密钥中。 不需要自己的数据库。
•如果可能，配置文件是用YAML编写的。
Helm 3变化概述
移除了Tiller:
•用client/library结构（仅仅helm）替换了 client/server
•安全性现在是每个用户的基础（委托给了Kubernetes用户集群安全）
•发布版本现在作为集群内的密钥存储且改变了发布对象的元数据
•发布版本是在版本命名空间的基础上持久化的并且不再是Tiller的命名空间
升级了Chart仓库：
•helm search 现在支持本地仓库搜索和Artifact Hub查询
对于以下更新的规范，Chart的apiVersion升级到了”v2”：
•动态依赖的chart依赖移动到了Chart.yaml (删除了requirements.yaml 且 requirements –> dependencies)
•库chart (辅助/公共库) 现在可以添加为动态链接的chart依赖
•Chart有个type元数据字段将chart定义为application或library的chart。默认是可渲染和安装的应用
•Helm 2 的chart (apiVersion=v1) 依然可用
添加了XDG目录规范：
•Helm根目录针对存储配置文件删除和替换了XDG目录规范
•不再需要初始化Helm
•移除了helm init 和 helm home
其他更改：
•简化了Helm的安装和设置：
•仅针对Helm客户端 (二进制)
•按照已有范式运行
•不再默认设置local或stable仓库
•删除了crd-install钩子并用chart中的crds目录替换了，在渲染chart之前会安装所有的crd
•删除了test-failure钩子注释值，且弃用了test-success。使用test代替
删除/替换/添加的命令：
•delete –> uninstall : 默认删除所有的发布记录（之前需要–purge）
•fetch –> pull
•home (已删除)
•init (已删除)
•install: 需要发布名称或者–generate-name 参数
•inspect –> show
•reset (已删除)
•serve (已删除)
•template: -x/–execute 参数重命名为 -s/–show-only
•upgrade: 添加了参数 –history-max，限制每个版本保存的最大记录数量（0表示不限制）
Helm 3 Go库经历了很多变化，不再兼容Helm 2库
发行版二进制包现在托管在 get.helm.sh
Helm 一般惯例
Chart名称
•chart名称必须是小写字母和数字。单词之间 可以 使用横杠分隔(-)：
aws-cluster-autoscaler
•不能用大写字母也不能用下划线。点 . 符号也不行。
版本号
•Helm尽可能使用 SemVer 2来表示版本号。
格式化YAML
•YAML 文件应该按照双空格缩进(绝不要使用tab键)。
Helm 和 Chart的用法
•Helm 是指整个项目
•helm 是指客户端命令
•chart 不是专有名词，不需要首字母大写
•但Chart.yaml需要首字母大写，因为文件名大小写敏感
Chart
•Helm使用的包格式称为 chart。 chart就是一个描述Kubernetes相关资源的文件集合。
•Chart是作为特定目录布局的文件被创建的。它们可以打包到要部署的版本存档中。
•helm pull chartrepo/chartname
下载和查看一个发布的chart，但不安装
‘helm search’：查找 Charts
•helm search hub 从 Artifact Hub 中查找并列出 helm charts。
•helm search repo 从你添加（使用 helm repo add）到本地 helm 客户端中的仓库中进行查找。
‘helm install’：安装一个 helm 包
•$ helm install happy-panda bitnami/wordpress –generate-name
•NAME: happy-panda
•LAST DEPLOYED: Tue Jan 26 10:27:17 2021
•NAMESPACE: default
•STATUS: deployed
•REVISION: 1
•NOTES: …
•$ helm status
追踪 release 的状态，或是重新读取配置信息
helm install 命令可以从多个来源进行安装：
•chart 的仓库
•本地 chart 压缩包
helm install foo foo-0.1.1.tgz
•解压后的 chart 目录
helm install foo path/to/foo
•完整的 URL
helm install foo https://example.com/charts/foo-1.2.3.tgz
•$ helm show values bitnami/wordpress
查看 chart 中的可配置选项
$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml
$ helm install -f values.yaml bitnami/wordpress --generate-name
•安装过程中有两种方式传递配置数据：
–values (或 -f)：使用 YAML 文件覆盖配置。可以指定多次，优先使用最右边的文件。
–set：通过命令行的方式对指定项进行覆盖。(优先级更高)
•在–set 中覆盖的内容会被被保存在 ConfigMap 中
•helm get values
•helm upgrade –reset-values 清除 –set 中设置的值
创建charts
•$ helm create deis-workflow
•Creating deis-workflow
•helm lint
验证格式是否正确
•$ helm package deis-workflow
•deis-workflow-0.1.0.tgz
•$ helm install deis-workflow ./deis-workflow-0.1.0.tgz
‘helm upgrade’：升级 release & ‘helm rollback’：失败时恢复
$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress
•helm upgrade –install happy-panda bitnami/wordpress
•查看是否已经安装版本， 如果没有，会执行安装；如果版本存在，会进行升级
•helm get values
查看配置值是否生效
•$ helm rollback happy-panda 1
•helm history happy-panda
查看一个特定 release 的修订版本号
‘helm uninstall’：卸载 release
•$ helm uninstall happy-panda –keep-history
•helm list –uninstalled –all
查看当前部署的所有 release
告诉Helm不要卸载资源
•有时在执行helm uninstall时有些资源不应该被卸载。Chart的开发者可以在资源中添加额外的说明避免被卸载。
•kind: Secret
•metadata:
• annotations:
“helm.sh/resource-policy”: keep
•这个说明”helm.sh/resource-policy”: keep指示Helm操作(比如helm uninstall，helm upgrade 或helm rollback)要删除时跳过删除这个资源，然而，这个资源会变成孤立的。
•Helm不再以任何方式管理它。 如果在已经卸载的但保留资源的版本上使用helm install –replace会出问题。
‘helm repo’：使用仓库
•Helm 3 不再附带一个默认的 chart 仓库。
•helm repo 提供了一组命令用于添加、列出和移除仓库。
•helm repo list
查看配置的仓库
•helm repo add bitnami https://charts.bitnami.com/bitnami
•helm repo update
•helm repo remove
创建一个chart仓库
•chart仓库 是一个配置了index.yaml文件和一些已经打包chart的HTTP服务器。当你准备好分享chart时，最好的方法是将chart上传到chart仓库。
•注： 从Helm 2.2.0开始，客户端支持对仓库进行SSL身份认证。其他身份验证协议可以通过插件提供。
•由于chart仓库可以是任何服务于YAML和tar文件并响应GET请求的HTTP服务器，托管你自己的chart仓库时就有很多选择。比如可以使用Google Cloud Storage(GCS)， Amazon S3，GitHub页面，甚至创建自己的web服务器。
chart仓库结构
•chart仓库由chart包和包含了仓库中所有chart索引的特殊文件index.yaml。
•通常描述chart的index.yaml也托管在同一个服务器上作为 来源文件(不是必须和chart包放在同一个服务器上，但是这样是最方便的)。
•比如，https://example.com/charts仓库布局可能看起来像这样：
•charts/
• |
• |- index.yaml
• |
• |- alpine-0.1.2.tgz
• |
• |- alpine-0.1.2.tgz.prov
•在这个案例中，index文件包含了Alpine这一个chart的信息，并提供了下载地址：https://example.com/charts/alpine-0.1.2.tgz。
index文件
•yaml格式，包含了一些包的元信息，包括chart中Chart.yaml文件的内容。
•一个合法的chart仓库必须有一个index文件，包含了chart仓库中每一个chart的信息。
•helm repo index命令会基于给定的包含chart包的本地目录生成一个index文件。
托管chart仓库
•Google Cloud存储
•Cloudsmith
•JFrog Artifactory
•GitHub页面
•普通web服务器
ChartMuseum 仓库服务器
在chart仓库中存储chart
•$ helm package docs/examples/alpine/
•$ mkdir fantastic-charts
•$ mv alpine-0.1.0.tgz fantastic-charts/
•$ helm repo index fantastic-charts –url https://fantastic-charts.storage.googleapis.com
(用刚才创建的本地路径和远程仓库url构建一个index.yaml文件放在给定的目录路径中)。
•现在你可以使用同步工具或手动上传chart和index文件到chart仓库中。如果使用的是Google Cloud Storage，使用gsutil客户端检查 示范工作流。针对于GitHub，你可以简单地将chart放在合适的目标分支中。
添加一个新的chart到已有仓库中
每次你想在仓库中添加一个新的chart时，你必须重新生成index。helm repo index命令会完全无痕重建index.yaml文件。只包括在本地找到的chart。
不过你可以使用–merge参数增量添加新的chart到现有index.yaml文件中（使用类似GCS的远程仓库时很有用）。
确保订过的index.yaml文件和chart都上传了，如果生成了源文件，也要上传。
与别人分享你的chart
准备好分享你的chart时，只需要告诉别人你的仓库地址就可以了。
他们会通过helm repo add [NAME] [URL]命令将仓库添加到他们的客户端，并使用想引用仓库的任何名称。
•$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com
•$ helm repo list
•fantastic-charts https://fantastic-charts.storage.googleapis.com
•如果chart支持HTTP的基础验证，你也需要提供用户名和密码
Chart 文件结构
•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 # 可选: 包含简要使用说明的纯文本文件
Templating Engine
–set 的格式和限制
Chart.yaml
必需
•apiVersion name version
可选
•kubeVersion description type keywords home sources
•dependencies maintainers（name, email, url）
•icon appVersion deprecated annotations
Templates and Values
Helm Chart 模板是按照 Go模板语言书写， 增加了50个左右的附加模板函数 来自 Sprig库 和一些其他 指定的函数。
所有模板文件存储在chart的 templates/ 文件夹。 当Helm渲染chart时，它会通过模板引擎遍历目录中的每个文件。
•NOTES.txt: chart的”帮助文本”。这会在你的用户执行helm install时展示给他们。
•deployment.yaml: 创建Kubernetes 工作负载的基本清单
•service.yaml: 为你的工作负载创建一个 service终端基本清单。
•_helpers.tpl: 放置可以通过chart复用的模板辅助对象
模板的Value通过两种方式提供：
•Chart开发者可以在chart中提供一个命名为 values.yaml 的文件。这个文件包含了默认值。
•Chart用户可以提供一个包含了value的YAML文件。可以在命令行使用 helm install命令时提供。
•$ helm install –generate-name –values=myvals.yaml wordpress
•当用户提供自定义value时，这些value会覆盖chart的values.yaml文件中value。
helm get manifest
$ helm install full-coral ./mychart
$ helm get manifest full-coral
•—
•# Source: mychart/templates/configmap.yaml
•apiVersion: v1
•kind: ConfigMap
•metadata:
• name: mychart-configmap
•data:
myvalue: “Hello World”
添加一个简单的模板调用
Release前面的点表示从作用域最顶层的命名空间开始。
这样.Release.Name就可解读为“通顶层命名空间开始查找 Release对象，然后在其中找Name对象”。
Release是一个Helm的内置对象。它可以显示从库中赋值的发布名称。
$ helm install –debug –dry-run goodly-guppy ./mychart
让服务器渲染模板，然后返回生成的清单文件。
使用–dry-run会使测试代码变得很简单，但不能保证Kubernetes本身会接受生成模板。
内置对象
Release：
该对象描述了版本发布本身。包含了以下对象：
•Release.Name： release名称
•Release.Namespace： 版本中包含的命名空间(如果manifest没有覆盖的话)
•Release.IsUpgrade： 如果当前操作是升级或回滚的话，需要将该值设置为true
•Release.IsInstall： 如果当前操作是安装的话，需要将该值设置为true
•Release.Revision： 此次修订的版本号。安装时是1，每次升级或回滚都会自增
•Release.Service： 该service用来渲染当前模板。Helm里一般是Helm
Values：
Values是从values.yaml文件和用户提供的文件传进模板的。Values默认为空
Chart： Chart.yaml文件内容。 Chart.yaml里的任意数据在这里都可以可访问的。
比如 {{ .Chart.Name }}-{{.Chart.Version }} 会打印出 mychart-0.1.0
Files：
在chart中提供访问所有的非特殊文件。当你不能使用它访问模板时，你可以访问其他文件。
•Files.Get 通过文件名获取文件的方法。 （.Files.Getconfig.ini）
•Files.GetBytes 用字节数组代替字符串获取文件内容的方法。 对图片之类的文件很有用
•Files.Glob 用给定的shell glob模式匹配文件名返回文件列表的方法
•Files.Lines 逐行读取文件内容的方法。迭代文件中每一行时很有用
•Files.AsSecrets 使用Base 64编码字符串返回文件体的方法
•Files.AsConfig 使用YAML格式返回文件体的方法
Capabilities：
提供关于Kubernetes集群支持功能的信息
•Capabilities.APIVersions 是一个版本集合
•Capabilities.APIVersions.Has $version 说明集群中的版本 (e.g., batch/v1) 或是资源 (e.g., apps/v1/Deployment) 是否可用
•Capabilities.KubeVersion 和 Capabilities.KubeVersion.Version 是Kubernetes的版本号
•Capabilities.KubeVersion.Major Kubernetes的主版本
•Capabilities.KubeVersion.Minor Kubernetes的次版本
Template：
包含了已经被执行的当前模板信息
•Template.Name: 当前模板的命名空间文件路径 (e.g. mychart/templates/mytemplate.yaml)
•Template.BasePath: 当前chart模板目录的路径 (e.g. mychart/templates)
Values 文件
Values提供了对传递到chart的值的访问方法， 其内容源包括了多个位置：
•chart中的values.yaml文件
•如果是子chart，就是父chart中的values.yaml文件
•使用-f参数(helm install -f myvals.yaml ./mychart)传递到 helm install 或 helm upgrade的values文件
•使用–set (比如helm install –set foo=bar ./mychart)传递的单个参数
顺序：默认使用values.yaml，可以被父chart的values.yaml覆盖，继而被用户提供values文件覆盖， 最后会被–set参数覆盖。
模板函数和流水线
•管道符
drink: {{ quote .Values.favorite.drink }}
drink: {{ .Values.favorite.drink | quote }}
{{ .Values.favorite.food | upper | quote }}
模板功能
value: {{ .Values.who | quote }} (使用整型时 不quote)
value: {{ .Values.who | repeat 5 | quoto}}
value: {{ .Values.who | lower | upper }}
value: {{ include "mytpl" . | lower | quote }}
value: {{ required "A valid entry required!" .Values.who }}
value: {{ .Values.who | default "my-default-value" }}
value: {{ .Values.who | indent 6 }}
value: {{ .Values.who | nindent 6 }} (在字符串开头添加新行)
流控制
{{ if PIPELINE }}
• # Do something
{{ else if OTHER PIPELINE }}
• # Do something else
{{ else }}
• # Default case
{{ end }}
管道会被设置为 false：
布尔false
数字0
空字符串
nil (空或null)
空集合(map, slice, tuple, dict, array)
{{ with PIPELINE }}
• # restricted scope
{{ end }}
•.是对 当前作用域 的引用。因此 .Values就是告诉模板在当前作用域查找Values对象。
•with允许你为特定对象设定当前作用域(.)。
•在限定的作用域内，无法使用.访问父作用域的对象(Release.Name)。
•或者，我们可以使用**$**从父作用域中访问Release.Name对象。
•当模板开始执行后$会被映射到根作用域，且执行过程中不会更改。
{{ $.Release.Name }}
values.yaml
range操作符也设置了.的作用域。
每一次循环，.都会设置为当前的pizzaTopping。
我们可以直接发送.的值给管道。
(|- YAML中是指多行字符串）
变量
命名模板
•此时需要越过模板，开始创建其他内容了。命名模板 (有时称作一个 部分 或一个 子模板)仅仅是在文件内部定义的模板，并使用了一个名字。有两种创建方式和几种不同的使用方法。
•模板名称是全局的。如果您想声明两个相同名称的模板，哪个最后加载就使用哪个。 因为在子chart中的模板和顶层模板一起编译，命名时要注意chart特定名称。
•一个常见的命名惯例是用chart名称作为模板前缀：
{{ define "mychart.labels" }}
用define和template声明和使用模板
按照惯例，Helm chart将这些模板放置在局部文件中，一般是_helpers.tpl
define方法会有个简单的文档块({{/* ... */}})来描述功能
局部的和_文件
Helm的模板语言允许你创建命名的嵌入式模板， 这样就可以在其他位置按名称访问。
文件的命名惯例：
•templates/中的大多数文件被视为包含Kubernetes清单
•NOTES.txt是个例外
•命名以下划线(_)开始的文件则假定没有包含清单内容。这些文件不会渲染为Kubernetes对象定义，但在其他chart模板中都可用。
•这些文件用来存储局部和辅助对象，实际上当我们第一次创建mychart时，会看到一个名为_helpers.tpl的文 件，这个文件是模板局部的默认位置。
设置模板范围
helm install –dry-run –disable-openapi-validation moldy-jaguar ./mychart
{{- template "mychart.labels" . }}
include方法
由于template是一个行为，不是方法，无法将 template调用的输出传给其他方法，数据只是简单地按行插入。
include方法：更好地处理YAML文档的输出格式
在模板内部访问文件
Helm 提供了通过**.Files**对象访问文件的方法。不过，在我们使用模板示例之前，有些事情需要注意：
•可以添加额外的文件到chart中。虽然这些文件会被绑定。但是由于Kubernetes对象的限制，Chart必须小于1M。
•通常处于安全考虑，一些文件无法通过.Files对象访问：
•无法访问templates/中的文件
•无法访问使用.helmignore排除的文件
•Chart不能保留UNIX模式信息，因此当文件涉及到.Files对象时，文件级权限不会影响文件的可用性。
•mychart/config1.toml: message = Hello from config 1
•mychart/config2.toml: message = Hello from config 2
•mychart/config3.toml: message = Hello from config 3
子chart和全局值
chart可以使用依赖，称为 子chart，且有自己的值和模板。
在深入研究代码之前，需要了解一些子chart的重要细节：
•子chart被认为是“独立的”，意味着子chart从来不会显示依赖它的父chart。
•父chart可以覆盖子chart的值。
•Helm有一个 全局值 的概念，所有的chart都可以访问。
创建子chart
•$ cd mychart/charts
•$ helm create mysubchart
•Creating mysubchart
•$ rm -rf mysubchart/templates/*
用父chart的值来覆盖
•mychart/charts/mysubchart/values.yaml
•dessert: cake
•mychart/charts/mysubchart/templates/configmap.yaml
•data:
dessert: {{ .Values.dessert }}
•mychart/values.yaml
•dessert: ice cream
在mysubchart中的所有指令会被发送到mysubchart中。
运行helm install –dry-run –debug mychart，会看到一项mysubchart的配置：
现在，子chart的值已经被顶层的值覆盖了。
我们不会改变mychart/charts/mysubchart/templates/configmap.yaml模板到 .Values.mysubchart.dessert的指向。
从模板的角度来看，值依然是在.Values.dessert。
当模板引擎传递值时，会设置范围。 因此对于mysubchart模板，.Values中只提供专门用于mysubchart的值。
但是有时确实希望某些值对所有模板都可用。这是使用全局chart值完成的。
全局Chart值
•全局值是使用完全一样的名字在所有的chart及子chart中都能访问的值。
•全局变量需要显示声明。
•不能将现有的非全局值作为全局值使用。
•这些值数据类型有个保留部分叫Values.global，可以用来设置全局值。
•mychart/values.yaml：
•global:
•salad: caesar
•mychart/templates/configmap.yaml和mysubchart/templates/configmap.yaml 应该都能以{{ .Values.global.salad }}进行访问。
与子chart共享模板
父chart和子chart可以共享模板。在任意chart中定义的块在其他chart中也是可用的。
可以这样定义一个简单的模板：
{{- define "labels" }}from: mychart{{ end }}
模板标签全局共享。因此，标签chart可以包含在任何其他chart中。
库类型Chart
•库类型chart是一种 Helm chart，定义了可以由其他chart中Helm模板共享的chart原语或定义。这允许用户通过chart分享可复用得代码片段来避免重复并保持chart 干燥。
•在Helm 3中引用了库chart，从形式上区别于Helm 2中chart维护的通用或辅助chart。 作为一个chart类型引入，可以提供：
•一种明确区分通用和应用chart的方法
•逻辑上阻止安装通用chart
•通用chart中的未渲染模板可以包含版本组件
•chart维护者可以定义一个通用的chart作为库并且现在可以确信Helm将以标准一致的方式处理chart。 也意味着通过改变chart类型来分享应用chart中的定义。
创建一个简单的库chart
•$ helm create mylibchart
•Creating mylibchart
•$ rm -rf mylibchart/templates/*
•$ rm -f mylibchart/values.yaml
•已命名的模板 (有时称为局部模板或子模板)是定义在一个文件中的简单模板，并分配了一个名称。
•在templates/目录中， 所有以下划线开始的文件()不会输出到Kubernetes清单文件中。因此依照惯例，辅助模板和局部模板被放置在.tpl或_.yaml文件中。
这个示例中，我们要写一个通用的配置映射来创建一个空的配置映射源。在mylibchart/templates/_configmap.yaml文件中定义如下：
•这个配置映射结构被定义在名为mylibchart.configmap.tpl的模板文件中。
data是一个空源的配置映射， 这个文件中另一个命名的模板是mylibchart.configmap。
这个模板包含了另一个模板mylibchart.util.merge， 会使用两个命名的模板作为参数，称为mylibchart.configmap和mylibchart.configmap.tpl。
mylibchart/templates/_util.yaml
复制方法mylibchart.util.merge是mylibchart/templates/_util.yaml文件中的一个命名模板。 是 通用Helm辅助Chart的实用工具。因为它合并了两个模板并覆盖了两个模板的公共部分。
mylibchart/Chart.yaml
这个库chart现在可以分享了，并且配置映射定义可以复用了。
使用简单的库chart
•$ helm create mychart
•Creating mychart
•$ rm -rf mychart/templates/*
mychart/templates/configmap.yaml
可以看到这简化了我们通过继承为添加了标准属性的公共配置映射定义必须要做的事情。在模板中添加了配置，在这个示例中的数据key myvalue和值。这个配置会覆盖公共配置映射中的空源。因为我们在上一节中提到的辅助方法mylibchart.util.merge，这是可行的。
为了能使用通用代码，我们需要添加mylibchart作为依赖。将以下内容添加到mychart/Chart.yaml文件的末尾：
使用简单的库chart
这包含了作为文件系统动态依赖的**库chart，和我们的应用chart**位于同一父路径下。由于将库chart作为动态依赖， 我们需要执行helm dependency update，它会拷贝库chart到你的charts/目录。
•$ helm dependency update mychart/
现在我们准备好部署chart了。安装之前，需要先检测渲染过的模板。
•$ helm install mydemo mychart/ –debug –dry-run
现在安装：
•$ helm install mydemo mychart/
•我们可以检索这个版本并看到实际的版本已经加载。
•$ helm get manifest mydemo
The Common Helm Helper Chart
•这个 chart是公共chart的初始模式。 它提供的应用程序反映了Kubernetes chart开发的最佳实践。开发chart时可以立即使用共享代码。
•$ helm create demo
•Creating demo
demo/templates/deployment.yaml
demo/Chart.yaml
demo/templates/service.yaml
注意：需要添加incubator仓库到Helm仓库列表中(helm repo add)。
由于我们引用了一个chart作为动态依赖，需要执行helm dependency update。这样会将辅助chart拷贝到你的charts/目录。
Chart Hook
Helm 提供了一个 hook 机制允许chart开发者在发布生命周期的某些点进行干预。比如你可以使用hook用于：
•安装时在加载其他chart之前加载配置映射或密钥
•安装新chart之前执行备份数据库的任务，然后在升级之后执行第二个任务用于存储数据。
•在删除发布之前执行一个任务以便在删除服务之前退出滚动。
钩子的工作方式与常规模板类似，但因为Helm对其不同的使用方式，会有一些特殊的注释。这部分会讲述钩子的基本使用模式。
可用的钩子
定义了以下钩子：
注释值 描述
•pre-install 在模板渲染之后，Kubernetes资源创建之前执行
•post-install 在所有资源加载到Kubernetes之后执行
•pre-delete 在Kubernetes删除之前，执行删除请求
•post-delete 在所有的版本资源删除之后执行删除请求
•pre-upgrade 在模板渲染之后，资源更新之前执行一个升级请求
•post-upgrade 所有资源升级之后执行一个升级请求
•pre-rollback 在模板渲染之后，资源回滚之前，执行一个回滚请求
•post-rollback 在所有资源被修改之后执行一个回滚请求
•test 调用Helm test子命令时执行 ( test文档)
钩子和发布生命周期
•钩子允许你在发布生命周期的关键节点上有机会执行操作。比如，考虑helm install的生命周期。默认生命周期看起来是这样：
1.用户执行helm install foo
2.Helm库调用安装API
3.在一些验证之后，库会渲染foo模板
4.库会加载结果资源到Kubernetes
5.库会返回发布对象（和其他数据）给客户端
6.客户端退出
钩子和发布生命周期
Helm 为install周期定义了两个钩子：pre-install和post-install。如果foo chart的开发者两个钩子都执行， 周期会被修改为这样：
1.用户返回 helm install foo
2.Helm库调用安装API
3.在 crds/目录中的CRD会被安装
4.在一些验证之后，库会渲染foo模板
5.库准备执行pre-install钩子(将hook资源加载到Kubernetes中)
6.库按照权重对钩子排序(默认将权重指定为0)，然后在资源种类排序，最后按名称正序排列。
7.库先加载最小权重的钩子(从负到正)
8.库会等到钩子是 “Ready”状态(CRD除外)
9.库将生成的资源加载到Kubernetes中。注意如果设置了–wait参数，库会等所有资源是ready状态， 且所有资源准备就绪后才会执行post-install钩子。
10.库执行post-install钩子(加载钩子资源)。
11.库会等到钩子是”Ready”状态
12.库会返回发布对象(和其他数据)给客户端
13.客户端退出
等钩子准备好是什么意思？
• 这取决于钩子声明的资源。
•如果资源是 Job 或 Pod类型，Helm会等到直到他成功运行完成。 如果钩子失败，发布就会失败。这是一个阻塞操作,所以Helm客户端会在这个任务执行时暂停。
•针对其他种类，一旦Kubernetes将资源标记为已加载(已添加或已更新)，资源会被认为是”Ready“。 当一个钩子中声明了很多资源时， 资源会串行执行。如果有钩子权重，会按照权重顺序执行。从Helm 3.2.0开始，具有相同权重的钩子资源会和普通非钩子资源以相同的顺序安装。 否则，顺序就无法保证。（Helm 2.3.0及之后，它们按照字母排序。不过该行为并不会绑定，将来可能会改变。）增加钩子权重被认为是很好的做法， 如果权重不重要，可以设置为0。
钩子资源不使用对应版本管理
钩子创建的资源无法作为发布的一部分进行跟踪和管理。一旦Helm验证hook达到ready状态，将不使用钩子资源。 当对应发布删除后，钩子资源的垃圾回收会在将来添加到Helm 3中，因此不能被删除的钩子资源应该添加注释：
helm.sh/resource-policy: keep
实际上，如果你在钩子中创建了资源，不能依靠helm uninstall去删除资源。要删除这些资源:
•要么在钩子模板文件中添加一个自定义的helm.sh/hook-delete-policy 注释
•要么 设置任务资源的生存时间（TTL）字段
编写一个钩子
钩子就是在metadata部分指定了特殊注释的Kubernetes清单文件。
因为是模板文件，你可以使用所有的普通模板特性，包括读取 .Values， .Release，和 .Template。
比如这个模板，存储在templates/post-install-job.yaml，声明了一个要运行在post-install上的任务：
一个资源可以实现多个钩子：
annotations:
“helm.sh/hook”: post-install,post-upgrade
Chart Test
chart包含了很多一起工作的Kubernetes资源和组件。作为一个chart作者，你可能想写一些测试验证chart安装时是否按照预期工作。 这些测试同时可以帮助chart用户理解你的chart在做什么。
test 在helm chart中放在 templates/目录，并且是一个指定了容器和给定命令的任务。如果测试通过，容器应该成功退出 (exit 0) 任务的定义必须包含helm测试钩子的注释：helm.sh/hook: test。
示例测试以下内容：
•验证你values.yaml文件中的配置可以正确注入
•确保你的用户名和密码是对的
•确保不正确的用户名和密码不会工作
•判断你的服务只启动的并且正确地负载均衡
你可以在Helm的一个版本中运行预定义的测试，执行
helm test
对于chart用户来说， 这是验证chart发布（或应用）可以正常运行的很好的方式。
运行一个发布版本测试套件的步骤
首先，安装chart到你的集群中创建一个版本。需要等待所有的pod变成active的状态；如果安装之后立即执行test， 可能会出现相应的失败，你不得不再执行一次test。
•注:
•你可以在单个yaml文件中定义尽可能多的测试或者分布在templates/目录中的多个yaml文件中。
•为了更好地隔离，欢迎你将测试套件嵌套放在tests/目录中，类似
•一个test就是一个 Helm 钩子，所以类似于 helm.sh/hook-weight和helm.sh/hook-delete-policy的注释可以用于测试资源。
