CKAD Pod Design: Deployments, Jobs und CronJobs meistern

TL;DR

CKAD Pod Design deckt Deployments, ReplicaSets, Jobs, CronJobs und Labels/Selektoren ab -- zusammen ca. 20% der Pruefung.
Imperative kubectl-Befehle sparen Zeit: kubectl create deployment und kubectl create cronjob statt YAML von Hand.
Rolling Updates steuert ihr ueber maxSurge und maxUnavailable. Rollbacks mit kubectl rollout undo.
Jobs und CronJobs haben eigene Felder wie parallelism, completions, backoffLimit und concurrencyPolicy.
Labels und Selektoren sind die Grundlage fuer alles in Kubernetes -- Services, Deployments und NetworkPolicies nutzen sie.

Warum Pod Design fuer die CKAD entscheidend ist

Der Bereich Pod Design gehoert zu den Domains "Application Design and Build" und "Application Deployment" der CKAD-Pruefung. Zusammen machen diese beiden Domains 40% der Gesamtbewertung aus. Wer Deployments, Jobs und Labels nicht sicher beherrscht, hat in der Pruefung ein ernstes Problem.

In diesem Artikel gehen wir jedes Thema systematisch durch -- mit imperativem kubectl-Befehl, YAML-Manifest und Praxisuebung. Die Struktur orientiert sich am offiziellen CKAD-Curriculum.

Wenn ihr noch keinen Ueberblick ueber die gesamte CKAD-Pruefung habt, lest zuerst den CKAD Zertifizierungs-Guide.

Deployments

Ein Deployment ist die Standardmethode, um zustandslose Anwendungen auf Kubernetes zu betreiben. Es verwaltet ReplicaSets, die wiederum Pods erstellen und ueberwachen.

Deployment erstellen (imperativ)

# Deployment mit 3 Replicas erzeugen
kubectl create deployment webapp --image=nginx:1.27 --replicas=3

# YAML-Vorlage generieren und anpassen
kubectl create deployment webapp --image=nginx:1.27 --replicas=3 \
  --dry-run=client -o yaml > webapp-deploy.yaml

Deployment-Manifest (deklarativ)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 250m
            memory: 256Mi

Deployment skalieren

# Skalieren auf 5 Replicas
kubectl scale deployment webapp --replicas=5

# Autoscaling einrichten (HPA)
kubectl autoscale deployment webapp --min=3 --max=10 --cpu-percent=80

Pruefungstipp: In der CKAD-Pruefung wird oft verlangt, ein Deployment zu erstellen und danach zu skalieren. Nutzt den imperativen Befehl fuer die Erstellung und passt nur bei Bedarf das YAML an.

Rolling Updates und Rollbacks

Kubernetes fuehrt Updates standardmaessig als Rolling Update durch. Das bedeutet: Neue Pods werden schrittweise erstellt, waehrend alte Pods terminiert werden. Es gibt nie einen Moment, in dem die Anwendung komplett offline ist.

Update-Strategie konfigurieren

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.27

maxSurge: Maximale Anzahl zusaetzlicher Pods ueber der gewuenschten Replica-Anzahl waehrend des Updates. 1 bedeutet: maximal 5 Pods bei 4 Replicas.

maxUnavailable: Maximale Anzahl nicht verfuegbarer Pods waehrend des Updates. 1 bedeutet: mindestens 3 von 4 Pods laufen immer.

Updates durchfuehren und pruefen

# Image aktualisieren
kubectl set image deployment/webapp nginx=nginx:1.28

# Update-Status pruefen
kubectl rollout status deployment/webapp

# Rollout-History anzeigen
kubectl rollout history deployment/webapp

# Details einer bestimmten Revision
kubectl rollout history deployment/webapp --revision=2

Rollback ausfuehren

# Zur vorherigen Version zurueck
kubectl rollout undo deployment/webapp

# Zu einer bestimmten Revision zurueck
kubectl rollout undo deployment/webapp --to-revision=1

# Rollout pausieren (z.B. fuer Canary-Tests)
kubectl rollout pause deployment/webapp

# Rollout fortsetzen
kubectl rollout resume deployment/webapp

Pruefungstipp: kubectl rollout undo ist einer der am haeufigsten geforderten Befehle in der CKAD-Pruefung. Uebt ihn, bis er automatisch sitzt.

ReplicaSets

Ein ReplicaSet stellt sicher, dass eine definierte Anzahl identischer Pods laeuft. In der Praxis erstellt man ReplicaSets fast nie direkt -- Deployments uebernehmen das automatisch.

Wann ReplicaSets direkt verwenden?

In der Pruefung kann trotzdem nach einem ReplicaSet gefragt werden. Der Unterschied zum Deployment: Ein ReplicaSet hat keine Update-Strategie.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: webapp-rs
  labels:
    app: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.27

# ReplicaSets eines Deployments anzeigen
kubectl get replicasets -l app=webapp

# Pods eines ReplicaSets anzeigen
kubectl get pods -l app=webapp --show-labels

Merke: Wenn die Pruefungsaufgabe "Deployment" sagt, erstellt ein Deployment. Wenn sie explizit "ReplicaSet" sagt, erstellt ein ReplicaSet. Verwechselt die beiden nicht.

Jobs

Ein Job erstellt einen oder mehrere Pods und stellt sicher, dass diese erfolgreich beendet werden. Im Gegensatz zu Deployments laeuft ein Job nicht dauerhaft -- er hat ein definiertes Ende.

Job erstellen (imperativ)

# Einfachen Job erstellen
kubectl create job backup-job --image=busybox -- sh -c "echo Backup completed"

# YAML-Vorlage generieren
kubectl create job backup-job --image=busybox \
  --dry-run=client -o yaml -- sh -c "echo Backup completed" > job.yaml

Job-Manifest mit erweiterten Optionen

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processor
spec:
  completions: 5
  parallelism: 2
  backoffLimit: 3
  activeDeadlineSeconds: 300
  template:
    spec:
      containers:
      - name: processor
        image: busybox
        command: ["sh", "-c", "echo Processing batch $RANDOM && sleep 10"]
      restartPolicy: Never

Wichtige Job-Felder

Feld	Bedeutung	Default
`completions`	Wie viele Pods erfolgreich beendet werden muessen	1
`parallelism`	Wie viele Pods gleichzeitig laufen duerfen	1
`backoffLimit`	Maximale Anzahl fehlgeschlagener Versuche	6
`activeDeadlineSeconds`	Timeout fuer den gesamten Job	unbegrenzt
`restartPolicy`	Muss `Never` oder `OnFailure` sein	-

# Job-Status pruefen
kubectl get jobs
kubectl describe job data-processor

# Pods eines Jobs anzeigen
kubectl get pods -l job-name=data-processor

# Logs eines Job-Pods lesen
kubectl logs job/data-processor

Wichtig: Bei Jobs muss restartPolicy auf Never oder OnFailure stehen. Always ist nicht erlaubt und fuehrt zu einem Validierungsfehler.

CronJobs

Ein CronJob erstellt Jobs nach einem Zeitplan -- genau wie cron unter Linux.

CronJob erstellen (imperativ)

# CronJob: alle 5 Minuten
kubectl create cronjob log-cleanup --image=busybox \
  --schedule="*/5 * * * *" -- sh -c "echo Cleanup at $(date)"

# YAML-Vorlage generieren
kubectl create cronjob log-cleanup --image=busybox \
  --schedule="*/5 * * * *" \
  --dry-run=client -o yaml -- sh -c "echo Cleanup" > cronjob.yaml

CronJob-Manifest mit erweiterten Optionen

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 200
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: busybox
            command: ["sh", "-c", "echo DB backup started && sleep 30 && echo done"]
          restartPolicy: OnFailure

Cron-Schedule-Syntax

# ┌───────────── Minute (0-59)
# │ ┌───────────── Stunde (0-23)
# │ │ ┌───────────── Tag im Monat (1-31)
# │ │ │ ┌───────────── Monat (1-12)
# │ │ │ │ ┌───────────── Wochentag (0-6, So=0)
# │ │ │ │ │
# * * * * *

Beispiel	Bedeutung
`/5 * * *`	Alle 5 Minuten
`0 * * * *`	Jede volle Stunde
`0 2 * * *`	Taeglich um 2:00 Uhr
`0 0 * * 1`	Jeden Montag um Mitternacht
`0 0 1 * *`	Am 1. jedes Monats

Wichtige CronJob-Felder

Feld	Bedeutung	Default
`concurrencyPolicy`	`Allow`, `Forbid` oder `Replace`	Allow
`startingDeadlineSeconds`	Maximale Verzoegerung bevor Job uebersprungen wird	unbegrenzt
`successfulJobsHistoryLimit`	Wie viele erfolgreiche Jobs aufbewahrt werden	3
`failedJobsHistoryLimit`	Wie viele fehlgeschlagene Jobs aufbewahrt werden	1
`suspend`	CronJob pausieren (true/false)	false

concurrencyPolicy erklaert:

Allow: Mehrere Jobs koennen gleichzeitig laufen (Default).
Forbid: Neuer Job wird uebersprungen, wenn der vorherige noch laeuft.
Replace: Laufender Job wird abgebrochen und durch neuen ersetzt.

# CronJobs auflisten
kubectl get cronjobs

# Manuell einen Job aus einem CronJob ausloesen
kubectl create job manual-backup --from=cronjob/db-backup

Labels und Selektoren

Labels sind Schluessel-Wert-Paare, die an jede Kubernetes-Ressource angehaengt werden koennen. Selektoren filtern Ressourcen anhand dieser Labels. Praktisch jede Kubernetes-Abstraktion nutzt Labels: Services finden ihre Pods ueber Labels, Deployments verwalten ReplicaSets ueber Labels, NetworkPolicies selektieren Pods ueber Labels.

Labels setzen und abfragen

# Label beim Erstellen setzen
kubectl run web --image=nginx:1.27 --labels="app=web,env=prod,tier=frontend"

# Label nachtraeglich hinzufuegen
kubectl label pod web version=v1

# Label aendern
kubectl label pod web version=v2 --overwrite

# Label entfernen
kubectl label pod web version-

# Pods nach Labels filtern
kubectl get pods -l app=web
kubectl get pods -l app=web,env=prod
kubectl get pods -l 'env in (prod,staging)'
kubectl get pods -l 'env notin (dev)'
kubectl get pods -l '!tier'

# Labels aller Pods anzeigen
kubectl get pods --show-labels

matchLabels vs. matchExpressions

In Deployment-Selektoren und anderen Ressourcen koennt ihr zwei Arten von Selektoren verwenden:

# Einfacher Selektor mit matchLabels
selector:
  matchLabels:
    app: webapp
    env: prod

# Erweiterter Selektor mit matchExpressions
selector:
  matchExpressions:
  - key: env
    operator: In
    values: ["prod", "staging"]
  - key: tier
    operator: NotIn
    values: ["cache"]
  - key: app
    operator: Exists

Verfuegbare Operatoren: In, NotIn, Exists, DoesNotExist

Pruefungstipp: In der CKAD-Pruefung reicht fast immer matchLabels. matchExpressions wird selten abgefragt, aber ihr solltet die Syntax kennen.

5 Uebungsaufgaben mit Loesungen

Uebung 1: Deployment mit Rolling Update

Aufgabe: Erstelle Deployment api-server im Namespace exam mit Image httpd:2.4, 4 Replicas, maxSurge 2, maxUnavailable 0. Aktualisiere dann auf httpd:2.4.58 und pruefe den Status.

Loesung:

kubectl create namespace exam

kubectl create deployment api-server --image=httpd:2.4 --replicas=4 -n exam \
  --dry-run=client -o yaml > api-server.yaml

Editiert die YAML-Datei und fuegt die Strategy hinzu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  namespace: exam
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 0
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: httpd
        image: httpd:2.4

kubectl apply -f api-server.yaml
kubectl set image deployment/api-server httpd=httpd:2.4.58 -n exam
kubectl rollout status deployment/api-server -n exam

Uebung 2: Job mit Parallelitaet

Aufgabe: Erstelle Job batch-process im Namespace exam. Image: busybox. Befehl: echo "Processing item". Es sollen insgesamt 6 Items verarbeitet werden, maximal 3 gleichzeitig. BackoffLimit: 2.

Loesung:

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-process
  namespace: exam
spec:
  completions: 6
  parallelism: 3
  backoffLimit: 2
  template:
    spec:
      containers:
      - name: processor
        image: busybox
        command: ["sh", "-c", "echo Processing item && sleep 5"]
      restartPolicy: Never

kubectl apply -f batch-process.yaml
kubectl get jobs -n exam -w
kubectl get pods -n exam -l job-name=batch-process

Uebung 3: CronJob mit concurrencyPolicy

Aufgabe: Erstelle CronJob metrics-export im Namespace exam. Alle 10 Minuten, Image busybox, Befehl: echo "Exporting metrics". ConcurrencyPolicy: Forbid. SuccessfulJobsHistoryLimit: 5.

Loesung:

kubectl create cronjob metrics-export --image=busybox \
  --schedule="*/10 * * * *" -n exam \
  --dry-run=client -o yaml -- sh -c "echo Exporting metrics" > metrics-cj.yaml

Ergaenzt die fehlenden Felder:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: metrics-export
  namespace: exam
spec:
  schedule: "*/10 * * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 5
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: metrics-export
            image: busybox
            command: ["sh", "-c", "echo Exporting metrics"]
          restartPolicy: OnFailure

kubectl apply -f metrics-cj.yaml
kubectl get cronjobs -n exam

Uebung 4: Rollback zu bestimmter Revision

Aufgabe: Erstelle Deployment frontend (nginx:1.24, 2 Replicas) im Namespace exam. Fuehre zwei Updates durch (nginx:1.25, dann nginx:1.26). Rollback zur allerersten Version (nginx:1.24).

Loesung:

kubectl create deployment frontend --image=nginx:1.24 --replicas=2 -n exam
kubectl set image deployment/frontend nginx=nginx:1.25 -n exam
kubectl set image deployment/frontend nginx=nginx:1.26 -n exam

# History pruefen
kubectl rollout history deployment/frontend -n exam

# Zur Revision 1 zurueck (nginx:1.24)
kubectl rollout undo deployment/frontend --to-revision=1 -n exam

# Verifizieren
kubectl describe deployment frontend -n exam | grep Image

Uebung 5: Label-basierte Abfragen

Aufgabe: Erstelle drei Pods im Namespace exam: pod-a (Labels: app=web, env=prod), pod-b (Labels: app=web, env=staging), pod-c (Labels: app=api, env=prod). Finde dann alle Pods mit app=web. Finde alle Pods mit env=prod ODER env=staging. Finde alle Pods OHNE Label tier.

Loesung:

kubectl run pod-a --image=nginx:1.27 -n exam --labels="app=web,env=prod"
kubectl run pod-b --image=nginx:1.27 -n exam --labels="app=web,env=staging"
kubectl run pod-c --image=nginx:1.27 -n exam --labels="app=api,env=prod"

# Alle Pods mit app=web (pod-a, pod-b)
kubectl get pods -n exam -l app=web

# Alle Pods mit env=prod ODER env=staging (alle drei)
kubectl get pods -n exam -l 'env in (prod,staging)'

# Alle Pods ohne Label tier (alle drei, da keiner tier hat)
kubectl get pods -n exam -l '!tier'

# Bonus: Labels aller Pods anzeigen
kubectl get pods -n exam --show-labels

Zusammenfassung: CKAD Pod Design Cheat Sheet

Thema	Imperativer Befehl
Deployment erstellen	`kubectl create deployment NAME --image=IMG --replicas=N`
Skalieren	`kubectl scale deployment NAME --replicas=N`
Image-Update	`kubectl set image deployment/NAME CONTAINER=IMG`
Rollback	`kubectl rollout undo deployment/NAME`
Job erstellen	`kubectl create job NAME --image=IMG -- COMMAND`
CronJob erstellen	`kubectl create cronjob NAME --image=IMG --schedule="CRON" -- CMD`
Labels setzen	`kubectl label pod NAME key=value`
Label-Filter	`kubectl get pods -l key=value`

Nutzt diese Befehle in der Pruefung als Ausgangspunkt und passt das generierte YAML nur bei Bedarf an. Das spart wertvolle Minuten.

Weitere CKAD-Uebungsaufgaben findet ihr in unserem Hands-on Uebungsartikel. Den vollstaendigen Lernplan fuer die CKA findet ihr im 8-Wochen-Lernplan.

CKAD Pod Design: Deployments, Jobs und CronJobs meistern

TL;DR

Warum Pod Design fuer die CKAD entscheidend ist

Deployments

Deployment erstellen (imperativ)

Deployment-Manifest (deklarativ)

Deployment skalieren

Rolling Updates und Rollbacks

Update-Strategie konfigurieren

Updates durchfuehren und pruefen

Rollback ausfuehren

ReplicaSets

Wann ReplicaSets direkt verwenden?

Jobs

Job erstellen (imperativ)

Job-Manifest mit erweiterten Optionen

Wichtige Job-Felder

CronJobs

CronJob erstellen (imperativ)

CronJob-Manifest mit erweiterten Optionen

Cron-Schedule-Syntax

Wichtige CronJob-Felder

Labels und Selektoren

Labels setzen und abfragen

matchLabels vs. matchExpressions

5 Uebungsaufgaben mit Loesungen

Uebung 1: Deployment mit Rolling Update

Uebung 2: Job mit Parallelitaet

Uebung 3: CronJob mit concurrencyPolicy

Uebung 4: Rollback zu bestimmter Revision

Uebung 5: Label-basierte Abfragen

Zusammenfassung: CKAD Pod Design Cheat Sheet

Verwandte Artikel

Kubernetes-Beratung gesucht?

📖 Verwandte Artikel

CKA vs CKAD vs CKS: Welche Zertifizierung wählen?

CKAD Übungsaufgaben: 20 Hands-on Aufgaben mit Lösungen

CKA, CKAD und CKS Erfahrungsbericht: Mein Weg zum Bestehen

Kubernetes Schulung: 90-Tage-Plan bis zur CKA

Kubestronaut werden: Karriere-Guide für Kubernetes-Engineers