Kubernetes: wann ein mittelständisches Unternehmen es nicht braucht

Kubernetes ist überall: in Stellenanzeigen, in Architekturvorschlägen, in den Plattformen der großen Cloud-Anbieter. Es ist zum Standard für Systeme geworden, die Hunderte von Diensten betreiben, und das zu Recht. Für ein Unternehmen mit 20 bis 500 Mitarbeitenden, das eine Handvoll Werkzeuge betreibt, lautet die Frage nicht, ob Kubernetes ein gutes Werkzeug ist (das ist es), sondern ob es ein Problem löst, das das Unternehmen tatsächlich hat.

Dieser Artikel unserer Rubrik Infrastruktur und Cloud erklärt, was Kubernetes bringt, was sein Betrieb kostet und welche Zeichen sagen, dass man vorerst oder dauerhaft darauf verzichten kann.

Kurz gesagt

• Kubernetes verteilt Container auf mehrere Maschinen und hält sie im beschriebenen Zustand: Das ist seine Stärke, wenn es viele Dienste und mehrere Maschinen gibt.
• Es liefert weder Datenbank noch Überwachung noch Sicherung: Diese Baustellen bleiben vollständig bestehen.
• Es will gepflegt werden: Jede Minor-Version erhält etwa ein Jahr lang Korrekturen, und eine veraltete Version kann bei einem Anbieter teurer werden.
• Einige Dienste auf ein oder zwei Servern lassen sich einfacher verwalten, mit in einer Datei beschriebenen Containern, getesteten Sicherungen und einem Wiederanlaufplan.

Was Kubernetes tut, in einem Satz

Die Kubernetes-Dokumentation beschreibt es als portable, erweiterbare Open-Source-Plattform zur Verwaltung containerisierter Workloads. Konkret beschreiben Sie den gewünschten Zustand (dieser Dienst, in drei Instanzen, mit so viel Speicher), und Kubernetes arbeitet fortlaufend daran, diesen Zustand auf einer Gruppe von Maschinen herzustellen: Es startet neu, was ausfällt, verteilt die Last und rollt neue Versionen schrittweise aus.

Die erste Zahl zeigt, dass Kubernetes bei denen, die Container bereits in großem Maßstab nutzen, zum Standard geworden ist. Die beiden anderen erinnern daran, dass man es nicht wie eine Software einführt, die man einfach installiert: Es verändert die Arbeitsweise eines Teams.

Was Kubernetes nicht tut

Das ist der am wenigsten bekannte Teil, und die offizielle Dokumentation ist hier sehr deutlich. In ihrem Abschnitt darüber, was Kubernetes nicht ist, stellt sie klar, dass es:

• keine integrierten Anwendungsdienste wie Datenbank, Cache oder gemeinsamen Speicher bereitstellt;
• keine Lösung für Protokollierung, Überwachung oder Alarmierung vorschreibt oder liefert, abgesehen von Mechanismen zum Sammeln und Exportieren von Metriken;
• Ihre Anwendung nicht baut und Ihren Quellcode nicht ausrollt;
• kein vollständiges System zur Konfiguration, Wartung oder Verwaltung der Maschinen bietet.

Mit anderen Worten: Wer Kubernetes einführt, hat damit weder Sicherungen noch Überwachung noch Datenbank gelöst. Diese Baustellen bleiben vollständig bestehen und müssen zusätzlich in Kubernetes eingepasst werden. Für ein kleines Team ist das der entscheidende Punkt: Man fügt eine Schicht hinzu, die betrieben werden muss, und nimmt keine weg.

Was der Betrieb kostet

Kubernetes entwickelt sich schnell. Die Versionsseite des Projekts gibt an, dass nur die drei letzten Minor-Versionen gepflegt werden und jede etwa ein Jahr lang Korrekturen erhält. Ein Cluster muss also mindestens einmal pro Jahr aktualisiert werden, und jedes Mal ist zu prüfen, ob alles, was darauf läuft, mitzieht.

Bei einem Anbieter hat dieser Rhythmus einen ausdrücklichen Preis. Bei AWS zum Beispiel kostet ein verwalteter Cluster 0,10 Dollar pro Stunde im Standard-Support und 0,60 Dollar im erweiterten Support, wenn seine Version den Standardzeitraum überschritten hat. Andere Anbieter haben ihre eigenen Preislisten; das Prinzip bleibt gleich: Aufgeschobene Wartung kostet Geld. Diese Kosten kommen zu den Maschinen selbst hinzu, und wir haben sie unter den fünf Posten eingeordnet, die eine Cloud-Rechnung aufblähen.

Die Hauptkosten bleiben menschlich: Es braucht jemanden, der die Funktionsweise des Clusters versteht, seine Netzwerke, Berechtigungen und Aktualisierungen, und der erreichbar ist, wenn er sich falsch verhält. Kubernetes schafft die Arbeit der Systemadministratoren nicht ab: Es verlagert sie hin zu spezialisierteren Kompetenzen.

Woran Sie erkennen, dass Sie es nicht brauchen

Die Schwelle von etwa zwanzig Diensten ist keine Norm, sondern eine Größenordnung, die Sie mit Ihrer eigenen Situation abgleichen sollten. Das verlässlichste Kriterium bleibt jeweils das letzte jeder Spalte: die verfügbare Kompetenz, um es zu betreiben.

Was stattdessen genügt

Für die meisten mittelgroßen Unternehmen deckt ein einfacherer Aufbau den Bedarf:

• in einer Datei beschriebene Container, mit Docker Compose, das seine Dokumentation als Werkzeug zum Definieren und Ausführen von Anwendungen mit mehreren Containern beschreibt; die Beschreibung der Dienste liegt in einem versionierten Repository und lässt sich auf einer anderen Maschine erneut abspielen;
• ein Router vor den Diensten, der Adressen und Zertifikate verwaltet;
• Sicherungen außerhalb des Servers, die tatsächlich wiederhergestellt werden, und eine schriftliche Liste der Dienste und ihrer Volumes;
• eine externe Überwachung, die meldet, wenn ein Dienst nicht mehr antwortet;
• ein schriftlicher Wiederanlaufplan, mit gemessener tatsächlicher Wiederherstellungszeit.

Die Grenze dieses Aufbaus ist bekannt: Ein einzelner Server ist ein Single Point of Failure. Wenn Ihr Geschäft einen Stillstand für die Dauer einer Wiederherstellung nicht verkraftet, ist die erste Stufe nicht zwingend Kubernetes: Ein zweiter Server, der übernehmen kann, oder verwaltete Dienste bei einem Anbieter decken den Bedarf oft mit weniger Komplexität. Die Abwägungen zwischen Server und Cloud finden Sie in Dedizierter Server, VPS oder Cloud: nach Nutzung wählen.

Wenn Sie es trotzdem einsetzen

Es gibt gute Gründe dafür: ein Team, das es bereits beherrscht, eine Anwendung, die skalieren muss, ein Hersteller, der seine Software nur in dieser Form ausliefert. In diesem Fall drei Vorsichtsmaßnahmen:

1. Einen verwalteten Dienst bevorzugen, wenn bei Ihnen niemand einen Cluster betreibt: Der Anbieter übernimmt den heikelsten Teil.
2. Die Aktualisierungen von Anfang an einplanen, mindestens eine pro Jahr, mit einer Testumgebung.
3. Außerhalb des Clusters lassen, was nicht hineingehört, etwa eine verwaltete Datenbank, statt alles hineinzuzwängen.

Der Cluster ergänzt dann die gemeinsame Infrastrukturbasis Ihrer Projekte: gleiche Regeln für Zugriffe, Sicherungen und Budget.

Wo Sie anfangen

Zählen Sie Ihre Dienste und notieren Sie für jeden, wer ihn betreibt und welche Unterbrechung akzeptabel ist. Wenn die Liste kurz ist und einige Minuten Stillstand das Geschäft nicht gefährden, beginnen Sie mit gut beschriebenen Containern, Sicherungen, die sich wirklich wiederherstellen lassen, einer Überwachung, die vor den Kunden warnt, und einem schriftlichen Notfallwiederherstellungsplan. Ein konkretes Beispiel dieses Aufbaus finden Sie in n8n selbst gehostet in Produktion.

Die anderen Artikel der Rubrik behandeln die benachbarten Schritte: die Werkzeuge, die Sie zuerst aus dem SaaS holen sollten, die wahren Kosten eines SaaS-Ausstiegs über drei Jahre, die Cloud-Migration, ohne alles kaputtzumachen, die Abhängigkeit Europas von der amerikanischen Cloud und was NIS2 von französischen Unternehmen verlangen wird.

Wenn Sie diesen Aufbau für Ihre Verwaltungswerkzeuge möchten: Unser SaaS-Ausstieg installiert ihn auf einem eigenen Server, bis zu fünf Dienste, getestete Sicherungen und Dokumentation inklusive. Wenn Ihnen ein Team Kubernetes vorschlägt und Sie eine zweite Meinung wünschen, beschreiben Sie uns das Projekt.

Häufige Fragen

Quellen

1. Kubernetes, Overview (neuer Tab)kubernetes.io
2. Kubernetes, Releases (neuer Tab)kubernetes.io
3. AWS, Preise für Amazon EKS (neuer Tab)aws.amazon.com
4. Docker, Docker Compose (neuer Tab)docs.docker.com