Sieben Entscheidungskriterien

Kubernetes oder einfachere Containerplattform

0:00 Container sind heute so selbstverständlich wie Versionsverwaltung. Fast jedes Team packt seine Anwendungen in Images, und fast genauso oft folgt der nächste Gedanke wie von selbst: Dann brauchen wir auch Kubernetes. Manchmal stimmt das. Oft aber holt man sich damit eine Plattform ins Haus, deren Betrieb mehr Aufmerksamkeit bindet als die Anwendungen, die darauf laufen sollen.

0:21 In den nächsten Minuten geht es um genau diese Abwägung. Sie lernen vier Betriebsmodelle kennen, vom einzelnen Server bis zum selbst betriebenen Cluster, und sieben Kriterien, mit denen Sie herausfinden, welches davon zu Ihren Anwendungen, Ihrem Team und Ihrem Budget passt.

Vier Betriebsmodelle und die Frage davor

0:37 Bevor wir Kriterien anlegen, schauen wir uns an, was überhaupt zur Wahl steht. Zwischen „ein Server mit Docker" und „eigener Kubernetes-Cluster" liegt heute eine ganze Landschaft, und gerade die Mitte hat sich in den letzten Jahren stark verändert. Viele Aufgaben, für die man früher Kubernetes eingeführt hat, erledigen Cloud-Anbieter inzwischen als fertigen Dienst. Das verschiebt die Frage.

1:00 Stellen Sie sich vor, Sie brauchen ein Auto. Sie können eines kaufen und selbst warten, eines leasen, bei dem die Werkstatt inklusive ist, oder einen Fuhrpark mit eigener Werkstatt aufbauen. Der Fuhrpark ist das Leistungsfähigste, aber nur sinnvoll, wenn Sie wirklich viele Fahrzeuge und eigene Mechaniker haben. Genauso ist es mit Containerplattformen.

1:20 Dieses Kurzmodul nimmt Ihnen die Entscheidung nicht ab und empfiehlt auch keinen Anbieter. Es gibt Ihnen sieben Fragen an die Hand. Gehen Sie sie für Ihre Anwendungen durch, ergibt sich eine begründete Tendenz und nicht bloß ein Bauchgefühl, das am Ende jemand anderes betreiben muss. Lesen Sie die Tabelle von oben nach unten, dann sehen Sie ein Muster.

1:40 Mit jeder Zeile wächst die Kontrolle über die Plattform, und mit jeder Zeile wächst auch das, was Ihr Team selbst verantwortet. Auf dem einzelnen Containerhost kümmern Sie sich um einen Server. Bei der verwalteten Containerplattform kümmern Sie sich fast nur noch um Ihre Anwendung. Beim verwalteten Kubernetes kommen Clusterdesign, Erweiterungen und Upgrades hinzu, und beim selbst betriebenen Kubernetes zusätzlich die Steuerungsebene mit ihrer Datenbank und den Zertifikaten.

2:06 Keine Zeile ist per se besser. Die Frage ist, wie viel Verantwortung Ihr Team tragen will und kann. Die drei großen Cloud-Anbieter haben jeweils einen Dienst, der Container ausführt, ohne dass Sie einen Cluster sehen. Bei Microsoft heißt er Azure Container Apps, bei Google Cloud Run, bei Amazon ECS mit Fargate. Die Namen unterscheiden sich, das Versprechen ist ähnlich: Sie liefern ein Image, legen Speicher und Rechenleistung fest, und die Plattform kümmert sich um Endpunkte mit HTTPS, um das Hoch- und Herunterskalieren und um neue Versionen, die sich schrittweise einführen lassen.

2:39 Das ist genau der Teil, für den viele Teams vor einigen Jahren noch Kubernetes eingeführt hätten. Behalten Sie das im Kopf, wenn wir gleich zu den Kriterien kommen. Am anderen Ende der Skala steht der einzelne Server mit Docker Compose. Den belächeln manche, zu Unrecht. Docker selbst beschreibt ihn als einfachsten Weg, eine Anwendung bereitzustellen, und für wenige interne Anwendungen ist er oft genau richtig.

3:04 Ein paar Dinge sollten Sie vorher anpassen, etwa keinen Quellcode mehr von außen einbinden und eine Neustart-Regel setzen. Der eigentliche Stolperstein liegt woanders: Ein Server ist ein Server. Fällt er aus, steht alles, und Updates, Backups und Ausfallplanung liegen ganz bei Ihnen. Mehr als einen Rechner orchestriert Compose nicht. Wer das braucht, braucht etwas anderes.

Workloads, Last und Zustand

3:27 Jetzt zu den Kriterien, und wir beginnen bei dem, was am häufigsten übersprungen wird: bei den Anwendungen selbst. Welche Art von Programmen wollen Sie betreiben, wie schwankt ihre Last über den Tag, und wo liegen ihre Daten? Diese drei Fragen klingen banal. Sie entscheiden aber oft schon allein, ob Kubernetes überhaupt etwas beitragen kann.

3:47 Der wichtigste Ausgangspunkt ist nicht die Technologie, die man gern hätte, sondern das, was tatsächlich laufen soll. Eine Weboberfläche, eine Programmierschnittstelle, ein paar Hintergrundprozesse und nächtliche Jobs: Das ist das tägliche Brot jeder verwalteten Containerplattform. Interessant wird Kubernetes erst bei Anforderungen, die diese Dienste bewusst nicht anbieten.

4:07 Programme, die auf jedem Rechner im Cluster laufen müssen, Container mit erweiterten Rechten, eigene Automatisierungen, die den Cluster selbst steuern, Grafikkarten für Machine Learning oder ein einheitlicher Betrieb über Cloud, Rechenzentrum und Außenstellen. Fragen Sie also ehrlich: Brauchen wir diese Fähigkeiten, oder brauchen wir nur einen verlässlichen Ort für Container?

4:29 Auf der linken Seite steht der Komfort, auf der rechten die Kontrolle. Eine verwaltete Plattform skaliert nach Anfragen, Ereignissen oder Auslastung und kann eine Anwendung bei Stille ganz abschalten. Das spart Geld, hat aber einen Preis: Die erste Anfrage danach wartet, bis wieder eine Instanz gestartet ist. Kubernetes lässt Sie dagegen fast alles selbst bestimmen, welche Anwendung auf welchem Rechner läuft, in welcher Zone, mit welcher Priorität und auf welcher Hardware.

4:55 Die letzte Zeile ist die wichtigste. Diese Stellschrauben sind nur dann ein Vorteil, wenn Sie sie tatsächlich brauchen und Ihr Team sie beherrscht. Sonst sind sie bloß zusätzliche Fehlerquellen. Machen wir das an einem Beispiel greifbar. Tellerrand nimmt für einen Schulcaterer die Essensbestellungen von Eltern entgegen, für vierzig Schulen.

5:15 Morgens zwischen sieben und neun, kurz vor Bestellschluss, ist richtig was los. Nachts, am Wochenende und in den Ferien passiert dagegen fast nichts. Die Bestellschnittstelle, die Oberfläche für die Eltern und der Dienst, der die Küchenlisten erzeugt, speichern selbst keinen Zustand und reagieren auf Ereignisse. Genau für dieses Profil sind verwaltete Plattformen gebaut: hochfahren, wenn es voll wird, und herunterfahren bis auf null, wenn niemand bestellt.

5:41 Ein eigener Cluster würde hier vor allem eines tun, nämlich nachts Geld kosten. Bleibt die Frage nach den Daten. Es ist verlockend, die Datenbank gleich mit in den Cluster zu packen, wenn die Anwendung ohnehin dort läuft. Für viele Teams ist eine Trennung aber tragfähiger: die Anwendungen auf der Containerplattform, die Datenbank als verwalteter Dienst, Dateien im Objektspeicher.

6:04 Kubernetes hat durchaus Werkzeuge für zustandsbehaftete Programme. Aber, und das sagt die Kubernetes-Dokumentation selbst sehr deutlich: Es bringt keine Datenbanken und keine Nachrichtensysteme mit. Wer sie im Cluster betreibt, ist auch für Replikation, Sicherung, Wiederherstellung und Upgrades zuständig. Das ist ein eigener Beruf, kein Nebenprodukt der Containerisierung.

Kontrolle, Betriebsreife und Sicherheit

6:27 Die ersten drei Kriterien haben auf die Anwendungen geschaut. Die nächsten drei schauen auf Sie, auf Ihre Organisation. Wie viel Gestaltungsfreiheit brauchen Sie wirklich? Haben Sie die Leute, um eine Plattform dauerhaft zu betreiben? Und wie sollen Sicherheit und Abschottung geregelt sein? Hier fallen die Entscheidungen, die man erst Jahre später richtig zu spüren bekommt.

6:49 Kubernetes beschreibt sich selbst bemerkenswert ehrlich: Es ist ausdrücklich keine fertige Komplettplattform, sondern ein Baukasten, den man erweitern kann. Mit eigenen Ressourcentypen, Automatisierungen und Regelwerken lässt sich darauf eine maßgeschneiderte Plattform für ein ganzes Unternehmen bauen. Eine verwaltete Containerplattform geht den umgekehrten Weg.

7:10 Sie bringt Eingang, Geheimnisverwaltung, Skalierung, Versionen und Protokolle fertig mit und lässt Ihnen dafür weniger Spielraum. Die entscheidende Frage ist also nicht, welche Lösung die längere Funktionsliste hat. Sondern: Wollen Sie eine Plattform als eigenes Produkt entwickeln, oder wollen Sie einfach Ihre Anwendungen ausführen?

7:29 Ein verbreiteter Irrtum lautet: Wenn der Cloud-Anbieter Kubernetes verwaltet, ist der Betrieb erledigt. Das Schaubild zeigt, warum das nicht stimmt. Der Anbieter übernimmt die oberste Schicht, die Steuerungsebene samt Patches, auf Wunsch auch die Rechner darunter. Alles andere bleibt bei Ihnen: die Upgrades von Cluster und Erweiterungen, das Netzwerk, Identitäten und Geheimnisse, dann Überwachung, Sicherung, Kapazitätsplanung und der Notfall um drei Uhr nachts.

7:56 Und ganz unten steht etwas, das gern vergessen wird: die Entwicklungsteams, die Unterstützung, Dokumentation und Selbstbedienung brauchen. Eine Plattform, die niemand gern nutzt, wird umgangen. Die Forschungsgruppe DORA, bekannt für ihre jährlichen Studien zur Softwareauslieferung, hat dazu eine klare Haltung. Eine interne Plattform ist ein Produkt, und die Entwicklerinnen und Entwickler sind ihre Kunden. Sie soll Komplexität schlucken, nicht an die Teams weiterreichen.

8:24 Die typischen Fallen kennt man aus vielen Häusern: ein Plattformteam, das nur Tickets abarbeitet, statt Selbstbedienung zu ermöglichen, ein großer Start nach langer Bauzeit, wenn sich die Bedürfnisse längst geändert haben, oder eine starre Einheitslösung für alle. DORA warnt sogar ausdrücklich: Eine schlecht geführte Plattform kann die Auslieferung langsamer und instabiler machen.

8:44 Das ist kein Argument gegen Kubernetes, aber eines für Ehrlichkeit über die eigene Reife. Bei der Sicherheit ist Kubernetes ausgesprochen reich ausgestattet. Rollen und Rechte, getrennte Namensräume, Regeln für den Netzwerkverkehr, Kontingente und drei vorgefertigte Sicherheitsprofile für Pods, von sehr offen bis streng gehärtet.

9:04 Die offizielle Sicherheits-Checkliste verlangt unter anderem minimale Rechte und ein Netz, das standardmäßig alles verbietet. Das heißt aber auch: Jede dieser Möglichkeiten muss jemand richtig einstellen und regelmäßig prüfen. Mehr Freiheit bedeutet mehr Fläche für Fehler. Verwaltete Plattformen nehmen Ihnen viel davon ab, dafür akzeptieren Sie das Sicherheitsmodell des Anbieters.

9:25 Brauchen Sie wirklich eigene Mandanten- und Sicherheitsmodelle, oder vergrößert die Freiheit nur die Angriffsfläche?

Kosten, Matrix und Entwicklungspfad

9:33 Sechs Kriterien liegen hinter uns. Das siebte ist das, worauf am Ende fast jede Entscheidung hinausläuft, die Kosten. Allerdings nicht die, die auf der Preisliste stehen. Danach führen wir alles in einer kompakten Matrix zusammen und schauen, wie sich die richtige Wahl verändert, wenn ein Unternehmen wächst. Wer Plattformen nur über Rechenleistung und Speicherpreise vergleicht, vergleicht den kleineren Teil der Kosten.

9:58 Rechnen Sie über drei bis fünf Jahre, und zählen Sie die Menschen mit: das Plattformteam, die Rufbereitschaft, die Upgrades. Kubernetes erscheint etwa dreimal im Jahr in einer neuen Version, und jede wird rund ein Jahr lang mit Korrekturen versorgt. Wer nicht regelmäßig nachzieht, sitzt bald auf einer Version ohne Sicherheitsupdates. Dazu kommen Schulung, Überwachung und ungenutzte Kapazität.

10:20 Und noch ein Wort zur vielgepriesenen Portabilität: Das Image lässt sich überall starten. Die Anwendung mit ihren Identitäten, Netzen, Datenbanken und Geheimnissen hängt trotzdem an ihrer Umgebung. Diese Matrix fasst zusammen, wohin die sieben Kriterien in typischen Situationen zeigen. Sie lesen sie am besten nicht als Regelwerk, sondern als Gegenprobe.

10:41 Auffällig ist das Gefälle: Wenige Anwendungen, schwankende Last und kein eigenes Plattformteam zeigen fast immer zur einfacheren Lösung. Kubernetes rückt erst dann in den Vordergrund, wenn viele unterschiedliche Anwendungen, mehrere Teams, eigene Automatisierungen oder strenge Vorgaben für den eigenen Betrieb zusammenkommen.

11:00 Die beiden letzten Zeilen sind die ehrlichsten. Gibt es keinen klaren Bedarf, beginnt man einfacher. Und lautet die einzige Begründung, dass man ja Microservices habe, lohnt sich ein zweiter Blick auf die Entscheidung. Eine Plattformentscheidung ist keine Ehe auf Lebenszeit. Das Schaubild zeigt drei Phasen, die viele Unternehmen durchlaufen.

11:20 Am Anfang ein kleines Team mit wenigen Diensten und unvorhersehbarer Last, hier spielt die verwaltete Plattform ihre Stärken aus. Dann das Wachstum: mehr Teams, höhere Anforderungen an die Verfügbarkeit, der Wunsch nach gemeinsamen Standards. Und irgendwann vielleicht die Plattformphase mit vielen unterschiedlichen Anwendungen, Compliance-Vorgaben und Selbstbedienung für alle Teams.

11:42 Erst dort spielt Kubernetes seine Stärken voll aus. Tellerrand steht heute ziemlich eindeutig am Anfang dieser Kette. Daraus folgt ein Gedanke, der vielen Teams die Entscheidung erleichtert. Wer heute gegen Kubernetes entscheidet, entscheidet nicht für immer. Er entscheidet für die aktuelle Lage und kann festlegen, unter welchen Bedingungen er neu prüft.

12:02 Teurer als ein späterer Umzug ist fast immer eine Startarchitektur, die man vorsorglich viel zu groß gewählt hat und die das kleine Team dann jahrelang mitschleppt. Und den späteren Wechsel kann man sich leicht offenhalten: Images, Konfiguration und Auslieferung sauber voneinander trennen, keine unnötigen Abhängigkeiten zum Anbieter einbauen.

12:21 Dann ist der Umzug ein Projekt und kein Neuanfang.

Übung

12:25 Genug der Theorie. Jetzt sind Sie dran. Die sieben Kriterien entfalten ihren Wert erst, wenn man sie auf einen echten Fall anwendet, am besten auf Ihren eigenen. Wer gerade keinen zur Hand hat, nimmt Tellerrand, denn dort steht gerade eine Entscheidung an. Tellerrand hat Erfolg. Aus vierzig Schulen sollen dreihundert werden, zwei weitere Entwicklungsteams kommen hinzu, ein Dienst für die Rechnungen ist geplant und ein Abgleich mit den Verwaltungssystemen der Schulen.

12:52 Plötzlich wird die Frage ernst. Reicht weiterhin ein Server mit Compose, wechselt man auf eine verwaltete Containerplattform, oder ist jetzt der Zeitpunkt für verwaltetes Kubernetes gekommen? Alle drei Varianten haben ihre Fürsprecher im Team. Ihre Aufgabe ist es, nicht zu raten, sondern mit den sieben Kriterien eine Antwort zu finden, die Sie auch in einem Jahr noch begründen können.

13:14 Gehen Sie in fünf Schritten vor. Beschreiben Sie zuerst Ihre Landschaft knapp: welche Anwendungen, welche Last, welche Daten, wie viele Teams und wie viel Betriebskapazität. Dann nehmen Sie sich jedes Kriterium einzeln vor und notieren, in welche Richtung es zeigt. Die Daten betrachten Sie dabei getrennt, denn sie gehören oft woanders hin als die Anwendungen.

13:35 Erst danach legen Sie sich fest, mit Begründung und mit dem Risiko, das Sie bewusst in Kauf nehmen. Und zum Schluss das, was oft fehlt: ein Prüfpunkt. Also eine messbare Bedingung, bei der Sie die Entscheidung wieder auf den Tisch legen. Worum es bei dieser Übung eigentlich geht, ist eine Fähigkeit, nicht ein Dokument: eine Plattformwahl so zu begründen, dass sie einer kritischen Nachfrage standhält, und sie gegen die anderen Optionen abzugrenzen.

14:01 Fertig sind Sie, wenn zu jedem der sieben Kriterien eine Tendenz dasteht, die Wahl begründet ist und ein messbarer Prüfpunkt festhält, wann neu entschieden wird. Ein Tipp vorab: Rechnen Sie nicht mit einer reinen Lehre. Oft ist das Ergebnis eine Kombination, etwa die Anwendungen auf der Plattform und die Daten in einem verwalteten Dienst daneben.

Und jetzt?

14:21 Am Ende dieses Kurzmoduls steht kein pauschales Ja oder Nein zu Kubernetes, sondern eine begründete Wahl mit einem klaren Punkt, an dem Sie sie überprüfen. Für manche Teams heißt das: einfacher anfangen, als man dachte. Für andere heißt es: Kubernetes ist tatsächlich der richtige Weg, oder die Frage ist noch offen. Dann führt der nächste Schritt in das Seminar Docker, Podman und Kubernetes für Entwickler.

14:44 Dort geht es um Images, lokale Arbeitsabläufe, die Grundlagen eines Clusters und seine Absicherung, also um alles, was Sie brauchen, um die Entscheidung auch praktisch zu tragen. Mehr dazu finden Sie auf learning-master.de.