Helm是Kubernetes包管理器而非自动化部署工具；helm upgrade --install实现幂等部署；helm repo update必须手动执行；values合并遵循后覆盖前规则，嵌套结构需显式清空；helm template可预检YAML错误。
Helm 是 Kubernetes 的包管理器，不是“自动化部署工具”——它本身不触发部署，只负责模板渲染和版本化发布。想靠 helm install 就实现 CI/CD 自动化，八成会卡在权限、上下文或 chart 版本漂移上。
为什么 helm upgrade --install 是日常运维的底线操作
直接用 helm install 会导致重复执行失败（资源已存在），而 helm upgrade 又要求 release 必须已存在。二者合体的 helm upgrade --install 才是幂等前提。
- 首次运行：当作
install处理，创建 release - 后续运行：自动识别已有 release 并执行
upgrade - 必须显式指定
--namespace，否则默认落在default，和多数 CI 环境 namespace 隔离策略冲突 - 加
--atomic能在升级失败时自动回滚，但会延长命令耗时，调试阶段建议先关掉
helm repo add 后不 helm repo update，chart 拉取永远失败
很多人以为 helm repo add 会自动同步远程索引，其实只是把仓库地址写进本地 repositories.yaml。真正获取 chart 列表，必须手动触发 helm repo update。
- CI 脚本里漏掉这步，
helm search repo xxx查不到，helm pull报no chart name found - 私有仓库（如 Harbor）需提前配置认证：
helm registry login harbor.example.com -u user -p pass - 使用
helm pull --version 1.2.3显式指定版本，避免依赖 latest 标签——后者在私有仓库中常被禁用
values 文件合并顺序决定最终配置，别迷信 -f 参数顺序
Helm 合并 values 的规则是「后加载的覆盖前加载的」，但前提是它们结构一致。嵌套 map 若未完整声明，会出现字段丢失而非覆盖。
- 执行
helm upgrade -f common.yaml -f prod.yaml --set replicaCount=3时：
—prod.yaml里的同名 key 会覆盖common.yaml
—--set最高优先级，但只能覆盖叶子节点，不能删掉整个 section - 若
common.yaml定义了ingress.enabled: true，而prod.yaml没提 ingress，最终仍是true—— 不会变成null或false - 想清空某个嵌套结构，得在 prod.yaml 里显式写
ingress: {}，而不是留空
CI 中用 helm template 做预检，比直接 upgrade 少踩 70% 的 YAML 错误
直接在集群上跑 helm upgrade，报错信息常被封装成 “failed to install CRD” 或 “invalid spec”，实际可能是 values 写错字段名、缩进错位、或用了未定义的 tpl 函数。
- 在流水线里加一步：
helm template myapp ./mychart -f values.yaml --namespace staging | kubectl --dry-run=client -f - -
helm template输出纯 YAML，可配合yq或grep做断言，比如检查是否含imagePullSecrets - 注意：--dry-run=client 不校验 RBAC 和 CRD，真正权限问题仍要上集群测；但至少能提前发现
{{ .Values.nonexist }}这类模板错误
chart 的 Chart.yaml 里 version 字段和 appVersion 完全无关，前者控制 chart 发布版本，后者只是给应用标个号——但很多团队拿它当镜像 tag 用，结果 helm repo index 生成失败，或者 CI 里按 appVersion 推送镜像却找不到对应 chart。
