What is Helm in Kubernetes? Helm and Helm Charts explained | Kubernetes Tutorial 23

Introduction to Helm

In this section, the speaker introduces the main concepts of Helm and explains its use cases and benefits.

What is Helm?

• Helm is a package manager for Kubernetes.

• It allows packaging collections of Kubernetes YAML files into bundles called Helm charts.

• Helm charts can be distributed in public and private repositories.

• Using Helm, you can create your own charts or download and use existing ones from repositories.

Use Cases of Helm

• Helm is commonly used for deploying complex applications like databases (e.g., Elasticsearch, MongoDB) and monitoring tools (e.g., Prometheus).

• Charts for these common deployments are available in public repositories.

• Companies also create private repositories to share charts internally within their organizations.

Benefits of Using Helm

• Simplifies the deployment process by providing pre-packaged configurations.

• Saves time by avoiding manual searching and collecting of YAML files from the internet.

• Allows easy sharing and reuse of configurations through public and private repositories.

Templating Engine in Helm

This section explains how Helm acts as a templating engine, allowing the creation of reusable templates for deploying microservices in Kubernetes.

Templating Engine Functionality

• With multiple microservices deployed in a Kubernetes cluster, each with similar deployment and service configurations, writing separate YAML files for each service becomes repetitive.

• Using Helm's templating engine, a common blueprint can be defined with dynamic values replaced by placeholders.

• The template file references an external configuration file called values.yaml, where specific values are defined.

Conclusion

The speaker concludes by summarizing the main points discussed about Helm's features and benefits.

Summary

• Helm is a package manager for Kubernetes that simplifies the deployment process.

• Helm charts are bundles of Kubernetes YAML files that can be shared and reused.

• Helm acts as a templating engine, allowing the creation of reusable templates for deploying microservices.

• Using Helm saves time and effort by providing pre-packaged configurations and avoiding manual searching for YAML files.

The transcript is already in English, so there is no need to respond in a different language.

Using Helm Charts for Dynamic Value Configuration

In this section, the speaker discusses how Helm charts can be used to define and configure values dynamically in template files. This allows for easier management of values across multiple microservices and different Kubernetes clusters.

Structure of a Helm Chart

• A Helm chart is made up of several directories and files.

• The top-level directory is the name of the chart.

• Inside the chart directory, there are:

• Chart.yaml: Contains meta information about the chart such as name and version.

• values.yaml: Configures values for the template files. These can be overridden later.

• charts/: Stores dependencies if the chart depends on other charts.

• templates/: Contains the template files that will be filled with values during deployment.

Injecting Values into Helm Templates

• Values defined in values.yaml serve as default configurations that can be overridden.

• Values can be overridden by providing an alternative values file using the --values flag when executing helm install.

• Alternatively, individual values can be provided using the --set flag on the command line.

Release Management with Helm

• In Helm version 2, there is a client-server setup where Tiller (the server) runs in a Kubernetes cluster.

• Tiller stores a copy of each configuration for future reference, creating a history of chart executions.

• When upgrading a chart, changes are applied to the existing deployment instead of removing it and creating a new one.

• If an upgrade goes wrong, it can be rolled back using the helm rollback command.

Differences Between Helm Versions 2 & 3

This section highlights some differences between Helm versions 2 and 3 regarding release management.

Tiller in Helm Version 2

• In Helm version 2, the client-server setup includes Tiller as the server component.

• Tiller receives the YAML files from the Helm client and creates components in the Kubernetes cluster based on those files.

• Tiller stores a copy of each configuration for future reference, enabling release management.

Security Concerns with Tiller

• The presence of Tiller in Helm version 2 poses security concerns.

• Tiller has excessive permissions within the Kubernetes cluster, allowing it to create, update, and delete components.

• This architecture raises security issues due to the level of access granted to Tiller.

Removal of Tiller in Helm Version 3

• In Helm version 3, the architecture was simplified by removing Tiller.

• Helm is now a simple binary without a separate server component.

• This change addresses the security concerns associated with Tiller's excessive permissions.