How to Create Professional Helm Charts for Kubernetes

By /

Helm has emerged as the package manager of choice for Kubernetes, empowering developers to better define, install, configure, and update even complex applications running in containers. This step-by-step guide will teach you how to create robust, production-ready Helm charts from scratch.

By the end, you‘ll be able to build reusable charts that support multiple environments, integrate with CI/CD pipelines, and follow best practices for distribution. Let‘s get charting!

What Makes Helm Charts So Valuable?

Since its inception in 2015 and graduation to a CNCF project in 2021, Helm has quickly become a cornerstone within cloud-native toolchains. But why has it found such fast adoption?

Streamlining Deployments

While Kubernetes provides tremendous flexibility, deploying real-world applications directly with YAMLs or JSON can prove complex:

  • Hundreds of lines required per application
  • Difficult troubleshooting and updates
  • No native package management

Helm alleviates these pains by bundling related Kubernetes resources together as versioned packages called charts. This simplifies sharing and installing applications immensely.

Teams gain better abstractions over infrastructure, allowing them to focus more on deliverying application value vs wrestling with low-level YAML.

Enabling CI/CD Pipelines

In modern infrastructures, code changes rapidly across large, distributed teams. Manually updating hundreds of YAML files becomes unscalable.

Instead, Helm charts integrate beautifully into continuous integration / continuous delivery pipelines (CI/CD). Developers can test and validate changes locally via Helm, then rely on automation to ship charts safely to production.

Versioning ensures it‘s easy to track changes and rollback if needed – a vast improvement over YAML wrangling! Best practices like semantically versioned charts, LTS versions, and automatic testing help teams standardize and remove risk around deployments.

Accelerating Innovation

With these advantages in mind, Helm adoption has skyrocketed across startups and enterprises alike:

Year New Helm Chart Versions
2019 18,000
2020 48,000
2021 Over 70,000

Clearly this tool has struck a chord in streamling Kubernetes application lifecycles. Let‘s explore how you can start benefiting from Helm charts!

Chart Prerequisites

Before writing your first chart, you‘ll want to setup:

1. A Kubernetes Cluster

Charts transform templates to Kubernetes resources, so first you need a cluster. Great options include:

  • Local clusters:
    • Minikube – Single node cluster
    • Kind – Docker container cluster
  • Managed clusters: All major cloud providers like AWS (EKS), GCP (GKE) and Azure (AKS) offer hosted Kubernetes. Handle provisioning for you.
  • On-prem clusters: Leverage Kubernetes tools like k3s or Rancher for self-hosted clusters.

I‘d recommend Minikube or Kind to start. They take just minutes to bootstrap yet emulate real cluster experiences.

2. Helm CLI Installed

Naturally, you‘ll need the helm client somewhere with access to your cluster.

On macOS/Linux I‘d suggest a package manager like Homebrew:

brew install helm

Or grab the latest release directly from GitHub.

Now verify it works:

helm version

Should see client and server versions, meaning helm can talk to Kubernetes.

3. Basic Kubernetes Familiarity

Having experience with Kubernetes primitives will make chart concepts more intuitive. Ensure you understand:

  • Pods
  • Deployments
  • Services
  • Namespaces
  • Role Bindings

No need to be an expert! Just grasp the basics of running containers and networking them together.

With those pillars in place, let‘s start charting!

Scaffolding Your First Helm Chart

Helm includes a handy command for bootstrapping a chart structure from scratch:

helm create my-first-chart

This generates a common template to extend in the my-first-chart directory:

my-first-chart
├── charts
├── Chart.yaml
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   └── tests
└── values.yaml

Let‘s walk through what these critical files provide out of the box!

The Chart.yaml File

The essential Chart.yaml defines metadata like the name, version, and other details about a chart.

For example:

apiVersion: v2
name: my-first-chart
description: A Helm chart for Kubernetes
type: application
version: 0.1.0 
appVersion: 1.0

Helm leverages semantic versioning for charts based on defined versioning guidelines.

Start with version 0.1.0 and increment the version with each change.

Templating Basics with values.yaml

The values file contains default configuration values that templates reference. Override them at install time.

For example, we could add app configuration like:

image: 
  repository: nginx
  tag: stable
  pullPolicy: IfNotPresent

replicas: 1

Then rewrite templates to leverage these variables.

Templating empowers declaring Kubernetes manifests as code for maximum customization!

Customizing Generated Templates

The templates directory houses YAML definitions for Kubernetes objects like:

  • Deployments
  • Services
  • HorizontalPodAutoscalers
  • Ingress routes
  • Secret generators
  • NetworkPolicies
  • and more…

Each renders dynamically based on values.

For example, we could edit deployment.yaml:

spec:
  containers:
    - name: {{ .Chart.Name }} 
      image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
      imagePullPolicy: {{ .Values.image.pullPolicy }}

This injects our values cleanly!

Now we have a valid, configurable chart foundation ready for extension.

Testing Your Chart Locally

Before distributing or upgrading charts, rigorously test changes.

Good news – Helm makes validation a breeze with handy commands:

Linting Your Chart

helm lint checks that the chart structure looks valid:

helm lint my-first-chart

It catches issues like:

  • Invalid YAML formatting
  • Mismatched template delimiters
  • Broken values references

Fix errors until you see:

1 chart(s) linted successfully

Installing Your Chart

More importantly, deploy your chart to verify operation:

helm install my-first-app my-first-chart

Watch it initialize pods:

kubectl get pods -w

When all are Running, the chart deployed smoothly!

Now tweak values and templates until the app launches perfectly based on overrides. That confidence will prove invaluable for production-level charts.

Packaging Charts for Teams

So far we‘ve built and tested a simple single-service chart. But real-world applications often span dozens of microservices or jobs connecting to external services.

How do we package larger distributed applications? Helm enables several best practices:

Supporting Multiple Environments

Teams typically maintain multiple environments like development, staging, and production.

Rather than maintain separate chart copies, use values files to handle environment differences:

  1. Create files like dev-values.yaml, prod-values.yaml
  2. Override namespaces, replica counts, resource limits, etc
  3. Reference values based on the install:
helm install my-app -f dev-values.yaml my-chart/

No chart changes needed across environments!

Configuring Team Standards

Naming conventions and labels often vary organization to organization.

We can parameterize differences using values:

namespaces:
  prod: production
  dev: development

labels: 
  team: {{ .Values.teamPrefix }}-core

Then reference them in templates:

metadata:
  namespace: {{ .Values.namespaces.dev }} 
  labels:
    {{- include "mychart.appLabels" . | nindent 4 }}

Simplifies adhering to team conventions!

Managing Chart Dependencies

Structure large applications into multiple reusable charts. Track requirements in Chart.yaml:

dependencies:
  - name: backend 
    version: "1.0.0"
    repository: "https://charts.myorg.com"

Helm will install nested charts from the repository automatically alongside parent charts!

No need to reinvent the wheel. Share functionality between apps with reusable dependency charts.

Automated Testing Pipelines

To release charts with confidence:

  1. Add Helm unit tests
  2. Check for issues: 
     helm lint 
 helm install --dry-run
  3. If all passes, promote chart through environments with CICD automation
  4. Run integration/smoke testing per environment
  5. Watch metrics and rollback if necessary

Zero-touch pipelines key for scaling complex distributed apps!

Distributing Your Charts

Once tested, share your charts internally or with the community:

Distribution Method Description
Self-hosted Chart Museum Internal helm chart repo server behind auth
Public Chart Repositories Share publicly on sites like ArtifactHub
Git Repository Store charts in git and integrate with CICD

Each environment may prefer different sources. Mix and match distribution to share charts broadly!

Maintaining Chart Sources

Chart museums act as dedicated Helm chart repos. They store different versions and serve charts on-demand to helm clients.

Benefits:

  • Role-based access control
  • Census overview of chart versions
  • Integrate with CI/CD pipelines
  • Caching layers accelerate pulls

ChartMuseum is a popular open-source solution.

For public sharing, submit charts to Kubernetes default repositories like ArtifactHub or domain-specific hubs. Drive community adoption!

Conclusion

That wraps up our guide on effectively authoring and maintaining Helm charts!

We covered:

  • The value Helm delivers in streamlining deployments
  • Common chart customizations to support multiple teams and environments
  • Rigorously testing charts locally and integrating with CICD automation
  • Sharing charts internally and with the broader community

Charts transform deployments from frustrating YAML wrangling to programmable templates. This simplifies integration with pipelines and manages exponential complexity growth in large distributed apps.

Now master packaging, versioning, testing and shipping applications with the flexibility of Helm! Reach out if any questions arise.

Related Posts

Scroll to Top