Day 3 on Eriks training corner

ConfigMaps and Secrets

Mon, 01 Jan 0001 00:00:00 +0000

ConfigMaps and Secrets

Configuration lives in the environment, not in the image. The same image runs in dev and in prod - only the ConfigMap differs.

apiVersion: v1
kind: ConfigMap
metadata:
 name: app-cfg
data:
 DATACENTER: dc01
 app.properties: |
 color=blue

Two ways to consume it:

env: # 1 - one key as a variable
 - name: DATACENTER
 valueFrom:
 configMapKeyRef: { name: app-cfg, key: DATACENTER }

volumes: # 2 - whole ConfigMap as files
 - name: cfg
 configMap: { name: app-cfg }

Mounted files update by themselves (within a minute or so, when the kubelet syncs). Environment variables do not - they are set once at container start, so the Pod must be restarted: kubectl rollout restart deploy/....

Persistent storage

Mon, 01 Jan 0001 00:00:00 +0000

Persistent storage

A container’s writable layer dies with the container, and emptyDir dies with the Pod. Anything that must outlive a reschedule has to come from outside the cluster.

Three objects

graph LR PV[PersistentVolume the actual storage cluster-scoped] --- B((bind)) PVC[PersistentVolumeClaim a request for storage namespaced] --- B POD[Pod mounts the claim] --> PVC SC[StorageClass creates PVs on demand] -.optional.-> PV

PersistentVolume (PV) - a piece of storage that exists. Cluster-scoped.
PersistentVolumeClaim (PVC) - “I need 1 GiB, ReadWriteOnce”. Namespaced. The Pod references the claim, never the volume.
StorageClass - a factory that creates PVs automatically (dynamic provisioning).

This cluster ships with no StorageClass and no CSI driver, so at first nothing is created automatically: you write the PV yourself, pointing at one of the NFS exports on support01 (/storage1, /storage2, /storage3). That is the on-premise reality a cloud cluster hides from you - and the second half of Lab 18 fixes it by installing a driver.

StatefulSets

Mon, 01 Jan 0001 00:00:00 +0000

StatefulSets

A Deployment treats its Pods as interchangeable: random names, random start order, one shared Service. Databases and clusters need the opposite.

graph TB SS[StatefulSet db] --> P0[db-0 PVC data-db-0] SS --> P1[db-1 PVC data-db-1] SS --> P2[db-2 PVC data-db-2] H[Headless Service db clusterIP: None] -.-> P0 H -.-> P1 H -.-> P2

What you get that a Deployment cannot give you:

Property	Meaning
Stable identity	Pods are `db-0`, `db-1`, `db-2` - the name survives a restart
Stable network name	`db-0.db.default.svc.cluster.local` via a headless Service
Own storage	`volumeClaimTemplates` creates one PVC per Pod, kept on delete
Ordered operations	starts 0,1,2; terminates 2,1,0; rolling update in reverse order

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: web-headless  # the headless Service, required
 replicas: 3
 selector:
 matchLabels: { app: web }
 template:
 metadata:
 labels: { app: web }
 spec:
 containers:
 - name: web
 image: nginx:1.27
 volumeMounts:
 - name: data
 mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 storageClassName: "" # no dynamic provisioning here
 resources:
 requests:
 storage: 1Gi

With no StorageClass in this cluster, volumeClaimTemplates will sit Pending until a matching PV exists for every replica - three replicas need three PVs. That is exactly why the lab creates /storage1..3 as three PVs first.

Helm basics

Mon, 01 Jan 0001 00:00:00 +0000

Helm basics

A real application is a dozen manifests that must be applied in the right order with matching values. Helm packages them.

Term	Meaning
Chart	the package - templates plus default values. Like an RPM or DEB
Repository	a web server with charts; Artifact Hub indexes the public ones
Release	one installation of a chart in a cluster, with a unique name
Revision	one version of a release; every upgrade adds one

graph LR R[(Repository)] --> CH[Chart + values.yaml] V[your -f values.yaml / --set] --> H[helm] CH --> H H -->|render templates| M[Kubernetes manifests] M --> K[Cluster: release rev N]

One chart, many releases: install the same chart three times under three names and you get three independent instances.

Helm charts

Mon, 01 Jan 0001 00:00:00 +0000

Writing a chart

helm create myapp

myapp/
Chart.yaml # metadata: name, version, appVersion (required)
values.yaml # default values (required)
charts/ # dependency charts
crds/ # CRDs, installed before everything else
templates/ # the manifests, as Go templates
_helpers.tpl # reusable macros

version is the chart version (SemVer 2, ends up in myapp-0.1.0.tgz); appVersion is the version of the software inside.

Templates

Namespace	Source
`.Values`	`values.yaml`, overridden by `-f` and `--set`
`.Chart`	`Chart.yaml`
`.Release`	`.Release.Name`, `.Namespace`, `.Revision` - set at install time

metadata:
 name: {{ include "myapp.fullname" . }}
spec:
 replicas: {{ .Values.replicaCount }}
 template:
 spec:
 containers:
 - name: {{ .Chart.Name }}
 image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"

Useful: default, quote, required "message" .Values.x, {{- ... -}} to trim whitespace, {{ if }} / {{ range }}, and include for helpers.

CRDs and operators

Mon, 01 Jan 0001 00:00:00 +0000

CRDs and operators

Custom Resource Definitions

A CRD teaches the API server a new kind. After you apply one, kubectl get, describe, explain, RBAC and every other tool work on it exactly as they do on Pods - because to the API server there is no difference.

kubectl get crd
kubectl api-resources | grep -v -E 'v1$|apps/v1' # what is not core Kubernetes
kubectl explain cluster.spec # works on CRDs too

A CRD alone stores data and does nothing with it. It is a table with validation.