Day 2 on Eriks training corner

DaemonSets

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

DaemonSets

One Pod per node - automatically, including nodes that join later.

graph TB DS[DaemonSet log-agent] --> P1[Pod on worker01] DS --> P2[Pod on worker02] DS --> P3[Pod on worker03] N[new node joins] -.-> P4[Pod created automatically]

No replicas field - the node list is the replica count.

Typical users: CNI agents (calico-node), kube-proxy, log shippers, node exporters, storage drivers. Your cluster already runs several: kubectl get ds -A.

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: node-logger
spec:
 selector:
 matchLabels: { app: node-logger }
 template:
 metadata:
 labels: { app: node-logger }
 spec:
 containers:
 - name: logger
 image: busybox:1.36
 command: ["sh", "-c", "while true; do date; sleep 30; done"]

Control plane skipped: control01 has a NoSchedule taint. Add a toleration to run there (that is how calico-node and kube-proxy get there).
Subset of nodes: nodeSelector, e.g. only nodes labelled storage=nfs.
Updates: RollingUpdate (default, node by node) or OnDelete.

References

DaemonSet

StatefulSets (and a first look at PVCs)

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

StatefulSets (and a first look at PVCs)

A Deployment treats Pods as interchangeable: random names, random order, shared storage. Databases 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

Property	Meaning
Stable identity	`db-0`, `db-1`, `db-2` - the name survives a restart
Stable DNS name	`db-0.db.default.svc.cluster.local` via a headless Service
Own storage	`volumeClaimTemplates` - one PVC per Pod, kept on delete
Ordered	starts 0,1,2; stops 2,1,0

PV and PVC in 30 seconds

graph LR P[Pod] --> PVC[PersistentVolumeClaim I need 1Gi RWX] PVC -->|bound| PV[PersistentVolume NFS support01:/storage1]

PV - a piece of real storage (here: an NFS export). Cluster-scoped.
PVC - a request for storage, in your namespace. Kubernetes binds it to a matching PV.
StorageClass - creates PVs on demand. This cluster has none yet, so today PVs are created by hand. Details on Day 5.

 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteMany"]
 storageClassName: "" # bind to a pre-created PV
 resources:
 requests:
 storage: 500Mi

Watch out

Deleting the StatefulSet or scaling down keeps the PVCs - your data survives, clean-up is manual.
A StatefulSet does not replicate your data. It gives identity and storage; replication is the application’s (or an operator’s) job.

References

Jobs and CronJobs

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

Jobs and CronJobs

Deployments keep things running. Jobs make things finish.

Job

Runs Pods until the required number succeed.

apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 completions: 3 # successful Pods needed
 parallelism: 2 # at most 2 at a time
 backoffLimit: 4 # retries before the Job fails
 activeDeadlineSeconds: 120
 ttlSecondsAfterFinished: 600 # auto-delete when done
 template:
 spec:
 restartPolicy: Never  # or OnFailure - never Always
 containers:
 - name: pi
 image: perl:5.40
 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(200)"]

Field	Effect
`completions` / `parallelism`	how many, how many at once
`backoffLimit`	failed attempts before `Failed` (exponential back-off)
`activeDeadlineSeconds`	hard time limit for the whole Job
`ttlSecondsAfterFinished`	garbage-collect the Job and its Pods

CronJob

Creates a Job on a schedule.

ConfigMaps and Secrets

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

ConfigMaps and Secrets

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

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

env: # one key as a variable
 - name: DATACENTER
 valueFrom:
 configMapKeyRef: { name: app-cfg, key: DATACENTER }
envFrom: # all keys as variables
 - configMapRef: { name: app-cfg }
volumes: # all keys as files
 - name: cfg
 configMap: { name: app-cfg }

Consumed as	Change visible in a running Pod?
mounted file	yes, after ~1 min (not with `subPath`)
environment variable	no - `kubectl rollout restart`

Secret

Same shape, different intent. Values are base64 - encoding, not encryption.

Networking, CNI, Services and DNS

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

Networking, CNI, Services and DNS

The Kubernetes network model

Three rules, implemented by the CNI plugin:

Every Pod gets its own IP.
Every Pod reaches every other Pod - on any node - without NAT.
Agents on a node reach all Pods on that node.

Nothing else is promised: how packets travel is the CNI’s choice.

CNI: overlays and routing

graph LR subgraph worker01 PA[Pod 10.244.1.5] end subgraph worker02 PB[Pod 10.244.2.7] end PA -->|"encapsulated in node-to-node packet (VXLAN / IP-in-IP)"| PB

Mode	How	Trade-off
Overlay - VXLAN, IP-in-IP	Pod packet wrapped in a node packet	works on any network; small overhead
Native routing - BGP	nodes announce Pod routes to each other / the router	no overhead; network must cooperate
eBPF data plane	packet handling in the kernel, replaces kube-proxy	fastest; newer kernels

Plugin	Overlay / routing	NetworkPolicy	Notes
Calico (this cluster)	VXLAN, IP-in-IP, BGP, eBPF	yes + own policy CRDs	most common on-prem
Cilium	VXLAN, native, eBPF	yes + L7 policies	eBPF-first, Hubble observability
Flannel	VXLAN	no	simple, no policies
Cloud CNIs (Azure, AWS VPC)	VPC-native IPs	via Calico / Cilium	managed clusters

A CNI without NetworkPolicy support silently ignores your policies. Policies are Day 4.

Helm

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

Helm

A real application is a dozen manifests with matching values. Helm packages them.

Term	Meaning
Chart	the package - templates plus default `values.yaml`
Repository	web server (or OCI registry) with charts; Artifact Hub indexes them
Release	one installation of a chart, with a unique name
Revision	one version of a release; every upgrade adds one

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

Helm is a single binary (current major: Helm 4). It uses your kubeconfig; there is no server-side component.

Ingress (legacy)

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

Ingress (legacy)

The original answer to “one HTTP entry point for many applications”. You will meet it in every existing cluster - new work belongs on Gateway API.

graph LR C[Client] --> T[Ingress controller Traefik] T -->|host shop.k8s.lab| S1[Service shop] T -->|host wiki.k8s.lab| S2[Service wiki] I[Ingress objects] -.read by.-> T

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: shop
spec:
 ingressClassName: traefik  # which controller
 rules:
 - host: shop.k8s.lab
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service: { name: shop, port: { number: 80 } }

Why it is legacy

The spec only knows host + path. Everything else (rewrites, canaries, timeouts) is a controller-specific annotation - not portable.
One object mixes infrastructure (TLS, entry point) and application routing.
The API is frozen; development happens in Gateway API.
ingress-nginx, the most used controller, was retired in March 2026.

An Ingress without a running controller does nothing - silently. Traefik reads both Ingress and Gateway API, which makes it a practical migration path.

Gateway API

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

Gateway API

The successor of Ingress: one HTTP(S) entry point, routing by host, path, header or weight - expressed as typed resources instead of annotations.

graph LR C[Browser shop.k8s.lab] --> GW[Gateway listener web] GW --> R1[HTTPRoute shop] GW --> R2[HTTPRoute wiki] R1 --> S1[Service shop] R2 --> S2[Service wiki] GC[GatewayClass traefik] -.-> GW

Three objects, three owners

Object	Answers	Owned by
GatewayClass	which implementation?	cluster admin (installed with the controller)
Gateway	where does traffic enter - ports, protocols, TLS, who may attach	platform team
HTTPRoute	which requests go to which Service	application team

The route points up to its Gateway with parentRefs; the Gateway decides with allowedRoutes which namespaces may attach. Teams add routes without touching shared configuration.

Kustomize

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

Kustomize

Same application, different environments - without templates. Plain YAML plus patches, built into kubectl.

graph TB B[base/ deployment.yaml, service.yaml] --> D[overlays/dev 1 replica, tag latest] B --> P[overlays/prod 3 replicas, tag 1.28, limits] D -->|kubectl apply -k| C1[namespace dev] P -->|kubectl apply -k| C2[namespace prod]

app/
 base/
 kustomization.yaml
 deployment.yaml
 service.yaml
 overlays/
 dev/kustomization.yaml
 prod/kustomization.yaml
 prod/resources-patch.yaml

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
 - ../../base
namespace: prod
labels:
 - pairs: { env: prod }
 includeSelectors: false
images:
 - name: nginx
 newTag: "1.28"
replicas:
 - name: web
 count: 3
configMapGenerator:
 - name: web-cfg
 literals: [LOG_LEVEL=warn]
patches:
 - path: resources-patch.yaml

kubectl kustomize overlays/prod # render
kubectl diff -k overlays/prod # compare with the cluster
kubectl apply -k overlays/prod # apply

configMapGenerator appends a content hash to the name (web-cfg-7g2h9) and updates the references - a changed config triggers a rollout automatically.