Kubernetes | The .NET Blog

Aspire 13.3: Kubernetes-Unterstützung, Browser-Logs und die Aspireify-Funktion

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Fünf Wochen sind keine lange Zeit für ein Release, aber Aspire 13.3 fühlt sich nicht so an. Die Hauptpunkte sind bedeutsam: erstklassiges Kubernetes- und AKS-Deployment mit Helm, eine agentengestützte Onboarding-Funktion namens Aspireify, Browser-Log-Erfassung direkt im Dashboard und strukturierte Befehlsergebnisse. Dazu 45 neue Features, 134 Verbesserungen und 93 Fehlerbehebungen.

Kommen wir zu den Highlights.

Aspireify: Agentengestütztes Onboarding

Aspire zu einem bestehenden Projekt hinzuzufügen klingt einfach — AppHost einfügen, fertig. In der Praxis erfordert es viel Recherche: welche Ports wichtig sind, welche Umgebungsvariablen echte Abhängigkeiten sind, welche Docker-Compose-Dienste zu Aspire-Integrationen zugeordnet werden sollen.

Die neue Aspireify-Funktion gibt Ihrem Coding-Agenten einen geführten Workflow genau dafür. Wenn aspire init einen Skelett-AppHost erstellt, hilft die Aspireify-Funktion dem Agenten, das Repository zu inspizieren, zu verstehen, wie es bereits funktioniert, und den AppHost so zu verdrahten, dass er zur App passt — nicht umgekehrt.

Die Standardhaltung ist “Änderungen an Ihrem Code minimieren.” Wenn Ihre App bereits DATABASE_URL liest, mappt der Agent das mit WithEnvironment() anstatt Sie zu bitten, Ihre Konfiguration neu zu schreiben. Wenn ein Port fest codiert ist, teilt die Funktion dem Agenten mit, wann er ihn beibehalten soll.

Das ist die Art von KI-Tooling, die wirklich Zeit spart, anstatt mehr Arbeit zum Überprüfen zu generieren.

Erstklassiges Kubernetes- und AKS-Deployment

Dies stand schon eine Weile auf der Wunschliste. Aspire 13.3 liefert erstklassige Kubernetes- und AKS-Deployment-Unterstützung mit Helm. Sie können jetzt AKS direkt aus den Aspire-Tools als Deployment-Ziel wählen.

Für Teams, die bereits Produktionsworkloads auf AKS betreiben, schließt dies eine bedeutende Lücke. Ihr Aspire-App-Modell hat jetzt einen sauberen Weg von der lokalen Entwicklung zu Kubernetes ohne manuelle Helm-Chart-Erstellung.

Browser-Logs im Dashboard

Das ist eine jener Funktionen, die klein erscheinen, bis man ein Frontend-Problem debuggt.

Die neue WithBrowserLogs() API hängt eine verfolgte Browser-Ressource an jede endpoint-fähige Ressource an. Aspire startet Chromium mit einer privaten CDP-Pipe und streamt Konsolen-Logs, Netzwerkanfragen und Fehler direkt in den Ressourcen-Log-Stream:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

Der TypeScript AppHost unterstützt dasselbe:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Konsolen-Fehler, fehlgeschlagene Netzwerkanfragen, clientseitige Ausnahmen — alles im selben Dashboard sichtbar, wo Sie bereits Traces und Metriken beobachten. Kein Tab-Wechsel zu Browser DevTools mehr für die Grundlagen.

Strukturierte Befehlsergebnisse

Ressourcenbefehle haben ein bedeutsames Upgrade erhalten. Bisher gaben Befehle Erfolg/Misserfolg zurück. Jetzt geben sie strukturierte Ergebnisse zurück: Text, JSON oder Markdown, das durch das Modell, die Dashboard-Benutzeroberfläche, die CLI und die MCP-Tools fließt.

Das Dashboard verbindet all das mit einem neuen Benachrichtigungscenter im Header. Befehlsergebnisse erscheinen als zeitgestempelte Benachrichtigungen mit Markdown-Rendering und einer “Antwort anzeigen”-Aktion.

Das macht Ressourcenbefehle wirklich komposierbar. Eine Integration kann jetzt einen Befehl exponieren, der eine bedeutsame Ausgabe zurückgibt — wie eine Tunnel-URL — anstatt nur irgendwo den Zustand zu ändern.

Fazit

Aspire 13.3 ist das Upgrade wert, allein schon für die Kubernetes-Unterstützung. Die Browser-Logs und strukturierten Befehlsergebnisse fühlen sich wie die Art von Verbesserungen der Lebensqualität an, die sich in einem alltäglichen Entwicklungsworkflow schnell ansammeln.

Vollständige Versionshinweise: What’s New in Aspire 13.3

KubeCon Europe 2026: Was .NET-Entwickler wirklich wissen sollten

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Kennst du das Gefühl, wenn ein riesiger Ankündigungs-Post erscheint und du durchscrollst und denkst: „Cool, aber was ändert das jetzt tatsächlich für mich"? So geht es mir jede KubeCon-Saison.

Microsoft hat gerade ihren vollständigen KubeCon Europe 2026 Überblick veröffentlicht — geschrieben von Brendan Burns persönlich — und ehrlich gesagt steckt hier echte Substanz drin. Nicht nur Feature-Checklisten, sondern operative Verbesserungen, die ändern, wie du Dinge in Produktion betreibst.

Lass mich aufschlüsseln, was für uns .NET-Entwickler wirklich zählt.

mTLS ohne die Service-Mesh-Steuer

Hier ist die Sache mit Service Meshes: Jeder will die Sicherheitsgarantien, niemand will den operativen Overhead. AKS schließt diese Lücke endlich.

Azure Kubernetes Application Network gibt dir Mutual TLS, anwendungsbewusste Autorisierung und Traffic-Telemetrie — ohne ein volles Sidecar-lastiges Mesh zu deployen. In Kombination mit Cilium mTLS in Advanced Container Networking Services bekommst du verschlüsselte Pod-zu-Pod-Kommunikation mit X.509-Zertifikaten und SPIRE für Identity Management.

Was das in der Praxis bedeutet: Deine ASP.NET Core APIs, die mit Background-Workern kommunizieren, deine gRPC-Services, die sich gegenseitig aufrufen — alles verschlüsselt und identitätsverifiziert auf Netzwerkebene, ohne eine einzige Code-Änderung. Das ist gewaltig.

Für Teams, die von ingress-nginx migrieren, gibt es außerdem Application Routing mit Meshless Istio mit vollem Kubernetes Gateway API Support. Keine Sidecars. Standardbasiert. Und sie haben ingress2gateway-Tools für inkrementelle Migration mitgeliefert.

GPU-Observability, die kein Nachgedanke ist

Wenn du KI-Inferenz neben deinen .NET-Services ausführst (und seien wir ehrlich, wer fängt nicht langsam damit an?), bist du wahrscheinlich auf den GPU-Monitoring-Blindspot gestoßen. Du hattest großartige CPU/Memory-Dashboards und dann… nichts für GPUs ohne manuelle Exporter-Konfiguration.

AKS zeigt GPU-Metriken jetzt nativ in Managed Prometheus und Grafana an. Gleicher Stack, gleiche Dashboards, gleiche Alerting-Pipeline. Keine Custom-Exporter, keine Third-Party-Agents.

Auf der Netzwerkseite wurde Per-Flow-Visibilität für HTTP-, gRPC- und Kafka-Traffic mit einer One-Click Azure Monitor-Erfahrung hinzugefügt. IPs, Ports, Workloads, Flow-Richtung, Policy-Entscheidungen — alles in eingebauten Dashboards.

Und hier kommt die, bei der ich zweimal hingeschaut habe: Agentic Container Networking fügt eine Web-UI hinzu, in der du natürlichsprachliche Fragen zum Netzwerkzustand deines Clusters stellen kannst. „Warum erreicht Pod X Service Y nicht?" → Read-Only-Diagnose aus Live-Telemetrie. Das ist um 2 Uhr nachts wirklich nützlich.

Cross-Cluster-Networking ohne Doktortitel

Multi-Cluster Kubernetes war historisch eine „Bring deinen eigenen Netzwerk-Kleber mit"-Erfahrung. Azure Kubernetes Fleet Manager liefert jetzt Cross-Cluster-Networking über Managed Cilium Cluster Mesh:

Einheitliche Konnektivität über AKS-Cluster hinweg
Globale Service-Registry für Cross-Cluster-Discovery
Zentral verwaltete Konfiguration statt pro Cluster wiederholt

Wenn du .NET-Microservices über Regionen hinweg für Resilienz oder Compliance betreibst, ersetzt das eine Menge fragilen Custom-Kleber. Service A in West Europe kann Service B in East US über das Mesh entdecken und aufrufen, mit konsistenten Routing- und Sicherheitsrichtlinien.

Upgrades, die keinen Mut erfordern

Seien wir ehrlich — Kubernetes-Upgrades in Produktion sind stressig. „Upgraden und hoffen" war die De-facto-Strategie für zu viele Teams und der Hauptgrund, warum Cluster bei Versionen hinterherhinken.

Zwei neue Fähigkeiten ändern das:

Blue-Green Agent Pool Upgrades erstellen einen parallelen Node-Pool mit der neuen Konfiguration. Verhalten validieren, Traffic schrittweise verlagern und einen sauberen Rollback-Pfad behalten. Keine In-Place-Mutationen auf Produktions-Nodes mehr.

Agent Pool Rollback ermöglicht es, einen Node-Pool auf seine vorherige Kubernetes-Version und Node-Image zurückzusetzen, wenn ein Upgrade schiefgeht — ohne den Cluster neu aufzubauen.

Zusammen geben sie Operatoren endlich echte Kontrolle über den Upgrade-Lebenszyklus. Für .NET-Teams ist das wichtig, weil Plattform-Geschwindigkeit direkt steuert, wie schnell du neue Runtimes, Sicherheitspatches und Netzwerk-Fähigkeiten einsetzen kannst.

KI-Workloads werden zu First-Class Kubernetes-Bürgern

Die Upstream-Open-Source-Arbeit ist gleichermaßen wichtig. Dynamic Resource Allocation (DRA) ist gerade in Kubernetes 1.36 GA geworden und macht GPU-Scheduling zu einem echten First-Class-Feature statt eines Workarounds.

Einige Projekte, die es wert sind beobachtet zu werden:

Projekt	Was es macht
AI Runway	Gemeinsame Kubernetes-API für Inferenz — Models deployen ohne K8s-Kenntnisse, mit HuggingFace-Discovery und Kostenschätzungen
HolmesGPT	Agentisches Troubleshooting für Cloud-Native — jetzt ein CNCF-Sandbox-Projekt
Dalec	Deklarative Container-Image-Builds mit SBOM-Generierung — weniger CVEs in der Build-Phase

Die Richtung ist klar: Deine .NET-API, deine Semantic-Kernel-Orchestrierungsschicht und deine Inferenz-Workloads sollten alle auf einem konsistenten Plattformmodell laufen. Wir kommen dahin.

Wo ich diese Woche anfangen würde

Wenn du diese Änderungen für dein Team evaluierst, hier meine ehrliche Prioritätenliste:

Observability zuerst — GPU-Metriken und Netzwerk-Flow-Logs in einem Nicht-Prod-Cluster aktivieren. Schau dir an, was du verpasst hast.
Blue-Green-Upgrades testen — den Rollback-Workflow vor deinem nächsten Produktions-Cluster-Upgrade ausprobieren. Vertrauen in den Prozess aufbauen.
Identity-Aware Networking pilotieren — einen internen Service-Pfad wählen und mTLS mit Cilium aktivieren. Den Overhead messen (Spoiler: er ist minimal).
Fleet Manager evaluieren — wenn du mehr als zwei Cluster betreibst, zahlt sich Cross-Cluster-Networking durch weniger Custom-Kleber von selbst.

Kleine Experimente, schnelles Feedback. Das ist immer der richtige Zug.

Zum Schluss

KubeCon-Ankündigungen können überwältigend sein, aber diese Runde bewegt wirklich etwas für .NET-Teams auf AKS. Bessere Netzwerksicherheit ohne Mesh-Overhead, echte GPU-Observability, sicherere Upgrades und stärkere KI-Infrastruktur-Grundlagen.

Wenn du bereits auf AKS bist, ist jetzt ein großartiger Moment, deine operative Baseline zu verbessern. Und wenn du planst, .NET-Workloads auf Kubernetes zu verlagern — die Plattform ist gerade deutlich produktionsreifer geworden.