Managing Shared Kubernetes Components with Helm Chart Dependencies

The Problem: Redundant Infrastructure Definitions

When managing multiple Kubernetes applications, you often find yourself duplicating the same supporting infrastructure—such as Redis caches, PostgreSQL databases, or Prometheus exporters—across every application chart. This duplication leads to configuration drift, where one application uses an outdated version of a database while another uses a newer one, making global updates a manual and error-prone process.

The solution is to use Helm Chart Dependencies. By treating shared components as sub-charts, you can centralize the definition of a component and instantiate it across multiple parent charts with a single version reference.

Prerequisites

• Helm 3.x installed on your local machine.
• A Kubernetes cluster with kubectl configured for access.
• Access to a Helm repository (e.g., Artifact Hub or a private ChartMuseum instance) where the shared components are hosted.

Implementing Sub-Charts for Shared Services

To implement dependencies, you must modify the Chart.yaml file of your parent application. This tells Helm which external charts to fetch and how to version them.

1. Defining Dependencies

Add a dependencies section to your Chart.yaml. Use specific version constraints to avoid unexpected breaking changes during updates.

# Chart.yaml
apiVersion: v2
name: my-main-app
version: 1.0.0
dependencies:
  - name: postgresql
    version: 12.1.0
    repository: https://charts.bitnami.com/bitnami
  - name: redis
    version: 17.x.x
    repository: https://charts.bitnami.com/bitnami
    condition: redis.enabled

In this example, the condition field allows you to toggle the Redis deployment on or off via your values.yaml file, which is essential for differentiating between development and production environments.

2. Resolving the Dependency Tree

Defining the dependency is not enough; Helm must download the actual chart archives into a local charts/ directory before the parent chart can be packaged or installed.

Run the following command from the root of your parent chart directory:

# Run as a user with write permissions to the chart directory
helm dependency update .

Expected Result: Helm will create a charts/ folder containing .tgz files for PostgreSQL and Redis. A Chart.lock file will be generated to ensure all team members use the exact same versions.

3. Overriding Sub-Chart Values

Sub-charts are isolated. They cannot see the parent chart's templates. To configure a sub-chart, you must nest the configuration under the sub-chart's name in the parent's values.yaml.

# values.yaml
# Global values are passed to all sub-charts
global:
  storageClass: "longhorn"

# Specific overrides for the postgresql sub-chart
postgresql:
  enabled: true
  auth:
    database: app_db
    username: admin

4. Using Aliases for Multiple Instances

If your application requires two separate instances of the same chart (e.g., two different Redis caches for different purposes), use an alias.

# Chart.yaml
dependencies:
  - name: redis
    version: 17.x.x
    repository: https://charts.bitnami.com/bitnami
    alias: cache-session
  - name: redis
    version: 17.x.x
    repository: https://charts.bitnami.com/bitnami
    alias: cache-data

You would then configure these separately in values.yaml using the aliases cache-session: and cache-data:.

Verification and Diagnostics

Before deploying to a cluster, verify that the dependencies are resolved and the values are merging correctly.

• Check Dependency Status: Run helm dependency list . to ensure all required charts are present and match the versions specified in Chart.yaml.
• Dry-Run Rendering: Run helm template . to output the generated YAML. Search the output for resources belonging to the sub-charts (e.g., kind: StatefulSet for PostgreSQL) to confirm they are being generated.
• Live Check: After deployment, use kubectl get pods -l "app.kubernetes.io/instance=my-main-app" to verify that the sub-chart pods are running alongside the main application.

Limitations and Risks

Rollback Procedure

Because helm dependency update modifies the local filesystem (adding the charts/ directory and Chart.lock), you can revert these changes by deleting the generated files and the dependencies block in Chart.yaml, then committing the changes via your version control system (Git).