Wie Managed Kubernetes Ausfälle begrenzt

Wenn eine kritische Anwendung ausfällt, zählt jede Sekunde. Für Schweizer Organisationen unter FINMA-Aufsicht oder mit sensiblen Daten kostet ein Ausfall weit mehr als eine Betriebsunterbrechung. Er kann Compliance, Kundenvertrauen und Reputation beschädigen. Genau darum wird Managed Kubernetes zum strategischen Hebel, um Ausfallrisiken zu begrenzen.

Dieser Artikel behandelt drei Dinge: einen Ausfall verhindern, ihn im Ernstfall diagnostizieren und wissen, was von selbst zurückkommt. Die Architektur dahinter, replizierte Control Plane, etcd-Quorum, Speicher über drei Standorte, erklärt Kubernetes-HA über mehrere Rechenzentren. Die Anleitung zur Verteilung einer Last über die drei Standorte steht im Guide Kubernetes über drei Rechenzentren.

Kernpunkte: wie Managed Kubernetes Ausfälle begrenzt

• Kubernetes überwacht den Zustand der Pods und startet jene neu, die ihre Probes nicht bestehen, sofern ein gesunder Node sie aufnehmen kann.
• Speicherreplikation schützt Ihre Daten. Sie macht Ihre Anwendungen deswegen nicht verfügbar: das sind zwei getrennte Ebenen.
• Eine verwaltete Control Plane nimmt Ihnen die operative Komplexität von etcd, Zertifikaten und Upgrades ab.
• Hikube repliziert die Control Plane und, je nach gewähltem Replikationsmodus, die persistenten Volumes über Genf, Gland und Luzern. Die Verteilung Ihrer Pods über die Standorte bleibt Ihre Konfiguration: Topology Spread und PodDisruptionBudget.
• Liveness- und Readiness-Probes erkennen Anomalien, bevor sie Ihre Nutzer erreichen, wenn ihre Schwellenwerte am realen Verhalten der Anwendung ausgerichtet sind.

Diagnostizieren, die drei Ebenen, auf denen ein Ausfall entsteht

Ein Ausfall in Kubernetes nimmt eine von drei Formen an, und die erste Frage lautet, welche. Ein Pod, ein Node oder die Control Plane: die Antwort bestimmt, wer handelt und was zu erwarten ist.

Ein Pod-Ausfall

Die Anwendung stürzt ab oder antwortet nicht mehr. Der Pod besteht seine Probe nicht, der Scheduler verlegt ihn auf einen gesunden Node. Das ist der häufigste Fall und derjenige, den die Plattform ohne Sie übernimmt, solange anderswo Kapazität bleibt.

Ein Node-Ausfall

Hardwaredefekt, Netzwerkstörung oder Ressourcenerschöpfung. Alle Pods auf diesem Node sind nicht verfügbar, bis sie anderswo starten. Das verräterische Zeichen: mehrere Dienste fallen gleichzeitig aus, ohne fachlichen Zusammenhang.

Ein Ausfall der Control Plane

API-Server, Scheduler, Controller Manager und etcd bilden das Gehirn des Clusters. Ist die Control Plane nicht verfügbar, können Sie nichts mehr deployen oder ändern, die bereits laufenden Pods laufen jedoch weiter. Bei Hikube betreibt Hidora SA diese Ebene: es ist der einzige der drei Fälle, in dem die Diagnose nicht bei Ihnen liegt.

Verhindern, was vor dem Ausfall konfiguriert wird

Hochverfügbarkeit entsteht nicht spontan. Sie wird deklariert, in Ihren Manifests, vor dem Vorfall.

Health-Probes: Liveness und Readiness

Liveness-Probes prüfen, ob die Anwendung lebt; besteht ein Container den Test nicht, startet Kubernetes ihn neu. Readiness-Probes zeigen an, ob der Pod Verbindungen annehmen kann, und nehmen jene aus dem Dienst, die es nicht können.

Für regulierte Anwendungen, bei denen jede Millisekunde zählt, brauchen diese Probes passende Schwellenwerte. Ein zu langes Intervall verzögert die Erkennung. Ein zu kurzes erzeugt Fehlalarme und unnötige Neustarts.

Replicas, PodDisruptionBudget und Anti-Affinität

Dieser Teil liegt bei Ihnen, und nichts ersetzt ihn. Definieren Sie zunächst mehrere Replicas für jedes kritische Deployment: mindestens drei halten den Dienst aufrecht, wenn zwei Instanzen ausfallen. Nutzen Sie PodDisruptionBudgets, damit während Wartungsarbeiten eine Mindestzahl an Pods verfügbar bleibt.

Affinität und Anti-Affinität steuern die Verteilung der Pods über die Nodes, Topology-Spread-Constraints ihre Verteilung über die Standorte. Eine Anti-Affinitätsregel verhindert, dass zwei Replicas desselben Dienstes auf demselben physischen Node laufen. Ohne diese Deklarationen hindert nichts Ihre Replicas daran, sich denselben Node, oder dasselbe Rechenzentrum, zu teilen, der gleich ausfällt.

Replikation des Speichers

Persistente Volumes enthalten die Daten Ihrer Stateful-Anwendungen, etwa Datenbanken und Message-Queues. Ein Speicherausfall kann zu unwiederbringlichem Datenverlust führen.

Die replizierte Storage Class verteilt die Daten über mehrere Nodes und mehrere unabhängige Rechenzentren. Hikube bietet synchrone oder asynchrone Replikation persistenter Volumes über Genf, Gland und Luzern; der gewählte Modus bestimmt Ihren RPO. Fällt ein Standort aus, bleiben die Kopien von den betriebsbereiten Standorten lesbar.

Für Workloads mit regelmässigen Backups kombinieren Sie Velero mit S3-Objektspeicher. Replikation schützt vor einem Standortausfall; sie schützt nicht vor versehentlichem Löschen, das ebenfalls repliziert wird.

Monitoring und Alarme

Früh erkannte Anomalien verhindern, dass kleine Vorfälle zu grossen Ausfällen werden. Ein wirksames Monitoring sammelt Metriken, aggregiert Logs und löst Alarme aus, bevor Nutzer betroffen sind.

Setzen Sie einen vollständigen Observability-Stack ein: Grafana zur Visualisierung, VictoriaMetrics für Metriken und VictoriaLogs für zentralisierte Logs. Diese Werkzeuge integrieren sich nativ mit Kubernetes und liefern vorkonfigurierte Dashboards je Ressourcentyp.

Konfigurieren Sie Alarme auf den Schlüsselindikatoren: CPU- und Speicherauslastung der Nodes, Fehlerrate der Pods, Latenz der API-Anfragen. Ein Alarm bei 80 % Auslastung lässt Zeit zu handeln, bevor die Sättigung eintritt.

Wiederherstellen: was von selbst zurückkommt, was nicht

Was die Plattform ohne Sie übernimmt

Ein Container, der seine Liveness-Probe nicht besteht, wird neu gestartet. Ein Pod, dessen Node verschwindet, wird anderswo eingeplant, sofern ein gesunder Node die Kapazität hat. Die Control Plane wird von Hidora SA repliziert und aktualisiert: Sie verwalten kein etcd, überwachen kein Quorum, lösen kein Failover aus.

Was nicht von selbst zurückkommt

Ein Deployment mit einer einzigen Replica, es gibt nichts, worauf während des Neustarts umgeschaltet werden könnte. Replicas, die mangels Topology Spread alle auf dem ausgefallenen Standort lagen. Ein Pod, den das PodDisruptionBudget nicht verschieben lässt oder den kein verbleibender Node aufnehmen kann. Ein Volume, dessen Replikationsmodus nie aktiviert wurde. In all diesen Fällen verhält sich die Plattform genau wie vorgesehen und Ihre Anwendung ist ausgefallen: der Unterschied liegt in der Konfiguration, nicht in der Infrastruktur.

Replikation, Anwendungsverfügbarkeit, RPO und RTO

Vier getrennte Begriffe, die oft verwechselt werden. Replikation liegt auf Volume-Ebene: Ihre Daten existieren in mehreren Kopien. Anwendungsverfügbarkeit liegt bei Ihren Pods: sie ergibt sich aus Spread und PDB, nicht aus der Replikation. Der RPO, die Menge verlorener Daten, hängt vom Replikationsmodus ab, synchron oder asynchron. Der RTO, die Zeit bis zur Wiederherstellung, ist nicht vom SLA abgedeckt: Behebungszeiten sind nicht garantiert und es wird kein MTTR publiziert; eine Fristzusage wird im Einzelfall vertraglich geregelt. Der genaue Umfang steht unter Sicherheit und Compliance.

Welche besonderen Anforderungen gelten für regulierte Anwendungen?

Finanzwesen, Gesundheit und Verwaltung stellen strenge Anforderungen an Verfügbarkeit und Datenresidenz. Ein Kubernetes-Cluster für solche Workloads muss DSGVO-, revDSG- und FINMA-Vorgaben erfüllen.

Datensouveränität stellt sicher, dass Ihre Informationen unter Schweizer Recht bleiben. US-Hyperscaler unterliegen dem Cloud Act, der sie zur Herausgabe von Daten an ausländische Behörden zwingen kann. Ein Schweizer Anbieter wie Hikube arbeitet ausschliesslich unter Schweizer Recht, einem der schützendsten weltweit.

Die Zertifizierung ISO 27001 belegt, dass Sicherheits- und Incident-Management-Prozesse internationalen Standards entsprechen. Sie deckt die gesamte Kette ab, von den Rechenzentren bis zu den Betriebsverfahren.

Wie optimiert man die Latenz zwischen den drei Standorten?

Synchrone Replikation bringt Netzwerklatenz zwischen den Rechenzentren mit sich. Bei latenzempfindlichen Anwendungen muss dieser Preis am eigenen Schreibprofil gemessen werden, bevor man ihn eingeht.

Nutzen Sie Zone-Affinity-Routing, um Verkehr zu Pods im selben Rechenzentrum zu lenken. Das reduziert Netzwerk-Hops und verbessert die Antwortzeiten für Endnutzer, zum Preis einer weniger gleichmässigen Verteilung.

Für Workloads mit minimaler Latenz kommen dedizierte GPU-Ressourcen mit direktem Hardwarezugriff infrage. Hikube bietet GPUs L40S, A100 und H100 direkt an den Nodes für native Leistung ohne Virtualisierung.

Fazit: eine resiliente Kubernetes-Infrastruktur bauen

Ausfälle in einer Kubernetes-Umgebung zu begrenzen verlangt ein systematisches Vorgehen und eine klare Rollenteilung. Probes, Monitoring und Speicherreplikation senken die Wahrscheinlichkeit eines Vorfalls. Replicas, Spread und PDB bestimmen, was überlebt, wenn er eintritt.

Für Schweizer Organisationen in regulierten Branchen nimmt souveränes Managed Kubernetes eine ganze Schicht dieser Arbeit ab: die Control Plane wird betrieben und aktualisiert, die Daten bleiben in der Schweiz unter lokalem Recht.

Hikube repliziert die Control Plane und die Volumes, je nach gewähltem Modus, über Genf, Gland und Luzern und zielt auf eine Wiederherstellung der Control Plane ohne Eingriff. Die Wiederanlaufzeiten Ihrer Anwendungen hängen von Ihrer Konfiguration ab und sind nicht Gegenstand einer veröffentlichten Zusage.

FAQ zu Managed Kubernetes und dem Umgang mit Ausfällen

Wie lange dauert die Erholung von einem Knotenausfall?

Kubernetes plant die Pods ohne manuellen Eingriff auf gesunde Nodes um. Die Dauer hängt von der Probe, der Imagegrösse und der verbleibenden Kapazität ab; Hikube veröffentlicht keinen RTO.

Beeinträchtigt Multi-Standort-Replikation die Leistung?

Synchrone Replikation erhöht die Schreiblatenz zwischen den Standorten. Messen Sie sie an Ihrem realen Profil statt an einer generischen Zahl. Zone-Affinity-Routing begrenzt diesen Effekt für latenzempfindliche Anwendungen.

Wie geht Hikube mit dem vollständigen Verlust eines Rechenzentrums um?

Die Control Plane behält ihr Quorum auf den beiden verbleibenden Standorten und plant weiter. Die Worker-Nodes der beiden anderen Standorte bleiben bestehen, und die Kopien Ihrer replizierten Volumes bleiben dort lesbar. Ihre Anwendungen überleben jedoch nur, wenn Sie mehrere Replicas, Topology-Spread-Constraints und ein PodDisruptionBudget deklariert haben: ein Failover der Anwendung erfolgt nicht automatisch.

Welche Compliance-Zertifizierungen liegen vor?

Hikube und seine Rechenzentren sind nach ISO 27001 zertifiziert. Die Plattform erfüllt DSGVO und revDSG, die Daten liegen ausschliesslich in der Schweiz unter Schweizer Recht.

Kann ich die Resilienz meines Clusters vor der Produktion testen?

Ja, Sie können Node-Ausfälle simulieren und das Verhalten Ihrer Anwendungen in einer Staging-Umgebung prüfen. Werkzeuge wie Chaos Mesh injizieren Störungen kontrolliert, um Ihre Hochverfügbarkeitskonfiguration zu validieren.