【问题标题】:Is it possible to abstract boilerplate YAML from helm subchart templates?是否可以从 helm 子图模板中抽象出样板 YAML?
【发布时间】:2020-02-28 03:03:29
【问题描述】:

有没有办法将样板 YAML 从子图表模板移动到父 _helpers.tplvalues.yaml

掌舵项目

    MyHelmApp
    │
    ├── Chart.yaml
    ├── values.yaml
    ├── templates
    │   ├── _helpers.tpl
    │   ├── configmap.yaml
    │   └── app-ingress-rules.yaml
    │
    └── charts
        │
        ├── app1
        │   ├── Chart.yaml
        │   ├── templates
        │   │   ├── _helpers.tpl
        │   │   ├── deployment.yaml
        │   │   └── service.yaml
        │   └── values.yaml
        ├── app2
        │   ├── Chart.yaml
        │   ├── templates
        │   │   ├── _helpers.tpl
        │   │   ├── deployment.yaml
        │   │   └── service.yaml
        │   └── values.yaml
        └── app3
            ├── Chart.yaml
            ├── templates
            │   ├── _helpers.tpl
            │   ├── deployment.yaml
            │   └── service.yaml
            └── values.yaml

详细说明:我有 3 个应用程序子图表,它们的模板中都有样板 YAML。这些模板中的值在父图表的 values.yaml 中定义,并且变量路径是相同的。例如:

app1、app2 和 app3 deployment.yaml 都包含...

          livenessProbe:
            httpGet:
              path: {{ .Values.health.livenessProbe.path }}
              port: {{ .Values.health.livenessProbe.port }}
            initialDelaySeconds: {{ .Values.health.livenessProbe.initialDelaySeconds }}
            periodSeconds: {{ .Values.health.livenessProbe.periodSeconds }}
            timeoutSeconds: {{ .Values.health.livenessProbe.timeoutSeconds }}
            successThreshold: {{ .Values.health.livenessProbe.successThreshold }}
            failureThreshold: {{ .Values.health.readinessProbe.failureThreshold }}

          readinessProbe:
            tcpSocket:
              port: {{ .Values.health.readinessProbe.port }}
            initialDelaySeconds: {{ .Values.health.readinessProbe.initialDelaySeconds }}
            periodSeconds: {{ .Values.health.readinessProbe.periodSeconds }}
            timeoutSeconds: {{ .Values.health.readinessProbe.timeoutSeconds }}
            successThreshold: {{ .Values.health.livenessProbe.successThreshold }}
            failureThreshold: {{ .Values.health.readinessProbe.failureThreshold }}

values.yaml(在父图表中)

app1:
  health:
    livenessProbe:
      path: /system_health
      port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
      timeoutSeconds: 5
      successThreshold: 1
      failureThreshold: 3
    readinessProbe:
      port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 5
      successThreshold: 1
      failureThreshold: 3

app2:
  health:
    livenessProbe:
      path: /system_health
      port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
      timeoutSeconds: 5
      successThreshold: 1
      failureThreshold: 3
    readinessProbe:
      port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 5
      successThreshold: 1
      failureThreshold: 3

(etc)

回到问题:我想抓取子图表模板中相同的内容并将其移动到一个集中的位置,例如父图表的 _helpers.tpl 或 values.yaml;这可能吗?你能提供一个例子来说明你会如何做到这一点吗?

【问题讨论】:

    标签: kubernetes yaml kubernetes-helm


    【解决方案1】:

    Helm 在具有共享模板命名空间的单个执行环境中呈现它提供的所有 YAML,来自所有父图表和依赖图表。理论上,app1 图表可以依赖于父级的_helpers.tpl 中定义的模板,并且在您显示的特定布局中,它会起作用。

    由于这种环境设置,还可以编写一个“图表”,它实际上不会生成任何自己的 YAML,而只是包含模板。 Helm 3 将包括“图书馆图表”作为一个特定的概念。更好的布局仍然是拥有一个包含共享模板的库,并引用它。

    MyHelmApp
    \-- charts
      +-- app1
      | +-- Chart.yaml
      | \-- templates/...
      \-- common
        +-- Chart.yaml
        \-- templates
          \-- _helpers.tpl
              (but no *.yaml)
    

    现在MyHelmApp 依赖于app1app2app3,每个都依赖于common。这将使您可以独立于其兄弟姐妹安装其中的任何一个。

    Helm 没有办法将 YAML 的片段“推送”到其他位置的对象中(Kustomize,相对较新的 Kubernetes 的一部分,可以做到这一点)。每个对象都必须为自己声明任何可能允许的潜在定制。所以在每个图表中你必须声明

    spec:
    {{ include "common.probes" . | indent 2 }}
    

    通用图表只定义模板,当它们被调用时,它们会使用本地化到子图表的.Values 版本。

    {{- define "common.probes" -}}
    livenessProbe:
      httpGet:
        path: {{ .Values.health.livenessProbe.path }}
        et: cetera
    {{ end -}}
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-03-01
      • 1970-01-01
      • 1970-01-01
      • 2012-12-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多