Volkmar Kellermann Häufig erwische ich mich dabei, wie ich in stillen Momenten den Nutzen von Komplexitäten überdenke, einfach, um zu schauen, ob bestimmte Dinge wirklich Sinnvoll sind oder eher in die Sparte Overenginiereing fallen.
Betrachten wir doch mal das Thema Kubernetes und Container. Ohne Frage bietet diese Technologie viele Vorteile hinsichtlich Standardisierung, Automatisierung und Hochverfügbarkeit. Dazu kommt eine riesige Open-Source-Community, die Tag für Tag für Innovation und Stabilisierung in und um Kubernetes sorgt. Aber welchen Preis muss ich für diese Vorteile zahlen?
Container machen es einfach möglich, mehrere Services auf einem Host-System zu betreiben und damit Overhead bei der Bereitstellung von virtuellen Servern zu sparen. Um das Ganze in den Griff zu bekommen, benötigt man allerdings mit Kubernetes etwas Orchestrierung für Container im Kontext der Infrastruktur.
Da ein Kubernetes-Cluster nicht genügt, braucht man davon gleich mehrere. Jeder Cluster bringt eine Control Plane mit, die im Schnitt aus 1 bis 5 Nodes besteht. Das sind alles virtuelle Maschinen, die ihren eigenen Overhead haben. Doch den wollten wir uns ja eigentlich durch Container sparen.
Stehen Kosten und Nutzen noch im Verhältnis?
Nun mag man meinen, dass eine Control Plane vergleichsweise wenig Ressourcen braucht. Wenn man es mal durchrechnet, ist es dennoch alles andere als trivial. Angenommen es sind zehn Kubernetes-Cluster in Betrieb. Das ist heutzutage eine eher überschaubare Anzahl. Da ein Anspruch an Hochverfügbarkeit besteht, geht man nun bei der Bereitstellung der Control Plane, von drei Control-Plane-Nodes je Cluster aus. Damit liegen bereits 30 VMs Overhead vor. Gibt man jeder dieser VMs 4 CPUs, 8 GB RAM und 50 Gigabyte Diskspace, benötigt man in Summe nur für die Bereitstellung der Control-Plane-Nodes 120 CPUs, 240 GB RAM und 1,5 Terabyte Storage. Dazu kommt noch, dass jede VM verwaltet werden muss.
Einen solchen Overhead in Zeiten, in denen wir über Nachhaltigkeit, Green IT und Energiekrise sprechen? Lest euch dazu gern den Beitrag zum Thema IT und CO2 Fußabdruck durch.
Die Vorteile, die Kubernetes als Orchestrierung für Applikations-Workloads im Einklang der Infrastruktur liefert, möchte niemand mehr missen. Das beweisen allein die Zahlen: Die Anzahl der Kubernetes-Cluster in den Datacentern ist steigend und das ist auch gut so. Infrastruktur-Automatisierung verschafft uns Flexibilität und Verfügbarkeit. Beides trägt dazu bei, dass Ressourcen effizienter eingesetzt werden können. Wie sich eine gut durchdachte Automatisierung beim Bau von Container Images auf die CO2-Bilanz auswirkt, beschreibt mein lieber Kollege Sebastian Zoll in diesem Beitrag: https://focus.sva.de/bessere-co2-bilanz-durch-automatisierte-image-builds/.
Was wäre, wenn man sich diesen Overhead einfach sparen könnte, ohne auf den Mehrwert einer Multi-Kubernetes-Cluster-Umgebung zu verzichten?
Schon von Kubermatic gehört?
Ein Unternehmen mit Sitz in Hamburg liefert eine Lösung. Gegründet 2016, noch unter dem Namen Loodse, könnte man Kubermatic als Pionier im Bereich Kubernetes-Multicluster-Management bezeichnen. Gut, Multicluster klingt erstmal nicht nach Vermeidung von Overhead, aber lesen Sie doch gerne weiter…
Control Plane in Containern
Man stelle sich vor, man packt die einzelnen Kubernetes-Komponenten der Control Plane, bestehend aus Controller Manager, Api Server und Etcd, in Container auf einem zentralen Kubernetes-Cluster. Das klingt vielleicht ein wenig verrückt. Wenn man allerdings drüber nachdenkt, ist es eine logische Konsequenz. Wenn man von einer Anzahl von 10 Clustern ausgeht, verfügt man über einen Initial Cluster bestehend aus 6 Nodes: 3 für Control Plane und 3 für den Workload der Plattform und die Control Planes der User-Cluster. Angewendet auf das oben angebrachte Beispiel, bedeutet das, dass mit jedem User-Cluster drei Nodes wegfallen. Dies spart bei 10 Clustern 30 Nodes. Wie sich dieser Zusammenhang bei mehreren hundert Clustern bemerkbar macht, lässt sich in der Abbildung gut erkennen. Hier wird Kubernetes, wie es klassisch bereitgestellt wird, dem Ansatz von Kubermatic bei einer Anzahl von 250 Clustern gegenübergestellt.
Ist das schon alles?
Die Sache muss doch einen Haken haben, oder? Nein hat sie nicht. Multicluster-Management aus der Tüte bringen nicht viele Plattformen mit. Dass dies noch mit dem geringen Ressourcenverbrauch für Control Plane und Etcd einhergeht, ist ein voller Gewinn. Dazu kommt, dass sich Cluster bei allen gängigen Cloud-Providern vollkommen automatisiert bereitstellen lassen. Die Rechte dazu können über Projekte sogar direkt an Entwickler:innen oder Application Owner deligiert werden. Die zugesicherten Ressourcen können bzw. sollten auf Basis dieser Projekte eingeschränkt werden. Somit kann sichergestellt werden, dass nicht blind virtuelle Instanzen gebaut werden.
Das User Interface der Kubernetes Kubermatic Platform, kurz KKP genannt, ist sehr fokussiert und zielgerichtet. Es verfügt über eine Admin-View, in der man plattformspezifische und projekt- bzw. Cluster-übergreifende Konfigurationen machen kann, sowie eine User-View, in der man über Projekte zu den eigenen Clustern gelangt. Um mehr über die im Cluster befindlichen Ressourcen zu erfahren, kann man sich über ein Kubernetes Dashboard einen Überblick über beispielsweise auf dem Cluster laufende Applikationsworkloads verschaffen.
Kubermatic liefert nach eigener Aussage Vanilla Kubernetes aus. Da kann man wohl nicht widersprechen. Die User Cluster enthalten keine herstellerspezifischen Custom Resourcen. Sollte man sich also später für eine andere Kubernetes Platform entscheiden, kann man ohne große Hindernisse migrieren.
Aufbau und Bereitstellung
Wie kann man sich denn nun den Aufbau eine Kubermatic-Cluster-Umgebung vorstellen?
Initial wird mittels KubeOne ein Basis-Kubernetes-Cluster für die Plattform selbst und für sogenannte Seed Cluster bereitgestellt. KubeOne ist ein zertifizierter Kubernetes Installer. Es ist OpenSource und eine leichte Wahl, wenn man einfach nur einen Kubernetes Cluster benötigt, den man hoch und runter skalieren kann. Für die Kubermatic Plattform dient es uns in diesem Fall als Basis-Cluster.
Auf KubeOne wird die KKP ausgerollt. Damit erhält man das User Interface, mit dem man Multicluster-Management betreiben kann. Um Cluster zu bauen, müssen allerdings noch sogenannte Seeds installiert werden. Diese sind das Bindeglied zwischen KKP, dem Cloud Provider und den bereitgestellten User Clustern. Man kann einen Seed für jeweils einen Cloud Provider bereitstellen.
Der Seed muss nicht zwangsläufig auf dem initialen KubeOne Cluster, der hier in der Regel selbst als Seed Cluster dient, laufen. Hier sind alle denkbaren Varianten umsetzbar. Hat man beispielsweise einen KubeOne Cluster im eigenen Datacenter und möchte gern Seeds in der Google Cloud bereitstellen, dann ist es möglich, dort auf einem abgesetzten Seed Cluster einen Seed für die User Cluster in der Google Cloud in Betrieb zu nehmen. So geht man eventuellen Verbindungsproblemen aus dem Weg und hält die Kommunikationswege kurz. Der limitierende Faktor ist in diesem Fall eigentlich nur die Netzwerkverbindung.
Fazit
Mit Kubermatic gibt es einen Hersteller, der den Betrieb von Kubernetes Clustern innovativ, fokussiert und ressourcengünstig zur Verfügung stellt. Ob im klassischen Datacenter-, Produktions- oder gar im Provider-Bereich: Kubermatic bringt in jeder Kubernetes-Umgebung, die mehr als 3 Cluster am Start hat, eine Menge Vorteile. Bedingt durch die Energiekrise und die steigenden Kosten für Server, ziehe ich im Übrigen meine Workloads bereits auf Kubermatic, um Overhead und damit Compute-Ressourcen zu sparen. Sprechen Sie mich gerne an, wenn so ein Umzug auch für Sie in Frage kommt.