子chart和全局值

到目前为止，我们只使用了一个chart。但chart可以使用依赖，称为 子chart，且有自己的值和模板。 该章节我们会创建一个子chart并能看到访问模板中的值的不同方式。

在深入研究代码之前，需要了解一些应用的子chart的重要细节：

  1. 子chart被认为是“独立的”，意味着子chart从来不会显示依赖它的父chart。
  2. 因此，子chart无法访问父chart的值。
  3. 父chart可以覆盖子chart的值。
  4. Helm有一个 全局值 的概念，所有的chart都可以访问。

这些限制不一定都适用于提供标准化辅助功能的 library charts。

浏览本节的示例之后，这些概念会变得更加清晰。

创建子chart

为了做这些练习，我们可以从本指南开始时创建的mychart/开始，并在其中添加一个新的chart。

  1. $ cd mychart/charts
  2. $ helm create mysubchart
  3. Creating mysubchart
  4. $ rm -rf mysubchart/templates/*

注意，和以前一样，我们删除了所有的基本模板，然后从头开始，在这个指南中，我们聚焦于模板如何工作，而不是管理依赖。 但 Chart指南提供了更多子chart运行的信息。

在子chart中添加值和模板

下一步，为mysubchart创建一个简单的模板和values文件。mychart/charts/mysubchart应该已经有一个values.yaml。 设置如下：

  1. dessert: cake

下一步，在mychart/charts/mysubchart/templates/configmap.yaml中创建一个新的配置映射模板：

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: {{ .Release.Name }}-cfgmap2
  5. data:
  6.   dessert: {{ .Values.dessert }}

因为每个子chart都是 独立的chart，可以单独测试mysubchart：

  1. $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart
  2. SERVER: "localhost:44134"
  3. CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart
  4. NAME:   newbie-elk
  5. TARGET NAMESPACE:   default
  6. CHART:  mysubchart 0.1.0
  7. MANIFEST:
  8. ---
  9. # Source: mysubchart/templates/configmap.yaml
  10. apiVersion: v1
  11. kind: ConfigMap
  12. metadata:
  13.   name: newbie-elk-cfgmap2
  14. data:
  15.   dessert: cake

用父chart的值来覆盖

原始chart，mychart现在是mysubchart的 父。这种关系是基于mysubchart在mychart/charts中这一事实。

因为mychart是父级，可以在mychart指定配置并将配置推送到mysubchart。比如可以修改mychart/values.yaml如下：

  1. favorite:
  2.   drink: coffee
  3.   food: pizza
  4. pizzaToppings:
  5.   - mushrooms
  6.   - cheese
  7.   - peppers
  8.   - onions
  10. mysubchart:
  11.   dessert: ice cream

注意最后两行，在mysubchart中的所有指令会被发送到mysubchartchart中。因此如果运行helm install --dry-run --debug mychart，会看到一项mysubchart的配置：

  1. # Source: mychart/charts/mysubchart/templates/configmap.yaml
  2. apiVersion: v1
  3. kind: ConfigMap
  4. metadata:
  5.   name: unhinged-bee-cfgmap2
  6. data:
  7.   dessert: ice cream

现在，子chart的值已经被顶层的值覆盖了。

这里需要注意个重要细节。我们不会改变mychart/charts/mysubchart/templates/configmap.yaml模板到 .Values.mysubchart.dessert的指向。从模板的角度来看，值依然是在.Values.dessert。当模板引擎传递值时，会设置范围。 因此对于mysubchart模板，.Values中只提供专门用于mysubchart的值。

但是有时确实希望某些值对所有模板都可用。这是使用全局chart值完成的。

全局Chart值

全局值是使用完全一样的名字在所有的chart及子chart中都能访问的值。全局变量需要显示声明。不能将现有的非全局值作为全局值使用。

这些值数据类型有个保留部分叫Values.global，可以用来设置全局值。在mychart/values.yaml文件中设置一个值如下：

  1. favorite:
  2.   drink: coffee
  3.   food: pizza
  4. pizzaToppings:
  5.   - mushrooms
  6.   - cheese
  7.   - peppers
  8.   - onions
  10. mysubchart:
  11.   dessert: ice cream
  13. global:
  14.   salad: caesar

因为全局的工作方式，mychart/templates/configmap.yaml和mysubchart/templates/configmap.yaml 应该都能以{{ .Values.global.salad }}进行访问。

mychart/templates/configmap.yaml:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: {{ .Release.Name }}-configmap
  5. data:
  6.   salad: {{ .Values.global.salad }}

mysubchart/templates/configmap.yaml:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: {{ .Release.Name }}-cfgmap2
  5. data:
  6.   dessert: {{ .Values.dessert }}
  7.   salad: {{ .Values.global.salad }}

现在如果预安装，两个输出会看到相同的值：

  1. # Source: mychart/templates/configmap.yaml
  2. apiVersion: v1
  3. kind: ConfigMap
  4. metadata:
  5.   name: silly-snake-configmap
  6. data:
  7.   salad: caesar
  9. ---
  10. # Source: mychart/charts/mysubchart/templates/configmap.yaml
  11. apiVersion: v1
  12. kind: ConfigMap
  13. metadata:
  14.   name: silly-snake-cfgmap2
  15. data:
  16.   dessert: ice cream
  17.   salad: caesar

全局值在类似这样传递信息时很有用，不过要确保使用全局值配置正确的模板，确实需要一些计划。

与子chart共享模板

父chart和子chart可以共享模板。在任意chart中定义的块在其他chart中也是可用的。

比如，我们可以这样定义一个简单的模板：

  1. {{- define "labels" }}from: mychart{{ end }}

回想一下模板标签时如何 全局共享的。因此，标签chart可以包含在任何其他chart中。

当chart开发者在include 和 template 之间选择时，使用include的一个优势是include可以动态引用模板：

  1. {{ include $mytemplate }}

上述会取消对$mytemplate的引用，相反，template函数只接受字符串字符。

避免使用块

Go 模板语言提供了一个 block 关键字允许开发者提供一个稍后会被重写的默认实现。在Helm chart中， 块并不是用于覆盖的最好工具，因为如果提供了同一个块的多个实现，无法预测哪个会被选定。

建议改为使用include。