Kubernetes von Google als IT-Infrastruktur-Dirigent

In der hin und her tobenden Debatte, ob es in der IT sinnvoller ist, alles im eigenen Haus zu erledigen oder das bestehende Rechenzentrum komplett oder teilweise auszulagern, wird gern übersehen, dass gerade ganz grosse Konzerne ausgesprochen erfolgreich eine selbst definierte Mischung fahren. Und dass heute von dort aus viele Vorbilder entstehen und Initiativen starten. Nicht nur die grossen Autokonzerne sind bei fast jeder neuen Technologie mit dabei und testen fortlaufend die ganze Palette von On-Premise bis extern, auch IT-Giganten wie Facebook, Netflix oder Google betreiben ihre IT nur noch zum Teil in den traditionellen Formen: Sie bauen sich eigene, günstige, per Software skalierbare Server-Farmen, geben manches an Provider wie Amazon AWS ab und zeigen sich grundsätzlich empfänglich für Entwicklungskonzepte wie Open Source und DevOps. Auch das noch vor Jahren eher verpönte Betriebssystem Linux gehört inzwischen für manche Aufgaben und Anwendungen zur Alltagsausrüstung gestandener Unternehmen – und ist in der Open-Source-Welt sogar so etwas wie ein Standard. Eine überraschend grosse Rolle in der Open-Source-Bewegung spielt ein Konzern, der in der Öffentlichkeit eher das Image eines gierigen Monopolisten hat: Google. Das jedenfalls stellt Aparna Sinha, Produktmanagerin bei Google in Kalifornien, im Gespräch mit Computerworld heraus.

Google habe sich zwar, so Aparna Sinha, eine umfassende, nicht standardisierte verteilte Umgebung aufgebaut, um mit den riesigen Datenmengen und der stetig wachsenden Zahl an Such­an­fragen zurechtzukommen. Das aber sei nicht damit gleichzusetzen, dass Google sich von der übrigen IT-Welt abgewendet hätte. Im Gegenteil. Google arbeite aktiv in vielen freien Communities und Entwicklungsgremien mit, stifte immer wieder intern erstellte Programme und Produkte oder verzichte auf Gebühren. Beispiele dafür seien etwa das Betriebssystem Android, das Portal Blogger.com, der Browser Chrome oder der E-Mail-Dienst Gmail. Für die Entwicklung neuartiger IT-Techniken und die Rolle der Open-Source-Bewegung dabei beinahe noch wichtiger ist ein Faktor, der von der europäischen Warte aus oft nicht so sichtbar ist: Neben dem regen Gedankenaustausch über die Communities der diversen Produkte und Projekte bieten zahllose Konferenzen – davon etliche an der Westküste der USA – mit ihren Vorträgen und dem inoffiziellen Networking ein höchst befruchtendes Podium für die laufenden Debatten. Dort finden sich die Experten der grossen Hersteller und der renommiertesten Universitäten, aber auch die grossen Stars aus dem Silicon Valley. Man werfe nur einen Blick auf die meist frei verfüg­baren Vorträge von Konferenzen wie FAST ’17 (Storage), Usenix (Security und andere Themen) oder VLDB (Very Large Data Bases). Oft haben sie Teams aus diversen Bereichen unterschiedlicher Hersteller oder Hochschulen verfasst. Mittendrin statt nur dabei sind oft die Leute von Google. Im Rahmen der zur Linux Foundation gehörenden CloudNativeCon kündigte Aparna Sinha zum Beispiel auf einer Konferenz in Berlin Ende März dieses Jahres Version 1.6 von Kubernetes an, einem Orchestrierungs-Tool für Container, das Google dieser Open-Source-Community 2014 übergeben hatte. Sinha wies in ihrem Vortrag ausdrücklich darauf hin, dass an diesem Projekt mittlerweile eine grosse Zahl von Mitarbeitern verschiedenster Unternehmen mitwirken, keineswegs nur solche von Google oder dem Linux-Distributor Red Hat. Letzterer führt seine auch ökonomisch wachsende Bedeutung nicht nur auf seine Rolle als Player bei traditionellen Unternehmen zurück, sondern auch und gerade auf seinen Beitrag zur Open-Source-Welt, seine Events und seine vielen Produkte. Nächste Seite: Kubernetes orchestriert Container

Google setzt intern auf Microservices, die sich darauf konzentrieren, kleine Aufgaben zu lösen, sowie auf schlanke Container, die im Unterschied zu virtuellen Maschinen kein eigenes Betriebssystem brauchen und sich leicht ausrollen lassen. Container gelten als die geeignete Form für rasch skalierbare «Next Generation»-Applikationen. Aparna Sinha zufolge kennzeichnet die IT-Infrastruktur von Google eine Kombination von Linux, Microservices, Containern und der Orchestrierung dieser Container mit Kubernetes.  Googles Verhältnis zu Kubernetes skizziert sie so: «Beim Kubernetes-Projekt geht es in erster Linie darum, für den Rest der Welt eine Umgebung zu schaffen, in der Applikationen in einer verteilten Umgebung laufen können. Wir haben bei Google festgestellt, dass wir das nicht allein umsetzen können. Am Anfang waren es nur zwei Institutionen, die sich darum gekümmert haben – Google und Red Hat. Das hat sich geändert. Es gibt nun viele Leute aus vielen Firmen sowie Einzelpersonen, die hier mitarbeiten. Ihre unterschiedlichen Erfahrungen und Ansprüche gehen in das Projekt ein.» Nur mit solch einem Background könne ein Projekt dieser Art zu einem Erfolg werden. Und erfolgreich ist Kubernetes ohne Zweifel. Nach etwas mehr als zwei Jahren Projektlaufzeit gibt es bereits 35 kommerzielle Versionen, die auf der gemeinsamen Arbeit aufbauen, darunter eine von VMware. «Diese Bandbreite spricht klar für den Erfolg von Kubernetes», sagt die Google-Managerin. Besonders viel beigetragen hätten Red Hat und seine Container-Plattform OpenShift.

Als herausstechendes Merkmal der aktuellen Kubernetes-Version 1.6 nennt Sinha Multi-Workload- und Multi-Team-Fähigkeit grosser Cluster. Dazu erklärt sie: «Grosse Cluster sind sehr populär und werden von Hunderten von Unternehmen eingesetzt. Eine wichtige Rolle spielen dabei diese neuen Features: rollenbasierte Zugangskontrolle und dynamisches Storage-Provisioning. Mit RBAC (Role Based Access Control) führen wir Autorisierung auf dem Cluster-Niveau ein, das heisst, wir decken die ge­samte Bandbreite von einzelnen Usern bis zu Multi-User-Clustern ab.» Die zweite wichtige Neuerung betrifft laut Sinha den Storage-Bereich: «Storage-Klassen und die VPods, die mit ihnen assoziiert sind, unterstützen stabile Container-Umgebungen. Dynamisches Storage-Provisioning ist eine elementare Funktion für Container und Kubernetes. Da Container immer ihren Geist aufgeben können, braucht es ein automatisches Storage-Provisioning, um genug Speicherkapazität zu haben. Mit PVclaim (Persistent Volume claim) haben wir nun genügend Kapazität pro Speicherklasse (SSD, Festplatte und so weiter) zur Verfügung.» Kubernetes ist in seiner gegenwärtigen Form eine Community, die sich auf der Basis des ursprünglich von Google gelieferten Know-hows um das Container-Management kümmert. Nicht zuletzt geht es dabei um das Management von 5000 oder mehr Node Clusters, das kontrollierte Abarbeiten von Computing- und Speicher-Prozessen (Scheduling) und besonders um Stabilität: Allein für Version 1.6 von Kubernetes wurden über 30 Features in dieser Richtung überarbeitet. Neue Funktionen werden sich in Zukunft auch des Themas Machine Learning annehmen. Nächste Seite: Security für Container

Mit zwei Demos untermauerte Sinha auf der Berliner Kon­ferenz die Intentionen von Kubernetes 1.6. Gegenüber Computerworld erläutert sie die unterschiedliche Ausrichtung der beiden Vorführungen: «Die erste Demo sollte zeigen, wie durch rollenbasierte Zugriffskontrolle bestimmte User in die Lage versetzt werden, bestimmte Dinge zu tun, während andere User andere Dinge tun dürfen, ohne dass Konflikte auftreten. Insofern haben wir eine klassische Funktionalität der IT eingeführt, auf einem sehr granularen, detaillierten Niveau. Dieser Security-Mechanismus stellt für sich genommen sicher nichts Revolutionäres dar, erleichtert aber den täglichen Umgang mit der neuen Technologie von Containern.» Die zweite Demo stellte Neuerungen rund um Dynamic Storage Provisioning vor: «In Containern ist es nicht einfach, einen bestimmten Status zu erhalten», so Sinha. «Wenn man zum Beispiel Daten schreiben will, und man hat aufgrund einer Änderung in der Applikation neue Informationen, dann muss man diese natürlich speichern. Aber ein Container kann immer plötzlich seinen Dienst versagen und ein anderer tritt an seine Stelle. Das bedeutet, man kann Informationen verlieren. Deshalb ist es so wichtig, einen Mechanismus zu entwickeln, der Storage mit Containern verbindet. Dieser Mechanismus wird in Kubernetes Volumes genannt. Wir haben viele Sub-Volumes, weil es viele verschiedene Formen von Storage gibt. Früher ist man davon ausgegangen, man hat beides nebeneinander – einen Computer, zum Beispiel einen Mainframe, und daneben ein Speichersystem. Dann wurde Virtualisierung eingeführt und der Computer oder der Mikroprozessor wurde in verschiedene Bereiche aufgeteilt, aber es gab daneben immer noch die Festplatte. Die virtuellen Maschinen (VMs) wurden Teil des Speichers. Jetzt gehen wir noch weiter und unterteilen sogar die VMs in Container. Und das heisst, man braucht etwas, um die Daten zu speichern, wenn ein einzelner Container seinen Dienst versagt, und um dann den Inhalt beziehungsweise die Daten zu finden und in einen neuen Container zu packen.» Auf den Einwurf, dies sei ein grosser Nachteil von Containern gegenüber virtuellen Maschinen, antwortet Sinha knapp: «Korrekt» – um hinzuzufügen: «Das ist auch der Grund, warum man keine Applikationen mit langer Lebensdauer (stateful) in Container packt.» Meist lege man nur kurzlebige (stateless) Anwendungen in Containern ab. Container können nicht die gleiche Rolle spielen wie Silo-Architekturen, dedizierte Server oder virtuelle Maschinen. Mit Dynamic Storage Provisioning ist man bei der Verbesserung der Technologie aber ein Stück vorangekommen. Sinha: «Mit Dynamic Storage Provisioning sorgen wir dafür, dass die Inhalte oder Daten von Containern nicht verloren gehen. Mit meiner Demo habe ich gezeigt, dass man den Inhalt eines Containers in einer laufenden Kopie (Claim) erfassen kann. Beim Ausfall eines Containers lässt sich dann sein Inhalt (Volume) in einen anderen Container verschieben und die Arbeit kann automatisch fortgesetzt werden. Der Nutzer braucht hier nicht einzugreifen.» Sinha betont, dass man mit der Dynamic-Storage-Provisioning-Technologie bereits einen Schwachpunkt des Container-Einsatzes neutralisieren könne. An weiteren Verbesserungen werde in der Forschungsabteilung von Google gearbeitet. Nächste Seite: Container vs. Virtualisierung

Wie es überhaupt zu dieser Entwicklung gekommen ist, beschreibt Sinha so: «Die Geschichte von Kubernetes geht zurück auf eine Situation bei Google vor etwa 12 Jahren, als wir mit einem System zu arbeiten begannen, das «Container» genannt wurde. Es ist wichtig zu verstehen, dass wir im Unterschied zu Virtualisierung, bei der der Mikroprozessor in mehrere Teile aufgebrochen wird, bei Containern so vorgehen, dass wir das Betriebssystem in viele kleine Teile aufbrechen. Wir schaffen so ein Multiplexing zwischen kleineren Prozessen, die das Betriebssystem anstösst. Das ist effizienter, als den Mikroprozessor aufzuteilen, weil man dort jeder virtuellen Maschine ein eigenes Betriebssystem mitgeben muss. Bei Containern braucht man nur ein Betriebssystem, und man braucht jeder Applikation nur eine dünne spezifische Schicht an Betriebssystemfunktionen mitzugeben. Jeder Container ist kompakter, startet schneller und ist leichter zu verschieben. Und man kann mehr von ihnen installieren, die dann zusammenarbeiten. All das erhöht die Effizienz und spart Zeit.» Diese Entwicklung hatte auch für Google selbst Folgen: «Google als Search-Company kämpft seit Beginn an mit dem Problem, dass man nicht weiss, wann der Traffic plötzlich ansteigt oder gar explodiert. Und Google operiert auf dem ganzen Globus. Wir hätten einen oder mehrere Mainframes in­stallieren müssen, um im globalen Ausmass skalieren zu können – aber das war zu teuer. Wir haben deshalb auf kostengünstige Computer gesetzt, die aber nicht besonders zuverlässig sind – sie können jeden Moment ausfallen. Also haben wir intensiv an verteilten Systemen gearbeitet, um diese Nachteile zu kompensieren. Eigentlich war schon der Mainframe ein Distributed System, das man in alle Richtungen aufspalten kann und das Parallel Processing oder Virtualisierung kennt. Um mit vielen günstigen Computern an dieses Ideal heranzukommen, war sehr viel Entwicklungsarbeit erforderlich. Man musste gegen Ausfälle oder Latenzen ankämpfen und neue Methoden des Rebootings erfinden. In den Jahren 2004 und 2005 wurde die Basis für diese Entwicklungen gelegt.» Google setzte auf Linux und war eines der Unternehmen, die dieses Betriebssystem in Container und einzelne Jobs aufteilten. Man hat das aber nie kommerzialisiert, sondern es Firmen wie Docker und anderen überlassen, daraus ein Geschäft zu machen. Sinha abschliessend: «Container und Kubernetes, eigentlich das Betriebssystem von Containern, sind wie der Mainframe. Sie sind nur nicht an einem Platz, sondern überall.» Zum Verhältnis von proprietär und offen: Google hat nach der Übergabe seiner Kubernetes-Entwicklung an die CloudNativeCon-Community eine eigene Orchestrierungs-Software für Container in Betrieb genommen. Irgendwo ist eben Schluss mit «open».