Veröffentlicht am

CKA Lernplan: In 8 Wochen zur Zertifizierung

Teilen:
Authors

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

WocheThemaStunden/WocheMeilenstein
1Cluster Setup und etcd10-12hkind-Cluster aufgesetzt, etcd-Backup geuebt
2API-Server, Scheduler, kubeadm10-12hkubeadm-Upgrade durchgefuehrt
3Workloads: Deployments, DaemonSets, Jobs10-12hAlle Workload-Typen imperativ erstellt
4Scheduling: Affinity, Taints, Tolerations10-12hScheduling-Szenarien geloest
5Services, Networking, NetworkPolicies10-12hNetworkPolicy-Lab bestanden
6Storage: PV, PVC, StorageClasses8-10hStateful App mit PVC deployed
7Troubleshooting: Systematisches Debugging10-12h5 Fehlerszenarios geloest
8Mock Exams, killer.sh, Review12-15hkiller.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
TagAktivitaetDauer
Mokiller.sh Session 1 unter Zeitdruck2-3h
DiFehleranalyse: falsche Aufgaben durcharbeiten2h
MiSchwaechen-Themen gezielt wiederholen2h
DoWeitere Mock Exams (Kodekloud o.ae.)2h
Frkiller.sh Session 2 unter Pruefungsbedingungen2-3h
SaLetzte Fehleranalyse, Cheat-Sheet finalisieren3h
SoRuhetag oder leichte Wiederholung1h

Wichtig: killer.sh ist schwerer als die echte Pruefung. 60-70% bei killer.sh bedeuten gute Chancen in der echten CKA.


Verwandte Artikel


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