企业官网建设流程全解析

Bitnami Chart 生产避坑指南

【免费下载链接】chartsBitnami Helm Charts项目地址: https://gitcode.com/GitHub_Trending/charts30/charts

当你用 Bitnami Chart 部署生产库，最疼的不是首次 install，而是三个月后的漂移：common 库一升级行为就变，镜像还从公共仓库拉，资源给得小到 Pod 被驱逐。这篇文章从依赖锁定、参数穿透、资源预设、快速失败校验四个实战问题出发，讲清生产 values.yaml 怎么写。

chart 依赖锁定：update 之后先查 Chart.lock

很多人以为 Chart.yaml 里写的版本号就是最终生效的版本。不是。

2.x.x 是区间，不是承诺

以 redis 为例，它声明的 common 依赖是2.x.x。执行helm dependency update，今天解析到 2.31.4，明天可能解析到更新的 2.31.x。而 common 库的 templates/ 目录里有 14 个 tpl 文件，任何一个行为变化都会随版本一起被拉进来。

下面两段分别来自 redis 的 Chart.yaml 和更新后的 Chart.lock。

# Chart.yaml：声明的是版本区间 dependencies: - name: common repository: oci://registry-1.docker.io/bitnamicharts version: 2.x.x # Chart.lock：update 之后实际锁定的版本 - name: common version: 2.31.4 digest: sha256:fc442e77200e1914dd46fe2649...

锁文件解决的是：Chart.yaml 里的 2.x.x 区间每次都可能解析出不同结果，没有锁，依赖更新就是掷骰子。

⚠️ 注意，2.x 小版本范围内函数会被废弃。_images.tpl 里common.images.pullSecrets的注释就标了 deprecated，指向新的renderPullSecrets。也就是说，一次"兼容"升级可能悄悄改变生成的清单。

把锁文件交给 CI 盯

规则只有一条：Chart.lock 提交进仓库，CI 里跑完helm dependency build后断言 digest 不变。变了就有人改了版本区间，先看清 common 改了什么再合。这个仓库里 common 当前是 2.31.10，而 redis 的锁停在 2.31.4——两者不一致本身就是个提醒。

镜像统一：global.imageRegistry 一处改动全 chart 生效

场景很常见：集群换私有镜像仓库。如果 chart 里组件多、还有子 chart，逐个改 registry 会改到吐。

common 模板的取值顺序

所有 Bitnami chart 的镜像都走common.images.image这一个模板，取值顺序是固定的：registry 先看组件级.Values.image.registry，为空就回退global.imageRegistry；tag 未设置时回退 chart 的 appVersion；给了 digest，分隔符从冒号换成 @，digest 永远盖过 tag。正因为所有组件都走这一个模板，"改一处 global 全生效"才成立。拉取密钥同理：renderPullSecrets会把 global 与组件级的 pullSecrets 合并并去重。

生产用 digest 兜底

想钉死生产拉取的镜像，在 values 里这样覆盖。

global: imageRegistry: registry.example.com imagePullSecrets: - regcred image: digest: "sha256:9a3f5b..."

它解决的是 tag 可被重发的问题：tag 是仓库可以变的值，digest 不行。

子 chart 不听你的：global 是 Helm 模板复用的唯一通道

部署 postgresql-ha 这类带子 chart 的发布时，你改的往往是内层 chart 的行为。穿透规则很简单：common 模板跨 chart 边界只认global.*。

穿透规则：common 模板只认 global

global 承载的就是imageRegistry、imagePullSecrets、defaultStorageClass这几类"每个组件都该听同一份"的参数。而子 chart 自己命名空间里的键（比如postgresql.auth.*）遵循子 chart 的 schema。键名写错不会报错，只会静默回退到子 chart 的默认值——这是"设了值没生效"最常见的根因。

像上图这种发布，一个 release 驱动整套多 Pod 拓扑，配置的只有一套 values。global 写错，图里每个组件都跟着错。

生产 values.yaml：别拿 nano 预设上生产

redis 的 master 默认resourcesPreset: "nano"，同时resources: {}。values 注释自己说了：设置了 resources 预设就被忽略，生产推荐用 resources。common 库 _resources.tpl 开头更直接：预设仅供基础测试，不用于生产。

预设档位一览

下表是模板里写死的真实档位（含 ephemeral-storage 之外的四项）：

🚨 写了一个不存在的档位，模板会直接 fail 并列出全部合法值。这是故意的，比默默猜一个值强。

模板里 if/else 的顺序就是优先级

下面是 redis master Pod 模板里 resources 块的真实渲染顺序。

{{- if .Values.master.resources }} resources: {{- toYaml .Values.master.resources | nindent 12 }} {{- else if ne .Values.master.resourcesPreset "none" }} resources: {{- include "common.resources.preset" (dict "type" .Values.master.resourcesPreset) | nindent 12 }} {{- end }}

这个顺序解决了"预设和自定义配置不能混写"的问题：只要填了 resources，预设就不参与渲染，默认 nano 只是兜底。

所以生产 values 只需要显式写 resources，不用去动 resourcesPreset。

别信 install 成功：让 chart 自己拦住错误参数

Helm 只校验结构，不校验语义。参数在不在合理范围，是 chart 自己的事。

一次把所有错误攒齐再 fail

redis 的 _helpers.tpl 是这种写法的范本：各校验项的结果攒进列表，任一非空就整体停掉。

{{- define "redis.validateValues" -}} {{- $messages := list -}} {{- $messages := append $messages (include "redis.validateValues.architecture" .) -}} {{- $messages := append $messages (include "redis.validateValues.tls" .) -}} {{- $message := join "\n" $messages -}} {{- if $message -}} {{- printf "\nVALUES VALIDATION:\n%s" $message | fail -}} {{- end -}} {{- end -}}

攒齐再 fail 的好处是所有问题一次列全。比如 architecture 写成非法值，install 会直接失败并告诉你合法值只有 standalone 和 replication，不用修一个、装一次、再撞一个。

latest 标签会被 chart 点名警告

common.warnings.rollingTag会在渲染时检查各组件的镜像标签，用到 latest 这类滚动标签就发出警告。💡 生产环境应当让这条警告清零：要么固定 tag，要么钉 digest。

落地建议

1. Chart.lock 提交进仓库，CI 里跑helm dependency build后断言 digest 不变，变了就人工看 common 的变更。
2. global.imageRegistry和imagePullSecrets只在这一个层级配一次，组件级不重复写 registry。
3. 生产 values 显式写resources的 requests/limits，关键镜像用 digest 钉死，resourcesPreset 保持默认即可。
4. install 之前先在本机跑helm template <release> ./chart -f values-prod.yaml，让校验失败和滚动标签警告出现在你的终端，而不是集群里。

【免费下载链接】chartsBitnami Helm Charts项目地址: https://gitcode.com/GitHub_Trending/charts30/charts