Search code examples
kuberneteschartsredisdependencieskubernetes-helm

2 Helm Charts with shared Redis dependency

Currently, I have 2 Helm Charts - Chart A, and Chart B. Both Chart A and Chart B have the same dependency on a Redis instance, as defined in the Chart.yaml file:

dependencies:
- name: redis
  version: 1.1.21
  repository: https://kubernetes-charts.storage.googleapis.com/

I have also overwritten Redis's name since applying the 2 Charts consecutively results in 2 Redis instances, as such:

redis:
  fullnameOverride: "redis"

When I try to install Chart A and then Chart B I get the following error:

Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: PersistentVolumeClaim, namespace: default, name: redis

I was left with the impression that 2 charts with identical dependencies would use the same instance if it's already present?

Solution

  • When you install a chart using Helm, it generally expects each release to have its own self-contained set of Kubernetes objects. In the basic example you show, I'd expect to see Kubernetes Service objects named something like

    release-a-application-a
release-a-redis
release-b-application-b
release-b-redis

    There is a general convention that objects are named starting with {{ .Release.Name }}, so the two Redises are separate.

    This is actually an expected setup. A typical rule of building microservices is that each service contains its own isolated storage, and that services never share storage with each other. This Helm pattern supports that, and there's not really a disadvantage to having this setup.

    If you really want the two charts to share a single Redis installation, you can write an "umbrella" chart that doesn't do anything on its own but depends on the two application charts. The chart would have a Chart.yaml file and (in Helm 2) a requirements.yaml file that references the two other charts, but not a templates directory of its own. That would cause Helm to conclude that a single Redis could support both applications, and you'd wind up with something like

    umbrella-application-a
umbrella-application-b
umbrella-redis

    (In my experience you usually don't want this – you do want a separate Redis per application – and so trying to manage multiple installations using an umbrella chart doesn't work especially well.)