…oder mit Kubernetes verwalten sich ihre Services wie von selbst

Haben Sie auch schon mal über einen ClusterCluster In der IT ist ein Cluster ein Verbund von mehrerern Komponenten wie Speichern oder Rechnern, die zum Zweck der Ausfallsicherheit oder Leistungserhöhung den selben Service ausliefern. nachgedacht, um Ihre Rechenleistung zu skalieren oder bei einem Hardware- oder Standortausfall Ihren Service einfach weiter zu betreiben?

Klar – aber die Kosten, die komplexe Konfiguration und der Leerlauf im Regelbetrieb schrecken Sie ab. Hier kommt Kubernetes oder wie in diesem Fall K3s ins Spiel. Sie haben bestimmt schon von Docker-ContainernDocker-Container Als Docker-Container bezeichnet man eine Technologie, bei der ein Service und alle Komponenten die zu seiner Erbringung notwendig sind in einem Paket, dem so genannten Container zusammengefasst werden. Die Schnittstellen werden abstrahiert und an den Container-Dienst, z.B. Dockerd übermittelt. gehört. Das ist zwar nicht die Einzige mögliche Lösung für K3s, der Einfachheit halber möchte ich mich aber hier darauf beschränken.

Mit Docker-Containern kann man – falls man die Konfiguration einmal passend erstellt hat – recht schnell einen Service bereitstellen. Alle Abhängigkeiten sollte der Container dabei mitbringen. Einen Schritt weiter gedacht, könnte man in Ausnahmesituationen einfach schnell ein paar weitere Container starten und – ein geeigneter und vorbereiteter Service vorausgesetzt – die Leistung ganz fix skalieren, oder einen ausgefallenen HostHost Als Host bezeichnet man einen PC / Server, welcher das für eine Virtualisierung benötigte Betriebssystem (KVM, VMWare®) für Gastrechner bereitstellt. Oft auch scherzhaft "Blech" genannt, da hier meist die "reale" Hardware gemeint ist. woanders wieder zum Leben erwecken.

Ja klar, macht der brave Administrator alles, auch am Sonntag nachmittag… Besser wäre vielleicht ein System, welches sich automatisch darum kümmert. Hier kommen Kubernetes (K8s) und K3s ins Spiel, die können das ganz gut. Zu den Hauptunterschieden von K8s und K3s gehört wohl der Umfang der Basis-Installation. So möchte K8s gleich mal 3 Master ServerMaster / Slave Als Master oder Slave bezeichnet man in der IT historisch viele hierarchische Abhängigkeiten. Eine mögliche Bezeichnung wäre Haupt- und Nebengerät. K3s stellt aber keine aufgewokte Bezeichnung bereit., die nichts anderes tun als die Worker-Nodes zu verwalten. Das ist zwar aus Sicht eines Ausfalles toll, aber schon sehr ressourcenintensiv. K3s kommt erst mal mit einem Master, der auch noch Worker-Node ist viel spartanischer daher, für reine Testumgebungen sollte das auch durchaus reichen. Mit einem Einzeiler auf der Kommandozeile lassen sich recht flott Worker-Nodes hinzufügen, oder auf Wunsch auch ein weiterer Master.

Jetzt kommt der Trick 17

Wir geben K3s ein Ziel vor, zum Beispiel fordern wir vom K3s-Master einfach 3 Apache-Webserver an, das definieren wir in einem so genannten Pod. Diesen Pod und die darin angeforderten Webserver-Container kann K3s jetzt auf den Nodes verteilen wie er möchte, oder wie es der interne Service Load Balancer vorsieht. Tritt eine Situation ein, bei der das Ziel nicht mehr erfüllt ist, weil vielleicht ein Host mit einer Worker-Node nicht erreichbar ist, wird K3s versuchen (einen) weitere(n) Container auf einem verfügbaren Node zu starten. Das macht K3s so lange bis das Ziel erreicht ist, oder keine weitern (freigegebenen) Ressourcen mehr zur Verfügung stehen. Dann bleibt der Service im Status degraded, oder im schlechtesten Fall steht er nicht zur Verfügung.

Das hört sich bisher alles ganz nach der Erfüllung vieler Adminwünsche auf einmal an, jedoch ist die Konfiguration teilweise sehr anspruchsvoll. Wir wollen schließlich nicht nur einen Webserver, sondern auch die passende Webseite, CMS, Datenbank usw. bereitstellen. Der erste Service mit einem „Hallo Welt“ ist in wenigen Minuten online, die gesamte Firmenwebseite, die auch bei einem Ausfall, oder bei blitzartigem Besucheransturm weiter läuft stellt ein ganz anderes Kaliber dar.

Nützliche Helfer

Damit die ganze Sache ein wenig übersichtlicher wird, bietet sich Open-Lens als grafische Benutzeroberfläche an. Hier gibt es diverse Möglichkeiten den Cluster, die Nodes und die darauf laufenden Pods zu verwalten.

Helm soll beim Verwalten und Verteilen der Pods behilflich sein. Das geschieht über sogenannte Charts und eine recht umfangreiche Biosphäre an bereitgestellten Templates und Containern, was bei mir bisher ganz gut funktioniert hat.

Fazit

K3s geht sparsam mit ihren Ressourcen um. Einmal sauber eingerichtet kümmert sich der Clustermanager um die Verteilung Ihrer Services auf die vorgesehenen Plattformen. Mit ein paar kleinen Änderungen an den Pod-Konfigurationen lassen sich schnell eine Menge Container verteilen oder wieder stilllegen.

Vielleicht gar keine so schlechte Idee ein eigener Cluster.