Kubernetes

Je webshop draait in 40 containers, verspreid over 6 servers.
Om 3 uur 's nachts valt server 4 uit.

Wie start die containers opnieuw op? Op welke server? En hoe vinden de andere containers ze daarna terug?

Leerdoelen

Na deze les kan je:

• uitleggen waarom containerorchestratie nodig is
• Docker Compose en Kubernetes vergelijken
• de architectuur van een Kubernetes cluster beschrijven: control plane en nodes
• de belangrijkste bouwblokken herkennen en in YAML gebruiken: pod, deployment, service, gateway, namespace, secret, persistent volume claim
• een applicatie deployen, bevragen, schalen en updaten met kubectl
• inschatten wanneer Kubernetes (niet) de juiste keuze is

Inhoud

1. Even herhalen: software containers
2. Low tech oplossing: Docker Compose
3. High tech oplossing: Kubernetes
   • situering
   • architectuur
4. Bouwblokken
5. Werking: kubectl, schalen, netwerken, storage, demo
6. Verder: Helm, operators, GitOps…

Virtuele machines vs. containers

Software containers

• Gebruiken de kernel van de host
  • moeten daarom niet opstarten zoals een OS
  • kunnen daardoor erg klein gemaakt worden
• Worden opgebouwd met een Dockerfile (of Containerfile) tot een image, volgens de open OCI-standaard
• Bieden isolatie ten opzichte van andere containers, gebaseerd op namespaces (wat zie je?) en cgroups (hoeveel mag je gebruiken?) in Linux
• Een image draait overal hetzelfde: laptop, CI-pipeline, Cloud Run, Kubernetes…

Waar staan containers?

Dockerfile

Een Dockerfile beschrijft stap voor stap hoe een image gebouwd wordt.

FROM ubuntu:24.04
LABEL maintainer="roel.vansteenberghe@odisee.be"
RUN apt-get update \
 && apt-get install -y nginx \
 && rm -rf /var/lib/apt/lists/*
COPY index.html /var/www/html/
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
								

Uitdagingen voor containerbeheer

En ook: self-healing, updates zonder downtime, secrets, ...

Docker Compose

• Beschrijft een applicatie van meerdere containers in één YAML-bestand (compose.yaml)
• Containers vinden elkaar via hun servicenaam (bv. webserver → databank)
• Eenvoudig op te zetten: één commando
• Maar: beperkt tot één host, geen self-healing over hosts heen, geen autoscaling
• Sinds Compose v2 een plugin van de Docker CLI: docker compose (de oude Python-versie docker-compose wordt niet meer ondersteund)

Ideaal voor development, tests en kleine setups

compose.yaml: Wordpress + databank

services:
  database:
    image: mariadb:11.4
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MARIADB_ROOT_PASSWORD: somewordpress
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: wordpress
								

  wordpress:
    image: wordpress:latest
    volumes:
      - wp_data:/var/www/html
    ports:
      - "80:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: database
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress

volumes:
  db_data:
  wp_data:
								

Wat valt op?

• Elke container krijgt een servicenaam. Die gebruik je om ernaar te verwijzen, bv. WORDPRESS_DB_HOST: database. Je hoeft dus geen ip-adressen te kennen.
• Dat werkt via de ingebouwde DNS-server van Docker, op het netwerk dat Compose voor deze applicatie aanmaakt.
• ports: hoe de container van buitenaf bereikbaar is. Dit is de -p-parameter van docker run. De databank heeft geen ports: die is enkel intern bereikbaar.
• volumes: data die het herstarten (en verwijderen) van een container overleeft.
• restart: always: crasht een container, dan start Docker hem opnieuw. Maar enkel op deze host.

Opstarten

docker compose up -d      # opstarten op de achtergrond (= daemon)
docker compose ps         # welke containers draaien er?
docker compose logs -f    # logs volgen
docker compose down       # alles stoppen en opruimen (volumes blijven)
						

En als je 3 servers hebt in plaats van 1? En als er één uitvalt?

Kubernetes

• Komt uit de stal van Google (geïnspireerd op het interne systeem Borg), sinds 2015 open source en geschonken aan de CNCF
• Een erg actief project: 3 releases per jaar, elke release krijgt ongeveer 14 maanden ondersteuning
• Kan lokaal geïnstalleerd worden, maar wordt meestal gebruikt als managed dienst: GKE (Google), EKS (AWS), AKS (Azure)
• Een erg universeel framework met plugins voor container runtime (CRI), netwerk (CNI) en storage (CSI)
• Je beschrijft wat je wil (declaratief), Kubernetes zorgt voor het hoe

Situering

• Door de adoptie bij Google, AWS en Azure de de facto standaard voor containerbeheer
• Gericht op specialisten: terminal first (kubectl voor Windows, Linux en Mac), beperkte GUI
• Verschillende distributies die een meerwaarde willen bieden tegenover 'vanilla' Kubernetes: OpenShift (Red Hat), Rancher (SUSE), Tanzu (Broadcom), k3s…
• Snelle ontwikkeling: features gaan van alpha naar beta naar GA, en geregeld wordt iets deprecated
  • bv. Docker als runtime (dockershim) verdween in v1.24
  • bv. Ingress wordt niet meer verder ontwikkeld, de Gateway API is de opvolger
• Worker nodes kunnen ook Windows-machines zijn

Een ecosysteem van aanbieders

Eén schakel in de DevOps-keten

Architectuur van een cluster

Wie doet wat?

De kern: desired state

Jij beschrijft de gewenste toestand, controllers zorgen er continu voor dat de werkelijkheid volgt: self-healing.

De belangrijkste objecten

Configuratie via kubectl, YAML (of JSON) en deels via de GUI van je cloudprovider

Bouwblok: node

• Een node is simpelweg een machine, meestal een VM, waarop pods geplaatst kunnen worden
• Het besturingssysteem varieert, maar vaak is het een gespecialiseerd OS met een kleine footprint (bv. Container-Optimized OS bij GKE, Bottlerocket bij AWS, Talos)
• Nodes met dezelfde configuratie vormen een node pool, die je kan laten autoscalen
• Opgelet: niet alle resources zijn bruikbaar voor jouw pods. Het OS, de kubelet en systeempods nemen per node al snel 1 GB of meer. Kijk naar Allocatable in kubectl describe node.

Bouwblok: pod

• Bevat één of meer containers en volumes. De containers delen het netwerk (localhost) en de volumes.
• Elke pod krijgt één intern ip-adres: bereikbaar vanuit andere pods, niet van buiten de cluster
• Maak je in principe niet zelf aan: een deployment doet dat voor jou. Pods zijn wegwerpbaar.

Bouwblok: deployment

• Bevat de desired state van een applicatie: image, aantal replica's, resources, update-strategie…
• De control plane controleert continu of de applicatie nog voldoet (bv. aantal instanties) en stuurt bij waar nodig
• Onder de motorkap maakt een deployment een ReplicaSet per versie. Zo kan je ook terug naar een vorige versie (rollback).

Deployment: YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.29
        ports:
        - containerPort: 80
								

Requests en limits

containers:
- name: nginx
  image: nginx:1.29
  resources:
    requests:
      memory: "64Mi"  # 64 MiB RAM
      cpu: "100m"     # 0,1 core
    limits:
      memory: "128Mi"
      cpu: "500m"
								

Voeg altijd requests (en limits) toe

Health checks: probes

readinessProbe:
  httpGet:
    path: /healthz
    port: 80
  periodSeconds: 5
						

Meer soorten workloads

StatefulSets

Variant op een deployment, met sticky identity:

Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

• Vaste namen: mysql-0, mysql-1… met een vaste DNS-naam
• Elke pod krijgt een eigen volume (volumeClaimTemplates), dat hem volgt bij een herstart
• Pods worden in volgorde gestart en gestopt

Bouwblok: service

• Pods komen en gaan, en hun ip-adres verandert. Een service geeft een groep pods een stabiel adres en een DNS-naam, en verdeelt de load.
• Types:
  • ClusterIP (default): vast virtueel ip, enkel binnen de cluster
  • NodePort: bereikbaar op een vaste poort (30000–32767) van elke node
  • LoadBalancer: de cloudprovider maakt een (TCP-)load balancer met een extern ip. De implementatie hangt af van je provider.
• Voor http(s) naar buiten: liever een Gateway (of Ingress), met veel meer mogelijkheden

Service types

Service: YAML

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080
								

Bouwblok: Ingress en Gateway

Best practice: naar buiten via een Gateway, niet via een LoadBalancer per service

Gateway en HTTPRoute

Gateway en HTTPRoute: YAML

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
								

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
spec:
  parentRefs:
  - name: shop-gateway
  rules:
  - matches:
    - path: { type: PathPrefix, value: /api }
    backendRefs:
    - { name: api, port: 80 }
  - backendRefs:            # al de rest
    - { name: web-v1, port: 80, weight: 90 }
    - { name: web-v2, port: 80, weight: 10 }
								

• De HTTPRoute hangt zich via parentRefs aan een Gateway
• Met weight splits je het verkeer: hier gaat 10% naar een nieuwe versie (canary release)

Bouwblok: namespace

• Een logische scheiding tussen projecten, klanten of omgevingen (dev, test, prod) binnen dezelfde cluster
• Namen moeten uniek zijn binnen een namespace, niet over namespaces heen
• Elke service krijgt automatisch een DNS-naam:

  
  service-naam.namespace.svc.cluster.local
  								

• Opgelet: standaard geen beveiliging. Diensten zijn over namespaces heen bereikbaar. Afschermen doe je met NetworkPolicies, RBAC en ResourceQuota per namespace.

Labels & selectors: de lijm

Selectors kiezen ook nodes

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
  - name: cuda-demo
    image: registry.k8s.io/cuda-vector-add:v0.1
    resources:
      limits:
        nvidia.com/gpu: 1
  nodeSelector:
    cloud.google.com/gke-accelerator: nvidia-l4
								

Secrets

• Gevoelige gegevens (wachtwoorden, tokens, certificaten) los van de image en van je code bewaren
• Opgelet: de waarden zijn enkel base64-gecodeerd, niet geëncrypteerd. Wie de secret mag lezen, kent het wachtwoord.
• Encryptie at rest in etcd moet aan staan (bij managed clusters vaak standaard), en beperk de toegang met RBAC
• Niet-gevoelige configuratie zet je in een ConfigMap

kubectl create secret generic db-user-pass \
    --from-literal=username=admin \
    --from-literal=password='1f2d1e2e67df'
secret/db-user-pass created
						

Een secret gebruiken

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:   # leesbaar invoeren, anders base64
  username: "db-admin"
  password: "S3cr3tP@ssw0rd!"
								

apiVersion: v1
kind: Pod
metadata:
  name: app-pod-env
spec:
  containers:
  - name: my-app
    image: busybox
    command: ["sleep", "3600"]
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: password
								

Secrets: best practices

• Gebruik ze enkel als het nodig is. De meeste cloudomgevingen hebben een specifieke dienst voor secrets: Secret Manager (GCP), Secrets Manager (AWS), Key Vault (Azure).
• Koppel die aan je cluster met de Secrets Store CSI driver of de External Secrets Operator
• Nog beter: geen wachtwoord. Met Workload Identity krijgt een pod een eigen identiteit in de cloud, zonder sleutelbestand.
• Nooit secrets in Git, in de image of in logs

Klaarzetten van je omgeving

• Een goede editor met YAML-ondersteuning (bv. VS Code met de Kubernetes-extensie)
• kubectl, het commando om Kubernetes te beheren, en bij GKE ook de gke-gcloud-auth-plugin
• De inloggegevens van je cluster ophalen

gcloud components install kubectl gke-gcloud-auth-plugin
gcloud container clusters get-credentials cluster --location europe-west1-d
kubectl get nodes
kubectl create namespace demo
						

Resources aanmaken

kubectl create deployment testdeploy \
    --image=nginx:1.29 --port=80 -n demo
								

kubectl apply -f deployment.yaml
kubectl apply -f ./k8s/   # hele map
								

Resources bevragen

'pods' kan je uiteraard vervangen door andere objecten: deployments, services, gateways, pvc…

Schalen

kubectl scale deployment web --replicas=5
								

kubectl autoscale deployment web \
    --min=2 --max=10 --cpu=60%
kubectl get hpa
								

Rolling updates

kubectl set image deployment/web web=registry/app:v2   # nieuwe versie
kubectl rollout status deployment/web                  # meekijken
kubectl rollout undo deployment/web                    # terug naar v1
						

Netwerken

• Elke pod heeft een eigen ip-adres. Alle pods kunnen elkaar bereiken zonder NAT, ook over nodes heen.
• Dat netwerk tussen de nodes komt van een CNI-plugin: Calico, Cilium, Flannel… of die van je cloudprovider
• Een service krijgt een ClusterIP: een virtueel ip-adres dat verkeer verdeelt over de pods (via kube-proxy of eBPF)
• Pods vinden services via DNS (CoreDNS): gebruik de servicenaam, nooit een pod-ip
• Containers binnen dezelfde pod praten via localhost
• NetworkPolicies werken als firewallregels tussen pods

Storage

• Samen met ingress het onderdeel dat het meest afhangt van de implementatie van de vendor (via een CSI-driver)
• Een PersistentVolumeClaim (PVC) = een aanvraag voor opslag van een bepaalde StorageClass (type: SSD, standaard…)
• Het onderliggende PersistentVolume (PV) wordt bij cloudproviders automatisch aangemaakt: dynamic provisioning
• Access modes:

  ReadWriteOnce	lezen/schrijven vanaf één node (meest voorkomend, bv. persistent disk)
  ReadWriteOncePod	lezen/schrijven door één pod
  ReadOnlyMany	enkel lezen, vanaf meerdere nodes
  ReadWriteMany	lezen/schrijven vanaf meerdere nodes: netwerkbestandssysteem nodig (bv. Filestore, EFS)

Storage: YAML

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fastdisks
  resources:
    requests:
      storage: 8Gi
								

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fastdisks
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
volumeBindingMode: WaitForFirstConsumer
								

Demo

• Google Cloud: een GKE-cluster aanmaken
• Namespaces
• De console (UI) van GKE
• Een deployment en service aanmaken, schalen en een pod verwijderen (self-healing)

Demo!

Quiz: welk object?

Verder…

• CronJobs: pods op regelmatige tijdstippen uitvoeren (docs)
• Operators: eigen objecten (CRD's) + een controller die de kennis van een beheerder automatiseert, bv. een PostgreSQL-cluster met backups en failover
• Helm: de 'app store' van Kubernetes
• GitOps: de cluster volgt automatisch wat in Git staat (Argo CD, Flux)
• Autoscaling op events (KEDA) en slim node-beheer (cluster autoscaler, Karpenter)

Kubernetes als bouwblok

• voor cloud independency: dezelfde YAML op GKE, EKS, AKS of on-premises
• voor service mesh-architecturen: Istio, Linkerd, Cloud Service Mesh (mTLS, retries, observability tussen services)
• voor serverless oplossingen: Knative. Cloud Run implementeert de Knative Serving API.
• voor AI-workloads: GPU-nodes en schedulers voor training en inferencing

Extra: Helm

• Een abstractielaag die een "app store" voor Kubernetes mogelijk maakt
• Herbruikbare pakketten: charts, met een systeem voor templating (values)
• Installeren, upgraden en terugrollen als één geheel

helm repo add prometheus-community \
    https://prometheus-community.github.io/helm-charts
helm install monitoring \
    prometheus-community/kube-prometheus-stack
								

Artifact Hub

Compose, Kubernetes of serverless?

Samenvatting

Kubernetes is een platform om platformen te bouwen

Zelf aan de slag

• Lokaal testen met minikube, kind of de ingebouwde Kubernetes van Docker Desktop / Rancher Desktop
• Officiële tutorial: Kubernetes basics
• Google Skills: Kubernetes in Google Cloud

Begin je zoektocht naar info steeds in de officiële documentatie. Die is, in tegenstelling tot de honderden blogs over het onderwerp, steeds up-to-date. Geen overbodige luxe met een framework dat elke paar maanden nieuwe features krijgt…

Volgende stap: aan de slag in het labo!