Introduction

Limiting memory for a .NET application in Kubernetes requires configuration at both Kubernetes and runtime levels. Kubernetes enforces container memory limits using cgroups, while .NET runtime adjusts GC and heap behavior based on detected constraints. If limits are missing or misaligned, pods may get OOMKilled or suffer heavy GC pressure. A production-safe setup defines requests/limits in manifests, sets runtime tuning only when necessary, and monitors memory behavior under realistic load.

Core Sections

Set pod memory requests and limits

Define both requests and limits in your deployment spec.

1resources:
2  requests:
3    memory: "256Mi"
4    cpu: "250m"
5  limits:
6    memory: "512Mi"
7    cpu: "1"

requests affect scheduling. limits enforce hard caps.

Configure .NET runtime when needed

Modern .NET respects cgroup limits, but explicit tuning can help.

1env:
2  - name: DOTNET_GCHeapHardLimit
3    value: "402653184" # 384 MiB in bytes
4  - name: DOTNET_GCHeapCount
5    value: "4"

Only set hard limits after profiling; over-constraining can hurt throughput.

Example deployment snippet

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: api
5spec:
6  replicas: 2
7  template:
8    spec:
9      containers:
10        - name: api
11          image: myrepo/api:1.0.0
12          resources:
13            requests:
14              memory: "256Mi"
15            limits:
16              memory: "512Mi"

Keep values consistent with workload characteristics and node capacity.

Observe memory usage in production

Track:

• working set and RSS,
• GC pause time,
• OOM kill count,
• request latency under memory pressure.

Use Prometheus/Grafana or your platform metrics stack.

Tune by load testing, not guesswork

Run stress tests with realistic traffic. Increase limits gradually, then compare latency and error rates. Memory tuning without representative load often produces unstable results in production.

Common Pitfalls

• Setting only limits without requests and causing poor scheduling behavior.
• Using very tight memory limits that trigger frequent OOM kills.
• Hardcoding GC env vars without measuring impact.
• Ignoring memory leaks and trying to mask them with larger limits.
• Treating local container behavior as identical to Kubernetes production nodes.

Verification Workflow

Validate memory settings by running load tests long enough to capture steady-state GC behavior. Confirm pods do not OOM, latency remains acceptable, and autoscaling signals are sane. Keep at least one canary deployment with tighter observability before rolling memory changes cluster-wide.

11. Deploy with explicit requests/limits
22. Run sustained load test
33. Monitor RSS, GC, and latency
44. Check OOM and restart counts
55. Adjust limits based on measured headroom

Operational Hardening

For production-quality implementation, convert the conceptual solution into a repeatable operational practice. Start by documenting exact prerequisites such as runtime versions, configuration defaults, and required permissions. Then add one executable smoke test that can run quickly in CI and a second environment-check script that validates external dependencies before rollout. Capture structured logs for both success and failure paths so troubleshooting does not depend on manual reproduction.

Create lightweight runbook notes with concrete failure signatures and first-response actions. Include known transient failures, expected retry behavior, and safe rollback steps. If your system has multiple environments, verify the same workflow on local, staging, and production-like infrastructure to catch hidden differences in networking, file paths, or credentials. Keep this process intentionally small so engineers actually run it during routine changes.

11. Document prerequisites and version constraints
22. Run fast smoke test in CI
33. Validate environment dependencies before deploy
44. Capture structured logs and error signatures
55. Rehearse rollback procedure
66. Record outcomes for future regressions

Summary

For .NET apps on Kubernetes, memory control starts with proper pod requests and limits, then optional runtime tuning when data supports it. Monitor real behavior under load and iterate carefully. Clear resource policies and validation reduce OOM incidents and improve overall service stability.