Kubernetes-Prüfung: 01 Fundamentals
Schwierigkeitsgrad: Fundamentals
Sprache: Deutsch
Format: schriftliche Prüfung mit kleinem Hands-on-Anteil
Empfohlene Dauer: 90 bis 120 Minuten
Maximalpunktzahl: 100 Punkte
Bestehensgrenze: 70 Punkte
Diese Prüfung enthält Aufgaben, Abgabeanforderungen und Bewertungsraster. Sie enthält keine vollständige Musterlösung.
1. Prüfungsziel
Die Prüfung weist nach, dass du Kubernetes-Grundlagen sicher einordnen und einfache Workloads kontrolliert ausrollen kannst. Der Fokus liegt auf Grundbegriffen, Objektmodell, kubectl, Namespaces, Pods, Deployments, ReplicaSets, Services, Labels, Selectors, ConfigMaps, Secrets, Rollouts und erster Fehlerdiagnose.
Nach der Prüfung soll erkennbar sein, dass du:
- den Zweck von Kubernetes und das Prinzip des gewünschten Zustands erklären kannst,
- zentrale Cluster-Komponenten fachlich einordnest,
- einfache YAML-Manifeste lesen und erstellen kannst,
- Ressourcen in einem eigenen Namespace ausrollst,
- Services über Labels und Selectors mit Pods verbindest,
- Logs, Events und Rollout-Status zur Diagnose nutzt,
- einfache Fehler wie falsches Image, falscher Selector und CrashLoopBackOff systematisch untersuchst,
- Lab-Ressourcen sauber dokumentierst und zurückbauen kannst.
2. Voraussetzungen und erlaubte Hilfsmittel
Du brauchst:
- einen ungefährlichen Kubernetes-Lab-Cluster, zum Beispiel
kind,minikube,k3doder eine bereitgestellte Lab-Umgebung, kubectl,- Schreibrechte in einem eigenen Namespace,
- eine Shell und einen Texteditor.
Erlaubt sind:
- die offizielle Kubernetes-Dokumentation,
- eigene Notizen aus dem Workshop,
kubectl explain,kubectl api-resources,kubectl describe,kubectl logsundkubectl get events.
Nicht erlaubt sind:
- produktive Cluster-Kontexte,
- echte Zugangsdaten, Tokens oder privaten Schlüssel,
- fertige Musterlösungen aus früheren Prüfungen,
- Änderungen außerhalb des Prüfungs-Namespace.
Empfohlener Namespace:
export NS=exam-fundamentals
3. Ausgangsszenario
Ein Team möchte eine sehr einfache interne Webanwendung in Kubernetes betreiben. Die Anwendung soll aus einem Deployment mit zwei Replikaten bestehen und intern über einen ClusterIP-Service erreichbar sein. Die Konfiguration soll teilweise über eine ConfigMap und ein Beispiel-Secret bereitgestellt werden.
Der Cluster ist ein Lab-Cluster. Es geht nicht um produktive Hochverfügbarkeit, sondern um korrekte Grundbedienung, nachvollziehbare Manifeste und saubere Diagnose.
4. Erwartete Abgabe
Gib am Ende einen Ordner oder ein Archiv mit folgenden Dateien ab:
01-fundamentals-abgabe/
answers.md
namespace.yml
deployment.yml
service.yml
configmap.yml
secret.yml
evidence.md
cleanup.md
answers.md enthält die Antworten auf die Wissensfragen und die Manifest-Analyse.
evidence.md enthält relevante Ausgaben oder kurze Zusammenfassungen von kubectl get, describe, logs, Events und Rollout-Status.
cleanup.md enthält den Rückbauweg.
5. Teil A: Wissensfragen
Beantworte die Fragen präzise. Eine gute Antwort nennt Zweck, relevante Ressource oder Komponente, typische Fehlerquelle und mindestens eine Validierungsmöglichkeit.
- Was ist der Zweck von Kubernetes, und was bedeutet deklarativer gewünschter Zustand?
- Welche Aufgabe hat der API Server?
- Warum ist
etcdkritisch für einen Kubernetes-Cluster? - Welche Rolle haben Scheduler, Controller Manager und kubelet?
- Was ist der Unterschied zwischen Pod, ReplicaSet und Deployment?
- Warum werden Pods im Normalbetrieb selten direkt erstellt?
- Wie findet ein Service seine Pods?
- Was ist der Unterschied zwischen Label und Annotation?
- Was ist ein Namespace, und welche Sicherheitsgrenze ersetzt er nicht?
- Wofür nutzt man ConfigMaps, und wofür nutzt man Secrets?
- Warum ist Base64 bei Kubernetes Secrets keine Verschlüsselung?
- Welche Befehle nutzt du zuerst bei
ImagePullBackOff,CrashLoopBackOffund Service ohne Endpoints?
6. Teil B: Manifest-Analyse
Analysiere das folgende Manifest schriftlich.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: exam-fundamentals
labels:
app: web
tier: frontend
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
tier: frontend
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
Beantworte:
- Welche API-Gruppe und Version werden verwendet?
- Welche Ressource wird erstellt?
- Wo steht der gewünschte Zustand?
- Welche Labels erhält das Deployment, und welche Labels erhalten die Pods?
- Welche Rolle spielt
spec.selector.matchLabels? - Warum müssen Selector und Pod-Template-Labels zusammenpassen?
- Welche Ressource erzeugt das Deployment indirekt?
- Wie würdest du prüfen, ob der Rollout erfolgreich war?
7. Teil C: Praxisaufgabe
Aufgabe C1: Namespace vorbereiten
- Prüfe den aktiven Kontext.
- Erstelle den Namespace
exam-fundamentals. - Setze den Namespace für den aktuellen Kontext oder nutze konsequent
-n exam-fundamentals. - Dokumentiere Clustername, Node-Anzahl und Client-Version.
Erwartete Nachweise:
kubectl config current-context
kubectl get nodes -o wide
kubectl get namespace exam-fundamentals
Aufgabe C2: Deployment ausrollen
Erstelle deployment.yml für eine Webanwendung mit diesen Anforderungen:
- Ressource:
Deployment - Name:
web - Namespace:
exam-fundamentals - Image:
nginx:1.27 - Replikate:
2 - Labels:
app=web,tier=frontend,environment=exam - Container-Port:
80
Wende das Manifest an und prüfe:
kubectl apply --dry-run=server -f deployment.yml
kubectl apply -f deployment.yml
kubectl rollout status deployment/web -n exam-fundamentals
kubectl get deployment,replicaset,pod -n exam-fundamentals
Aufgabe C3: Service erstellen
Erstelle service.yml mit diesen Anforderungen:
- Ressource:
Service - Name:
web - Typ:
ClusterIP - Selector:
app=web - Port:
80 - TargetPort:
80
Prüfe Service, Endpoints und EndpointSlices.
kubectl get svc,endpoints,endpointslices -n exam-fundamentals
kubectl describe svc web -n exam-fundamentals
Aufgabe C4: ConfigMap und Secret einbinden
Erstelle eine ConfigMap web-config mit:
APP_MODE=exam
WELCOME_TEXT=Hallo aus der Fundamentals-Prüfung
Erstelle ein Secret web-secret mit stringData:
DEMO_PASSWORD=not-a-real-secret
Erweitere das Deployment so, dass:
APP_MODEals Environment-Variable im Container verfügbar ist,- das Secret als Datei unter
/etc/demo-secretread-only gemountet wird.
Wichtig: Verwende kein echtes Passwort und keinen echten Token.
Aufgabe C5: Rollout, Skalierung und Rollback
- Skaliere das Deployment auf drei Replikate.
- Ändere das Image auf
nginx:1.26. - Prüfe Rollout-Status und Rollout-History.
- Führe ein Rollback durch.
- Dokumentiere, welches Image nach dem Rollback aktiv ist.
Geeignete Befehle:
kubectl scale deployment/web --replicas=3 -n exam-fundamentals
kubectl set image deployment/web nginx=nginx:1.26 -n exam-fundamentals
kubectl rollout status deployment/web -n exam-fundamentals
kubectl rollout history deployment/web -n exam-fundamentals
kubectl rollout undo deployment/web -n exam-fundamentals
8. Teil D: Diagnose und kurze Betriebsnotiz
Aufgabe D1: Service ohne Endpoints
Verändere den Service-Selector absichtlich auf einen falschen Wert, zum Beispiel:
selector:
app: wrong-web
Dokumentiere:
- Symptom,
- Diagnosekommando,
- Ursache,
- Fix,
- Validierung nach dem Fix.
Aufgabe D2: Fehlerbild erklären
Erkläre jeweils kurz Diagnose und wahrscheinlichste Ursache für:
| Fehlerbild | Erwartete Diagnose |
|---|---|
ImagePullBackOff |
Welche Events prüfst du? |
CrashLoopBackOff |
Welche Logs prüfst du? |
| Service ohne Endpoints | Welche Labels, Selector und Endpoints prüfst du? |
Pod bleibt Pending |
Welche Events und Node-/Ressourceninformationen prüfst du? |
Aufgabe D3: Betriebsnotiz
Erstelle eine kurze Betriebsnotiz in evidence.md mit:
- Kontext und Namespace,
- angewendeten Manifesten,
- erzeugten Ressourcen,
- wichtigsten Prüfkommandos,
- gefundenem Fehler und Fix,
- Rückbauweg.
9. Bewertung
| Bereich | Punkte | Erwartung |
|---|---|---|
| Wissensfragen | 24 | Begriffe korrekt, knapp und mit Kubernetes-Bezug erklärt |
| Manifest-Analyse | 16 | apiVersion, kind, metadata, spec, Selector und Rollout verstanden |
| Praxisaufgabe | 34 | Namespace, Deployment, Service, ConfigMap, Secret, Skalierung und Rollback funktionieren |
| Diagnose | 16 | Logs, Events, Rollout-Status, Selector und Endpoints methodisch genutzt |
| Dokumentation und Rückbau | 10 | Abgabe nachvollziehbar, keine echten Secrets, Cleanup dokumentiert |
| Summe | 100 |
Bewertungsskala:
| Punkte | Ergebnis |
|---|---|
| 90–100 | sehr gut bestanden |
| 80–89 | gut bestanden |
| 70–79 | bestanden |
| 0–69 | nicht bestanden |
10. K.-o.-Kriterien
Die Prüfung gilt unabhängig von der Punktzahl als nicht bestanden, wenn eines dieser Kriterien zutrifft:
- Es wird ein produktiver oder fremder Cluster-Kontext verwendet.
- Es werden echte Zugangsdaten, Tokens oder privaten Schlüssel in Manifeste geschrieben.
- Ressourcen werden außerhalb des Prüfungs-Namespace erstellt, ohne dass die Aufgabe es verlangt.
- Es gibt keine nachvollziehbare Abgabe der erstellten Manifeste.
- Die Diagnose besteht nur aus Raten und enthält keine Events, Logs oder Statusausgaben.
11. Prüfer-Checkliste
| Kriterium | Erfüllt? |
|---|---|
| Kontext vor Anwendung geprüft | ☐ |
Namespace exam-fundamentals verwendet |
☐ |
| Deployment mit zwei oder drei Replikaten korrekt erstellt | ☐ |
| Service hat nach Fix passende Endpoints | ☐ |
| ConfigMap und Secret korrekt eingebunden | ☐ |
| Rollout, Skalierung und Rollback dokumentiert | ☐ |
| Fehlerdiagnose nutzt Events, Logs und Endpoints | ☐ |
| Rückbau dokumentiert | ☐ |