Kubernetes | The .NET Blog

Aspire 13.3: Kubernetes Support, Browser Logs, and the Aspireify Skill

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

Five weeks is not a long time for a release, but Aspire 13.3 doesn’t feel like it. The headline items are meaningful: first-class Kubernetes and AKS deployment with Helm, an agent-assisted onboarding skill called Aspireify, browser log capture directly in the dashboard, and structured command results. Plus 45 new features, 134 improvements, and 93 bug fixes.

Let’s hit the highlights.

Aspireify: Agent-Assisted Onboarding

Adding Aspire to an existing project sounds simple — drop an AppHost in, done. In practice it involves a lot of archaeology: which ports matter, which environment variables are real dependencies, which Docker Compose services should map to Aspire integrations.

The new Aspireify skill gives your coding agent a guided workflow for exactly this. When aspire init drops a skeleton AppHost, the Aspireify skill helps the agent inspect the repo, understand how it already runs, and wire the AppHost to fit the app — not the other way around.

The default stance is “minimize changes to your code.” If your app already reads DATABASE_URL, the agent maps that with WithEnvironment() instead of asking you to rewrite your configuration. If a port is hardcoded, the skill tells the agent when to preserve it.

This is the kind of AI tooling that actually saves time rather than generating more work to review.

First-Class Kubernetes and AKS Deployment

This one has been on the wishlist for a while. Aspire 13.3 ships first-class Kubernetes and AKS deployment support with Helm. You can now target AKS as a deployment target directly from the Aspire tooling.

For teams already running production workloads on AKS, this closes a significant gap. Your Aspire app model now has a clean path from local dev to Kubernetes without manual Helm chart authoring.

Browser Logs in the Dashboard

This is one of those features that sounds small until you’re debugging a frontend issue.

The new WithBrowserLogs() API attaches a tracked browser resource to any endpoint-capable resource. Aspire launches Chromium using a private CDP pipe and streams console logs, network requests, and errors directly into the resource log stream:

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

TypeScript AppHost supports the same:

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

Console errors, failed network requests, client-side exceptions — all visible in the same dashboard where you’re already watching traces and metrics. No more tab-switching to browser DevTools for the basic stuff.

Structured Command Results

Resource commands got a meaningful upgrade. Until now, commands returned success/failure. Now they return structured results: text, JSON, or markdown that flows through the model, dashboard UI, CLI, and MCP tools.

The dashboard ties this together with a new notification center in the header. Command results show up as timestamped notifications with markdown rendering and a “View response” action.

This makes resource commands genuinely composable. An integration can now expose a command that returns meaningful output — like a tunnel URL — rather than just changing state somewhere.

Wrapping Up

Aspire 13.3 is worth the upgrade even just for the Kubernetes support. The browser logs and structured command results feel like the kind of quality-of-life improvements that accumulate quickly in a day-to-day development workflow.

Full release notes: What’s New in Aspire 13.3

KubeCon Europe 2026: What .NET Developers Should Actually Care About

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

You know that feeling when a massive announcement post drops and you’re scrolling through it thinking “cool, but what does this actually change for me”? That’s me every KubeCon season.

Microsoft just published their full KubeCon Europe 2026 roundup — written by Brendan Burns himself — and honestly? There’s real substance here. Not just feature checkboxes, but the kind of operational improvements that change how you run things in production.

Let me break down what actually matters for us .NET developers.

mTLS without the service mesh tax

Here’s the thing about service meshes: everyone wants the security guarantees, nobody wants the operational overhead. AKS is finally closing that gap.

Azure Kubernetes Application Network gives you mutual TLS, application-aware authorization, and traffic telemetry — without deploying a full sidecar-heavy mesh. Combined with Cilium mTLS in Advanced Container Networking Services, you get encrypted pod-to-pod communication using X.509 certificates and SPIRE for identity management.

What this means in practice: your ASP.NET Core APIs talking to background workers, your gRPC services calling each other — all encrypted and identity-verified at the network level, with zero application code changes. That’s huge.

For teams migrating off ingress-nginx, there’s also Application Routing with Meshless Istio with full Kubernetes Gateway API support. No sidecars. Standards-based. And they shipped ingress2gateway tooling for incremental migration.

GPU observability that’s not an afterthought

If you’re running AI inference alongside your .NET services (and let’s be honest, who isn’t starting to?), you’ve probably hit the GPU monitoring blind spot. You’d get great CPU/memory dashboards and then… nothing for GPUs without manual exporter plumbing.

AKS now surfaces GPU metrics natively into managed Prometheus and Grafana. Same stack, same dashboards, same alerting pipeline. No custom exporters, no third-party agents.

On the network side, they added per-flow visibility for HTTP, gRPC, and Kafka traffic with a one-click Azure Monitor experience. IPs, ports, workloads, flow direction, policy decisions — all in built-in dashboards.

And here’s the one that made me do a double-take: agentic container networking adds a web UI where you can ask natural-language questions about your cluster’s network state. “Why is pod X not reaching service Y?” → read-only diagnostics from live telemetry. That’s genuinely useful at 2 AM.

Cross-cluster networking that doesn’t require a PhD

Multi-cluster Kubernetes has historically been a “bring your own networking glue” experience. Azure Kubernetes Fleet Manager now ships cross-cluster networking through managed Cilium cluster mesh:

Unified connectivity across AKS clusters
Global service registry for cross-cluster discovery
Configuration managed centrally, not repeated per cluster

If you’re running .NET microservices across regions for resilience or compliance, this replaces a lot of fragile custom plumbing. Service A in West Europe can discover and call Service B in East US through the mesh, with consistent routing and security policies.

Upgrades that don’t require courage

Let’s be honest — Kubernetes upgrades in production are stressful. “Upgrade and hope” has been the de facto strategy for too many teams, and it’s the main reason clusters fall behind on versions.

Two new capabilities change this:

Blue-green agent pool upgrades create a parallel node pool with the new configuration. Validate behavior, shift traffic gradually, and keep a clean rollback path. No more in-place mutations on production nodes.

Agent pool rollback lets you revert a node pool to its previous Kubernetes version and node image after an upgrade goes sideways — without rebuilding the cluster.

Together, these finally give operators real control over the upgrade lifecycle. For .NET teams, this matters because platform velocity directly controls how fast you can adopt new runtimes, security patches, and networking capabilities.

AI workloads are becoming first-class Kubernetes citizens

The upstream open-source work is equally important. Dynamic Resource Allocation (DRA) just went GA in Kubernetes 1.36, making GPU scheduling a proper first-class feature instead of a workaround.

A few projects worth watching:

Project	What it does
AI Runway	Common Kubernetes API for inference — deploy models without knowing K8s, with HuggingFace discovery and cost estimates
HolmesGPT	Agentic troubleshooting for cloud-native — now a CNCF Sandbox project
Dalec	Declarative container image builds with SBOM generation — fewer CVEs at the build stage

The direction is clear: your .NET API, your Semantic Kernel orchestration layer, and your inference workloads should all run on one consistent platform model. We’re getting there.

Where I’d start this week

If you’re evaluating these changes for your team, here’s my honest priority list:

Observability first — enable GPU metrics and network flow logs in a non-prod cluster. See what you’ve been missing.
Try blue-green upgrades — test the rollback workflow before your next production cluster upgrade. Build confidence in the process.
Pilot identity-aware networking — pick one internal service path and enable mTLS with Cilium. Measure the overhead (spoiler: it’s minimal).
Evaluate Fleet Manager — if you run more than two clusters, cross-cluster networking pays for itself in reduced custom glue.

Small experiments, fast feedback. That’s always the move.

Wrapping up

KubeCon announcements can be overwhelming, but this batch genuinely moves the needle for .NET teams on AKS. Better networking security without mesh overhead, real GPU observability, safer upgrades, and stronger AI infrastructure foundations.

If you’re already on AKS, this is a great moment to tighten your operational baseline. And if you’re planning to move .NET workloads to Kubernetes — the platform just got significantly more production-ready.