- Authors

- Name
- Phillip Pham
- @ddppham
TL;DR
- 8 Wochen genuegen fuer die CKA-Vorbereitung bei taeglich 1-2 Stunden unter der Woche und 3-4 Stunden am Wochenende.
- Woche 1-2: Cluster Architecture und etcd. Woche 3: Workloads. Woche 4: Scheduling. Woche 5: Networking. Woche 6: Storage. Woche 7: Troubleshooting. Woche 8: Mock Exams.
- Jede Woche hat konkrete Lernziele, praktische Uebungen und einen Meilenstein.
- Insgesamt ca. 100-120 Stunden Vorbereitung -- verteilt auf Theorie, Praxis und Simulation.
- Der CKA-Lernplan setzt grundlegende Linux- und Container-Kenntnisse voraus.
Voraussetzungen
Bevor ihr mit dem 8-Wochen-CKA-Lernplan startet, solltet ihr diese Grundlagen mitbringen:
- Linux-Basics: Dateisystem-Navigation, Berechtigungen, systemctl, journalctl
- Container-Grundlagen: Docker oder containerd, Images bauen und starten
- Netzwerk-Basics: IP-Adressen, DNS, Ports, TCP/UDP
- YAML-Syntax: Grundstruktur lesen und schreiben koennen
Einen vollstaendigen Ueberblick ueber die CKA-Pruefung findet ihr in unserem CKA Zertifizierungs-Guide 2026.
Zeitplanung im Ueberblick
| Woche | Thema | Stunden/Woche | Meilenstein |
|---|---|---|---|
| 1 | Cluster Setup und etcd | 10-12h | kind-Cluster aufgesetzt, etcd-Backup geuebt |
| 2 | API-Server, Scheduler, kubeadm | 10-12h | kubeadm-Upgrade durchgefuehrt |
| 3 | Workloads: Deployments, DaemonSets, Jobs | 10-12h | Alle Workload-Typen imperativ erstellt |
| 4 | Scheduling: Affinity, Taints, Tolerations | 10-12h | Scheduling-Szenarien geloest |
| 5 | Services, Networking, NetworkPolicies | 10-12h | NetworkPolicy-Lab bestanden |
| 6 | Storage: PV, PVC, StorageClasses | 8-10h | Stateful App mit PVC deployed |
| 7 | Troubleshooting: Systematisches Debugging | 10-12h | 5 Fehlerszenarios geloest |
| 8 | Mock Exams, killer.sh, Review | 12-15h | killer.sh mit 70%+ bestanden |
Gesamtaufwand: ca. 100-120 Stunden
Woche 1-2: Cluster Architecture, etcd und kubeadm
Lernziele: Kubernetes-Architektur verstehen, etcd-Backup/-Restore beherrschen, kubeadm-Upgrades durchfuehren.
Theorie: Control Plane vs. Worker Nodes, Static Pods (/etc/kubernetes/manifests/), etcd Consensus, kubeadm-Workflow, API-Server-Flags, TLS-Zertifikate.
# Lokalen Cluster mit kind aufsetzen
cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF
# etcd-Backup erstellen
ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# etcd Restore
ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db \
--data-dir=/var/lib/etcd-restored
# kubeadm-Upgrade-Prozess (Control Plane)
kubeadm upgrade plan
kubeadm upgrade apply v1.30.0
# Worker Node upgraden
kubectl cordon worker-1
kubectl drain worker-1 --ignore-daemonsets --delete-emptydir-data
# Auf dem Worker: kubeadm upgrade node, kubelet neu starten
kubectl uncordon worker-1
Meilenstein: etcd-Backup/-Restore und kubeadm-Upgrade sitzen.
Woche 3: Workloads -- Deployments, DaemonSets, Jobs
Lernziele: Alle Workload-Ressourcen erstellen, Rolling Updates und Rollbacks, Init Containers.
# Deployment erstellen und skalieren
kubectl create deployment nginx --image=nginx:1.27 --replicas=3
kubectl scale deployment nginx --replicas=5
# Rolling Update und Rollback
kubectl set image deployment/nginx nginx=nginx:1.28
kubectl rollout status deployment/nginx
kubectl rollout undo deployment/nginx
# Job und CronJob
kubectl create job backup --image=busybox -- /bin/sh -c "echo done"
kubectl create cronjob daily-backup --image=busybox \
--schedule="0 2 * * *" -- /bin/sh -c "echo backup"
Pruefungstipp: DaemonSets haben keinen imperativen Befehl. Erstellt ein Deployment mit --dry-run=client -o yaml, aendert kind: Deployment zu kind: DaemonSet und entfernt replicas und strategy.
Meilenstein: Alle Workload-Typen imperativ erstellen, Rolling Updates beherrschen.
Woche 4: Scheduling -- Affinity, Taints, Tolerations
Lernziele: Pods gezielt auf Nodes schedulen, Taints/Tolerations verstehen, Resource Requests und Limits.
# Node Labels und Taints
kubectl label nodes worker-1 disktype=ssd
kubectl taint nodes worker-1 dedicated=gpu:NoSchedule
kubectl taint nodes worker-1 dedicated=gpu:NoSchedule- # entfernen
# Pod mit Node Affinity und Toleration
apiVersion: v1
kind: Pod
metadata:
name: scheduled-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd
tolerations:
- key: "dedicated"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
containers:
- name: app
image: nginx:1.27
resources:
requests:
cpu: "500m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
Fuer praktische Tipps zur Pruefung selbst lest CKA Pruefung bestehen: 10 Tipps.
Meilenstein: Scheduling-Szenarien mit Affinity, Taints und Resources loesen.
Woche 5: Services, Networking und NetworkPolicies
Lernziele: Service-Typen, Ingress, NetworkPolicies, Kubernetes-DNS (CoreDNS).
# Services erstellen
kubectl expose deployment webapp --port=80 --type=ClusterIP
kubectl expose deployment webapp --port=80 --type=NodePort
# DNS testen
kubectl run dns-test --image=busybox:1.36 --rm -it --restart=Never \
-- nslookup webapp.default.svc.cluster.local
# Ingress-Ressource
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: webapp-ingress
spec:
ingressClassName: nginx
rules:
- host: webapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: webapp
port:
number: 80
---
# NetworkPolicy: Default Deny und selektive Freigabe
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend
namespace: production
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
Fuer fortgeschrittene NetworkPolicy-Szenarien lest Kubernetes Network Policies Advanced.
Meilenstein: Services, Ingress und NetworkPolicies ohne Doku konfigurieren.
Woche 6: Storage -- PV, PVC, StorageClasses
Lernziele: PV/PVC erstellen und binden, StorageClasses, Volumes in Pods mounten.
# PersistentVolume und PVC
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-storage
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: /mnt/data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-app
spec:
accessModes:
- ReadWriteOnce
storageClassName: manual
resources:
requests:
storage: 5Gi
---
# Pod mit PVC
apiVersion: v1
kind: Pod
metadata:
name: app-with-storage
spec:
containers:
- name: app
image: nginx:1.27
volumeMounts:
- name: data
mountPath: /usr/share/nginx/html
volumes:
- name: data
persistentVolumeClaim:
claimName: pvc-app
Pruefungstipp: storageClassName und accessModes muessen zwischen PV und PVC uebereinstimmen. Stimmen sie nicht, bleibt der PVC Pending.
Meilenstein: Stateful App mit PVC deployed, Binding-Probleme debuggen.
Woche 7: Troubleshooting
Lernziele: Systematisches Debugging von Cluster-, Node- und Pod-Problemen.
# Systematischer Troubleshooting-Workflow
# 1. Cluster-Status
kubectl get nodes
kubectl cluster-info
# 2. Node-Probleme
kubectl describe node worker-1
systemctl status kubelet
journalctl -u kubelet -f
# 3. Pod-Probleme
kubectl get pods -A -o wide
kubectl describe pod problem-pod
kubectl logs problem-pod
kubectl logs problem-pod --previous
# 4. Netzwerk-Debugging
kubectl run debug --image=busybox:1.36 --rm -it --restart=Never \
-- wget -qO- http://service-name:80
# Haeufige Fehler:
# CrashLoopBackOff -> Logs pruefen, Command/Entrypoint
# ImagePullBackOff -> Image-Name, Registry, Pull-Secret
# Pending -> Resources, Taints, NodeSelector
# ContainerCreating -> Volumes, Secrets, ConfigMaps
Meilenstein: 5 verschiedene Fehlerszenarios systematisch diagnostizieren und loesen.
Woche 8: Mock Exams und Review
# Pruefungsumgebung vorbereiten (am Pruefungstag als Erstes)
alias k=kubectl
export do="--dry-run=client -o yaml"
export now="--force --grace-period=0"
source <(kubectl completion bash)
complete -o default -F __start_kubectl k
cat << 'EOF' > ~/.vimrc
set tabstop=2
set shiftwidth=2
set expandtab
set number
set autoindent
EOF
| Tag | Aktivitaet | Dauer |
|---|---|---|
| Mo | killer.sh Session 1 unter Zeitdruck | 2-3h |
| Di | Fehleranalyse: falsche Aufgaben durcharbeiten | 2h |
| Mi | Schwaechen-Themen gezielt wiederholen | 2h |
| Do | Weitere Mock Exams (Kodekloud o.ae.) | 2h |
| Fr | killer.sh Session 2 unter Pruefungsbedingungen | 2-3h |
| Sa | Letzte Fehleranalyse, Cheat-Sheet finalisieren | 3h |
| So | Ruhetag oder leichte Wiederholung | 1h |
Wichtig: killer.sh ist schwerer als die echte Pruefung. 60-70% bei killer.sh bedeuten gute Chancen in der echten CKA.
Verwandte Artikel
- CKA Pruefung bestehen: 10 Tipps
- CKA-Zertifizierung 2026: Pruefungsinhalte und Tipps
- CKS Zertifizierung 2026
- CKAD Zertifizierung 2026
- Kubernetes Hands-on Tutorial
Ihr braucht einen massgeschneiderten CKA-Lernplan fuer euer Team oder Hands-on-Workshops? Sprecht uns an unter /kontakt.
Kubernetes-Beratung gesucht?
Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.
📖 Verwandte Artikel
Weitere interessante Beiträge zu ähnlichen Themen
Kubernetes Zertifizierung: Lerngruppe und Community finden
Lerngruppe für die Kubernetes-Zertifizierung finden: Die besten Communities auf Discord, Slack und Meetups für CKA, CKAD und CKS Vorbereitung.
CKA vs CKAD vs CKS: Welche Zertifizierung wählen?
CKA, CKAD und CKS im detaillierten Vergleich: Prüfungsinhalte, Schwierigkeitsgrad, Überlappungen, Karrierepfade und empfohlene Reihenfolge.
CKA Cluster Architecture: etcd, API Server und Control Plane
Control-Plane-Komponenten für die CKA-Prüfung verstehen: API Server, etcd Backup und Restore, Scheduler und HA-Setup mit praktischen Beispielen.
CKA Mock Exam: Beste Übungsprüfungen im Vergleich
Die besten CKA Mock Exams im Vergleich: Killer.sh, KodeKloud und Killercoda mit Bewertung, optimaler Nutzung und Zeitplanung vor der Prüfung.
CKA Prüfung bestehen: 10 Praxis-Tipps
CKA beim ersten Anlauf bestehen mit diesen zehn Tipps: kubectl Aliases, Zeitmanagement, Dokumentation nutzen und häufige Fehler vermeiden.