Mit über 90.000 Contributors und rund 4,4 Millionen Contributions ist Kubernetes nach Linux das zweitgrößte Open-Source-Projekt weltweit. Hierzulande stuft mittlerweile auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) Kubernetes als De-facto-Standard für Container-Orchestrierung ein. Doch wie funktioniert ein Projekt dieser Größenordnung eigentlich von innen? Im Rahmen des Cloud-Native-Festivals CloudLand 2025 hat Mario Fahlandt, der im Kubernetes-Projekt unter anderem in den Special Interest Groups (SIG) Contributor Experience und K8s Infra aktiv ist, einen detaillierten Einblick in die Strukturen, Einstiegsmöglichkeiten und Karrierepfade der Kubernetes-Community gegeben.

Fahlandt, der selbst als Host für die EMEA/APAC-Region bei der Kubernetes New Contributor Orientation (NCO) fungiert, machte in seinem Vortrag deutlich: Beiträge zum Projekt beschränken sich keineswegs auf Code. Meeting-Notizen anfertigen, Fragen im Slack-Channel beantworten, Dokumentationen korrigieren oder Blog-Posts verfassen – all das zählt als Contribution.

Drei Kategorien von Special Interest Groups

Die Community organisiert sich unter dem Dach der Cloud Native Computing Foundation (CNCF) in einer ausdifferenzierten Struktur. An der Spitze steht ein Steering Committee mit sieben gewählten Mitgliedern. Die eigentliche Arbeit findet in 24 Special Interest Groups (SIGs) statt, die sich in drei Kategorien gliedern: Project-SIGs wie Architecture, Docs oder Release unterstützen das Gesamtprojekt organisatorisch. Horizontal-SIGs – darunter API-Machinery, Auth oder Scalability – kümmern sich um querschnittliche Kernfunktionalität. Vertical-SIGs wie Network, Storage oder Node verantworten jeweils spezifische technische Komponenten. Ergänzt wird diese Struktur durch sieben Working Groups für temporäre Themen und drei Committees. Jeder Code- und Dokumentationsteil ist dabei einer konkreten SIG oder einem Subproject zugeordnet.

Wer sollte sich engagieren und wie gelingt der Einstieg?

Wer einsteigen möchte, findet über den Kubernetes-Slack (Kanal #kubernetes-new-contributors), die K-Dev-Mailingliste und den Community-Kalender Anschluss. Die monatliche NCO-Session findet jeweils am dritten Dienstag statt – für die EMEA/APAC-Region beispielsweise um 10:30 Uhr CET. Die Sessions laufen seit September 2024 und werden auch 2026 fortgesetzt.

Die Contributor Ladder als Karrierepfad

Fahlandt zufolge definiert die sogenannte Contributor Ladder einen transparenten Aufstiegspfad. Vom Non-member Contributor gelangt man über die Org-Membership – für die zwei bestehende Reviewer bürgen müssen – zum Reviewer, Approver und schließlich zum Subproject Owner oder SIG Chair. Fahlandt warnte allerdings vor einer typischen Einstiegsfalle: Wer sich isoliert ein „Good First Issue“ aus dem Repository schnappt und ohne Kontakt zur jeweiligen SIG daran arbeitet, scheitert häufig. Labels wie „good first issue“ oder „help wanted“ in Repositories wie kubernetes/kubernetes markieren zwar geeignete Aufgaben – etwa Dokumentationsverbesserungen, Link-Korrekturen oder Test-Ergänzungen. Doch der Schlüssel zum Erfolg liegt darin, zunächst einer SIG beizutreten, an deren Meetings teilzunehmen und sich dauerhaft einzubringen. Besonders niedrigschwellig sind sogenannte Evergreen-Aufgaben wie Meeting-Protokolle, SIG-Spotlight-Blogposts oder Reviews für die SIG Docs.

Wer den persönlichen Austausch sucht, findet im deutschsprachigen Raum zunehmend Gelegenheit, auf Konferenzen wie CloudLand 2026, den ContainerDays, den Cloud Native Days Austria oder der CLC 2026. Darüber hinaus plant die CNCF regelmäßig Kubernetes Community Days (KCDs), und über Meetup.com sind allein in Deutschland Tausende Mitglieder in Kubernetes-bezogenen Gruppen organisiert.

Fahlandts Fazit bringt die Philosophie der Community auf den Punkt: „Der Einstieg ist nicht immer leicht und das ist verständlicherweise frustrierend. Aber wenn man dranbleibt, lohnt es sich enorm. Wir würden euch gerne dabei helfen, dranzubleiben!“

Über den Speaker

Mario Fahlandt ist Customer Delivery Architect bei Kubermatic. Darüber hinaus engagiert er sich aktiv im Kubernetes-Projekt der CNCF – unter anderem als TAG Co Chair Operational Resilience, SIG Co Chair Contributor Experience, SIG K8s Infra und Comms Subproject Tech Lead.

(map)

Im vergangenen August habe ich an dieser Stelle argumentiert, dass Event Sourcing die perfekte Grundlage für KI sei. Die Kernthese lautete: Ohne vollständige, kontextreiche Daten bleibt jedes noch so leistungsfähige Modell blind. Event Sourcing liefert genau diese Daten, weil es nicht nur den aktuellen Zustand speichert, sondern die gesamte fachliche Geschichte. An der These hat sich nichts geändert. Doch eine Frage blieb damals offen: Wie macht man diese Daten für ein Large Language Model zugänglich?

Seit knapp anderthalb Jahren existiert mit dem Model Context Protocol (MCP) ein offener Standard, der LLMs mit beliebigen externen Datenquellen verbindet. Damit lässt sich die Lücke zwischen dem, was ein Event-Store an Daten bereithält, und dem, was ein Sprachmodell davon sehen kann, elegant schließen. Dieses Zusammenspiel verdient einen genaueren Blick.

Warum Kontext für LLMs alles entscheidet

Wer mit Large Language Models arbeitet, lernt schnell eine wichtige Lektion: Die Qualität der Antworten hängt weniger vom Modell ab als vom Kontext, den man ihm gibt. Ein durchschnittliches Modell mit hervorragendem Kontext liefert bessere Ergebnisse als ein Spitzenmodell, dem der Kontext fehlt. Das gilt für einfache Prompts ebenso wie für komplexe Analysen über Unternehmensdaten.

Kontext bedeutet hier nicht nur die Frage, die man stellt, sondern vor allem auch die Daten, auf die das Modell zugreifen kann. Und genau hier liegt das Problem: Die meisten Datenbanken speichern ausschließlich den aktuellen Zustand. Eine relationale Datenbank verrät Ihnen, dass eine Kundin den Status „Premium“ hat. Sie verrät aber nicht, seit wann, warum oder welche Interaktionen dazu geführt haben. Sie zeigt, dass ein Produkt 9,99 Euro kostet, nicht jedoch, ob dieser Preis gestern gesenkt wurde oder seit zehn Jahren unverändert ist. Sie zeigt, dass eine Bestellung den Status „offen“ hat, nicht jedoch, ob sie dreimal geändert, einmal storniert und dann erneut aufgegeben wurde.

Für ein LLM ist das, als würde man ihm ein Buch reichen, in dem nur das letzte Kapitel steht. Es kann den aktuellen Zustand beschreiben, aber keine Zusammenhänge erklären, keine Muster erkennen, keine Entwicklungen nachvollziehen. Es fehlt schlicht die Geschichte, die in den vorangegangenen Kapiteln erzählt wurde.

Event Sourcing löst dieses Problem grundlegend. Statt den Zustand zu speichern und bei jeder Änderung zu überschreiben, werden die einzelnen Zustandsänderungen als fachliche Ereignisse festgehalten. Jedes Ereignis beschreibt, was passiert ist, wann es passiert ist und in welchem fachlichen Kontext es steht. Die Summe aller Ereignisse ergibt nicht nur den aktuellen Zustand, sondern die vollständige, chronologische und unveränderliche Geschichte. Aus dem letzten Kapitel wird das gesamte Buch.

MCP als universelle Brücke

Die beste Datengrundlage nützt allerdings wenig, wenn ein LLM nicht darauf zugreifen kann. Bislang erforderte die Anbindung externer Datenquellen an ein Sprachmodell in der Regel individuelle Integrationen: eigene APIs, eigenen Glue-Code, eigene Wartung. Für jede Kombination aus Datenquelle und LLM musste eine eigene Lösung gebaut werden. Das skaliert schlecht und schafft Abhängigkeiten, die sich im Laufe der Zeit zu einer ernsthaften technischen Schuld entwickeln.

Das Model Context Protocol ändert das: MCP ist ein offener Standard, den Anthropic im November 2024 vorgestellt hat und der inzwischen breite Unterstützung durch zahlreiche Anbieter genießt. Auch OpenAI, Google und andere große Anbieter haben sich dem Standard angeschlossen. MCP definiert eine einheitliche Schnittstelle zwischen LLMs und externen Datenquellen. Ein MCP-Server stellt Werkzeuge und Daten bereit, die ein LLM über einen MCP-Client nutzen kann. Die Interaktion erfolgt in natürlicher Sprache: Das Modell formuliert Anfragen, der Server liefert die passenden Daten. Das Ganze geschieht über ein standardisiertes Protokoll auf Basis von JSON-RPC, sodass weder auf Client- noch auf Server-Seite proprietäre Technik erforderlich ist.

Das Entscheidende an MCP ist seine Datenquellenagnostik. Der Standard definiert, wie die Kommunikation abläuft, nicht jedoch, welche Art von Daten dahintersteckt. Ob ein MCP-Server eine relationale Datenbank, ein Dateisystem, eine API oder einen Event-Store anbindet, spielt auf Protokollebene keine Rolle. Inzwischen existieren MCP-Server für Dutzende von Systemen: von GitHub über Slack bis hin zu Datenbanken verschiedenster Art.

Die Frage, die MCP nicht beantwortet, ist deshalb umso wichtiger: Welche Qualität haben die Daten, die über diesen Kanal fließen? Wenn MCP die Brücke zwischen LLM und Datenquelle ist, dann entscheidet die Datenquelle darüber, wie tragfähig diese Brücke sein kann. Eine über MCP angebundene CRUD-Datenbank liefert weiterhin nur Snapshots. Ein Event-Store hingegen liefert die ganze Geschichte.

Was ein LLM in einer Bibliothek sehen kann

Um das greifbar zu machen, hilft ein konkretes, von mir regelmäßig genutztes Beispiel, das eine öffentliche Bibliothek als Domäne modelliert. Die zugehörigen Events sind überschaubar und dennoch fachlich reichhaltig: Ein BookAcquired-Event beschreibt die Anschaffung eines neuen Buches mit Titel, Autorin oder Autor und ISBN. BookBorrowed dokumentiert die Ausleihe, BookReturned die Rückgabe. Auf der Seite der Leserinnen und Leser gibt es ReaderApplied für die Anmeldung und ReaderAccepted für die Freischaltung des Bibliotheksausweises. Geht es an die konkrete Implementierung, greife ich auf den CloudEvents-Standard zurück, der ein fachlich benanntes Typenfeld und eine umgekehrte Domain-Schreibweise wie io.eventsourcingdb.library.book-borrowed vorsieht. Jedes Buch und jede Leserin beziehungsweise jeder Leser bildet dabei ein eigenes Subject, also einen eigenen Event-Stream, der die jeweilige Geschichte vollständig abbildet.

Stellen Sie sich nun vor, ein LLM hätte über einen MCP-Server Zugriff auf den Event-Store dieser Stadtbibliothek. Es könnte die vorhandenen Subjects durchsuchen, also die einzelnen Bücher sowie Leserinnen und Leser identifizieren. Es könnte die Event-Typen auflisten und so die Struktur der Domäne verstehen, ohne dass jemand sie erklären müsste. Und es könnte gezielt Fragen beantworten, die mit einer CRUD-Datenbank schwer oder gar nicht zu beantworten wären.

„Welche Bücher wurden in den letzten zwölf Monaten angeschafft, aber noch nie ausgeliehen?“

Diese Frage erfordert die Kenntnis, dass ein Buch existiert (BookAcquired), und die Abwesenheit eines bestimmten Folgeereignisses (BookBorrowed). In einer CRUD-Datenbank müsste dafür ein eigens gepflegtes Feld existieren, das bei jeder Änderung korrekt aktualisiert wird. Im Event-Store ergibt sich die Antwort direkt aus der Ereignisfolge.

„Zeige mir die vollständige Ausleihhistorie von Leserin 23.“

In einer CRUD-Datenbank sehen Sie bestenfalls, welches Buch die Leserin gerade ausgeliehen hat. Im Event-Store sehen Sie jede einzelne Ausleihe, jede Rückgabe, jede verspätete Rückgabe und jede erhobene Gebühr. Das LLM kann daraus Muster ableiten, etwa ob bestimmte Genres bevorzugt werden oder ob Rückgaben regelmäßig verspätet erfolgen.

„Welche Bücher werden häufig ausgeliehen, aber selten rechtzeitig zurückgebracht?“

Auch das ist eine Frage, die erst durch die Kombination mehrerer Ereignisse über die Zeit beantwortbar wird. Ein LLM, das diese Daten sieht, kann nicht nur die Antwort liefern, sondern auch Hypothesen formulieren: Liegt es an der Länge des Buches? An der Beliebtheit? An konkreten Leserinnen und Lesern, die generell verspätet zurückgeben?

Entscheidend ist: Keine dieser Fragen erfordert, dass jemand vorab ein spezielles Lesemodell gebaut oder eine Auswertung programmiert hat. Das LLM formuliert die Frage, der MCP-Server liefert die Daten, und das Modell interpretiert sie. Die Flexibilität entsteht dadurch, dass die Rohdaten fachlich und historisch vollständig sind. Was in diesem Beispiel mit einer Stadtbibliothek funktioniert, funktioniert in der Realität mit jeder Domäne: Versicherungsschäden, Logistikketten, Bestellprozesse im E-Commerce, Behandlungsverläufe im Gesundheitswesen, …: Die Liste ist endlos. Und je reichhaltiger die Events aus semantischer Sicht sind, desto mehr kann ein LLM damit anfangen.

Warum Events die natürliche Sprache für LLMs sind

Es gibt einen weiteren Grund, warum Event Sourcing und LLMs so gut zusammenpassen, und er liegt in der Form der Daten selbst. Events sind von Natur aus in fachlicher Sprache formuliert. Ein Event-Typ wie io.eventsourcingdb.library.book-borrowed sagt bereits, was passiert ist. Die Daten des Events enthalten die Details: welches Buch, welche Leserin oder welcher Leser, zu welchem Zeitpunkt. Ein LLM muss bei solchen Daten nicht raten, was gemeint ist. Es liest keine kryptischen Statuscodes, keine technischen Fremdschlüssel, keine Spalte type mit dem Wert 3. Es liest genau das, was passiert ist: Ein Buch wurde ausgeliehen, ein Buch wurde zurückgegeben, eine Gebühr wurde erhoben, eine Leserin wurde gesperrt. Die Semantik steckt in den Daten selbst.

Hinzu kommt die chronologische Ordnung. Events sind naturgemäß zeitlich sortiert. Ein LLM kann die Events daher lesen wie eine Erzählung: Erst wurde das Buch angeschafft, dann ausgeliehen, dann zurückgegeben, dann erneut ausgeliehen, dann verspätet zurückgegeben, dann eine Gebühr erhoben. Diese narrative Struktur entspricht genau dem, womit Sprachmodelle am besten umgehen können. Sie sind darauf trainiert, Zusammenhänge in sequenziellen Daten zu erkennen, Muster zu identifizieren und Schlussfolgerungen zu ziehen. Eine Folge von Events ist strukturell näher an einem Text als an einer relationalen Tabelle.

Schließlich ist jedes Event in sich abgeschlossen und kontextreich. Es beschreibt nicht nur, was sich geändert hat, sondern trägt den fachlichen Zusammenhang bereits in sich. Ein BookBorrowed-Event enthält nicht nur eine Buch-ID und eine Leser-ID, sondern steht im Kontext eines Subject, das die gesamte Geschichte dieses Buches repräsentiert. Dieser eingebaute Kontext reduziert die Notwendigkeit, dem LLM zusätzliche Erklärungen mitzugeben. Die Events sprechen für sich.

Wer die aktuelle Entwicklung beim Context Engineering verfolgt, erkennt die Parallele: Es geht darum, einem Sprachmodell möglichst reichhaltigen, strukturierten und relevanten Kontext zur Verfügung zu stellen. Events erfüllen alle drei Kriterien, ohne dass eine zusätzliche Aufbereitung nötig wäre. Sie sind gewissermaßen bereits in der Sprache geschrieben, die LLMs am besten verstehen. Mit anderen Worten: Wenn Ihre Software bereits gute Daten liefert, wird die Auswertung per künstlicher Intelligenz bedeutend vereinfacht.

Von der Idee zur Praxis

Die Verbindung von Event Sourcing und MCP ist keine bloße Theorie. Mitte März 2026 wurde beispielsweise für die Datenbank EventSourcingDB ein MCP-Server als kostenfreie Erweiterung veröffentlicht. Er ermöglicht es, über ein beliebiges LLM in natürlicher Sprache mit dem Event-Store zu interagieren: Events lesen und schreiben, Subjects und Event-Types durchsuchen, Event-Schemas registrieren, EventQL-Queries ausführen und sogar die eingebaute EventQL-Dokumentation abfragen. Der MCP-Server läuft dabei als eigenständiger Prozess neben der Datenbank, unterstützt TLS-Verschlüsselung und Token-basierte Authentifizierung und ist als Docker-Image verfügbar.

Praktisch bedeutet das: Eine Entwicklerin kann ihrem LLM die Frage stellen, welche Subjects im Event-Store existieren, und erhält eine strukturierte Antwort. Sie kann fragen, welche Ereignisse für ein bestimmtes Buch vorliegen, und das LLM liest sie chronologisch aus dem Store. Sie kann eine analytische Frage formulieren, und das LLM übersetzt sie in eine EventQL-Query, führt sie aus und interpretiert das Ergebnis. All das geschieht über eine standardisierte Schnittstelle, ohne eine einzige Zeile Integrationscode. Was bisher erfahrene Entwicklerinnen und Entwickler mit Kenntnissen der Query-Sprache und der Datenstruktur erforderte, wird durch natürliche Sprache für ein breiteres Publikum zugänglich.

Es wäre jedoch falsch, diesen Gedanken auf ein einzelnes Produkt zu verengen. Das Prinzip gilt für jeden Event-Store, der einen MCP-Server anbietet oder künftig anbieten wird. Der Wert liegt nicht in der spezifischen Implementierung, sondern in der Kombination: ein Event-Store, der die vollständige fachliche Geschichte bereithält, und ein standardisiertes Protokoll, das diese Geschichte für Sprachmodelle zugänglich macht. EventSourcingDB ist lediglich ein konkretes Beispiel dafür, wie diese Kombination heute in der Praxis aussehen kann.

Nicht die Technik entscheidet, sondern die Daten dahinter

MCP löst also ein reales Problem: Es standardisiert den Zugang von LLMs zu externen Datenquellen und macht individuelle Integrationen überflüssig. Das ist ein bedeutender Schritt. Doch MCP allein reicht nicht. Ein standardisierter Zugang zu unzureichenden Daten liefert standardisiert unzureichende Ergebnisse.

Die eigentliche Frage bleibt bestehen: Welche Daten stecken hinter dem MCP-Server? Wer eine CRUD-Datenbank anbindet, gibt einem LLM Zugriff auf den aktuellen Zustand. Das ist besser als gar kein Zugriff, bleibt aber bei Snapshots ohne Geschichte. Das LLM sieht, was ist. Es sieht nicht, was war, was sich verändert hat oder warum.

Wer hingegen einen Event-Store anbindet, gibt einem LLM Zugriff auf die gesamte fachliche Historie. Es sieht nicht nur den Zustand, sondern den Weg dorthin. Es kann Muster erkennen, Zusammenhänge herstellen und Entwicklungen nachvollziehen. Es kann erklären, nicht nur beschreiben.

Die Kombination aus Event Sourcing und MCP ist deshalb so wirkungsvoll, weil sie zwei komplementäre Probleme gleichzeitig behebt. Event Sourcing löst das Datenproblem: Es liefert vollständige, kontextreiche und fachlich formulierte Daten. MCP löst das Zugangsproblem: Es macht diese Daten über eine standardisierte Schnittstelle für Sprachmodelle erreichbar. Keines der beiden löst für sich allein die gesamte Herausforderung. Zusammen jedoch schließen sie eine Lücke, die bislang dafür sorgte, dass LLMs entweder keinen Zugang zu den richtigen Daten hatten oder Zugang zu den falschen.

Dabei ist bemerkenswert, wie stabil diese Kombination gegenüber Veränderungen ist. Die Modelle werden sich weiterentwickeln, neue LLMs werden erscheinen, bestehende werden leistungsfähiger. Die Art, wie wir Prompts formulieren, wird sich ändern. Auch MCP wird sich als Protokoll weiterentwickeln. Was sich nicht ändern wird, sind die gespeicherten Ereignisse. Sie bleiben das unveränderliche Fundament, auf dem alles andere aufbaut. Wer heute damit beginnt, Events zu speichern, investiert nicht in eine kurzlebige Technologie, sondern in Daten, die mit jedem neuen Modell und jedem zukünftigen Zugangsweg an Wert gewinnen.

Wer im vergangenen August meinen eingangs erwähnten Artikel über Event Sourcing als Grundlage für KI gelesen hat, findet hier den nächsten logischen Schritt. Die Daten sind da. Jetzt sind sie auch zugänglich.

(rme)

Microsoft hat seine Entwicklungsumgebung Visual Studio 2026 im März mit neuen Features versehen, die sich vor allem um Künstliche Intelligenz (KI) drehen. Alle neuen Funktionen sind in der Insiders-Version verfügbar.

Agent Skills und benutzerdefinierte Agenten

In Visual Studio können Entwicklerinnen und Entwickler nun benutzerdefinierte Copilot-Agenten erstellen. Diese können beispielsweise den Coding-Standards des Teams folgen oder interne Dokumentation durchsuchen. Die spezialisierten Copilot-Agenten können Zugriff auf Workspace-Awareness, Codeverständnis, Tools, das bevorzugte Modell und Verbindungen via Model Context Protocol (MCP) zu externen Wissensquellen erhalten.

Dazu spezifizieren Entwickler die gewünschten Anpassungen in einer .agent.md-Datei, fügen diese im Repository zu .github/agents/ hinzu und können dann den neuen Agenten im Agent Picker auswählen. Wurde kein Modell festgelegt, verwendet der KI-Agent das im Model Picker gewählte Modell.

Mit Skills lassen sich die KI-Agenten ebenfalls versehen. Die Agenten beziehen Skills automatisch aus verschiedenen Stellen im Repo, etwa .github/skills/, oder aus dem User-Profil, etwa ~/.copilot/skills/. Jeder Skill besitzt ein eigenes Verzeichnis mit einer SKILL.md-Datei, die der Agent-Skill-Spezifikation entspricht. Agent Skills sind ein offenes Format, um KI-Agenten mit spezialisiertem Wissen auszustatten.

Copilot behebt NuGet-Vulnerabilities

Der KI-Copilot kann nun auch dabei helfen, Vulnerabilities zu beheben. Direkt aus dem Solution Explorer heraus können Entwicklerinnen und Entwickler die Benachrichtigung „Fix with GitHub Copilot“ anwählen, wenn eine Vulnerability erkannt wurde, die NuGet betrifft, das Paketverwaltungssystem für .NET. Beim Durchklicken analysiert Copilot die Schwachstelle und kann entsprechende Dependency-Updates empfehlen sowie implementieren.

Weitere Updates betreffen unter anderem die Verwendung von MCP: Admins können festlegen, welche MCP-Server innerhalb ihrer Organisation erlaubt sind, und nur diese lassen sich dann in Visual Studio verwenden. Bei anderen Servern erscheint eine Fehlermeldung.

Die neuen Features lassen sich im Insiders-Build nutzen. Weitere Informationen zu den Updates liefert Microsofts Entwicklerblog.

(mai)