CKA Cluster Architecture: etcd, API Server und Control Plane

TL;DR

Die CKA-Domain "Cluster Architecture, Installation and Configuration" macht 25% der Pruefung aus -- die zweitgroesste Domain.
etcd Backup und Restore ist eine der haeufigsten CKA-Pruefungsaufgaben. Die etcdctl-Befehle muessen sitzen.
Alle Control-Plane-Komponenten laufen als Static Pods unter /etc/kubernetes/manifests/ -- das ist fuer Troubleshooting entscheidend.
Der kube-apiserver ist der zentrale Einstiegspunkt: Jede Interaktion mit dem Cluster laeuft ueber ihn.
HA-Setups mit mehreren Control Planes werden in der Pruefung konzeptionell abgefragt, nicht praktisch aufgebaut.

CKA Cluster Architecture im Ueberblick

Die Domain "Cluster Architecture, Installation and Configuration" ist mit 25% Gewichtung eine der wichtigsten Saeulen der CKA-Pruefung. Sie testet, ob ihr versteht, wie ein Kubernetes-Cluster aufgebaut ist und wie die einzelnen Komponenten zusammenspielen.

In der Praxis bedeutet das: Ihr muesst wissen, welche Prozesse auf der Control Plane laufen, wie etcd gesichert und wiederhergestellt wird, wie Static Pods funktionieren und wie der Scheduler Entscheidungen trifft.

Fuer den vollstaendigen CKA-Ueberblick mit allen Domains empfehlen wir den CKA Zertifizierungs-Guide 2026.

kube-apiserver: Das Herzschlag des Clusters

Der kube-apiserver ist die einzige Komponente, mit der alle anderen Komponenten direkt kommunizieren. Er ist der zentrale API-Endpunkt fuer kubectl, das Dashboard, Operator-Controller und interne Dienste.

Aufgaben des API Servers

Empfaengt und validiert alle API-Requests (REST)
Authentifizierung und Autorisierung (Zertifikate, Tokens, RBAC)
Serialisiert Objekte und schreibt sie in etcd
Benachrichtigt andere Komponenten ueber Watch-Mechanismen

API Server pruefen

# API Server Pod anzeigen
kubectl get pods -n kube-system -l component=kube-apiserver

# API Server Manifest lesen (auf der Control Plane Node)
cat /etc/kubernetes/manifests/kube-apiserver.yaml

# API Server Health-Check
kubectl get --raw /healthz

# API-Versionen auflisten
kubectl api-versions

# API-Ressourcen und deren Verben anzeigen
kubectl api-resources -o wide

Wichtige API Server Flags

Die folgenden Flags stehen im Static Pod Manifest und werden in der CKA-Pruefung haeufig abgefragt:

# Auszug aus /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
  containers:
  - command:
    - kube-apiserver
    ---advertise-address=192.168.1.10
    ---etcd-servers=https://127.0.0.1:2379
    ---etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    ---etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    ---etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    ---service-cluster-ip-range=10.96.0.0/12
    ---service-account-key-file=/etc/kubernetes/pki/sa.pub
    ---tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    ---tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    ---authorization-mode=Node,RBAC
    ---enable-admission-plugins=NodeRestriction
    ---audit-log-path=/var/log/kubernetes/audit.log
    ---audit-policy-file=/etc/kubernetes/audit-policy.yaml

Pruefungstipp: Wenn eine Aufgabe fragt, welchen Port der API Server nutzt oder welche etcd-Adresse konfiguriert ist, schaut in /etc/kubernetes/manifests/kube-apiserver.yaml.

etcd: Der Speicher des Clusters

etcd ist ein verteilter Key-Value-Store, der den gesamten Cluster-State speichert. Jede Ressource, die ihr mit kubectl create anlegt, landet als Eintrag in etcd. Faellt etcd aus, ist der Cluster funktionsunfaehig.

etcd Grundlagen

# etcd-Pod im Cluster anzeigen
kubectl get pods -n kube-system -l component=etcd

# etcd-Version pruefen
kubectl exec -n kube-system etcd-controlplane -- etcdctl version

# etcd Health-Check
kubectl exec -n kube-system etcd-controlplane -- 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 \
  endpoint health

etcd Backup (Pruefungskritisch!)

Das Backup und Restore von etcd ist eine der am haeufigsten gestellten CKA-Pruefungsaufgaben. Lernt die folgenden Befehle auswendig:

# Umgebungsvariable fuer die API-Version setzen
export ETCDCTL_API=3

# Snapshot erstellen
etcdctl snapshot save /opt/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

# Snapshot verifizieren
etcdctl snapshot status /opt/etcd-backup.db --write-table

Ausgabe des Status-Befehls:

+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| c4d3b2a1 |   125487 |       1243 |     5.2 MB |
+----------+----------+------------+------------+

etcd Restore (Pruefungskritisch!)

# 1. Restore aus Snapshot in neues Datenverzeichnis
etcdctl snapshot restore /opt/etcd-backup.db \
  --data-dir=/var/lib/etcd-restored

# 2. etcd Static Pod Manifest anpassen
# Aendert den hostPath Volume-Mount von /var/lib/etcd auf /var/lib/etcd-restored

Nach dem Restore muss das etcd Static Pod Manifest angepasst werden:

# In /etc/kubernetes/manifests/etcd.yaml aendern:
volumes:
- hostPath:
    path: /var/lib/etcd-restored    # Neues Verzeichnis
    type: DirectoryOrCreate
  name: etcd-data

# 3. Warten bis der etcd-Pod mit dem neuen Verzeichnis startet
# Static Pods werden automatisch von kubelet neu gestartet

# 4. Pruefen ob der Cluster wieder funktioniert
kubectl get nodes
kubectl get pods -A

Wichtig: Nach dem Restore zeigt auf das neue Datenverzeichnis. Aendert NICHT den alten Pfad -- erstellt ein neues Verzeichnis und passt das Manifest an.

kube-scheduler: Wer laeuft wo?

Der kube-scheduler ueberwacht neu erstellte Pods, die noch keinem Node zugewiesen sind, und waehlt den optimalen Node fuer jeden Pod aus.

Wie der Scheduler entscheidet

Der Scheduling-Prozess laeuft in zwei Phasen:

1. Filtering (Ausschluss): Nodes, die die Anforderungen nicht erfuellen, werden aussortiert:

Nicht genug CPU oder Memory verfuegbar
Taints, die der Pod nicht toleriert
NodeSelector oder NodeAffinity stimmen nicht ueberein
Pod hat einen bestimmten Node-Namen angefordert

2. Scoring (Bewertung): Die verbleibenden Nodes werden nach Kriterien bewertet:

Gleichmaessige Ressourcenverteilung
Pod-Affinity und Anti-Affinity
Bereits vorhandene Images auf dem Node

# Scheduler-Status pruefen
kubectl get pods -n kube-system -l component=kube-scheduler

# Scheduler-Manifest anzeigen
cat /etc/kubernetes/manifests/kube-scheduler.yaml

# Scheduler-Events fuer einen Pod anzeigen
kubectl describe pod my-pod | grep -A 5 Events

Custom Scheduler

Kubernetes unterstuetzt mehrere Scheduler gleichzeitig. Ein Pod kann angeben, welchen Scheduler er nutzen moechte:

apiVersion: v1
kind: Pod
metadata:
  name: custom-scheduled-pod
spec:
  schedulerName: my-custom-scheduler
  containers:
  - name: nginx
    image: nginx:1.27

# Pruefen, welcher Scheduler einen Pod zugewiesen hat
kubectl get events --field-selector reason=Scheduled

kube-controller-manager: Die Kontroll-Schleife

Der kube-controller-manager fuehrt alle eingebauten Controller als einen einzigen Prozess aus. Jeder Controller ueberwacht den Ist-Zustand und bringt ihn auf den Soll-Zustand.

Wichtige Controller

Controller	Aufgabe
ReplicaSet Controller	Stellt sicher, dass die gewuenschte Anzahl Pods laeuft
Deployment Controller	Verwaltet ReplicaSets fuer Rolling Updates
Node Controller	Erkennt ausgefallene Nodes, markiert sie als NotReady
Job Controller	Erstellt Pods fuer Jobs, trackt Completions
ServiceAccount Controller	Erstellt Default-ServiceAccounts in neuen Namespaces
Endpoint Controller	Aktualisiert Endpoint-Objekte fuer Services

# Controller Manager Status
kubectl get pods -n kube-system -l component=kube-controller-manager

# Controller Manager Manifest
cat /etc/kubernetes/manifests/kube-controller-manager.yaml

# Beispiel-Flags
# --node-monitor-period=5s      (wie oft Nodes geprueft werden)
# --node-monitor-grace-period=40s (wie lange ein Node unresponsive sein darf)
# --pod-eviction-timeout=5m0s   (wann Pods von NotReady Nodes evakuiert werden)

kubelet: Der Agent auf jedem Node

Der kubelet ist kein Static Pod -- er laeuft als systemd-Service auf jedem Node. Er ist verantwortlich fuer:

Registrierung des Nodes beim API Server
Empfang von Pod-Spezifikationen und Sicherstellung, dass Container laufen
Health-Checks der Container (Liveness und Readiness Probes)
Berichterstattung ueber Node- und Pod-Status an den API Server

kubelet-Konfiguration pruefen

# kubelet-Service Status
systemctl status kubelet

# kubelet-Konfiguration finden
ps aux | grep kubelet | grep config
# Typischer Pfad: /var/lib/kubelet/config.yaml

# kubelet-Konfiguration anzeigen
cat /var/lib/kubelet/config.yaml

# kubelet-Logs pruefen (wichtig fuer Troubleshooting)
journalctl -u kubelet -f
journalctl -u kubelet --since "5 minutes ago"

Static Pods

Static Pods werden direkt vom kubelet verwaltet, ohne den API Server. Sie werden definiert durch YAML-Dateien in einem bestimmten Verzeichnis -- standardmaessig /etc/kubernetes/manifests/.

# Static Pod Pfad in der kubelet-Konfiguration finden
grep staticPodPath /var/lib/kubelet/config.yaml
# Output: staticPodPath: /etc/kubernetes/manifests

# Alle Static Pods auflisten
ls /etc/kubernetes/manifests/
# etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

Pruefungstipp: Wenn eine Aufgabe fragt, wie man einen Static Pod erstellt, legt einfach eine YAML-Datei in /etc/kubernetes/manifests/ ab. Der kubelet erkennt die Datei automatisch und startet den Pod.

# Beispiel: Static Pod erstellen
# Datei: /etc/kubernetes/manifests/my-static-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-static-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80

Komponentengesundheit pruefen

In der CKA-Pruefung wird oft verlangt, den Zustand des Clusters zu analysieren. Hier die wichtigsten Befehle:

# Alle Systemkomponenten
kubectl get pods -n kube-system

# Node-Status
kubectl get nodes -o wide
kubectl describe node controlplane

# Komponentenstatus (deprecated aber noch funktional)
kubectl get componentstatuses

# API Server erreichbar?
kubectl cluster-info

# etcd-Gesundheit
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 \
  endpoint health

# kubelet-Status auf einem Node
ssh worker-node-1 "systemctl status kubelet"

# Alle Events im Cluster sortiert nach Zeit
kubectl get events -A --sort-by='.metadata.creationTimestamp'

High Availability (HA) Setup

In Produktionsumgebungen laeuft die Control Plane auf mehreren Nodes. Die CKA-Pruefung fragt HA-Konzepte konzeptionell ab -- ihr muesst kein HA-Setup von Grund auf bauen.

HA-Architektur

Stacked etcd (Standard bei kubeadm):

etcd laeuft auf denselben Nodes wie die Control Plane
Weniger Nodes noetig, aber etcd und API Server teilen sich Ressourcen
Minimum: 3 Control Plane Nodes

External etcd:

etcd laeuft auf separaten Nodes
Bessere Isolation und Performance
Minimum: 3 etcd Nodes + 2 Control Plane Nodes

etcd Quorum

etcd benoetigt eine Mehrheit der Nodes (Quorum) fuer Schreiboperationen:

etcd Nodes	Quorum	Tolerierte Ausfaelle
1	1	0
3	2	1
5	3	2
7	4	3

Empfehlung: 3 oder 5 etcd-Nodes. Gerade Zahlen bringen keinen Vorteil, da das Quorum gleich bleibt (z.B. 4 Nodes brauchen auch ein Quorum von 3).

Load Balancer vor dem API Server

In einem HA-Setup sitzt ein Load Balancer vor den API Servern. kubectl und alle Komponenten verbinden sich zum Load Balancer, nicht direkt zu einem einzelnen API Server.

                    ┌─────────────────┐
                    │  Load Balancer   │
                    │  (Port 6443)     │
                    └────────┬────────┘
               ┌─────────────┼─────────────┐
               v             v             v
       ┌──────────┐  ┌──────────┐  ┌──────────┐
       │ CP Node 1│  │ CP Node 2│  │ CP Node 3│
       │ API+etcd │  │ API+etcd │  │ API+etcd │
       └──────────┘  └──────────┘  └──────────┘

Praxisbeispiel: etcd Backup und Restore Workflow

Dieser Workflow simuliert eine typische CKA-Pruefungsaufgabe:

# Schritt 1: Aktuellen Cluster-State pruefen
kubectl get nodes
kubectl get pods -A

# Schritt 2: etcd-Zertifikate identifizieren
cat /etc/kubernetes/manifests/etcd.yaml | grep -E "cert|key|cacert"

# Schritt 3: Backup erstellen
ETCDCTL_API=3 etcdctl snapshot save /opt/backup/etcd-snapshot.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

# Schritt 4: Backup verifizieren
ETCDCTL_API=3 etcdctl snapshot status /opt/backup/etcd-snapshot.db --write-table

# Schritt 5: Restore in neues Verzeichnis
ETCDCTL_API=3 etcdctl snapshot restore /opt/backup/etcd-snapshot.db \
  --data-dir=/var/lib/etcd-from-backup

# Schritt 6: etcd Manifest anpassen
# Editiert /etc/kubernetes/manifests/etcd.yaml:
# - hostPath.path aendern von /var/lib/etcd zu /var/lib/etcd-from-backup

# Schritt 7: Warten und verifizieren
# kubelet erkennt die Aenderung automatisch und startet etcd neu
kubectl get pods -n kube-system -l component=etcd
kubectl get nodes

Haeufige Fehler in der CKA-Pruefung

1. etcd-Zertifikate vergessen: Jeder etcdctl-Befehl braucht --cacert, --cert und --key. Ohne diese Flags schlaegt der Befehl fehl.

2. ETCDCTL_API nicht gesetzt: Ohne ETCDCTL_API=3 nutzt etcdctl die API-Version 2, die andere Befehle hat.

3. Nach Restore altes Verzeichnis verwenden: Aendert den Volume-Mount im etcd-Manifest auf das neue Verzeichnis. Das alte Verzeichnis nicht ueberschreiben.

4. Static Pod Pfad nicht kennen: Der Pfad steht in /var/lib/kubelet/config.yaml unter staticPodPath. Er ist fast immer /etc/kubernetes/manifests/, aber prueft es.

5. kubelet nicht als systemd-Service erkennen: Anders als die anderen Control-Plane-Komponenten ist kubelet kein Static Pod, sondern ein systemd-Service. systemctl restart kubelet statt Pod loeschen.

Mehr Tipps fuer die Pruefung findet ihr in unserem Artikel CKA bestehen: 10 Tipps.