WEEW12 BLOG

外观

Helm 入门系列 06：玩转进阶——Helm Chart 高级功能落地实战

约 2234 字大约 7 分钟

Helm 入门系列云原生Helm

2026-03-31

如果你已经掌握了 Helm Chart 的基础模板编写，恭喜你跨过了第一道门槛！但想要把 Helm 用在生产环境，仅靠基础模板远远不够——依赖复用、配置校验、生命周期自定义、安全验证这些高级功能，才是让 Chart 从“能用”变“好用、可靠”的关键。

本文就带你手把手落地 Chart 的核心高级功能，用通俗的语言+实战案例，讲透依赖管理、库 Chart、钩子、测试等核心能力，让你的 Chart 适配生产级场景。

一、依赖项管理：让 Chart 学会“搭积木”

就像开发应用会依赖第三方库一样，Chart 也能依赖其他 Chart（子 Chart），实现功能复用。比如部署 WordPress 时，可直接依赖 MySQL Chart，不用重复写数据库部署逻辑。

1.1 基础配置：声明依赖关系

在 Chart 的 Chart.yaml 里用 dependencies 字段定义依赖，核心就 3 个参数：子 Chart 名称、版本范围、仓库地址。

# Chart.yaml 示例
apiVersion: v2
name: rocket  # 父Chart名称
version: 0.1.0
dependencies:
  - name: booster  # 子Chart名
    version: "^1.2.0"  # 版本范围
    repository: "https://charts.example.com/"  # 子Chart仓库
  - name: logger
    version: "~2.3.0"
    repository: "@internal-repo"  # 引用已添加的本地仓库

1.2 版本范围：别让版本“乱飘”

子 Chart 的版本不能随便写，用 SemVer 速记语法能精准控制版本范围，避免部署时拉到不兼容的版本：

速记语法通俗解释
^1.2.3能更到 1.x.x，但不跨 2.0.0
~1.2.3能更到 1.2.x，但不跨 1.3.0
1.2.x任意 1.2 开头的补丁版本

1.3 安装&锁定依赖：保证部署一致性

写完依赖后，执行命令下载子 Chart 并锁定版本：

helm dependency update  # 简写 helm dep up

这会生成两个关键文件：

  • Chart.lock：把版本范围“固化”成具体版本（比如 ^1.2.0 锁定为 1.2.5），确保所有人部署的版本一致；
  • charts/ 目录：存放下载的子 Chart 压缩包。

如果 charts/ 目录为空但有 Chart.lock，用 helm dependency build 就能快速重建依赖。

1.4 给子 Chart 传值：父对子的“配置指令”

父 Chart 想改子 Chart 的默认配置，不用改子 Chart 源码，直接在父 Chart 的 values.yaml 里以子 Chart 名为键配置即可：

# 父Chart的values.yaml
booster:
  image:
    tag: "v1.2.5"  # 覆盖booster的默认镜像标签
  replicaCount: 3  # 覆盖booster的默认副本数

安装时也能临时改：

helm install rocket ./rocket --set booster.image.tag=v1.2.6

1.5 条件启用：按需加载组件

有些子 Chart 是可选的（比如 WordPress 可选内置 MySQL），用 condition 或 tags 就能动态开关：

单个组件开关（condition）

# Chart.yaml
dependencies:
  - name: mysql
    version: "^8.0.0"
    repository: "https://charts.bitnami.com/bitnami"
    condition: mysql.enabled  # 开关：Values.mysql.enabled为true才启用

在 values.yaml 里默认禁用：

mysql:
  enabled: false

安装时启用：helm install wordpress ./wordpress --set mysql.enabled=true

批量组件开关（tags）

给多个子 Chart 打标签，批量启用/禁用：

dependencies:
  - name: redis
    tags: ["cache", "performance"]
  - name: elasticsearch
    tags: ["search", "performance"]

默认禁用所有 performance 标签的组件：

tags:
  performance: false

安装时批量启用：helm install app ./app --set tags.performance=true

二、库 Chart：打造可复用的“模板工具箱”

如果多个 Chart 要共用相同的模板（比如统一的标签生成、ConfigMap 模板），不用重复写，用库 Chart 封装即可——它是特殊的 Chart，只提供模板，不能直接安装。

2.1 创建库 Chart

核心是在 Chart.yaml 里标记 type: library：

apiVersion: v2
name: mylib
version: 1.0.0
type: library  # 标识为库Chart
description: "通用模板工具箱"

目录结构很简单：不用 values.yaml，模板文件放 templates/ 下，命名以 _ 开头（比如 _configmap.tpl），只定义可复用的命名模板。

2.2 实战：用库 Chart 简化配置

比如库 Chart 里定义通用的 ConfigMap 模板：

# templates/_configmap.tpl
{{/* 定义可复用的ConfigMap模板 */}}
{{- define "mylib.configmap" -}}
{{- $context := index . 0 -}}
{{- $overrides := index . 1 -}}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "mylib.fullname" $context }}
data:
  {{- include "mylib.merge" (list $context $overrides "mylib.configmap.tpl") | nindent 2 }}
{{- end -}}

业务 Chart 引用这个库 Chart（先在 Chart.yaml 加依赖），然后直接调用模板：

# 业务Chart的templates/configmap.yaml
{{/* 调用库Chart的模板，传入自定义配置 */}}
{{ include "mylib.configmap" (list . "myapp.configmap.overrides") }}

{{/* 自定义配置：补充业务特有的内容 */}}
{{- define "myapp.configmap.overrides" -}}
data:
  app.conf: |
    env: {{ .Values.env }}
    logLevel: {{ .Values.logLevel }}
{{- end -}}

三、值文件校验：给配置“加道安检”

values.yaml 没有固定结构，用户很容易配错（比如把副本数写成字符串、拉取策略填错值）。用 JSON Schema 做校验，能提前拦截错误。

3.1 写校验规则：values.schema.json

在 Chart 根目录创建 values.schema.json，定义配置的类型、范围、可选值：

{
  "type": "object",
  "properties": {
    "image": {
      "type": "object",
      "properties": {
        "repository": { "type": "string", "minLength": 1 },  // 仓库名不能为空
        "pullPolicy": {
          "type": "string",
          "enum": ["Always", "IfNotPresent", "Never"]  // 仅允许这3个值
        }
      },
      "required": ["repository"]  // 必传字段
    },
    "replicaCount": {
      "type": "integer",
      "minimum": 1,
      "maximum": 10  // 副本数1-10之间
    }
  }
}

3.2 校验效果：错配置直接报错

如果用户配了非法值：

helm install app ./app --set image.pullPolicy=InvalidPolicy

Helm 会直接报错，避免部署后出问题：

Error: INSTALLATION FAILED: values don't meet the specifications...
- image.pullPolicy: Invalid value: "InvalidPolicy": must be one of ["Always", "IfNotPresent", "Never"]

四、钩子：给 Chart 生命周期“加自定义动作”

钩子是带特殊注解的 K8s 资源（比如 Job、Pod），能在 Chart 安装/升级/卸载等阶段执行自定义操作（比如安装后初始化数据库、卸载前备份数据）。

4.1 常用钩子类型（通俗版）

钩子类型执行时机
pre-install安装前（模板渲染后，资源提交前）
post-install安装后（资源部署成功）
pre-upgrade升级前
post-upgrade升级后
pre-uninstall卸载前
test执行 helm test 时

4.2 实战：安装后执行初始化 Job

# templates/hooks/init-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-init
  annotations:
    helm.sh/hook: post-install  # 安装后执行
    helm.sh/hook-weight: "10"  # 多个钩子时，数字越小越先执行
    helm.sh/hook-delete-policy: hook-succeeded  # 执行成功后删除Job
spec:
  template:
    spec:
      containers:
      - name: init
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        command: ["/bin/sh", "-c", "echo '初始化完成'"]
      restartPolicy: OnFailure

4.3 跳过钩子

如果不想执行钩子，加 --no-hooks 即可：

helm upgrade app ./app --no-hooks

五、Chart 测试：确保部署后能“正常干活”

部署完 Chart 后，得验证应用是否能用——Helm 提供了内置测试和进阶的 CT 工具两种方式。

5.1 内置测试：helm test

用 test 类型的钩子定义测试用例（比如验证服务能访问）：

# templates/tests/test-connection.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-test-connection
  annotations:
    helm.sh/hook: test  # 仅helm test时执行
spec:
  template:
    spec:
      containers:
      - name: test
        image: curlimages/curl:latest
        command: ["curl", "--silent", "--fail", "{{ .Release.Name }}-service:{{ .Values.service.port }}"]
      restartPolicy: Never

运行测试：

helm test myapp

测试成功会输出 Phase: Succeeded，失败则会提示错误，快速定位问题。

5.2 进阶测试：CT 工具（适配 CI/CD）

如果要批量测试不同配置、校验 Chart 语法，用官方的 Chart Testing（CT）工具：

ct lint --charts ./mychart  # 校验语法、版本、结构
ct install --charts ./mychart  # 测试不同values配置下的安装效果

适合集成到 CI/CD 流水线，自动化验证 Chart 质量。

六、安全防护：给 Chart “验明正身”

生产环境最怕 Chart 被篡改或来源不可信，Helm 用 PGP 签名+Provenance 文件解决这个问题。

6.1 生成签名文件

先有 PGP 密钥对，然后打包 Chart 时签名：

helm package ./mychart \
  --sign \  # 启用签名
  --key "你的PGP密钥名" \
  --keyring ~/.gnupg/secring.gpg

会生成两个文件：mychart-0.1.0.tgz（Chart 包）和 mychart-0.1.0.tgz.prov（签名文件）。

6.2 验证 Chart 真伪

安装前先验证：

# 验证本地Chart
helm verify ./mychart-0.1.0.tgz --keyring ~/.gnupg/pubring.gpg

# 安装远程Chart时自动验证
helm install myapp example/mychart --verify --keyring ~/.gnupg/pubring.gpg

验证通过才会安装，避免恶意 Chart 进入集群。

七、CRD 扩展：让 Chart 支持自定义 K8s 资源

如果你的应用依赖自定义资源（CRD），Helm 也能管理，推荐用 crds/ 目录的方式：

7.1 步骤：把 CRD 放 crds/ 目录

在 Chart 根目录创建 crds/，放入 CRD 文件（不用模板化）：

mychart/
├── crds/
│   └── myresource.yaml  # CRD定义
├── Chart.yaml
└── values.yaml

Helm 会在安装其他资源前优先装 CRD，且不会自动升级/删除 CRD（避免误操作集群级资源）。

7.2 注意事项

CRD 是集群级资源，修改/删除会影响所有命名空间；升级时要保证向后兼容，多租户集群要限制 CRD 安装权限。

总结

掌握这些高级功能，你的 Helm Chart 就能从“入门级模板”升级为“生产级包”：

  • 依赖管理让 Chart 模块化、可复用；
  • 库 Chart 减少重复模板；
  • 配置校验和测试提前规避问题；
  • 钩子实现生命周期自定义；
  • 签名和 CRD 管理保障安全与扩展性。

这些功能不是孤立的，结合使用（比如依赖+钩子+测试），能打造出健壮、可维护的 Chart，真正发挥 Helm 在 K8s 包管理中的价值。

Copyright © 2026 weew12