一个 Chart,多个环境:dev、staging 和 prod 的 Values 文件
只覆盖环境之间不同的部分,并理解 values 的合并顺序。
chart 的 values.yaml 保存合理的默认值,但 dev、staging 和 production 很少共享同一个命名空间、副本数或配置值。本指南介绍如何为每个环境叠加额外的 values 文件,而无需维护 chart 本身的多份副本。它基于上一篇指南中的 webapp chart。
让 values.yaml 作为共享的基线
任何在所有地方都应相同的内容,比如应用名称、镜像仓库,请保留在 values.yaml 中。只有特定于环境的字段才属于覆盖文件:
# values-dev.yaml
namespace: dev
config:
customHeader: "welcome to dev"
# values-prod.yaml
namespace: prod
replicaCount: 5
config:
customHeader: "welcome to production"
用 -f 传入的文件不会替换 values.yaml,而是合并在它之上。values-dev.yaml 只需提及 namespace 和 config.customHeader;其他一切,appName、image,都原样从基础文件继承。
在模板中引用命名空间
添加该值,并在任何清单需要声明其命名空间的地方使用它:
# values.yaml (add a default)
namespace: default
# templates/deployment.yaml, templates/service.yaml, templates/configmap.yaml
metadata:
name: {{ .Values.appName }}
namespace: {{ .Values.namespace }}
使用某个环境的 values 文件安装
kubectl create namespace dev
kubectl create namespace prod
helm install web-dev ./webapp -f values-dev.yaml -n dev
helm install web-prod ./webapp -f values-prod.yaml -n prod
这里有两样东西在做相关但不同的工作:-n dev 告诉 Helm 将 release 自身的元数据存放在哪个命名空间,而模板内的 metadata.namespace 告诉 Kubernetes 每个资源放进哪个命名空间。让两者保持一致,即 release 与它所部署的内容位于同一命名空间,是标准做法,可避免日后你运行 helm list -n dev 并期望看到实际运行在那里的一切时产生困惑。
helm list -A
kubectl get all -n dev
kubectl get all -n prod
curl <dev-pod-ip> # or kubectl port-forward, per NOTES.txt
确认每个环境都显示它自己的 customHeader 和副本数。
完整的优先级顺序
Helm 从多个来源合并 values,每个都覆盖之前的:
values.yaml,即 chart 自己的默认值。- 父 chart 的
values.yaml,如果此 chart 被用作依赖(这里不涉及)。 - 用
-f传入的任何文件,按给定顺序,后面的文件优先于前面的。 --set、--set-string或--set-json参数,它们优先于每一个文件。
helm upgrade web-dev ./webapp -f values-dev.yaml --set replicaCount=1
--set 便于一次性的覆盖或快速测试,但对于任何你想要复现的内容,请把它放进文件并提交到版本控制中。在终端里敲入的 --set 参数不会留下任何关于实际部署了什么的记录。
检查合并结果的两种方法
在信任一次安装或升级之前,先看看结果:
helm template ./webapp -f values-prod.yaml
helm get values web-prod
helm template -f 会像 install 一样,用给定的 values 文件渲染 chart,而不触碰集群,所以你可以直接比较两个环境的输出。helm get values(安装之后)显示记录在一个实时 release 上的实际 values,当运行中的 release 与你期望某个文件产生的结果不符时,应该检查它。
关于 secret 的说明
values 文件是纯文本,所以不要把真实凭据放进提交到 Git 的文件里。一种常见的划分是:非敏感的每环境配置放在 values-<env>.yaml 中,而 secret 则通过 CI secret 存储的 --set、Sealed Secrets 或 SOPS 之类的工具注入,或者让 chart 引用一个在 Helm 之外创建的 Kubernetes Secret,而不是把值嵌入 values.yaml。