1. 多 Chart 集成管理
只有一个或着少量 Chart 包时，可以通过 helm 命令来操作，管理也比较简单。但实际的业务服务可能比较多也比较复杂，直接使用 helm 来管理不仅不方便，而且容易出错，这时就需要考虑如何来管理多 Chart。
例如，可能会有以下的一些场景需要考虑管理多 chart：
- 产品比较复杂有非常多 Chart 需要编写和管理。例如，一套集成系统有 100 多个服务 Chart 需要编写和管理时。
- 使用 Chart 部署的环境比较多。例如，在私有化场景下，每个客户环境都需要部署一套环境时。
1.1. 现状分析
目前社区对于多 Chart 的管理已经有一些相关的功能或者产品提供支持，能够解决一些问题。如果刚好可以解决你的场景，恭喜你站在了巨人的肩膀上了。
以下会分析一些社区提供的多 Chart 管理方案，进行介绍以及说明其优缺点。
1.1.1. Helm 子 Chart
Helm 可以通过子 Chart 的方式来管理和安装多个 Chart 。
每个 Helm Chart 可以管理一个应用的安装。在实际的开发中，我们遇到的情况通常是需要管理多个应用，及其依赖的支撑服务。最典型的例子就是一个应用依赖一个数据库。应用和数据库分别使用各自的 Helm Chart 来安装。很明显的，安装数据库时提供的用户名、密码和数据库名称，必须与应用在连接数据库时使用的信息保持一致。
对于这样的情况，Helm 提供了子 Chart 的机制，也就是 charts 子目录。我们可以把数据库的 Chart 放到应用的 Chart 的 charts 子目录下，并通过 global 作用域来在父子 Chart 之间传递配置值。
父子 Chart 可以解决一部分问题。如果有两个应用都依赖同一个数据库，那么父子 Chart 就没办法有效工作了，因为把数据库的 Chart 作为任何一个应用的子 Chart 都不合适。Helm Chart 对于配置项的传递方式比较单一。
例如：
- Wordpress
1.1.2. Helmfile
Helmfile 通过 helmfile.yaml 文件帮助用户管理和维护众多 helm chart，其最主要作用是：
- 集成在 CI/CD 系统中，提高部署的可观测性和可重复性，区分环境，免去各种 --set 造成的困扰。提供
helmfile apply命令，体验与kubectl apply类似，根据helmfile.yaml中声明的配置可以一键执行相应的动作，如：添加 repo、安装或更新 release 等。 - 方便对 helm chart 进行版本控制，如指定版本范围、锁定版本等。helmfile 支持 Semver 2.0 的版本号，可以锁定主版本，防止误升级导致的错误。
- 定期同步，避免环境中出现不符合预期的配置。
- 区分环境。这也是个使用率较高的功能，使用 environments 配置·。如果不指定 --environment NAME 参数，默认使用 default 配置。
开源地址：
1.1.3. 容器云平台的应用市场
目前大多数的容器云平台提供 Web 页面来管理 Kuberentes 集群，除了直接创建 Deployment 之类的工作负载外，一般将也会提供基于 Helm 的应用的市场，使用应用市场可以快速查找和安装依赖的 Chart。
但是，对于企业内部开发和管理新 Chart 时，又不是那么的友好。
例如：
- ArtifactsHub
- Rancher 应用市场
1.2. 新的设计
并不是每个产品开发人员都喜欢并能够熟悉 Helm Chart 语法编写出高质量的 Chart 包的。
如何降低 Chart 的学习开发、维护管理难度在大型项目中也非常的重要。
这里提供两种思路，其一是构建一个脚手架模板，快速了解后就能开发高质量的 Chart 包；其二是基于 Web 页面的方式来创建和管理 chart 。
1.2.1. ChartStarter
基于声明式的 Kuberentes 应用定义？
- Kuberentes 版本兼容性管理
- Chart 版本配置多，但大都是默认。实际部署配置少，灵活
- 基于环境的配置管理，通过 cm 和secret 导入到 pod 的env中
1.2.2. 基于 Web 的 Chart 管理系统 ChartStarterWeb (csWeb)
- 基于 ChartStarter 的 Web 系统，平台核心就是管理 values.yaml 文件。
- 按照 Kuberentes 的功能提供模块配置，可以使用默认或调整默认值
- 管理依赖，提供依赖关系拓扑图
- 应用的定义与开发
- 环境的管理
- 多集群应用的安装部署
如果平台管理 helm Chart 原生配置，会复杂不会？