LAB14: Helm & Kustomize

BLOG 500: Helm & Kustomize

how to manage Kubernetes objects across environments using:

Two methods

1. Templating (Helm-like approach – using variables)

2. Patching / Overlays (Kustomize)

Scenario

• App: Static website using Nginx

• Source: index.html stored in ConfigMap

• Environments: dev and prod

• Differences:

  • Domains:

    • dev → dev.hello-world.xyz

    • prod → hello-world.xyz

  • SSL:

    • dev → ❌ no SSL

    • prod → ✅ SSL Ingress (TLS)

• Namespaces: hello-dev, hello-prod

• All objects must use labels and have names suffixed with -dev or -prod.

Method 1: Templating Approach

Templates use placeholders, and each environment fills values.

Directory Structure

.
├── Chart.yaml
├── templates/
│   ├── common.yaml
│   └── ingress.yaml
├── values-dev.yaml
└── values-prod.yaml

1. Base Template (common.yaml)

apiVersion: v1
kind: Namespace
metadata:
  name: {{ .Values.Namespace }}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: website-config-{{ .Values.Env }}
  namespace: {{ .Values.Namespace }}
  labels:
    env: {{ .Values.Env }}
data:
  index.html: |
    {{ .Values.Content }}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: website-{{ .Values.Env }}
  namespace: {{ .Values.Namespace }}
  labels:
    app: website
    env: {{ .Values.Env }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: website
      env: {{ .Values.Env }}
  template:
    metadata:
      labels:
        app: website
        env: {{ .Values.Env }}
    spec:
      containers:
        - name: website
          image: nginx
          volumeMounts:
            - name: html
              mountPath: /usr/share/nginx/html
      volumes:
        - name: html
          configMap:
            name: website-config-{{ .Values.Env }}
---
apiVersion: v1
kind: Service
metadata:
  name: website-svc-{{ .Values.Env }}
  namespace: {{ .Values.Namespace }}
  labels:
    app: website
    env: {{ .Values.Env }}
spec:
  selector:
    app: website
    env: {{ .Values.Env }}
  ports:
    - port: 80

2. Rendered Ingress Template

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: website-ingress-{{ .Values.Env }}
  namespace: {{ .Values.Namespace }}
  labels:
    env: {{ .Values.Env }}
spec:
  {{- if .Values.EnableTLS }}
  tls:
    - hosts:
        - {{ .Values.Domain }}
      secretName: website-tls-{{ .Values.Env }}
  {{- end }}
  rules:
    - host: {{ .Values.Domain }}
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: website-svc-{{ .Values.Env }}
                port:
                  number: 80

3. Chart.yaml

apiVersion: v2
name: website
description: A simple Helm chart for deploying a website
type: application

version: 0.1.0        # Chart version
appVersion: "1.0.0"   # Application version

# Optional (if you use dependencies later)
# dependencies: []

4. values.yaml

Env: ""
Namespace: ""
Domain: ""
Content: ""
EnableTLS: false

5. Dev Environment Values (values-dev.yaml)

Env: dev
Namespace: hello-dev
Domain: dev.hello-world.xyz
Content: "Hello from Dev Environment"
EnableTLS: false

6. Prod Environment Values (values-prod.yaml)

Env: prod
Namespace: hello-prod
Domain: hello-world.xyz
Content: "Hello from Production Environment"
EnableTLS: true

:::spoiler Let's deploy Here is a complete Helm workflow for your chart — check, template, package/archive, install, upgrade, and uninstall.

Your chart structure:

.
├── Chart.yaml
├── templates/
│   ├── common.yaml
│   └── ingress.yaml
├── values-dev.yaml
└── values-prod.yaml

---

✅ 1. Check the Helm Chart

Lint

Checks for template syntax errors:

helm lint .

---

✅ 2. Render the Templates (Dry-run)

Use dev values

helm template website-dev . -f values-dev.yaml

Use prod values

helm template website-prod . -f values-prod.yaml

With default values

helm template website .

This shows what Kubernetes manifests will be generated.

---

✅ 3. Archive / Package the Chart

This creates a .tgz archive:

helm package .

Output example:

Successfully packaged chart and saved it to: website-0.1.0.tgz

You can now upload this to a Helm repo.

---

✅ 4. Install the Chart

Install using dev values

helm install website-dev . -f values-dev.yaml

Install using prod values

helm install website-prod . -f values-prod.yaml

Install a packaged chart

helm install website ./website-0.1.0.tgz

---

✅ 5. Upgrade the Chart

Modify your templates/values and run:

Upgrade dev

helm upgrade website-dev . -f values-dev.yaml

Upgrade prod

helm upgrade website-prod . -f values-prod.yaml

Upgrade with new version

helm upgrade website ./website-0.1.1.tgz

---

✅ 6. Uninstall / Remove the Release

helm uninstall website-dev
helm uninstall website-prod

---

✅ 7. Optional Advanced Commands

Show Installed Version

helm list

Check Release Values

helm get values website-dev

Check Rendered Manifests of a Running Release

helm get manifest website-dev

:::

Method 2: Kustomize Overlay Approach

Directory structure:

app/
 ├── base/
 │   ├── configmap.yaml
 │   ├── deployment.yaml
 │   ├── service.yaml
 │   ├── ingress.yaml
 │   └── kustomization.yaml
 ├── dev/
 │   ├── kustomization.yaml
 │   └── patch-ingress.yaml
 └── prod/
     ├── kustomization.yaml
     └── patch-ingress.yaml

BASE (common to dev + prod)

namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: hello

configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: website-config
data:
  index.html: "HELLO FROM BASE"

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: website
  labels:
    app: website
spec:
  replicas: 1
  selector:
    matchLabels:
      app: website
  template:
    metadata:
      labels:
        app: website
    spec:
      containers:
      - name: website
        image: nginx
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      volumes:
      - name: html
        configMap:
          name: website-config

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: website-svc
spec:
  selector:
    app: website
  ports:
    - port: 80

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: website-ing
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: website-svc
            port:
              number: 80

base/kustomization.yaml

resources:
  - configmap.yaml
  - deployment.yaml
  - service.yaml
  - ingress.yaml
  - namespace.yaml

DEV OVERLAY

dev/kustomization.yaml

namespace: hello-dev

nameSuffix: -dev

commonLabels:
  env: dev

resources:
  - ../base

patches:
  - path: patch-ingress.yaml

configMapGenerator:
  - name: website-config
    behavior: replace
    literals:
      - index.html=Hello from Dev Environment

dev/patch-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: website-ing
spec:
  rules:
  - host: dev.hello-world.xyz

❌ No TLS patch → dev has no SSL.

PROD OVERLAY

prod/kustomization.yaml

namespace: hello-prod

nameSuffix: -prod

commonLabels:
  env: prod

resources:
  - ../base

patches:
  - path: patch-ingress.yaml

configMapGenerator:
  - name: website-config
    behavior: replace
    literals:
      - index.html=Hello from Production Environment

prod/patch-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: website-ing
spec:
  tls:
  - hosts:
    - hello-world.xyz
    secretName: website-tls
  rules:
  - host: hello-world.xyz

How to Deploy

Dry-run and apply

Now you can do:

# Dry-run dev
kubectl apply -k dev --dry-run=client

# Apply dev
kubectl apply -k dev

# Dry-run prod
kubectl apply -k prod --dry-run=client

# Apply prod
kubectl apply -k prod

Kustomize will automatically apply the namespace suffix (hello-dev / hello-prod) to all resources.

---

After this, verify namespaces and resources:

kubectl get ns
kubectl get all -n hello-dev
kubectl get all -n hello-prod

Using kustomize CLI

If you have kustomize installed separately:

# For dev
kustomize build dev

# For prod
kustomize build prod

This outputs the final manifests that would be applied. You can redirect it to a file if you want: kustomize build dev > dev.yaml

---

Apply Changes

Using kubectl directly

# Apply dev overlay
kubectl apply -k dev

# Apply prod overlay
kubectl apply -k prod

This will create/update all resources defined in base + overlay patches.

---

Using kustomize CLI + kubectl

# Build and apply dev
kustomize build dev | kubectl apply -f -

# Build and apply prod
kustomize build prod | kubectl apply -f -

References

-[helm & kustomize]