1. Helm 最佳使用场景

在云原生的背景下，应用的定义与交付可能由于 CI/CD 的流水线而变得界限模糊，但实际业务场景中不是所有的场景都适合使用 CI/CD 来实现。

Helm 的出现与快速成长不是偶然的巧合，而是它确实能解决实际的一些问题，带来有效的收益与价值。

1.1. 场景一：在 Kubernetes 中部署应用时涉及较多类型资源管理问题

在 Kubernetes 集群中部署服务并不是简单的将 Image 镜像运行起来就可以了，实际上还会涉及一些其他相关的 Kubernetes 的资源一起配合才能正常提供功能，例如常见的资源有 Deployment、Service、Ingress、Secret、ConfigMap、PV/PVC、ServiceAccount、RBAC 等等，还其他扩展服务的相关资源，如 Prometheus-operator 的 ServiceMonitor，或用户自定义的 CRD 等等。这么多类型的文件如果使用 YAML 文件管理会非常的复杂，或者通过容器云 Web 管理又难以分享、迁移、复用。

应用在测试环境功能测试验证后，在生产环境部署时相关的资源文件全部都重新一一创建也是可以的，但是很容易由于细节疏漏导致上线时出现文件缺失，配置错误等异常，给上线带来一定的困难和风险。这种情况推荐使用 Helm Chart 来定义应用，将该应用相关的 Kuberentes 资源统一进行打包管理，测试和生产的部署也仅有 values.yaml 配置上的少量差异，降低管理多个 Kuberentes 资源的复杂性问题。

1.2. 场景二：网络或安全限制导致无法使用 CI/CD 发布生产应用

有些公司测试环境与生产环境是网络隔离的状态，甚至是物理上的隔离需要更换设备才能访问不同环境，生产上线仅仅是需要的是部署。即便是网络可以打通想在生产环境单独搭建完整的流水线也不符合企业实际的，因为代码是企业的核心资产，生产环境是会面向全互联网用户，可能是自建机房也可能是在其他公有云平台上，大部分企业的 Git 代码服务器是不允许放通到互联网环境的，防止可能被攻击的安全风险。

因此推进的方式的是在开发/测试环境编译打包和测试应用，将应用封装成 Helm Chart 包，在测试环境经过严格的测试验证后，在生产环境部署 Helm Chart 即可。在测试环境对构建好的 Helm Chart 部署相关资源和配置都可以进行覆盖测试，这样也可以保障 Kubernetes 相关资源的准确与完整性，为生产环境上线提供高质量 SLA。

1.3. 场景三：多部门或子公司开发的产品复用

在企业内部一个部门开发了好的一款优秀的应用，其他部门也希望能够使用这个应用，特别是大型企业有多个子公司时尤为明显。这类应用例如：日报周报系统、设备日志系统、发票管理系统、ERP系统等等。这时如何将这些应用分享给其他部门会成为一个挑战，如果交付过程太过复杂就会导致推广受限，进而在集团层面产生资源的浪费。

使用 Helm Chart 来定义和封装应用，给其他相关人员提供程序时提供一个 Helm Chart 包即可，helm install 安装交付过程也方便快捷。

1.4. 场景四：软件私有化交付到客户环境

如前文提到的 ERP 系统、网易数帆轻舟平台等，这些 toB 私有化产品在交付时会有很多的无法预测的客户侧基础设施问题，如何高效高质量的将产品服务交付到客户环境成为这类企业核心关注的重点之一。

使用 Helm Chart 来定义和封装应用，将多个应用进行关联来构建一套功能完整的系统，能给私有化的交付提供高效、高质量、低成本的交付实践。