理想情况下，您可以使用以下命令给予依赖关系：
https://helm.sh/docs/helm/helm_dependency/

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Helm charts将其依赖项存储在'charts/'中。对于图表开发人员来说，在声明所有依赖关系的“Chart.yaml”中管理依赖关系通常更容易。
依赖项命令对该文件进行操作，从而可以轻松地在所需的依赖项和存储在'charts/'目录中的实际依赖项之间进行同步。
您还可以使用子图表和父图表格式来管理相关性
文件夹结构的东西会这样

├── Chart.yaml
├── charts
│   └── django
│       ├── Chart.yaml
│       ├── templates
│       │   ├── deployment.yaml
│       │   ├── ingress.yaml
│       │   └── service.yaml
│       └── values.yaml
├── templates
└── values.yaml

举例来说：https://medium.com/craftech/one-chart-to-rule-them-all-3f685e0f25a9
您也可以在官方文档中阅读更多内容：https://helm.sh/docs/chart_template_guide/subcharts_and_globals/
到目前为止，我们只使用了一个图表。但是图表可以有依赖关系，称为子图表，它们也有自己的值和模板。在本节中，我们将创建一个子图，并查看从模板中访问值的不同方式。

不幸的是没有尽管Helm的官方文档声称，它实际上与“包管理器”几乎没有相似之处。Helm charts实际上是完全单一的，不试图成为其他任何东西（与包管理器所做的正好相反）。
Helm通过图表重用和部署时模板提供了 * 构建时 * 依赖解决方案，但没有任何部署时依赖。在部署时，它仅：

• 解析yaml中的模板变量
• 从子yaml文件创建一个yaml文件
• 对yaml中的对象类型进行排序/拆分，以满足某些k8部署要求。
• 将自己的注解添加到对象中，以便在后续调用中重新发现它们。
• 部署yaml

Helm charts需要在打包时“编译”其所有依赖项，这意味着所有递归依赖项必须在打包时复制到伞图中。在部署时，所有这些依赖关系图都被简单地转储到单个大型yaml中，而不检查集群中已经存在的内容。只有在部署最终的yaml时，它才真正捕捉到存在冲突（如果存在冲突，并且它不只是创建同一事物的另一个示例）。