What's Helm and its basics.

What is helm?

Helm is a package manager for Kubernetes, an open-source container orchestration platform. It simplifies the deployment and management of applications on Kubernetes clusters by providing a templating system and a standardized way to package and distribute applications.

With Helm, you can define an application's configuration, dependencies, and deployment instructions in a package called a "chart." A chart is essentially a collection of files, including templates, configuration values, and metadata. Helm allows you to customize these templates and configuration values based on your specific deployment needs.

Helm uses a client-server architecture, where the Helm client interacts with the Tiller server component running within the Kubernetes cluster. The Helm client provides a command-line interface (CLI) for managing charts, while Tiller is responsible for deploying and managing the applications based on the chart specifications.

Using Helm, you can easily install, upgrade, and uninstall applications on Kubernetes clusters with a single command. It also supports versioning and rollback functionality, allowing you to track changes and revert to a previous version if necessary.

Helm has become a popular tool in the Kubernetes ecosystem due to its ability to simplify application deployment, promote reusability, and enhance collaboration among teams working with Kubernetes.

Top 5 reason for using helm?

There are several reasons why Helm is widely used in the Kubernetes ecosystem. Here are the top five reasons:

1. Simplified Application Deployment: Helm simplifies the process of deploying applications on Kubernetes clusters. It provides a standardized approach to define, package, and distribute applications using charts, which encapsulate all the necessary components, configuration values, and dependencies. This simplification saves time and effort in deploying complex applications.

2. Reusability and Modularity: Helm promotes reusability by allowing the creation and sharing of charts. Charts can be easily shared across teams and organizations, enabling the reuse of common configurations and deployment patterns. This modularity enhances collaboration and productivity among teams working with Kubernetes.

3. Versioning and Rollback: Helm supports versioning and rollback functionality, which is crucial for managing application releases. You can track and manage different versions of a chart, making it easier to deploy updates and roll back to a previous version if needed. This feature provides more control and flexibility in managing application lifecycle.

4. Configuration Management: Helm allows you to define configurable parameters within charts. These parameters can be customized during deployment, enabling the same chart to be used across different environments or deployments with specific configuration requirements. This flexibility simplifies the management of application configurations.

5. Ecosystem and Community Support: Helm has a thriving ecosystem and a large community of users and contributors. This results in an extensive collection of Helm charts available in the official Helm chart repository and other community-driven repositories. You can leverage these pre-built charts to deploy popular applications, services, and infrastructure components, saving time and effort in the deployment process.

Overall, Helm's ability to simplify deployment, promote reusability, provide versioning and rollback capabilities, support configuration management, and benefit from a vibrant community makes it a powerful tool for managing applications on Kubernetes clusters.

How helm works?

Helm works as a package manager for Kubernetes, providing a streamlined approach to deploying and managing applications on Kubernetes clusters. Here is an overview of how Helm works:

Chart Creation: Developers or system administrators create a Helm chart, which is a package that contains all the necessary files and configurations to deploy an application on Kubernetes. A chart typically includes a Chart.yaml file (metadata), a templates directory (containing Kubernetes manifest templates), and a values.yaml file (default configuration values).

Chart Packaging: The chart is packaged into a compressed file, usually a .tgz file. This packaging process bundles all the chart files and dependencies together, creating a portable and distributable package.

Chart Repository: The packaged chart can be published to a chart repository. Chart repositories serve as centralized locations to store and share Helm charts. Users can search and access these repositories to find and retrieve charts.

Helm Client: The Helm client is installed on the user's local machine or a build server. It provides a command-line interface (CLI) for interacting with Helm. Users can use the Helm CLI to search for charts, install, upgrade, and uninstall applications on Kubernetes clusters.

Chart Installation: Using the Helm CLI, users can install a chart from a repository by specifying the chart's name and version. During installation, users can override default configuration values to customize the deployment according to their specific needs.

Template Rendering: Once a chart is installed, Helm performs template rendering. It takes the Kubernetes manifest templates in the chart and replaces placeholders with actual values. These values can be user-defined configuration values or computed values from Helm itself. This process generates the final Kubernetes manifests that define the resources to be created on the cluster.

Tiller Server: Tiller is the server-side component of Helm and runs within the Kubernetes cluster. The Helm client communicates with the Tiller server to perform operations on the cluster. Tiller receives chart installation requests, resolves dependencies, and deploys the application based on the chart's specifications.

Application Deployment: After template rendering, Helm sends the generated Kubernetes manifests to the Tiller server. Tiller communicates with the Kubernetes API server to deploy the application. It creates the necessary Kubernetes resources, such as pods, services, deployments, and other objects, on the cluster.

Lifecycle Management: Helm provides functionalities for managing the lifecycle of applications deployed with charts. Users can upgrade or rollback deployments to different chart versions, view release history, and uninstall applications when they are no longer needed.

Helm simplifies and automates the application deployment process, promotes reusability, supports configuration management, and facilitates collaboration among teams working with Kubernetes. It provides a standardized approach to managing applications and enables users to easily deploy, upgrade, and manage applications on Kubernetes clusters.

Helm Architecture

The Helm architecture consists of several components that work together to facilitate application deployment and management on Kubernetes. Here are the key components of the Helm architecture:

Helm Client: The Helm client is a command-line tool installed on the user's local machine or a build server. It serves as the primary interface for interacting with Helm and managing charts and deployments. Users interact with the Helm client by executing commands to search for charts, install, upgrade, and uninstall applications on Kubernetes clusters.

Charts: Charts are packages that contain all the necessary files, templates, and configurations to deploy an application on Kubernetes. They define the application's structure and dependencies. Charts are typically created by developers or system administrators and can be customized during installation using configuration values.

Chart Repository: A chart repository is a central location where Helm charts are stored and shared. Chart repositories can be public or private, allowing users to search for and retrieve charts. The Helm client can communicate with one or multiple repositories to find and download charts for installation.

Kubernetes API Server: The Kubernetes API server is a central component of the Kubernetes control plane. It exposes the Kubernetes API, which Helm interacts with to deploy applications. Helm communicates with the API server to create, update, and delete Kubernetes resources (such as pods, services, deployments) based on the instructions provided in the chart.

Kubernetes Cluster: A Kubernetes cluster is a collection of nodes (machines) that run containerized applications. Helm interacts with the Kubernetes cluster to manage the deployment and lifecycle of applications. It leverages the Kubernetes API to create and manage the necessary resources on the cluster.

In the Helm architecture, the Helm client interacts with the chart repository to find and download charts. Users can customize the charts with configuration values and install them on a Kubernetes cluster. Helm communicates with the Kubernetes API server to deploy the application by creating the required Kubernetes resources. The Tiller component, which was deprecated in Helm 3, used to handle the server-side operations in earlier versions of Helm.

It's important to note that with the deprecation of Tiller in Helm 3, Helm now operates in a client-only mode, making it more secure and eliminating the need for an additional server-side component within the cluster.

What is chart and what it contains?

In Helm, a chart is a package that contains all the necessary files, templates, and configurations required to deploy an application on Kubernetes. It provides a standardized way to define and manage the deployment of applications on Kubernetes clusters.

A chart typically consists of the following components:

Chart.yaml: This file contains metadata about the chart, including the name, version, description, maintainers, and other details. It provides information about the chart itself and helps in identifying and managing different versions of the chart.

Templates: The templates directory contains the Kubernetes manifest templates written in YAML format. These templates define the Kubernetes resources (such as pods, services, deployments, config maps, etc.) that need to be created on the cluster for the application deployment. Placeholders or variables are used within the templates to allow customization and dynamic rendering during deployment.

values.yaml: This file defines the default configuration values for the application deployment. It contains a set of key-value pairs representing various configuration parameters. Users can override these default values during installation to customize the deployment according to their specific requirements.

Chart dependencies: A chart may have dependencies on other charts. In such cases, the dependencies are specified in a requirements.yaml file. This file lists the dependent charts along with their version constraints. Helm resolves and installs these dependencies when the chart is installed, ensuring that all required components are available.

Hooks (optional): Helm allows the inclusion of pre-install and post-install hooks in a chart. Hooks are scripts or commands that run at specific lifecycle stages of the chart deployment. These hooks enable additional operations or customizations to be performed before or after the installation of the chart, such as database setup, secrets generation, or other application-specific tasks.

By packaging all these components together, a chart encapsulates the application's configuration, dependencies, and deployment instructions in a portable and reusable package. This packaging allows for easy sharing, versioning, and deployment of applications using Helm. Users can leverage existing charts from repositories or create their own charts to deploy applications on Kubernetes clusters efficiently.