Helm

Helm is an open-source package manager for Kubernetes that uses charts to install, configure, upgrade, and roll back applications with single commands.

Table of Contents

Table of Contents

What Does Helm Mean?

Helm is an open-source package manager for Kubernetes. It simplifies deploying, configuring, and managing complex applications.

Helm uses charts. A chart is a packaged set of templates, configuration values, and dependencies. It holds everything needed to deploy an app to a cluster.

Teams do not need to apply many YAML files by hand. They install, upgrade, or roll back whole applications with a single command. Charts also make configurations easy to share across teams and environments.

Helm is often called the "apt" or "Homebrew" of Kubernetes. It streamlines installation and maintenance for developers, operators, and DevOps engineers.

Helm Architecture and Components

Since Helm 3, Helm is a client-only tool. It talks directly to the Kubernetes API and uses your existing cluster permissions.

  • Helm CLI: runs commands to manage repositories, installs, and upgrades.
  • Charts: packages of templates, values files, and metadata that define an app.
  • values.yaml: default settings that users override per environment without editing templates.
  • Chart.yaml: metadata such as chart version, app version, dependencies, and maintainers.
  • Templates: Go templates that render Kubernetes manifests from the supplied values.

Helm vs. Plain Kubernetes Manifests

Aspect Helm charts Plain YAML manifests
Install One command for the whole app Apply each file in order
Per-environment config Override values files Copy and edit files
Versioning Chart and release versions Manual tracking in Git
Rollback helm rollback to any revision Reapply old files by hand
Sharing Publish to chart repositories Share raw files

Why Helm Matters in Kubernetes and Testing

  • Simpler deployment: bundles all configuration into one installable package.
  • Consistency: makes deployments repeatable across environments and clusters.
  • Automation: fits easily into CI/CD pipelines for automated releases.
  • Maintainability: updates and rollbacks happen without manual reconfiguration.
  • Faster onboarding: ready-made charts deploy tools like Prometheus, Grafana, or Testkube.

In testing, Helm lets teams spin up test environments, dependencies, and supporting services on demand. Each test run can then mirror production more closely.

Helm Chart Repositories

  • Artifact Hub: hosts thousands of community charts for popular apps and services.
  • Private repositories: teams use Harbor, ChartMuseum, OCI registries, or cloud storage for internal charts.
  • Multiple sources: one Helm setup can pull from public and private repositories.
  • Semantic versioning: teams pin exact chart versions or move to newer releases deliberately.
  • Catalog commands: search, update, and maintain chart catalogs from the CLI.

Helm Release Management

Helm tracks each deployment as a release with a revision history:

  • Revisions: every helm install or helm upgrade creates a new revision you can roll back to.
  • helm list: shows releases in a namespace with status, chart version, and update time.
  • Stored state: release data is saved as Kubernetes Secrets, so it survives client failures.
  • helm history: shows configuration changes across revisions.
  • Atomic upgrades: the --atomic flag rolls back a failed upgrade automatically.

Common Challenges with Helm

  • Version drift: clusters may run slightly different chart versions.
  • Complex templating: managing dynamic values and secrets across environments gets hard.
  • Dependency management: charts that depend on other charts add upgrade complexity.
  • Security concerns: poorly maintained third-party charts can bring vulnerabilities or misconfigurations.
  • Limited visibility: failed releases are hard to trace without monitoring and logging.

Helm Best Practices for Production

  • Version your values: keep values files in Git next to app code.
  • Preview changes: use the helm diff plugin before upgrades.
  • Validate in CI: lint charts and check value schemas before deploying.
  • Name releases clearly: consistent names make apps easy to find across clusters.
  • Set resources: define requests and limits in chart values to avoid contention.
  • Audit regularly: find outdated dependencies and vulnerabilities in charts.

Helm Security Considerations

  • Verify chart sources: check signatures and review chart contents before installing.
  • Protect secrets: never store plain-text secrets in values files. Use an external secrets operator or sealed secrets.
  • Limit access: use RBAC to control who can install, upgrade, or delete releases in each namespace.
  • Restrict images: use pull policies and registry rules to block untrusted images.
  • Scan charts: scan dependencies and base images for vulnerabilities before production.

Real-World Examples

  • Observability stack: a DevOps engineer deploys Prometheus, Grafana, and Loki with Helm to standardize monitoring.
  • Test environments: a QA team uses Helm to spin up isolated environments with microservices, databases, and mocks.
  • Platform parity: a platform team manages versioned Testkube installs with Helm to keep staging and production aligned.
  • Community sharing: an open-source contributor publishes a chart for a reusable internal testing tool.

A B2B SaaS Example

Picture a cybersecurity SaaS company that needs a full copy of its stack for each integration test run. Hand-written manifests took a day to update for every new service.

The team packages the stack as a Helm chart with a small values file per test scenario. Spinning up a fresh environment becomes one command, and teardown is just as fast.

Our Perspective: Values Files Are Your Real Configuration

Teams often treat values files as an afterthought next to the chart. In practice, the values file is what makes staging different from production.

Review values changes as carefully as code changes. Most Helm surprises come from a value nobody noticed changing.

How Testkube Uses Helm

Testkube provides an official Helm chart to simplify installation and upgrades. With Helm, users can:

  • Deploy quickly: install Testkube with a few commands.
  • Customize: pass values for namespaces, storage, secrets, and integrations.
  • Upgrade or roll back: move between Testkube versions without reapplying complex manifests.
  • Automate setup: include the Testkube chart in automated cluster provisioning or GitOps workflows.
  • Stay consistent: run the same Testkube version in dev, staging, and production.

Here is a typical install using the official chart repository:

helm repo add kubeshop https://kubeshop.github.io/helm-charts
helm repo update
helm install testkube kubeshop/testkube \
  --namespace testkube --create-namespace \
  -f my-values.yaml

This makes Helm the preferred installation method for many Testkube users. It cuts setup time and simplifies ongoing management.

Frequently Asked Questions (FAQs)

What is a Helm chart?

A Helm chart is a packaged set of templates and default values that defines how to install and configure a Kubernetes application.

How do I install Testkube using Helm?

Add the chart repository with helm repo add kubeshop https://kubeshop.github.io/helm-charts. Then run helm install testkube kubeshop/testkube with your namespace and values file.

Can Helm be used in CI/CD pipelines?

Yes. Helm fits into CI/CD workflows for automated deployments, upgrades, and test environment setup.

Do I need to know Kubernetes manifests to use Helm?

Not necessarily. Helm hides most manifest complexity, though basic Kubernetes knowledge helps when you customize chart values.

What is the difference between Helm 2 and Helm 3?

Helm 3 removed the server-side component called Tiller and uses Kubernetes RBAC directly. It also added three-way merge patches and better namespace handling.

How do I debug a failed Helm installation?

Use helm status to check the release and helm get values to see its configuration. Check pod logs with kubectl, and preview manifests with helm install --dry-run --debug.

Related Terms and Concepts