0
点赞
收藏
分享

微信扫一扫

Helm chart 内置函数


文章目录

  • ​​1. 定义 chart​​
  • ​​2. 创建模板​​
  • ​​3. 添加一个简单的模板​​
  • ​​4. 调试​​
  • ​​5. 内置对象​​

1. 定义 chart

Helm 的 github 上面有一个比较​​完整的文档​​​,一个 chart 包就是一个文件夹的集合,文件夹名称就是 chart 包的名称,比如创建一个 ​​mychart​​ 的 chart 包:

$ helm create mychart
Creating mychart
$ tree mychart/
mychart/
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
│ └── service.yaml
└── values.yaml

2 directories, 7 files

templates 目录下面的文件:

  • ​NOTES.txt​​​:chart 的 “帮助文本”。这会在用户运行​​helm install​​ 时显示给用户。
  • ​deployment.yaml​​​:创建​​Kubernetes deployment​​​ 的基本​​manifest​
  • ​service.yaml​​​:为​​deployment​​​ 创建​​service​​​ 的基本​​manifest​
  • ​ingress.yaml​​​: 创建​​ingress​​ 对象的资源清单文件
  • ​_helpers.tpl​​:放置模板助手的地方,可以在整个 chart 中重复使用

然后我们把 templates 目录下面所有文件全部删除掉,这里我们自己来创建模板文件:

$ rm -rf mychart/templates/*.*

2. 创建模板

这里我们来创建一个非常简单的模板 ConfigMap,在 templates 目录下面新建一个​​configmap.yaml​​文件:

apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-configmap
data:
myvalue: "Hello World"

实际上现在我们就有一个可安装的 chart 包了,通过​​helm install​​命令来进行安装:

$ helm install ./mychart/
NAME: ringed-lynx
LAST DEPLOYED: Fri Sep 7 22:59:22 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME DATA AGE
mychart-configmap 1 0s

在上面的输出中,我们可以看到我们的 ​​ConfigMap​​ 资源对象已经创建了。然后使用如下命令我们可以看到实际的模板被渲染过后的资源文件:

$ helm get manifest ringed-lynx

---
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: mychart-configmap
data:
myvalue: "Hello World"

现在我们看到上面的 ​​ConfigMap​​​ 文件是不是正是我们前面在模板文件中设计的,现在我们删除当前的​​release​​:

$ helm delete ringed-lynx
release "ringed-lynx" deleted

3. 添加一个简单的模板

我们可以看到上面我们定义的 ConfigMap 的名字是固定的,但往往这并不是一种很好的做法,我们可以通过插入 release 的名称来生成资源的名称,比如这里 ConfigMap 的名称我们希望是:​​ringed-lynx-configmap​​,这就需要用到 Chart 的模板定义方法了。

Helm Chart 模板使用的是​​Go语言模板​​​编写而成,并添加了​​Sprig库​​中的50多个附件模板函数以及一些其他特殊的函。

需要注意的是kubernetes资源对象的 ​​labels​​​ 和 ​​name​​ 定义被限制 63个字符,所以需要注意名称的定义。

现在我们来重新定义下上面的 ​​configmap.yaml​​ 文件:

apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"

我们将名称替换成了​​{{ .Release.Name }}-configmap​​​,其中包含在{{和}}之中的就是模板指令,​​{{ .Release.Name }}​​​ 将 ​​release​​​ 的名称注入到模板中来,这样最终生成的 ConfigMap 名称就是以 ​​release​​ 的名称开头的了。这里的 Release 模板对象属于 Helm 内置的一种对象,还有其他很多内置的对象,稍后我们将接触到。

现在我们来重新安装我们的 Chart 包,注意观察 ​​ConfigMap​​ 资源对象的名称:

$ helm install ./mychart
helm install ./mychart/
NAME: quoting-zebra
LAST DEPLOYED: Fri Sep 7 23:20:12 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME DATA AGE
quoting-zebra-configmap 1 0s

可以看到现在生成的名称变成了​​quoting-zebra-configmap​​​,证明已经生效了,当然我们也可以使用命令​​helm get manifest quoting-zebra​​查看最终生成的清单文件的样子。

4. 调试

我们用模板来生成资源文件的清单,但是如果我们想要调试就非常不方便了,不可能我们每次都去部署一个​​release​​​实例来校验模板是否正确,所幸的时 Helm 为我们提供了​​--dry-run --debug​​​这个可选参数,在执行​​helm install​​​的时候带上这两个参数就可以把对应的 ​​values​​ 值和生成的最终的资源清单文件打印出来,而不会真正的去部署一个release实例,比如我们来调试上面创建的 chart 包:

$ helm install . --dry-run --debug ./mychart
[debug] Created tunnel using local port: '35286'

[debug] SERVER: "127.0.0.1:35286"

[debug] Original chart version: ""
[debug] CHART PATH: /root/course/kubeadm/helm/mychart

NAME: wrapping-bunny
REVISION: 1
RELEASED: Fri Sep 7 23:23:09 2018
CHART: mychart-0.1.0
USER-SUPPLIED VALUES:
{}

COMPUTED VALUES:
...
HOOKS:
MANIFEST:

---
# Source: mychart/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: wrapping-bunny-configmap
data:
myvalue: "Hello World"

现在我们使用​​--dry-run​​​就可以很容易地测试代码了,不需要每次都去安装一个 ​​release​​ 实例了,但是要注意的是这不能确保 Kubernetes 本身就一定会接受生成的模板,在调试完成后,还是需要去安装一个实际的 release 实例来进行验证的。

5. 内置对象

刚刚我们使用​​{{.Release.Name}}​​将 release 的名称插入到模板中。这里的 Release 就是 Helm 的内置对象,下面是一些常用的内置对象,在需要的时候直接使用就可以:

​Release​​:这个对象描述了 release 本身。它里面有几个对象:

  • ​Release.Name​​:release 名称
  • ​Release.Time​​:release 的时间
  • ​Release.Namespace​​​:release 的​​namespace​​(如果清单未覆盖)
  • ​Release.Service​​:release 服务的名称(始终是 Tiller)。
  • ​Release.Revision​​​:此​​release​​ 的修订版本号,从1开始累加。
  • ​Release.IsUpgrade​​​:如果当前操作是升级或回滚,则将其设置为​​true​​。
  • ​Release.IsInstall​​​:如果当前操作是安装,则设置为​​true​​。

​Values​​​:从​​values.yaml​​文件和用户提供的文件传入模板的值。默认情况下,Values 是空的。

​Chart​​​:​​Chart.yaml​​文件的内容。所有的 Chart 对象都将从该文件中获取。

​Files​​:这提供对 chart 中所有非特殊文件的访问。虽然无法使用它来访问模板,但可以使用它来访问 chart 中的其他文件。请参阅 “访问文件” 部分。

  • ​Files.Get​​​ 是一个按名称获取文件的函数(​​.Files.Get config.ini​​)
  • ​Files.GetBytes​​ 是将文件内容作为字节数组而不是字符串获取的函数。这对于像图片这样的东西很有用。

​Capabilities​​:这提供了关于 Kubernetes 集群支持的功能的信息。

  • ​Capabilities.APIVersions​​ 是一组版本信息。
  • ​Capabilities.KubeVersion​​​ 提供了查找 Kubernetes版本的方法。它具有以下值:​​Major​​​,​​Minor​​​,​​GitVersion​​​,​​GitCommit​​​,​​GitTreeState​​​,​​BuildDate​​​,​​GoVersion​​​,​​Compiler​​​,和​​Platform​​。
  • ​Capabilities.TillerVersion​​​ 提供了查找​​Tiller​​​版本的方法。它具有以下值:​​SemVer​​​,​​GitCommit​​​,和​​GitTreeState​​​。
    ​​​Capabilities.APIVersions.Has $version​​​指示集群上是否有可用的版本(例如batch/v1)或资源(例如)。apps/v1/Deployment
    ​​​Capabilities.KubeVersion​​​并且​​Capabilities.KubeVersion.Version​​​是 Kubernetes 版本。
    ​​​Capabilities.KubeVersion.Major​​​是 Kubernetes 的主要版本。
    ​​​Capabilities.KubeVersion.Minor​​​是 Kubernetes 次要版本。
    ​​​Capabilities.HelmVersion​​​是包含 Helm 版本详细信息的对象,它是相同的输出h​​elm version​​​​Capabilities.HelmVersion.Version​​是 semver 格式的当前 Helm 版本。
    ​Capabilities.HelmVersion.GitCommit​​是 Helm git sha1。
    ​Capabilities.HelmVersion.GitTreeState​​是 Helm git 树的状态。
    ​Capabilities.HelmVersion.GoVersion​​是使用的 Go 编译器的版本。

​Template​​:包含有关正在执行的当前模板的信息

  • ​Template.Name​​​: 当前模板的命名空间文件路径(例如​​mychart/templates/mytemplate.yaml​​)
  • ​Template.BasePath​​​: 当前图表的模板目录的命名空间路径(例如​​mychart/templates​​)

上面这些值可用于任何顶级模板,要注意内置值始终以大写字母开头。这也符合Go的命名约定。当你创建自己的名字时,你可以自由地使用适合你的团队的惯例。


举报

相关推荐

0 条评论