Wir verkaufen Betrieb, nicht Installation - wie die Arbeit an Ihrem Cluster wirklich aussieht

Kubernetes zu installieren ist ein Wochenende. Es zu betreiben sind die anderen 400 Nächte. Der größte Teil dieses Unterschieds taucht in keinem Angebot auf, weil er aus Dingen besteht, die nur sichtbar werden, wenn sie fehlschlagen: ein Backup, das sich als fehlend herausstellt, ein Zertifikat, das niemand erneuert hat, ein Volume, das um drei Uhr morgens volllief.

Wir verkaufen den Betrieb, nicht die Installation. Dieser Beitrag beschreibt, was dieser Satz in unseren Clustern konkret bedeutet - konkret genug, dass Sie prüfen können, ob Ihr aktueller Anbieter dasselbe tut.

Drei Backup-Schichten, weil eine ein Single Point of Failure ist

Block-Snapshots, Cluster-Objekte und logische Datenbank-Dumps lösen unterschiedliche Probleme, und keines davon ersetzt die anderen.

Schicht eins: Volume-Backups. Ein wiederkehrender Longhorn-Job läuft um 01:00 UTC und sichert jedes gelabelte Volume inkrementell in Hetzner-Objektspeicher in Helsinki, mit sieben Tagen Aufbewahrung. Das ist ein vollständiges Abbild des Blockgeräts - schnell wiederherzustellen, aber bei einer laufenden Datenbank nur crash-konsistent.

Schicht zwei: Cluster-Objekte. Velero sichert Kubernetes-Manifeste - Deployments, StatefulSets, Secrets, ConfigMaps - mit einer Woche Aufbewahrung. Bewusst keine Volume-Daten: Das ist die Aufgabe von Schicht eins, und beides zu vermischen erzeugt Backups, die halb fehlschlagen, und zwar so, dass es niemandem auffällt.

Schicht drei: logische Dumps. Für Datenbanken, bei denen wir transaktionskonsistente Wiederherstellungen und die Granularität „setz es auf gestern zurück“ wollen, schreibt ein Cron-Job je Anwendung die Datenbank in einen eigenen Bucket, getrennt von den Volume-Backups.

Die Voreinstellung ist, etwas nicht zu sichern. Jedes geschützte Volume ist eine bewusste Zeile in einer Liste in Git, und jede Entscheidung, etwas nicht zu schützen, bleibt als kommentierte Zeile mit Begründung in dieser Liste. Sonst kann ein halbes Jahr später niemand mehr sagen, ob ein fehlender Eintrag eine Entscheidung oder ein Versehen war.

Was das Monitoring abdeckt

Alerts gibt es für die Fehlerbilder, die Dienste tatsächlich umwerfen, nicht für ein Dashboard voller Grün:

• Storage - Volumes über 80 % und über 90 % Füllstand, dazu ein Alert auf schnelles Wachstum für alles, was in einer Stunde 10 % zulegt. Wachstum, das über den Trend auffällt, ist besser als Wachstum, das über einen Ausfall auffällt.
• Storage-Gesundheit - degradierte und fehlerhafte Volumes, Knoten, deren Storage nicht bereit ist, Platten kurz vor dem Volllaufen.
• Cluster-Gesundheit - Speicher der Control Plane und der Worker, Größe der etcd-Datenbank, Knoten, die auf Not-Ready wechseln, I/O-Wait, TCP-Retransmits und CPU-Steal.
• Außerhalb des Clusters - Uptime-Probes, ablaufende TLS-Zertifikate, Wachstum der Mail-Queue und Plattenbelegung auf Einzelservern, die in dasselbe Prometheus melden.
• Logs - zentralisiert, damit ein Vorfall von einer Stelle aus untersucht wird statt durch Raten, welchen Pod man sich ansieht.

Storage so dimensioniert, dass es noch wachsen kann

Eine Regel prägt, wie wir dimensionieren, und sie lohnt sich zu übernehmen: ein Volume lässt sich vergrößern, niemals verkleinern.

Kubernetes lehnt eine Reduzierung der angeforderten Storage-Größe ab. „Legen wir zur Sicherheit etwas Reserve drauf“ ist deshalb keine Vorsicht - es ist eine unumkehrbare Entscheidung, und eine laute, weil ein späterer Versuch, die Zahl zu senken, das Upgrade zum Fehlschlag bringt und jedes weitere Deployment dieser Anwendung blockiert. Das rückgängig zu machen bedeutet Ausfallzeit, ein Backup, das Löschen des Volumes und das Wiederherstellen der Daten.

Wir dimensionieren daher knapp und wachsen reaktiv. Die Kapazitäts-Alerts geben uns Vorwarnung, die Erweiterung läuft online und braucht keine Ausfallzeit, und Vergrößern ist günstig, während Verkleinern teuer ist. Im Zweifel ist die kleinere Zahl die sicherere - genau das Gegenteil des Instinkts, den die meisten Leute haben.

Produktionsdaten liegen auf Storage mit drei Replikas. Storage mit einer Replika ist für Dinge reserviert, die wirklich entbehrlich sind, etwa Caches und Staging. Wir sparen an der Volume-Größe, niemals an der Redundanz für Livedaten.

Git ist die Quelle der Wahrheit, auch um drei Uhr morgens

In der Produktion wird nichts von Hand geändert. Deployt wird über Git und die Pipeline: Commit, Image-Build mit dem unveränderlichen Commit-SHA als Tag, Upgrade des Releases aus Charts und Values, die im Infrastruktur-Repository liegen.

Die Versuchung, ein Produktionssystem direkt zu reparieren, ist während eines Vorfalls am größten - also genau dann, wenn sie den größten Schaden anrichtet: Die Änderung ist im Audit-Trail unsichtbar und verschwindet beim nächsten Rollout, meist Wochen später, wenn niemand die beiden Ereignisse mehr verbindet. Notzugang existiert, ist aber eine ausdrückliche, protokollierte Entscheidung und keine Gewohnheit.

Wie Sie gehen würden

Wenn wir beschreiben, was wir nachts tun, ist es fair, auch den Ausstieg zu beschreiben. Sie können Ihre Daten jederzeit mitnehmen: Datenbank-Dumps, Volume-Inhalte, die Helm-Values und Manifeste, die Ihr Deployment definieren, und den Quellcode von allem, was wir für Sie individuell geschrieben haben. Alles läuft auf Standard-Open-Source-Komponenten - Kubernetes, Longhorn, Postgres, Keycloak - es gibt also keine proprietäre Runtime zum Abschalten und nichts, was nur läuft, solange eine Rechnung bezahlt wird.

Das ist keine Großzügigkeit. Ein Kunde, der bleibt, weil Gehen schmerzhaft wäre, ist ein Kunde, der aufgehört hat zu prüfen, ob wir gut sind.

Für wen das ist

• Unternehmen mit Produktionslasten, aber ohne eigenes Betriebsteam, wo die Frage „wer wird gerufen?“ heute eine unangenehme Antwort hat.
• Regulierte Organisationen, die Backups, Aufbewahrung und Wiederherstellung nachweisen müssen, statt sie zu behaupten.
• Teams, die Kubernetes schon betreiben und die Betriebsschicht abgeben wollen, ohne die Plattform aus der Hand zu geben.

Wie Sie anfangen

Sagen Sie uns, was Sie betreiben, welche Anforderungen Sie an Recovery Time und Recovery Point haben und was während der Migration weiterlaufen muss. Wir kommen mit einem Plan und einem Angebot zurück.

Schreiben Sie an info@cybermindnet.eu oder nutzen Sie das Kontaktformular.