Chaos Engineering: Je Cluster Kapot Maken om het Sterker te Maken

Je cluster ziet er gezond uit. Pods draaien. Metrics zijn groen. Alles werkt.

Tot een node faalt tijdens piekverkeer. Of de database connection pool uitgeput raakt. Of die ene service die niemand zich herinnert gedeployed te hebben al het beschikbare geheugen begint op te eten.

Je kunt wachten tot deze dingen gebeuren in productie om 3 uur ’s nachts. Of je kunt opzettelijk dingen kapot maken, op jouw voorwaarden, en de zwakheden fixen voor ze storingen worden.

Dit is chaos engineering.

Waarom Dingen Opzettelijk Kapot Maken?

Gedistribueerde systemen falen op gedistribueerde manieren. Je kunt niet elke failure mode anticiperen door code te lezen of architectuurdiagrammen te tekenen. De enige manier om te weten hoe je systeem zich gedraagt onder failure is om het te laten falen.

Chaos engineering is niet:

Willekeurige destructie
Testen in productie zonder voorbereiding
Dingen kapot maken om te zien wat er gebeurt

Chaos engineering is:

Hypothese-gedreven experimenteren — “We geloven dat het systeem node failure graceful afhandelt”
Gecontroleerde fault injection — Bekende blast radius, gedefinieerde duur, rollback klaar
Leren van failures — Elk experiment verbetert begrip

Netflix pioniererde dit met Chaos Monkey — willekeurig instanties doden om te zorgen dat engineers resiliente services bouwden. Vandaag is de praktijk volwassen geworden met geavanceerde tools en methodologieën.

Het Chaos Engineering Proces

flowchart TD
    subgraph process["Chaos Engineering Cyclus"]
        H["Definieer Hypothese"]
        E["Ontwerp Experiment"]
        R["Draai in Gecontroleerde Omgeving"]
        O["Observeer & Meet"]
        L["Leer & Verbeter"]
    end

    H --> E --> R --> O --> L
    L --> H

1. Definieer Hypothese

Begin met wat je gelooft dat waar is:

“Als één node faalt, zullen pods binnen 5 minuten reschedulen”
“Als de database traag wordt, zal de API graceful degraderen, niet crashen”
“Als DNS faalt, zullen gecachete responses requests bedienen voor 30 seconden”

2. Ontwerp Experiment

Definieer:

Blast radius: Wat kan beïnvloed worden?
Duur: Hoe lang blijft de fault bestaan?
Rollback: Hoe stop je direct?
Metrics: Wat indiceert succes of falen?

3. Draai in Gecontroleerde Omgeving

Begin klein:

Development omgeving eerst
Dan staging
Productie alleen met safeguards

4. Observeer en Meet

Kijk naar je observability stack. Belangrijke vragen:

Vuurden alerts correct?
Hoe veranderde latency?
Stegen error rates?
Hoe lang tot recovery?

5. Leer en Verbeter

Documenteer bevindingen. Fix zwakheden. Update runbooks. Ontwerp dan het volgende experiment.

Litmus Chaos: Kubernetes-Native Chaos

Litmus is een CNCF project dat chaos engineering voor Kubernetes biedt. Het is declaratief, GitOps-vriendelijk, en uitgebreid.

Litmus Installeren

# Voeg Litmus helm repo toe
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update

# Installeer Litmus
helm install litmus litmuschaos/litmus \
  --namespace litmus \
  --create-namespace \
  --set portal.frontend.service.type=ClusterIP

Litmus Architectuur

flowchart TD
    subgraph litmus["Litmus Componenten"]
        subgraph control["Control Plane"]
            Portal["Litmus Portal<br/>(UI/API)"]
            Server["Litmus Server"]
        end
        subgraph exec["Execution Plane"]
            Sub["Subscriber"]
            Runner["Chaos Runner"]
            Exp["Chaos Experiments"]
        end
    end

    Portal --> Server
    Server --> Sub
    Sub --> Runner
    Runner --> Exp
    Exp --> Target["Target Workload"]

ChaosEngine: Experimenten Declareren

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-chaos
  namespace: default
spec:
  appinfo:
    appns: 'default'
    applabel: 'app=nginx'
    appkind: 'deployment'
  engineState: 'active'
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '30'
            - name: CHAOS_INTERVAL
              value: '10'
            - name: FORCE
              value: 'false'

Dit doodt nginx pods elke 10 seconden voor 30 seconden totaal. Simpel, contained, observeerbaar.

Essentiële Chaos Experimenten

Pod-Level Chaos

Pod Delete: Dood pods om restart gedrag te testen

experiments:
  - name: pod-delete
    spec:
      components:
        env:
          - name: TOTAL_CHAOS_DURATION
            value: '60'
          - name: CHAOS_INTERVAL
            value: '10'
          - name: PODS_AFFECTED_PERC
            value: '50'  # Dood 50% van de pods

Container Kill: Dood specifieke containers binnen pods

experiments:
  - name: container-kill
    spec:
      components:
        env:
          - name: TARGET_CONTAINER
            value: 'sidecar'
          - name: CHAOS_INTERVAL
            value: '10'

Node-Level Chaos

Node Drain: Simuleer node onderhoud

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: node-drain-chaos
spec:
  engineState: 'active'
  auxiliaryAppInfo: ''
  chaosServiceAccount: litmus-admin
  experiments:
    - name: node-drain
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '60'
            - name: TARGET_NODE
              value: 'worker-1'

Node CPU Hog: Simuleer CPU druk

experiments:
  - name: node-cpu-hog
    spec:
      components:
        env:
          - name: TOTAL_CHAOS_DURATION
            value: '60'
          - name: NODE_CPU_CORE
            value: '2'  # Verbruik 2 cores

Network Chaos

Pod Network Loss: Simuleer network partities

experiments:
  - name: pod-network-loss
    spec:
      components:
        env:
          - name: NETWORK_INTERFACE
            value: 'eth0'
          - name: NETWORK_PACKET_LOSS_PERCENTAGE
            value: '100'  # Totaal verlies
          - name: TOTAL_CHAOS_DURATION
            value: '30'

Pod Network Latency: Injecteer latency

experiments:
  - name: pod-network-latency
    spec:
      components:
        env:
          - name: NETWORK_LATENCY
            value: '300'  # 300ms latency
          - name: JITTER
            value: '100'  # 100ms jitter

Storage Chaos

Disk Fill: Test disk druk afhandeling

experiments:
  - name: disk-fill
    spec:
      components:
        env:
          - name: FILL_PERCENTAGE
            value: '90'
          - name: TOTAL_CHAOS_DURATION
            value: '60'

Je Eerste Experiment Draaien

Laten we een compleet chaos experiment draaien tegen een voorbeeld applicatie.

1. Deploy Test Applicatie

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  labels:
    app: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5

2. Maak ServiceAccount voor Litmus

apiVersion: v1
kind: ServiceAccount
metadata:
  name: litmus-admin
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: litmus-admin
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/exec", "pods/log", "events"]
    verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: litmus-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: litmus-admin
subjects:
  - kind: ServiceAccount
    name: litmus-admin
    namespace: default

3. Draai Pod Delete Experiment

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: demo-chaos
  namespace: default
spec:
  appinfo:
    appns: 'default'
    applabel: 'app=demo'
    appkind: 'deployment'
  engineState: 'active'
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '30'
            - name: CHAOS_INTERVAL
              value: '10'
            - name: FORCE
              value: 'false'
        probe:
          - name: "check-endpoint"
            type: "httpProbe"
            httpProbe/inputs:
              url: "http://demo-app.default.svc:80"
              insecureSkipVerify: false
              method:
                get:
                  criteria: "=="
                  responseCode: "200"
            mode: "Continuous"
            runProperties:
              probeTimeout: 5
              interval: 2
              retry: 2

4. Observeer Resultaten

# Watch chaos engine status
kubectl get chaosengine demo-chaos -w

# Check chaos result
kubectl get chaosresult demo-chaos-pod-delete -o yaml

# Watch pod gedrag
kubectl get pods -l app=demo -w

Game Days: Oefenen voor Echte Incidenten

Chaos experimenten testen systemen. Game days testen mensen.

Een Game Day Plannen

Definieer scope: Welke systemen, welke failure scenarios
Stel team samen: Engineers die op echte incidenten zouden reageren
Bereid runbooks voor: Documenteer verwachte responses
Stel succescriteria: Hoe ziet “goed afgehandeld” eruit?
Plan tijd: Dedicated tijd, niet gepropt tussen meetings

Game Day Structuur

09:00 - Briefing: Leg scope uit, regels, hoe af te breken
09:15 - Injecteer failure (team weet niet welke)
09:15 - Team reageert alsof echt incident
10:00 - Failure onthuld, extra scenarios geïntroduceerd
11:00 - Debrief: Wat werkte, wat niet, wat te verbeteren

Voorbeeld Scenarios

Scenario	Wat Je Leert
Dood primaire database	Failover snelheid, data integriteit
DNS storing	Caching gedrag, timeout handling
Certificaat verloopt	Monitoring gaps, renewal proces
Cloud regio onbeschikbaar	Multi-regio readiness
Secrets manager down	Applicatie gedrag zonder secrets

Integreren met GitOps

Chaos experimenten kunnen beheerd worden met ArgoCD:

# chaos-experiments/pod-delete.yaml (in Git)
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: scheduled-pod-delete
  namespace: chaos-testing
spec:
  engineState: 'stop'  # Handmatig geactiveerd
  # ... experiment config

Workflow:

Definieer experimenten in Git
Sync met ArgoCD
Activeer experimenten via engineState: 'active'
Review resultaten
Commit bevindingen en verbeteringen

Veiligheidsrichtlijnen

Wel Doen

Begin met non-productie omgevingen
Heb rollback procedures klaar
Monitor nauwlettend tijdens experimenten
Communiceer met stakeholders
Documenteer alles

Niet Doen

Experimenten draaien tijdens piekverkeer (tenzij dat specifiek getest wordt)
Chaos injecteren zonder het team te waarschuwen
De hypothese stap overslaan
Bevindingen negeren

Afbreek Condities

Definieer wanneer direct te stoppen:

Error rate overschrijdt X%
Latency overschrijdt Y seconden
Klantklachten ontvangen
Elk onverwacht gedrag

# Afbreken bij hoge error rate
probe:
  - name: "error-rate-check"
    type: "promProbe"
    promProbe/inputs:
      endpoint: "http://prometheus:9090"
      query: "rate(http_requests_total{status=~'5..'}[1m])"
      comparator:
        type: "float"
        criteria: "<"
        value: "0.1"  # Afbreken als > 10% errors

Een Chaos Cultuur Bouwen

Chaos engineering is geen tool. Het is een praktijk.

Begin klein:

Draai één experiment in development
Documenteer wat je leert
Deel met het team
Vergroot geleidelijk de scope

Vragen om te beantwoorden:

Wat gebeurt er als een node faalt?
Hoe gedraagt het systeem zich onder geheugendruk?
Wat als network latency 10x toeneemt?
Kunnen we een database replica verliezen zonder downtime?

Elk experiment dat een zwakheid onthult is een productie storing voorkomen.

Mijn Chaos Experimenten

In mijn homelab cluster draai ik regelmatig:

Wekelijkse pod delete: Willekeurige pods in non-kritieke namespaces
Maandelijkse node drain: Simuleer node failure
Kwartaalse volledige game day: Multi-failure scenarios

Wat ik heb geleerd:

Longhorn handelt node failures graceful af
Sommige workloads hebben geen goede terminationGracePeriod
Alerting vuurt vaak te laat
Recovery is altijd langzamer dan verwacht

Waarom Dit Ertoe Doet

Productie zal je systemen testen. De enige vraag is of je ze eerst test.

Chaos engineering transformeert “we denken dat het resilient is” naar “we weten dat het X, Y, en Z failures overleeft.” Het verandert hoop in bewijs.

De systemen die echte storingen overleven zijn degene die ervoor geoefend hebben.

Maak dingen opzettelijk kapot, op jouw voorwaarden, overdag. Of wacht tot ze per ongeluk kapot gaan, om 3 uur ’s nachts, tijdens de drukste dag van het jaar. Jouw keuze.

Waarom Dingen Opzettelijk Kapot Maken?#

Het Chaos Engineering Proces#

1. Definieer Hypothese#

2. Ontwerp Experiment#

3. Draai in Gecontroleerde Omgeving#

4. Observeer en Meet#

5. Leer en Verbeter#

Litmus Chaos: Kubernetes-Native Chaos#

Litmus Installeren#

Litmus Architectuur#

ChaosEngine: Experimenten Declareren#

Essentiële Chaos Experimenten#

Pod-Level Chaos#

Node-Level Chaos#

Network Chaos#

Storage Chaos#

Je Eerste Experiment Draaien#

1. Deploy Test Applicatie#

2. Maak ServiceAccount voor Litmus#

3. Draai Pod Delete Experiment#

4. Observeer Resultaten#

Game Days: Oefenen voor Echte Incidenten#

Een Game Day Plannen#

Game Day Structuur#

Voorbeeld Scenarios#

Integreren met GitOps#

Veiligheidsrichtlijnen#

Wel Doen#

Niet Doen#

Afbreek Condities#

Een Chaos Cultuur Bouwen#

Mijn Chaos Experimenten#

Waarom Dit Ertoe Doet#