Creating custom Helm charts in Kubernetes - Mechanics & Internals

Overview - Creating custom Helm charts

What is it?

Creating custom Helm charts means making your own packages that describe how to install and manage applications on Kubernetes. Helm charts are like blueprints that tell Kubernetes what resources to create and how to configure them. Custom charts let you package your specific app setup so you can easily deploy it anywhere. This helps automate and standardize app deployment on Kubernetes clusters.

Why it matters

Without custom Helm charts, deploying apps on Kubernetes would be manual, error-prone, and inconsistent. You would have to write and run many commands or YAML files every time you want to install or update your app. Custom charts solve this by bundling all deployment details into reusable, versioned packages. This saves time, reduces mistakes, and makes it easy to share and update apps across teams and environments.

Where it fits

Before learning custom Helm charts, you should understand basic Kubernetes concepts like pods, services, and deployments, plus how YAML files define resources. After mastering custom charts, you can learn advanced Helm features like chart dependencies, hooks, and creating Helm repositories for sharing charts.

Mental Model

Core Idea

A custom Helm chart is a reusable, versioned package that bundles Kubernetes resource templates and configuration to automate app deployment.

Think of it like...

Creating a custom Helm chart is like designing a recipe book for cooking a specific dish. The recipe lists ingredients (resources) and steps (configuration) so anyone can make the dish the same way every time.

┌───────────────────────────────┐
│        Custom Helm Chart       │
├───────────────┬───────────────┤
│ Chart.yaml    │ Metadata info │
│ values.yaml   │ Configurable  │
│               │ settings      │
│ templates/    │ Kubernetes    │
│               │ resource YAML │
└───────────────┴───────────────┘

Build-Up - 7 Steps

1

Foundation

Understand Helm and Kubernetes Basics

Concept: Learn what Helm is and how it works with Kubernetes to manage app deployments.

Helm is a tool that helps you install and manage applications on Kubernetes by using charts. Charts are packages that contain all the resource definitions needed to run an app. Kubernetes uses YAML files to define resources like pods and services. Helm simplifies this by templating these YAML files and managing versions.

Result

You know Helm is a package manager for Kubernetes and that charts bundle app deployment details.

Understanding Helm's role as a package manager clarifies why charts are useful for automating Kubernetes deployments.

2

Foundation

Explore Helm Chart Structure

Concept: Learn the basic files and folders that make up a Helm chart.

A Helm chart has a folder with these key parts: - Chart.yaml: metadata like name and version - values.yaml: default configuration values - templates/: folder with Kubernetes YAML templates These parts work together to define what resources Helm will create and how they can be customized.

Result

You can identify and explain the purpose of the main files in a Helm chart.

Knowing the chart structure helps you organize your app deployment files clearly and reuse them easily.

3

Intermediate

Create Basic Templates with Placeholders

🤔Before reading on: do you think Helm templates are static YAML files or dynamic files with placeholders? Commit to your answer.

Concept: Use Go templating syntax to add placeholders in YAML files that Helm replaces with real values during deployment.

In the templates/ folder, you write YAML files with placeholders like {{ .Values.image.tag }}. When you run Helm install, Helm replaces these placeholders with values from values.yaml or command line overrides. This lets you customize deployments without changing the templates themselves.

Result

Your chart can deploy apps with configurable settings like image tags or replica counts.

Understanding templating unlocks the power of Helm to create flexible, reusable deployment packages.

4

Intermediate

Use values.yaml for Configuration Defaults

🤔Before reading on: do you think values.yaml is mandatory or optional in a Helm chart? Commit to your answer.

Concept: values.yaml holds default settings that templates use, allowing users to customize deployments easily.

You define default values like replicaCount: 3 or image.tag: "1.0" in values.yaml. Templates reference these with {{ .Values.replicaCount }}. Users can override these defaults by passing their own values files or command line options during install or upgrade.

Result

Your chart supports easy customization without editing templates directly.

Separating configuration from templates makes charts easier to maintain and share.

5

Intermediate

Package and Install Your Custom Chart

Concept: Learn how to bundle your chart and deploy it on a Kubernetes cluster using Helm commands.

Use helm package to create a .tgz archive of your chart folder. Then use helm install myapp ./mychart-0.1.0.tgz to deploy it. Helm reads your templates and values, generates Kubernetes manifests, and applies them to the cluster. You can also upgrade or uninstall the chart with Helm commands.

Result

Your app is running on Kubernetes as defined by your custom chart.

Knowing how to package and install charts completes the deployment cycle and enables sharing.

6

Advanced

Add Helpers and Conditional Logic

🤔Before reading on: do you think Helm templates can include reusable snippets and conditions? Commit to your answer.

Concept: Use named templates (helpers) and if/else logic to make charts more modular and adaptable.

Define reusable snippets in templates/_helpers.tpl using {{- define "mychart.name" }}...{{- end }}. Call them with {{ include "mychart.name" . }}. Use {{- if .Values.enabled }} ... {{- end }} to conditionally create resources. This reduces duplication and supports complex deployment scenarios.

Result

Your chart is cleaner, easier to maintain, and supports optional features.

Mastering helpers and conditionals lets you build professional-grade charts that adapt to many use cases.

7

Expert

Manage Chart Dependencies and Repositories

🤔Before reading on: do you think Helm charts can include other charts as dependencies? Commit to your answer.

Concept: Charts can depend on other charts, and you can host charts in repositories for sharing and version control.

Define dependencies in Chart.yaml under dependencies: with name, version, and repository URL. Use helm dependency update to fetch them. Host your charts in Helm repositories (HTTP servers with index.yaml). Users can add your repo with helm repo add and install charts from it. This enables modular apps and easy distribution.

Result

You can build complex apps from smaller charts and share your charts with others professionally.

Understanding dependencies and repos is key to scaling Helm usage in teams and production.

Under the Hood

Helm works by combining templates with configuration values to generate Kubernetes manifest files. It uses Go's templating engine to replace placeholders and evaluate logic in templates. When you run helm install or upgrade, Helm sends the generated manifests to Kubernetes API server, which creates or updates resources. Helm also tracks releases in its storage (ConfigMaps or Secrets) to manage lifecycle and rollbacks.

Why designed this way?

Helm was designed to simplify Kubernetes app deployment by packaging complex YAML files into reusable charts. Using templating and values separates configuration from code, making charts flexible. Tracking releases allows safe upgrades and rollbacks. Alternatives like raw kubectl apply require manual YAML management, which is error-prone and hard to scale.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│  Chart Files  │─────▶│ Helm Template │─────▶│ Kubernetes    │
│ (YAML + tpl)  │      │ Engine        │      │ API Server    │
└───────────────┘      └───────────────┘      └───────────────┘
        │                      │                      │
        ▼                      ▼                      ▼
  values.yaml           Rendered Manifests       Created Resources
  (Config)              (YAML files)             (Pods, Services, etc.)

Myth Busters - 4 Common Misconceptions

Quick: Do you think Helm charts are only for installing apps once, not for upgrades? Commit yes or no.

Common Belief: Helm charts are just for initial app installation and not meant for upgrades or rollbacks.

Reality: Helm tracks releases and supports upgrades and rollbacks, making it a full lifecycle manager for Kubernetes apps.

Why it matters: Ignoring Helm's upgrade features leads to manual, error-prone updates and lost ability to revert changes safely.

Quick: Do you think values.yaml must contain all configuration and cannot be overridden? Commit yes or no.

Common Belief: All configuration must be set in values.yaml and cannot be changed during install or upgrade.

Reality: Users can override values.yaml settings by passing custom values files or command line options at install or upgrade time.

Why it matters: Believing this limits flexibility and forces editing charts for every environment, increasing errors.

Quick: Do you think Helm templates are static files without logic? Commit yes or no.

Common Belief: Helm templates are just static YAML files without any programming or logic capabilities.

Reality: Helm templates use Go templating language allowing conditionals, loops, and reusable snippets for dynamic manifests.

Why it matters: Missing this means underusing Helm's power to create adaptable and maintainable charts.

Quick: Do you think Helm charts must be stored only locally and cannot be shared? Commit yes or no.

Common Belief: Helm charts are only local folders and cannot be shared or hosted remotely.

Reality: Helm supports chart repositories, allowing charts to be hosted, versioned, and shared over HTTP servers.

Why it matters: Not knowing this limits collaboration and professional distribution of charts.

Expert Zone

1

Helm's release storage can be configured to use Secrets or ConfigMaps, affecting security and cluster resource usage.

2

Chart hooks let you run Kubernetes jobs at specific lifecycle events, but misuse can cause deployment failures or stuck releases.

3

Using 'required' fields in values.yaml with validation in Helm 3.7+ prevents silent misconfigurations early.

When NOT to use

Avoid Helm charts for very simple or one-off Kubernetes resources where plain YAML or Kustomize is faster. For complex multi-cluster or GitOps workflows, tools like ArgoCD or Flux may be better suited.

Production Patterns

In production, teams use private Helm repositories with access control, automated CI pipelines to lint and package charts, and semantic versioning for chart releases. Charts often include health checks, resource limits, and support for multiple environments via values files.

Connections

Package Managers (e.g., apt, npm)

Helm charts are Kubernetes-specific package managers similar to how apt or npm manage software packages.

Understanding general package managers helps grasp Helm's role in bundling, versioning, and distributing Kubernetes apps.

Infrastructure as Code (IaC)

Helm charts are a form of IaC, describing infrastructure declaratively for automation.

Knowing IaC principles clarifies why templating and versioning in Helm improve reliability and repeatability.

Recipe Books in Cooking

Both Helm charts and recipe books provide step-by-step instructions and ingredients to produce consistent results.

This cross-domain view highlights the importance of clear, reusable instructions for complex processes.

Common Pitfalls

#1 Hardcoding values directly in templates instead of using values.yaml.

Wrong approach:

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: myimage:1.0

Correct approach:

apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: app
image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

Root cause:

Not separating configuration from templates reduces flexibility and forces code changes for every deployment variation.

#2 Ignoring Helm's release management and manually deleting Kubernetes resources.

Wrong approach:

kubectl delete deployment myapp
kubectl delete service myapp

Correct approach:

helm uninstall myapp

Root cause:

Not using Helm commands breaks release tracking, causing Helm to lose sync and complicate upgrades or rollbacks.

#3 Using complex logic directly in templates making them hard to read and maintain.

Wrong approach:

{{- if and (eq .Values.env "prod") (gt .Values.replicas 2) }}
# complex nested logic
{{- end }}

Correct approach:

Define helper templates in _helpers.tpl for complex logic and call them in main templates for clarity.

Root cause:

Mixing complex logic in main templates reduces readability and increases risk of errors.

Key Takeaways

Custom Helm charts package Kubernetes app deployments into reusable, configurable blueprints.

Separating templates from configuration values enables flexible and consistent deployments across environments.

Helm's templating language supports dynamic manifests with conditionals and reusable snippets for maintainability.

Charts can depend on other charts and be shared via repositories, enabling modular and collaborative workflows.

Using Helm's release management ensures safe upgrades, rollbacks, and lifecycle tracking of Kubernetes applications.