找回密码
 立即注册
首页 资源区 代码 用 Sidecar 容器为 .NET Core 应用做诊断和性能分析 ...

用 Sidecar 容器为 .NET Core 应用做诊断和性能分析

123qwe 2025-5-28 22:08:42
在微服务架构和云原生应用广泛采用的今天,.NET Core 应用被越来越多地部署在 Kubernetes 集群中。然而,一旦这些应用出现性能瓶颈,仅靠传统的日志和指标可能无法定位问题的根本原因。
从 .NET Core 3 开始,微软推出了一系列跨平台的运行时诊断工具,比如:

  • dotnet-counters:用于查看实时性能计数器
  • dotnet-dump:抓取和分析内存转储
  • dotnet-trace:采集运行时事件和 CPU 栈信息
  • dotnet-gcdump:采集垃圾回收(GC)相关信息
这些工具通过 .NET Core 的 Diagnostic Server 与目标进程进行通信,在 Linux 系统中,它们通过 Unix Domain Socket 进行 IPC 交互。默认的 Socket 文件位于 /tmp 目录下。
使用 Sidecar 模式部署诊断工具

在容器环境下部署诊断工具通常有两种方式:

  • 将工具和应用程序打包在同一个镜像中
  • 使用 sidecar 容器独立运行诊断工具
第一种方式会导致镜像体积变大,且工具升级不方便。因此,推荐使用 Sidecar 容器:它与主容器在同一个 Pod 中运行,共享网络和存储卷,适合部署监控或日志收集等辅助任务。
我们将构建一个 Sidecar 模式的诊断方案,解决以下三个关键问题:

  • 如何从 Sidecar 容器访问主容器内的 .NET Core 进程
  • 如何共享 /tmp 目录以建立 IPC 通道
  • 如何持久化诊断数据
案例演示:分析一个 ASP.NET Core Worker Service

首先,我们创建一个简单的 Worker Service 应用,它会周期性计算某个位置的质数(模拟 CPU 密集型任务):
  1. _logger.LogInformation("Prime number at position {position} is {value}", pos, FindPrimeNumber(pos));
复制代码
然后为该应用构建镜像并推送到容器仓库(如 Docker Hub 或 Azure 容器注册表)。
接着,我们构建第二个容器镜像,下面是我们构建该 Sidecar 容器镜像所用的 Dockerfile:
  1. FROM mcr.microsoft.com/dotnet/sdk:5.0 as tools
  2. # 安装所需的 .NET 诊断工具
  3. RUN dotnet tool install --tool-path /tools dotnet-trace
  4. RUN dotnet tool install --tool-path /tools dotnet-dump
  5. RUN dotnet tool install --tool-path /tools dotnet-counters
  6. # 使用更小的运行时镜像作为最终镜像,减少体积
  7. FROM mcr.microsoft.com/dotnet/runtime:5.0 AS runtime
  8. # 将工具复制到最终镜像中
  9. COPY --from=tools /tools /tools
  10. # 添加工具目录到 PATH,确保容器启动后可以直接调用 dotnet 工具
  11. ENV PATH="/tools:${PATH}"
  12. WORKDIR /tools
复制代码
1.png

Kubernetes 部署设计

为了持久化诊断数据,我们需要一个挂载的共享存储。在 Azure Kubernetes Service (AKS) 中,我们可以动态创建基于 Azure Files 的存储卷。以下是关键的 YAML 片段:
  1. apiVersion: apps/v1
  2. kind: Deployment
  3. spec:
  4.   template:
  5.     spec:
  6.       shareProcessNamespace: true
  7.       containers:
  8.         - name: toolbox
  9.           image: <your-sidecar-image>
  10.           volumeMounts:
  11.             - name: tmp
  12.               mountPath: /tmp
  13.             - name: data
  14.               mountPath: /data
  15.         - name: app
  16.           image: <your-app-image>
  17.           volumeMounts:
  18.             - name: tmp
  19.               mountPath: /tmp
  20.       volumes:
  21.         - name: tmp
  22.           emptyDir: {}
  23.         - name: data
  24.           persistentVolumeClaim:
  25.             claimName: monitor-azfiles
复制代码
注意点

  • shareProcessNamespace: true 使得 Sidecar 可以看到主容器的进程
  • /tmp 目录通过 emptyDir 共享,建立 IPC 通道
  • Sidecar 容器的 /data 目录挂载 Azure Files 持久卷,用于存储诊断结果
  • 设置 stdin: true 和 tty: true 保证 Sidecar 容器处于可交互状态
部署完成后,你可以使用 kubectl exec 命令进入 Sidecar 容器:
  1. kubectl exec -it <pod-name> -n net-worker -c toolbox -- /bin/bash
复制代码
实际运行诊断工具

1. 使用 dotnet-trace 采集追踪数据

首先获取主容器的进程 ID:
  1. dotnet-trace ps
复制代码
然后开始采集数据并将其保存到挂载的共享目录中:
  1. dotnet-trace collect -p 13 --format Chromium -o /data/trace.json
复制代码
下载 /data/trace.json 后,可以用 Chrome 或 Edge 浏览器访问 chrome://tracing 或 edge://tracing 查看可视化结果。
2. 使用 dotnet-counters 查看性能指标
  1. dotnet-counters collect --process-id 13 --refresh-interval 10 --output /data/counters --format json
复制代码
同样可以将 JSON 文件下载后用 VS Code 打开分析。
总结

通过将诊断工具打包进 Sidecar 容器,并结合共享的 /tmp 目录和持久卷存储,我们可以在 Kubernetes 中高效、灵活地为 .NET Core 应用进行性能诊断。这种方式解耦了诊断工具与主应用容器,具有良好的可维护性和扩展性。

来源:新程序网络收集,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
您需要登录后才可以回帖 登录 | 立即注册