> Markdown version of [/videos/100188-diagnostic-tooling-how-to-get-insights-from-your-net-services-hosted-in-kubernetes-containers?t=442](https://www.wearedevelopers.com/videos/100188-diagnostic-tooling-how-to-get-insights-from-your-net-services-hosted-in-kubernetes-containers?t=442). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md). --- # Diagnostic Tooling: How to get insights from your .NET services hosted in Kubernetes containers? Struggling to extract diagnostic data from hardened, shell-less Kubernetes containers? Learn how to securely generate memory dumps and CPU traces using dotnet-monitor as a decoupled sidecar. - **Speakers:** [Tom Crecelius](https://www.wearedevelopers.com/@tom-crecelius) - **Event:** World Congress 2026 Europe - **Published:** July 10, 2026 - **Duration:** 28:30 - **URL:** https://www.wearedevelopers.com/videos/100188-diagnostic-tooling-how-to-get-insights-from-your-net-services-hosted-in-kubernetes-containers ## Summary Running .NET services in modern, production-ready Kubernetes environments brings a fresh set of challenges—specifically, extracting diagnostic data from hardened, shell-less containers. Baking CLI tools directly into application images is a profound security risk and a violation of operational concerns. Instead, developers need a secure, decoupled method for generating and retrieving memory dumps, CPU traces, and event counters without compromising environment integrity. The solution lies in configuring `dotnet-monitor` as a diagnostic sidecar container. By altering the default diagnostic port behaviors and utilizing shared volume mounts, teams can communicate with the .NET runtime through Unix domain sockets. `dotnet-monitor` introduces an HTTP API and rule-based triggers to collect highly specific telemetry, such as GC (garbage collector) dumps and CPU thresholds, either on demand or automatically. For robust production deployment, this configuration must prioritize securing the monitoring endpoints. This involves mapping Kubernetes secrets to enforce API key authentication and TLS encryption via Kestrel, while utilizing egress providers to safely offload diagnostic artifacts to Azure Blob or S3-compatible storage. As an alternative to sidecars, developers can leverage Kubernetes ephemeral containers for debugging, though this approach requires intricate JSON workarounds for volume mounting and strict pod resource management. **Keywords:** kubernetes diagnostic tooling, dotnet-monitor sidecar, containerized .NET services, kubernetes security policies, diagnostic ports configuration, .NET event pipes, GC heap snapshots, chiseled container debugging, kubectl port-forwarding, kubernetes ephemeral containers, HTTP API telemetry triggers, egress providers offloading, secure S3 artifact storage, TLS Kestrel encryption, shared volume mounts ## Chapters 1. **Defining diagnostic artifacts and their continuous importance** (00:10) — Diagnostic artifacts like files and captured data help analyze runtime conditions for troubleshooting and optimization. 1. **Building blocks of the .NET diagnostic ecosystem** (03:11) — Events, event counters, and memory dumps form the technical foundation of .NET runtime analysis. 1. **Extracting runtime data with event pipes and diagnostic ports** (04:55) — Event pipes emit continuous data streams while diagnostic ports enable two-way communication between the runtime and external tools. 1. **Challenges of diagnosing services in secured Kubernetes clusters** (07:22) — Hardened container images restrict standard analysis tools and limit the ability to execute inside pods. 1. **Security risks of baking diagnostic tools into application images** (09:13) — Including troubleshooting utilities inside production containers compromises security and violates the minimum-privilege principle. 1. **Centralizing artifact collection using dotnet monitor via APIs** (12:34) — The dotnet monitor tool enables on-demand trace creation and rule-based diagnostic triggers without compromising application boundaries. 1. **Configuring a diagnostic sidecar container in Kubernetes pods** (13:40) — A dedicated sidecar securely shares a diagnostic port volume with the main application for safe external investigation. 1. **Customizing diagnostic port locations for enhanced security** (15:30) — Using a dedicated diagnostic folder instead of the default temporary directory prevents unintentional access by other shared components. 1. **Securing the HTTP API with authentication and TLS encryption** (17:59) — Production deployments of dotnet monitor require secure API keys and TLS certificates mounted via Kubernetes secrets. 1. **Automating artifact storage using secure egress providers** (20:01) — Egress providers allow immediate and secure export of diagnostic artifacts to external locations like network shares or blob storage. 1. **Injecting ephemeral debug containers into running Kubernetes pods** (21:34) — Ephemeral containers offer a lightweight, temporary alternative to sidecars but require specialized APIs to enable necessary volume mounts. 1. **Summary of container diagnostics and garbage collector behavior** (26:00) — A brief recap of the recommended diagnostic approaches and clarification on how memory dumps automatically trigger garbage collection. ## Related Moments - [Debugging serverless container applications in Kubernetes production environments](https://www.wearedevelopers.com/videos/243-serverless-native-java-with-quarkus) (from "Serverless-Native Java with Quarkus") - [Introduction to Kubernetes security challenges and opportunities](https://www.wearedevelopers.com/videos/412-kubernetes-security-challenge-and-opportunity) (from "Kubernetes Security - Challenge and Opportunity") - [Assessing common Kubernetes security incidents and misconfigurations](https://www.wearedevelopers.com/videos/1411-kubernetes-security-best-practices) (from "Kubernetes Security Best Practices") - [Optimizing software development for production and Kubernetes](https://www.wearedevelopers.com/videos/383-kubernetes-native-java) (from "Kubernetes Native Java") - [Decomposing infrastructure problems using sandbox environments and networking tools](https://www.wearedevelopers.com/videos/1055-how-i-saved-200k-yr-in-direct-costs-writing-0-code-lines-in-k8s) (from "How I saved 200K/yr in direct costs writing 0 code lines in K8s") - [Addressing local development challenges with Podman Desktop](https://www.wearedevelopers.com/videos/1133-containers-and-kubernetes-made-easy-deep-dive-into-podman-desktop-and-new-ai-capabilities) (from "Containers and Kubernetes made easy: Deep dive into Podman Desktop and new AI capabilities") ## Related Articles - [Learning Kubernetes made easy with KubeCampus](https://www.wearedevelopers.com/magazine/348-learning-kubernetes-made-easy-with-kubecampus) - [Building AI Solutions with Rust and Docker](https://www.wearedevelopers.com/magazine/494-building-ai-solutions-with-rust-and-docker) - [Dev Digest 138 - Are you secure about this?](https://www.wearedevelopers.com/magazine/486-dev-digest-138-are-you-secure-about-this) - [Dev Digest 132 - Binging WADFlix?](https://www.wearedevelopers.com/magazine/473-dev-digest-132-binging-wadflix) ## Related Jobs - [Lead Cloud DevSecOps Engineer - Kubernetes](https://www.wearedevelopers.com/jobs/ext/1659167-lead-cloud-devsecops-engineer-kubernetes) at **BWI GmbH** - [Platform Engineer (DevOps)](https://www.wearedevelopers.com/jobs/48264-platform-engineer-devops) at **WDW Consulting GmbH** - [Devops Engineer](https://www.wearedevelopers.com/jobs/ext/1940926-devops-engineer) at **Bitpanda** - [Lead Software Engineer - Data Engineering](https://www.wearedevelopers.com/jobs/ext/2000968-lead-software-engineer-data-engineering) at **Dynatrace** - [Software Engineer, Platform Engineering (L2)](https://www.wearedevelopers.com/jobs/ext/1956829-software-engineer-platform-engineering-l2) at **Twilio** - [Senior Engineer, Infrastructure Platform](https://www.wearedevelopers.com/jobs/ext/328836-senior-engineer-infrastructure-platform) at **Intercom, Inc.**