Deploying .NET applications on Kubernetes has specific patterns that differ from other language ecosystems. The .NET runtime's characteristics (startup time, memory model, threading) shape the deployment patterns.
Container image optimisation
Multi-stage Docker builds for .NET: stage 1 (SDK image) builds the application; stage 2 (runtime image) copies only the published output. The ASP.NET Core runtime image is significantly smaller than the SDK image. For smallest possible images: use self-contained single-file publish, base on the runtime-deps image (not the full runtime), and use ReadyToRun compilation to reduce startup time at the cost of slightly larger binary size.
.NET 5 startup time
ASP.NET Core startup time has improved significantly with each release. .NET 5 with ReadyToRun (R2R) compilation starts in 100-200ms compared to 1-2 seconds for JIT compilation from cold. R2R pre-compiles the IL to native code for the target platform, eliminating JIT overhead on startup. This matters for Kubernetes workloads that scale out rapidly, new pod instances should be ready in seconds.
Health endpoints for Kubernetes probes
ASP.NET Core's health check framework provides /health endpoints that Kubernetes liveness and readiness probes call. Liveness probe: check that the application process is running and not deadlocked (a simple OK response). Readiness probe: check that all dependencies (database, cache, upstream services) are accessible before the pod receives traffic. The Microsoft.Extensions.Diagnostics.HealthChecks NuGet package provides health check implementations for common Azure and .NET dependencies.
Horizontal Pod Autoscaler for .NET workloads
HPA for .NET web APIs works best with custom metrics: request rate per pod (from Prometheus + kube-metrics-adapter), queue depth for background worker pods, or business-level throughput metrics. CPU utilisation as the HPA metric works for CPU-bound .NET workloads but lags for IO-bound workloads where pods are waiting on database responses rather than consuming CPU. The KEDA (Kubernetes Event-Driven Autoscaling) project provides HPA based on Azure Service Bus queue depth, Kafka lag, and other event source metrics.