Week 13 - Templating & Infrastructure as Code¶

Welcome to the start of phase 4!

Up until now, you have been deploying to Kubernetes using static YAML manifests. While this works well for a single environment, it introduces issues with duplication, configuration drift, and complexity when managing multiple environments (dev, test, prod).

This phase focuses on production readiness: automatic scaling, failure tolerance, observability, and templated deployments.

Introduction¶

In this lab, we will migrate from static YAML files to a templating tool. This allows us to separate the logic (the deployment structure) from the configuration (the specific values for an environment).

You must choose one of the following tools:

1. Helm: A package manager for Kubernetes that uses templates and values files.
2. Kustomize: A native configuration management tool that uses bases and overlays.

Operational requirements¶

Installing the templating tools¶

You will need the tools installed locally to develop and lint your templates.

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

choco install kubernetes-helm
# OR
winget install Helm.Helm

kubectl kustomize --help

Templating Strategy¶

You must convert your existing Kubernetes manifests into a templated format.

my-chart/
├── Chart.yaml          # Metadata
├── values.yaml         # Default configuration 
└── templates/          # Logic
    ├── deployment.yaml
    └── service.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
    name: {{ .Release.Name }}
    labels:
        app: {{ .Release.Name }}
spec:
    replicas: {{ .Values.replicaCount }}
    selector:
        matchLabels:
          app: {{ .Release.Name }}
    template:
        metadata:
          labels:
            app: {{ .Release.Name }}
        spec:
        containers:
            - name: {{ .Release.Name }}
              image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
              ports:
                - containerPort: {{ .Values.service.port }}

replicaCount: 1
image:
    repository: nginx
    tag: stable
service:
    port: 80

manifests/
├── base/                   # Logic (Common)
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/               # Configuration
    └── prod/
        ├── patch.yaml
        └── kustomization.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
    name: my-nginx
spec:
    replicas: 1
    template:
        spec:
            containers:
            - name: nginx
              image: nginx:latest

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- deployment.yaml

resources:
- ../../base
patches:
- path: patch.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3

Safe Deployments (Atomic Rollback)¶

In production, deployments fail. A bad configuration or a broken image shouldn't leave your workloads in a broken state.

Secret Management¶

Helm charts and Kustomize overlays are code. Code lives in Git.

Example (Helm):

helm upgrade --install my-app ./chart \
  --set secret.password=$DB_VAR \ # Sets a specific values file only for this execution
  --rollback-on-failure \
  --timeout=5m

Development requirements¶

Statelessness¶

To prepare for chaos engineering (which starts soon), your application must be able to survive random pod failures. This requires your application to be as stateless as possible.

You can do this by either deploying a replicated/clustered database solution yourself, or using one of the many preinstalled operators in the cluster:

If your system so far uses disk-based solutions (files written directly to disk, SQLite) you may get away with using ReadWriteMany volumes, instead of having to rewrite large parts of your code, but make sure to test everything.

Documentation requirements¶

Tasks¶

• Install Helm or Kustomize locally.
• Refactor your Kubernetes manifests into a Chart (Helm) or Base/Overlay (Kustomize).
• Update your .gitlab-ci.yml to deploy using the templating tool.
• Configure "Atomic" deployment (automated rollback on failure).
• Ensure strict separation of configuration and logic.
• Inject secrets securely via the pipeline (no hardcoded secrets in git).
• Verify your application is stateless (ready for chaos).