Kubernetes | The .NET Blog

Aspire 13.3：Kubernetes 支持、浏览器日志和 Aspireify 技能

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

五周对于一个版本来说并不长，但 Aspire 13.3 让人感觉不是这样。主要内容非常重要：使用 Helm 进行 Kubernetes 和 AKS 一流部署、名为 Aspireify 的代理辅助入门技能、直接在仪表板中捕获浏览器日志，以及结构化命令结果。还包括 45 项新功能、134 项改进和 93 个错误修复。

让我们来看看亮点。

Aspireify：代理辅助入门

将 Aspire 添加到现有项目听起来很简单——添加 AppHost，完成。实际上需要大量研究：哪些端口重要、哪些环境变量是真正的依赖项、哪些 Docker Compose 服务应该映射到 Aspire 集成。

新的 Aspireify 技能 正是为此为您的编码代理提供了引导工作流程。当 aspire init 创建骨架 AppHost 时，Aspireify 技能会帮助代理检查存储库、了解其已有的工作方式，并连接 AppHost 以适应应用程序——而不是反过来。

默认立场是"最小化对代码的更改"。如果您的应用程序已经读取 DATABASE_URL，代理会使用 WithEnvironment() 进行映射，而不是要求您重写配置。如果端口是硬编码的，该技能会告诉代理何时保留它。

这正是那种能真正节省时间而不是生成更多审查工作的 AI 工具。

一流的 Kubernetes 和 AKS 部署

这在愿望清单上已经有一段时间了。Aspire 13.3 提供了使用 Helm 的 Kubernetes 和 AKS 一流部署支持。您现在可以直接从 Aspire 工具中将 AKS 指定为部署目标。

对于已经在 AKS 上运行生产工作负载的团队，这弥补了一个重要缺口。您的 Aspire 应用模型现在有了从本地开发到 Kubernetes 的清晰路径，无需手动编写 Helm 图表。

仪表板中的浏览器日志

这是那些在调试前端问题之前看起来很小的功能之一。

新的 WithBrowserLogs() API 将跟踪的浏览器资源附加到任何支持端点的资源。Aspire 使用私有 CDP 管道启动 Chromium，并将控制台日志、网络请求和错误直接流式传输到资源的日志流中：

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

TypeScript AppHost 同样支持：

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

控制台错误、失败的网络请求、客户端异常——所有这些都在您已经观察追踪和指标的同一仪表板中可见。不再需要为了基础内容切换到浏览器 DevTools。

结构化命令结果

资源命令获得了重大升级。到目前为止，命令返回成功/失败。现在它们返回结构化结果：流经模型、仪表板 UI、CLI 和 MCP 工具的文本、JSON 或 Markdown。

仪表板通过标题中的新通知中心将这一切联系在一起。命令结果以带时间戳的通知形式出现，带有 Markdown 渲染和"查看响应"操作。

这使资源命令真正可组合。集成现在可以公开一个返回有意义输出的命令——比如隧道 URL——而不仅仅是在某处更改状态。

结论

Aspire 13.3 仅凭 Kubernetes 支持就值得升级。浏览器日志和结构化命令结果感觉像是那种在日常开发工作流程中快速积累的生活质量改进。

完整发布说明：What’s New in Aspire 13.3

KubeCon Europe 2026：.NET 开发者真正需要关注的内容

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

本文为自动翻译。查看原文请点击这里。

你知道那种感觉吗？一个巨大的公告文章出来了，你一边滚动一边想"不错，但这对我到底有什么改变"？这就是我每个 KubeCon 季的状态。

微软刚刚发布了他们的 KubeCon Europe 2026 完整总结——出自 Brendan Burns 本人之手——说实话？这次有真正的干货。不只是功能清单，而是真正改变你在生产环境中运维方式的运营改进。

让我来梳理一下对我们 .NET 开发者真正重要的内容。

不用付服务网格税的 mTLS

服务网格的问题在于：每个人都想要安全保障，没人想要运营负担。AKS 终于在弥补这个差距了。

Azure Kubernetes Application Network 给你提供了双向 TLS、应用感知授权和流量遥测——不需要部署一个带 sidecar 的重型 mesh。结合 Advanced Container Networking Services 中的 Cilium mTLS，你可以获得使用 X.509 证书和 SPIRE 身份管理的加密 pod 间通信。

这在实践中意味着什么：你的 ASP.NET Core API 与后台 worker 通信，你的 gRPC 服务互相调用——全部在网络层加密和身份验证，零应用代码更改。这意义重大。

对于从 ingress-nginx 迁移的团队，还有 Meshless Istio 的 Application Routing 全面支持 Kubernetes Gateway API。无 sidecar。基于标准。并且发布了 ingress2gateway 工具用于增量迁移。

不再是事后想到的 GPU 可观测性

如果你在 .NET 服务旁运行 AI 推理（说实话，谁现在还没开始？），你可能遇到过 GPU 监控盲区。CPU/内存仪表板很棒，然后 GPU 部分…没有手动配置导出器就什么都没有。

AKS 现在原生暴露 GPU 指标到托管的 Prometheus 和 Grafana。同样的技术栈，同样的仪表板，同样的告警管道。无需自定义导出器，无需第三方代理。

在网络方面，增加了 HTTP、gRPC 和 Kafka 流量的逐流可见性，配合一键 Azure Monitor 体验。IP、端口、工作负载、流方向、策略决策——全部在内置仪表板中。

让我看了两遍的是：agentic container networking 添加了一个 Web UI，你可以用自然语言询问集群的网络状态。“为什么 pod X 无法到达服务 Y？"→ 从实时遥测获取只读诊断。凌晨两点真的很有用。

不需要博士学位的跨集群网络

多集群 Kubernetes 历来是"自带网络胶水"的体验。Azure Kubernetes Fleet Manager 现在通过托管 Cilium 集群网格提供跨集群网络：

AKS 集群间的统一连接
用于跨集群发现的全局服务注册表
集中管理配置，而不是每个集群重复

如果你为了弹性或合规在多个区域运行 .NET 微服务，这替代了很多脆弱的自定义胶水。West Europe 的服务 A 可以通过网格发现和调用 East US 的服务 B，使用一致的路由和安全策略。

不需要勇气的升级

说实话——生产环境中的 Kubernetes 升级是有压力的。“升级然后祈祷"一直是太多团队的实际策略，也是集群版本落后的主要原因。

两个新功能改变了这一点：

Blue-green 代理池升级 用新配置创建一个并行节点池。验证行为，逐步转移流量，保持干净的回滚路径。不再在生产节点上进行就地变更。

代理池回滚 允许你在升级出问题后将节点池恢复到之前的 Kubernetes 版本和节点镜像——无需重建集群。

两者结合，终于给运维人员提供了对升级生命周期的真正控制。对于 .NET 团队来说很重要，因为平台速度直接控制你能多快采用新的运行时、安全补丁和网络能力。

AI 工作负载成为 Kubernetes 一等公民

上游开源工作同样重要。Dynamic Resource Allocation (DRA) 刚在 Kubernetes 1.36 中 GA，使 GPU 调度成为真正的一等功能而不是变通方案。

值得关注的项目：

项目	作用
AI Runway	推理的通用 Kubernetes API——不懂 K8s 也能部署模型，带 HuggingFace 发现和成本估算
HolmesGPT	云原生的智能体故障排除——现在是 CNCF Sandbox 项目
Dalec	带 SBOM 生成的声明式容器镜像构建——构建阶段减少 CVE

方向很明确：你的 .NET API、Semantic Kernel 编排层和推理工作负载应该都运行在一个一致的平台模型上。我们正在接近。

这周我会从哪里开始

如果你在为团队评估这些变化，这是我真诚的优先级列表：

先搞可观测性——在非生产集群中启用 GPU 指标和网络流日志。看看你一直错过了什么。
测试 blue-green 升级——在下次生产集群升级前测试回滚工作流。建立对流程的信心。
试点身份感知网络——选择一个内部服务路径并用 Cilium 启用 mTLS。测量开销（剧透：很小）。
评估 Fleet Manager——如果你运行超过两个集群，跨集群网络光减少自定义胶水就能回本。

小实验，快反馈。这永远是正确的做法。

总结

KubeCon 公告可能让人应接不暇，但这批更新确实为 AKS 上的 .NET 团队带来了实质性改变。更好的网络安全（无 mesh 开销）、真正的 GPU 可观测性、更安全的升级以及更强大的 AI 基础设施支撑。

如果你已经在用 AKS，现在是加强运营基准的好时机。如果你计划将 .NET 工作负载迁移到 Kubernetes——平台刚刚变得更加适合生产环境了。