© Valentyn Volkov, 123RF
Neben einer Rekordzahl von Keynotes und Besuchern stand bei der Cloud Native Con und Kubecon Europe 2017 unter anderem die Containerverwaltung Kubernetes im Mittelpunkt. Deren Macher kündigten auf der gut besuchten Veranstaltung in der Nähe des Berliner Alexanderplatzes die neue Version 1.6 an.
Die 1500 Konferenzbesucher, die sich Ende März auf der Cloud Native Con und Kubecon Europe 2017 [1] drängelten, ließen das Berlin Congress Center aus allen Nähten platzen. Mit dem Ansturm hatten die Veranstalter von der Cloud Native Computing Foundation (CNCF, [2]) nicht gerechnet. Die Planung für Konferenzen beginne meist recht früh, und zu der vorherigen Konferenz in einem Hotel in Seattle sei noch eine überschaubare Menge an Menschen gekommen.
Rapider Zuwachs
Eine Ursache für den rapiden Besucherzuwachs dürfte sicherlich auch der Zuwachs an Projekten und Mitgliedern sein, die der CNCF in den zwei Jahren seit ihrer Gründung beitraten. Die Zahl schlug sich auch in den Keynotes nieder, von denen sich mehr als 20 auf drei Tage verteilten. Die erste offizielle hielt CNCF-Chef Dan Kohn (Abbildung 1). Als neues Platinum-Mitglied begrüßte er Dell/EMC an Bord der CNCF, auch Hangzhou Harmony-Cloud Technology LTD, Qaware, Solinea, Suse (Gold Member) sowie Tenx-Cloud traten der Foundation bei.
Abbildung 1: Der Chef der CNCF, Dan Kohn, freute sich über die zahlreichen Mitglieder und Projekte unter dem Dach der noch jungen Foundation.
Auch auf der Projektseite wuchs die CNCF im Laufe der Konferenz: Docker und Core OS übergaben der Foundation gemeinsam die Docker-Runtime Containerd und die Container-Engine Rkt. Die Docker-Runtime soll in Zukunft besser mit Kubernetes zusammenspielen, und laut Core-OS-CTO Brandon Philips will auch die Rkt-Engine die Interoperabilität mit der OCI (Open Container Initiative) und Kubernetes ausbauen.
Überhaupt Kubernetes
Die Containerplattform war der eigentliche Star der Veranstaltung [3], ihre Version 1.6 erschien in der Nacht auf den ersten offiziellen Konferenztag. Erstmals übernahm nicht Google, sondern Core OS die Release, aber Aparna Sinha von Google stellte die neue Version vor.
Kubernetes 1.6 erleichtert demnach die Arbeit in Teams und mit verschiedenen Workloads. Controlled Scheduling bestimmt, welche Pods mit welchen Nodes kooperieren. So legen die Macher etwa fest, dass bestimmte Pods nur auf schnellem Speicher laufen (SSDs) oder bestimmte Nodes nur diese und jene Workloads abarbeiten. Dies sei laut Sinha wichtig für Multicluster-Setups, der Code stamme unter anderem von Red Hat, IBM, Huawai und Google selbst.
Die neu eingeführte Role Based Access Control erlaubt es, bestimmte Dienste Teams zuzuordnen. Das demonstrierte die leitende Produktmanagerin von Kubernetes live vor Ort. Team Blau sieht dann nur die für es selbst bestimmten Dienste und Pods, Team Green die für dies bestimmten. Sinha zeigte zudem, wie Admins Speicher dynamisch oder manuell über Yaml-Files allozieren. Dabei genügt es, wenn der Admin die gewünschte Menge an Speicher angibt, Kubernetes kümmert sich um den Rest.
Pods im Spiel
Wer sich nun fragt, wer so ein Containermanagement-System eigentlich braucht (Stichwort: Overkill), dem brachte ein Talk der Deep-Learning-Forscher Vicki Cheung und Jonas Schneider des Open-AI-Projekts Erleuchtung – sie bringen ihren KI-Agents das Computerspielen bei [4]. Die Infrastruktur für die zahlreichen Spielumgebungen, in denen die KI-Agents agieren, stellt dabei ein kleines Team mit Hilfe von Kubernetes bereit.
Im Projekt treten oft schwer vorhersagbare Lastspitzen auf, die abzufedern ein Autoscaler hilft. Zusätzliche Workloads lagert das Team notfalls über ein Provisioning-API in die Cloud aus, die Zonen skalieren sie dynamisch je nach Anforderung. Ihnen gefalle vor allem das konsistente Benutzerinterface, das sich auch in die Cloud erstrecke, zudem zeigten sie sich vom Kube-API angetan.
Imageprobleme
Vor Ort fragte das Linux-Magazin unter anderem nach Security-Problemen im Containerbereich. In Registries wie dem Docker Hub oder Quay (dem Pendant von Core OS) veralten Images schnell und weisen ohne Rebuilds bald Sicherheitslücken auf. Dennoch erneuern viele Anbieter ihre Images nicht, wie das vorige Linux-Magazin zeigte.
Rkt-Entwickler Core OS kennt das Problem, es hat laut CTO Brandon Philips zwei Seiten. Einerseits gehe es darum, die Sicherheitslücken in den Images zu finden, andererseits müsse jemand den Admins sagen, dass die Images unsicher sind und neue Builds brauchen.
Wie das Docker Hub bietet auch Core OS mit Clair einen Imagescanner an, der CVE-Datenbanken von Distributionen anzapft und die gescannten Images mit deren Sammlung an Sicherheitslücken abgleicht. Eine Integration in Kubernetes sei geplant, könne aber noch etwas dauern. Zudem arbeite man an einem Channel-Konzept für Quay, das automatische Updates einschließt.
Auch Clayton Coleman, Open-Shift-Architekt bei Red Hat, sieht unsichere Containerimages als Problem. Man wisse nicht wirklich, wer die einzelnen Images wie gut betreue, selbst wenn sie aus dem Upstream stammen. Scanner helfen, aber Admins müssten sich die Problematik bewusst machen. Red Hat deaktiviere daher für einige Kunden den Zugriff auf die offiziellen Image-Repositories und baue eigene Images für Open Shift, die Sicherheitschecks durchlaufen.
Bauen statt updaten
Container verändern auch die Updateprozeduren und machen Aktualisierungen rechenaufwändiger. Das sieht auch Coleman so. Sicherlich sei der Aufwand, bei Sicherheitslücken und Fixes stets neue Images herunterzuladen, höher, als einfach über den Paketmanager Pakete zu aktualisieren. Allerdings betonte Coleman auch die Vorteile. So seien Rollbacks deutlich einfacher möglich, während Downgrades in VMs nicht immer zuverlässig funktionieren. Konfigurationen lassen sich zentralisieren, die gesamte Infrastruktur besser in Schuss halten, etwa mit automatisierten Builds.
In eine ähnliche Kerbe haute auch Lutz Lange, der als Solutions Architekt für Red Hat arbeitet. Wer viele verschiedene Workloads in Containern betreibe, für den seien Upgrades sicherlich aufwändiger, weil er viele Layer aktualisieren müsste. Häufig würden aber eher homogene Anwendungen zum Einsatz kommen. Der Mehraufwand an Rechenzeit lohne sich vor allem bei breit skalierten Anwendungen und wenn Unternehmen recht umfangreiche Aufgaben in Container verlagern.
Einige Unternehmen würden zwar gern Container nutzen – allerdings auch für alte Anwendungen. Nicht alle Legacy-Programme würden in der Cloud problemlos laufen, erklärt Lange. Relationale Datenbanken eignen sich etwa wesentlich schlechter als ihre No-SQL-Pendants für eine Containerisierung. Gerade bei komplexeren Applikationen würde er Firmen eher raten, die Finger von Containern zu lassen.
Der morgendliche Keynote-Redner am dritten Tag erinnerte schließlich daran, dass Lösungen wie Kubernetes nicht automatisch Sinn ergeben, schon gar nicht in der Federation. Wer nur zwei Instanzen betreibe, brauche keine Federation, machte Kelsey Hightower deutlich, der an Googles Cloud Platform arbeitet. Er zeigte in Form einer Demo, in welchem Kontext eine solche globale Verteilung von Anwendungen Sinn ergibt.
Joe Beda von Heptio warnte davor, Kubernetes mit immer neuen Features zu überladen. Kubernetes sei vor allem eine “System Software for System Engineers”, man müsse jedoch auch an einfache Clusternutzer denken, die nur ihre App im Blick haben. Jedes neue Konzept erhöhe auch die Komplexität von Kubernetes und schrecke neue User ab. Die Plattform müsse sich im Idealfall auch für jene Admins eignen, die keine “Systemnerds” sind.
