Helm — Package Manager for Kubernetes
SummaryIntroduces Helm as the standard package manager for...
Introduces Helm as the standard package manager for...
Introduces Helm as the standard package manager for Kubernetes. Explains the problem Helm solves — managing complex multi-resource applications as a single unit — and covers the core concepts of charts, releases, values, and repositories. Establishes the mental model for the detailed sections that follow.
Helm — Package Manager for Kubernetes
Deploying a single Pod requires one YAML file. Deploying a production-ready application requires dozens: Deployments, Services, ConfigMaps, Secrets, Ingress rules, ServiceAccounts, RBAC bindings, PersistentVolumeClaims, HorizontalPodAutoscalers. Each resource has its own manifest, and each manifest must be kept in sync with the others. Change the application name, and you update it in fifteen places. Promote from staging to production, and you swap values across every file. Roll back a failed release, and you reconstruct the exact set of manifests that were running before.
This is the problem Helm solves. Helm is the package manager for Kubernetes — it bundles related manifests into a single deployable unit, parameterizes the values that change between environments, and tracks the history of every installation so you can upgrade and roll back with a single command.
Core Concepts
Helm organizes around four concepts:
Chart. A chart is a package. It contains a collection of Kubernetes manifest templates, a default values file, and metadata describing the application. Charts are versioned and can depend on other charts. The bitnami/nginx chart, for example, contains everything needed to deploy nginx: Deployment, Service, ConfigMap, and optional Ingress — all parameterized through values.
Repository. A repository is a server that hosts charts. Public repositories like Bitnami, Artifact Hub, and the ingress-nginx project publish charts for common applications. You add a repository to your local Helm client, and then you can search and install charts from it.
Release. A release is a specific installation of a chart in a cluster. When you run helm install my-nginx bitnami/nginx, Helm creates a release named my-nginx. The release tracks the chart version used, the values applied, and the Kubernetes resources created. You can have multiple releases of the same chart in the same cluster, each with different configuration.
Values. Values are the configuration parameters that customize a chart. Every chart ships with a values.yaml file containing defaults. You override these defaults at install time using --set flags or custom values files. Values flow into the chart’s templates, producing the final Kubernetes manifests that get applied to the cluster.
Helm 3 Architecture
Helm 3 is a client-only tool. There is no server component running inside the cluster — the helm CLI communicates directly with the Kubernetes API server using your kubeconfig credentials. Release metadata is stored as Kubernetes Secrets (by default) in the namespace where the release is installed. This architecture means Helm requires no special cluster setup: if you can run kubectl, you can run helm.
Helm on the CKAD Exam
The CKAD exam allocates roughly 5–10% of its weight to Helm. The exam environment provides Helm pre-installed and may include tasks such as adding a repository, searching for charts, installing a release with custom values, upgrading a release, and rolling back to a previous revision. You will not be asked to author chart templates, but you must be comfortable with the full lifecycle of chart consumption: finding charts, inspecting their configurable values, installing with overrides, and managing releases.
The next two sections cover this lifecycle in detail: first the concepts and inspection commands, then the install-upgrade-rollback workflow.