Learnitweb

Introduction to Helm

What is Helm?

Helm is a package manager for Kubernetes, similar to package managers on other platforms:

  • Windows: Uses installers (e.g., .exe, .msi).
  • Linux: Uses package managers like apt and yum.
  • Node.js: Uses npm (Node Package Manager).

Like these package managers, Helm helps install, upgrade, and manage software—but in the Kubernetes ecosystem.

Helm works with charts, which are like packages containing all the Kubernetes resource templates and configurations needed for an application. These charts can be pulled from repositories (public or private) and deployed with a single command.

Challenges of Working Directly with Kubernetes

Before diving into Helm, it’s crucial to understand the challenges of managing applications directly in Kubernetes. Let’s consider a scenario where we deploy a Product Microservice Application that relies on a MySQL database in a Kubernetes cluster.

  1. Managing Multiple YAML Configuration Files
    To deploy our microservice and database, we must create several YAML files to define different Kubernetes resources. These include:
    • Deployment YAML for MySQL
    • Service YAML to expose MySQL on a specific port
    • ConfigMap and Secret YAML for configuration and sensitive data like database credentials
    • Deployment YAML for the microservice
    • Service YAML for the microservice
    • Additional configurations like Ingress, Network Policies, and Persistent Volume Claims (PVC) as required
      Each of these files must be manually maintained and updated, making the deployment process cumbersome.
  2. Static Configuration Issues
    Once created, these YAML files remain static. This means:
    • They cannot dynamically receive parameters (like different environment-specific values for staging and production).
    • Many sections in the YAML files are repetitive, leading to redundancy and maintenance difficulties.
    • Any modifications require changes to multiple files, increasing the risk of human error.
  3. Consistency Issues in Deployments
    Typically, these YAML files are stored in GitHub to maintain version control. However, consistency issues arise when:
    • Developers or DevOps engineers manually edit Kubernetes resources using commands like kubectl edit.
    • These manual changes are not reflected in the source-controlled YAML files.
    • The cluster state becomes inconsistent with the stored configurations, leading to unpredictable behavior during future deployments.
  4. Lack of Revision History
    Kubernetes does not maintain a version history of deployments. Consider the following scenario:
    1. We deploy an application using its YAML configuration.
    2. We modify only the Service and ConfigMap and redeploy.
    3. Later, we modify just the Deployment YAML and redeploy again.
    4. At some point, we want to revert to a previous version.

Without a built-in revision system, rolling back to a previous state becomes difficult unless we manually back up each working version. Also, changes made directly in the cluster may not be traceable.

How Helm Solves These Challenges

Helm, often called the package manager for Kubernetes, addresses these issues by providing:

1. Charts: The Helm Equivalent of Packages

Helm uses charts, which are like packages that contain:

  • Templates for Kubernetes YAML manifests.
  • Values files (values.yaml) to store dynamic configurations.
  • Dependencies required for the application.

You can install a Helm chart with a single command:

helm install my-release bitnami/apache

    Here:

    • my-release is the name of the deployment.
    • bitnami/apache points to the Bitnami repository that contains the chart.

    2. Templating for Dynamic Configurations

    • Helm allows us to define templates for YAML files.
    • These templates use variables that can be dynamically replaced based on the environment.
    • Example: We can define a values.yaml file that specifies environment-specific parameters.

    3. Chart Repositories and Reusability

    • Helm charts can be stored in public or private repositories, making sharing and reuse easy.
    • Organizations can host their own Helm repositories for internal applications.

    4. Consistency and GitOps Alignment

    • Helm enforces a structured deployment process, preventing manual overrides that cause inconsistencies.
    • Changes are managed through Helm charts and stored in version control systems like GitHub.

    5. Built-in Revision History and Rollbacks

    • Helm maintains revision history for deployments.
    • If an issue arises in a new deployment, we can quickly roll back to a previous version using:
    helm rollback my-release 1

    This command restores the deployment to revision 1.

    6. Upgrading Applications Easily

    When a newer version of an application is available, Helm allows easy upgrades with:

    helm upgrade my-release bitnami/apache

    6. Uninstalling Deployments

    If you need to remove an application, Helm ensures a clean uninstallation:

    helm uninstall my-release

    This removes all associated Kubernetes resources (Deployments, Services, ConfigMaps, Secrets, etc.).

    7. Intelligent Resource Ordering

    • Kubernetes requires certain resources (like ConfigMaps and Secrets) to be created before Deployments and Services.
    • Helm automatically determines the correct order and deploys resources accordingly.

    8. Lifecycle Hooks for Custom Tasks

    • Helm allows execution of hooks at different lifecycle events (installation, upgrade, rollback, etc.).
    • Example: A hook can be used to seed a database before starting the application.

    9. Security and Chart Verification

    • Helm supports cryptographic signing of charts to verify their integrity.
    • This prevents unauthorized tampering with Helm charts downloaded from repositories.

    Summary

    Managing Kubernetes applications manually using multiple YAML files can be inefficient, error-prone, and difficult to track. Helm simplifies this process by:

    • Reducing redundancy with templating.
    • Enforcing consistency through version-controlled Helm charts.
    • Providing revision history for easy rollbacks.
    • Enabling quick installation, upgrades, and uninstallation with simple commands.
    • Automatically managing the order of resource creation.
    • Allowing lifecycle hooks for custom automation.
    • Ensuring security through chart verification.

    In the next sections, we will explore how to install Helm, create a Helm chart, and deploy a microservice application using Helm in a Kubernetes cluster.