Die neue IT-Welt: Flukturierende Services Container, Kubernetes und Persistent Storage

Anfangs wurde die x86-CPU nur zu zehn Prozent genutzt. Dann kam die virtuelle Maschine und trieb die Auslastung in bis dato unbekannte Dimensionen. Doch für die Scale-out Architektur der großen Webscaler wird die Parallelisierbarkeit von Anwendungen benötigt, die Google mit seinen Microservices in die Welt der Commodity-Prozessoren gebracht hat.

Anbieter zum Thema

Vogel IT-Medien GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Google Germany GmbH

Google Germany GmbH

„Es war einmal“, so könnte man nach nur sieben Jahrzehnten IT-Geschichte viele Kapitel beginnen. Es war einmal, als findige Köpfe wie die Ingenieurin Diane Green und ihr Ehemann, der Informatikprofessor Mendel Rosenblum, darauf kamen, die altgediente Virtualisierungstechnologie vom Mainframe abzulösen und anderen Server-Systemen zur Verfügung zu stellen.

Ihre Firma VMware ging schon bald an EMC und sorgte für eine „Disruption“ (sprich: Revolutionierung) hinsichtlich des Umgangs mit Anwendungen und Daten: In der Vergangenheit oft nur zum Teil und isoliert genutzt, ließen sich IT-Systeme nun in mehrere Untereinheiten oder „virtuelle Maschinen“ aufspalten und mit verschiedenen Applikationen belegen, was zur Auslastung der Kapazitäten bei gleichzeitiger Kosteneinsparung führte. Virtuelle Maschinen lassen sich überdies leicht verschieben, auch in die Cloud oder von Cloud zu Cloud.

Distributed Computing anstelle Mainframe

Diane Green leitet heute das Cloud-Business bei Google. Was man als Indiz dafür nehmen kann, dass die IT-Geschichte nicht bei der Virtualisierung stehengeblieben ist. Wie Arpana Sinha, Senior Product Manager for Kubernetes and Container Engine bei Google, auf der KubeCon-Konferenz in Berlin 2017 berichtete, konnte man sich für die eigenen globalen und sehr großen Rechenzentren keine teuren Mainframes leisten.

Google-Ingenieure setzten stattdessen auf das Abstraktionsprinzip und zerlegten – so Sinha – die Server in viele kleine Einheiten von „Distributed Computing“, um so unabhängig von der Hardware-Basis die Compute-Leistung klassischer Mainframes zu erreichen oder sogar zu übertrumpfen.

Google hat sich viele Jahre lang über die eigene Technologie ausgeschwiegen. Das hat sich inzwischen geändert. Im Jahr 2015 veröffentlichten Google-Mitarbeiter ein Papier mit dem Titel „Large-scale cluster management at Google with Borg“, und gleichzeitig übergab der Konzern eine abgespeckte Version von „Borg” unter der Bezeichnung„Kubernetes” an die Open-Source-Welt – beziehungsweise an die Linux Foundation und ihre Unterorganisation Cloud Native Computing Foundation (CNCF). Das Wort „Kubernetes” bezeichnet den Steuermann oder Kapitän eines Schiffes und bewegt sich damit in der maritimen Terminologie der Docker-Container (Docker = Hafenarbeiter).

Cloud Native Computing Foundation

Dickes Ding: Kubernetes 1.6 und vieles, vieles mehr

Von der KubeCon und CloudNativeCon EU 2018

Kubernetes auf dem Höhepunkt?

Die Besonderheit von Containern

Container als Behälter von Anwendungen und Daten gelten im Unterschied zu virtuellen Maschinen als einfach zu verwalten und unkompliziert einzurichten, da sie kein Betriebssystem mehr in sich aufnehmen, sondern sich wie eine Applikation oder ein isolierter Rechenprozess verhalten. Das gemeinsame Basis-Betriebssystem mehrerer Container ist Linux.

Solche „Behälter“ sind bei Entwicklern und in Dev/Ops-Umgebungen beliebt, werden aber auch zunehmend in der produktiven IT großer Unternehmen eingesetzt, wobei ehemals monolithische Anwendungen in so genannte Microservices aufgeteilt werden. Diese arbeiten jede für sich und können geändert werden, ohne dass dies Auswirkungen auf andere Teile einer Anwendung wie zum Beispiel einer Datenbank hat.

Anstelle von „tight coupling“ verschiedener Funktionen, das Risiken für neue Software-Releases darstellt und zu Verzögerungen bei der Veröffentlichung neuer Versionen führen kann, treten alternative Eigenschaften wie Agilität, Ausfallsicherheit und Automatisierung – das Stichwort lautet „loosely coupled“.

Treten zum Beispiel in diesem neuen Konzept Probleme bei einem Online-Banken-Service mit der Transferfunktion auf, können die Kunden immer noch ihr Konto überprüfen oder Rechnungen bezahlen, weil jedes dieser Features in einem eigenen Microservice inklusive einer separaten Datenbank verpackt ist. Bei einer monolithischen Oracle-Datenbank würde dagegen der Ausfall einer Funktion dazu führen, dass die Kunden auch andere Funktionen nicht mehr nutzen könnten, heißt es in dem Report „The Expert’s Guide to Running Containers in Production“ des Container-Spezialisten Portworx.

Kubernetes als zentrale Speicherschnittstelle

Die Ablösung von der Hardware-Basis stellt eine Container-Umgebung jedoch vor ein neues Problem: Management und Steuerung Hunderter oder Tausender von Anwendungs- und Datenbehältern müssen praktisch – und möglichst automatisch – bewältigt werden. Mit Kubernetes wurde ein Orchestrierungs-Tool für solche Umgebungen geschaffen.

Die unabhängige Container und Storage Interface Group (CSIG) befasst sich mit den Kontakten zu den Block- und File-Speicherherstellern, um die Volumes von Kubernetes mit deren Spezifikationen zu verbinden. Das schließt Tests der jeweiligen Codes sowie Open-Source-APIs der (proprietären) Storage-Produkte für den Release-Prozess von Kubernetes ein.

Da andere Kubernetes-Varianten wie Mesos, Docker oder Cloud Foundry mit der gleichen Thematik von Open Source versus Anbindung an kommerzielle Produkte zu tun haben, kam es hier zu einer engeren Zusammenarbeit und der Gründung einer gemeinsamen Arbeitsgruppe. Wie Saad Ali, Google-Ingenieur und Leiter der Kubernetes Storage Special Interest Group (SSIG), berichtet, waren die Hersteller an einem gemeinsamen Plug-in für sämtliche Kubernetes-Varianten interessiert. Es ist geplant, die CSIG später in die CNCF zu integrieren.

CNCF: Die organisatorische Heimat von Kubernetes

Eine Reihe von Kommités in der Open-Source-Community kümmert sich um solche Serverless-Systeme sowie um Networking und Storage, um eine gemeinsame Entwicklung und Reife der verschiedenen Ansätze zu erreichen. Die Ergebnisse werden dann einem gemeinsamen Gremium (TOC genannt) vorgelegt – eine Verfahrensweise, die die Verbreitung von Open-Source-Lösungen einschließlich Storage-Schnittstellen fördern soll.

Saad Ali gibt sich auf jeden Fall optimistisch. Alle Speicherhersteller können sich mit Code für ihre Schnittstellen beteiligen und manche – so Ali – schreiben sogar eigene Beiträge für den Kubernetes-Code. Allerdings haben sie kein Stimmrecht in der CNCF. Ali erläutert dazu: "Wir wollen Interessenskonflikte zwischen den diversen Speicherherstellern untereinander, aber auch mit der CNCF vermeiden."

Kubernetes übernimmt die Steuerung

Das hauptsächliche Problem, das es bei Containern zu lösen gilt, ist laut Ali "Persistent Storage". Container lassen sich sehr einfach erstellen, es besteht aber auch die permanente Gefahr, dass sie sich auflösen und ihr Inhalt damit verloren geht. Container sind laut Ali "leichter als virtuelle Maschinen gebaut". "Sie können sehr schnell gestartet und beendet werden. Werden sie beendet, verschwindet auch das Filesystem innerhalb des Containers.

Das Ende eines Containers wird von Kubernetes bestimmt: Ein Container enthält eine Applikation oder einen Microservice, und der Container soll über verschiedene Docker-Nodes verteilt werden, um den Datenverkehr in den Griff zu bekommen. Diese Verteilung kann man manuell steuern oder diese Aufgabe an Kubernetes übergeben.

Das Orchestrierungsinstrument übernimmt die Verteilung der Container und ihrer Replikas und stellt die notwendigen Ressourcen, zum Beispiel CPU und Memory, zur Verfügung. Das Monitoring dieser Prozesse erfolgt ebenfalls durch Kubernetes. Wird festgestellt, dass es an einem Node zu einem Ressourcenproblem kommt, kann das Tool den Container automatisch stoppen und an anderer Stelle wieder einen neuen eröffnen."

Container-Management

Kubernetes nimmt so automatisch zum Beispiel wegen eines Lastproblems mit Memory oder CPU einen Container von einer Maschine weg und startet ihn woanders neu. Für Ali besteht in dieser automatischen Funktion der Vorteil der Cluster-Steuerung durch Kubernetes, unabhängig davon, um welche Anwendung es sich handelt. Sie muss lediglich an einen Container angepasst sein.

Zur Lösung des Storage-Problems beim plötzlichen Ende eines Containers unterscheidet Kubernetes zwischen „ephemeral“ (flüchtigem) und „persistent“ (dauerhaftem) Storage. Ali erklärt: "Flüchtige Speicher haben die gleiche Lebensdauer wie ein Pod, eine Ansammlung von Containern. Mit Kubernetes ist der einzelne Container nicht die bestimmende Einheit, sondern es sind viele Container, die die Basis eines Prozesses bilden.

Kubernetes geht nicht von einem singulären Prozess für das Speichern aus, sondern von einer Mehrzahl von Containern in einem Pod. In einem Pod finden sich also entweder einer oder mehrere Container. Jeder Pod hat eine bestimmte Lebensdauer. Wird der Lifecycle eines Pods beendet, betrifft das alle Container in diesem Pod – sie werden an einen anderen Ort verlagert."

Ganzheitlicher Service

Um diese Prozesse zu verstehen, muss man sich laut Ali einen Rechner oder einen Node mit begrenzten Ressourcen vorstellen: „Man setzt dort zum Beispiel drei Pods ein und damit ist diese Maschine belegt. Alles wird zur Zufriedenheit ausgenutzt. Will der Administrator dort nun einen vierten Pod unterbringen und gibt ihm sogar eine höhere Priorität als den ersten drei, entscheidet Kubernetes: `Ich muss Platz dafür schaffen. Es wählt einen der drei ersten Pods aus und entfernt ihn. Das ist in der Tat etwas seltsam, gehört aber zu den Besonderheiten von Kubernetes.“

Ali fügt hinzu: „Wir sagen in solchen Fällen: Pet versus Cattle. In der Vergangenheit widmete man sich Applikationen wie seinen geliebten Haustieren (Pets), während man beim Vieh vielleicht 25 Kühe hat - wenn eine davon stirbt, wird sie ersetzt. Kühe haben Nummern, keine Namen.

Bei Kubernetes ist es das Gleiche: Wir kümmern uns weniger um die einzelnen Anwendungen - was dagegen zählt ist der ganzheitliche Service. Dieser besteht zum Beispiel aus drei Pods. Wenn ein Pod verschwindet, taucht er an anderer Stelle wieder auf: Der Kubernetes-Service kommt damit zurecht. Wichtig ist das gesamte Konzept, weniger bedeutsam ist, wo die einzelne Applikation läuft."

Daten sind immer zu sichern

Ein Container enthält aber immer einen Inhalt, den es auf jeden Fall – auch im Ableben des Cattle-Containers – zu sichern gilt. Hier kommt der "Persistent Storage" ins Spiel. Ali: „Der Inhalt muss irgendwohin in Sicherheit gebracht werden. File- und Block-Storage werden innerhalb des Containers gemountet, Beispiele sind NFS, iSCSI, GC Persistent Disk bei Google Cloud oder bei Amazon NBS Virtual Cloud. Solange Daten im Container geschrieben werden, ist dann dafür gesorgt, dass außerhalb eine Sicherheitskopie angelegt wird. "Stirbt" der Container, sind die Daten damit dauerhaft vorhanden. Storage ist auf diese Weise vom Computing entkoppelt. Wenn der Compute-Teil verschwindet, wird ein neuer Container erzeugt und die Daten werden wieder von außerhalb in ihn gemountet. Der neue Container kann dann dort weitermachen, wo der alte aufgehört hat.“

Diese Volume-Plugins bezeichnet der Google-Experte als eindeutigen Vorteil von Kubernetes. Die Anwender haben dabei die freie Wahl, eine der genannten externen Speichermethoden je nach ihren Präferenzen anzuwenden. Insgesamt habe man über 20 Speichersysteme für diesen Zweck in Kubernetes integriert.

Was früher manuell gemacht werden musste, ist in Kubernetes nun automatisiert, On-Premise und in der Cloud. Laut Ali muss der Pod zum Beispiel nur 50 Gigabyte an Storage verlangen und Kubernetes weist ihm dann je nach Speicherort eine entsprechende Technologie wie NFS oder andere zu.

Interesse an Container-Technik und Kubernetes wächst

Unternehmen, die sich für Container und Kubernetes entscheiden, profitieren davon, dass Google diese Technologien seit mehr als 15 Jahren bei sich einsetzt. Zwar hat das Unternehmen nicht alle Komponenten an die CNCF abgetreten, aber „Open Source“ bedeutet in diesem Fall, dass man nicht bei Null anfängt, sondern dass Google zumindest teilweise einige bewährte proprietäre Methoden herausgerückt hat – und dass sich eine größere Anzahl von Google-Fachleuten aktiv an den Arbeitsgruppen der CNCF beteiligt.

Dies spricht sich auch allmählich herum. So konnten die Veranstalter der letzten Veranstaltung CloudNativeCon + KubeCon in Kopenhagen mehr als die doppelte Besucherzahl gegenüber der Veranstaltung vor einem Jahr in Berlin verbuchen.

Fazit

Der Anspruch von Kubernetes (und Google) besteht nicht darin, die in Jahrzehnten gewachsenen Speichertechnologien überflüssig zu machen oder sie zu ersetzen, sondern sie den Anwendern in neuer vereinfachter Form zur Verfügung zu stellen. Das Gleiche gilt auch für die komplexe Verwaltung der Docker-Container, die sich rasch ausbreiteten, aber vielen Administratoren Probleme beim praktischen Einsatz bereiteten.

Google hat 2015 mit seinem Borg-Paper und der Freigabe von Borg-Komponenten auf diese Situation reagiert. Intern hat man mit Omega eine erweiterte Version von Borg geschaffen, extern hat Google damit für viel Aufmerksamkeit gesorgt.

Weitere Orchestrierungsansätze für Container gibt es mit Docker Swarm, Apache Mesos, Nomad, Rancher, Cloud Foundry (als Open Source und kommerzialisiert als Pivotal Container Services PKS), StorageOS sowie von Red Hat/CoreOS und Portworx. Und nicht zuletzt hat VMware auf die wachsende Konkurrenz von Containern und Kubernetes reagiert: Dort empfiehlt man den Kunden, Container in virtuelle Maschinen zu verpacken, um sie so besser voneinander zu isolieren.

(ID:45544307)