Kubernetes Deployment Using Helm — A Complete Beginner-Friendly Guide

When deploying applications to Kubernetes, engineers quickly face challenges:

Too many YAML files
Repeated configurations across environments
Manual updates during releases
Hard-to-maintain deployments

Helm solves all of these.

Helm is the package manager for Kubernetes that allows you to deploy applications using reusable, templated, and version-controlled charts.

In this guide, we’ll learn:

What Helm is
Why Helm is used
Helm chart folder structure
How Deployment, Service, and Ingress work together
How to write Helm templates
How to deploy a service using Helm

Let’s get started.

1. What Is Helm?

Helm is a package manager for Kubernetes — similar to apt, yum, or Homebrew.

A Helm chart contains all the Kubernetes YAML files (Deployment, Service, Ingress, ConfigMaps, etc.) packaged into a single reusable template.

✔ Helm solves real problems:

Problem	Helm Solution
Too many YAML files	One reusable chart
Duplicate configs across environments	`values.yaml` overrides
Manual edits	Template-based automation
Risky updates	Versioned upgrades (`helm upgrade`)

Instead of maintaining dozens of YAML files, you maintain only one chart + environment-specific values.

2. Helm Chart Folder Structure

When you run:


helm create myservice

Helm generates this structure:


myservice/
│
├── Chart.yaml            # Chart metadata
├── values.yaml           # Default config values (overridable)
│
├── templates/            # All Kubernetes YAML templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── hpa.yaml
│   ├── _helpers.tpl      # Helper functions
│   └── NOTES.txt
│
└── charts/               # Dependencies (optional)

Let’s break these down.

3. Key Files Explained

✔ Chart.yaml

Metadata about the service:


apiVersion: v2
name: myservice
version: 0.1.0
description: My Backend Service
appVersion: "1.0"

✔ values.yaml

This file holds your environment-specific configuration.


replicaCount: 2

image:
  repository: myregistry/myservice
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

env:
  APP_ENV: "prod"
  LOG_LEVEL: "info"

You can override these for dev, QA, prod using:


helm install myservice -f values-prod.yaml .

4. Deployment — Template Example

templates/deployment.yaml uses Helm templating:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "myservice.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "myservice.name" . }}
    spec:
      containers:
        - name: myservice
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}
          env:
            - name: APP_ENV
              value: "{{ .Values.env.APP_ENV }}"

Helm replaces {{ ... }} placeholders with values during installation.

5. Service — Internal Load Balancer

service.yaml exposes the Pods inside the cluster:


apiVersion: v1
kind: Service
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  type: ClusterIP
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.port }}
  selector:
    app: {{ include "myservice.name" . }}

This allows other services inside the cluster to reach your API.

6. Ingress — External Access

If you want the service accessible from the internet:


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ include "myservice.fullname" . }}
spec:
  rules:
    - host: api.mycompany.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: {{ include "myservice.fullname" . }}
                port:
                  number: {{ .Values.service.port }}

Ingress uses an Ingress Controller (NGINX, Traefik, AWS ALB) to route HTTP/HTTPS traffic.

7. How Deployment, Service, and Ingress Are Connected

This is one of the most important concepts and often misunderstood.

Connection Breakdown

Component	Role
Deployment	Creates and manages Pods
Service	Maps stable IP to Pods & load balances
Ingress	Maps external domain/path to Service

Flow Diagram


Client → Ingress → Service → Pods (via Deployment)

Detailed Flow Description

Deployment creates Pods with label:
```
app: myservice
```
Service selects Pods using:
```
selector:
  app: myservice
```
Ingress forwards external HTTP traffic to the Service:
```
backend:
  service:
    name: myservice
```

Text Diagram


                       ┌───────────────────────┐
                       │       Ingress         │
                       │  (HTTP/HTTPS Router)  │
                       └───────────▲───────────┘
                                   │
                       ┌───────────┴───────────┐
                       │       Service         │
                       │   (Load Balancer)     │
                       └───────────▲───────────┘
                                   │
                       ┌───────────┴───────────┐
                       │      Deployment        │
                       └───────────▲───────────┘
                                   │
                       ┌───────────┴───────────┐
                       │         Pods           │
                       └────────────────────────┘

8. Installing the Helm Chart

Install


helm install myservice ./myservice

Upgrade


helm upgrade myservice ./myservice

Uninstall


helm uninstall myservice

9. Using Environment-Specific Overrides

dev-values.yaml


replicaCount: 1
image:
  tag: "1.0-dev"

prod-values.yaml


replicaCount: 4
image:
  tag: "1.0-prod"

Deploy:


helm install myservice -f prod-values.yaml .

Conclusion

Helm is an essential tool for real-world Kubernetes deployments.
It simplifies your deployment workflow by providing:

✔ Reusable templates
✔ Environment-specific configurations
✔ Clean separation of logic and values
✔ Version-controlled releases
✔ Easy upgrades and rollbacks

The Backend Engineer’s Journal