Einführung in Kubernetes, Teil 1: Logik und Terminologie
Schlau steuern
Wer auf den Docker-Zug aufspringt, merkt schnell, dass die Verwaltung der Container von Hand eine Menge Arbeit macht. Kubernetes tritt an, den Betrieb von Container-Umgebungen zu automatisieren und zu orchestrieren.
Wer sich aktuell mit den Themen Cloud und Container beschäftigt, stößt immer wieder auf eine Software: Kubernetes. Googles Container-Verwaltung hat in den vergangenen Monaten die Herzen vieler Admins im Sturm erobert – zumindest die Herzen jener Admins, die sich ohnehin bereits mit Containern und verteilten Systemen beschäftigt haben.
Wer bisher mit diesen Themen keinen Kontakt hatte, findet den Kubernetes-Hype hingegen erfahrungsgemäß eher befremdlich: Meist ist zwar bekannt, dass es um Docker und Container-Verwaltung geht. Doch was Kubernetes tatsächlich ist und wie es im Kern funktioniert, ist nicht jedem Admin klar.
Schade – denn Container haben im Alltag durchaus eine Daseinsberechtigung: Richtig eingesetzt machen sie dem Admin das Leben leichter und erlauben es, Software – die typische „Legacy“-Software ist dabei ausdrücklich eingeschlossen – effektiv zu betreiben.
In diesem ersten Teil des Tutorials geht es zunächst um die Frage, was Kubernetes ist, wie es sich von anderen Systemen – etwa klassischer Virtualisierungsverwaltung – unterscheidet und welche Begriffe aus dem Kubernetes-Universum Admins kennen sollten. Der zweite Teil wird das Thema ganz praktisch angehen und sich mit der Frage beschäftigen, wie sich ein minimales Kubernetes-Setup aufsetzen und erforschen lässt, um erste Erfahrung zu sammeln. Teil 3 beschäftigt sich mit der Nutzung von Kubernetes im Rechenzentrum: Worauf sollten Admins achten, die eine große Kubernetes-Umgebung planen? Und wie lassen sich die beim „Trockenschwimmen“ gewonnenen Erkenntnisse in die Praxis übertragen?
Das leidige Thema Clustering
Seitdem Computer Bestandteil kritischer Infrastruktur sind, muss deren Hang auszufallen als Risiko berücksichtigt werden. Admins können bestätigen, dass in einem typischen Rechenzentrum eine ganze Reihe von Komponenten dazu neigt, den Betrieb zu verweigern: Festplatten, RAM, Lüfter, Netzwerk-Switches, Sicherungen und dergleichen mehr. Genauso lange beschäftigen sich Admins und Firmen mit Hochverfügbarkeit und Redundanz. Wer auf Linux schon mal hochverfügbare Dienste bauen wollte, hat sich vermutlich mit Systemen wie Pacemaker oder Red Hats Cluster Suite (RHCS) herumgeschlagen. In Sachen Benutzerfreundlichkeit sind sie allerdings nicht das Gelbe vom Ei. Und eine „angeklebte“ HA-Lösung ist nie so gut wie ein redundanter Ansatz, der in der Applikation implizit angelegt ist.
Inzwischen haben sich die Bedingungen merklich geändert: Wo Admins vor Jahren noch ganze Serverparks selber pflegten, setzen sie heute oft auf die Cloud und verlagern ihren Workload in eine Privat-Cloud-Plattform oder zu Amazon & Co. Praktisch alle gängigen Cloud-Konzepte gehen das Thema HA jedoch anders an als konventionelle Plattformen: Amazon etwa weist seine Kunden bei AWS explizit darauf hin, dass jede Komponente der Cloud ohne Vorwarnung ausfallen kann. Der Rat lautet, man solle seine Applikation einfach so bauen, dass sie gegen etwaige Ausfälle gewappnet ist und weiter funktioniert.
Ambivalentes Verhältnis
Diese Amazon-Aussage weist auf eine Veränderung im Design von Software hin, die sich in den vergangenen Jahren – beinahe im Vorbeigehen – ergeben hat. Denn gerade weil das Clustern von Legacy-Anwendungen so lästig war, kümmern sich die meisten Anwendungen neueren Datums selbst um ihre Hochverfügbarkeit – sie sind inhärent redundant. Diese Entwicklung hat der Cloud-Hype zwar nicht ausgelöst, doch beide Ansätze haben sich gegenseitig befeuert. Unter Entwicklern gilt es jedenfalls als gute Sitte, sich beim Design neuer Software oder Systeme so gut wie möglich um das Thema Redundanz zu kümmern.
Die zweite signifikante Veränderung in der Alltagsarbeit von Admins ist der immer stärker werdende Drang zur Automatisierung. Schließlich gibt es nicht nur Unternehmen, die die Cloud nutzen, sondern auch solche, die Cloud-Plattformen betreiben – mit Dutzenden oder Hunderten von Servern. Wollten Admins sie einzeln und händisch pflegen, wie es noch vor Jahren üblich war, würden sie früher oder später den Überblick verlieren – und das Setup wäre fehleranfällig. Amazon hat das im Februar gekonnt unter Beweis gestellt, als ein einzelner händisch produzierter Tippfehler Teile von S3 für mehrere Stunden lahmlegte. Und auch, wer virtuelle Umgebungen in der Cloud betreibt, sieht sich vielen Instanzen gegenüber. Ansible, Puppet, Chef & Co. leisten einen bedeutenden Beitrag dazu, dass die Arbeit der Admins machbar bleibt.