Kubernetes Cluster: Helm Integration

When deploying applications in Kubernetes, a better approach is to use Helm, a helm package manager designed specifically for Kubernetes. Helm simplifies the process of installing well-known or widely used solutions into your Kubernetes cluster by offering preconfigured packages that can be installed quickly. With Helm, you can fetch and install Kubernetes applications directly from remote repositories or create your Helm charts for local deployments.

Helm comes pre-installed on all control plane nodes within a Kubernetes cluster, requiring no extra setup. To begin using Helm, simply connect to the node (for example, through Web SSH), and you’re ready to go.

Additionally, Helm’s package manager version is automatically updated whenever the Kubernetes cluster undergoes upgrades, ensuring you have the latest features and improvements at your disposal.

Helm operates on three key concepts:

1. Chart: A Chart is like a bundled package Helm uses to deploy applications, tools, or services in a Kubernetes cluster. It includes all the necessary configurations and definitions needed to run the application smoothly within Kubernetes.
2. Repository: A Repository is a storage space where Helm charts are gathered and made available for sharing. It is a centralized channel, where developers can access and contribute to charts, making it easy to deploy applications using Helm.
3. Release: A Release represents a deployed instance of a chart within a Kubernetes cluster. You can install the same chart multiple times in the same cluster, each with its unique identifier (release name). For example, you can have several database instances running as separate releases, each with its distinct configuration and settings.

In this guide, we’ll walk through the essential steps of using Helm:

• Searching for charts and working with repositories
• Installing new Helm applications
• Managing existing applications

Discovering Helm Charts

Within a minute, you can easily find preconfigured solutions ready to deploy in your Kubernetes cluster. Helm, the package manager for Kubernetes, offers a central hub filled with a variety of ready-to-use solutions. Additionally, you have the option to utilize custom repositories.

Helm provides a robust search feature that can query two distinct source types:

Helm search hub queries the Artifact Hub, a community-driven Helm chart repository that aggregates charts from numerous sources.

For example, to find publicly available charts for WordPress, you can use the following command:

Helm Search Hub WordPress

When you use the helm search repo, it looks through the repositories that you’ve added to your local Helm client using helm repo add. This search is done to the local system, so it doesn’t require an internet connection.

Starting with Helm 3 (which has been used since Kubernetes 1.18.10), there’s no default chart repository included. Instead, you can manage repositories using commands like helm repo add, helm repo list, and helm repo remove. For instance, to add well-known Bitnami repositories, you can use the following command:

Helm Repo Add Bitnami https://charts.bitnami.com/bitnami

To view the list of configured repositories, use the helm repo list command. This command will display the repositories that are currently set up in your Helm client.

Helm Repo List

To ensure your Helm client is up to date with the latest changes in chart repositories, you can run the following command:

Helm Repo Update

Installing Helm Package

To install a new package using Helm, use the `helm install` command with two required arguments:

• name: This is the name you choose for the release (e.g., `mywordpress`).
• chart: This is the name of the chart you want to install, typically in the format `{repository}/{chart}` (e.g., `bitnami/wordpress`).

In addition to the required arguments, you can provide optional chart options to customize the application during installation. This allows you to tailor settings such as configuration values. For instance, during installation, you can change the blog name by using the –set wordpressBlogName=’My Blog!’ parameter. You can find more customization charts in the managing Helm section.

helm install –set wordpressBlogName=’My Blog!’ mywordpress bitnami/wordpress

Note: Before proceeding, please ensure that a public IP address is assigned or enabled for the environment. If it’s not enabled, please enable the IP address before proceeding further with the task.

When you install a Helm chart, it creates a new release instance. If you prefer Helm to generate a name for the release, you can omit specifying a release name and use the –generate-name parameter instead.

The Helm client provides helpful information such as resources created, the status of release, or any further steps of configuration needed. Let’s go through these steps to confirm that our WordPress instance is set up and running smoothly.

To obtain the WordPress URL and admin credentials after installing WordPress using Helm, you can run the following commands:

1. export SERVICE_IP=$(kubectl get svc –namespace default mywordpress –template “{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}”)
2. printf “WordPress URL: http://$SERVICE_IP/\nWordPress Admin URL: http://$SERVICE_IP/admin\nUsername: user\nPassword: $(kubectl get secret –namespace default mywordpress -o jsonpath=”{.data.wordpress-password}” | base64 –decode)\n”

Then, log in to the WordPress admin dashboard using the admin credentials obtained during installation.

Upon setting a custom blog name (“My Blog!“) using the –set parameter, it seamlessly applies to our blog.

Handling Helm Application

Helm offers various commands for managing deployed charts. These actions encompass upgrading and rolling back releases, checking status and configuration values, and more.

1. To monitor the status of a release or review its configuration, utilize the helm status command.

helm status mywordpress

Frequently, there’s a need to personalize the chart with specific settings of your choice. This can be achieved by supplying the desired values using either the –values (-f) or –set flags during the installation or upgrade processes. The –values option involves passing custom values through a distinct YAML file, while –set allows for direct input via the command line (e.g., –set a=b,c=d or –set outer.inner=value).

You have the flexibility to use these flags repeatedly, with –set taking precedence over others. When conflicts arise, the most recent (right-most) override holds priority.

2. You can utilize the helm upgrade command to update your release to a new chart version or modify your release’s configuration. Helm aims to execute the upgrade in the least invasive manner possible by updating only the components that have changed since the last release.

Given the intricacies of our WordPress chart from the installation process, it’s essential to provide the current passwords when upgrading the release. To streamline this, let’s assign these values to their respective variables for convenience.

• export WORDPRESS_PASSWORD=$(kubectl get secret –namespace “default” mywordpress -o jsonpath=”{.data.wordpress-password}” | base64 –decode)
• export MARIADB_ROOT_PASSWORD=$(kubectl get secret –namespace “default” mywordpress-mariadb -o jsonpath=”{.data.mariadb-root-password}” | base64 –decode)
• export MARIADB_PASSWORD=$(kubectl get secret –namespace “default” mywordpress-mariadb -o jsonpath=”{.data.mariadb-password}” | base64 –decode)

You can now supply passwords using the –set flag:

helm upgrade --set wordpressPassword=$WORDPRESS_PASSWORD,mariadb.auth.rootPassword=$MARIADB_ROOT_PASSWORD,mariadb.auth.password=$MARIADB_PASSWORD mywordpress bitnami/wordpress

helm upgrade –set

For example, you can create a values-template.yaml file like this:

wordpressPassword: %WP_PASS%
Mariadb:
auth:
rootPassword: %DB_ROOT_PWD%
password: %DB_PWD%

Next, replace the placeholders with the actual password values you’ve exported to variables:

cat values-template.yaml | \
sed "s/%WP_PASS%/$WORDPRESS_PASSWORD/g" | \
sed "s/%DB_ROOT_PWD%/$MARIADB_ROOT_PASSWORD/g" | \
sed "s/%DB_PWD%/$MARIADB_PASSWORD/g" > values.yaml

Now you can pass the file containing the required configurations (values.yaml) in the helm upgrade or helm install commands using the –values (-f) flag. These steps will enable you to upgrade the multiple WordPress without specifying a password for each of them.

For instance:

helm upgrade -f values.yaml mywordpress bitnami/wordpress

This manages to make it streamline the process and ensures that your custom parameters are managed properly.

3. The helm get values command is a useful tool for viewing the values used to generate a release in the cluster. You can use as follows:

helm get values mywordpress

You’ll notice that our password settings remain unchanged after the upgrade.

4. Additionally, reverting to a previous release is straightforward in case of any issues.

To perform a rollback using Helm, you’ll need two specific parameters: the name of the target release and the revision number you wish to revert to. The first installation always starts at revision one. Each subsequent install, upgrade, or rollback increases this revision number by one.

helm history mywordpress

helm rollback mywordpress 1

5. To remove a release from the cluster, use the following command:

helm uninstall mywordpress

Once you’ve uninstalled a release, you can use the helm list command to view your currently deployed releases.

These are the fundamentals of using the Helm package manager with Kubernetes.