Für Journalisten hielt der zweite Tage der Kubecon + CloudNativeCon Europe 2020 neben weiteren Keynotes auch zwei Gesprächsrunden zu den Themen KI und Edge parat. Besonders Edge bereitet den Anbietern offenbar Kopfzerbrechen.
Erstmal zu den Neuigkeiten von der Kubecon, die Vicki Cheung in einem Keynote-Vidoe zum besten gab. Zunächst sprach sie über die Neuerungen von Kubernetes 1.18, das bereits im März erschien, warf aber auch einen Blick voraus auf die nächste Version 1.19, die dieser Tage erscheinen soll. Unter anderem wies Cheung auf den Support für generische flüchtige Volumes hin, der mehr Wahlfreiheit beite als “EmptyDir”. Nodes lassen sich debuggen, indem der Admin “kubectl” in den jeweiligen Namespaces der Nodes ausführt. Nicht zuletzt gibt es ersten Support für Cgroupsv2 in Kubernetes.
KI modular
Die naheliegende Frage zu KI lautete: Warum sollte man Dinge wie Deep Learning und Machine Learning auch noch mit der Komplexität von Cloud Native verheiraten? Darauf hatten die Vertreter von Red Hat, HPE, Rancher Labs, Microsoft und IBM unterschiedliche Antworten. Was alle sehen, ist die Möglichkeit, KI-Pipelines zu bauen, KI-Prozesse also in Komponenten bzw. Container zu zerlegen. Das ermögliche es zum Beispiel, über ein einfaches Ergänzen der Pipeline gezielt gegen die in vielen KI-Modellen vorhandene Voreingenommenheit anzusteuern. Ein bislang übrigens ungelöstes Problem. Skylar Thomas von HPE hielt vor allem die Idee von Modell-Containern für interessant, um KI-Modelle besser zu skalieren und auszutauschen.
Vicke Cheung warf einen Blick auf die kommende Version 1.19 von Kubernetes.
Microsofts David Aronchick stellt sich ein kontinuierliches Trainieren der Modelle in der Pipeline vor. Was zunächst wie ein feuchter Traum für Cloud-Anbieter wirkt, hat einen Hintergrund: Trainierte und ausgelieferte Modelle lassen sich gezielt verwirren, in der Computer Vision zum Beispiel durch bestimmte farbige Muster. Zwar lassen sich beim Training über das so genannte Adversarial Machine Learning im Vorfeld solche Störmuster entdecken, läuft die KI aber erstmal in einem Edge-Szenario, könnten Angreifer neue Muster finden, auf die die KI nicht vorbereitet ist. Das weiß auch Aronick von Microsoft und schlägt daher die kontinuierlichen Trainings-Pipelines vor, um jederzeit auf Angriffe gegen die KI im Edge-Bereich zu reagieren. Das macht auch klar: Edge-Szenarien mit KI-Einsatz, aber ohne Internetanbindung, sind so schwierig umzusetzen.
Not yet living on the Edge
Apropos Edge: “Its a mess.” Dieser Satz jedenfalls fiel in der Gesprächsrunde und alle Beteiligten nickten mehr oder weniger deutlich dazu. Das beginnt bei der Begriffsklärung. Noch immer reden selbst Experten oft über verschiedene Dinge, wenn von Edge die Rede ist. Für Shannon Williams von Rancher ist Edge zum Beispiel alles an Compute-Ressourcen was sich außerhalb des Rechenzentrums befindet. Dem würde ein Telekommunikations-Vertreter sicherlich so nicht zustimmen. Klar ist aber, dass die Vielfalt von Edge den daran arbeitenden Unternehmen, aber auch ihren Kunden, zu schaffen macht. Sehr viele Endpoints, alle mit unterschiedlichen Betriebssystemen und Hardwareausstattung – die Komplexität sei enorm.
An sich wollen Kunden Kubernetes im Edge-Bereich. Williams erzählt von einem Windkraft-Anbieter. Der wollte zunächst ein lokales Datacenter für den Park betreiben, etwas später bereits Kubernetes auf jeder einzelnen Turbine installieren. Mitunter kommt aber selbst das von Rancher angebotene K3S an seine Grenzen, denn es braucht als Host immer noch einen schlanken, aber voll ausgestatteten Rechner. Die kommen aber nicht in allen Edge-Szenarien zum Einsatz, was die Frage aufwirft, ob sich Kubernetes noch mehr entkernen ließe.
Zugleich möchten die Kunden aber alle Vorteile von Kubernetes, möchten Gitops, Automatisierung und so weiter. Eine Folge der Komplexität ist, dass die Kunden aktuell warten. Der große Durchbruch von Kubernetes im Edge-Bereich, das klang durch, dürfte also noch ein paar Jahre auf sich warten lassen. Etwa im Auto: Dort hält Karthik Gaekwad von Verica die Security noch für eines der ungelösten Probleme. In einem Auto sollen zum Beispiel nicht alle Pods miteinander reden dürfen. Mehrere Cluster pro Wagen sind für ihn eine mögliche Lösung.
Ob es überhaupt Sinn ergibt, Container und Kubernetes im Edge-Bereich einzusetzen? Die Teilnehmer sagen ja. Shannon Williams betont, dass Kubernetes einfach einen gemeinsamen Standard im Edge-Bereich schaffe, ein “Shared OS”, wenn man so will. Brent Schroeder von Suse wiederum betont die Dynamik von Kubernetes: Der Betrieb von Containern ermögliche den Edge-Unternehmen schnelle Update-Zyklen, was andere Modelle nicht bieten.
Cloud-Native-Transformation
Cloud Native ist komplex und das nicht nur im Edge Bereich, sondern auch im Rechenzentrum. Wie lässt sich zum Beispiel ein Wechsel von monolithischen Architekturen auf Cloud Native aus Entwicklersicht einführen. Darüber sprachen wir am Rande der Kubecon mit Michael Friedrich von Gitlab. Er ist Developer Evangelist und weiß, dass bei der Umstellung auf Microservices die Komplexität errückend werden kann. Eine Lösung: ganz kleine Schritte. Generell sieht er zwei mögliche Lösungswege. Der erste: Ein Cloud-Team, auch Lighthouse genannt, testet die neue Technologie, evaluiert und bringt unter Umstände andere Teams dazu, diese zu übernehmen, wenn sie sich als praktisch erweisen. Auch dabei gilt, die Entwickler und Admins nicht zu überfordern und klein anzufangen. Sie sollten sich anfangs zum Beispiel mit Containern beschäftigen, erst später dann mit CI/CD. Alles in kleinen Schritten.
Ein zweiter Weg wäre, Cloud Native in der Firma komplett auszurollen, auch dabei sind kleine Schritte wichtig. So ein Umbruch sollte niemanden überfordern. Die Firma kann Schulungen für Docker anbieten und nicht jeder Monolith lässt sich zwingend in einen Microservice verwandeln. Mitunter genügt es, ein anderen Weg zu wählen und den Dienst in eine VM zu verpacken. Mitunter hilft es auch, Entwicklern die Vorteile von Cloud Native vor Augen zu führen: Wenn nachts ein paar Container sterben, muss der Admin nicht mehr unbedingt aufstehen, weil Kubernetes neue startet. Dank der Isolierung und Zerlegung in Komponenten lassen sich zudem Fehler frühzeitig entdecken. Das entspanne auch den Release-Druck und die nach einem Release meist sehr bald folgende Jagd auf Bugs.
