Betriebskosten für Container-Workloads senken

Die Nutzung von Containern zur Bereitstellung von Anwendungen hat in den vergangenen Jahren stark zugenommen. Container-Orchestrierungsdienste wie Kubernetes, Docker Swarm oder verschiedene Managed Container Services von großen Hyperscalern wie Amazons AWS, Microsofts Azure und Googles Compute Cloud sind heute Standard-Tools für die Verwaltung von Container-Workloads in Unternehmen. Doch trotz der Vorteile von Containern, wie Skalierbarkeit und Flexibilität, können die Kosten für ihren Betrieb erheblich sein und variieren je nach gewähltem Anbieter. In diesem Zusammenhang ist es wichtig, die Kostenunterschiede zwischen den verschiedenen Orchestrierungsdiensten zu verstehen, um fundierte Budget-Entscheidungen treffen zu können.

Wer seine Container-Workloads kosteneffizient betreiben will, muss wissen, welche Möglichkeiten er dafür hat. Dadurch, dass inzwischen fast jedes Unternehmen auf Container setzt, ist der Markt in den vergangenen Jahren enorm gewachsen und hat viele hochinteressante Angebote generiert. Die Frage ist, welches Angebot ist das Richtige für Sie? Wir helfen Ihnen, den Überblick zu behalten:

Container Runtime

Diese Entscheidung kann für viele IT-Entscheider zweitrangig sein, auch wenn sich die Runtimes im Aufbau und im Toolset teils erheblich unterscheiden. Aus Operating-Sicht muss das System „unter der Haube“ die Container betreiben können und dafür ist die sog. Container Runtime verantwortlich. Das kann ContainerD sein, oder Docker oder eine andere Runtime. Ich gehe hier nur darauf ein, weil Folgendes wichtig ist: Die Container-Images sind dieselben. Beispiel: Wenn Ihre IT-Abteilung ein Container-Image mit Docker erstellt hat, dann kann dieses Image auch mit ContainerD ausgeführt werden. „Docker“ ist ein Synonym für Container im Allgemeinen geworden, was teilweise Einschränkungen suggeriert, wo keine sind. Das hat zu viel unberechtigter Unruhe geführt, als Kubernetes vor einiger Zeit verlauten ließ, dass sie Docker nicht mehr unterstützen würden. Tatsächlich sind mit Docker erstellte Container auch unter Kubernetes-Varianten lauffähig, die ContainerD als Runtime verwenden.

Kubernetes, oder nicht?

Für den Betrieb von Containern selbst gibt es mehrere Möglichkeiten, hier aufgeführt nach aufsteigender Komplexität und Möglichkeiten. Einige davon sind:

• ContainerD oder Docker, um einzelne Container zu betreiben
• Docker-Compose, um mehrere Container zu verbinden und zu betreiben, üblicherweise eine Applikation auf einem Server.
• Docker Swarm, um mehrere Applikationen auf mehreren Servern zu betreiben.
• Anbieterspezifische Services wie Amazons Elastic Container Service (ECS und Fargate)
• Kubernetes, um mehrere Applikationen auf mehreren Servern zu betreiben, erheblich komplexer konfigurierbar als Docker Swarm.

Wir beschränken uns in diesem Artikel ausschließlich auf Kubernetes als umfassendste und zumindest bei uns inzwischen einzige Plattform für den Betrieb von Container Workloads.

Kubernetes Distributionen

Wir betreiben inzwischen nahezu 100 % unserer Workloads auf Kubernetes, weswegen es für mich inzwischen zu einem Teil des Betriebssystems zählt. Entsprechend nenne ich nun auch verschiedene Kubernetes-Varianten “Distributionen”:

Das können Systeme sein, die man, eben wie ein Betriebssystem, selbst installiert, wie:

• Aus dem Hause SUSE, die Rancher Labs aufgekauft haben: ** K3S als eigenständige, leichtgewichtige Kubernetes-Distribution ** RKE1, RKE2 oder K3S provisioniert durch das Cluster-Verwaltungssystem „Rancher“
• Ubuntus MicroK8s
• Kubernetes’ eigenes Minikube für lokale Entwicklungs- und Test-Installationen
• Kubernetes aus einzelnen Komponenten konfiguriert und zusammengestellt für fortgeschrittene Nutzer, die einen hohen Anpassungsbedarf haben und daher nicht auf eine vorgefertigte Lösung setzen möchten.
• u. v. m.

Oder es sind verwaltete Kubernetes Systeme, also Managed Services, wie:

• bei Amazon AWS: Der Elastic Kubernetes Service (EKS)
• bei Microsoft Azure: Der Azure Kubernetes Services (AKS)
• bei Googles Cloud: Die Google Kubernetes Engine (GKE)

Das Resultat ist in allen Fällen ein Kubernetes-Cluster, den man über API bzw. dort angebundene Tools wie kubectl, helm und co. verwalten kann, und damit eine anbieterunabhängige Betriebsumgebung für meine Container-Workloads.

Anbieterunabhängig? Auch bei managed Services wie EKS, AKS und GKE? Ja! Jeder Cloudanbieter hat natürlich ein nachvollziehbares Interesse daran, seine Kunden an sich zu binden und bietet daher immer einige anbieterabhängige Zusatzfeatures für „seine“ Kubernetes-Distribution an, aber die muss (und sollte) man nicht nutzen, wenn man wirklich unabhängig bleiben will. Und mit Kubernetes kann man das eben. Das ist sicherlich nicht im Interesse der großen Hyperscaler – aber möglicherweise in Ihrem!

“Hard Actions” - was kann ich vor dem Aufsetzen eines Clusterbetriebs beachten?

Hier gibt es hauptsächlich eine Regel: Wählen Sie den für Ihre Anforderungen besten Anbieter aus. Verschiedene Faktoren sind üblicherweise:

• Betriebsstabilität / Ausfallsicherheit
• Level der durch Management abgedeckten Leistung, die man nicht selbst erbringen muss
• Sicherheit
• Preis
• Flexibilität bei der Leistung
• Serverstandort

Grob kann man die Angebote am Markt wie folgt von teuer nach günstig sortieren, solange es um die reine „Workload-Leistung pro Euro“ geht. Wir reden hier von Preisunterschieden von bis zu dem etwa Zehnfachen zwischen „Teuer“ und „Günstig“. Wohlgemerkt ohne differenzierte Betrachtung von Verwaltungsmehraufwänden bei Lösungen mit einem geringeren Managementanteil. Dafür sei auf den Abschnitt „Total Cost of Ownership“ weiter unten im Text verwiesen.

• Teuer: managed Cloud-Services wie EKS, AKS, GKE
• Mittel: virtuelle Maschinen von Cloud-Anbietern oder klassischen Rechenzentrumsanbietern mit selbstverwaltetem Kubernetes
• Günstig: Bare Metal, also echte Server in klassischen Rechenzentren oder OnPremise, also im eigenen Haus, mit selbstverwaltetem Kubernetes.

Der Begriff „Teuer“ sei hier aber keinesfalls negativ konnotiert. Alle hier dargestellten Lösungen existieren in einem hart umkämpften Marktgefüge. Es gilt also in jedem Fall: „You get, what you pay for“. Es ist aber wichtig zu verstehen, wofür man abhängig vom Skillset im eigenen Unternehmen eigentlich zahlen sollte, und wofür nicht.

“Soft Actions” - was kann ich im bestehenden Clusterbetrieb tun?

Einsparungsmöglichkeiten durch die Verwendung von Kubernetes-Ressourcenlimits und -requests

Es klingt, wie ein alter Hut – Untersuchungen zeigen aber, dass von dieser Möglichkeit nach wie vor zu wenig oder falsch Gebrauch gemacht wird: Durch die Definition von resource-requests und -limits können der Ressourcenverbrauch von Containern in Kubernetes gesteuert und damit indirekt die Kosten für den Betrieb reduziert werden.

Hierbei besonders zu beachten: Ressourcenlimits sollten immer nur in Kombination mit Ressourcenrequests vergeben werden, da Kubernetes bei einer reinen Angabe von Limits auch die Requests auf ebendiesen Wert setzt.

Ein Beispiel: Eine Workload benötigt im Normalfall nur einen halben CPU-Kern, sie soll aber maximal bis zu 4 CPU-Kerne nutzen dürfen, sobald sie mehr benötigt. Intuitiv würde man jetzt vielleicht nur das Limit auf 4 CPU-Kerne setzen. Das würde aber dazu führen, dass diese Workload nun immer auch eine Mindest(!)anforderung von 4 CPU-Kernen bei Kubernetes anmeldet. Eine (sinnvolle) Überprovisionierung wird so ausgeschlossen, was zu erheblichen Mehrkosten durch eigentlich unnötigen Leistungsbedarf führen kann. Korrekt wäre, zusätzlich auch noch einen Request von z. B.: 250m oder 500m zu setzen, um eben einen viertel oder einen halben CPU-Kern als Minimalanforderung an Kubernetes zu kommunizieren.

Verwendung von Kubernetes-Tools zur Überwachung und Optimierung von Ressourcennutzung

Hier können verschiedene Tools, allen voran Prometheus, zum Einsatz kommen, um den tatsächlichen Leistungshunger der verschiedenen Workload-Komponenten zu überwachen. Nicht selten stellt sich bei genauerem Monitoring nämlich heraus, dass bestimmte Container völlig zu Unrecht viel Last produzieren und oftmals recht einfach zu optimieren wären.

Kritische Stimmen werden nun zu Recht anmerken, dass wir hier Äpfel mit Birnen vergleichen, weil man das Gesamtbild des einzukaufenden Service in Betracht ziehen muss, und nicht nur das Endergebnis, nämlich einen funktionierenden Kubernetes Cluster.

Das ist sicherlich richtig, weswegen ich hier auf die Total Cost of Ownership anhand der verschiedenen Lifecycle-Elemente einer Betriebsumgebung eingehen möchte. Ich versuche diese Einschätzung hier so objektiv zu treffen, wie möglich, aber natürlich gilt: „Your mileage may vary:“ Für einige Unternehmen sind bestimmte Punkte sehr viel relevanter als andere.

Ich werde hier generell drei Varianten unterscheiden, in die sich die von uns verwalteten Systeme meist unterteilen lassen:

• Fully managed Kubernetes (EKS, AKS, GKE et al.) – im folgenden „FM“ genannt.
• Distribution managed Kubernetes (z. B. via Rancher) – im folgenden „DM“ genannt.
• Voll selbst aufgesetztes und konfiguriertes Kubernetes – im folgenden „SM“ genannt.

Darüber hinaus kommt es darauf an, ob das System auf virtuellen Maschinen (im Folgenden „VM“) gehostet wird, oder auf BareMetal (im Folgenden „BM“). Bei FM gehen wir hier immer von VMs aus. Wichtig: Distribution managed Kubernetes (also DM) kann und wird gerne auch auf VMs bei Hyperscalern wie AWS, Azure und Google Cloud installiert. So kann man die ausgezeichnete Verfügbarkeit und Skalierbarkeit eines Großanbieters mit der Unabhängigkeit eines Distribution managed Kubernetes optimal kombinieren. Ein späterer Umzug zu einem anderen Anbieter wird damit maximal vereinfacht.

Training / Einlernphase

In jedem Fall muss man sich mit Kubernetes als Nutzer auskennen – bei egal welcher Lösung. Dieser Punkt ist also ohnehin gegeben.

• FM: Zusatzknowhow benötigt, für den Betrieb auf diesen Plattformen. Das kann je nach Hyperscaler erheblich sein.
• DM: Zusatzknowhow für den Betrieb des Kubernetes-Managers benötigt. Im Normalfall ist der Lernaufwand hier überschaubar.
• SM: Zusatzknowhow für den Betrieb, Konfiguration, Updates etc. von Kubernetes selbst benötigt. Das kann erheblich sein.

Es mag kontrovers sein, aber gerade beim Punkt „Training“ ist für mich ein voll verwalteter Service eines Hyperscalers eher mit mehr, als weniger Lernaufwand verbunden. Ich sehe hier die verschiedenen, anwenderfreundlichen und plattformunabhängigen Kubernetes-Distributionen als die klaren Gewinner.

Reparaturen / Desaster Recovery

In jedem Fall gilt: Sollte man es doch einmal geschafft haben, seinen Kubernetes-Cluster zu zerstören, und nicht nur die Workloads darauf, muss man manuell eingreifen.

• FM/DM/SM: Abhängig vom Setup unterschiedlich komplexe Wiederherstellung aus Backups oder Neuprovisionierung. Aufwände insgesamt vergleichbar, sofern die Installationsprozesse (vor allem bei SM) durch Infrastructure as Code-Maßnahmen abgebildet wurden.

• BM-Installationen: Zusätzlicher Aufwand bei der Wiederherstellung, da ggf. Hardware neu beschafft/provisioniert/installiert werden muss.

Maintenance / Verwaltung / Updates/ Upgrades / Service

Kubernetes-Versionsupgrades können immer wieder Inkompatibilitäten mit den auf dem Cluster betriebenen Workloads generieren. Das betrifft alle Installationstypen gleichermaßen.

• FM: niedrigster Aufwand, da hier die einzelnen Server-Nodes nicht zugreifbar sind und damit auch nicht gewartet werden müssen/können.
• DM: erhöhter Aufwand durch Betriebssystem-Updates auf den einzelnen Servern.
• SM: deutlich erhöhter Aufwand durch Betriebssystem-Updates auf den einzelnen Servern und manuelle Kubernetes-Updateprozesse

Service / Support

• FM: Sehr kostenintensiv, wenn vom Hyperscaler eingekauft, wenige Experten am Markt, da diese Kubernetes und Hyperscaler-spezifisches Know-how benötigen.
• DM/SM: Wenige Experten am Markt, aber keine Kombination mit Clowdanbieter-spezifischem Know-how erforderlich.

Security

• FM: mit Abstand die komplexeste Rechteverwaltung. Die Zugriffs-Rechteverwaltung der Hyperscaler ist äußerst komplex und lässt sehr granulare Konfigurationen zu. Das ist einerseits eine Stärke, führt im Gegenzug aber auch zu möglichen Fehlerquellen und Damit SIcherheitslücken bei der Konfiguration und zu erheblichen Mehraufwänden bei der Konfiguration. Positiv ist, dass Hyperscaler oft Add-Ons für ihre Kubernetes-Installationen anbieten, die weitere Sicherheitsaspekte abdecken. Zusammenfassend kann man sagen: Hyperscaler bieten hier mehr Möglichkeiten “out of the box”, bei deren Implementierung aber im Gegenzug auch erhebliche Aufwände entstehen.

• DM/SM: Abhängig von Distribution und eingesetztem Hoster. Zusammenfassend kann man sagen: Man bekommt die Sicherheit, die man sich installiert und konfiguriert.

Für alle Installationstypen gelten die gleichen Vorgaben und die gleichen empfohlenen Maßnahmen, was generelle IT-Sicherheit angeht.

Für mich persönlich sind Kubernetes Distributionen, beispielsweise Rancher mit RKE/K3S, für das Management von Kubernetes der klare Favorit bei der Wahl einer Betriebsumgebung für Container Workloads.

Egal, ob ich als Nodes letztlich VMs eines Hyperscalers wie AWS oder Azure, eines klassischen Hosting-Anbieters, oder Bare-Metal Maschinen verwende. Mit einer K8S-Distribution bleibe ich anbieterunabhängig und habe einen Großteil der Komplexität einer K8S-Installation weg abstrahiert – eben so, als wäre es Teil meines Betriebssystems.

Hier einige Entscheidungskriterien, die ich für die Wahl einer bestimmten Hostingplattform für mein Distribution-Managed Kubernetes heranziehen würde:

• Wenn ich Workloads und deren Leistungsbedarf testen muss -> Hyperscaler VMs (Beispielsweise AWS EC2)
• Wenn ich sehr hohe Ausfallsicherheit bei einfacher Skalierbarkeit haben möchte -> Hyperscaler VMs
• Wenn ich einfache, günstige Installationen benötige -> Hosting-Anbieter root VM
• Wenn ich sehr viel Leistung zu günstigen Konditionen möchte und mein Kubernetes-Cluster den Ausfall eines Nodes zuverlässig ausgleichen kann -> Klassisches RZ mit Bare-Metal Servern.

Auf diese Weise können sich auch hybride Cloud-Infrastrukturen bilden, bei denen man die einzelnen Komponenten eines größeren Systems dort betreibt, wo es am meisten Sinn ergibt.

Und noch ein Satz in eigener Sache: Natürlich unterstützen wir auch Sie gerne mit Rat (Consulting) und Tat (Setup, Migration und Betrieb) bei der Einführung oder dem Betrieb von Kubernetes bei Ihnen im Unternehmen. Melden Sie sich einfach bei uns, und wir sprechen darüber!