Einführung in Kubernetes, Teil 3: Produktiveinsatz planen und vorbereiten
Cluster-Regatta
Im dritten Teil des Kubernetes-Tutorials geht es vorrangig um die praktischen Aspekte des Betriebs der Software. Wie lässt sich Hochverfügbarkeit erreichen? Wo lauern Design-Fallstricke? Und: Ein Kubernetes oder viele?
In den vergangenen Teilen des Tutorials hat iX Kubernetes im Detail vorgestellt und die Konzepte und Ansätze erklärt. Im zweiten Teil ging es um drei Varianten, den Erstkontakt herzustellen und im selbst gewählten Tempo die Lösung kennenzulernen. Den Abschluss der Reihe bilden Überlegungen praktischer Art: Zwar lässt sich mit Minikube oder Kubeadm ein Cluster schnell hochziehen. Doch für den produktiven Einsatz im Rechenzentrum eignet sich ein solches Vorgehen nur bedingt.
Denn wer Kubernetes praktisch betreiben möchte, sieht sich gleich mit mehreren zentralen Fragen konfrontiert, für die eine automatisierte Installation Antworten bietet: Soll es wirklich ein einziger und großer Kubernetes-Cluster für verschiedene Kunden sein oder sind viele kleine Installationen nicht die bessere Wahl? Wie lassen die sich sinnvoll und effizient installieren und betreiben? Wie sorgen Administratoren dafür, dass die gängigen Best Practices in Sachen Redundanz zur Anwendung kommen? Und gibt es Stolperfallen, die der Admin besser von vornherein umschifft? Den Anfang macht die Frage nach dem besten Deployment-Ansatz.
Ohne Automatisierung geht es nicht
Am Ende von Teil zwei klang an, dass der Betrieb im Rechenzentrum nicht durch simple Shell-Werkzeuge befriedigend zu erreichen ist. Das hat mehrere Gründe. Zum einen ist eine Kubernetes-Installation immer ein Setup, das potenziell in die Breite skalieren muss. Wo heute zehn Server ihren Dienst verrichten, sind es in zwei Monaten vielleicht schon 200. Und die stellen Administratoren vor ganz andere Herausforderungen als das Mini-Setup, mit dem sie ihre Kubernetes-Karriere möglicherweise begonnen haben.
Zum Glück ist das Problem nicht neu: OpenStack, das die Cloud-Welt seit Jahren zumindest auf der Open-Source-Seite dominiert, steht in vielerlei Hinsicht vor ähnlichen Herausforderungen. Deshalb sind Aspekte des Betriebs großer Installationen hinlänglich analysiert und dokumentiert. An erster Stelle steht die Administration per se: Wie verwaltet der Admin 100 oder mehr Rechner so, dass das Personal nicht linear mit der Zahl der benötigten Knoten skaliert? Das Zauberwort heißt in dieser Hinsicht ganz klar Automatisierung.
Teil zwei des Tutorials hat deshalb eine Variante des Kubernetes-Deployments vorgestellt, bei der Ansible im Mittelpunkt steht. Welche Automatisierung zum Einsatz kommt, ist letztlich nicht von großer Bedeutung. Denn wichtige Fragen gibt es bereits zu klären, bevor diese überhaupt ins Spiel kommt.
Das beginnt schon bei der Installation: Muss ein Setup in kurzer Zeit massiv wachsen, wird der Anbieter genug damit zu tun haben, die Hardware ins Rack zu schrauben. Müsste er anschließend auf Dutzenden Rechnern händisch ein Betriebssystem installieren und konfigurieren, ginge dafür eine erhebliche Menge Zeit drauf. Große Setups wie Kubernetes-Cluster müssen mit der Automatisierung deshalb schon zuvor beginnen, etwa bei der automatischen Installation eines Betriebssystems.
Für künftige Kubernetes-Administratoren ergeben sich an dieser Stelle zwei Optionen. Wenn sie die Automatisierung für ihr Kubernetes selbst erstellen, können sie auch das automatische Deployment selber bauen. Gleich mehrere Lösungen, einen Rechner per PXE oder UEFI-Boot ein Installations-Image laden zu lassen und ihm danach ein Betriebssystem zu verpassen, haben sich erfolgreich am Markt etabliert.
Zusätzlich bieten die großen Linux-Distributoren Hilfe: Red Hat, SUSE und Canonical haben für Kubernetes eigene Versionen ihrer Distribution im Programm, die sich zusammen mit den dort etablierten Management-Werkzeugen nutzen lassen.
Kubernetes aus der Dose
Red Hat etwa bietet mit OpenShift Container eine Variante der eigenen OpenShift-Plattform an, die speziell auf Kubernetes ausgelegt ist. Kern ist die Distribution „Red Hat Enterprise Linux Atomic Host“, eine minimale Variante von Red Hat Enterprise Linux (RHEL), deren einzige Funktion das Starten von Containern ist. Alternativ dazu lässt sich Kubernetes auch auf einem normalen RHEL betreiben; das versetzt den Admin zudem in die Lage, die verschiedenen Automatisierungswerkzeuge von Red Hat wie Satellite für das gesamte Setup zu benutzen. Red Hat leistet offiziell seit RHEL 7.1 Support für Kubernetes.
SUSE rührt derzeit kräftig die Werbetrommel für seine Container-as-a-Service-Plattform (CaaS). Prinzipiell handelt es sich um ein ähnliches Produkt wie bei Red Hat: Auf Basis einer zusammengedampften SLES-Version, die SUSE „SLE MicroOS“ getauft hat, bietet die Plattform Kubernetes an. Der Hersteller kombiniert den Ansatz mit Werkzeugen wie Salt, um dem Admin in Sachen Automatisierung und Deployment das Gros der Arbeit abzunehmen (Abbildung 1).
Canonical ging letztes Jahr mit einer eigenen Kubernetes-Distribution an den Start, die in die Ubuntu-Tools für Systemverwaltung integriert ist. Wer diesen Weg geht, kann Kubernetes auf einem Ubuntu-Cluster betreiben, den er zuvor mit dem Dienst Metal as a Service (MaaS) und Landscape gebaut und konfiguriert hat. Wie die beiden anderen großen Hersteller hat Ubuntu mittlerweile ein Basis-Linux im Programm (Ubuntu Core), das anschließend auf den diversen Container-Hosts läuft und dort so wenig Wartungsaufwand wie möglich benötigen soll (Abbildung 2).
Vor- und Nachteile
Administratoren können somit zwischen drei kommerziellen Produkten wählen. Alle Hersteller haben allerdings ihre eigene Vorstellung davon, wie die Verwaltung von Hard- und Software funktioniert und welche Funktionen den Nutzern zur Verfügung stehen. Hinzu kommt die persönliche Erfahrung: Wer den Umgang mit Ubuntu, SLES oder RHEL gewohnt ist, wird vermutlich zur Lösung „seines“ Anbieters tendieren, wenn es um die Auswahl einer Kubernetes-Distribution geht. Zudem unterscheiden sich die drei Ansätze in Umfang und Qualität nicht maßgeblich voneinander.
Variante B ist der Eigenbau: Bare-Metal-Deployment samt automatisierter Installation von Kubernetes per Ansible. Das kostet mehr Zeit, am Ende ist der Mühe Lohn allerdings eine maßgeschneiderte Lösung für exakt die eigenen Ansprüche. Bei dieser Variante bietet natürlich kein Hersteller Support.