Learn Helm Chart - Pre-Requisites Skill & Setup Environment

#Introduction

Welcome to the Learn Helm Chart series! This series will take you from zero to building production-grade Helm charts and managing applications on Kubernetes professionally. There are 30 episodes that build on each other: prerequisites and environment setup, the history of why Helm was born, Helm 3 architecture, CLI basics, release management, upgrade and rollback, values configuration, building your own charts, Go templates, dependencies, hooks, JSON Schema, testing, documentation, packaging, repositories, OCI registry, all the way to CI/CD integration and GitOps.

Why is Helm so important? Kubernetes handles container orchestration brilliantly, but it introduces a new problem: managing dozens of YAML files by hand. A production application is not a single Deployment — it consists of Deployments, Services, ConfigMaps, Secrets, Ingresses, HorizontalPodAutoscalers, and ServiceAccounts that must stay consistent across dev, staging, and production environments. Helm wraps all of this into a single package that can be installed, upgraded, and rolled back with one command. A DevOps Engineer who doesn't know Helm is like a frontend developer who writes all styling as inline styles: it works, but it's impossible to maintain at team scale and system scale.

Episode 0 is your roadmap. Before touching Helm, we make sure of five things: (1) the Kubernetes skills you must master, (2) kubectl habits that are comfortable at your fingertips, (3) an understanding of YAML as the language of manifests, (4) a package manager mental model that will make Helm feel familiar, and (5) a Kubernetes cluster with kubectl and the Helm CLI already verified. Every later episode assumes this foundation is solid. Let's begin.

#Kubernetes Skills You Must Master

Helm does not replace Kubernetes — it sits on top of Kubernetes. Everything Helm installs is ultimately an ordinary Kubernetes resource: Pod, Deployment, Service, and so on. If you don't understand what Helm creates, you won't be able to read helm get manifest output, debug install failures, or judge whether a chart is safe to use. These are the resources you must understand before moving on.

Understand not just the definitions but the relationships between resources: Ingress → Service → Deployment → Pod → ConfigMap/Secret. This is the flow you'll see in almost every Helm chart. Try building it yourself in your lab: an nginx Deployment that reads index.html from a ConfigMap, exposed through a Service, then protected by an Ingress. If you can explain that flow without opening your notes, your foundation is solid.

#kubectl Habits That Should Be Second Nature

Helm bridges you to the Kubernetes API server — but kubectl is your right-hand tool for verification. When Helm says "release installed," you don't take it at face value; you verify with kubectl. Master the following commands until they flow without thinking:

Most debugging in this series follows the same pattern: helm install → fails → kubectl get pods → Pod is CrashLoopBackOff → kubectl describe pod → read the Events section → kubectl logs → find the root cause. If this flow still feels foreign, practice it in this episode first.

#YAML: The Base Language of Kubernetes Manifests

Every Kubernetes resource is written in YAML — and every Helm chart ultimately renders YAML. Two YAML concepts you must master: mapping (key-value pairs, marked by indentation) and sequence (lists, marked by dashes). Indentation is everything — YAML doesn't support tabs, and two spaces is the Kubernetes convention.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  labels:
    app: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

Note the structure: apiVersion, kind, metadata, and spec are mappings. Under containers there is a sequence (dashes), and each item is a mapping. Later, when Helm renders templates, the final output will look exactly like this — the difference is that the changing parts (name, image, replica count) come from template variables instead of being written by hand.

#Mental Model: Package Manager & Templating

You're probably already familiar with npm for JavaScript or pip for Python. Helm is built on the same mental model — and this is the key to building your understanding quickly:

• Chart ≈ package — a collection of files (manifests + metadata) that can be distributed, like a .tgz package in npm.
• Repository ≈ npm / PyPI registry — where charts are stored and fetched.
• Release ≈ installation — one chart installed in the cluster under a unique name; it can be uninstalled without affecting the source chart.
• Chart version ≈ semantic version — follows the MAJOR.MINOR.PATCH rules.
• Values ≈ configuration variables at install time — like configuration options when running an install command.

One important difference from npm: npm manages libraries executed inside a program; Helm manages declarative infrastructure — YAML files sent to the Kubernetes API server. But the mental pattern is identical: one command to install, one command to upgrade, one command to uninstall, and a "registry" for sharing packages.

#Setting Up Your Kubernetes Cluster

You need a Kubernetes cluster for practice. For this series, a local cluster is more than enough — even better, because it's cheap, fast, and safe to destroy over and over. Your options:

Recommendation for this series: Minikube for beginners, or Kind if you're already comfortable with Docker. Both run real Kubernetes (not a simulation) — every Helm command in this series works identically on a local cluster and in production.

#Installing & Verifying kubectl

kubectl is the official Kubernetes CLI — your first bridge to the cluster. Installation via the official binary is the most portable, but package managers are also valid:

Option 1: Official binary (Linux)Option 2: Package manager (Ubuntu/Debian)

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client

sudo apt update && sudo apt install -y kubectl
kubectl version --client

Note that kubectl version has two parts of output: Client Version and Server Version. Right after installation, the server part is missing because the cluster hasn't been created yet. What matters right now: Client Version shows up and its version is at most one minor version apart from the server version later. Once the cluster is ready, verify the connection:

Verify connection to cluster

kubectl version
kubectl cluster-info
kubectl get nodes

kubectl cluster-info output shows the API server URL, and kubectl get nodes shows nodes that are Ready — the official sign that your kubectl can talk to the cluster.

#Installing & Verifying the Helm CLI

Helm 3 is a single client binary with no server daemon — once installed, it's ready to use immediately. The fastest and most widely used method on a local machine is the official installer script (full coverage of all methods is in episode 3):

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
helm version

helm version shows the Helm client version along with the Go version used to build it, for example version.BuildInfo{Version:"v3.16.0"}. Make sure the major number is 3 — this entire series uses Helm 3. Unlike kubectl, Helm has no "server version" because it talks directly to the Kubernetes API server using the same kubeconfig as kubectl.

#Supporting Tools: kubeconform, jq, Git, and an Editor

Besides kubectl and Helm, prepare the following supporting tools:

• kubeconform — a validator of Kubernetes manifests against official schemas. We'll use it later to validate Helm render output before applying it to the cluster. Installation: go install github.com/yannh/kubeconform/cmd/kubeconform@latest or a binary from the GitHub releases page.
• jq — a JSON processor for the terminal, used to parse -o json output from kubectl or Helm. Installation: sudo apt install -y jq.
• Git — required for chart versioning and following team workflows. Make sure git version responds.
• Editor: VS Code with the Helm and YAML extensions (add the Kubernetes schema for manifest autocompletion), or Neovim with helm-language-server and yaml-language-server.

kubeconform -v
jq --version
git --version
echo "Tools OK"

#Environment Verification: Your First Pod in the Cluster

This is this episode's "stress test": run your first pod in the cluster and make sure everything works end to end — kubectl talks to the API server, the scheduler places the pod, kubelet pulls the image and runs the container.

Run your first pod and observe

kubectl create deployment hello-k8s --image=nginx:1.27
kubectl get pods
kubectl port-forward deployment/hello-k8s 8080:80

Open http://localhost:8080 — if the nginx welcome page appears, your environment is officially ready for the entire series. kubectl port-forward is a skill you'll use repeatedly in the following episodes to access applications inside the cluster without exposing them publicly. When you're done, clean up the lab:

kubectl delete deployment hello-k8s

#Common Pitfalls

1. Using kubectl before the cluster is ready. The error The connection to the server localhost:8080 was refused. Fix: create the cluster first (minikube start or kind create cluster), then check kubectl config current-context.
2. The Pod/Deployment/Service concepts are still fuzzy. If you don't understand the difference, all the later debugging episodes will feel like puzzles. Strengthen this with practice before moving on.
3. Skipping verification. Not running your first pod means you don't know whether the environment actually works. Never continue the series with an untested environment.
4. Minimum RAM not met. The local cluster will crash often. Increase the Minikube VM RAM allocation with minikube start --memory 4096 or add machine RAM.
5. Ignoring jq and kubeconform. Both are productivity extensions: kubeconform saves you from YAML field typos; jq saves you from reading giant JSON output by hand.

#Conclusion

In episode 0 you've secured five foundations: Kubernetes skills (Pod, Deployment, Service, ConfigMap, Secret, Namespace, Ingress along with their flow), kubectl habits (get, describe, apply, logs, port-forward), YAML understanding as the language of manifests, the package manager mental model (Chart ≈ package, Repository ≈ registry, Release ≈ installation), and a local cluster with verified kubectl and Helm CLI — proven by your first pod running successfully.

Points to take away:

• Helm sits on top of Kubernetes — everything it installs is still an ordinary Kubernetes resource.
• kubectl is the verification tool, Helm is the packaging tool. You must master both.
• YAML is the language of manifests; indentation is everything.
• The npm/pip mental model speeds up understanding of Chart, Repository, and Release.
• An unverified environment is a ticking time bomb in this series.

Remember, the Learn Helm Chart series consists of 30 episodes that build on each other. Episode 0 is the first brick — and you've just laid it perfectly. In the next episode, episode 1, we step back for a moment to understand the history, background, and why Helm was born: the deployment challenges in Kubernetes, the evolution from Helm 1 to Helm 3, the story of Tiller being removed because of security issues, and an honest comparison of Helm against Kustomize and bare kubectl. See you in episode 1, and happy building your Kubernetes lab!