Kubernetes / Cloud Native erobert den IT-Betrieb Neue Aufgaben für die CNCF-Community

Anbieter zum Thema

DAXTEN GmbH

Zur CNCF/Kubernetes-Community gehören viele Tausend. Zur „KubeCon/CloudNativeCon“, deren europäische Ausgabe im April stattgefunden hat, finden sich zahlreiche neue Firmen ein und so einige vom Vorjahr auch nicht mehr. Rund 10.000 Besucher sind dieses Mal gekommen, hauptsächlich um sich auszutauschen. Die Themen: Security, KI, Massen an Daten, Echtzeitfähigkeit, Day-2-Operations, Plattform-Engineering, Nachhaltigkeit, Observability, FinOps und die Komplexität von Service-Meshes, Containern und Kubernetes.

Die Popularität von Cloud Native ist ungebrochen; waren es in Valencia, wo die Veranstaltung im vergangenen Jahr stattgefunden hat, rund 7.000 Besucher vor Ort, platzte sie mit mehr als 10.000 Besuchern aus allen Nähten – rund 58 Prozent haben die Veranstaltung das erste Mal besucht - weitere 2.000 schafften es nur auf die Warteliste, viele sind online dabei gewesen. Um den Vorträgen vor Ort zu folgen, haben Interessenten schnell sein müssen; denn einige sind schlichtweg überfüllt gewesen.

Der Veranstalter, die Cloud Native Computing Foundation (CNCF), zählt inzwischen 159 Projekte zu denen rund 1.300 so genannte Maintainer und rund 200.000 Contributors aus mehr als 180 Ländern gehören. Jüngste (Gold-)Mitglieder sind Hitachi sowie Ernst&Young. Der indische IT-Dienstleister HCLTech ist von Gold auf den Platin-Status aufgestiegen, Infosys direkt auf dieser höchsten Stufe eingestiegen. Die Liste der neuen Mitglieder mit Silber-Level umfasst mehr als 50 Firmen.

Zu den Projekten, die sich derzeit am schnellsten entwickeln, gehören Kubernets, OpenTelemetry, Argo und Backstage. Im so genannten Inkubator-Modus befinden sich „Backstage“, „CertManager“ (Trust Manager), Cilium - eBPF-basiertes Networking, Security und Observerstion-Projekt), „CloudCustodian“, „Cri-O“ – zum Beispiel für Open Telemetry Tracing, „Dapr“, eine portable, ereignisgesteuerte Laufzeitumgebung für die Entwicklung verteilter Anwendungen in der Cloud und im Edge-Bereich, „Dragonfly“, „Emissionary-Ingress“ (früher: Ambassador), „Falco“, „gRPC“, „In-Toto“ – ein Supply Chain Security Projekt, „Istio“, „Longhorn“ und „Nats“ https://nats.io/.

Der Film „Inside Envoy: the Proxy for the Future“

Die Cloud Native Computing Foundation hat bei Speakeasy Productions einen Dokumentarfilm über die Entstehung eines ihrer bedeutendsten Projekte erstellen lassen. Er ist für alle interessant, die sich dafür interessieren, wie es hinter den Kulissen der Open-Source-Foundation zugeht.

Envoy ist eine der wichtigsten Open-Source-Innovationen beim Übergang von monolithischen Architekturen zu Microservices, da sein hochleistungsfähiger Service-Proxy eine effiziente Kommunikation und Lastverteilung ermöglicht und dazu beiträgt, die Komplexität der Service-to-Service-Kommunikation zu reduzieren. Envoy wird inzwischen von Tausenden von Unternehmen genutzt und hat die Einführung von Microservices in der gesamten Branche beschleunigt.

Doch am Anfang stand ein Programmierfehler; Software-Ingenieur Matt Klein arbeitete einst für Twitter, bevor er 2015 zu Lyft wechselte. Ein kleiner Fehler im Softwarecode hatte zu einer falschen Datierung geführt, was Twitter letztlich Einkommenseinbußen bescherte und Klein seinen Job dort kostete. Heute sagt er: „In meinen kühnsten Träumen hätte ich mir nie vorstellen können, dass Envoy zu dem werden würde, was es heute ist.“

Zur Zeit seines Wechsels zu Lyft kämpfte das Unternehmen mit der Umstellung von einer monolithischen auf eine Microservice-Architektur, wie viele Unternehmen in Wachstumsphasen. Klein machte sich an die Arbeit und programmierte allein drei Monate lang an der ersten Version dessen, was später Envoy werden sollte. Ursprünglich als Edge-Proxy eingeführt, entwickelte sich Envoy so, dass es 100 Prozent des Lyft-Verkehrs abwickeln konnte.

Vom Ausgangsproblem zum Support bis zur Massenakzeptanz

Mitte 2016 wurde Envoy für die gesamte Netzwerkkommunikation bei Lyft verwendet. Envoy wurde im Herbst 2016 als Open-Source-Lösung veröffentlicht und fand schnell Anklang. Im Jahr 2017 trat Envoy der Cloud Native Computing Foundation (CNCF) bei. Heute bedient Envoy täglich Billionen von Anfragen und wurde von Tausenden von Unternehmen auf der ganzen Welt übernommen.

Im Envoy-Film kommen prominente Innovatoren, Führungskräfte und Ingenieure zu Wort, die die Geschichte der Entstehung und des Wachstums von Envoy zu der bahnbrechenden Technologie erzählen, die heute von Hunderttausenden von Entwicklern und Unternehmen auf der ganzen Welt geschätzt wird. Der Film ist die zweite große Veröffentlichung von Speakeasy Productions zu zentralen Open-Source-Softwareprojekten.

Der andere große Dokumentarfilm „Inside Prometheus: An Open Source System That Changed Technology“ zeigt die Entwicklung des Open-Source-Projekts „Prometheus“. Aus demselben Haus stammt auch eine zweiteilige Serie über die Entstehung und das Wachstum von „Kubernetes“.

Für viele erfreulich dürfte sein, dass die CNCF-Gemeinde ein Glossar für Fachvokabular und Abkürzungen verwaltet. Es ist derzeit in zehn Sprachen erhältlich, auch in Deutsch und in Bengali und Chinesisch.

<blockquote class="inf-blockquote">Ende September trifft sich die CNCF-Community in Shanghai. Die diesjährige Nordamerika-Konferenz findet Anfang November 2023 in Chicago statt und die nächste KubeCon/CloudNativeCon Europe soll vom 19. bis zum 22. März 2024 in Paris stattfinden.</blockquote>

Wie Bil Ren (siehe Abbildung 1) in seinem Keynote-Teil ausgeführt hat, ist ein Problem, mit dem sich auch die Cloud-Native-Gemeinde auseinander setzen muss, die Komplexität der Software. Rund 500.000.000 Software-Innovationen würde es laut Gartner-Analysten bis 2025 geben, rund 90 Prozent davon Cloud Native. Zugleich aber sind die meisten Anwendungen nicht Cloud-fähig, geschweige denn alle Branchen. Der Schlüssel der Transformation in die Digitalisierung sei sowohl Offenheit im Sinne von Open Source als auch eine höhere Produktivität.

Ohne auf die Huawei-spezifischen Ideen für ein Cloud-Native-Projekt eingehen zu wollen, lässt sich festhalten, dass viele der Sprecher es ähnlich sehen. Die Keynote, die hier heraussticht, ist die von Aparna Subramanian, Director of Production Engineering bei Shopify: „Is Kubernetes Delivering on its Promise? A Platform Engineering Perspective“.

Zum einen macht sie darauf aufmerksam, dass tatsächlich die Zahl der „End-Benutzer“, solche Unternehmen, die Kubernetes und Cloud Nativ nutzen, aber kein damit erstelltes Produkt verkaufen, wächst. Seit jeher umwirbt die Foundation solche Unternehmen stark und möchte viel mehr gewinnen. Damit aber müssen auch die Projekte den Bedürfnissen dieser Anwender stärker entsprechen. Day-2-Operations, Security, Produktivitätsgewinn, FinOps und Standardisierung rücken stärker in den Fokus.

Schon im vergangenen Jahr war der Begriff „Plattform Teams“ aufgetaucht, in diesem Jahr erweitert um „Plattform Engineers“. Ihre Arbeit soll dazu beitragen, dass Anwendungsteams von Arbeiten an den Grundlagen entlastet werden. Von dem Gedanken an DevOps, also das Verheiraten von Entwicklung und Operations, also Betrieb, soll jedoch nicht in einer Scheidung enden. Allerdings hat sich schon im vergangenen Jahr herauskristallisiert, dass die Entwickler, die auch mehr und mehr Operations-Aufgaben aufgebürdet bekommen haben, diese gar nicht wollten.

Jetzt sollen also kleine Teams aus Plattform-Schaffenden die Entlastung bringen und zugleich die Produktivität aller erhöhen. Das Problem: Keiner scheint genau definieren zu können, wie diese Plattform-Teams zusammengesetzt sein sollen, und welche Aufgaben sie übernehmen sollten. Es können Security-Grundlagen sein, bei Mercedes-Benz Tech Innovation, einer 100prozentigen Tochter des Mercedes-Benz-Konzerns, die in diesem Jahr den „End-User-Award“ der CNCF bekommen hat, geht es etwa um das Provisionieren von Cluster oder auch das Bereitstellen von Helm-Charts.

Was machen Plattform-Teams?

Auch Release-Engineers können Mitglieder eines Plattform-Teams sein; denn die Updates von K8 (Kubernetes) seien bis jetzt eine Qual gewesen. Sie spricht von „einfachen Bausteinen“ und vom Ziel die Komplexität in den Griff zu bekommen. Dann sind auch Themen denkbar wie das automatische Skalieren. Jedenfalls sind sich alle Befürworter von Plattform-Teams einig, dass sich mit ihrer Hilfe Time-to-Market verkürzt und sich die Produktivität aller erhöht.

Im „Podcast #11: Sebastian Kister, Audi, über Cloud-Native-Plattform-Teams in der Prinzregententorte“; erläutert der Leiter des Kubernetes-Kompetenzzentrums bei Audi, unter anderem, wie bei ihm die Plattform-Schaffenden aufgestellt sind.

Aber wie steht es nun mit dem `Versprechen´, Kubernetes sei eine skalierbare, infrastrukturunabhängige Container-Management-Plattform, die eine einfache Bereitstellung und Verwaltung von Containern überall ermöglicht?

Das Kubernetes-Versprechen auf dem Prüfstand

Nun von Beginn an hat Kubernetes ein gut strukturiertes Application Performance Interface (API) und eine wohl verstandene Erweiterbarkeit, einen Mechanismus, mit dem Nutzer modellieren können und eine Möglichkeit, alle Ressourcen innerhalb der Plattform einheitlich zu konfigurieren und einzusetzen. Das habe es Plattform-Teams ermöglicht, schneller zu arbeiten und die von den Geschäftsinteressenten geforderte schnelle Marktreife zu erreichen.

• Und auch im Nachhinein bekommt Kubernetes in puncto Portabilität von ihr fünf Sterne. „Kubernetes ist portabel und hat eine Ebene der Standardisierung über die Infrastruktur und mehrere Clouds hinweg geschaffen - und was noch wichtiger ist: Als Plattformteam sind unsere Fähigkeiten ebenfalls portabel“, sagt Subramanian.

• Ihr nächster Punkt ist die Bewertung der Zuverlässigkeit. Sie erläutert: „Die Plattformteams haben gelernt, alles als austauschbare Dinge zu behandeln, die kommen und gehen können. Wir betrachten Dinge nicht mehr als heilig und als etwas, das besonders geschützt werden muss, und das hat uns insgesamt geholfen zur Zuverlässigkeit der Plattform beizutragen.“

• Die Erweiterungsfähigkeit aber sei das Merkmal, was Kubernetes wirklich leistungsfähig mache. Denn damit sei Kubernetes viel mehr als ein Container-Orchestrierungssystem: „Durch die Nutzung der Ressourcen und Operatoren können wir jeden Aspekt der Skalierbarkeit unserer Infrastruktur modellieren und im Lebenszyklus verwalten“, hält Subramanian fest.

• Vielleicht ist überraschend, dass sie Kubernetes ausgerechnet bei der Skalierbarkeit nur drei Sterne zukommen lässt. Sie sagt: „Kubernetes ist gut skalierbar, aber Endbenutzer wie Shopify und andere Endbenutzer, mit denen ich spreche, sind wirklich an die Grenzen gestoßen, obwohl wir in der Lage waren, die meisten dieser Probleme zu umgehen, indem wir einfach mehr Cluster erstellt haben. Ich würde der Skalierbarkeit nur drei Sterne geben, weil wir die Messlatte für die Skalierbarkeit ständig höher legen.“

• Ihr letzter Punkt ist die Einfachheit. Kubernetes sei ein komplexes System und nicht eine Lösung, die out of the box für Anwendungsentwickler zu verwenden ist. Allerdings, so Subramanian, „ist es leistungsfähig und flexibel genug, um von Plattformteams genutzt zu werden.“ Hier störe die Komplexität nicht. Viele erfolgreiche Unternehmen hätten ihre gesamte Plattform auf dieser Technologie aufgebaut.

Datenmassen und zwar schnell

Klar, auch in der CNCF-Welt war man sich klar, dass es Künstliche Intelligenz und Machine Learning gibt, dass diese jede Ressourcen und Unmengen an Daten brauchen würden. Auch dass es Auswirkungen auf die Geschwindigkeit hat, wenn Maschinen miteinander kommunizieren war sicher irgendwie schon immer gesetzt.

Doch nun gibt es „ChatGPT“ und das rüttelt den ein oder anderen in der Community wach. 'Wir müssen etwas tun', verkündeten verschiedene Teilnehmer diverser Podiumsdiskussionen willig zuhörenden Journalisten. Viele konkreter wurde es nicht.

Man wies auf die Gefahren hin, sollten Programmierunkundige programmierender KI vertrauen, sowie auf rechtliche Probleme, etwa mit der Urheberschaft. Neu scheint auch ins kollektive Bewusstsein zu sickern, dass diese lernenden Modelle irre Mengen an Daten verköstigen und das schnell. „Echtzeit sind bei uns vier Sekunden“, sagt Audi-Mann Kister im „Datacenter-Diaries“-Podcast #11. https://player.captivate.fm/episode/7c984059-a340-4388-86fd-a5deb2e7bcc3/ Doch die Tendenz zu weiter fallenden Latenzen, die geduldet werden, ist steigend.

Ein Objektspeicher

Dafür, dass Daten – das Speichern, das Transportieren, das Sichern und der Zugang als das A und O angesehen werden, sind vergleichsweise wenige Datenbewahrer und -Organisierer auf dem Shopflor der Veranstaltung anzutreffen gewesen. Die Ausnahme: Minio, Anbieter eines leistungsstarken, S3-kompatiblen Objektspeichers. Dieser ist konzipiert für KI/ML, Data Lakes und Datenbank-Workloads im Exascale-Umfang.

Die Open-Source-Software unter GNU AGPL v3-Lizenz läuft vor Ort und in jeder Cloud (öffentlich oder privat) und vom Rechenzentrum bis zum Edge. Der Hersteller wirbt damit, dass „Minio“ zugleich der schnellste Objektspeicher mit veröffentlichten GETs/PUTs-Ergebnissen ist - von über 325 GiB/s und 165 GiB/s auf 32 Knoten mit NVMe-Laufwerken und einem 100Gbe-Netzwerk.

Erwachendes Umweltbewußtsein

Gleich zwei Keynote-Beitrage haben sich damit befasst , dass und wie mithilfe von Containern, Services, Cloud Native-Techniken insgesamt Energie zu sparen sei. AWS-Mann Nathan Taber, Head of Product for Kubernetes, äußert: „Nachhaltigkeit ist wichtig."

Sie sei eines der Leitlinien für die Investitionen in Open-Source-Projekte - „für die Ressourcen, die benötigt werden, um gesunden Code für gesunde Communities“ zu unterstützen. Nachhaltigkeit hat hier allerdings eher die Bedeutung eines langfristigen Engagements; so habe AWS erst kürzlich rund 10 Millionen Dollar in das Projekt „Open SSFF“ gesteckt.

Nachhaltigkeit im Sinne von umweltschonend/ressourcenschonend haben Red Hat und Microsoft auf's Trapez gebracht. Unter anderem geht es um die Implementierung von „Kepler“-Metriken in das Projekt „Keda“. Das Akronym steht für 'Kubernetes Event-Driven Autoscaling' und wird wird von beiden Firmen, aber auch Atos zum Beispiel unterstützt.

Kepler wiederum steht für 'Kubernetes efficient power level exporter' ist ein Werkzeug zur Erfassung von CPU-, GPU- und RAM-Metriken, die zum Beispiel mit „Prometheus“ verarbeitet werden können. Das Werkzeug liefert zudem Echtzeitmetriken für die CPU (über RAPL), die GPU (über NVML, die Nvidia Management Library) und andere Ressourcen und erstellt aggregierte Metriken, die mit „Kiali“ beziehungsweise „Jaeger“-Traces abgeglichen werden können, um Cloud-native Anwendungen im Hinblick auf Energie-Effizienz zu optimieren.

Red Hat hat zudem seine Runtime ausgetauscht; denn es hat sich erwiesen, dass „C run“ wesentlich effizienter ist als „run C“, die OCI-kompatible Runtime für Container.

WASM versus Kubernetes?

Ein Dementi zu „WebAssembly“ könne unter Umständen Kubernetes ersetzen, lässt aufhorchen. Es erinnert ein wenig an „Wo Rauch ist, ist auch Feuer“ oder „Keiner denkt an eine Steuererhöhung“, so dass jeder weiß, sie kommt nur noch nicht in welcher Höhe. So zitiert Engineering Manager Sean Isom von Adobe in eiem CNCF-Blog Solomon Hykes, den Erfinder von Docker mit: „Hätte es WASM+WASI im Jahr 2008 gegeben, hätten wir Docker nicht entwickeln müssen. So wichtig ist das. WebAssembly auf dem Server ist die Zukunft der Datenverarbeitung.“ In seinem Blog-Beitrag geht es um die Kombination von WASM und Kubernetes.

Das ist es auch, was die CNCF-Verantwortlichen propagieren: WASM ergänze Kubernetes. Doch Kubernetes sei nach wie vor die Lingua franka. Festzustehen scheint allerdings, dass ein großer Vorteil von WebAssembly im Backend ist, dass auf sichere Weise eine hohe Leistung und Effizienz ermöglicht wird. So geschieht das Aufsetzen eines Containers im Bereich von Nanosekunden. Da WASM mit Kubernetes kompatibel ist, sind die Investitionen in Kubernetes jedoch nicht verloren.

(ID:49432663)