Die fertige Version von .NET 10.0 steht seit den Abendstunden des 11. November 2025 auf der Downloadseite kostenfrei zur Verfügung. Für .NET 10.0 benötigen Entwicklerinnen und Entwickler die Entwicklungsumgebung Visual Studio 2026 (alias Version 18.0), die ebenfalls gestern erstmals in einer stabilen Version erschienen ist.

Support für 36 Monate

Microsoft gewährt für .NET 10.0 einen Long-Term Support (LTS) von 36 Monaten, also von November 2025 bis November 2028. Für die vorherige Version .NET 9.0 endet der Support ebenfalls im November 2028, nachdem Microsoft im September bekanntgab, den ursprünglich auf 18 Monate begrenzten Support auf 24 Monate zu erweitern.

Diese Erweiterung gilt ab .NET 9.0 für alle Versionen mit Standard-Term Support (STS). .NET 11.0, das im November 2026 erscheinen soll (voraussichtlich wieder am zweiten Dienstag im November, also am 10.11.2026), wird wieder eine solche Version mit Standard-Term Support sein.

.NET für Android läuft auch auf .NET Core Runtime

Der Aufbau von .NET 10.0 ist fast der gleiche wie bei .NET 9.0 (siehe Abbildung): zahlreiche Anwendungsarten laufen auf Basis eines gemeinsamen Software Development Kit (SDK), einer gemeinsamen Basisklassenbibliothek, den Sprachen C#, F# und Visual Basic .NET sowie dem in (fast) allen Anwendungsarten verwendbaren objektrelationalen Mapper Entity Framework Core. Anders als der Vorgänger Entity Framework Core 9.0, der auf .NET 8.0 und .NET 9.0 nutzbar war, läuft die Version 10.0 des objektrelationalen Mappers ausschließlich auf .NET 10.0. Im Untergrund von .NET 10.0 wirken weiterhin zwei verschiedene Runtimes, abhängig von Anwendungsart und Betriebssystem: die .NET Core Runtime und die Mono Runtime.

Neu in .NET 10.0 ist, dass Android-Anwendungen nicht nur wie bisher auf der Mono Runtime, sondern auch auf der .NET Core Runtime laufen können. Dieses Feature gilt aber in .NET 10.0 als experimentell. Ebenso gilt die Kompilierung von Konsolenanwendungen und Browseranwendungen (außer innerhalb von Blazor) zu WebAssembly weiterhin als experimentelles Feature.

Wieder zahlreiche Breaking Changes

Umsteiger von älteren .NET-Versionen auf .NET 10.0 müssen nicht nur das Target-Framework in der Projektdatei bzw. zentralen Build-Konfigurationsdatei Directory.Build.props auf net10.0 ändern, sondern auch einige Breaking Changes berücksichtigen.

Die Breaking Changes, von denen es in .NET 10.0 weniger als in den letzten Versionen gibt, dokumentiert Microsoft in drei Listen:

.NET 10.0 läuft schneller

Wie in den letzten Versionen hat Microsoft zahlreiche Leistungsverbesserungen eingebaut. Insbesondere sind das in .NET 10.0 Verbesserungen der Ausführungszeit und Speicherallokation bei zahlreichen .NET-Basisklassen, was sich positiv auf viele Anwendungen auswirkt. Erläuterungen zu den Performance- und Speicherverbrauchsverbesserungen und genaue Zahlen findet man in einem sehr langen Dokument.

Neuerungen in allen Bereichen

In .NET 10.0 gibt es viele neue Funktionen in allen Bereichen: bei der Programmiersprache C#, in der Basisklassenbibliothek, beim objektrelationalen Mapping mit Entity Framework Core, bei der JSON-Serialisierung mit System.Text.Json, den Webframeworks ASP.NET Core und Blazor sowie bei dem Cross-Platform-UI .NET MAUI. Auch bei den alten Windows-Desktop-Frameworks Windows Forms und WPF gibt es einzelne Verbesserungen.

heise Developer hatte über die Neuerungen in .NET 10.0 jeweils anhand der Preview- und Release-Candidate-1-Versionen berichtet, sofern es dort signifikante Neuerungen gab.

KI-nutzende Entwicklertools sind laut Linus Torvalds auch nur Werkzeuge, daher bedürfen sie keiner neuen Regeln bei der Kernel-Entwicklung – und auch bei Copyright-Fragen greift das Gewohnte. Das ist die Kurz- und Grobform einiger Aussagen, die der Linux-Erfinder diese Woche im Rahmen einer noch laufenden Diskussion getätigt hat.

Anlass für die Aussagen war ein zur Begutachtung eingereichter Text, der Richtlinien zum Einsatz von KI-Tools bei der Entwicklung von Torvalds‘ Kernel definiert. Mitglieder des Linux Technical Advisory Board haben ihn ausgearbeitet, nachdem es vor einigen Monaten eine Debatte um Auszeichnungen beim Einsatz von KI-Werkzeugen gab, als ein Entwickler des Stable-Teams von Linux hier vorgeprescht war. Letzterer nutzt schon eine Weile Machine Learning und mittlerweile AI-Tools, um Patches zu identifizieren, die ein Zurückportieren in ältere Versionen wert sind.

Entschieden ist bezüglich der KI-Richtlinien aber noch nichts. Der Text und die Diskussionen sollen die Basis für eine Entscheidung beim diesjährigen Linux Kernel Maintainer Summit Anfang Dezember in Tokio bilden, zu dem jährlich zirka 30 der wichtigsten Linux-Entwickler eingeladen werden.

Gleiche Regeln für Suchen-und-Ersetzen und KI

Torvalds Aussage zur Einstufung von KI-Tools als normale Werkzeuge ist vom Grundton der vorgestellten Richtlinien gar nicht so weit weg. Dieser stuft KI-nutzende Entwicklerwerkzeuge als eine noch gewieftere Form von komplexen und schon länger eingesetzten Werkzeugen ein – etwa das schon seit Jahren bei der Linux-Entwicklung gelegentlich verwendete Refactoring-Tool Coccinelle. Wie zuvor sollten Entwickler daher exakt dokumentieren, welche solcher Tools sie wie bei der Entwicklung eines Patches eingesetzt haben.

Laut dem Richtlinien-Vorschlag soll das allerdings nicht für einfache Tools gelten, etwa solche zum Umformatieren des Codes oder zum Suchen-und-Ersetzen. Daran hat sich Torvalds gestört, denn er will deren Einsatz genauso dokumentiert wissen – und verweist auf einige ältere Änderungen, wo die Patch-Beschreibung beschreibt, wie Entwickler mithilfe von ’sed‘ komplexere Umbenennungen durchgeführt haben. Dabei betont er, KI-Tools bräuchten keine Sonderbehandlung.

Urheberrechtsproblematik ist die Gleiche wie bei anderen Patches

Ähnlich sieht Torvalds es bei der Copyright-Frage, wie er in einem späteren Diskussionsbeitrag erläutert: Der Urheberrecht-Aspekt gelte für anderen Code genauso. So führt er an, dass der Kernel schon allerlei von einem Computer generierten Code enthält, wie Millionen von Zeilen in Headern des Amdgpu-Treibers. Was er nicht sagt, aber damit offenbar meint: Die Verantwortung liegt am Ende beim Entwickler, der den Code einreicht.

In ebendieser Mail teilt Torvalds aber auch in Richtung KI aus und merkt an, das Besondere an KI sei „der Hype und die Milliarden und Abermilliarden von Dollar“. Später schließt er mit „KI ist nur ein weiteres Werkzeug, Leute. Eines, mit dem manche Leute viel Geld verdienen. Und ja, es wird die Gesellschaft verändern. Aber es ist und bleibt nur ein Werkzeug“.

(dmk)

Für viele Unternehmen lautet die zentrale Frage nicht mehr, ob sie künstliche Intelligenz einsetzen, sondern wie sie diese verantwortungsvoll und nachhaltig integrieren. Bislang bremsen fragmentierte, nicht standardisierte Insellösungen und meist teure proprietäre KI-Stacks die Einführung noch. Besonders für Organisationen, die auf Datensouveränität, Compliance und langfristige finanzielle Stabilität setzen, stellt die unkoordinierte KI-Infrastruktur ein erhebliches Risiko dar – in Hybrid-Cloud-Umgebungen ebenso wie On-Premises.

Mit der im Rahmen der KubeCon + CloudNativeCon North America 2025 offiziell freigegebenen Version 1.0 des „Kubernetes AI Conformance“-Programms will die Cloud Native Computing Foundation (CNCF) nun Ordnung in die zersplitterte KI-Landschaft bringen. Das Programm geht dabei über eine Zertifizierung hinaus – es ist als eine weltweit getragene Open-Source-Initiative angelegt, die einen gemeinsamen technischen Standard für KI-Infrastrukturen schaffen soll. „Insbesondere für europäische Unternehmen liefert sie den Rahmen, um KI sicher und skalierbar einzusetzen“, erklärt Mario Fahlandt, der bei der CNCF unter anderem als Co-Chair der Technical Advisory Group (TAG) Operational Resilience sowie der Special Interest Group (SIG) Contributor Experience für Kubernetes aktiv ist. „Die Initiative definiert eine klare, zukunftssichere Roadmap, die Workload‑Portabilität, technische Konsistenz und digitale Souveränität gewährleistet.“

Technische Standards versus Prozess‑Frameworks

Während der KI-Markt durch eine Vielzahl an Zertifizierungen geprägt ist, müssen Entscheidungsträger klar zwischen technischen und organisatorischen Standards unterscheiden. Einige Anbieter konzentrieren sich auf Management- und Governance-Frameworks wie ISO 42001. Dieser internationale Standard legt Anforderungen für den Aufbau eines KI-Managementsystems (AIMS) fest. Er unterstützt Unternehmen dabei, Risiken, ethische Fragen, Datenschutz und regulatorische Vorgaben zu steuern. Außerdem bewertet er, ob interne Prozesse eine verantwortungsvolle Entwicklung und Bereitstellung von KI sicherstellen.

Das neue CNCF‑Programm „Kubernetes AI Conformance“ hebt sich grundlegend von Governance-Standards ab. Es fungiert primär als technischer Implementierungsstandard und legt dazu fest, welche Fähigkeiten, APIs und Konfigurationen ein Kubernetes-Cluster benötigt, um KI‑ und ML‑Workloads zuverlässig und effizient auszuführen. Damit zielt die CNCF-Konformität auf eine garantierte technische Portabilität ab, die auch zu weniger Abhängigkeit von einzelnen Herstellern beiträgt. Sie stellt sicher, dass Unternehmen ihre KI-Anwendungen künftig auf jeder konformen Plattform betreiben können – in der Public Cloud, im eigenen Rechenzentrum oder an Edge-Standorten. Diese Portabilität bildet die Grundlage digitaler und damit auch datengetriebener Souveränität.

Die Entwicklung des Standards treibt innerhalb des Kubernetes-Projekts eine neu gebildete Arbeitsgruppe voran, die durch die Special Interest Groups Architecture und Testing unterstützt wird. Seit der KubeCon Europe im Frühjahr 2025 hat die Gruppe zunächst zentrale technische Säulen definiert, die die besonderen Anforderungen von KI‑Workloads berücksichtigen. „Darauf aufbauend entstand ein verbindlicher Anforderungskatalog, den jede Plattform erfüllen muss, um als Kubernetes-AI-konform zu gelten“, erläutert Fahlandt.

Effizientes Management von Beschleunigern im KI-Training

KI‑Trainingsjobs setzen umfassende Hardware‑Ressourcen voraus und benötigen meist teure, häufig zudem knapp verfügbare GPUs. In nicht standardisierten Umgebungen ergeben sich daraus zwei Kernprobleme:

• Ressourcenfragmentierung: Wertvoller GPU‑Speicher bleibt ungenutzt.
• Topologie‑Blindheit: Das Scheduling ist nicht für Multi‑GPU‑Workloads optimiert.

Beide Aspekte tragen zur Überprovisionierung und steigenden Kosten bei.

Eine CNCF‑konforme Plattform muss daher die Kubernetes-API für Dynamic Resource Allocation (DRA) unterstützen. Seit Kubernetes-Version 1.34 gilt DRA als stabil und ermöglicht es, komplexe Hardware-Ressourcen flexibel anzufordern und zu teilen. Ähnlich dem PersistentVolumeClaim‑Modell für Speicher können Nutzerinnen und Nutzer gezielt Ressourcen aus definierten Geräteklassen anfordern. Kubernetes übernimmt dabei automatisch das Scheduling und die Platzierung aller Workloads.

Erweiterte Ingress‑Funktionen für KI-Inferenz

KI‑Inferenz‑Workloads – also KI-Modelle im Betrieb – unterscheiden sich stark von typischen, zustandslosen Webanwendungen. Sie laufen meist länger, beanspruchen viele Ressourcen und speichern Zustände. Standard‑Load‑Balancer sind für deren Lastverteilung ungeeignet. Das CNCF‑Konformitätsprogramm verlangt daher die Unterstützung der Kubernetes Gateway API und ihrer Erweiterungen für modellbewusstes Routing (model‑aware routing).

Die Gateway API Inference Extension, ein offizielles Kubernetes‑Projekt, erweitert Standard-Gateways zu spezialisierten Inference‑Gateways. Damit lassen sich Routing und Load Balancing gezielt für KI‑Workloads optimieren. Unterstützte Funktionen sind unter anderem gewichtete Verkehrsaufteilung (weighted traffic splitting) und Header‑basiertes Routing, das etwa für OpenAI-Protokoll‐Header relevant ist.

Zeitplanung und Orchestrierung von KI‑Workloads

Verteilte KI-Trainingsjobs bestehen aus mehreren Komponenten, die gleichzeitig starten müssen. Plant der Scheduler Pods einzeln ein, kann es zu Deadlocks kommen: Ein Job bleibt hängen, weil einige Pods keine Ressourcen finden, andere aber bereits Ressourcen blockieren. Eine Kubernetes-Plattform muss mindestens eine All‑or‑Nothing‑Scheduling‑Lösung unterstützen, beispielsweise Kueue oder Volcano. So starten verteilte KI‑Workloads nur, wenn alle zugehörigen Pods gleichzeitig platziert werden können.

Ist ein Cluster‑Autoscaler aktiv, soll er Knotengruppen mit bestimmten Beschleunigertypen je nach Bedarf automatisch vergrößern oder verkleinern. Ebenso muss der HorizontalPodAutoscaler Beschleuniger‑Pods korrekt skalieren und dabei auch benutzerdefinierte Metriken berücksichtigen, die für KI‑ und ML‑Workloads relevant sind.

Überwachung und Metriken

Moderne KI‑Workloads und spezialisierte Hardware erzeugen neue Lücken im Monitoring. Noch fehlt ein einheitlicher Standard, um Beschleuniger-Metriken zu erfassen – viele Teams verfügen daher nicht über geeignete Werkzeuge, um Infrastrukturprobleme schnell zu analysieren.

Jede CNCF‑konforme Plattform muss daher künftig eine Anwendung installieren können, die Leistungsmetriken für alle unterstützten Beschleunigertypen – etwa Auslastung oder Speichernutzung – über einen standardisierten Endpunkt verfügbar macht. Zusätzlich ist ein Überwachungssystem erforderlich, das Metriken automatisch erfasst und verarbeitet, wenn Workloads sie im Standardformat (z. B. Prometheus‑Expositionsformat) bereitstellen.

Sicherheit und Ressourcentrennung

Beschleuniger wie GPUs sind gemeinsam genutzte Ressourcen. Fehlt eine strikte Isolierung auf Kernel‑ und API-Ebene, können Container‑Workloads gegenseitig auf Daten oder Prozesse zugreifen und so Sicherheitsrisiken in Multi‑Tenant‑Umgebungen verursachen. Eine CNCF‑konforme Plattform muss daher den Zugriff auf Beschleuniger klar trennen und über Frameworks wie Dynamic Resource Allocation (DRA) oder Geräte-Plug-ins kontrollieren. Nur so lassen sich Workloads isolieren und unerlaubte Zugriffe oder Beeinträchtigungen verhindern.

Unterstützung für Operatoren

KI-Frameworks wie Ray oder Kubeflow sind verteilte Systeme, die auf Kubernetes als Operatoren laufen. Eine Plattform benötigt dafür eine stabile Basis, um zu verhindern, dass instabile Webhooks, CRD‑Verwaltung (Custom Resource Definition) oder eine unzuverlässige API-Server-Struktur dazu führen, dass Operatoren ausfallen und die gesamte KI-Plattform zum Stillstand kommt.

Eine CNCF-konforme Umgebung muss mindestens einen komplexen KI-Operator (etwa Ray oder Kubeflow) installieren und ausführen können. Sie muss nachweisen, dass Operator‑Pods, Webhooks und die Reconciliation der Custom Resources stabil und vollständig funktionieren.

Ein internationaler, Community‑getriebener Standard mit europäischer Beteiligung

Das Kubernetes-AI-Conformance‑Programm der CNCF schafft auf Basis der von der Arbeitsgruppe WG AI Conformance definierten Säulen einen stabilen, offenen und zukunftssicheren Standard für KI-Infrastrukturen. Plattformen, die auf den offenen Upstream-APIs basieren, eröffnen insbesondere auch europäischen Unternehmen die Chance, ihre KI-Strategien portabel und souverän umzusetzen – von der Public Cloud bis zum sicheren On‑Premises‑Rechenzentrum. „Verschiedene Anbieter‑Plattformen sind bereits ‚Kubernetes AI Conformant‘ für die Kubernetes-Versionen 1.33 und 1.34“, sagt Fahlandt. Dazu zählen auch Plattformen europäischer Anbieter wie Gardener, Giant Swarm, Kubermatic und SUSE.

Weitere Anforderungen werden laufend entwickelt und im Community‑Prozess diskutiert. Die CNCF lädt alle Interessierten ein, sich aktiv an dem offenen Standard zu beteiligen. Weitergehende Informationen rund um das Programm finden sich in der offiziellen Ankündigung im CNCF-Blog.

(map)