9. 通过依赖项导入子值
在某些情况下,希望允许子图表的值传播到父图表并作为通用默认值共享。使用该exports格式的另一个好处是,它将使未来的工具能够内省用户可设置的值。
可以使用 YAML 列表dependencies在字段中的父图表中指定包含要导入的值的键。import-values列表中的每个项目都是从子图表exports字段导入的键。
要导入exports键中未包含的值,请使用子父格式。两种格式的示例如下所述。
9.1 exports 格式
如果子图表的values.yaml
文件在根目录包含一个exports
字段,则可以通过指定要导入的键将其内容直接导入父值,如下例所示:
# parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data
# child's values.yaml file exports: data: myint: 99
由于我们data
在导入列表中指定键,Helm 在exports
子图表的字段中查找data
键并导入其内容。
最终的父值将包含我们导出的字段:
# parent's values myint: 99
请注意,父键data
不包含在父级的最终值中。如果需要指定父键,请使用 ‘child-parent’ 格式。
9.2 使用子父格式
要访问未包含在exports
子图表值的键中的值,您需要指定要导入的值的源键 ( child) 和父图表值中的目标路径 ( parent)。
下面import-values
的示例中的 指示 Helm 获取在child:
路径中找到的任何值并将它们复制到指定路径中的父值parent
:
# parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports
在上面的示例中,在子图表 1 default.data
的值中找到的值将被导入到myimports
父图表值中的键,详细信息如下:
# parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!"
# subchart1's values.yaml file default: data: myint: 999 mybool: true
父图表的结果值为:
# parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!"
父级的最终值现在包含从 subchart1
导入的myint
和字段。mybool
10. charts/通过目录手动管理依赖项
charts/如果需要对依赖项进行更多控制,可以通过将依赖关系图复制到目录中来明确表达这些依赖关系。
依赖项应该是一个解压缩的图表目录,但它的名称不能以_or开头.。图表加载器会忽略此类文件。
例如,如果 WordPress 图表依赖于 Apache 图表,则 Apache 图表(正确版本)将在 WordPress 图表的charts/目录中提供:
wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ...
harts/
上面的示例显示了 WordPress
图表如何通过将这些图表包含在其目录中来表达其对 Apache 和 MySQL
的依赖。
提示: 要将依赖项放入您的
charts/
目录,请使用helm pull
命令
11. 使用依赖项的操作方面
面的部分解释了如何指定图表依赖关系,但是这对使用helm installand 的图表安装有何影响helm upgrade?
假设名为“A”的图表创建了以下 Kubernetes 对象
命名空间“A-命名空间”
有状态集“A-StatefulSet”
服务“A-服务”
此外,A 依赖于创建对象的图表 B
命名空间“B-命名空间”
副本集“B-副本集”
服务“B-服务”
安装/升级图表 A 后,将创建/修改一个 Helm 版本。该版本将按以下顺序创建/更新所有上述 Kubernetes 对象:
A-命名空间
B-命名空间
A-服务
B-服务
B-副本集
A-StatefulSet
这是因为当 Helm 安装/升级图表时,图表中的 Kubernetes 对象及其所有依赖项都是
聚合成一个集合;然后
按类型后跟名称排序;然后
按该顺序创建/更新。
因此,使用图表及其依赖项的所有对象创建了一个版本。
Kubernetes 类型的安装顺序由 kind_sorter.go 中的枚举 InstallOrder 给出(参见Helm 源文件)。
12. 模板和值
Helm Chart 模板是用Go 模板语言编写的,添加了来自 Sprig 库的 50 个左右的附加模板函数和一些其他专用函数。
所有模板文件都存储在图表的templates/文件夹中。当 Helm 渲染图表时,它将通过模板引擎传递该目录中的每个文件。
模板的值以两种方式提供:
图表开发人员可以提供一个values.yaml在图表内部调用的文件。该文件可以包含默认值。
图表用户可以提供包含值的 YAML 文件。这可以在命令行中使用helm install.
当用户提供自定义值时,这些值将覆盖图表values.yaml文件中的值。
12.1 模板文件
模板文件遵循编写 Go 模板的标准约定(有关详细信息,请参阅text/template Go
包文档)。示例模板文件可能如下所示:
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 }}
上面的示例大致基于https://github.com/deis/charts,是 Kubernetes 复制控制器的模板。它可以使用以下四个模板值(通常在values.yaml文件中定义):
imageRegistry:Docker 映像的源注册表。
dockerTag:泊坞窗图像的标签。
pullPolicy:Kubernetes 拉取策略。
storage:存储后端,默认设置为"minio"
所有这些值都由模板作者定义。Helm 不需要或指定参数。
要查看许多工作图表,请查看 CNCF Artifact Hub。
12.2 预定义值
通过values.yaml文件(或通过--set标志)提供的值可以从.Values模板中的对象访问。但是您可以在模板中访问其他预定义的数据。
以下值是预定义的,可用于每个模板,并且不能被覆盖。与所有值一样,名称区分大小写。
Release.Name:版本名称(不是图表)
Release.Namespace: 图表发布到的命名空间。
Release.Service:进行发布的服务。
Release.IsUpgrade:如果当前操作是升级或回滚,则设置为 true。
Release.IsInstall:如果当前操作是安装,则设置为 true。
Chart:的内容Chart.yaml。因此,图表版本是可获得的,Chart.Version并且维护者在Chart.Maintainers.
Files:一个类似地图的对象,包含图表中的所有非特殊文件。这不会让您访问模板,但会让您访问存在的其他文件(除非使用排除它们.helmignore)。可以使用{{ index .Files "file.name" }}或使用该{{.Files.Get name }}功能访问文件。您还可以使用以下方式访问文件的[]byte内容{{ .Files.GetBytes }}
Capabilities:一个类似地图的对象,包含有关 Kubernetes 版本 ( {{ .Capabilities.KubeVersion }}) 和支持的 Kubernetes API 版本 ( {{ .Capabilities.APIVersions.Has "batch/v1" }})的信息
注意:任何未知Chart.yaml字段都将被删除。它们将无法在Chart对象内部访问。因此,Chart.yaml不能用于将任意结构化的数据传递到模板中。不过,值文件可用于此目的。
12.3 Values files
考虑上一节中的模板values.yaml
,提供必要值的文件如下所示:
imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3"
值文件采用 YAML
格式。图表可能包含默认values.yaml
文件。Helm install
命令允许用户通过提供额外的 YAML 值来覆盖值:
$ helm install --generate-name --values=myvals.yaml wordpress
当以这种方式传递值时,它们将被合并到默认值文件中。例如,考虑一个myvals.yaml
如下所示的文件:
storage: "gcs"
当它与values.yaml图表中的 合并时,生成的内容将是:
imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs"
请注意,只有最后一个字段被覆盖。
注意:图表中包含的默认值文件必须命名为values.yaml. 但是在命令行上指定的文件可以命名为任何名称。
注意:如果在or--set上使用该标志,则这些值会在客户端简单地转换为 YAML。helm install helm upgrade
注意:如果值文件中存在任何必需的条目,则可以使用“必需”函数在图表模板中将它们声明为必需的然后可以使用该.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 }}
12.4 Scope, Dependencies, and Values
Values files
可以声明顶级图表以及该图表charts/
目录中包含的任何图表的值。或者,换一种说法,值文件可以为图表及其任何依赖项提供值。例如,上面的演示 WordPress 图表同时具有mysql和apache作为依赖项。值文件可以为所有这些组件提供值:
title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache
更高级别的图表可以访问下面定义的所有变量。因此 WordPress 图表可以访问 MySQL 密码为.Values.mysql.password. 但是较低级别的图表无法访问父图表中的内容,因此 MySQL 将无法访问该title属性。就此而言,它也不能访问apache.port.
值是命名空间的,但命名空间会被修剪。因此对于 WordPress 图表,它可以访问 MySQL 密码字段为.Values.mysql.password. 但是对于 MySQL 图表,值的范围已经缩小,命名空间前缀被删除,所以它会简单地看到密码字段为.Values.password.
12.5 Global Values
从 2.0.0-Alpha.2
开始,Helm 支持特殊的“global
”值。考虑上一个示例的修改版本:
title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache
上面添加了一个global带有 value 的部分app: MyWordPress。该值可用于所有图表,如.Values.global.app。
例如,mysql模板可以访问app为{{ .Values.global.app}},apache图表也可以访问。实际上,上面的值文件是这样重新生成的:
title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache
这提供了一种与所有子图表共享一个顶级变量的方法,这对于设置metadata
标签等属性很有用。
如果子图表声明了一个全局变量,则该全局变量将向下传递(到子图表的子图表),但不会向上传递到父图表。子图表无法影响父图表的值。
12.6 架构 Files
有时,图表维护者可能想要定义其值的结构。这可以通过在values.schema.json
文件中定义模式来完成。模式表示为JSON 模式。它可能看起来像这样:
- helm install
- helm upgrade
- helm lint
- helm template
满足此架构要求的文件示例values.yaml
可能如下所示:
name: frontend protocol: https port: 443
请注意,模式应用于最终.Values
对象,而不仅仅是values.yaml
文件。这意味着以下yaml文件有效,鉴于图表安装了相应的--set
选项,如下所示。
name: frontend protocol: https
helm install --set port=443
此外,根据所有子图模式检查最终.Values
对象。这意味着父图表无法规避子图表的限制。这也适用于反向 - 如果子图的文件中未满足子图的要求,则父图必须满足这些限制才能有效。values.yaml
13. 自定义资源定义 (CRD)
Kubernetes 提供了一种机制来声明新类型的 Kubernetes 对象。使用 CustomResourceDefinitions (CRD),Kubernetes 开发人员可以声明自定义资源类型。
在 Helm 3 中,CRD 被视为一种特殊的对象。它们在图表的其余部分之前安装,并且受到一些限制。
CRD YAML 文件应放在crds/图表内的目录中。多个 CRD(由 YAML 开始和结束标记分隔)可以放在同一个文件中。Helm 将尝试将CRD 目录中的所有文件加载到 Kubernetes 中。
CRD 文件不能被模板化。它们必须是纯 YAML 文档。
当 Helm 安装一个新图表时,它会上传 CRD,暂停直到 API 服务器使 CRD 可用,然后启动模板引擎,渲染图表的其余部分,并将其上传到 Kubernetes。由于这种排序,CRD 信息.Capabilities在 Helm 模板中的对象中可用,并且 Helm 模板可以创建在 CRD 中声明的对象的新实例。
例如,如果您的图表在目录中有一个 CRD ,您可以CronTab在目录中创建该类型的crds/实例:CronTabtemplates/
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: # ...
Helm
将确保该CronTab
类型已安装并且在 Kubernetes API
服务器中可用,然后再继续在templates/.
13.1 CRD 的限制
与 Kubernetes 中的大多数对象不同,CRD 是全局安装的。出于这个原因,Helm 在管理 CRD 时采取了非常谨慎的方法。CRD 受到以下限制:
永远不会重新安装 CRD。如果 Helm 确定crds/目录中的 CRD 已经存在(无论版本如何),Helm 将不会尝试安装或升级。
CRD 永远不会在升级或回滚时安装。Helm 只会在安装操作时创建 CRD。
CRD 永远不会被删除。删除 CRD 会自动删除集群中所有命名空间中的所有 CRD 内容。因此,Helm 不会删除 CRD。
鼓励想要升级或删除 CRD 的操作员手动执行此操作并非常小心。
✈推荐阅读:
https://www.bookstack.cn/read/helm-3.8.0-en/b5fa667da3c6d162.md
helm v3.8.0 命令入门指南
helm 快速学习手册