Hochverfügbarkeit
Hochverfügbarkeit betrifft in einem Kubernetes-Cluster zwei voneinander unabhängige Ebenen: die Control Plane und Ihre Workloads. Beide müssen getrennt betrachtet werden – eine hochverfügbare Control Plane macht eine einzelne Anwendungsinstanz nicht ausfallsicher.
Hochverfügbare Control Plane
Standardmäßig läuft die Control Plane eines Clusters als Einzelinstanz. Fällt sie aus, laufen bereits gestartete Pods auf den Worker Nodes weiter, aber die Kubernetes API ist nicht erreichbar: Es lassen sich keine Änderungen ausrollen, keine Pods neu planen und keine Skalierungen durchführen.
Mit der Option High Availability repliziert centron die zentralen Control-Plane-Komponenten. Der eingebaute Failover-Mechanismus beseitigt damit den Single Point of Failure der Control Plane.
| Eigenschaft | Wert |
|---|---|
| Preis | Je Cluster und Monat, siehe Preisübersicht für Kubernetes |
| Zusicherung | 99,9 % Verfügbarkeit, siehe Hinweis unten |
| Aktivierung | Bei der Cluster-Erstellung oder nachträglich |
| Entfernung | Nicht möglich |
Für centron Managed Kubernetes gilt eine zugesicherte Verfügbarkeit von 99,9 %. Die hochverfügbare Control Plane verringert darüber hinaus technisch das Ausfallrisiko, indem sie den Single Point of Failure beseitigt. Maßgeblich ist der Leistungsschein Managed Kubernetes.
Eine hochverfügbare Control Plane kann nach dem Hinzufügen nicht mehr aus dem Cluster entfernt werden. Die Kosten fallen ab Aktivierung dauerhaft für dieses Cluster an.
Für produktive Cluster wird High Availability empfohlen. Für Test-, Entwicklungs- und Lernumgebungen ist die Standard-Control-Plane in der Regel ausreichend.
Zur Aktivierung siehe Hochverfügbarkeit aktivieren.
Hochverfügbare Workloads
Die Verfügbarkeit Ihrer Anwendungen bestimmen Sie selbst über deren Konfiguration. Die wichtigsten Punkte:
Mehrere Replicas
Eine Anwendung mit nur einer Replica ist nicht ausfallsicher – weder bei einem Node-Ausfall noch während eines Upgrades. Betreiben Sie produktive Dienste mit mindestens zwei Replicas.
Mindestens zwei Nodes je Pool
Bei Upgrades und Wartungsarbeiten werden Nodes nacheinander neu gestartet. Mit nur einem Node im Pool ist Ihre Anwendung in dieser Zeit nicht erreichbar. Empfohlen sind daher mindestens 2 Nodes je Node Pool.
Verteilung über Nodes erzwingen
Ohne weitere Vorgaben kann der Scheduler mehrere Replicas auf demselben Node platzieren – der Ausfall dieses einen Nodes trifft dann alle Instanzen gleichzeitig. Mit topologySpreadConstraints oder Pod-Anti-Affinity verteilen Sie Replicas gezielt über verschiedene Nodes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: web
containers:
- name: web
image: nginx:stable
Unterbrechungsbudget festlegen
Ein PodDisruptionBudget legt fest, wie viele Pods einer Anwendung während freiwilliger Unterbrechungen – etwa beim Leeren eines Nodes im Zuge eines Upgrades – gleichzeitig entfernt werden dürfen:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: web
Readiness Probes definieren
Ohne Readiness Probe leitet Kubernetes Datenverkehr an einen Pod weiter, sobald dessen Container gestartet ist – auch wenn die Anwendung noch nicht bereit ist. Definieren Sie Readiness Probes, damit während eines Rollouts nur einsatzbereite Pods Anfragen erhalten.
Surge Upgrades
Mit aktivierten Surge Upgrades stellt centron während eines Upgrades temporär zusätzliche Nodes bereit (maximal 10), bevor alte Nodes entfernt werden. Die Kapazität des Clusters bleibt dadurch während des Upgrades erhalten. Die Einstellung finden Sie im Tab Settings des Clusters.
Verwandte Themen
- Hochverfügbarkeit aktivieren
- Cluster-Architektur
- Verfügbarkeit – Standort und zugesicherte Verfügbarkeit
- Best Practices
- SLAs & Leistungsscheine
Alle Preise verstehen sich zuzüglich Umsatzsteuer.