High Availability: Kubernetes Control Plane absichern

TL;DR

Ein einzelner Control-Plane-Node ist ein Single Point of Failure. Fuer Produktion braucht ihr mindestens drei Master-Nodes mit etcd-Quorum, einen Load Balancer vor dem API-Server und eine klare Entscheidung zwischen Stacked und External etcd Topology. Dieser Artikel zeigt das Setup mit kubeadm, erklaert Failure-Szenarien und gibt konkrete Empfehlungen fuer den Betrieb.

Warum ein einzelner Master nicht reicht

In einer Standard-kubeadm-Installation laeuft alles auf einem Node: API-Server, Controller-Manager, Scheduler und etcd. Faellt dieser Node aus, koennen keine neuen Pods geschedulet werden, kein kubectl funktioniert und bestehende Workloads laufen zwar weiter, sind aber nicht mehr steuerbar.

Fuer Produktion ist das inakzeptabel. Die Loesung: mehrere Control-Plane-Nodes mit verteiltem etcd und einem Load Balancer davor.

# Aktuellen Cluster-Status pruefen
kubectl get nodes -l node-role.kubernetes.io/control-plane
# Bei HA sollten hier mindestens 3 Nodes erscheinen

# etcd-Cluster-Health pruefen
kubectl -n kube-system exec -it etcd-master-01 -- \
  etcdctl endpoint health \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

etcd-Quorum: Warum ungerade Zahlen

etcd nutzt den Raft-Konsensus-Algorithmus. Entscheidungen brauchen eine Mehrheit (Quorum). Das hat direkte Auswirkungen auf die Cluster-Groesse:

Drei Members ist der Standard fuer Produktion. Fuenf Members erhoehen die Ausfalltoleranz, aber auch die Latenz bei Schreiboperationen, weil mehr Nodes zustimmen muessen. Sieben oder mehr Members sind selten sinnvoll.

Gerade Zahlen bringen keinen Vorteil: 4 Members tolerieren genau wie 3 Members nur einen Ausfall (Quorum = 3), brauchen aber mehr Ressourcen.

Stacked vs. External etcd Topology

kubeadm unterstuetzt zwei HA-Topologien:

Stacked etcd (empfohlen fuer die meisten Setups)

etcd laeuft als Static Pod auf jedem Control-Plane-Node. Einfacher zu betreiben, aber ein Node-Ausfall betrifft sowohl den API-Server als auch ein etcd-Member.

# kubeadm-config.yaml fuer den ersten Control-Plane-Node (Stacked)
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.31.0
controlPlaneEndpoint: "k8s-api.example.com:6443"
etcd:
  local:
    extraArgs:
      - name: heartbeat-interval
        value: "250"
      - name: election-timeout
        value: "2500"
networking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "10.96.0.0/12"
apiServer:
  certSANs:
    - "k8s-api.example.com"
    - "10.0.0.100"

External etcd

etcd laeuft auf dedizierten Nodes, getrennt von den Control-Plane-Nodes. Aufwaendiger, aber ein Control-Plane-Node-Ausfall laesst etcd unberuehrt. Sinnvoll ab 500+ Nodes oder bei strengen Verfuegbarkeitsanforderungen.

# kubeadm-config.yaml mit External etcd
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: v1.31.0
controlPlaneEndpoint: "k8s-api.example.com:6443"
etcd:
  external:
    endpoints:
      - "https://etcd-01.example.com:2379"
      - "https://etcd-02.example.com:2379"
      - "https://etcd-03.example.com:2379"
    caFile: "/etc/kubernetes/pki/etcd/ca.crt"
    certFile: "/etc/kubernetes/pki/etcd/apiserver-etcd-client.crt"
    keyFile: "/etc/kubernetes/pki/etcd/apiserver-etcd-client.key"

Load Balancer vor dem API-Server

Der controlPlaneEndpoint muss auf einen Load Balancer zeigen, der Traffic auf alle API-Server verteilt. Ohne Load Balancer zeigen alle kubeconfigs auf einen einzelnen Node -- und der kann ausfallen.

Variante 1: HAProxy + Keepalived (On-Premises)

# /etc/haproxy/haproxy.cfg
frontend k8s-api
    bind *:6443
    mode tcp
    option tcplog
    default_backend k8s-api-backend

backend k8s-api-backend
    mode tcp
    option tcp-check
    balance roundrobin
    server master-01 10.0.0.11:6443 check fall 3 rise 2
    server master-02 10.0.0.12:6443 check fall 3 rise 2
    server master-03 10.0.0.13:6443 check fall 3 rise 2

Keepalived stellt eine virtuelle IP (VIP) bereit, die zwischen den HAProxy-Instanzen wechselt, falls ein HAProxy ausfaellt.

Variante 2: Cloud Load Balancer

Bei AWS, Azure oder GCP nutzt ihr den jeweiligen internen Load Balancer. Der controlPlaneEndpoint zeigt auf den DNS-Namen des Load Balancers.

HA-Cluster mit kubeadm aufsetzen

Schritt 1: Ersten Control-Plane-Node initialisieren

sudo kubeadm init \
  --config kubeadm-config.yaml \
  --upload-certs

Die Ausgabe enthaelt zwei Join-Befehle: einen fuer weitere Control-Plane-Nodes und einen fuer Worker-Nodes. Der --upload-certs-Parameter verschluesselt die Zertifikate und laedt sie als Secret hoch, damit weitere Master sie automatisch abrufen koennen.

Schritt 2: Weitere Control-Plane-Nodes hinzufuegen

sudo kubeadm join k8s-api.example.com:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <certificate-key>

Schritt 3: etcd-Cluster verifizieren

kubectl -n kube-system exec -it etcd-master-01 -- \
  etcdctl member list \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  --write-out=table

Die Ausgabe sollte drei Members mit Status started zeigen.

Failure-Szenarien und deren Auswirkungen

Ein Control-Plane-Node faellt aus (Stacked, 3 Nodes):

• etcd hat noch Quorum (2 von 3). Cluster funktioniert.
• Load Balancer leitet Traffic an die verbleibenden API-Server.
• Controller-Manager und Scheduler laufen nur auf einem Node aktiv (Leader Election). Falls der Leader ausfaellt, uebernimmt ein anderer Node innerhalb von Sekunden.

Zwei Control-Plane-Nodes fallen aus (Stacked, 3 Nodes):

• etcd verliert Quorum. Keine Schreiboperationen moeglich.
• Bestehende Pods laufen weiter, aber kein Scheduling, kein Scaling, kein kubectl.
• Kritischer Zustand: Nodes so schnell wie moeglich wiederherstellen.

Netzwerkpartition zwischen etcd-Members:

• Split-Brain-Risiko. etcd verweigert Schreiboperationen, wenn kein Quorum erreichbar ist.
• Die Partition mit Quorum (2 von 3) funktioniert weiter. Die isolierte Partition wird read-only.

etcd-Backup: Pflicht bei HA

Auch mit HA braucht ihr regelmaessige etcd-Backups. Ein fehlerhaftes Upgrade oder korrupte Daten replizieren sich auf alle Members.

# etcd-Snapshot erstellen
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Snapshot verifizieren
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-$(date +%Y%m%d).db \
  --write-out=table

Automatisiert das als CronJob -- taeglich ist Minimum, stuendlich bei kritischen Clustern.

FAQ

Brauche ich fuer jede Umgebung ein HA-Setup?

Nein. Fuer Entwicklungs- und Testumgebungen reicht ein einzelner Master. HA lohnt sich fuer Produktion und Staging, wo Ausfallzeiten geschaeftskritisch sind.

Kann ich nachtraeglich von einem auf drei Master migrieren?

Ja, mit kubeadm join --control-plane. Voraussetzung: Der Load Balancer und der controlPlaneEndpoint muessen vorher konfiguriert sein. Sonst zeigen alle kubeconfigs auf den einzelnen Node statt auf den Load Balancer.

Wie ueberwache ich die etcd-Health?

Prometheus mit dem etcd-Exporter. Wichtige Metriken: etcd_server_has_leader, etcd_disk_wal_fsync_duration_seconds, etcd_network_peer_round_trip_time_seconds. Alerts bei Quorum-Verlust oder hohen Disk-Latenzen.

Was passiert bei einem etcd-Quorum-Verlust?

Keine Schreiboperationen mehr. Bestehende Workloads laufen weiter, aber der Cluster ist effektiv eingefroren. Die Loesung: ausgefallene Members wiederherstellen oder im Notfall aus einem Backup recovern.

Stacked oder External etcd -- was soll ich nehmen?

Stacked fuer die meisten Setups bis ca. 200 Nodes. External etcd bei sehr grossen Clustern, strengen SLAs oder wenn das Operations-Team die zusaetzliche Komplexitaet beherrscht.