目前，我有 2 个 Helm Charts - Chart A 和 Chart B。Chart A 和 Chart B 对 Redis 实例具有相同的依赖关系，如Chart.yaml file:
dependencies:
- name: redis
version: 1.1.21
repository: https://kubernetes-charts.storage.googleapis.com/
我还覆盖了 Redis 的名称，因为连续应用 2 个图表会产生 2 个 Redis 实例，如下所示：
redis:
fullnameOverride: "redis"
当我尝试安装 Chart A 然后安装 Chart B 时，出现以下错误：
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: PersistentVolumeClaim, namespace: default, name: redis
我的印象是，如果实例已经存在，两个具有相同依赖关系的图表将使用同一个实例？
当您使用 Helm 安装图表时，它通常期望每个release拥有自己独立的 Kubernetes 对象集。在您展示的基本示例中，我希望看到 Kubernetes 服务对象的名称类似于
release-a-application-a
release-a-redis
release-b-application-b
release-b-redis
有一个通用约定，对象的命名开头为{{ .Release.Name }}，所以两个 Redis 是分开的。
这实际上是一个预期的设置。构建微服务的典型规则是每个服务都包含自己的独立存储，并且服务从不相互共享存储。此 Helm 模式支持这一点，并且采用此设置并没有真正的缺点。
如果您确实希望两个图表共享一个 Redis 安装，您可以编写一个“伞”图表，它本身不执行任何操作，但依赖于两个应用程序图表。该图表将有一个Chart.yaml文件和（在 Helm 2 中）requirements.yaml引用其他两个图表的文件，但不是templates自己的目录。这将导致 Helm 得出结论：单个 Redis 可以支持这两个应用程序，并且您最终会得到类似的结果
umbrella-application-a
umbrella-application-b
umbrella-redis
（根据我的经验，你通常don't想要这个——你do希望每个应用程序都有一个单独的 Redis - 因此尝试使用伞图管理多个安装效果并不特别好。）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
