Ein Cluster, den du kaputtmachen darfst
Ein verwalteter Cluster beim Cloud-Anbieter nützt dir für die CKA wenig, weil du dort nie an die Control Plane kommst. Du brauchst zwei Umgebungen.
Nimm kind für alles, was innerhalb von Pods passiert, und ein kubeadm-Cluster aus zwei bis drei virtuellen Maschinen für alles, was an der Control Plane, am kubelet oder an etcd hängt. Nur im zweiten Aufbau existieren /etc/kubernetes/manifests und /var/lib/kubelet/config.yaml, und genau darum drehen sich die teuersten Prüfungsaufgaben.
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: workerStart mit kind create cluster --name uebung --config kind-cluster.yaml. Der Cluster ist in unter einer Minute da und genauso schnell wieder weg, ideal für CKAD-Drills. Für CKA-Themen reicht es nicht: die Knoten sind Container, ein kaputtes kubelet debuggst du dort nicht realistisch.
# etcd-Snapshot ziehen, bevor du etwas kaputt machst
sudo etcdctl \
--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 \
snapshot save /opt/etcd-uebung.db
# Danach ruhig Unsinn bauen und die Reparatur üben
sudo mv /etc/kubernetes/manifests/kube-scheduler.yaml /tmp/
kubectl -n kube-system get pod # der Scheduler verschwindet nach Sekunden
sudo journalctl -u kubelet -f # hier stehen die Fehler, nicht in kubectlStatic Pods im Verzeichnis /etc/kubernetes/manifests startet das kubelet direkt, ohne API-Server. Ein Tippfehler dort erzeugt deshalb kein Event in kubectl get events, sondern nur eine Zeile im Journal. Wer diesen Reflex nicht trainiert hat, sucht in der Prüfung an der falschen Stelle.