Kubernetes – Managing Dependencies and Versions in Helm

Introduction

Helm is an indispensable tool when it comes to deploying and managing applications in Kubernetes. Much like a package manager for Kubernetes, it simplifies the process of defining, installing, and upgrading even the most complex Kubernetes applications. This tutorial delves into managing dependencies and versions in Helm, ensuring that Kubernetes configurations are maintainable and coherent.

Understanding Helm Charts

A Helm chart is a collection of files that describe a related set of Kubernetes resources. It contains templates for Kubernetes YAML manifest files, a values.yaml file that specifies default configuration settings, and a Chart.yaml file that includes information about the chart itself. To understand dependency management, it’s essential to comprehend the role of the chart and its structure.

Managing Dependencies with Helm

Dependencies in Helm are other Helm charts that your application relies on to function. For example, if your web application requires a Redis cache, you’d include Redis as a dependency. These dependencies are specified in the Chart.yaml file, or they can be dynamically linked using Helm’s dependency management system.

dependencies:
  - name: redis
    version: "~5.0.0"
    repository: "https://charts.bitnami.com/bitnami"

The above snippet defines Redis as a dependency and specifies that any version compatible with 5.0.0 is acceptable. The repository from where the Redis chart can be retrieved is also provided.

Version Locking and Management

Version locking is crucial for ensuring consistent deployments. You can lock a dependency to a specific version number to prevent updates that haven’t been tested with your application. Helm provides a way to update dependencies while keeping their versions under control through the helm dependency update command, which should pull the most recent versions that still satisfy the criteria specified in Chart.yaml.

helm dependency update ./my-chart

The update command will update Chart.lock, locking down the versions of the library charts that your chart depends upon.

Updating and Upgrading Helm Charts

To make sure your Helm charts and their dependencies remain up-to-date, Helm provides commands that help you update and upgrade:

• helm repo update: Fetch the latest list of charts from the specified repository.
• helm upgrade: Upgrade a deployed release with a more recent version of a chart and/or values.

Example:

helm upgrade my-release my-chart --values my-values.yaml

When upgrading, Helm will attempt to do a smart comparison between the old and new versions to avoid non-necessary updates.

Advanced Example: Working with Subcharts

Subcharts are Helm charts used as dependencies of another chart. Their management involves understanding Helm’s chart dependencies feature and the requirements.yaml file, which has been replaced with Chart.yaml in Helm 3. Subcharts are installed underneath the parent chart and are versioned independently, though their lifecycle is controlled by the parent.

Let’s go through a practical example to understand how Subcharts work with Helm. We’ll create a simple Helm chart with a subchart as a dependency.

For this example, let’s assume you have a main application chart called myapp and you want to include a database as a subchart, for instance, PostgreSQL.

Step 1: Create the Main Chart (myapp)

First, create your main chart (if you haven’t already):

helm create myapp

This command creates a new chart directory with the necessary files.

Step 2: Add a Subchart to myapp

You can add a subchart by either manually placing a chart in the charts/ directory of your main chart or by defining it as a dependency.

Let’s add PostgreSQL as a dependency. You do this by editing the Chart.yaml file in your myapp chart.

1. Open myapp/Chart.yaml and add the dependency:

dependencies:
  - name: postgresql
    version: "10.3.11"
    repository: "https://charts.bitnami.com/bitnami"

2. Update your dependencies to ensure PostgreSQL chart is downloaded into your charts/ directory:

helm dependency update myapp

Step 3: Configure Subchart

You can override configuration values of the subchart (PostgreSQL) by editing the values.yaml in your myapp chart. Create a section for PostgreSQL and set the values you want to override.

postgresql:
  auth:
    username: "myuser"
    password: "mypassword"
    database: "mydatabase"

Step 4: Install the Chart

Now, you can install your myapp chart, and the PostgreSQL subchart will be installed as part of this process.

helm install myapp-release ./myapp

This command deploys myapp along with the PostgreSQL subchart on the Kubernetes cluster.

In this example, the PostgreSQL chart is a subchart of myapp. It’s managed as a dependency and its lifecycle (installation, upgrade, etc.) is controlled by the main chart (myapp). You can define as many subcharts as needed in this way, allowing you to modularize and manage complex applications. Remember that each subchart can be independently versioned, but their overall lifecycle is tied to the parent chart.

Dealing with Transitive Dependencies

Subcharts can have their own dependencies, which may lead to complex dependency trees. To help manage these, Helm uses a lock file (Chart.lock) to record the exact versions that should be installed to ensure that a Helm chart’s dependencies are satisfied reliably. By checking in the lock file into version control, you ensure that everyone on the team works with the same dependency resolutions.

Best Practices for Dependency Versioning

Here are some tips to effectively manage Helm chart dependencies:

1. Semantic Versioning: Use semantic versioning to help consumers of your chart understand what to expect from new versions with regards to compatibility and features.
2. Checking in Chart.lock: Ensuring that Chart.lock is checked into source control will help maintain consistency across different environments.
3. Regularly Update Dependencies: Keep dependencies updated but also maintain a rigorous testing cycle. Regularly running helm dependency update and testing updated charts helps catch issues early.
4. Prune Unnecessary Dependencies: Over time, dependencies may become outdated or unnecessary. Reviewing and pruning your dependencies will help keep your chart clean and reduce potential attack surfaces.

Conclusion

Managing dependencies and versions in Helm charts is essential to maintain the reliability and reproducibility of your Kubernetes deployments. Helm’s tools and conventions offer structured approaches to dependency version locking, maintenance, and upgrades. By mastering dependency management with Helm, you can ensure that your Kubernetes applications are both stable and cutting-edge. Remember to test thoroughly with every change, lean on semantic versioning principles, and keep a good handle on your subcharts and transitive dependencies. With these practices, managing complex applications becomes much more seamless and the risk for unwelcome surprises is minimized.