3.1 为什么需要Helm？
K8S上的应用对象，都是由特定的资源描述组成，包括deployment、service等。都保存各自文件中或者集中写到一个配置文件。然后kubectl apply –f 部署。
如果应用只由一个或几个这样的服务组成，上面部署方式足够了。
而对于一个复杂的应用，会有很多类似上面的资源描述文件，例如微服务架构应用，组成应用的服务可能多达十个，几十个。如果有更新或回滚应用的需求，可能要修改和维护所涉及的大量资源文件，而这种组织和管理应用的方式就显得力不从心了。
且由于缺少对发布过的应用版本管理和控制，使Kubernetes上的应用维护和更新等面临诸多的挑战，主要面临以下问题：
-
如何将这些服务作为一个整体管理
-
这些资源文件如何高效复用
-
不支持应用级别的版本管理
3.2 Helm 介绍
Helm是一个Kubernetes的包管理工具，就像Linux下的包管理器，如yum/apt等，可以很方便的将之前打包好的yaml文件部署到kubernetes上。
Helm有两个重要概念：
-
helm：一个命令行客户端工具，主要用于Kubernetes应用chart的创建、打包、发布和管理。
-
Chart：应用描述，一系列用于描述 k8s 资源相关文件的集合。
-
Release：基于Chart的部署实体，一个 chart 被 Helm 运行后将会生成对应的一个 release；将在k8s中创建出真实运行的资源对象。
3.3 Helm v3 变化
2019年11月13日， Helm团队发布 Helm v3的第一个稳定版本。
该版本主要变化如下：
1、 架构变化
最明显的变化是 Tiller的删除
2、Release名称可以在不同命名空间重用
3、支持将 Chart 推送至 Docker 镜像仓库中
4、使用JSONSchema验证chart values
5、其他
1）为了更好地协调其他包管理者的措辞 Helm CLI个别更名
helm delete` 更名为 `helm uninstall
helm inspect` 更名为 `helm show
helm fetch` 更名为 `helm pull
但以上旧的命令当前仍能使用。
2）移除了用于本地临时搭建 Chart Repository的 helm serve 命令。
3）自动创建名称空间
在不存在的命名空间中创建发行版时，Helm 2创建了命名空间。Helm 3遵循其他Kubernetes对象的行为，如果命名空间不存在则返回错误。
4） 不再需要requirements.yaml, 依赖关系是直接在chart.yaml中定义。
安装
首先当然需要一个可用的 Kubernetes 集群，然后在我们使用 Helm 的节点上已经配置好可以通过 kubectl 访问集群，因为 Helm 其实就是读取的 kubeconfig 文件来访问集群的。
由于 Helm V2 版本必须在 Kubernetes 集群中安装一个 Tiller 服务进行通信，这样大大降低了其安全性和可用性，所以在 V3 版本中移除了服务端，采用了通用的 Kubernetes CRD 资源来进行管理，这样就只需要连接上 Kubernetes 即可，而且 V3 版本已经发布了稳定版，所以我们这里来安装最新的 v3.0.1 版本，软件包下载地址为：Releases · helm/helm · GitHub，我们可以根据自己的节点选择合适的包，比如我这里是 Mac，就下载 MacOS amd64 的版本。
下载到本地解压后，将 helm 二进制包文件移动到任意的 PATH 路径下即可：
$ helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}
看到上面的版本信息证明已经成功了。
一旦 Helm 客户端准备成功后，我们就可以添加一个 chart 仓库，当然最常用的就是官方的 Helm stable charts 仓库，但是由于官方的 charts 仓库地址需要科学上网，我们可以使用微软的 charts 仓库代替：
$ helm repo add stable http://mirror.azure.cn/kubernetes/charts/
$ helm repo list
NAME URL
stable http://mirror.azure.cn/kubernetes/charts/
安装完成后可以用 search 命令来搜索可以安装的 chart 包：
$ helm search repo stable
NAME CHART VERSION APP VERSION DESCRIPTION
stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools
stable/aerospike 0.3.1 v4.5.0.5 A Helm chart for Aerospike in Kubernetes
stable/airflow 5.2.1 1.10.4 Airflow is a platform to programmatically autho...
stable/ambassador 5.1.0 0.85.0 A Helm chart for Datawire Ambassador
stable/anchore-engine 1.3.7 0.5.2 Anchore container analysis and policy evaluatio...
stable/apm-server 2.1.5 7.0.0 The server receives data from the Elastic APM a...
......
示例
为了安装一个 chart 包，我们可以使用 helm install 命令，Helm 有多种方法来找到和安装 chart 包，但是最简单的方法当然是使用官方的 stable 这个仓库直接安装：
首先从仓库中将可用的 charts 信息同步到本地，可以确保我们获取到最新的 charts 列表：
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
比如我们现在安装一个 mysql 应用：
$ helm install stable/mysql --generate-name
NAME: mysql-1575619811
LAST DEPLOYED: Fri Dec 6 16:10:14 2019
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
mysql-1575619811.default.svc.cluster.local
......
我们可以看到 stable/mysql 这个 chart 已经安装成功了，我们将安装成功的这个应用叫做一个 release，由于我们在安装的时候指定了--generate-name 参数，所以生成的 release 名称是随机生成的，名为 mysql-1575619811。我们可以用下面的命令来查看 release 安装以后对应的 Kubernetes 资源的状态：
$ kubectl get all -l release=mysql-1575619811
NAME READY STATUS RESTARTS AGE
pod/mysql-1575619811-8479b5b796-dgggz 0/1 Pending 0 27m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/mysql-1575619811 ClusterIP 10.106.141.228 <none> 3306/TCP 27m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/mysql-1575619811 0/1 1 0 27m
NAME DESIRED CURRENT READY AGE
replicaset.apps/mysql-1575619811-8479b5b796 1 1 0 27m
我们也可以 helm show chart 命令来了解 MySQL 这个 chart 包的一些特性：
$ helm show chart stable/mysql
......
如果想要了解更多信息，可以用 helm show all 命令：
$ helm show all stable/mysql ......
需要注意的是无论什么时候安装 chart，都会创建一个新的 release，所以一个 chart 包是可以多次安装到同一个集群中的，每个都可以独立管理和升级。
同样我们也可以用 Helm 很容易查看到已经安装的 release：
$ helm ls NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1575619811 default 1 2019-12-06 16:10:14.682302 +0800 CST deployed mysql-1.5.0 5.7.27
如果需要删除这个 release，也很简单，只需要使用 helm uninstall 命令即可：
$ helm uninstall mysql-1575619811 release "mysql-1575619811" uninstalled $ kubectl get all -l release=mysql-1575619811 No resources found. $ helm status mysql-1575619811 Error: release: not found
uninstall 命令会从 Kubernetes 中删除 release，也会删除与 release 相关的所有 Kubernetes 资源以及 release 历史记录。也可以在删除的时候使用 --keep-history 参数，则会保留 release 的历史记录，可以获取该 release 的状态就是 UNINSTALLED，而不是找不到 release了：
$ helm uninstall mysql-1575619811 --keep-history release "mysql-1575619811" uninstalled $ helm status mysql-1575619811 helm status mysql-1575619811 NAME: mysql-1575619811 LAST DEPLOYED: Fri Dec 6 16:47:14 2019 NAMESPACE: default STATUS: uninstalled ... $ helm ls -a NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1575619811 default 1 2019-12-06 16:47:14.415214 +0800 CST uninstalled mysql-1.5.0 5.7.27
因为 Helm 会在删除 release 后跟踪你的 release，所以你可以审查历史甚至取消删除 release（使用 helm rollback 命令）。
定制
上面我们都是直接使用的 helm install 命令安装的 chart 包，这种情况下只会使用 chart 的默认配置选项，但是更多的时候，是各种各样的需求，索引我们希望根据自己的需求来定制 chart 包的配置参数。
我们可以使用 helm show values 命令来查看一个 chart 包的所有可配置的参数选项：
$ helm show values stable/mysql ## mysql image version ## ref: https://hub.docker.com/r/library/mysql/tags/ ## image: "mysql" imageTag: "5.7.14" busybox: image: "busybox" tag: "1.29.3" testFramework: enabled: true image: "dduportal/bats" tag: "0.4.0" ## Specify password for root user ## ## Default: random 10 character string # mysqlRootPassword: testing ## Create a database user ## # mysqlUser: ## Default: random 10 character string # mysqlPassword: ## Allow unauthenticated access, uncomment to enable ## # mysqlAllowEmptyPassword: true ## Create a database ## # mysqlDatabase: ## Specify an imagePullPolicy (Required) ## It's recommended to change this to 'Always' if the image tag is 'latest' ## ref: http://kubernetes.io/docs/user-guide/images/#updating-images ## imagePullPolicy: IfNotPresent ......
上面我们看到的所有参数都是可以用自己的数据来覆盖的，可以在安装的时候通过 YAML 格式的文件来传递这些参数：
$ cat config.yaml mysqlUser: user0 mysqlPassword: user0pwd mysqlDatabase: user0db persistence: enabled: false $ helm install -f config.yaml stable/mysql helm install -f config.yaml mysql stable/mysql NAME: mysql LAST DEPLOYED: Fri Dec 6 17:46:56 2019 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: MySQL can be accessed via port 3306 on the following DNS name from within your cluster: mysql.default.svc.cluster.local ......
release 安装成功后，可以查看对应的 Pod 信息：
$ kubectl get pod -l release=mysql
NAME READY STATUS RESTARTS AGE
mysql-ddd798f48-gnrzd 0/1 PodInitializing 0 119s
$ kubectl describe pod mysql-ddd798f48-gnrzd
......
Environment:
MYSQL_ROOT_PASSWORD: <set to the key 'mysql-root-password' in secret 'mysql'> Optional: false
MYSQL_PASSWORD: <set to the key 'mysql-password' in secret 'mysql'> Optional: false
MYSQL_USER: user0
MYSQL_DATABASE: user0db
......
可以看到环境变量 MYSQL_USER=user0，MYSQL_DATABASE=user0db 的值和我们上面配置的值是一致的。在安装过程中，有两种方法可以传递配置数据：
-
--values（或者 -f）：指定一个 YAML 文件来覆盖 values 值，可以指定多个值，最后边的文件优先 -
--set：在命令行上指定覆盖的配置
如果同时使用这两个值，--set 将被合并到具有更高优先级的 --values，使用 --set 指定的值将持久化在 ConfigMap 中，对于给定的 release，可以使用 helm get values <release-name> 来查看已经设置的值，已设置的值也通过允许 helm upgrade 并指定 --reset 值来清除。
--set 选项接收零个或多个 name/value 对，最简单的用法就是 --set name=value，相当于 YAML 文件中的：
name: value
多个值之间用字符串“,”隔开，用法就是 --set a=b,c=d，相当于 YAML 文件中的：
a: b c: d
也支持更加复杂的表达式，例如 --set outer.inner=value，对应 YAML：
outer: inner: value
对于列表数组可以用 {} 来包裹，比如 --set name={a, b, c}，对应 YAML：
name: - a - b - c
从 Helm 2.5.0 开始，就可以使用数组索引语法来访问列表中某个项，比如 --set servers[0].port=80，对应的 YAML 为：
servers: - port: 80
也可以这样设置多个值，比如 --set servers[0].port=80,servers[0].host=example，对应的 YAML 为：
servers
- port: 80
host: example
有时候你可能需要在 --set 选项中使用特殊的字符，这个时候可以使用反斜杠来转义字符，比如 --set name=value1\,value2，对应的 YAML 为：
name: "value1,value2"
类似的，你还可以转义.，当 chart 模板中使用 toYaml 函数来解析 annotations、labels 以及 node selectors 之类的时候，这非常有用，比如 --set nodeSelector."kubernetes\.io/role"=master，对应的 YAML 文件：
nodeSelector: kubernetes.io/role: master
深度嵌套的数据结构可能很难使用 --set 来表示，所以一般推荐还是使用 YAML 文件来进行覆盖，当然在设计 chart 模板的时候也可以结合考虑到 --set 这种用法，尽可能的提供更好的支持。
更多安装方式
helm install 命令可以从多个源进行安装：
-
chart 仓库（类似于上面我们提到的）
-
本地 chart 压缩包（helm install foo-0.1.1.tgz）
-
本地解压缩的 chart 目录（helm install foo path/to/foo）
-
在线的 URL（helm install fool https://example.com/charts/foo-1.2.3.tgz）
升级和回滚
当新版本的 chart 包发布的时候，或者当你要更改 release 的配置的时候，你可以使用 helm upgrade 命令来操作。升级需要一个现有的 release，并根据提供的信息对其进行升级。因为 Kubernetes charts 可能很大而且很复杂，Helm 会尝试以最小的侵入性进行升级，它只会更新自上一版本以来发生的变化：
$ helm upgrade -f panda.yaml mysql stable/mysql helm upgrade -f panda.yaml mysql stable/mysql Release "mysql" has been upgraded. Happy Helming! NAME: mysql LAST DEPLOYED: Fri Dec 6 21:06:11 2019 NAMESPACE: default STATUS: deployed REVISION: 2 ...
我们这里 mysql 这个 release 用相同的 chart 包进行升级，但是新增了一个配置项：
mysqlRootPassword: passw0rd
我们可以使用 helm get values 来查看新设置是否生效：
$ helm get values mysql USER-SUPPLIED VALUES: mysqlDatabase: user0db mysqlPassword: user0pwd mysqlRootPassword: passw0rd mysqlUser: user0 persistence: enabled: false
helm get 命令是查看集群中 release 的非常有用的命令，正如我们在上面看到的，它显示了 panda.yaml 中的新配置值被部署到了集群中，现在如果某个版本在发布期间没有按计划进行，那么可以使用 helm rollback [RELEASE] [REVISION] 命令很容易回滚到之前的版本：
$ helm ls NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql default 2 2019-12-06 21:06:11.36358 +0800 CST deployed mysql-1.5.0 5.7.27 $ helm history mysql REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Fri Dec 6 17:53:03 2019 superseded mysql-1.5.0 5.7.27 Install complete 2 Fri Dec 6 21:06:11 2019 deployed mysql-1.5.0 5.7.27 Upgrade complete $ helm rollback mysql 1 Rollback was a success! Happy Helming! $ kubectl get pods -l release=mysql NAME READY STATUS RESTARTS AGE mysql-ddd798f48-gnrzd 1/1 Running 0 3h25m $ helm get values mysql USER-SUPPLIED VALUES: mysqlDatabase: user0db mysqlPassword: user0pwd mysqlUser: user0 persistence: enabled: false
可以看到 values 配置已经回滚到之前的版本了。上面的命令回滚到了 release 的第一个版本，每次进行安装、升级或回滚时，修订号都会加 1，第一个修订号始终为1，我们可以使用 helm history [RELEASE] 来查看某个版本的修订号。
除此之外我们还可以指定一些有用的选项来定制 install/upgrade/rollback 的一些行为，要查看完整的参数标志，我们可以运行 helm <command> --help 来查看，这里我们介绍几个有用的参数：
-
--timeout: 等待 Kubernetes 命令完成的时间，默认是 300（5分钟） -
--wait: 等待直到所有 Pods 都处于就绪状态、PVCs 已经绑定、Deployments 具有处于就绪状态的最小 Pods 数量（期望值减去 maxUnavailable）以及 Service 有一个 IP 地址，然后才标记 release 为成功状态。它将等待与--timeout值一样长的时间，如果达到超时，则 release 将标记为失败。注意：在 Deployment 将副本设置为 1 并且作为滚动更新策略的一部分，maxUnavailable 未设置为0的情况下，--wait将返回就绪状态，因为它已满足就绪状态下的最小 Pod 数量 -
--no-hooks: 将会跳过命令的运行 hooks -
--recreate-pods: 仅适用于 upgrade 和 rollback，这个标志将导致重新创建所有的 Pods。（Helm3 中启用了）
Charts
Helm 使用一种名为 charts 的包格式，一个 chart 是描述一组相关的 Kubernetes 资源的文件集合，单个 chart 可能用于部署简单的应用，比如 memcached pod，或者复杂的应用，比如一个带有 HTTP 服务、数据库、缓存等等功能的完整 web 应用程序。
Charts 是创建在特定目录下面的文件集合，然后可以将它们打包到一个版本化的存档中来部署。接下来我们就来看看使用 Helm 构建 charts 的一些基本方法。
文件结构
chart 被组织为一个目录中的文件集合，目录名称就是 chart 的名称（不包含版本信息），下面是一个 WordPress 的 chart，会被存储在 wordpress/ 目录下面，基本结构如下所示：
wordpress/ Chart.yaml # 包含当前 chart 信息的 YAML 文件 LICENSE # 可选：包含 chart 的 license 的文本文件 README.md # 可选：一个可读性高的 README 文件 values.yaml # 当前 chart 的默认配置 values values.schema.json # 可选: 一个作用在 values.yaml 文件上的 JSON 模式 charts/ # 包含该 chart 依赖的所有 chart 的目录 crds/ # Custom Resource Definitions templates/ # 模板目录，与 values 结合使用时，将渲染生成 Kubernetes 资源清单文件 templates/NOTES.txt # 可选: 包含简短使用使用的文本文件
另外 Helm 会保留 charts/、crds/ 以及 templates/ 目录以及上面列出的文件名的使用。
Chart.yaml 文件
对于一个 chart 包来说 Chart.yaml 文件是必须的，它包含下面的这些字段：
apiVersion: chart API 版本 (必须)
name: chart 名 (必须)
version: SemVer 2版本 (必须)
kubeVersion: 兼容的 Kubernetes 版本 (可选)
description: 一句话描述 (可选)
type: chart 类型 (可选)
keywords:
- 当前项目关键字集合 (可选)
home: 当前项目的 URL (可选)
sources:
- 当前项目源码 URL (可选)
dependencies: # chart 依赖列表 (可选)
- name: chart 名称 (nginx)
version: chart 版本 ("1.2.3")
repository: 仓库地址 ("https://example.com/charts")
maintainers: # (可选)
- name: 维护者名字 (对每个 maintainer 是必须的)
email: 维护者的 email (可选)
url: 维护者 URL (可选)
icon: chart 的 SVG 或者 PNG 图标 URL (可选).
appVersion: 包含的应用程序版本 (可选). 不需要 SemVer 版本
deprecated: chart 是否已被弃用 (可选, boolean)
其他字段默认会被忽略。
版本
每个 chart 都必须有一个版本号，版本必须遵循 SemVer2 标准，和 Helm Classic 不同，Kubernetes Helm 使用版本号作为 release 的标记，仓库中的软件包通过名称加上版本号来标识的。
例如，将一个 nginx 的 chart 包 version 字段设置为：1.2.3，则 chart 最终名称为：
nginx-1.2.3.tgz
还支持更复杂的 SemVer2 名称，例如版本：1.2.3-alpha.1+ef365，但是需要注意的是系统明确禁止使用非 SemVer 的名称。
Chart.yaml 中的 version 字段被很多 Helm 工具使用，包括 CLI 工具，生成包的时候，命令 helm package 将使用该字段作为包名称中的标记，系统是默认 Chart 包中的版本号与 chart.yaml 中的版本号匹配的，所以如果不匹配的话就导致一系列错误。
apiVersion 字段
对于 Helm 3 以上的版本 apiVersion 字段应该是 v2，之前版本的 Chart 应该设置为1，并且也可以有 Helm 3 进行安装。
appVersion 字段
要注意 appVersion 字段与 version 字段无关，这是一种指定应用程序版本的方法，比如 drupal 的 Chart 包可能有一个 appVersion: 8.2.1 的字段，表示 Chart 中包含的 drupal 版本是 8.2.1，该字段仅供参考，对 Chart 版本的计算不会产生影响。
弃用 Charts
当在 Chart 仓库中管理 charts 的时候，有时候需要弃用一个 chart，Chart.yaml 中的可选字段 deprecated 可以用来标记一个 chart 为弃用状态。如果将仓库中最新版本的 chart 标记为弃用，则整个 chart 都会被当做弃用状态了。以后可以通过发布一个未被标记为弃用状态的新版本来重新使用该 chart。弃用 charts 的工作流程如下所示：
-
更新 chart 的
Chart.yaml来标记 chart 为弃用状态 -
发布该新版本到 Chart 仓库
-
从源码仓库（比如 git）中删除 chart
Chart 类型
type 字段定义 chart 的类型，可以定义两种类型：应用程序（application）和库（library）。应用程序是默认的类型，它是一个可以完整操作的标准 chart，库或者辅助类 chart 为 chart 提供了一些实用的功能，library 不同于应用程序 chart，因为它没有资源对象，所以无法安装。
注意
一个应用 chart 也可以当作库进行使用。通过将类型设置为 library，然后该 chart 就会渲染成一个库，可以在其中使用所有的实用性功能，chart 的所有资源对象都不会被渲染。
LICENSE, README 和 NOTES
Chart 还可以包含用于描述 chart 的安装、配置、用法和许可证书的文件。
LICENSE 是一个纯文本文件，其中包含 chart 的许可证书。chart 可以包含一个许可证书，因为它可能在模板中具有编程逻辑，所以不只是配置，如果需要，chart 还可以为应用程序提供单独的 license(s)。
Chart 的 README 文件应该采用 Markdown（README.md）格式，并且通常应该包含如下的一些信息：
-
chart 提供的应用程序的描述信息
-
运行 chart 的任何先决条件或者要求
-
values.yaml和默认值中的一些选项说明 -
与 chart 的安装或配置有关的任何其他信息
chart 还可以包含简短的纯文本模板或者 NOTES.txt 文件，该文件将在安装后以及查看 release 状态的时候打印出来。该文件会被当成模板文件，并且可以用于显示使用说明，后续步骤或与 release 有关的任何其他信息。例如，可以提供用于连接到数据或访问 Web UI 的指令。由于在运行 helm install 或者 helm status 的时候该文件会打印到 STDOUT 中，所以建议该文件内容保持内容简短然后可以指向 README 文件来获取更多详细信息。
依赖
在 Helm 中，一个 chart 包可能会依赖许多其他的 chart。这些依赖关系可以使用 Chart.yaml 中的依赖关系字段动态链接，也可以引入到 charts/ 目录手动进行管理。
使用 dependencies 字段管理依赖¶
当前 chart 所需的依赖 chart 需要在 dependencies 字段中进行定义，如下所示：
dependencies:
- name: apache
version: 1.2.3
repository: https://example.com/charts
- name: mysql
version: 3.2.1
repository: https://another.example.com/charts
-
name字段是所依赖的 chart 的名称 -
version字段是依赖的 chart 版本 -
repository字段是 chart 仓库的完整 URL，不过需要注意，必须使用helm repo add在本地添加该 repo
定义了依赖项后，可以运行 helm dependency update 来更新依赖项，它将根据你的依赖项文件把你所有指定的 chart 包下载到 charts/ 目录中：
$ helm dependency update foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts
当执行 helm dependency update 命令的时候会解析 chart 的依赖项，会将他们作为 chart 包文件下载存放到 charts/ 目录中，所以，对于上面的示例，我们可以在 charts 目录中看到如下的文件：
charts/ apache-1.2.3.tgz mysql-3.2.1.tgz
alias 字段
除了上面的几个字段之外，每个依赖项还可以包含一个可选的 alias 别名字段。为依赖 chart 添加别名将使用别名作为依赖的名称。在需要访问其他名称的 chart 情况下，就可以使用别名，如下所示：
# parentchart/Chart.yaml
dependencies:
- name: subchart
repository: http://localhost:10191
version: 0.1.0
alias: new-subchart-1
- name: subchart
repository: http://localhost:10191
version: 0.1.0
alias: new-subchart-2
- name: subchart
repository: http://localhost:10191
version: 0.1.0
在上面示例中，我们将获得3个依赖项：
subchart new-subchart-1 new-subchart-2
当然其实我们也可以手动来实现，将同一个 chart 以不同的名称多次复制/粘贴到 charts/ 目录中也是可以的。
TEMPLATES 和 VALUES
Helm Chart 模板是用 Go template 语言 进行编写的，另外还额外增加了(【Sprig】](GitHub - Masterminds/sprig: Useful template functions for Go templates.)库中的50个左右的附加模板函数和一些其他专用函数。
所有模板文件都存储在 chart 的 templates/ 目录下面，当 Helm 渲染 charts 的时候，它将通过模板引擎传递该目录中的每个文件。模板的 Values 可以通过两种方式提供：
-
Chart 开发人员可以在 chart 内部提供一个名为
values.yaml的文件，该文件可以包含默认的 values 值内容。 -
Chart 用户可以提供包含 values 值的 YAML 文件，可以在命令行中通过
helm install来指定该文件。
当用户提供自定义 values 值的时候，这些值将覆盖 chart 中 values.yaml 文件中的相应的值。
模板文件¶
模板文件遵循编写 Go 模板的标准约定（可以查看 text/template 包文档查看详细信息），下面是一个模板文件示例：
apiVersion: v1
kind: ReplicationController
metadata:
name: deis-database
namespace: deis
labels:
app.kubernetes.io/managed-by: deis
spec:
replicas: 1
selector:
app.kubernetes.io/name: deis-database
template:
metadata:
labels:
app.kubernetes.io/name: deis-database
spec:
serviceAccount: deis-database
containers:
- name: deis-database
image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}
imagePullPolicy: {{ .Values.pullPolicy }}
ports:
- containerPort: 5432
env:
- name: DATABASE_STORAGE
value: {{ default "minio" .Values.storage }}
上面这个示例是 Kubernetes replication 控制器的一个模板，它可以使用以下4个模板值（通常在 values.yaml 文件中定义的）：
-
imageRegistry：Docker 镜像仓库 -
dockerTag：Docker 镜像 tag -
pullPolicy：镜像拉取策略 -
storage：存储后端，默认设置为"minio"
这些所有的 values 值都是有模板作者来定义的，Helm 不会也不需要规定这些参数。可以可以查看 Kubernetes Charts 项目去了解更多的 charts 项目的详细内容。
预定义 Values
在模板中用 .Values 可以获取到 values.yaml 文件（或者 --set 参数）提供的 values 值，此外，还可以在模板中访问其他预定义的数据。下面是一些预定义的、可用于每个模板、并且不能被覆盖的 values 值，与所有 values 值一样，名称都是区分大小写的：
-
Release.Name：release 的名称（不是 chart） -
Release.Namespace：release 被安装到的命名空间 -
Release.Service：渲染当前模板的服务，在 Helm 上，实际上该值始终为 Helm -
Release.IsUpgrade：如果当前操作是升级或回滚，则该值为 true -
Release.IsInstall：如果当前操作是安装，则该值为 true -
Chart：Chart.yaml文件的内容，可以通过Chart.Version来获得 Chart 的版本，通过Chart.Maintainers可以获取维护者信息 -
Files： 一个包含 chart 中所有非特殊文件的 map 对象，这不会给你访问模板的权限，但是会给你访问存在的其他文件的权限（除非使用.helmignore排除它们），可以使用{{ index .Files "file.name" }}或者{{ .Files.Get name }}或者{{ .Files.GetString name }}函数来访问文件，你还可以使用{{ .Files.GetBytes }}以[]byte的形式获取访问文件的内容 -
Capabilities：也是一个类 map 的对象，其中包含有关 Kubernetes 版本（{{ .Capabilities.KubeVersion }}）和支持的 Kubernetes API 版本（{{ .Capabilities.APIVersions.Has "batch/v1" }}）信息。
注意
任何未知的 Chart.yaml 字段都会被删除，在 Chart 对象内部无法访问他们，所以，Chart.yaml 不能用于将任意结构化的数据传递到模板中，但是可以使用 values 文件来传递。
Values 文件
为模板提供一些必须的 values 值的 values.yaml 文件如下所示：
imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3"
values 文件的格式是 YAML，一个 chart 包可能包含一个默认的 values.yaml 文件，helm install 命令允许用户通过提供其他的 YAML 值文件来覆盖默认的值：
$ helm install --values=myvals.yaml wordpress
用这种方式来传递 values 值的时候，它们将合并到默认值文件中，比如有一个 myvals.yaml 文件如下所示：
storage: "gcs"
将其与 chart 的 values.yaml 文件合并后，得到的结果为：
imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs"
我们可以看到只有最后一个字段被覆盖了。
注意
chart 内包含的默认 values 文件必须命名为 values.yaml，但是在命令行上指定的文件可以任意命名。 如果在 helm install 或者 helm upgrade 的时候使用 --set 参数，则这些值将在客户端转换为 YAML 格式。 如果 values 文件存在任何必须的条目，则可以使用 required 函数在 chart 模板中将它们声明为必须选项。
然后我们就可以使用 .Values 对象在模板中访问任意一个 values 值，类似于下面的模板文件：
apiVersion: v1
kind: ReplicationController
metadata:
name: deis-database
namespace: deis
labels:
app.kubernetes.io/managed-by: deis
spec:
replicas: 1
selector:
app.kubernetes.io/name: deis-database
template:
metadata:
labels:
app.kubernetes.io/name: deis-database
spec:
serviceAccount: deis-database
containers:
- name: deis-database
image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }}
imagePullPolicy: {{ .Values.pullPolicy }}
ports:
- containerPort: 5432
env:
- name: DATABASE_STORAGE
value: {{ default "minio" .Values.storage }}
作用范围、依赖和 Values
values 文件可以声明顶级的 chart 以及该 chart 的 charts/ 目录中包含的任何 chart 的值。或者，换句话说，values 文件可以为 chart 以及他的任何依赖项提供 values 值。例如，上面提到了 WordPress 这个 chart 同时依赖 mysql 和 apache 这两个依赖项，values 文件可以为所有这些组件提供 values 值：
title: "My WordPress Site" # 传递到 WordPress 模板 mysql: max_connections: 100 # 传递到 MySQL password: "secret" apache: port: 8080 # 传递到 Apache
较高级别的 Charts 可以访问下面定义的所有变量，所以，WordPress 这个 chart 可以通过 .Values.mysql.password 来访问 MySQL 的密码，但是较低级别的 chart 是无法访问父 chart 中的内容的，所有 MySQL 无法获取到 title 属性，当然同样也不能访问 apache.port。
Values 是有命名空间的，但是会对其进行调整，比如对于 WordPress 这个 chart 来说，它可以通过 .Values.mysql.password 来进行访问，但是对于 MySQL 这个 chart 本身来说，values 的范围缩小了，命名空间前缀会被删除，所以它只需要通过 .Values.password 就可以访问到。
全局 Values¶
从 2.0.0-Alpha.2 版本开始，Helm 开始支持特殊的 global 全局值，比如将上面的示例修改如下：
title: "My WordPress Site" # 传递到 WordPress 模板 global: app: MyWordPress mysql: max_connections: 100 # 传递到 MySQL password: "secret" apache: port: 8080 # 传递到 Apache
上面我们添加了一个全局范围的 value 值：app: MyWordPress，该值可以通过 .Values.global.app 提供给所有 chart 使用。
例如，mysql 模板可以以 {{ .Values.global.app }} 来访问 app，apache chart 也可以，实际上，上面的 values 文件会这样重新生成：
title: "My WordPress Site" # 传递到 WordPress 模板
global:
app: MyWordPress
mysql:
global:
app: MyWordPress
max_connections: 100 # 传递到 MySQL
password: "secret"
apache:
global:
app: MyWordPress
port: 8080 # 传递到 Apache
这种方式提供了一种与所有子 chart 共享一个顶级变量的方式，这对于设置 meta 数据这种属性是非常有用的。如果子 chart 声明了全局变量，则该全局变量将向下（传递到子 chart 的子 chart 中）传递，而不会向上传递到父 chart，子 chart 无法影响 父 chart的值。同样，父 chart 的全局遍历优先与子 chart 中的全局变量。
Schema 文件¶
有时候，chart 开发者可能希望在其 values 值上面定义一个结构，这种情况下可以通过在 values.schema.json 文件中定义一个 schema 来完成，这里的 schema 就是一个 JSON Schema 文件结构规范，如下所示：
{
"$schema": "https://json-schema.org/draft-07/schema#",
"properties": {
"image": {
"description": "Container Image",
"properties": {
"repo": {
"type": "string"
},
"tag": {
"type": "string"
}
},
"type": "object"
},
"name": {
"description": "Service name",
"type": "string"
},
"port": {
"description": "Port",
"minimum": 0,
"type": "integer"
},
"protocol": {
"type": "string"
}
},
"required": [
"protocol",
"port"
],
"title": "Values",
"type": "object"
}
该 schema 会对 values 值进行校验，调用以下任何命令时，都会进行验证：
-
helm install
-
helm upgrade
-
helm lint
-
helm template
比如下面的示例文件就可以满足上面的 schema 要求：
name: frontend protocol: https port: 443
需要注意的是该 schema 将应用于最终的 .Values 对象，而不仅仅是应用于 values.yaml 文件，所以下面的文件也是可以满足 schema 要求的：
name: frontend protocol: https
因为在安装的时候我们通过 --set 选项传递了必须的 port 属性：
$ helm install --set port=443
此外，还会根据所有的子 chart schemas 来检查最终的 .Values 对象，这意味着父 chart 无法规避对子 chart 的限制。同样的，如果子 chart 要求未满足子 chart 的 values.yaml 文件，则父 chart 必须满足这些限制才能生效。
参考文档
在编写模板、values、和 schema 文件的时候，下面这些文档可以提供一些帮助：
CRDS
Kubernetes 提供了一种声明新类型的 Kubernetes 对象的机制，使用 CustomResourceDefinitions（CRDS）可以让 Kubernetes 开发人员声明自定义资源类型。
在 Helm 3 中，CRD 被视为一种特殊的对象，它们在 chart 部分之前被安装，并且会受到一些限制。CRD YAML 文件应该放置 chart 内的 crds/ 目录下面。多个 CRDs 可以放在同一个文件中，Helm 将尝试将 CRD 目录中的所有文件加载到 Kubernetes 中。
需要注意的是 CRD 文件不能模板化，它们必须是纯的 YAML 文件。
当 Helm 安装一个新的 chart 的时候，它将会安装 CRDs，然后会暂停直到 API Server 提供 CRD 为止，然后才开始启动模板引擎，渲染其余的 chart 模板，并将其安装到 Kubernetes 中。由于这个安装顺序，CRD 信息在 Helm 模板的 .Capabilities 对象中是可以获取到的，并且 Helm 模板可能会创建在 CRD 中声明的对象的新实例。
比如，如果你的呃 chart 在 crds 目录下面有一个 CronTab 的 CRD，则可以在 templates/ 目录下面创建 CronTab 类型的实例：
crontabs/
Chart.yaml
crds/
crontab.yaml
templates/
mycrontab.yaml
crontab.yaml 文件必须包含不带模板指定的 CRD：
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
然后模板 mycrontab.yaml 可以创建一个新的 CronTab（和平时使用模板一样）：
apiVersion: stable.example.com
kind: CronTab
metadata:
name: {{ .Values.name }}
spec:
# ...
在继续安装 templates/ 之前，Helm 会确保已经安装上了 CronTab 类型，并且可以从 Kubernetes API server 上获得该类型。
CRDs 的限制
于 Kubernetes 中的大多数对象不同，CRDs 是全局安装的，所以 Helm 在管理 CRD 的时候比较谨慎，会有一些限制：
-
CRDs 不会重新安装，如果 Helm 确定
crds/目录中的 CRD 已经存在（无论版本如何），Helm 都不会重新安装或升级。 -
CRDs 不会在升级或回滚的时候安装，只会在安装操作的时候创建 CRDs。
-
CRDs 不会被删除，删除 CRD 会自动删除集群中所有 namespace 中的 CRDs 内容，所以 Helm 不会删除 CRD。
Helm 希望想要升级或删除 CRDs 的操作人员可以手动来仔细地操作。
使用 Helm 管理 Charts
helm 工具有几个用于操作 charts 的命令，如下所示。
创建一个新的 chart 包：
$ helm create mychart Created mychart/
一旦你已经编辑了一个 chart 包，Helm 可以将其打包到一个独立文件中：
$ helm package mychart Archived mychart-0.1.-.tgz
你还可以使用 helm 帮助你查找 chart 包的格式要求方面或其他问题：
$ helm lint mychart No issues found
Chart 仓库
chart 仓库实际上就是一个 HTTP 服务器，其中包含一个或多个打包的 chart 包，虽然可以使用 helm 来管理本地 chart 目录，但是在共享 charts 的时候，最好的还是使用 chart 仓库。
可以提供 YAML 文件和 tar文件并可以相应 GET 请求的任何 HTTP 服务器都可以作为 chart 仓库服务器。仓库的主要特征是存在一个名为 index.yaml 的特殊文件，该文件具有仓库中提供的所有软件包的列表以及允许检索和验证这些软件包的元数据。
在客户端，可以使用 helm repo 命令来管理仓库，但是 Helm 不提供用于将 chart 上传到远程 chart 仓库的工具。
模板开发（如下）
内置对象
前面我们介绍了 Helm Chart 的一些基本概念和使用，接下来我们重点介绍下 Chart 模板的编写。模板会渲染成 Kubernetes 的资源清单文件，下面我们将来学习下模板的结构，如何使用它们，如何编写 Go 模板以及如何调试。
对象从模板引擎传递到模板中，在代码中可以传递对象，也有一种方法可以在模板宏创建新的对象，比如 tuple 函数。对象可以很简单，也可以包含其他对象或函数，例如，Release 对象就包含几个对象（比如 Release.Name），Files 对象就包含几个函数。
前面提到过我们可以在模板中使用 {{ .Release.Name }} 获取 release 的名称，Release 是我们可以在模板中访问的几个顶级对象之一：
-
Release：该对象描述了 release 本身的相关信息，它内部有几个对象：-
Release.Name：release 名称 -
Release.Namespace：release 安装到的命名空间 -
Release.IsUpgrade：如果当前操作是升级或回滚，则该值为 true -
Release.IsInstall：如果当前操作是安装，则将其设置为 true -
Release.Revision：release 的 revision 版本号，在安装的时候，值为1，每次升级或回滚都会增加 -
Reelase.Service：渲染当前模板的服务，在 Helm 上，实际上该值始终为 Helm
-
-
Values：从values.yaml文件和用户提供的 values 文件传递到模板的 Values 值，默认情况下，Values 是空的。 -
Chart：获取Chart.yaml文件的内容，该文件中的任何数据都可以访问，例如{{ .Chart.Name }}-{{ .Chart.Version}}可以渲染成mychart-0.1.0，该对象下面可用的字段前面我们已经提到过了。 -
Files：可以访问 chart 中的所有非特殊文件，虽然无法使用它来访问模板文件，但是可以来访问 chart 中的其他文件。-
Files.Get：用于根据名称获取文件（比如.Files.Get config.ini） -
Files.GetBytes：用于以 bytes 数组而不是字符串的形式来获取文件内容的函数，这对于类似于图片之类的东西很有用 -
Files.Glob：用于返回名称于给定的 shell glob 模式匹配的文件列表 -
Files.Lines：可以逐行读取文件的函数，对于遍历文件中的每行内容很有用 -
Files.AsSecrets：将文件内容以 Base64 编码的字符串返回的函数 -
Files.AsConfig：将文件正文作为 YAML 字典返回的函数
-
-
Capabilities：提供了获取有关 Kubernetes 集群支持功能的信息的对象-
Capabilities.APIVersions：支持的版本集合 -
Capabilities.APIVersions.Has $version：判断一个版本（比如batch/v1）或资源（比如apps/v1/Deployment）是否可用 -
Capabilities.Kube.Version：Kubernetes 的版本 -
Capabilities.Kube：是 Kubernetes 版本的缩写 -
Capabilities.Kube.Major：Kubernetes 主版本 -
Capabilities.Kube.Minor：Kubernetes 的次版本
-
-
Template：包含当前正在执行的模板的相关信息-
Name：当前模板的命名空间文件路径（比如mychart/templates/mytemplate.yaml） -
BaePath：当前 chart 的模板目录的命名空间路径（比如mychart/templates）
-
需要注意的是内置的对象始终是以大写字母开头的，这也是符合 Go 的命名约定的，创建自己的名称的时候，可以自由使用适合你团队的约定，一些团队，比如 Kubernetes Charts 团队，选择仅使用首字母小写，以区分本地名称和内置名称，这里我们也会遵循该约定。
Values 文件
前面我们介绍了 Helm 模板提供的内置对象，其中就有一个内置对象 Values，该对象提供对传递到 chart 忠的 values 值的访问，其内容主要有4个来源：
-
chart 文件中的
values.yaml文件 -
如果这是子 chart，父 chart 的
values.yaml文件 -
用
-f参数传递给helm install或helm upgrade的 values 值文件（例如helm install -f myvals.yaml ./mychart） -
用
--set传递的各个参数（例如helm install --set foo=bar ./mychart）
values.yaml 文件是默认值，可以被父 chart 的 values.yaml 文件覆盖，而后者又可以由用户提供的 values 值文件覆盖，而该文件又可以被 --set 参数覆盖。
values 值文件是纯 YAML 文件，我们可以来编辑 mychart/values.yaml 文件然后编辑 ConfigMap 模板。删除 values.yaml 中的默认设置后，我们将只设置一个参数：
favoriteDrink: coffee
现在我们可以在模板中直接使用它：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favoriteDrink }}
可以看到在最后一行我们将 favoriteDrink 作为 Values 的属性进行访问：{{ .Values.favoriteDrink }}。我们可以来看看是如何渲染的：
$ helm install --generate-name --dry-run --debug ./mychart
install.go:148: [debug] Original chart version: ""
install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/course/k8strain/content/helm/manifests/mychart
NAME: mychart-1575963545
LAST DEPLOYED: Tue Dec 10 15:39:06 2019
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
USER-SUPPLIED VALUES:
{}
COMPUTED VALUES:
favoriteDrink: coffee
HOOKS:
MANIFEST:
---
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1575963545-configmap
data:
myvalue: "Hello World"
drink: coffee
由于在默认的 values.yaml 文件中将 favoriteDrink 设置为了 coffee，所以这就是模板中显示的值，我们可以通过在调用 helm install 的过程中添加 --set 参数来覆盖它：
$ helm install --generate-name --dry-run --debug --set favoriteDrink=slurm ./mychart install.go:148: [debug] Original chart version: "" install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/course/k8strain/content/helm/manifests/mychart NAME: mychart-1575963760 LAST DEPLOYED: Tue Dec 10 15:42:43 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575963760-configmap data: myvalue: "Hello World" drink: slurm
因为 --set 的优先级高于默认的 values.yaml 文件，所以我们的模板会生成 drink: slurm。Values 值文件也可以包含更多结构化的内容，例如我们可以在 values.yaml 文件中创建一个 favorite 的部分，然后在其中添加几个 keys：
favorite: drink: coffee food: pizza
现在我们再去修改下我们的模板：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink }}
food: {{ .Values.favorite.food }}
虽然我们可以通过这种方式来构造数据，但是还是建议你将 values 树保持更浅，这样在使用的时候更加简单。当我们考虑为子 chart 分配 values 值的时候，我们就可以看到如何使用树形结构来命名 values 值了。
删除默认 KEY
如果你需要从默认值中删除 key，则可以将该 key 的值覆盖为 null，在这种情况下，Helm 将从覆盖的 values 中删除该 key。例如，在 Drupal chart 中配置一个 liveness 探针:
livenessProbe:
httpGet:
path: /user/login
port: http
initialDelaySeconds: 120
如果你想使用 --set livenessProbe.exec.command=[cat, docroot/CHANGELOG.txt] 将 livenessProbe 的处理程序覆盖为 exec 而不是 httpGet，则 Helm 会将默认键和覆盖键合并在一起，如下所示：
livenessProbe:
httpGet:
path: /user/login
port: http
exec:
command:
- cat
- docroot/CHANGELOG.txt
initialDelaySeconds: 120
但是，这样却有一个问题，因为你不能声明多个 livenessProbe 处理程序，为了解决这个问题，你可以让 Helm 通过将 livenessProbe.httpGet 设置为 null 来删除它：
$ helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat, docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null
到这里我们已经了解到了几个内置对象，并利用它们将信息注入到了模板中，现在我们来看看模板引擎的另外方面：函数和管道。
函数和管道
现在我们已经了解了如何将信息加入到模板中，但是这些信息都是直接原样的放置过去的，有时候，我们希望以一种对我们更有用的方式来转换提供的数据。
下面让我们从一个最佳实践开始：将 .Values 对象中的字符串注入模板时，我们应该引用这些字符串，我们可以通过在 template 指令中调用 quote 函数来实现，比如：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ quote .Values.favorite.drink }}
food: {{ quote .Values.favorite.food }}
模板函数遵循的语法规则是 functionName arg1 arg2...，在上面的代码片段中，quote .Values.favorite.drink 会调用 quote 函数并传递一个单个参数。
Helm 有60多种可用的函数，其中一些是由 Go 模板语言本身定义的，其他大多数都是 Sprig 模板库提供的，接下来我们会通过部分示例来逐步介绍其中的一些功能函数。
Helm 模板
当我们谈论 Helm 模板语言 的时候，就好像是特定于 Helm 一样，但实际上它是 Go 模板语言加上一些额外的函数以及各种封装程序的组合，以将某些对象暴露给模板。当我们需要学习模板的时候，Go 模板上有许多资源会对我们有所帮助的。
管道
模板语言有一个强大的功能就是管道（Pipeline）概念，管道利用 UNIX 的概念，将一系列模板命令链接在一起，一起对外提供服务，换句话说，管道是按顺序完成多项工作的有效方式，我们来使用管道重写上面的示例模板：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | quote }}
food: {{ .Values.favorite.food | quote }}
在这里我们没有调用 quote ARGUMENT 函数，而是颠倒了下顺序，我们使用管道符（|）将参数发送给函数：.Values.favorite.drink | quote，使用管道，我们可以将多个功能链接在一起：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | quote }}
food: {{ .Values.favorite.food | upper | quote }}
管道顺序
反转顺序是模板中常见的做法，我们会看到 .val | quote 比 quote .val 用法更多，虽然两种方法都是可以的。
最后，模板渲染后，会产生如下所示的结果：
$ helm install --generate-name --dry-run --debug ./mychart
install.go:148: [debug] Original chart version: ""
install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/course/k8strain/content/helm/manifests/mychart
NAME: mychart-1575966483
LAST DEPLOYED: Tue Dec 10 16:28:04 2019
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
USER-SUPPLIED VALUES:
{}
COMPUTED VALUES:
favorite:
drink: coffee
food: pizza
favoriteDrink: coffee
HOOKS:
MANIFEST:
---
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1575966483-configmap
data:
myvalue: "Hello World"
drink: "coffee"
food: "PIZZA"
我们可以看到 values 中的 pizza 值已经被转换成了 "PIZZA"。当这样传递参数的时候，第一个求值结果（.Values.favorite.drink）会作为一个参数发送给函数，我们可以修改上面的 drink 示例，用一个带有两个参数的函数进行说明：repeat COUNT STRING。
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | repeat 5 | quote }}
food: {{ .Values.favorite.food | upper | quote }}
repeat 函数将重复字符串给定的次数，渲染后我们可以得到如下的输出结果：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575966939-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA"
default 函数
在模板中经常会使用到的一个函数是 default 函数：default DEFAULT_VALUE GIVEN_VALUE，该函数允许你在模板内部指定默认值，我们来修改上面示例中的模板：
food: {{ .Values.favorite.food | default "rice" | upper | quote }}
正常运行，我们还是可以得到 values.yaml 文件中定义的 pizza：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575966939-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA"
现在我们从 values.yaml 文件中移除 food 的定义：
favorite: drink: coffee # food: pizza
现在我们重新运行 helm install --generate-name --dry-run --debug ./mychart 将渲染成如下的 YAML 文件：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575967394-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "RICE"
在一个真实的 chart 模板中，所有的静态默认值都应位于 values.yaml 文件中，并且不应该重复使用 default 函数，但是，默认命令非常适合计算不能在 values.yaml 文件中声明的 values 值，例如：
food: {{ .Values.favorite.food | default (printf "%s-rice" (include "fullname" .)) }}
不过在有些地方，if 条件语句可能比 default 函数更合适，我们会在后面了解到。
模板函数和管道是将数据转换后然后将其插入到 YAML 文件中的一种强大方法，但是有的时候有必要添加一些模板逻辑，这些逻辑比仅仅插入字符串要复杂得多，下面我们将来了解模板语言中提供的控制流程。
运算符函数
另外需要注意的是在模板中，运算符（eq、ne、lt、gt、and、or 等等）均实现为函数，在管道中，运算符可以用括号（）进行分割。
接下来我们可以去了解控制流程条件语句、循环和作用域修饰符的使用。
流程控制
控制流程为模板作者提供了控制模板生成流程的功能，Helm 的模板语言提供了以下一些流程控制：
-
if/else条件语句 -
with指定一个作用域范围 -
range提供类似于for each这样的循环样式
除此之外，还提供了一些声明和使用命名模板的操作：
-
define在模板内部声明一个新的命名模板 -
template导入一个命名模板 -
block声明了一种特殊的可填充模板区域。
这里我们先来了解 if、with、range 语句的使用，其他将在后面的命名模板部分介绍。
if/else
首先我们先来了解下有条件地在模板中包含一个文本区域，就是 if/else ，这个条件判断的基本结构如下所示：
{{ if PIPELINE }}
# Do something
{{ else if OTHER PIPELINE }}
# Do something else
{{ else }}
# Default case
{{ end }}
可以看到我们这里判断的是管道而不是一个 values 值，这是因为控制结构可以执行整个管道，而不仅仅是判断值。如果值为以下的一些内容，则将管道判断为 false：
-
布尔 false
-
数字零
-
一个空字符串
-
nil（empty 或者 null）
-
一个空集合（map、slice、tuple、dict、array）
在其他条件下，条件都为真。
现在我们在上面的示例模板 ConfigMap 中添加一个简单的条件，如果 drink 设置为 coffee，我们就添加另外一个设置：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | default "tea" | quote }}
food: {{ .Values.favorite.food | upper | quote }}
{{ if eq .Values.favorite.drink "coffee" }}mug: true{{ end }}
我们把 values.yaml 文件内容设置成下面的样子：
favorite: # drink: coffee food: pizza
由于我们注释掉了 drink: coffee，所以渲染后输出不会包含 mug: true 的标志，但是如果我们把注释取消掉，则应该输出如下所示的内容：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575970308-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: true
这是因为上面模板中我们添加了 if eq .Values.favorite.drink "coffee" 这样的条件判断，相当于是判断 .Values.favorite.drink 值是否等于 "coffee"，如果相等则渲染 mug: true。
空格控制
还有一个非常重要的功能点就是关于空格的控制，因为空格对于 YAML 文件非常重要的，不是说任意缩进就可以，依然还是以前面的例子为例，我们来格式化下模板格式以更易于阅读：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | default "tea" | quote }}
food: {{ .Values.favorite.food | upper | quote }}
{{ if eq .Values.favorite.drink "coffee" }}
mug: true
{{ end }}
现在我们的模板看上去更易于阅读了，但是我们通过模板引擎来渲染下，却会得到如下的错误信息：
$ helm install --generate-name --dry-run --debug ./mychart install.go:148: [debug] Original chart version: "" install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/course/k8strain/content/helm/manifests/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key
这是因为我们在模板中添加了空格，生成了不正确的 YAML 文件：
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1575970308-configmap
data:
myvalue: "Hello World"
drink: "coffee"
food: "PIZZA"
mug: true
我们可以看到 mug: true 的缩进是有问题的，不符合 YAML 文件格式，现在我们讲缩进去掉试看看：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | default "tea" | quote }}
food: {{ .Values.favorite.food | upper | quote }}
{{ if eq .Values.favorite.drink "coffee" }}
mug: true
{{ end }}
重新渲染模板，然后可以发现已经可以正常通过了，但是渲染出来的 YAML 文件格式看上去还是有点奇怪：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575971172-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: true
我们可以看到得到的 YAML 文件中多了一些空行，这是因为模板引擎渲染的时候它会删除 {{ 和 }} 之间的内容，但是会完全保留其余的空格。我们知道在 YAML 文件中空格是有意义的，所以管理空格就变得非常重要了，不过 Helm 模板也提供了一些工具来帮助我们管理空格。
首先可以使用特殊字符修改模板声明的花括号语法，以告诉模板引擎去掉空格。{{- 添加了破折号和空格表示应将左边的空格移除，-}}表示将右边的空格移除，另外也需要注意的是，换行符也是空格。
空格
需要注意的时候要确保 - 和指令的其余部分之间要有空格，{{- 3 }} 表示删除左边的空格并打印3，但是 {{-3 }}表示打印-3。
使用这个语法，我们可以修改上面的模板来移除多余的空行：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | default "tea" | quote }}
food: {{ .Values.favorite.food | upper | quote }}
{{- if eq .Values.favorite.drink "coffee" }}
mug: true
{{- end }}
渲染后可以看到空行被移除掉了：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575972373-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: true
为了更加清楚地说明这个问题，我们用*来代替将要删除的每个空格，行尾的*表示被删除的换行符：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | default "tea" | quote }}
food: {{ .Values.favorite.food | upper | quote }}*
**{{- if eq .Values.favorite.drink "coffee" }}
mug: true*
**{{- end }}
所以我们这里用 {{- 表示的就是删除本行开头的两个空格以及上一行的换行符，这样是不是就将空行都删除了啊。
在使用移除空格的时候还需要小心，比如下面的操作：
food: {{ .Values.favorite.food | upper | quote }}
{{- if eq .Values.favorite.drink "coffee" -}}
mug: true
{{- end -}}
我们依然还是可以用 * 来代替空格进行分析，如下所示：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
drink: {{ .Values.favorite.drink | default "tea" | quote }}
food: {{ .Values.favorite.food | upper | quote }}*
**{{- if eq .Values.favorite.drink "coffee" -}}*
mug: true*
**{{- end -}}
第一个 {{- 会删除前面的空格和前面的换行符，然后后面的 -}} 会删除当前行的换行符，这样就会把 mug: true 移动到 food: "PIZZA" 后面去了，最终渲染过后就会变成：food: "PIZZA"mug: true，因为在两侧都去掉换行符。
有关模板中空格控制的详细信息，可以查看 Go 模板官方文档介绍。
不过有时候告诉模板系统如何缩进比起去控制模板指令的间距更加容易，所以，有时候你会发现缩进函数（{{ indent 2 "mug: true" }}）更有用。
使用 with 修改作用域
接下来需要了解的是 with 操作，它可以控制变量的作用域，然后重新用 . 调用就表示对当前作用域的引用，所以，.Values 是告诉模板引擎在当前作用域下内查找 Values 对象。
with 语句的语法和 if 语句比较类似：
{{ with PIPELINE }}
# 限制范围
{{ end }}
范围可以更改，可以让你将当前范围 . 设置为特定的对象，例如，我们一直在使用 .Values.favorites，让我们重写下模板文件 ConfigMap 来更改 . 的范围指向 .Values.favorites：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
{{- with .Values.favorite }}
drink: {{ .drink | default "tea" | quote }}
food: {{ .food | upper | quote }}
{{- end }}
我们这里将前面练习的 if 条件语句删除了，在模板中我们添加了一个 {{- with .Values.favorite }} 的语句，意思就是说在 with 语句的作用范围内可以用 . 表示 .Values.favorite 了，所以我们可以引用 .drink 和 .food 了，但是在 {{ end }} 之后就会重置为之前的作用域了。
不过需要注意得是，在受限的作用域范围内，你无法从父级范围访问到其他对象，比如，下面得模板会失败：
{{- with .Values.favorite }}
drink: {{ .drink | default "tea" | quote }}
food: {{ .food | upper | quote }}
release: {{ .Release.Name }}
{{- end }}
因为 Release.Name 并不在 . 的限制范围内，所以会产生错误，但是，如果我们交换最后两行，则就可以正常工作了，因为 {{ end }} 之后会重置作用域。
{{- with .Values.favorite }}
drink: {{ .drink | default "tea" | quote }}
food: {{ .food | upper | quote }}
{{- end }}
release: {{ .Release.Name }}
下面我先来了解下 range，然后我们再去了解下模板变量，它可以为上面得这个范围问题提供一种解决方案。
range 循环操作
我们知道许多编程语言都支持使用 for 循环、foreach 循环或者类似功能机制进行循环迭代，在 Helm 得模板语言中，迭代集合得方法是使用 range 运算符。
比如首先我们在 values.yaml 文件中添加一份 pizza 馅料列表：
favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions
现在我们有了 pizzaToppings 列表（在模板中称为切片），我们可以来修改下模板将列表打印到 ConfigMap 中：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
{{- with .Values.favorite }}
drink: {{ .drink | default "tea" | quote }}
food: {{ .food | upper | quote }}
{{- end }}
toppings: |-
{{- range .Values.pizzaToppings }}
- {{ . | title | quote }}
{{- end }}
我们仔细观察下模板中的 toppings: 列表，range 函数将遍历 Values.pizzaToppings 列表，我们看到里面使用了一个 .，类似于上面我们用 with 设置范围一样，运算符也是这样的，每次循环，. 都会被设置为当前的 pizzaTopping，也就是说第一次设置为mushrooms，第二次迭代设置为cheese，依次类推。
我们可以直接传递 . 这个值到管道上，所以我们这里 {{ . | title | quote }} 就相当于发送 . 给 title（标题大小写函数）函数，然后发送给 quote 函数，我们渲染这个模板，会输出如下的内容：
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1575975849-configmap
data:
myvalue: "Hello World"
drink: "coffee"
food: "PIZZA"
toppings: |-
- "Mushrooms"
- "Cheese"
- "Peppers"
- "Onions"
在上面模板中，我们做了一些小小的特殊处理，toppings: |- 行表示声明一个多行字符串，所以其实我们的 toppings 列表不是一个 YAML 列表，而是一个比较大的字符串，这是因为 ConfigMap 中的数据由 key/value 对组成，所有 key 和 value 都是简单的字符串，要了解为什么是这样的，可以查看 Kubernetes ConfigMap 文档，不过这个细节对我们这里不重要。
YAML
多行字符串可以使用 | 保留换行符，也可以使用 > 折叠换行，如：
this: | Foo Bar that: > Foo Bar
对应的意思就是：{this: 'Foo\nBar\n', that: 'Foo Bar\n'}
+ 表示保留文字块末尾的换行，- 表示删除字符串末尾的换行，如：
s1: | Foo s2: |+ Foo s3: |- Foo
对应的意思就是：{s1: 'Foo\n', s2: 'Foo\n\n\n', s3: 'Foo'}
有时候，在模板中快速创建一个列表，然后遍历该列表很有用，Helm 模板具有简化该功能的函数：tuple。元组是固定大小的列表集合，但是具有任意数据类型，下面是元组的大概使用方法：
sizes: |-
{{- range tuple "small" "medium" "large" }}
- {{ . }}
{{- end }}
上面的模板最终会被渲染成如下的 YAML：
sizes: |- - small - medium - large
除了列表和元组之外，range 还可以用于遍历字典，我们在下一节介绍模板变量的时候再来了解这个用法吧。
变量
有了函数、管道、对象以及控制结构，我们可以想象下大多数编程语言中更基本的思想之一：变量。在模板中，变量的使用频率较低，但是，我们还是可以使用他们来简化代码，以及更好地使用 with 和 range。
在前面的示例中，我们知道下面的模板渲染会出错：
{{- with .Values.favorite }}
drink: {{ .drink | default "tea" | quote }}
food: {{ .food | upper | quote }}
release: {{ .Release.Name }}
{{- end }}
因为 Release.Name 不在 with 语句块限制的范围之内，解决作用域问题的一种方法是将对象分配给在不考虑当前作用域情况下访问的变量。
在 Helm 模板中，变量是对另外一个对象的命名引用。它遵循 $name 格式，变量使用特殊的赋值运算符进行赋值 :=，我们可以修改上面的模板，为 Release.Name 声明一个变量：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
{{- $relname := .Release.Name -}}
{{- with .Values.favorite }}
drink: {{ .drink | default "tea" | quote }}
food: {{ .food | upper | quote }}
release: {{ $relname }}
{{- end }}
注意在 with 语句之前，我们先分配了 $relname := .Release.Name，然后在 with 语句块中，$relname 变量仍然表示 release 的名称，我们渲染该模板，可以得到如下的正确结果：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575982655-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: mychart-1575982655
变量在 range 循环里面非常有用，它们可以用于类似于列表的对象来捕获索引和 value 值：
toppings: |-
{{- range $index, $topping := .Values.pizzaToppings }}
{{ $index }}: {{ $topping }}
{{- end }}
注意 range 在前面，然后是变量，然后是赋值运算符，然后才是列表，这会将整数索引（从0开始）分配给 $index，并将 value 值分配给 $topping，上面的内容会被渲染成如下内容：
toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions
对于同时具有 key 和 value 的数据结构，我们也可以使用 range 来获得 key、value 的值，比如，我们可以像这样循环遍历 .Values.favorite：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"
{{- range $key, $val := .Values.favorite }}
{{ $key }}: {{ $val | quote }}
{{- end }}
在第一次迭代中，$key 是 drink，$val 是 coffee，在第二次迭代中，$key 是 food，$val 是 pizza。运行上面的命令将生成下面的内容：
# Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1575983119-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza"
一般来说变量不是全局的，它们的作用域是声明它们的块区域，之前，我们在模板的顶层分配了 $relname，该变量将在整个模板的范围内，但是在我们上面的示例中，$key 和 $val 作用域只在 {{ range... }}{{ end }} 区域内。
但是，有一个始终是全局变量的 $ 始终指向顶层根上下文，当我们在 range 循环内需要知道 chart 包的 release 名称的时候，该功能就非常有用了，比如下面的模板文件：
{{- range .Values.tlsSecrets }}
apiVersion: v1
kind: Secret
metadata:
name: {{ .name }}
labels:
# helm 模板经常使用 `.`，但是这里是无效的，用 `$` 是可以生效的。
app.kubernetes.io/name: {{ template "fullname" $ }}
# 这里不能引用 `.Chart.Name`，但是可用使用 `$.Chart.Name`
helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}"
app.kubernetes.io/instance: "{{ $.Release.Name }}"
# 值来自于 Chart.yaml 文件中的 appVersion
app.kubernetes.io/version: "{{ $.Chart.AppVersion }}"
app.kubernetes.io/managed-by: "{{ $.Release.Service }}"
type: kubernetes.io/tls
data:
tls.crt: {{ .certificate }}
tls.key: {{ .key }}
---
{{- end }}
到现在为止，我们只研究了在一个文件中声明的一个模板，但是，Helm 模板语言的强大功能之一是它能够声明多个模板并将其一起使用。我们将在下面的章节中来讨论这一点。
命名模板
前面我们都是只操作的一个模板，现在我们来尝试使用多个模板文件。在本节中，我们可以了解到如何在一个文件中定义命名模板，然后在其他地方使用它们。命名模板（有时也叫子模板）只是在文件内部定义的有名称的模板。主要有两种创建方式以及几种不同的使用方式。
当使用命名模板的时候有几个重要细节：模板名称是全局的，如果声明两个具有相同名称的模板，则会使用最后被加载的模板。由于子 chart 中的模板是与顶级模板一起编译的，所以需要谨慎命名。
一种流行的命名约定是在每个定义的模板前添加 chart 名称：{{ define "mychart.labels" }}，通过使用特定的 chart 名作为前缀，我们可以避免由于两个不同的 chart 实现了相同名称的模板而引起的冲突。
partials 和 _ 文件
到目前为止，我们只使用了一个模板文件，但是 Helm 的模板语言允许我们创建命名的嵌入式模板，可以在其他位置进行访问。在编写这些模板之前，有一些值得一提的命名约定：
-
templates/中的大多数文件都被视为 Kubernetes 资源清单文件（NOTES.txt 除外） -
以
_开头命名的文件也不会被当做 Kubernetes 资源清单文件 -
下划线开头的文件不会被当做资源清单之外，还可以被其他 chart 模板调用
_ 开头的这些文件其实就是 Helm 中的 partials 文件，所以其实我们完全可以将命名模板定义在这些 partials 文件中，默认就是 _helpers.tpl 文件，其实在前面我们创建的 mychart 包中也可以找到这个文件。
define 和 template
define 关键字可以让我们在模板文件中创建命名模板，它的语法如下所示：
{{ define "MY.NAME" }}
# 模板内容区域
{{ end }}
比如我们可以定义一个模板来封装下 Kubernetes 的 labels 标签：
{{- define "mychart.labels" }}
labels:
generator: helm
date: {{ now | htmlDate }}
{{- end }}
现在我们可以将该模板嵌入到前面的 ConfigMap 模板中，然后将其包含在模板中：
{{- define "mychart.labels" }}
labels:
generator: helm
date: {{ now | htmlDate }}
{{- end }}
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
{{- template "mychart.labels" }}
data:
myvalue: "Hello World"
{{- range $key, $val := .Values.favorite }}
{{ $key }}: {{ $val | quote }}
{{- end }}
当模板引擎读取这个文件的时候，它会存储 mychart.labels 的引用，直到该模板被调用，然后会内联渲染该模板。我们渲染这个模板可以都到如下所示的结果（记得先删掉默认生成的 _helpers.tpl 文件）：
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1576034036-configmap
labels:
generator: helm
date: 2019-12-11
data:
myvalue: "Hello World"
drink: "coffee"
food: "pizza"
一般来说，Helm 中约定将这些模板统一放到一个 partials 文件中，通常就是 _helpers.tpl 文件中，我们将上面的命名模板移动到该文件（templates/_helpers.tpl）中去：
{{/* 生成基本的 Label 标签 */}}
{{- define "mychart.labels" }}
labels:
generator: helm
date: {{ now | htmlDate }}
{{- end }}
一般来说，我们也会用一个简单的块（{{/*...*/}}）来注释这个命名模板的作用。
现在虽然我们把命名模板放到了 _helpers.tpl 文件中，但是我们在 configmap.yaml 模板中还是可以访问，因为命名模板是全局的：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
{{- template "mychart.labels" }}
data:
myvalue: "Hello World"
{{- range $key, $val := .Values.favorite }}
{{ $key }}: {{ $val | quote }}
{{- end }}
因为上面我们提到过命名模板是全局的，我们可以再渲染下上面的模板可以得到正确的结果。
设置模板范围
上面我们定义的模板中，还没有使用到任何对象，只使用了函数，现在我们来修改下定义的命名模板，包含 chart 的名称和版本：
{{/* 生成基本的 Label 标签 */}}
{{- define "mychart.labels" }}
labels:
generator: helm
date: {{ now | htmlDate }}
chart: {{ .Chart.Name }}
version: {{ .Chart.Version }}
{{- end }}
现在我们来渲染下模板，会出现下面的错误：
$ helm install --generate-name --dry-run --debug ./my chart install.go:148: [debug] Original chart version: "" install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/cour se/k8strain/content/helm/manifests/mychart Error: unable to build kubernetes objects from release manifest: error validati ng "": error validating data: [unknown object type "nil" in ConfigMap.metadata. labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] helm.go:76: [debug] error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in Co nfigMap.metadata.labels.version] ......
我们可以看到提示 labels.chart 为 nil，这是因为我们使用的 .Chart.Name 不在定义的这个模板的作用域范围内，当渲染命名模板（使用 define 定义）的时候，它将接收模板调用传递的作用域。在我们这个示例中，我们是这样引用这个模板的：
{{- template "mychart.labels" }}
没有传入任何作用域，所以在模板内我们无法访问 . 中的任何内容，当然要解决很简单，我们只需要把作用域范围传递给模板即可：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
{{- template "mychart.labels" . }}
......
我们这里在使用 template 调用模板的时候传递了 .，我们可以很容易传递 .Values 或者 .Values.favorite 或者我们想要的任何范围，但是这里我们想要的是顶级作用域，所以我们传递的是 .。
现在我们再来重新渲染我们的模板，可以得到如下所示的结果：
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1576035668-configmap
labels:
generator: helm
date: 2019-12-11
chart: mychart
version: 0.1.0
data:
myvalue: "Hello World"
drink: "coffee"
food: "pizza"
现在 {{ .Chart.Name }} 解析为了 mychart，而 {{ .Chart.Version }} 解析为了 0.1.0。
include 函数
假设我们定义了一个如下所示的简单模板：
{{- define "mychart.app" -}}
app_name: {{ .Chart.Name }}
app_version: "{{ .Chart.Version }}"
{{- end -}}
现在我们想把上面的内容插入到模板的 labels 部分，在 data 部分也想要这个内容：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
labels:
{{ template "mychart.app" . }}
data:
myvalue: "Hello World"
{{- range $key, $val := .Values.favorite }}
{{ $key }}: {{ $val | quote }}
{{- end }}
{{ template "mychart.app" . }}
但是我们直接渲染上面的模板还是会有错误：
$ helm install --generate-name --dry-run --debug ./my chart install.go:148: [debug] Original chart version: "" install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/cour se/k8strain/content/helm/manifests/mychart Error: unable to build kubernetes objects from release manifest: error validati ng "": error validating data: [ValidationError(ConfigMap): unknown field "app_n ame" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] helm.go:76: [debug] error validating "": error validating data: [ValidationErro r(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, Validat ionError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ......
因为 template 只是一个动作，而不是一个函数，所以无法将模板调用的输出传递给其他函数，只是内联插入，相当于渲染的结果是这样的：
apiVersion: v1
kind: ConfigMap
metadata:
name: measly-whippet-configmap
labels:
app_name: mychart
app_version: "0.1.0+1478129847"
data:
myvalue: "Hello World"
drink: "coffee"
food: "pizza"
app_name: mychart
app_version: "0.1.0+1478129847"
很明显上面的 YAML 文件是不符合 ConfigMap 资源对象的格式要求的，所以报错了。为解决这个问题，Helm 提供了代替 template 的函数 include，可以将模板的内容导入到当前的管道中，这样就可以在管道中传递给其他函数进行处理了，如下所示：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
labels:
{{ include "mychart.app" . | indent 4 }}
data:
myvalue: "Hello World"
{{- range $key, $val := .Values.favorite }}
{{ $key }}: {{ $val | quote }}
{{- end }}
{{ include "mychart.app" . | indent 2 }}
现在我们重新渲染就可以得到正确的结果了，这是因为我们用 include 函数得到模板内容后通过管道传给了后面的 indent 函数来保证了缩进：
Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1576036671-configmap
labels:
app_name: mychart
app_version: "0.1.0"
data:
myvalue: "Hello World"
drink: "coffee"
food: "pizza"
app_name: mychart
app_version: "0.1.0"
建议
在 Helm 模板中最好使用 include 而不是 template，这样可以更好地处理 YAML 文档的输出格式。
有时候如果我们只想导入内容而不是模板，这个时候我们可以通过下面描述的 .Files 对象来访问文件实现。
访问文件
在上一节中我们介绍了几种创建和访问命名模板的方法，这使得从另一个模板中导入一个模板变得很容易，但是有时候需要导入一个不是模板的文件并注入其内容，而不通过模板渲染器获得内容。
Helm 提供了一个 .Files 对象对文件的访问，但是在模板中使用这个对象之前，还有几个需要注意的事项值得一提：
-
可以在 Helm chart 中添加额外的文件，这些文件也会被打包，不过需要注意，由于 Kubernetes 对象的存储限制，Charts 必须小于 1M
-
由于一些安全原因，通过
.Files对象无法访问某些文件-
无法访问
templates/下面的文件 -
无法访问使用
.helmignore排除的文件
-
-
Chart 不会保留 UNIX 模式的信息，所以，当使用
.Files对象时，文件级别的权限不会对文件的可用性产生影响。
基本示例
现在我们来编写一个模板，将3个文件读入到 ConfigMap 模板中，首先我们在 chart 中添加3个文件，将3个文件都直接放置在 mychart/ 目录中。
config1.toml:
message = Hello from config 1
config2.toml:
message = This is config 2
config3.toml:
message = Goodbye from config 3
3个文件都是简单的 TOML 文件，我们知道这些文件的名称，所以我们可以使用 range 函数来遍历它们，并将其内容注入到 ConfigMap 中去。
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- $files := .Files }}
{{- range tuple "config1.toml" "config2.toml" "config3.toml" }}
{{ . }}: |-
{{ $files.Get . }}
{{- end }}
这里我们声明了一个 $files 的变量来保存 .Files 对象的引用，还使用了 tuple 函数来循环文件列表，然后我们打印每个文件夹 {{ . }}: |-，后面使用 {{ $files.Get . }} 获取文件内容。
现在我们渲染这个模板会产生包含3个文件内容的单个 ConfigMap：
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-1576046462-configmap
data:
config1.toml: |-
message = Hello from config 1
config2.toml: |-
message = This is config 2
config3.toml: |-
message = Goodbye from config 3
另外在处理文件的时候，对文件路径本身执行一些标准操作可能非常有用，为了解决这个问题，Helm 从 Go 的路径包中导入了许多功能供你使用，它们都可以使用与 Go 包中相同的相同名称来访问，但是首字母需要小写，比如 Base 需要变成 base，导入的函数有：- Base - Dir - Ext - IsAbs - Clean。
Glob 模式
随着 chart 的增长，你可能需要更多地组织文件，因此 Helm 提供了 Files.Glob 的方法来帮助我们获取具有 glob 模式的文件。
.Glob 返回 Files 类型，所以你可以在返回的对象上调用任何 Files 方法。比如，我们的文件目录结构如下所示：
foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml
我们可以用 Glob 进行多种选择：
{{ range $path := .Files.Glob "**.yaml" }}
{{ $path }}: |
{{ .Files.Get $path }}
{{ end }}
或者
{{ range $path, $bytes := .Files.Glob "foo/*" }}
{{ $path }}: '{{ b64enc $bytes }}'
{{ end }}
ConfigMap 和 Secrets
想要将文件内容同时放入 ConfigMap 和 Secrets 中，以便在运行时安装到 Pod 中，这种需求很常见，为了解决这个问题，Helm 在 Files 类型上添加了一个实用的方法。
根据上面的目录结构，我们可以按照如下的方式进行处理：
apiVersion: v1
kind: ConfigMap
metadata:
name: conf
data:
{{ (.Files.Glob "foo/*").AsConfig | indent 2 }}
---
apiVersion: v1
kind: Secret
metadata:
name: very-secret
type: Opaque
data:
{{ (.Files.Glob "bar/*").AsSecrets | indent 2 }}
编码
我们也可以导入一个文件并用 base64 编码进行编码：
apiVersion: v1
kind: Secret
metadata:
name: {{ .Release.Name }}-secret
type: Opaque
data:
token: |-
{{ .Files.Get "config1.toml" | b64enc }}
上面将采用我们上面的 config1.toml 文件并对其内容进行 base64 编码，渲染会得到如下所示的结果：
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: Secret
metadata:
name: mychart-1576048287-secret
type: Opaque
data:
token: |-
bWVzc2FnZSA9IEhlbGxvIGZyb20gY29uZmlnIDEK
Lines
有时，需要访问模板中文件的每一行内容，Helm 也提供了方法的 Lines 方法，我们可以使用 range 函数遍历没行内容：
data:
some-file.txt: {{ range .Files.Lines "foo/bar.txt" }}
{{ . }}{{ end }}
在 Helm 安装的时候无法将文件传递到 chart 外部，所以，如果你要求用户提供数据的话，则必须使用 helm install -f 或者 helm install --set 来获取。
NOTES.txt 文件
在本节中我们将来了解为 chart 用户提供说明的一个 NOTES.txt 文件，在 chart 安装或者升级结束时，Helm 可以为用户打印出一些有用的信息，使用模板也可以自定义这些信息。
要将安装说明添加到 chart 中，只需要创建一个 templates/NOTES.txt 文件，该文件纯文本的，但是可以像模板一样进行处理，并具有所有常规模板的功能和可用对象。
现在让我们来创建一个简单的 NOTES.txt 文件：
Thank you for installing {{ .Chart.Name }}.
Your release is named {{ .Release.Name }}.
To learn more about the release, try:
$ helm status {{ .Release.Name }}
$ helm get {{ .Release.Name }}
现在我们运行 helm install ./mychart，我们就可以在底部看到这样的消息：
RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get rude-cardinal
用这种方式可以向用户提供一个有关如何使用其新安装的 chart 的详细信息，强烈建议创建 NOTES.txt 文件，虽然这不是必须的。
子chart与全局值
Subcharts 和 Global Values
到现在为止，我们从单一模板，到多个模板文件，但是都仅仅是处理的一个 chart 包，但是 charts 可能具有一些依赖项，我们称为 subcharts（子 chart），接下来我们将创建一个子 chart。
同样在深入了解之前，我们需要了解下子 chart 相关的一些信息。
-
子 chart 是独立的，这意味着子 chart 不能显示依赖其父 chart
-
所以子 chart 无法访问其父级的值
-
父 chart 可以覆盖子 chart 的值
-
Helm 中有可以被所有 charts 访问的全局值的概念
创建子chart
同样还是在之前操作的 mychart/ 这个 chart 包中，我们来尝试添加一些新的子 chart：
$ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/*.*
和前面一样，我们删除了所有的基本模板，这样我们可以从头开始。
添加 values 和 模板
接下来我们为 mysubchart 这个子 chart 创建一个简单的模板和 values 值文件，mychart/charts/mysubchart 中已经有一个 values.yaml 文件了，在文件中添加下面的 values：
dessert: cake
下面我们再创建一个新的 ConfigMap 模板 mychart/charts/mysubchart/templates/configmap.yaml：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-cfgmap2
data:
dessert: {{ .Values.dessert }}
因为每个子 chart 都是独立的 chart，所以我们可以单独测试 mysubchart：
helm install --generate-name --dry-run --debug mychart/charts/mysubchart
install.go:148: [debug] Original chart version: ""
install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/course/k8strain/content/helm/manifests/mychart/charts/mysubchart
NAME: mysubchart-1576050755
LAST DEPLOYED: Wed Dec 11 15:52:36 2019
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
USER-SUPPLIED VALUES:
{}
COMPUTED VALUES:
dessert: cake
HOOKS:
MANIFEST:
---
# Source: mysubchart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mysubchart-1576050755-cfgmap2
data:
dessert: cake
从父 chart 覆盖 values
我们原来的 chart - mychart 现在是 mysubchart 的父级 chart 了。由于 mychart 是父级，所以我们可以在 mychart 中指定配置，并将该配置发送到 mysubchart 中去，比如，我们可以这样修改 mychart/values.yaml：
favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream
最后两行，mysubchart 部分中的所有指令都回被发送到 mysubchart 子 chart 中，所以，如果我们现在渲染模板，我们可以看到 mysubchart 的 ConfigMap 会被渲染成如下的内容：
# Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1576051914-cfgmap2 data: dessert: ice cream
我们可以看到顶层的 values 值覆盖了子 chart 中的值。这里有一个细节需要注意，我们没有将 mychart/charts/mysubchart/templates/configmap.yaml 模板更改为指向 .Values.mysubchart.dessert，因为从该模板的绝度来看，该值仍然位于 .Values.dessert，当模板引擎传递 values 值的时候，它会设置这个作用域，所以，对于 mysubchart 模板，.Values 中仅仅提供用于该子 chart 的值。
但是有时候如果我们确实希望某些值可以用于所有模板，这个时候就可以使用全局 chart values 值来完成了。
全局值
全局值是可以从任何 chart 或子 chart 中都可以访问的值，全局值需要显示的声明，不能将现有的非全局对象当作全局对象使用。
Values 数据类型具有一个名为 Values.global 的保留部分，可以在其中设置全局值，我们在 mychart/values.yaml 文件中添加一个全局值：
favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar
由于全局值的原因，在 mychart/templates/configmap.yaml 和 mysubchart/templates/configmap.yaml 下面都应该可以以 {{ .Values.global.salad }} 的形式来访问这个值。
mychart/templates/configmap.yaml：
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
salad: {{ .Values.global.salad }}
mysubchart/templates/configmap.yaml:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-cfgmap2
data:
dessert: {{ .Values.dessert }}
salad: {{ .Values.global.salad }}
然后我们渲染这个模板，可以得到如下所示的内容：
--- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1576053485-cfgmap2 data: dessert: ice cream salad: caesar --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-1576053485-configmap data: salad: caesar
全局值对于传递这样的数据比较有用。
共享模板
父级 chart 和子 chart 可以共享模板，任何 chart 中已定义的块都可以用于其他 chart。比如，我们可以定义一个简单的模板，如下所示：
{{- define "labels" }}from: mychart{{ end }}
前面我们提到过可以使用在模板中使用 include 和 template，但是使用 include 的一个优点是可以动态引入模板的内容：
{{ include $mytemplate }}
模板调试
调试模板可能比较麻烦，因为渲染的模板会发送到 Kubernetes API server，而 API server 可能会因为格式以外的一些原因而拒绝 YAML 文件。
下面这些命令可以帮助你调试一些问题：
-
helm lint是验证 chart 是否遵循最佳实践的首选工具 -
helm install --dry-run --debug或者helm template --debug：前面我们已经使用了这个技巧，这个是让服务器渲染模板，然后返回生成的资源清单文件的好方法，而且不会真正的去安装这些资源 -
helm get manifest：这是查看服务器上安装了哪些模板的好方法
当你的 YAML 文件无法解析的时候，但你想要查看生成的内容的时候，检索 YAML 的一种简单方法是注释掉模板中的问题部分，然后重新运行 helm install --dry-run --debug：
apiVersion: v2
# some: problem section
# {{ .Values.foo | quote }}
上面的内容将呈现并返回完整的注释：
apiVersion: v2 # some: problem section # "bar"
这提供了一种查看生成的内容的快速方法。
Chart Hooks¶
Helm 也提供了一种 Hook 机制，可以允许 chart 开发人员在 release 生命周期的某些时间点进行干预。比如，可以使用 hook 来进行下面的操作：
-
在加载任何 charts 之前，在安装的时候加载 ConfigMap 或者 Secret
-
在安装新的 chart 之前，执行一个 Job 来备份数据库，然后在升级后执行第二个 Job 还原数据
-
在删除 release 之前运行一个 JOb，以在删除 release 之前适当地取消相关服务
Hooks 的工作方式类似于普通的模板，但是他们具有特殊的注解，这些注解使 Helm 可以用不同的方式来使用他们。
Hooks
在 Helm 中定义了如下一些可供我们使用的 Hooks：
-
预安装
pre-install：在模板渲染后，kubernetes 创建任何资源之前执行 -
安装后
post-install：在所有 kubernetes 资源安装到集群后执行 -
预删除
pre-delete：在从 kubernetes 删除任何资源之前执行删除请求 -
删除后
post-delete：删除所有 release 的资源后执行 -
升级前
pre-upgrade：在模板渲染后，但在任何资源升级之前执行 -
升级后
post-upgrade：在所有资源升级后执行 -
预回滚
pre-rollback：在模板渲染后，在任何资源回滚之前执行 -
回滚后
post-rollback：在修改所有资源后执行回滚请求 -
测试
test：在调用 Helmtest子命令的时候执行（可以查看测试文档）
生命周期
Hooks 允许开发人员在 release 的生命周期中的一些关键节点执行一些钩子函数，我们正常安装一个 chart 包的时候的生命周期如下所示：
-
-
用户运行
helm install foo
-
-
-
Helm 库文件调用安装 API
-
-
-
经过一些验证，Helm 库渲染
foo模板
-
-
-
Helm 库将产生的资源加载到 kubernetes 中去
-
-
-
Helm 库将 release 对象和其他数据返回给客户端
-
-
-
Helm 客户端退出
-
如果开发人员在 install 的生命周期中定义了两个 hook：pre-install和post-install，那么我们安装一个 chart 包的生命周期就会多一些步骤了：
-
-
用户运行
helm install foo
-
-
-
Helm 库文件调用安装 API
-
-
-
在
crds/目录下面的 CRDs 被安装
-
-
-
经过一些验证，Helm 库渲染
foo模板
-
-
-
Helm 库将 hook 资源加载到 kubernetes 中，准备执行
pre-installhooks
-
-
-
Helm 库会根据权重对 hooks 进行排序（默认分配权重0，权重相同的 hook 按升序排序）
-
-
-
Helm 库然后加载最低权重的 hook
-
-
-
Helm 库会等待，直到 hook 准备就绪
-
-
-
Helm 库将产生的资源加载到 kubernetes 中，注意如果添加了
--wait参数，Helm 库会等待所有资源都准备好，在这之前不会运行post-installhook
-
-
-
Helm 库执行
post-installhook（加载 hook 资源）
-
-
-
Helm 库等待，直到 hook 准备就绪
-
-
-
Helm 库将 release 对象和其他数据返回给客户端
-
-
-
Helm 客户端退出
-
等待 hook 准备就绪，这是一个阻塞的操作，如果 hook 中声明的是一个 Job 资源，Helm 将等待 Job 成功完成，如果失败，则发布失败，在这个期间，Helm 客户端是处于暂停状态的。
对于所有其他类型，只要 kubernetes 将资源标记为加载（添加或更新），资源就被视为就绪状态，当一个 hook 声明了很多资源是，这些资源是被串行执行的。
另外需要注意的是 hook 创建的资源不会作为 release 的一部分进行跟踪和管理，一旦 Helm 验证了 hook 已经达到了就绪状态，它就不会去管它了。
所以，如果我们在 hook 中创建了资源，那么不能依赖 helm uninstall 去删除资源，因为 hook 创建的资源已经不受控制了，要销毁这些资源，你需要将 helm.sh/hook-delete-policy 这个 annotation 添加到 hook 模板文件中，或者设置 Job 资源的生存（TTL）字段。
编写 Hook
Hooks 就是 Kubernetes 资源清单文件，在元数据部分带有一些特殊的注解，因为他们是模板文件，所以你可以使用普通模板所有的功能，包括读取 .Values、.Release 和 .Template。
例如，在 templates/post-install-job.yaml 文件中声明一个 post-install 的 hook：
apiVersion: batch/v1
kind: Job
metadata:
name: "{{ .Release.Name }}"
labels:
app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
app.kubernetes.io/instance: {{ .Release.Name | quote }}
app.kubernetes.io/version: {{ .Chart.AppVersion }}
helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
annotations:
# 因为添加了这个 hook，所以我们这个资源被定义为了 hook
# 如果没有这行，则当前这个 Job 会被当成 release 的一部分内容。
"helm.sh/hook": post-install
"helm.sh/hook-weight": "-5"
"helm.sh/hook-delete-policy": hook-succeeded
spec:
template:
metadata:
name: "{{ .Release.Name }}"
labels:
app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
app.kubernetes.io/instance: {{ .Release.Name | quote }}
helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
spec:
restartPolicy: Never
containers:
- name: post-install-job
image: "alpine:3.3"
command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"]
当前这个模板成为 hook 的原因就是添加这个注解：
annotations: "helm.sh/hook": post-install
一种资源也可以实现多个 hooks：
annotations: "helm.sh/hook": post-install,post-upgrade
类似的，实现给定 hook 的资源数量也没有限制，比如可以将 secret 和一个 configmap 都声明为 pre-install hook。
当子 chart 声明 hooks 的时候，也会对其进行调用，顶层的 chart 无法禁用子 chart 所声明的 hooks。可以为 hooks 定义权重，这将有助于确定 hooks 的执行顺序：
annotations: "helm.sh/hook-weight": "5"
hook 权重可以是正数也可以是负数，但是必须用字符串表示，当 Helm 开始执行特定种类的 hooks 的时候，它将以升序的方式对这些 hooks 进行排序。
Hook 删除策略
我们还可以定义确定何时删除相应 hook 资源的策略，hook 删除策略可以使用下面的注解进行定义：
annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
我们也可以选择一个或多个已定义的注解：
-
before-hook-creation：运行一个新的 hook 之前删除前面的资源（默认） -
hook-succeeded：hook 成功执行后删除资源 -
hook-failed：hook 如果执行失败则删除资源
如果未指定任何 hook 删除策略注解，则默认情况下会使用 before-hook-creation 策略。
示例
前面介绍了 Helm 的基本使用，以及 Helm Chart 包开发相关的一些知识点，下面我们用一个实例来演示下如何开发一个真正的 Helm Chart 包。
应用
我们这里为前面的完整示例 Wordpress 开发一个 Chart 包，在开发 Chart 包之前很明显我们最需要的就是要知道我们自己的应用应该如何使用，如何部署，不然是不可能编写出对应的 Chart 包的。
我们可以用 helm create 命令来创建一个 Chart 包，这里我们就完全手动来创建，首先创建一个名为 wordpress 的文件夹:
$ mkdir wordpress && cd wordpress
然后在目录下面创建如下所示的 Chart.yaml 文件：
apiVersion: v2 name: wordpress description: A Helm chart for Kubernetes home: https://wordpress.org/ type: application # chart 版本号 version: 0.1.0 # wordpress 的应用版本 appVersion: 5.3.2
由于 Wordpress 应用本身是一来 MySQL 数据库的，所以同样需要添加一个依赖说明 requirements.yaml：
dependencies:
- name: mysql
version: 1.6.2
repository: http://mirror.azure.cn/kubernetes/charts/
condition: mysql.enabled
tags:
- wordpress-database
这里依赖的应用我们可以通过 helm search 命令来获取，当然也可以随意指定一个 Chart 版本：
$ helm search repo stable/mysql NAME CHART VERSION APP VERSION DESCRIPTION stable/mysql 1.6.2 5.7.28 Fast, reliable, scalable, and easy to use open-...
需要注意的是在依赖的文件中我们添加了一个 condition: mysql.enabled 条件，这意味着当 Values 值 mysql.enabled 为 true 的时候才会真正去依赖这个子 Chart，因为我们完全可以直接使用一个外部的数据库。所以首先我们要先添加一个 mysql.enabled 的 Values 值，添加如下所示的 values.yaml 文件：
## ## MySQL Chart 配置，参考如下 values.yaml ## https://github.com/helm/charts/blob/master/stable/mysql/values.yaml ## mysql: ## 是否部署mysql服务来满足wordpress的需求。如果要使用外部数据库，将 enabled 设置为 false 并配置 externalDatabase 参数。 enabled: true ## todo，其他 mysql 配置 ## 当 mysql.enabled=false 的时候使用外部数据库 externalDatabase: ## 数据库地址 host: localhost:3306 ## Wordpress 数据库的非root用户 user: wordpress ## 数据库密码 password: wordpress ## 数据库名称 database: wordpress
上面的 Values 配置很好理解，就是如果 mysql.enabled=true 则我们就用 mysql 这个子 Chart 去安装一个 MySQL 数据库，如果为 false 则使用下面 externalDatabase 的外部数据库信息来作为 wordpress 的数据库配置，虽然现在这些配置还完全没有任何作用，但是这些却是一开始就很容易考虑到的事情。
接下来创建一个 templates 和 charts 目录，并在 charts 目录下面获取 mysql 这个子 chart:
$ mkdir templates && mkdir charts $ cd charts && helm fetch stable/mysql && cd ..
现在的整个 Chart 包目录结构如下所示：
$ tree . . ├── Chart.yaml ├── charts │ └── mysql-1.6.2.tgz ├── requirements.yaml ├── templates └── values.yaml 2 directories, 4 files
接下来就是我们的重头戏模板的开发了。我们可以将前面课程示例中的 Wordpress 资源清单直接拷贝到 templates 目录下面，将 Deployment 和 Service 分别放在不同的 YAML 文件中，同样还有数据持久化的资源清单，但是这里我们就需要先将 MySQL 的部分移除掉，因为我们会通过外部数据库或者子 Chart 来渲染，不需要在这里显示的声明了，另外还需要将所有资源对象的命名空间去掉，因为我们可以通过 helm install 命令直接指定即可，现在我们的模板目录结构就如下所示了：
$ tree templates templates ├── deployment.yaml ├── pvc.yaml └── service.yaml 0 directories, 4 files
名称
这个时候我们可以尝试去安装调试下这个 Chart 模板：
$ helm install --generate-name --dry-run --debug .
install.go:148: [debug] Original chart version: ""
install.go:165: [debug] CHART PATH: /Users/ych/devs/workspace/yidianzhishi/course/k8strain/content/helm/manifests/wordpress
load.go:112: Warning: Dependencies are handled in Chart.yaml since apiVersion "v2". We recommend migrating dependencies to Chart.yaml.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: Middleware, namespace: default, name: redirect-https
helm.go:76: [debug] existing resource conflict: kind: Middleware, namespace: default, name: redirect-https
rendered manifests contain a resource that already exists. Unable to continue with install
helm.sh/helm/v3/pkg/action.(*Install).Run
/home/circleci/helm.sh/helm/pkg/action/install.go:242
main.runInstall
/home/circleci/helm.sh/helm/cmd/helm/install.go:209
main.newInstallCmd.func1
/home/circleci/helm.sh/helm/cmd/helm/install.go:115
github.com/spf13/cobra.(*Command).execute
/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:826
github.com/spf13/cobra.(*Command).ExecuteC
/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914
github.com/spf13/cobra.(*Command).Execute
/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864
main.main
/home/circleci/helm.sh/helm/cmd/helm/helm.go:75
runtime.main
/usr/local/go/src/runtime/proc.go:203
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1357
我们看到出现了错误，其中还有这样的一条警告信息 load.go:112: Warning: Dependencies are handled in Chart.yaml since apiVersion "v2". We recommend migrating dependencies to Chart.yaml.，大概意思就是在 Helm3 中依赖项的配置被移动到了 Chart.yaml 文件中，也就是在 Helm2 版本的时候依赖才会在 requirements.yaml 中声明，这里我们可以将 requirements.yaml 文件中的内容全部拷贝到 Chart.yaml 文件中去，然后删除 requirements.yaml 文件，这个时候重新 DEBUG 下就没有这个提示信息了。
下面的错误提示基本上都是类似于 rendered manifests contain a resource that already exists. 这样的信息，意思就是这些资源对象在现有集群中已经包含了，这很正常，因为我们的资源对象名称都是写死的，是非常有可能和现有的集群冲突的，所以接下来我们要给这些资源清单改名，如何才能避免冲突又具有很好的扩展性呢？这里我们创建一个如下所示的命名模板：
{{/*
创建一个默认的应用名称，截取63个字符是因为 Kubernetes 的 name 属性的限制（DNS 命名规范）。
*/}}
{{- define "wordpress.fullname" -}}
{{- if .Values.fullnameOverride -}}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- $name := default .Chart.Name .Values.nameOverride -}}
{{- if contains $name .Release.Name -}}
{{- .Release.Name | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
{{- end -}}
{{- end -}}
{{- end -}}
根据规范命名模板的名称最好以 Chart 名作为前缀，这里我们命名成 wordpress.fullname，首先就是判断是否定义了 fullnameOverride 这个 Values 值，如果定义了则截取 63 个字符并移除 - 这样的前后缀作为名称，如果没有定义呢？就要检查 Chart 名是否包含 Release 名称，如果包含则截取 Release 名的 63 个字符并移除 - 这样的前后缀作为名称，如果不包含，则将 Release 名称和 Chart 名称用 - 连接起来作为名称，这个命名的方式也是符合大部分 Chart 模板中的命名，以后的模板开发中都可以直接使用。在 templates 目录下面新建一个 _helpers.tpl 这样的 partials 文件，然后将上面定义的命名模板放置到里面去。后面我们所有的命名模板都将在该文件中完成。
接下来将 templates 目录下面的所有资源对象 name 属性全都换成上面我们定义的命名模板，由于这里并没有什么空格控制之类的，我们直接使用 template 函数即可，同样作为惯例，也习惯将 Release 和 Chart 名称之类作为 Label 标签，所以最终，这些资源清单的 Meta 信息如下所示，如果有其他额外的信息当然可以随意添加：
metadata:
name: {{ template "wordpress.fullname" . }}
labels:
app: "{{ template "wordpress.fullname" . }}"
chart: "{{ template "wordpress.chart" . }}"
release: {{ .Release.Name | quote }}
heritage: {{ .Release.Service | quote }}
然后当然也需要将 Deployment 的 matchLabels 和 template 下面的 Label 标签进行修改，以及 Service 的 selector 匹配的标签。
同样还有 PVC 对象，以前我们直接使用的一个确定名称的 PVC 对象：
volumes:
- name: wordpress-data
persistentVolumeClaim:
claimName: wordpress-pvc
但是现在我们这里作为模板就要考虑到各种情况了，很有可能使用我们模板的用户根本就不需要持久化，也有可能直接传递一个存在的 PVC 对象进来使用，所以这里做了如下改变：
volumes:
- name: wordpress-data
{{- if .Values.persistence.enabled }}
persistentVolumeClaim:
claimName: {{ .Values.persistence.existingClaim | default (include "wordpress.fullname" .) }}
{{- else }}
emptyDir: {}
{{ end }}
当我们定义了 Values 值 persistence.enabled=true 为 true 时候就表示要使用持久化了，所以要指定下面的 claimName 属性，但是还需要判断 persistence.existingClaim 这个 Values 值是否存在，如果存在则表示直接使用，如果不存在则使用我们模板里面渲染的 PVC 对象，如果不需要持久化，则直接使用 emptyDir:{} 即可。最后我们的 PVC 对象模板变成了如下所示：
{{- if and .Values.persistence.enabled (not .Values.persistence.existingClaim) }}
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: {{ template "wordpress.fullname" . }}
labels:
app: "{{ template "wordpress.fullname" . }}"
chart: "{{ template "wordpress.chart" . }}"
release: {{ .Release.Name | quote }}
heritage: {{ .Release.Service | quote }}
spec:
{{- if .Values.persistence.storageClass }}
storageClassName: {{ .Values.persistence.storageClass | quote }}
{{- end }}
accessModes:
- {{ .Values.persistence.accessMode | quote }}
resources:
requests:
storage: {{ .Values.persistence.size | quote }}
{{- end -}}
其中访问模式、存储容量、StorageClass、存在的 PVC 都通过 Values 来指定，增加了灵活性。对应的 values.yaml 配置部分我们可以给一个默认的配置：
## 是否使用 PVC 开启数据持久化 persistence: enabled: true ## 是否使用 storageClass，如果不适用则补配置 # storageClass: "xxx" ## ## 如果想使用一个存在的 PVC 对象，则直接传递给下面的 existingClaim 变量 # existingClaim: your-claim accessMode: ReadWriteMany # 访问模式 size: 2Gi # 存储容量
现在我们去重新做一次 DEBUG，可以看到正常了，但是还远远不够，接下来我们就来定制其他部分。
定制
比如副本数我们可以通过 Values 来指定，变成 replicas: {{ .Values.replicaCount }}。
更新策略也可以，因为更新策略并不是一层不变的，这里和之前不太一样，我们需要用到一个新的函数 toYaml：
{{- if .Values.updateStrategy }}
strategy: {{ toYaml .Values.updateStrategy | nindent 4 }}
{{- end }}
意思就是我们将 updateStrategy 这个 Values 值转换成 YAML 格式，并保留4个空格。然后添加其他的配置，比如是否需要添加 nodeSelector、容忍、亲和性这些，这里我们都是使用 toYaml 函数来控制空格，如下所示：
{{- if .Values.nodeSelector }}
nodeSelector:
{{ toYaml .Values.nodeSelector | indent 8 }}
{{- end -}}
{{- with .Values.affinity }}
affinity:
{{ toYaml . | indent 8 }}
{{- end }}
{{- with .Values.tolerations }}
tolerations:
{{ toYaml . | indent 8 }}
{{- end }}
接下来当然就是镜像的配置了，如果是私有仓库还需要指定 imagePullSecrets：
{{- if .Values.image.pullSecrets }}
imagePullSecrets:
{{- range .Values.image.pullSecrets }}
- name: {{ . }}
{{- end }}
{{- end }}
containers:
- name: wordpress
image: {{ printf "%s:%s" .Values.image.name .Values.image.tag }}
imagePullPolicy: {{ .Values.image.pullPolicy | quote }}
ports:
- containerPort: 80
name: web
对应的 Values 值如下所示：
image: name: wordpress tag: 5.3.2-apache ## 指定 imagePullPolicy 默认为 Always pullPolicy: IfNotPresent ## 如果是私有仓库，需要指定 imagePullSecrets # pullSecrets: # - myRegistryKeySecretName
然后就是最重要的环境变量配置部分了，因为涉及到数据库的配置，同样最核心的三个环境变量配置 WORDPRESS_DB_HOST、WORDPRESS_DB_USER、WORDPRESS_DB_PASSWORD，由于可能使用我们模板的用户可能使用外部数据库，也有可能使用我们依赖的 mysql 这个子 Chart，所以我们需要分别判断来进行渲染：
env:
- name: WORDPRESS_DB_HOST
{{- if .Values.mysql.enabled }}
value: {{ printf "%s:%d" (include "mysql.fullname" .) (int64 .Values.mysql.service.port) }}
{{- else }}
value: {{ .Values.externalDatabase.host | quote }}
{{- end }}
- name: WORDPRESS_DATABASE_NAME
{{- if .Values.mysql.enabled }}
value: {{ .Values.mysql.mysqlDatabase | quote }}
{{- else }}
value: {{ .Values.externalDatabase.database | quote }}
{{- end }}
- name: WORDPRESS_DB_USER
{{- if .Values.mysql.enabled }}
value: {{ .Values.mysql.mysqlUser | quote }}
{{- else }}
value: {{ .Values.externalDatabase.user | quote }}
{{- end }}
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
{{- if .Values.mysql.enabled }}
name: {{ template "mysql.fullname" . }}
key: mysql-password
{{- else }}
name: {{ printf "%s-%s" .Release.Name "externaldb" }}
key: db-password
{{- end }}
每一个环境变量首先都是判断 mysql.enabled 是否为 true，才表示使用子 Chart 来渲染，而对应的值都是子 Chart 中渲染过后的值，所以也需要我们去了解子 Chart 的渲染行为，如果使用外部的数据库就要简单很多，因为只需要读取 Values 值即可。另外一个值得注意的是如果是配置的密码，我们还需要去创建一个 Secret 资源对象来引用。所以我们在 templates 目录下面创建了一个 externaldb-secrets.yaml 的资源文件，里面配置的密码通过 b64enc 函数转换为 Base64 编码格式。
{{- if not .Values.mysql.enabled }}
apiVersion: v1
kind: Secret
metadata:
name: {{ printf "%s-%s" .Release.Name "externaldb" }}
labels:
app: {{ printf "%s-%s" .Release.Name "externaldb" }}
chart: "{{ template "wordpress.chart" . }}"
release: {{ .Release.Name | quote }}
heritage: {{ .Release.Service | quote }}
type: Opaque
data:
db-password: {{ .Values.externalDatabase.password | b64enc | quote }}
{{- end }}
然后就是 resource 资源声明，这里我们定义一个默认的 resources 值，同样用 toYaml 函数来控制空格：
resources:
{{ toYaml .Values.resources | indent 10 }}
最后是健康检查部分，虽然我们之前没有做 livenessProbe，但是我们开发 Chart 模板的时候就要尽可能考虑周全一点，这里我们加上存活性和可读性两个探针，并且根据 livenessProbe.enabled 和 readinessProbe.enabled 两个 Values 值来判断是否需要添加探针，探针对应的参数也都通过 Values 值来配置：
{{- if .Values.livenessProbe.enabled }}
livenessProbe:
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
successThreshold: {{ .Values.livenessProbe.successThreshold }}
failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
httpGet:
path: /wp-login.php
port: 80
{{- end }}
{{- if .Values.readinessProbe.enabled }}
readinessProbe:
initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }}
periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
successThreshold: {{ .Values.readinessProbe.successThreshold }}
failureThreshold: {{ .Values.readinessProbe.failureThreshold }}
httpGet:
path: /wp-login.php
port: 80
{{- end }}
这样我们的 Deployment 的模板就基本上完成了，我们可以通过 DEBUG 模式来模拟渲染：
$ helm install --generate-name --dry-run --debug .
可以根据结果来判断是否符合我们的需求。
最后我们还需要来对 Service 对象做模板化，因为前面我们是默认的 NodePort 类型，我们需要通过 Values 来定制：
apiVersion: v1
kind: Service
metadata:
name: {{ template "wordpress.fullname" . }}
labels:
app: "{{ template "wordpress.fullname" . }}"
chart: "{{ template "wordpress.chart" . }}"
release: {{ .Release.Name | quote }}
heritage: {{ .Release.Service | quote }}
spec:
selector:
app: "{{ template "wordpress.fullname" . }}"
type: {{ .Values.service.type }}
{{- if (or (eq .Values.service.type "LoadBalancer") (eq .Values.service.type "NodePort")) }}
externalTrafficPolicy: {{ .Values.service.externalTrafficPolicy | quote }}
{{- end }}
ports:
- name: web
port: {{ .Values.service.port }}
targetPort: web
{{- if (and (eq .Values.service.type "NodePort") (not (empty .Values.service.nodePort)))}}
nodePort: {{ .Values.service.nodePort }}
{{- end }}
这样我们就可以通过配置 Values 值来配置 Service 对象了。最后就是 Ingress/IngressRoute 对象了，大家可以自己尝试讲这部分补齐。
最后在 templates 目录下面加上 NOTES.txt 文件来说明如何使用我们的 Chart 包就可以了：
Get the WordPress Manifests Objects:
$ kubectl get all -l app={{ .Release.Name }}
最后我们来真正的使用我们的 Chart 包安装一次来测试下：
$ helm install mychart . --set service.type=NodePort NAME: mychart LAST DEPLOYED: Sun Mar 8 17:52:04 2020 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: Get the WordPress Manifests Objects: $ kubectl get all -l app=mychart $ helm ls NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mychart default 1 2020-03-08 17:52:04.826185 +0800 CST deployed wordpress-0.1.0 5.3.2
安装完成后可以查看我们的资源对象：
$ kubectl get all -l app=mychart-wordpress NAME READY STATUS RESTARTS AGE pod/mychart-wordpress-5f65786d89-2m45s 1/1 Running 0 70s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/mychart-wordpress NodePort 10.99.239.29 <none> 80:30427/TCP 70s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/mychart-wordpress 1/1 1 1 70s NAME DESIRED CURRENT READY AGE replicaset.apps/mychart-wordpress-5f65786d89 1 1 1 70s
这个时候我们通过上面的 NodePort 就可以去访问到我们的应用了，当然还有很多配置我们都是可以直接通过 Values 去进行定制的。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
