Skip to main content
Mapagam

Understanding Helm Fundamentals

1. Understanding Helm Architecture

Component Description Role
Helm Client (helm) Command-line interface for interacting with Kubernetes Manages chart installation, upgrades, and deletion
Kubernetes API Server Core Kubernetes control plane component Stores cluster state and manages resources
Tiller (Deprecated) Server-side component of Helm v2 Installs charts into Kubernetes clusters (removed in Helm v3)
Chart Repository Storage for Helm charts (local or remote) Stores and serves chart packages
Release Manager Tracks installed releases in Kubernetes Manages versioning and rollback capabilities
Note: Helm v3 removed Tiller, making the architecture more secure and simpler by running entirely client-side.

Example: Helm Chart Structure


charts/
├── myapp/
│   ├── Chart.yaml
│   ├── values.yaml
│   ├── templates/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── _helpers.tpl
│   └── charts/

2. Understanding Chart Concept

Property Description Example
apiVersion API version of the chart "v2"
name Name of the chart "nginx"
version Chart version (semver) "1.2.3"
appVersion Version of the application being deployed "1.18.0"
description Short description of the chart "A Helm chart for NGINX"
home Home page URL of the chart "https://nginx.org"
maintainers List of chart maintainers [{name: "John Doe", email: "john@example.com"}]

Example: Chart.yaml structure

apiVersion: v2
name: nginx
version: 1.2.3
appVersion: "1.18.0"
description: A Helm chart for NGINX
home: https://nginx.org
maintainers:
  - name: John Doe
    email: john@example.com

3. Understanding Release Concept

Property Description Notes
release.name Name of the release Must be unique within a namespace
release.namespace Kubernetes namespace where the release is installed Defaults to the current namespace
release.version Version of the release (incremented on upgrades) Used for rollback operations
release.status Current status of the release (deployed, failed, superseded) Indicates health and state of the release

Example: Release Status Check

helm status my-release
Note: A release is a specific instance of a chart, uniquely identified by its name and namespace.
Warning: Reusing a release name in the same namespace will overwrite the existing release.

Release Lifecycle

  • Install: Create a new release from a chart
  • Upgrade: Update an existing release to a new version
  • Rollback: Revert to a previous release version
  • Delete: Remove the release from the cluster

4. Understanding Repository Concept

Aspect Description Details
Repository Type Official Helm Chart Repositories Hosted on https://charts.helm.sh/stable and other official sources
Repository Type Private Helm Chart Repositories Can be hosted internally or on cloud providers (e.g., AWS S3, GCS, Azure Blob Storage)
Repository URL Format Public Repositories https://<repo-url>
Repository URL Format Private Repositories https://<repo-url> with authentication (e.g., basic auth, token)
Chart Storage Chart Archives Charts are stored as .tgz files (tar.gz) containing chart metadata and templates
Chart Index Index.yaml Contains metadata about available charts, versions, and dependencies

Example: Adding a Helm Repository

helm repo add stable https://charts.helm.sh/stable
helm repo update

Example: Listing Repositories

helm repo list
Note: Helm repositories are used to store and distribute charts. They can be public or private, and support various authentication methods for secure access.

5. Understanding Values Hierarchy

Level File Description
Chart.yaml values.yaml Default values defined in the chart's values.yaml file.
Values File values.yaml Override default values with custom values.yaml file.
Command Line --set Set individual values via command line using --set key=value.
Values File Override values.yaml Override values from values.yaml with another values.yaml file using -f.

Example: Setting Values Hierarchy

helm install my-release ./my-chart --set image.tag=v1.2.3 -f production-values.yaml
Note: The order of precedence is: --set > -f > values.yaml in chart.

6. Understanding Template Rendering

Helm uses the Go template engine for rendering templates. Templates are processed during chart installation or upgrade, substituting values from values.yaml and the Chart.yaml metadata.

Template Type Description Example
Go Template Syntax Core templating engine used by Helm {{ .Values.replicaCount }}
Template Functions Predefined functions to manipulate data {{ .Release.Name | quote }}
Template Actions Code blocks that execute logic {{- if .Values.service.enabled -}}

Example: Basic Template Rendering

apiVersion: v1
kind: Service
metadata:
  name: {{ include &#34;myapp.fullname&#34; . }}
spec:
  selector:
    app: {{ include &#34;myapp.name&#34; . }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.targetPort }}

Example: Conditional Rendering

{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.service.name }}
spec:
  ports:
    - port: {{ .Values.service.port }}
{{- end }}
Note: Template rendering happens in the Helm client, not on the Kubernetes cluster. Values are substituted before resources are sent to Kubernetes.

7. Understanding Chart Lifecycle

Helm Chart Lifecycle Overview

  1. Creation: Author creates a chart structure with templates, values, and metadata.
  2. Versioning: Chart is versioned using semantic versioning (e.g., 1.2.3).
  3. Package: Chart is packaged into a .tgz file using helm package.
  4. Repository: Packaged chart is stored in a Helm repository (local or remote).
  5. Installation: Chart is installed to a Kubernetes cluster using helm install.
  6. Upgrading: Chart is upgraded to a new version using helm upgrade.
  7. Rollback: If needed, chart can be rolled back to a previous version using helm rollback.
  8. Uninstalling: Chart is removed from the cluster using helm uninstall.
Phase Description Command Notes
Creation Initial chart structure setup helm create my-chart Creates directory structure with templates, values, and metadata
Packaging Compresses chart into .tgz format helm package my-chart Validated chart before publishing
Installation Deploys chart to Kubernetes cluster helm install my-release my-chart Uses values.yaml or custom values
Upgrade Applies new chart version or values helm upgrade my-release my-chart Supports rollback via --history-max
Rollback Reverts to a previous release helm rollback my-release <revision> Reuses previous chart version
Uninstall Removes chart from cluster helm uninstall my-release Can delete all resources or keep them
Note: Helm charts support hooks that run at specific lifecycle events (e.g., pre-install, post-delete).

Example: Chart Versioning

apiVersion: v2
name: my-app
description: A Helm chart for my application
version: 1.2.3
appVersion: "1.0.0"

8. Understanding Helm Three-Way Merge

Helm uses a three-way merge strategy to reconcile changes between the desired state (chart values), the live state (current Kubernetes resources), and the base state (previous version of the chart). This ensures safe updates and prevents unintended overwrites.

Strategy Description Use Case
Three-Way Merge Merges changes from the chart, live resources, and base state to compute a new desired state. Safe updates that preserve user modifications to resources.
Merge Strategy Uses helm upgrade to apply changes using the merge logic. Updating existing releases with new chart versions or values.

Example: Merge Conflict Resolution

When a resource is modified outside of Helm (e.g., manually changed in Kubernetes), Helm attempts to merge the changes. If conflicts occur, Helm will prompt for resolution or use a conflict resolution strategy.

helm upgrade my-release ./my-chart --set config.key=value
Note: Helm's merge logic does not support all Kubernetes resource types. Some resources (e.g., Service or Ingress) may require manual handling to avoid unintended overwrites.

Three-Way Merge Process

  • Base State: The previous version of the chart or release.
  • Live State: Current Kubernetes resources managed by the chart.
  • Desired State: The new chart or updated values to apply.

9. Understanding Chart API Versions

API Version Description Notes
v1 Legacy chart format Deprecated as of Helm 3, use v2 or later
v2 Chart format introduced in Helm 2 Supports dependencies and sub-charts
v3 Chart format introduced in Helm 3 Default and recommended version, no more Chart.yaml schema changes
Note: Helm 3 removed the Tiller component and changed chart API versions to align with Kubernetes standards.

10. Comparing Helm vs Kustomize

Helm vs Kustomize: Key Differences

  • Helm is a package manager for Kubernetes, using templates and values files to deploy applications. Kustomize is a configuration management tool that modifies Kubernetes manifests directly without templates.
  • Helm uses a chart-based approach with Chart.yaml, values.yaml, and templates/ directory. Kustomize uses a kustomization.yaml file to overlay and customize existing manifests.
  • Helm supports dependency management via requirements.yaml. Kustomize does not have built-in dependency management but supports overlays for customization.
  • Helm provides a rich ecosystem of pre-built charts from repositories like https://charts.helm.sh/stable. Kustomize does not provide a chart repository but works with any Kubernetes manifest.
  • Helm is ideal for deploying complex, multi-component applications with versioning and rollback capabilities. Kustomize is better suited for customizing existing Kubernetes manifests and managing multiple environments with minimal changes.
Feature Helm Kustomize
Template Engine Helm templates with Go template syntax Direct YAML manipulation and overlays
Configuration Values files (values.yaml) Kustomization files (kustomization.yaml)
Dependency Management Supports requirements.yaml No built-in support; use overlays or external tools
Chart Repository Official repositories like https://charts.helm.sh/stable No chart repository; works with any manifest
Rollback Capability Yes, with helm rollback No built-in rollback; requires manual or script-based approach
Use Case Complex deployments with versioning and reuse Customizing existing manifests, environment-specific changes

Example: Helm Chart Structure

my-app/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml

Example: Kustomize Structure

my-app/
  kustomization.yaml
  deployment.yaml
  service.yaml

Was this article helpful?

Related Cheat Sheets