helm upgrade命令中--version参数的使用时机与适用场景

首先明确该参数的核心作用：显式声明目标chart的版本号，优先级高于helm默认的版本选择逻辑，官方对该参数的基础定义为：

--version string 指定要使用的确切chart版本，若未指定该参数则默认使用最新版本。

参数的具体生效逻辑和你传入的chart来源直接绑定，不存在全局统一的行为：

• 当你使用本地chart源（本地tgz压缩包、本地解压后的chart目录）执行安装/升级时，helm会直接读取chart包内Chart.yaml中声明的version字段作为实际生效的chart版本，不会触发远程版本拉取、匹配逻辑。
  你提到的两个操作：

  # 首次安装用本地1.0.0包
  helm install my-app-rls my-app-1.0.0.tgz
  # 升级用本地1.0.1包
  helm upgrade my-app-rls my-app-1.0.1.tgz
  

  属于典型的本地chart源场景，这时候完全不需要加--version参数。如果强行加，helm只会做一致性校验：如果你传入的--version值和tgz包内Chart.yaml写的版本不一致，会直接报错终止升级，不会覆盖包内的版本号。
• 当你使用远程仓库chart源（格式为<仓库名>/<chart名>、OCI仓库地址）执行安装/升级时，helm会先拉取仓库的版本索引，再根据--version参数匹配要拉取的chart包：传了参数就拉取对应精确版本的包，找不到就报错；没传参数就默认拉取索引里标记为最新的稳定版本。

该参数的设计初衷是解决远程chart源的版本选择问题，同时可用于发版流程的强校验，常见必要场景如下：

• 从公共/私有helm仓库（HTTP仓库、OCI仓库均可）拉取chart执行升级时，锁定固定版本，避免意外拉取最新版。
  生产环境从仓库部署chart时必须加该参数，否则helm默认拉取仓库内最新的稳定版，一旦仓库推送了不兼容的大版本chart，下次执行升级就会直接拉取未经过验证的新版本，引发服务故障。比如要从bitnami仓库升级nginx到15.3.0版本，命令写法为：

  helm upgrade my-nginx bitnami/nginx --version 15.3.0
  

• CI/CD流水线中做版本双重校验，避免人为失误。哪怕你用本地tgz包发版，也可以显式传入预期的版本号，一旦出现拿错安装包、打包时Chart.yaml版本填错的情况，helm会因为版本不匹配直接终止流程，拦住错误发版。
• 检索、测试仓库中历史版本chart时，指定版本拉取对应包做验证，不需要手动去仓库索引里翻找历史包下载地址。

• 误区1：认为--version可以修改chart包内的版本号。实际上该参数没有修改chart元数据的能力，仅做版本选择、一致性校验。
• 误区2：认为所有升级场景都要加--version。用明确版本命名的本地tgz包升级时，加该参数没有额外收益，写错了反而会导致升级失败。

内容的提问来源于stack exchange，提问作者Vahid